Google の AI およびインフラストラクチャ チームが、業界の大半が見逃したブログ記事で、静かに注目すべき成果を発表しました。それは、TensorFlow から JAX へのプロダクション機械学習モデルの移行において、数千行のコード、数百のレイヤー、複数ファイルにまたがる深い依存関係を伴う規模で、6 倍の高速化を実現したというものです。Sundar Pichai 氏は Google Cloud Next のステージでこれに言及しました。その数字が見出しになりました。その根底にあるアーキテクチャこそが実際のストーリーであり、それは今現在行われている、エージェントの群れが 8 エージェントであろうと 800 エージェントであろうと、あらゆる信頼できる大規模エージェント移行の背後にあるのと同じアーキテクチャです。
ここで最も重要な詳細は次のとおりです。彼らはまず、単一の AI エージェントをコードベースに向けて試しました。それは失敗しました。部分的にではなく、コンテキストを見失い、存在しない API を幻覚し、コンパイルできないコードを生成しました。修正方法は、よりスマートなモデルではありませんでした。それはまったく異なるアーキテクチャであり、現在では「ダークファクトリー」パターンという名前が付けられています。これは、エージェントが計画、実装、テスト、そしてコードを出荷する際に、人間のレビューを一切介さないコードベースであり、完全に自動化された工場が暗闇の中で機械を動かすのと同じです。なぜなら、誰も照明をつけるために残っていないからです。
この記事は、そのパターンの完全な解説です。マーケティング版ではありません。何百ものエージェントが、人間が個々の変更をチェックすることなく、実際のコードベースを移行する実際のメカニズムと、それを安全にするものがモデルへの信頼ではなく、そもそもその信頼を必要としないように特別に設計されたアーキテクチャである理由についてです。
単一のエージェントが大規模に失敗する理由
アーキテクチャの前に、なぜ単純なアプローチが破綻するのかを正確に理解してください。なぜなら、機能するパターンにおけるすべての設計上の決定は、これらの失敗のいずれかを修正するために特別に存在するからです。
大規模なコードベースに向けられた単一のエージェントは、まずコンテキストの問題に直面します。寛大なコンテキストウィンドウがあっても、何百もの相互依存ファイル、深い呼び出しチェーン、モジュール間の継承された前提条件を持つコードベースは、単一のセッションが首尾一貫して保持できる範囲を超えます。エージェントは最初のいくつかのファイルでは好調ですが、作業コンテキストが蓄積された、半分関連性のある履歴で満たされるにつれて、パフォーマンスが低下します。
次に、シーケンスの問題に直面します。コード移行は、デフォルトでは並列タスクではありません。ファイル B は、多くの場合、ファイル A が既に移行されていることに依存します。なぜなら、関数シグネチャが変更され、インポートが移動され、データ構造の形状が変わったからです。明示的な依存関係マップを持たないエージェントは、順序を推測するか（これにより壊れた中間状態が生成されます）、またはファイルがたまたまリストされた順序で処理しますが、これは機能的に推測と同じです。
次に、検証の問題に直面します。これが実際に最も重要な問題です。コードを移行し、その後自分の移行を評価するエージェントは、そもそも間違いを生み出したのとまったく同じ盲点を持って自分の宿題をチェックしています。エージェントが特定の API が新しいバージョンで異なる動作をすることを理解していない場合、自分の出力をレビューするときにその誤解をキャッチできません。なぜなら、同じ理解のギャップが両方のパスに存在するからです。
Google のチームはこれを直接発見しました。単一エージェントのセットアップでは、移行の構造ルールと、行ごとの実行の詳細を同時にバランスさせることができませんでした。これら 2 つの懸念事項を別々の役割に分割することが実際の修正であり、OpenAI が公開した移行クックブック、マルチエージェント移行ループに関する学術研究、そしてこれを大規模に実際に実行しているすべてのプロダクションシステムで、独立して現れるのと同じ修正です。
アーキテクチャ: 1 つのジェネラリストではなく、3 つの役割
機能するパターンは、ジョブを実際に異なる役割に分割します。単に同じジェネラリストエージェントに向けられた異なるプロンプトではありません。
プランナーは、LLM の推測ではなく、決定論的なツールを使用して作業を順序付けます。 これが、実際にスケーリングするシステムと、デモでは印象的に見えてもプロダクションで崩壊するシステムを区別する詳細です。Google のプランナーは、LLM に推論を通じて移行順序を考え出すように要求しません。コンパイラベースの静的解析（数十年にわたってエンタープライズソフトウェアを支えてきたのと同じカテゴリの決定論的ツール）を使用して、実際の依存関係ツリーを構築し、リーフノード（他に何も依存しないファイル）から始まり、他のすべてが依存するファイルに向かって上に向かって作業する実行計画を定義します。
これは、依存関係の順序付けが創造的な問題ではないため重要です。これは、正解がある機械的な問題であり、既に決定論的な解決策がある問題を解決するために LLM を使用することは、存在する必要のない新しいエラーの原因を導入するだけです。これの根底にあるルールは次のとおりです。問題にアルゴリズムによる答えがある場合は、アルゴリズムを使用します。本当に判断を必要とするタスクの部分、つまり実際のコード変換のために言語モデルを予約します。どのファイルが最初に行くかの順序付けではありません。
移行エージェント（または、大規模なシステムでは、同じ役割の何百ものエージェントが並行して、分離された、スコープの狭いインスタンスで実行されます）は、実際のコード変換を行います。 各インスタンスは、1 つのスコープ化されたタスク、理想的には 1 つのファイルまたは 1 つの厳密にバインドされたモジュール、1 つのチェックアウト、および何をなぜ変更する必要があるかを正確に説明する明示的な移行概要を取得します。関連するコードを検査し、編集を行い、パッチを生成します。自分のパッチが正しいかどうかを判断しません。それはその仕事ではなく、アーキテクチャは誤ってその仕事を引き受けることができないように特別に設計されています。
環境および検証レイヤーは、何かが受け入れられる前に、分離された環境で移行されたコードをビルド、実行、およびテストします。 ここで、「完了したことは完了した」ということが、意見ではなく機械的な事実になります。Google のこのフレーミングは正確です。業界は歴史的に、AI の作業が実際にいつ完了したかを決定するための 2 つの悪いオプションを提供してきました。何百ものファイルにスケーリングしない人間のレビュー、または実際に何がチェックされたかの記録がないため監査できない AI の自己評価です。彼らの答えは数学的検証です。コンパイルの成功、テストの合格、および動作が定義された仕様と一致することを確認する決定論的なコードであり、両方の悪いオプションを、実際に検査可能な 3 番目のオプションに置き換えます。
このリストに何が欠けているかに注目してください。マージする前に個々の差分をすべて読む人間です。それがダークファクトリーパターンの要点全体であり、また、ほとんどの人の安全性に関する直感が間違っているまさにその点でもあります。なぜなら、それはシステムがエージェントをより信頼しているように聞こえるからです。その逆です。構造的にエージェントを信頼していないのです。「エージェントがこれが機能すると言った」という単一の判断ポイントを、エージェントが影響を与えたり、回避したりできない検証レイヤーに置き換えることによって。
分離レイヤー: 各エージェントが独自のサンドボックスを取得する理由
何百ものエージェントを同じコードベースに対して同時に実行すると、明らかなリスクが生じます。エージェント 47 がエージェント 12 の変更が依存するファイルを編集中で、エージェント 12 の編集がコンパイルを壊した場合はどうなるでしょうか。
OpenAI の公開された移行アーキテクチャと Google のプロダクションシステムの両方で一貫している答えは、デフォルトでの分離です。各移行タスクは、独自のサンドボックス環境、多くの場合独自の git worktree（その 1 つのタスクにスコープされた、関連するリポジトリの完全で独立したチェックアウト）で実行されます。そのサンドボックス内のエージェントが何かを壊した場合、共有コードベースではなく、分離されたコピーを壊し、ましてや別のエージェントの進行中の作業を壊すことはありません。
この分離は、衝突を防ぐだけではありません。共有可能な mutable state が何百もの同時エージェントによって踏まれることがないため、システム全体を簡単に並列化可能にします。エージェント 1 からエージェント 800 まで、それぞれが特定のタスクに関連するファイルとコンテキストのみを含むクリーンな環境で、あるエージェントの幻覚が別のエージェントの正しい作業を汚染するリスクゼロで、真に同時に実行できます。
ハーネス、つまりどのタスクをどのサンドボックスに送り、結果のパッチをどうするかを決定するオーケストレーションレイヤーは、個々のサンドボックスの外側に留まります。これは、特定かつ重要なアーキテクチャ上の選択です。シークレット、外部ツール、実際のリポジトリへのアクセス権を持つ信頼されたプロセスは、AI が生成したコードが実際に実行される信頼されていない実行環境とは別に存在します。サンドボックスは、その 1 つのタスクに必要なものだけを正確に取得し、それ以上は取得しません。ホストプロセスは、生成されたコードを自身の昇格された権限で直接実行することはありません。この分離こそが、エージェントのコードを実行することを安全にしているのです。なぜなら、サンドボックス内の間違いや、敵対的なプロンプトインジェクションでさえ、外部への経路がないからです。
ループ自体: 計画、実行、検証、改良
規模と特定のツールを取り除けば、このすべての根底で実行されている実際のループには 4 つの段階があり、タスクが合格するか、再試行回数の上限に達するまで、タスクごとに繰り返されます。
ステージ 1: 移行計画。 移行エージェントは、スコープ化されたタスク（1 つのファイルまたはモジュール、特定のターゲット仕様（言語バージョン、フレームワークの変更、API 互換性要件））を受け取り、候補となる変換を生成します。これは、創造的で判断ベースの言語モデル推論が主要な作業を行っている唯一のステージです。なぜなら、特定のパターンを新しいフレームワークの同等のものに正しく変換する方法を決定するには、機械的なルックアップだけでなく、真の理解が必要だからです。
ステージ 2: 自動化された環境セットアップ。 このパターンに関する学術文献では環境エージェントと呼ばれることもある別のコンポーネントが、移行されたコードのビルドおよびランタイム環境を自律的に構築し、依存関係の解決と構成を処理して、候補パッチを抽象的に評価するのではなく、現実的な条件下で実際にコンパイルおよび実行できるようにします。
ステージ 3: テスト検証。 移行されたコードは、実際のテストスイート、またはその特定のモジュールにテストスイートが存在しない場合は生成された同等のものに対して実行されます。これは機械的な検証ステップであり、印象ではなく、客観的な合格または不合格を生成します。テストに合格するかしないかのどちらかであり、エージェントが回避できる曖昧さはありません。
ステージ 4: フィードバックによる改良。 失敗した場合、特定のテストの失敗と診断ログは、「これは機能しなかった、もう一度試して」という漠然としたものではなく、対象を絞った修正入力として移行エージェントにルーティングされます。パッチを所有するエージェントは、何が壊れたかについての具体的な証拠に基づいて、特定のロジックと依存関係マッピングを改良します。これは、ゼロからの一般的な再試行ではありません。
この 4 段階のサイクルは、定義された上限付きでタスクごとに繰り返されます。この正確なループパターンの文書化された動作バージョンは、「古いパターンに一致するファイルがなくなった」などの停止条件と、ハードな最大反復回数（公開された例の 1 つでは 200 回）を指定しており、その後、収束していないタスクで無期限に実行されるのではなく、システムが自動的に停止します。
この上限は、大規模では非常に重要です。これがないと、仕様自体があいまいであるか、ターゲットパターンにクリーンな同等物が本当にないために構造的に完了不可能なタスクが、人間が実際に確認して解決できる特定の境界のある失敗として表面化する代わりに、リソースを永久に消費することになります。
人間のレビューがスケーリングしない理由と、その代わりになるもの
「人間がそれぞれをレビューしない」ことが、ここでは手抜きではなく、実際にはより安全な設計である理由を正確に述べる価値があります。
AI エージェントのコードレビューと人間のコードレビューを比較した研究では、具体的で有用な何かが見つかりました。AI が生成したレビューコメントは、コード行あたりの長さが人間のレビューのほぼ 7 倍であり、ほぼ完全にコードの改善と欠陥の検出に集中しています。一方、人間のレビューは、共通理解の構築、知識の伝達、チームメイト間の社会的コミュニケーションなど、まったく別のことに自然に広がります。人間のレビューのやり取りは、フィードバックの種類によって大きく異なります。AI 間のレビューの相互作用は、何がフラグされているかに関係なく、はるかに均一で機械的です。
これを正しく読めば、重要なことがわかります。人間のレビューと AI の検証は、構造的に異なることに優れているということです。エージェントの群れが生成する速度と量で、人間に 800 の個別の差分をレビューするように依頼することは、安全性の向上ではなく、ゴム印の承認を生み出すボトルネックです。なぜなら、その量を超えて人間が真の精査を維持することはできないからです。ダークファクトリーパターンにおける実際の安全性は、検証を削除することから来ているのではありません。それは、ある種の検証（何百もの反復的な差分にわたる、遅く、疲れ果て、一貫性のない人間の注意）を、スケーリングする別の種類の検証（差分 1 と差分 800 でまったく同じ厳密さを、注意疲労ゼロで生成する決定論的なビルドおよびテスト検証）に置き換えることから来ています。
これはまた、プランナーステージが順序付けに LLM の判断ではなくコンパイラベースの静的解析を使用する理由でもあります。システム内のどこでも、決定論的なチェックが判断の呼び出しを置き換えることができる場合は、そうすべきです。なぜなら、決定論的なチェックは、このアーキテクチャの中で事後に真に監査可能な唯一の部分だからです。静的アナライザーが見つけたものを正確に再生できます。言語モデルが特定の移行順序が「正しい」と「感じた」理由を完全に再生することはできません。
それでも人間が必要なもの、そして線が実際にある場所
このパターンは、「人間を完全に排除して願う」というものではありません。Google のプロダクションシステム、学術的な Environment-in-the-Loop 研究、OpenAI 自身のクックブックなど、このパターンの信頼できる公開バージョンはすべて、人間の判断が必須のままである場所に明示的な線を引いています。
エージェント駆動型ライブラリ移行の定量研究にわたる一貫した発見：エージェントは高い移行カバレッジを確実に達成し、どの API 変更が必要かを正しく識別しますが、より複雑なケースでは、アプリケーション全体の動作を維持することに特に苦労します。そこでは、成功した移行には、構文のパターンマッチングだけでなく、意図の理解が必要です。その発見から直接導き出される推奨事項は、バッチ全体ではなく、決定論的検証が高リスクまたは低信頼性としてフラグを立てたファイルのサブセットに対して、人間がループ内でチェックポイントを設けることです。
実際には、これにより階層化されたシステムが生成されます。静的依存関係分析が小さく、十分に分離され、構造的に単純であると分類するファイル（実際の移行の大部分）は、決定論的なビルドおよびテストゲート以外に人間のタッチを一切必要とせずに、完全に自動化されたループを通過します。複雑で、深く相互接続され、またはビジネスクリティカルなロジックに触れるとフラグが立てられたファイルは、そうでなければ完全に自動化されたシステム内であっても、マージ前に実際の人間のレビューのためにキューにルーティングされます。
この階層化されたアプローチは、「800 のエージェント、それぞれをレビューする人間はゼロ」という現実的なバージョンです。人間が何も見ないということではありません。システムは、機械的でリスクの低い作業の 95% を完全な自動化を通じてルーティングし、一方で希少なリソースである真の人間の判断を、決定論的検証が再現できない価値を実際に付加するケースのごく一部にのみ集中させるように、特別に設計されているのです。
独自のコードベースのためにこれを構築する
このパターンは、スケールアップと同じくらいきれいにスケールダウンします。800 の並列エージェントを大規模なプロダクションコードベースに対して実行する場合でも、一握りのシーケンシャルな移行タスクを単一のリポジトリに対して実行する場合でも、同じ 4 つの役割が適用されます。
プランナーから始めて、それを LLM にしたくなる衝動を抑えてください。移行に何らかの依存関係構造（ファイルのインポート、共有インターフェース、ビルド順序）がある場合は、実際の静的解析ツールを言語に適したもの使用して、その依存関係グラフを機械的に構築してください。この単一の決定は、システム全体で最もレバレッジの効くものです。なぜなら、後続のすべてのステージは、プランナーが行う順序付けの間違いを継承するからです。
個々のタスクを、依存関係グラフが許す限り狭くスコープしてください。1 つのファイル、1 つのモジュール、1 つの明確に境界が定められた変更単位で、何をなぜ行う必要があるかを正確に説明する明示的な概要を添えてください。効率性だけを理由に、複数の無関係な変更を 1 つのタスクに組み合わせるのは避けてください。なぜなら、スコープが狭いほど、検証ステージの合格または不合格の判断が明確になるからです。
すべてのタスクの実行を分離してください。最低でもタスクごとに新しい git worktree、実際の規模で実行する場合は完全なサンドボックス環境。これはオプションのインフラストラクチャオーバーヘッドではありません。これは、並列化を安全にし、単一のエージェントの間違いを封じ込め、伝染させないようにするものです。
他の何よりも先に、決定論的な検証を構築してください。コンパイルの成功、テストスイートの合格率、可能な場合は動作の等価性チェック。これは、「エージェントが機能すると言った」を「実際に機能したか」に置き換えるコンポーネントであり、ほとんどの自作の移行試行が完全にスキップする単一のコンポーネントであり、まさにそれが、それらの試行が意味のある規模で失敗する理由です。
再試行ループを明示的に制限してください。感覚ではなく、数字で。「このタスクがスタックしている」ように見える状態を、何かを実行する前に定義し、スタックしたタスクを無期限にリソースを消費させたり、さらに悪いことに、偽の成功を静かに報告させたりするのではなく、自動的に人間のキューにルーティングしてください。
見出しの数字の根底にある実際の教訓
特定の大規模移行で実行されている実際の数値が何であれ、800 エージェントでも 80 でも 8,000 でも、見出しの数字はストーリーの中で最も面白くない部分です。興味深い部分は、それらのエージェントのどれも、自分の作業が正しいかどうかを個別に判断することを信頼されておらず、システム全体がその不信を中心に、それにもかかわらずではなく、設計されていることです。
ダークファクトリーが暗闇で稼働するのは、誰も見ていないからではありません。監視が完全に機械自体、つまりコンパイラチェック、テストスイート、依存関係グラフに移され、ファイル 1 とファイル 800 で、毎回同じ厳密な答えを、疲労なく、そして人間に同じ反復的な判断を何千回も連続して求めることから生じる不整合なしに生成するからです。
それが、現在プロダクションで機能しているこのすべてのバージョンの背後にある実際のパターンです。より大きなモデルへのより勇敢な信頼ではありません。単一のコンポーネント（人間であれ AI であれ）が、自分の作業の唯一の判断者となることを、より規律正しく拒否することです。
より多くの AI コンテンツについては、@cyrilxbt をフォローしてください
