**
AI コミュニティで広く流布しているアーキテクチャの考え方が、多くのチームを誤った方向に導いている。
結論から先に
もしあなたが複数の AI エージェントに「プロダクトマネージャー」「アーキテクト」「テストエンジニア」といった役割を割り当て、会社の部門のようにドキュメントを渡しながら協業させることを検討しているなら——今すぐやめてください。
このモデルは直感的で論理的にも正しく見えますが、エンジニアリング上に根本的な欠陥があります。さらに重要なのは、Anthropic、OpenAI、Google の三大プロバイダーはいずれも、自社のエージェントシステムを構築する際にこのモデルを採用していないという事実です。
これは偶然ではありません。
「三省六部」アーキテクチャとは何か？
この比喩は、コミュニティで広く普及しているマルチエージェント設計思想の一群を指します。さまざまなフレームワークや記事で、役割ベースのエージェント、仮想チーム、CrewAI スタイルの分業、MetaGPT スタイルの組織など、異なる名前で呼ばれています。本記事ではこれらを総称して「部門化」モデルと呼びます。
その核となるパターンは、複雑なタスクをいくつかの機能に分解し、各エージェントに役割を与えることです。PM が要件を、テックリードがアーキテクチャを、Dev が実装を、QA がテストを担当します。タスクはエージェント間を流れ作業のように流れていきます。
このモデルは図にすると非常に見栄えがします。「分業」という人間の直感を満たし、「AI チーム」という概念を具体的で説明可能なものにします。CrewAI のようなフレームワークが多くのユーザーを獲得したのもこのためです。
問題は、これが人間のボトルネックを解決するものであって、AI のボトルネックを解決するものではないということです。
なぜこのアナロジーが根本的に間違っているのか
人間に分業が必要な理由は以下の通りです：
- 一人の人間の注意力には限界があり、すべての情報を同時に処理できない。
- 人間には専門的な壁があり、学習や切り替えのコストが高い。
- 人間は互いに調整するためのインターフェースを必要とする。
しかし、LLM の特性はまったく異なります：
- 同じモデルが PRD もコードも書ける。「専門的な境界」は存在しない。
- モデルのボトルネックは注意力の範囲ではなく、推論の深さと情報の完全性である。
- モデルには、情報の損失を補う「文化」や「暗黙の了解」がない。
エージェントに「プロダクトマネージャー」というラベルを貼っても、それがより専門的になるわけではありません——むしろ、境界を越えることを拒否するようになります。「テストエンジニア」という枠に閉じ込められたエージェントは、「自分の担当範囲ではない」という理由でアーキテクチャ上の問題を見逃すかもしれません。最も価値のある推論はしばしば境界部分で発生するものですが、部門化モデルはシステムレベルでこの可能性を封じてしまいます。
ロールプレイは偽の境界を作り出します。これが第一の問題です。
第二の問題：情報は伝達の過程で死ぬ
部門化モデルでは、エージェント A がドキュメントを作成し、それをエージェント B に渡します。
このプロセスで渡されるのは結論であり、推論のプロセスではありません。
B はドキュメントを受け取り、それを再解釈し、コンテキストを再構築します。本来の意図は劣化し、暗黙の前提は失われ、ハンドオフのたびに誤差が蓄積されます。ワークフローが長くなればなるほど、最終的な出力は「局所的には正しいが、全体的にはズレている」ものになります——各ノードは妥当に見えるが、全体としては元の目標から逸脱しているのです。
人間の組織は、会議、文化、インフォーマルなコミュニケーションによってこの情報損失を補っています。エージェントにはそのようなメカニズムがありません。
よくある反論があります：三大プロバイダーのソリューション（progress.txt、spec ファイル、runbook）も「ファイルを渡す」ことではないのか？ 違いは何なのか？
違いは、誰が書き、誰のために書き、どのように更新されるかにあります。
部門化された情報フローは、役割間の一方通行のハンドオフです。A が終えて B に渡す。B は振り返らず、A は B がドキュメントをどのように使ったかを知りません。情報は結論に圧縮され、推論プロセスは失われ、ハンドオフは断絶点となります。
外部状態ファイルは、同じタスクのインクリメンタルなログです。実行主体は各チェックポイントで同じレコードに追記し、次のセッションは前の「同僚」の出力結論ではなく、タスクの全履歴を読み取ります。状態を書く人と読む人は同じ役割であり、時間が異なるだけです。情報は「圧縮されて渡される」のではなく、「継続的に蓄積される」のです。
この違いが、推論チェーンがセッションをまたいで連続性を維持できるかどうかを決定します。
エージェント間の「ハンドオフファイル」に膨大なトークンが浪費され、実際の推論には使われません。あなたが得るのは、会社の振る舞いをシミュレートするシステムであって、問題を解決するシステムではありません。
三大プロバイダーが実際に行っている方法
注目すべきは、Anthropic、OpenAI、Google が本番グレードのエージェントシステムを構築する際、そのエンジニアリングドキュメントのほとんどで「ロールプレイ」や「部門分割」について言及していないことです。
Anthropic：コンテキストエンジニアリング + 明示的な状態ファイル
Anthropic は「プロンプトエンジニアリング」を「コンテキストエンジニアリング」にアップグレードしました。問題は「良いプロンプトを書く方法」ではなく、「望ましい振る舞いを生み出すトークン構成は何か」です。
Claude Code や Research システムを構築する際、彼らの核心的な課題は次の通りでした：エージェントは個別のセッションで動作しなければならず、新しいセッションは以前に何が起こったかを記憶していません。彼らの比喩は「シフトエンジニア」です——新しいシフトのエンジニアは前のシフトの作業について何も知りません。
解決策はエージェントに異なる役割を演じさせることではなく、以下の方法でした：
- claude-progress.txt：セッション間の作業ログ。エージェントは各セッションの終了時に更新し、次のセッションの開始時に読み込みます。
- Git 履歴：状態のアンカーとして機能し、すべてのインクリメンタルな変更を記録します。
- Initializer Agent：最初のセッションでのみ実行され、環境をセットアップし、機能リストを展開し、以降のすべてのセッション用の runbook を作成します。
重要な洞察：推論チェーンの連続性は、モデルが「記憶する」ことに依存するのではなく、明示的な外部状態にアンカーされることに依存するということです。
また、ハーネスに「モデルの能力に関する仮定」をハードコードすることは危険であることも発見しました。Sonnet 4.5 には「コンテキスト不安」がありました——コンテキスト制限に近づくと早期にまとめようとするため、ハーネスにコンテキストリセットを追加しました。しかし Opus 4.5 ではこの振る舞いが消え、リセットは無駄なものになりました。これは、ハーネスはモデルとともに進化する必要があることを示しています。どんな「恒久的な解決策」も、現段階におけるエンジニアリング上の妥協に過ぎません。
マルチエージェント Research システムにおいて、Anthropic のアーキテクチャはオーケストレーター・ワーカーです。リードエージェントがタスクを分解し、サブエージェントを調整します。サブエージェントは異なる方向性を並行して探索し、結果はリードエージェントに戻って統合されます。彼らは、トークン消費量だけでパフォーマンスの違いの 80% を説明できることを発見しました。マルチエージェントの価値は「分業」ではなく、より多くのトークンを使ってより広い探索空間をカバーすることにあります。
ここで混乱点があります：Anthropic のサブエージェントは「分業」に見えるかもしれませんが、本質は異なります。部門化は機能的な分割です——異なる役割が異なる種類の作業を処理します（PM から Dev へ、QA へ）。Anthropic のサブエージェントは機能的な並列処理です——複数の同一エージェントが異なる方向を同時に探索し、「次の手」はなく、すべての結果は同じオーケストレーターに戻ります。前者はリレー競争であり、後者は広く網を張ることです。
OpenAI：Compaction + Skills + 構造化 Spec ファイル
長期タスクに対する OpenAI の原則はさらに直接的です：タスクの開始時に継続性を計画することです。
Codex の実験では、エンジニアはエージェントに spec ファイルを与え（目標を固定し、エージェントが「印象的だが方向性の間違った」ものを作るのを防ぐ）、マイルストーンベースの計画を生成させ、runbook ファイルを使ってエージェントに操作方法を指示しました。この runbook は共有メモリと監査ログとしても機能します。
結果：GPT-5.3-Codex は約 25 時間連続で実行され、完全なデザインツールを完成させ、その間一貫性を維持しました。
サーバーサイドの compaction は、緊急時のフォールバックではなく、デフォルトのプリミティブとして機能します。マルチステップタスクでは、previous_response_id により、モデルは毎回コンテキストを再構築することなく、同じスレッドで作業を継続できます。
また、Skills という概念も導入しました。これは、コンテナにマウントされる再利用可能でバージョン管理された命令セットであり、特定のタスクに対してエージェントに安定した運用基準を提供します。これらは「役割」ではなく、ツールと操作手順であり、根本的に異なります。
Google：100 万トークンコンテキスト + コンテキスト駆動開発
Google の方向性は、ウィンドウを力技で拡大することです。Gemini の 100 万トークンコンテキストは明確な差別化戦略です。彼らの論理は、以前は RAG による分割や古いメッセージの破棄などの手法が強制されていたが、十分に大きなウィンドウがあれば「すべてをそのまま入れる」ことで置き換えられるというものです。
しかし、それでも十分ではないと彼らは認めています。Google は Gemini CLI 用の Conductor 拡張機能をリリースしました。その核となるアイデアは Anthropic と同じです：プロジェクトの意図をチャットウィンドウからコードベース内の永続的な Markdown ファイルに移すことです。哲学は：「不安定なチャット履歴に頼るな。正式な spec と計画ファイルに頼れ。」
Gemini 3 では Thought Signatures も導入されました。これは、長いセッションにおける推論チェーンの主要ノードを保存し、「推論のドリフト」——長いコンテキストにおける論理的不整合の問題——を防ぐものです。
本当のアーキテクチャ原則とは何か？
これら 3 社のエンジニアリング実践から、いくつかの共通原則を抽出できます：
推論チェーンは断ち切ってはならない。分岐して統合することはできる。 マルチエージェントの正しい使い方は流れ作業ではなく、メインエージェントが全体の意図を保持し、サブコールを使ってサブ問題を深掘りし、結果はメインエージェントに戻すことであって、次のエージェントに渡すことではありません。
明示的な外部状態に頼れ。モデルの記憶に頼るな。 progress.txt、Git 履歴、spec ファイル、データベース——形式は問いません。原則は：推論チェーンの主要ノードは永続ストレージに外部化されなければならないということです。
マルチエージェントの価値は並列カバレッジであり、分業ではない。 Anthropic の Research システムの結論は明確です：パフォーマンスの向上は「より多くのトークンを使うこと」から来ており、「より良い分業」から来るのではありません。マルチエージェントは幅優先のタスク——独立した方向性を同時に探索する必要があるシナリオ——に適しています。継続的な推論と深いコンテキスト依存性を必要とするシナリオには適していません。
検証エージェントは否定者であり、リレー走者ではない。 品質管理のためにマルチエージェントを使用する場合、正しい設計は、あるエージェントが別のエージェントの作業の問題を具体的に見つけることです。「作業結果を渡す」ことではありません。敵対的テストであり、流れ作業の受け渡しではありません。
ツールはツールであり、役割ではない。 エージェントにどのようなツールを装備するか（bash、ファイル I/O、検索、コード実行）は、どのようなラベルを貼るかよりもはるかに重要です。ツールはエージェントができることを決定します。役割ラベルはエージェントがやろうとすることを制約するだけです。
なぜ「部門化」モデルが人気なのか？
それは説明が簡単だからです。
「このエージェントは PM、あれは QA」——誰でも理解できます。AI システムの説明可能性に対する人間の欲求と、「AI がチームのように働く」という経営陣の想像力を満たします。
また、デモが簡単でもあります。部門、矢印、ハンドオフのあるフローチャートとして描くと、非常に直感的です。
しかし、説明やデモが簡単であることと、エンジニアリング的に健全であることは別問題です。
より深い理由は、このモデルを採用するほとんどのチームが「マルチエージェント間の転送におけるコンテキスト損失」という問題に真に向き合ったことがないからです。彼らのタスクは十分に複雑でないか、問題が他の要因によって隠蔽されています。タスクの複雑さが増し、システムが「局所的には正しいが、全体的には間違っている」エラーを示し始めたとき、問題が露呈します。
実践的なアドバイス
最高のマルチエージェントシステムは、会社のように見えません。それはむしろ、思考者の複数の草稿のように見えます——同じ脳が異なる次元で推論を展開し、最終的にそれらを一貫した結論に統合するものです。
この原則に基づいて：
「何人のエージェントが必要か？」と問うのではなく、「このタスクの情報依存構造は何か？」と問いましょう。
タスクが継続的な推論と高いコンテキスト依存性を必要とする場合（例：複雑な機能の設計ドキュメントを書く）、単一のエージェント + 優れたコンテキストエンジニアリングが通常、マルチエージェントよりも優れています。
タスクが独立した方向性の同時探索を必要とする場合（例：10 社の競合を同時に調査する）、マルチエージェントの並列処理は合理的です。各サブエージェントのタスクは独立しており、情報損失のコストは最小限に抑えられます。
タスクが複数のセッションにまたがる場合、外部状態ファイルは必須です。効果的な状態ファイルには、以下の 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）
