三省六部幻覚：なぜ「バーチャル・カンパニー」スタイルのMulti-Agentアーキテクチャはエンジニアリング上で成立しないのか？

この記事を読むのに必要な時間は 31 分

三大AI企業はこれをやっていないため、あなたのマルチエージェントアーキテクチャは間違っている可能性があります。

原文タイトル：「三省六部幻覚：なぜ「バーチャルカンパニー」スタイルの Multi-Agent アーキテクチャがエンジニアリング上で持続しないのか」
原著者：SagaSu、AI Entrepreneur

AI コミュニティで広く普及しているアーキテクチャの考え方が、多くのチームを迷子にさせています。

まず結論から

複数の AI エージェントをそれぞれ「プロダクトマネージャー」、「アーキテクト」、「テストエンジニア」と名付け、それらが企業部門のようにドキュメントをやり取りし、タスクを共同で遂行することを考えている場合は、停止してください。

このパターンは直感的に見え、論理的には合理的に思えますが、それはエンジニアリング上で根本的な欠陥があります。さらに、Anthropic、OpenAI、Google の 3 社は、独自のエージェントシステムを構築する際に、このパターンを採用していません。

それは偶然ではありません。

「三省六部」スタイルのアーキテクチャとは何か

この比喩は、コミュニティで広く普及している多エージェント設計の考え方を指し、さまざまなフレームワークや記事で異なる名前が付けられています：role-based agents、virtual team、CrewAI 風の役割分担、MetaGPT 風の組織――本文では統一して「三省六部」と呼びます。

中心的なパターンは次のとおりです：複雑なタスクをいくつかの機能に分割し、各エージェントが1つの役割を果たします――PM が要件を担当し、Tech Lead がアーキテクチャを担当し、Dev が実装を担当し、QA がテストを担当します。タスクはエージェント間で流れ、まるで組み立てラインのようです。

このパターンは図式上非常に見栄えが良いです。これは人間の「役割分担協力」に関する直感を満たし、また、「AI チーム」という概念を具体的かつ説明可能にしました。このため、CrewAI などのフレームワークは多くのユーザーを獲得しています。

問題は、これが人間のボトルネックを解決しているが、AI のボトルネックを解決していないという点です。

なぜこの比喩は根本的に間違っているのか

人間が分業を必要とする理由：

・個人の注意は限られており、すべての情報を同時に処理することはできない

・人は専門分野があり、学習切り替えコストが高い

· 人与人之间需要接口来协调

しかし、LLMの特性はまったく異なります：

· 同じモデルがPRDを作成し、コードを記述することができ、「職業の境界線」がありません

· モデルのボトルネックは注意の幅ではなく、「推論の深さ」および「情報の完全性」です

· モデル間には情報損失を補う「文化」や「通じ合い」はありません

Agentに「プロダクトマネージャー」のレッテルを貼っても、それは彼をより専門的にはしませんが、「仕事の範囲外」を拒否することになります。一方、「テストエンジニア」という役割に閉じ込められているAgentは、アーキテクチャの問題に直面してもそのままスキップするかもしれません。「私の職務範囲に含まれていないから」。最も価値のある推論はしばしば境界線上で行われますが、三省六部のモデルはこの可能性をシステム全体で閉じてしまいます。

役割プレイは偽の境界線を作り出します。これが最初の問題です。

第二の問題：情報が伝達中に失われる

三省六部のモデルでは、エージェントAがドキュメントを生成し、エージェントBに渡します。

このプロセスは結論を伝達し、推論プロセスではありません。

Bはドキュメントを受け取り、再理解し、新たなコンテキストを構築します。元の意図が薄れ、含まれることになる仮定が失われ、各受け渡しで誤差が蓄積されます。ワークフローが長くなればなるほど、最終的な出力は「局所的に正しいが全体的にドリフトしている」状態になります——各ノードが合理的に見えますが、全体としては最初の目標から逸脱しています。

人間の組織は、この情報の損失を補うために会議、文化、非公式なコミュニケーションに依存しています。エージェント同士にはこれらのメカニズムがありません。

ここでよくある反論があります：3社のベンダーの解決策（progress.txt、specファイル、runbook）も「ファイルの伝達」ではありませんか？違いは何ですか？

違いは誰が書いているか、誰に向けて書かれているか、どのように更新されているかにあります。

三省六部の情報伝達は役割間の一方向の引き継ぎです：Aが書いてBに引き渡し、Bはもう戻らず、AもBがそのドキュメントをどのように使ったかわかりません。情報は結論に圧縮され、推論プロセスが失われ、受け渡しは途切れたままです。

外部状態ファイルは同一タスクの増分ログです：実行本体は各チェックポイント時に同じ記録に追記し、次のセッションはタスクの完全な履歴を読み取ります。以前の「同僚」の出力結論ではなく、同じ役割が状態を書き込み、読み取る役割ですが、時間が異なります。情報は「圧縮転送」されるのではなく、「連続的に蓄積」されます。

この違いにより、推論チェーンがセッションを超えて連続的に維持されるかが決まります。

多くのトークンがエージェント間の「引き継ぎファイル」に浪費され、実際の推論には使用されません。手に入るのは企業行動をシミュレートするシステムであり、問題を解決するシステムではありません。

三社の実際のアプローチ

注目すべきは、Anthropic、OpenAI、Google が自社の本番用エージェントシステムを実際に構築する際に、「役割演じ」や「部門間の役割分担」の言葉がほとんど見当たらないことです。

Anthropic：Context Engineering + 明示的な状態ファイル

Anthropic は「プロンプトエンジニアリング」を「コンテキストエンジニアリング」に昇格させました：問題はプロンプトをうまく書くことではなく、どのトークン構成が最も望ましい振る舞いを生み出すかです。

Claude Code と Research システムを構築する際、彼らが直面した主要な課題は、エージェントが不連続なセッションで動作しなければならないことであり、新しいセッションごとに以前の出来事を一切覚えていない必要があります。彼らの比喩は「交代勤務エンジニア」であり、新しいシフトのエンジニアは前のシフトの仕事を全く知りません。

解決策は、エージェントに異なる役割を演じさせるのではなく：

・claude-progress.txt：セッションを超える作業ログ。エージェントは各セッション終了時に更新し、次のセッション開始時に読み取ります

・Git ヒストリー：状態のアンカーとして、すべての増分変更を記録します

· イニシャライザーエージェント：最初のセッションのみ実行され、環境を構築し、機能リストを展開し、ランブックを作成し、その後のすべてのセッションで使用できるようにします

Key Insight: 推論チェーンの連続性は、モデルに「記憶」を頼らず、明示的な外部状態によって支えられています。

彼らはまた、『モデル能力の仮定』をハーネスにハードコードすることは危険であることを発見しました。Sonnet 4.5 には「コンテキスト不安」があり、コンテキストの限界に近づくと早めに終了するため、ハーネスにはコンテキストリセットが追加されました。

しかし、Opus 4.5 ではこの挙動が消え、リセットが固定の重みとなりました。これは、ハーネスがモデルの進化に合わせて変化し、どんな「永続的な解決策」も現時点のエンジニアリング上の妥協にすぎないことを示しています。

複数のエージェントを持つ研究システムでは、Anthropic のアーキテクチャはオーケストレーター-ワーカーです：リードエージェントがタスクを分解し、サブエージェントを調整し、サブエージェントが異なる方向に並行して探索し、その結果をリードエージェントにフィードバックして総合します。

彼らは、トークンの消費量自体がパフォーマンスの 80% の違いを説明していることに気づきました — 複数のエージェントの価値は「分業」ではなく、より多くのトークンでより大きな検索空間をカバーすることです。

ここで混乱しやすい点があります：Anthropic のサブエージェントは「分業」のように見えますが、本質はまったく異なります。三省六部は機能的な分業です — 異なる役割が異なる仕事を担当し、PM が完了したら Dev に渡し、Dev が完了したら QA に渡すような流れです。各役割はパイプラインの一部だけを担当します。

Anthropic のサブエージェントは機能的に並行しています — 複数の同様の性質を持つエージェントが異なる方向に同時に探索し、次の「バトン」はなく、すべての結果が同じオーケストレーターに戻されて総合されます。前者はリレー競走であり、後者は同時に網を投げて魚を捕まえるようなものです。

OpenAI：コンパクション + スキル + 構造化スペックファイル

OpenAI が提唱する長期タスクの原則はより直接的であり、タスク開始時には連続性の計画をすでに立てている。

彼らのCodex実験では、エンジニアはエージェントにスペックファイルを提供し（目標を固定し、エージェントが「非常に印象的だが方向性の間違ったものを生成するのを防ぐ」）、それに基づいたマイルストーンベースの計画を生成させ、その後、エージェントに操作方法を伝えるランブックファイルを使用した。このランブックは同時に共有メモリと監査ログでもある。

結果：GPT-5.3-Codexは約25時間連続して実行され、完全な設計ツールを完成し、その全過程で一貫性を維持した。

サーバーサイドのコンパクションはデフォルトのプリミティブとして機能し、緊急時のフォールバックではない。複数段階のタスクでは、previous_response_idにより、モデルは同じスレッドで作業を継続し、コンテキストを毎回再構築する必要がありません。

彼らはまた、スキルの概念を導入しました - 再利用可能でバージョン管理された命令セットは、コンテナにマウントされ、エージェントが特定のタスクを実行する際に安定した操作規範を持つようにします。これは「役割」ではなく、ツールと操作手順であり、本質的に異なるものです。

Google：1Mコンテキスト+コンテキスト駆動型開発

Googleの方向性は大規模ウィンドウを使用することです：Geminiの1Mトークンコンテキストは明確な差別化戦略です。彼らの論理は、かつて強制されていたRAGスライス、古いメッセージの破棄などの技術は、十分な大きさのウィンドウの中で「直接挿入」されることができるということです。

しかし、それだけでは足りませんとGoogle自身が認めています。GoogleはGemini CLIでConductor拡張機能を導入し、その核心的な考え方はAnthropicと全く同じです：プロジェクト意図をチャットウィンドウから取り出し、コードベースの永続的なMarkdownファイルに配置すること。その哲学は、「不安定なチャット記録に依存せず、公式のスペックと計画ファイルに依存する」ことです。

Gemini 3 では、Thought Signatures メカニズムも導入されました：長いセッションで推論チェーンの重要なノードを保存し、「reasoning drift（推論の漂流）」を防ぎます――つまり、長い文脈で論理が不整合になる問題。

真のアーキテクチャ原則は何か

3つのエンジニアリングプラクティスから、いくつかの共通の原則を抽出できます：

推論チェーンは断ち切ることはできず、分岐して再統合するだけです。 複数のエージェントの適切な使用法は、パイプラインではなく、メインエージェントが完全な意図を持ち、サブコールは特定のサブ問題を探求するためのものであり、結果はメインエージェントに戻り、次のエージェントに渡すものではありません。

明示的な外部状態を使用し、モデルに記憶を頼らないでください。 progress.txt、Git の履歴、仕様ファイル、データベース――形式は重要ではありませんが、原則は、推論チェーンの重要なノードを永続ストレージに外部化する必要があり、モデルがコンテキストウィンドウ内で「覚えている」ことに依存してはいけません。

複数のエージェントの価値は並行カバレッジにあり、分業ではありません。 Anthropic Research システムの結論は非常に明確です：性能向上は主に「より多くのトークンを使うこと」によるものであり、「分業をより合理的にすること」によるものではありません。複数のエージェントは、幅優先型のタスクに適しています――多くの独立した方向を同時に探索する必要があるシナリオに適しています。連続した推論や文脈への深い依存が必要なシナリオには適していません。

検証エージェントは否定者であり、引き継ぎ者ではありません。 クオリティコントロールに複数のエージェントを使用する場合、正しい設計は1つのエージェントが別のエージェントの問題を専門的に処理させることであり、「作業成果を伝達する」ことではありません。対抗的な検証は、パイプラインでの伝達ではありません。

ツールはツールであり、役割ではありません。 エージェントにどのようなツール（bash、ファイル読み書き、検索、コード実行）を提供するかは、どのようなラベルを貼るかよりもはるかに重要です。ツールはエージェントが行うことを決定します。役割のラベルは、エージェントが何をしたいと考えているかに制約を与えるだけです。

なぜ三省六部は人気になったのか？

それは説明しやすいからです。

「このエージェントはPMで、あちらはQAです」という言葉は誰もが理解できます。これは人類のAIシステムの説明可能性への渇望を満たし、また経営陣の「AIがチームのように機能する」想像にも応えています。

それはさらによく展示される。フローチャートで描かれ、部署があり、矢印があり、引き継ぎがあり、非常に直感的です。

しかし、良い説明と良い展示は、エンジニアリングの面で成立しているかどうかとは別の問題です。

もっと深層にある原因は：このパターンを採用しているほとんどのチームは、実際には「複数のエージェント間でのコンテキストの伝達時の情報損失」に直面したことがありません。彼らのタスクはおそらくそれほど複雑でないか、問題が他の要因で覆い隠されていました。タスクの複雑さが増すと、システムが奇妙な「局所的には正しくても全体的には誤っている」状況を示すようになり、問題が露呈されます。

実践上の提案

最高の複数エージェントシステムは、企業のようにはなりません。それはむしろ同じ脳内で推論を展開し、最終的に一貫した結論に収束する、思考者の複数の草稿のようなものです。

この原則から：

「何人のエージェントが必要か」ではなく、「このタスクの情報依存構造は何ですか」と尋ねてください。

タスクが連続的な推論を必要とし、高度にコンテキストに依存している場合（たとえば、複雑な機能の設計ドキュメントを作成する場合）、単一のエージェントと適切なコンテキストエンジニアリングが多くの場合よりも優れています。

タスクが複数の独立した方向を同時に探索する必要がある場合（たとえば、10の競合他社の異なるモジュールを同時に研究する場合）、多数のエージェントが並行して作業するのは合理的です。各サブエージェントのタスクは互いに独立しており、情報の損失コストが最小限に抑えられます。これがAnthropic Researchシステムのトークン量が説明する80％の性能差の背後にある理由です。分業がそれをより良くするのではなく、より大きな検索範囲がそれをより良くするのです。

タスクが複数のセッションにわたる場合、外部状態ファイルが必要です。有効な状態ファイルには次の4つの情報が含まれている必要があります：

・タスクの目標（不変で、セッション開始時に読み取られ、ドリフトを防ぎます）

・完了したステップ（追記、上書きせず、完全な履歴を保持）

・現在の状態（カバーして、最新の進展を反映）

・既知の罠（追加して、次のセッションでの重複を回避）

これらの4つの情報はそれぞれ別々に管理され、すべて一緒になると「次の自分」が必要とする完全な文脈になります。

検証段階を追加する場合、検証エージェントの唯一のタスクは問題を見つけることであり、「バトンを受け継いで続ける」ことではありません。対立的な検証は、流れ作業の伝達ではありません。

最後に：モデルの能力が急速に向上しています。今日ハーネスに必要なワークアラウンドは、6か月後には不要になるかもしれません。Anthropicはすでにこれを確認しました―Sonnet 4.5のコンテキストの不安定さはOpus 4.5では消え、それに設計されたコンテキストのリセットは無用のコードとなりました。アーキテクチャの進化可能性を保ち、完璧なアーキテクチャを選ぶよりも重要です。

三省六部は、気分が良いが工学的コストが高い錯覚です。その真のコストは直接の失敗ではなく、システムが複雑さが増す中で、診断が困難な方法で劣化することです―各ノードは全て「動作しているように見えます」が、全体としては漂流しています。

問題に気付いた時には、既に流れ作業は長くなっています。

参考文献：

Anthropic Engineering Blog（Building Effective Agents、Effective Context Engineering、Multi-Agent Research System、Effective Harnesses for Long-Running Agents、Managed Agents）；OpenAI Developers Blog（Run Long Horizon Tasks with Codex、Shell + Skills + Compaction）；Google Developers Blog（Architecting Efficient Context-Aware Multi-Agent Framework、Conductor: Context-Driven Development for Gemini CLI）