ミッションのスピードに合わせたリファクタリング：Red Hat AI によるレガシーシステムのモダナイゼーションに対する「エージェントメッシュ」アプローチ

レガシーソフトウェアは、自動的に終了が停止されるわけではありません。それはプロダクション環境に残り、技術的負債を蓄積し、変化を拒み、密かにリスクとなります。これは、何を実行するかというよりも’、何をもはやサポートできないかに関連して生じるリスクです。

これは、政府や産業界を支援する大手システムインテグレーター (SI) が直面している課題です。ミッションクリティカルなアプリケーションのポートフォリオにおいて、システムインテグレーター (SI) や航空宇宙企業は、古くなった Python や Java のコードベースを管理しています。これらは、最新でセキュリティを重視したサポート可能な基盤、とくに Red Hat Enterprise Linux 10 (RHEL 10) に移行する必要があります。

その目標は、単なるソフトウェアのアップグレードではありません。それは、ソフトウェア提供のスピード、AI のスピード、および政府のデータセンター、最前線のミッションエリア、または航空機のモバイルシステムが依存するセキュリティポスチャを維持することです。

これは米国連邦政府にとって理論的な話ではありません。 GSA の AI ガバナンスフレームワークと戦争省 (DoW) は現在、各機関やサービスに対し、責任ある AI を単に導入するだけでなく、これを運用化することを求めています。防衛またミッションのステークホルダーにとっての義務は単なるポリシーのチェック項目ではなく、内部のエージェントに重要な業務を委ねる前に、ソフトウェアファクトリーを正しく構築するための強制力となります。 

最近の案件で、絶対条件の 1 つとなっていたのが、完全なオフライン互換性でした。国家安全保障をサポートする環境は、多くの場合、設計上インターネットにアクセスできません。外部サービス (GitHub、クラウド API、リモートのパッケージレジストリー) への依存はすべて、脆弱性や障害の原因となり、あるいはシステムをコンプライアンスから大幅に逸脱させる可能性があります。 

システムを手動でモダナイズすることは技術的には可能でしたが、想定されるエンジニアリング作業は数年に及ぶため、必要とされる規模で実現することはできませんでした。別の選択肢は、何もせずに、運用リスクが増大する老朽化したシステムの運用を継続することでした。そこで、第 3 の道が存在するかどうかという疑問が生じました。エージェント型の自動化を使用して、より効率的なプロセスを構築し、エンジニアがすべてのステップを手作業で行うのではなく、大規模なモダナイゼーションを管理できるようにすることは可能でしょうか。

そこで、私たちは Red Hat AI と Red Hat OpenShift AI を使用して、エージェント型プラットフォームを構築しました。

大規模なレガシーのモダナイゼーションにおける問題

ブラウンフィールドの移行、つまり (グリーンフィールドの概念実証 (POC) ではなく) 実際のプロダクションコードを移行することは、何かを新しく構築することとは根本的に異なります。AI にプロンプトを出して完了、というわけにはいきません。

レガシーのコードベースには、多くの場合、次のような特徴があります。

• 老朽化したアーキテクチャ： これまでのエンジニアリング標準を反映した前提、フレームワーク、インフラストラクチャを中心として設計されたシステム。
• 限定的または不均一なテストカバレッジ：コードベースの大部分は、自動テストが標準的な手法となる前に記述されたものです。
• 暗黙的な動作の契約： 実際には存在するが、正式に文書化されたり強制されたりしたことのないモジュールやサービス間の依存関係。
• 蓄積された技術的負債：徐々に本番システムの一部となった、回避策、非推奨のライブラリ、互換性に関する修正のレイヤー。

国家安全保障のミッションにおいて、誤った結果を招くことのリスクは、抽象的なものではありません。移行の失敗は、単にアプリケーションを破損させるだけではなく、ワークフローを停止させ、ミッションを遅延させ、あるいは人々を保護するインフラストラクチャにセキュリティ上の脆弱性をもたらす可能性があります。

このような環境では、クラウド API の背後で実行される大規模な汎用フロンティアモデルは選択肢にはなりません。機密コードを外部エンドポイントに送信することはできません。大規模な環境では、予測不可能な推論動作を許容することはできません。クラウドのフロンティアモデルに接続できるとしても、リクエストが大規模なパラメータ空間にわたる長い推論チェーンに展開される場合、トークンのボリュームと計算のオーバーヘッドを正当化することはできません。大規模な移行では、システムに数百万行ものコードが含まれるため、それがすぐにレイテンシー、インフラコスト、運用リスクの増大につながります。

小規模で効率的なモデルが適切なツールとなる理由

ほとんどの AI アプリケーションでは、利用可能な最大のモデルを選択する傾向があります。その場合、パラメーターは増加し、コンテキストは拡大し、より優れた回答が期待されます。しかし、ネットワークから切断された、リソースに制約のあるミッションクリティカルな環境では、そのロジックはすぐに破綻してしまいます。大規模なフロンティアモデルでは、多くの場合、過剰なレイテンシー、予測不可能な推論ループ、および制御されたインフラストラクチャでの対応が困難となる大量の GPU メモリー需要が発生します。

小規模言語モデル (SLM) はエージェント型ワークフローに適しています。それは、システムでは、単にモデルの規模が大きいだけでなく、信頼性が高く再現性のある実行と低レイテンシーの応答が求められるからです。小規模なモデルは、ツール呼び出し、オーケストレーション、構造化された推論などの自動化タスクに適した、高速で確定的な動作を提供できます。また、ローカルでのファインチューニングと運用が容易であるため、チームは外部エンドポイントに依存することなく、ドメイン固有のエージェント群をデプロイできます。言い換えれば、モデルが 1 つのドメインのみをよく「理解」している場合、確率分布はより明確になり、同じ答えを生成する頻度が高まる傾向があります。

とはいえ、Red Hat によるテストでは、とくに大規模なソフトウェアシステムを把握する必要のあるコードの移行タスクにおいて、モデルの機能は依然としてコンテキスト長やパラメーター数と強い相関関係があることが明らかになりました。初期のテストで良好なパフォーマンスを発揮したモデルは、Llama 4 バリアントと Claude モデルでした。これは主に、非常に大きなコンテキストウィンドウ (256,000 トークン以上) と強力な推論能力によるものでした。逆に、Claude は時に単純なエンジニアリング・タスクについて考えすぎて、不必要に長い推論チェーンを生成し、トークンの使用量とレイテンシーを増加させることが判明しました。大規模な移行では、このような動作が積み重なり、すぐに多額の計算コストが生じます。

このため、現在は Meta Maverick をローカルで実行しており、大規模モデルの GPU メモリー要件を考慮して、Mistral モデルを使用した並行テストも行っています。また、Llama 4 Scout の再評価も進めています。これは優れたパフォーマンスを発揮しますが、同様に、現在の環境における利用可能なコンピューティングの限界を押し上げます。

実際的な回避策として、小規模なモデルを使用しながらワークフローをリファクタリングし、コンテキストの制限が発生した際にそれを軽減するハイブリッドモデル戦略を導入しました。

エージェントのハーネス向けの現時点でのモデル選択は、以下のとおりです。

• mistralai/Devstral-Small-2-24B-Instruct：コーディングエージェント用。256K トークンのコンテキスト。コーディングベンチマークで高いパフォーマンスを発揮し、ソフトウェア分析やリファクタリング・タスク向けに最適化されています。
• mistralai/Ministral-3-14B-Reasoning：非コーディングエージェント用。256K トークンのコンテキスト。構造化された推論、依存関係分析、および移行ワークフロー全体でのオーケストレーションに効果的です。

システムでは、エージェントモデルに加えて、ナレッジのインデックス作成と検索に特化したモデルも使用しています。

• gpt-oss-120B：コードベースのグローバル構造を表す GraphRAG ナレッジグラフの構築に使用されます。
• intfloat/e5-mistral-7B-instruct：GraphRAG のインデックス作成とベクトル検索に使用される埋め込みモデル。

これらは妥協による選択というわけではなく、利用可能なコンピューティング環境に基づく、目的に適したエンジニアリング上の判断によるものでした。私たちが直面するコンテキストの制限は GPU 容量に起因するものであり、アーキテクチャ自体の制約によるものではありません。インフラストラクチャのスケーリングに伴い、エージェントのハーネスやモデル選択戦略も拡張できます。

エージェントメッシュのアーキテクチャ：OpenShift AI 上に構築された、エージェント型の「ハーネスのハーネス」

このプラットフォームの中心となるのはエージェント型ハーネスです。これは、複数の専用 AI エージェントを連携させるモジュール式のオーケストレーション・フレームワークであり、各エージェントが移行ワークフローの特定の部分を担当します。このハーネスは OpenShift AI 上で実行され、vLLM を活用して効率的で低レイテンシーのモデル推論を行います。時間が経つにつれて、このパターンはエージェントメッシュと呼ばれるものへと進化しています。これは、複数のエージェント型ワークフローが相互運用し、タスクを調整し、複雑なモダナイゼーション・プログラム間で状態を共有できる「ハーネスのハーネス」アーキテクチャです。

現在のアーキテクチャの状況は次のとおりです。

コーディングエージェント (Devstral を利用) は、レガシーの Python 2 または Java ソースコードを分析し、非推奨の API を特定し、リファクタリングされた同等のものを生成して、変更を加える前の元の動作をキャプチャする特性評価テストを作成します。これらは単に構文を変換するだけでなく、動作の意図を維持するように機能します。

非コーディングエージェント (Ministral を利用) は、依存関係のマッピング、移行計画、進捗状況の追跡など、より広範なワークフロー全体で推論タスクを実行します。確定的なオーケストレーション・ロジックが実行フローを管理するため、エージェントは移行、検証、ブロックされた事項、および次に実行すべき内容に基づいて連携します。

カスタム追跡管理エージェントは、GitLab との統合を処理します (また接続されていない環境では完全に置き換えることも可能です)。このコンポーネントは、ブラックボックスではなく完全に検査可能なコードであり、組織はハーネスを既存の開発およびガバナンスシステムと統合できます。

ハーネス自体はモジュール性と交換可能性を考慮して設計されており、カスタム構築されたエージェントと OpenCode などのオープンソースエージェントを組み合わせています。システムがブラックボックスではないかという組織の質問に対する正直な答えは、一言では言い切れません。LLM 推論レイヤーは、他のニューラルネットワークと同様に本質的に不透明であるためです。しかし、オーケストレーション・ロジック、エージェントコード、出力、および意思決定の証跡は完全に追跡、監査、検査が可能であり、これは DoW のセキュリティおよび保証の要件の下で運用する組織にとって非常に重要です。

OpenShift AI 内で推論エンジンとして機能する vLLM は、重要なイネーブラーです。効率的な推論は単なるパフォーマンスの最適化ではなく、GPU リソースが限られた環境では、それこそがマルチエージェントのワークフローを実現可能にする要素です。vLLM の最適化された提供機能により、プラットフォームは単一のタスクでコンピューティング・リソースを使い果たすことなく、移行ワークフローに必要な反復的で複数のステップからなる推論ループを処理できます。

テスト、セキュリティレビュー、ドキュメント生成、デプロイメント検証などの隣接タスク用に、追加のエージェント型ハーネスが登場すると、これらはより広範なエージェントメッシュを介して相互接続できるようになり、モダナイゼーションのパイプライン全体で協調的な自動化が可能になります。

移行ワークフロー：まずは Python、次に Java

この取り組みの最初のフェーズでは、Python 2 から Python 3 への移行を対象としています。これは実際の成果物であると同時に、フレームワークの検証でもあります。Python 2 は 2020 年にサポート終了を迎えました。現在も Python 2 で稼働しているシステムは、脆弱性にパッチが適用されず、アップストリームのサポートもない状態で動作しています。政府機関や企業のシステムにとって、これは理論的なリスクではありません。

テストで検証された私たちの仮説は、移行コストは外部への依存関係の複雑さに比例するというものです。非推奨のサードパーティ・パッケージと密接に連携しているアプリケーションを正常に移行するには、より多くのエージェントの反復処理が必要になります。これはモデル設計に反映されています。フローあたりのエージェント型サブタスクを減らし、イテレーションあたりのスコープ設定をより厳密にし、イテレーション間の検証ステップの確定度を引き上げました。

30 日間の目標：テストカバレッジ 80%、GitLab への依存は不要、Python 2 と Python 3 のバージョン間での機能の同等性は検証済み。

図 1：OpenShift AI 上のコーディングエージェント、非コーディングエージェント、ツールによるエージェント型ソフトウェアファクトリーのワークフロー

30/60/90日間のロードマップは、Java 25 への OpenJDK および Corretto バージョン (7、8、11、17、21) を対象とした Java 移行へと移行し、移行パスは対象環境が RHEL 8 か RHEL 9/10 かによって異なります。これは魔法のボタンでも万能のソリューションでもないことを明記しておきたいと思います。エージェント型フレームワークは出発点であり、その中の各エージェントは移行ワークフローの特定のタスク専用に構築されています。これにより、ゼロから作り直すことなく Java に拡張することが可能になります。

本当に重要なことを測定する：ブラウンフィールドの KPI

エージェント型および従来のソフトウェア開発の KPI の多くは、グリーンフィールド開発向けに作成されています。それらの KPI は、ユーザーがアーキテクチャを理解し、ドキュメントにアクセスでき、新しいものを構築していることを前提としています。また、それらは速度を評価の対象としています。

ブラウンフィールドのレガシー移行において、正確性の伴わない速度は成功ではなく、むしろ AI が発展する速度で技術的負債を生成させることになります。

この取り組みについて私たちが定義した KPI フレームワークは、次の 3 つの質問を中心に階層化されています。

正常に動作するか？(機能同等率、統合テスト合格率、変更失敗率など) これらは、実行可否を判断するための指標となります。リファクタリングされたコードが、同一の入力に対して元のコードと同一の出力を生成しないのであれば、他の要素は問題となりません。

仕組みを理解しているか？(開発者の受け入れ率、テストカバレッジの差、移行完了率など) コードが実行されるだけでは移行は完了しません。そのコードを所有する開発者が、内容を読み、信頼し、保守できるようになって初めて完了と言えます。

チームはコードを長期的に所有できるか？(開発者の信頼スコア、最初の貢献までの時間、開発者の能力向上など)。最終的な投資対効果 (ROI) の指標は、タスクあたりのトークンコストではありません。それは、エンジニアリングチームが繰り返しの移行作業からどれだけの時間を取り戻し、より価値の高いミッションへの貢献に集中できるようになったかということになります。

速度の指標 (スループット、イテレーションのレイテンシー、1 分あたりのエージェントのアクション) は、システムのチューニングのエンジニアリング・ダッシュボード向けのものです。これらは、成功の尺度としてプログラム評価で扱うべきものではありません。

Red Hat AI と OpenShift AI が可能にすること

これらは、実際にサポートできるプラットフォームがなければ、役に立ちません。 OpenShift AI は、ここで説明しているすべて機能の基盤となるレイヤーを提供します。

• vLLM によるモデル提供：エージェントのハーネスを駆動するコーディングおよび推論モデルのための、効率的でスケーラブルな推論を提供します。
• モデルカスタマイズのワークフロー：リソース制約のある環境で実行する必要があるモデル向けに、ファインチューニング、LoRA、量子化をサポートします。
• 非接続クラスタのサポート：このプラットフォームは、ここでの基本要件であるインターネットアクセスがない環境で実行されるように設計されています。
• 監査ロギングと可観測性：ミッションのステークホルダーが求めるトレーサビリティと説明可能性が、後付けではなくプラットフォームに組み込まれています。
• モジュール式のコンテナ化されたアーキテクチャ：エージェントはコンテナ化されており、スワップ可能で、システムインテグレーター、航空宇宙企業、連邦政府がすでに習熟している既存の OpenShift インフラストラクチャを通じてデプロイ可能です。

図 2 ：  Red Hat AI でエージェントを構築するためのコンポーネントと機能

ターゲットランタイム環境として RHEL 10 を追加したことは、偶然ではありません。RHEL 10 は、セキュリティの強化、先進的な Python および Java の最新のランタイムサポート、および政府システムが求める運用の信頼性をもたらします。RHEL 10 への移行は、単なるソフトウェアのライフサイクルに関する決定ではなく、セキュリティとミッションの準備状況に関する決定にもなります。

より規模の大きなパターン：ミッションエリア全体でのエージェントメッシュ

この取り組みは、防衛産業基盤、連邦政府、さらには業界全体で今後繰り返し行われると予想される取り組みの一例に過ぎません。レガシーのソフトウェア資産は膨大です。それらを手動で移行するためのエンジニアリングリソースは、問題の対応に要される規模では存在しません。また、サポート対象外のソフトウェアを実行できるセキュリティ上の猶予期間は終わりに近づいています。

OpenShift AI のようなプラットフォーム上のエージェント型 AI は、熟練したエンジニアリングチームが、手作業でモダナイズするには何年もかかるようなコードベースの移行を、ミッションクリティカルな環境で求められる厳密さとトレーサビリティを維持しながら、はるかに短い時間で管理することを可能にする、強力なツールです。

このモデルでは、エージェントのハーネスが特化型エージェントを調整して、個別のモダナイゼーション・タスクを実行します。このようなハーネスが隣接する機能 (テスト、セキュリティレビュー、デプロイメント検証など) に拡大すると、エージェントメッシュが形成されます。これは、大規模なソフトウェア資産全体にわたる複雑なエンジニアリング・ワークフローを調整する、「ハーネスのハーネス」アーキテクチャです。

エージェントは反復的な作業を担います。エンジニアは、アーキテクチャの設計、監視、エージェントの評価、例外処理を行います。このような分業体制こそがモデルなのです。

小規模モデル効率的な推論モジュール式エージェント非接続環境での運用ミッションに合わせたシステムのモダナイゼーション

まとめ

フロンティアモデルは、卓越した推論エンジンです。専用に設計されたエージェント型プラットフォームは、ミッションを遂行するための手段となります。

政府機関にとって、これは単に最新の AI トレンドを導入することではありません。重要なシステムを安全かつ最新の状態に保ち、ミッションを遂行できるようにするためのインフラストラクチャと AI 機能を備えることなのです。

Red Hat は、Red Hat AI を使用してその基盤を構築しています。

詳細はこちら

• Red Hat AI
• Red Hat OpenShift AI