マルチエージェントが現実になった年
2024年の大半、マルチエージェントをめぐる議論は「雰囲気」でした。「エージェントの群れ」が結婚式を企画したり、架空の会社を運営したりするデモが投稿され、そのほとんどは本番環境との接触で生き残ることはありませんでした。約束は大きく、証拠は薄かったのです。
それが変わったのは2025年4月、Anthropicが自社のマルチエージェント・リサーチシステムに関するエンジニアリング報告を公開したときです。アーキテクチャの骨格は単純でした。リードとなるClaude Opus 4エージェントがオーケストレーターとして機能し、リサーチクエスチョンをサブタスクに分解し、並列でサブエージェントを起動して調査させ、その出力を統合します。Anthropic社内のブラウジング評価において、この構成は単一エージェントのOpus 4ベースラインを90.2%上回りました。(Anthropic engineering, "How we built our multi-agent research system")
これが見出しです。しかし注釈の方がより重要です。同じ報告は、マルチエージェントシステムが通常のチャットに比べて約15倍のトークンを消費すると述べています。彼らの評価フレームワークにおいて、トークン消費量はパフォーマンスのばらつきの約80%を説明していました。90.2%という数字は無料で得られるものではなく、買っているのです。
つまり、AI機能を設計するファウンダー、CTO、スタッフエンジニアにとって問題はもはや「マルチエージェントは本物のパターンなのか?」ではありません。「このタスクにとってマルチエージェントは正しいパターンなのか、そしてそれはどのくらいのコストで?」です。2025年と2026年前半は、感覚以上の根拠でその問いに答えるだけのデータを生み出しました。勝ったパターン、負けたパターン、そして繰り返し現れる失敗モードは、古典的な組織設計によく似ています。それがこの記事の主軸です。
失敗モードの分類体系：Cemriらが記録したもの
2025年3月、Mert Cemriとバークレーの共同研究者たちは「Why Do Multi-Agent LLM Systems Fail?」を発表しました (arXiv 2503.13657)。この論文は、人気のあるマルチエージェントフレームワーク5つを対象に150以上の会話トレースを分析し、この分野が切実に必要としていたものを提示しました。それが分類体系です。
14の異なる失敗モードが、3つのファミリーにグループ化されています。
仕様とシステム設計の失敗。 エージェントが役割仕様に従わない。タスク仕様に従わない。会話履歴を失う。同じステップを繰り返す。終了条件が発火しない。システムはタスクを「知っている」のに、目の前の個々のエージェントはそのように振る舞いません。
エージェント間のミスアライメント。 エージェントが進捗をリセットしてやり直す。互いに情報を渡さない。本題から外れたやりとりに脱線する。別のエージェントが何をやったかを確認せず勝手に仮定して行動する。これはどんなチームでも起こる、典型的な「あなたがやってくれていると思った」型の失敗です。
タスク検証と終了の失敗。 検証が不完全か、まったく行われない。出力が間違っているのにシステムが成功を宣言する。最終的な受け入れチェックを担うエージェントが存在しない。問題は下流に流れた後、悪い出力がすでに伝播してから人間が気づくだけです。
このリストを読めば、形が明らかになります。これらは狭義のモデル失敗ではありません。調整の失敗です。新人5人のチームが、誰が何を担当するかを書き出す前の最初の1か月で犯すのと同じ失敗です。
14のモードを別の切り口でまとめると、組織設計との並行性がさらにはっきりします。
- 役割の曖昧さ。 タスクのオーナーシップが不明瞭。2つのエージェントが同じステップに取りかかる、あるいはどちらも取りかからない。
- 状態の曖昧さ。 何が完了し、何が保留中で、何がブロックされているかについて、単一の真実の源(SSOT)がない。
- 説明責任のギャップ。 悪い出力に対して誰が責任を持つのか?ピアツーピア型システムでは、しばしば誰も持ちません。
- 調整オーバーヘッド。 「会議問題」。エージェントは生産する代わりに、交渉にトークンを使います。
- 仕様のドリフト。 同じ指示が、エージェントごとにも、ターンごとにも、異なって解釈されます。
出荷できていないチームを立て直したことがあるなら、この5つはすべて見覚えがあるはずです。人間のチームでの解決策は、エージェントシステムでも同じです。運用モデルを選び、役割を書き出し、ハンドオフを定義し、仕事を計装することです。
なぜピアツーピア型エージェントは機能しないのか
2024年から2025年初頭にかけて最も多かったアーキテクチャ上のミスは、ピアツーピア型のコラボレーションでした。異なる役割プロンプト(CEO、リサーチャー、コーダー、レビュアー)を持つエージェントの「チーム」を起動し、グループチャットで会話させ、調整が自然発生することを期待するアプローチです。AutoGenスタイルのグループチャット、初期のCrewAIデモ、そして大量に登場した「箱入りAIスタートアップ」プロジェクトのいずれもがこのパターンに依存していました。
そして本番環境では一貫して失敗しました。Cemri分類体系のあらゆる失敗モードは、P2P構成において増幅されます。オーケストレーターがいなければ、どのエージェントにも何でも頼めるため、役割の境界がぼやけます。会話履歴中に状態が散らばります。誰も正準的な記録のオーナーではないからです。説明責任は消えます。出力を生むのはシステム全体であり、システム全体には名前が付いていないからです。
調整オーバーヘッドが致命傷になります。ピアエージェント5体のグループでは、意味のあるアクションが起こるたびに、コメントを残さなければと感じる4人の観察者が生まれます。トークンコストは膨れ上がります。S/N比は崩壊します。Cemriらは、エージェントが終了済みのスレッドを終了したと認識できずに再起動してしまう「会話リセット」が、彼らのコーパスにおいて最も頻繁で最も高コストな失敗の一つだったと報告しています。
具体例を挙げます。2025年後半に話したあるリサーチチームは、競合分析のドラフトを作成するためにP2P型エージェントシステムを構築しました。5体のエージェント:市場アナリスト、プロダクトアナリスト、財務アナリスト、ライター、エディター。最初の実行には90分かかり、14,000語の文書が出力されました。そのうち約11,000語は、エージェントたちが文書に何を含めるべきかを議論する内容でした。残る3,000語が文書本体で、しかも内容が互いに矛盾していました。チームは翌週、これをオーケストレーター・ワーカー型に作り直しました。同じタスクで22分、4,200語、内容は内部的に整合しています。トークン消費はおよそ半分でした。
P2Pが失敗したのは、エージェントが十分に賢くなかったからではありません。グループにとって最も難しいこと、つまり議長なしで自分たち自身を組織化することを彼らに求めたから失敗したのです。
オーケストレーター・ワーカー型：勝利したパターン
Anthropicのリサーチシステムは、教科書通りのオーケストレーター・ワーカー型構成です。1体のコーディネーター・エージェントがハイレベルなタスクを所有します。タスクをサブタスクに分解し、それぞれを具体的なブリーフとともにワーカー・エージェントに渡し、結果を集約し、次に何をするかを決定します。ワーカー同士は会話しません。彼らはオーケストレーターと会話します。
これは人間の組織設計にすっきりとマッピングされます。だからこそ機能するのです。ファウンダー1人と契約者4人で構成される小さなスタートアップは、まさにこの形で動いています。ファウンダーが仕様、予算、タイムライン、共有コンテキストを保持します。契約者はブリーフに沿ったスコープのタスクを実行します。情報はファウンダーを経由して上に流れ、タスクはファウンダーから下に流れます。慎重に設計されたペア構成を除き、契約者同士で調整することは期待されません。
このパターンには、信頼性の観点で重要な4つの特性があります。
共有状態のオーナーが1人だけ存在する。 オーケストレーターが正準的な記録を保持します。何が完了したかについて曖昧さはありません。
ワーカーのコンテキストはスコープが限定される。 各ワーカーは必要なものだけを受け取ります。これによりコンテキストウィンドウが扱いやすくなり、タスク間の汚染が起こりにくくなります。
ハンドオフが定義されている。 ワーカーの出力は、オーケストレーターが検証できる構造化フォーマットで返されます。自由形式の交渉はありません。
説明責任の窓口が一つだけ存在する。 出力が間違っていれば、責任はオーケストレーターにあります。デバッグする場所は1か所です。
Anthropicの報告は、信頼性向上の作業の多くがオーケストレーターの内部で行われたことを明示しています。リードエージェントのプロンプトは、システム全体の中で最も長く、最も慎重にチューニングされた部分です。役割定義、分解のヒューリスティクス、終了ロジックがそこに住んでいるからです。(Anthropic engineering)
範囲を限定したコラボレーション(bounded collaboration)は、有用なバリエーションです。2体のワーカーが特定のハンドオフに限って相談することは許される場合がありますが、構造化されたチャネルを通じて、定義されたトピックについてのみ行われます。Slackチャンネルではなく、予定された朝会のようなものだと考えてください。境界こそが要点です。
| パターン | 失敗耐性 | コスト | 複雑性 | 適する場面 |
|---|---|---|---|---|
| ピアツーピア(グループチャット) | 低。あらゆる失敗モードが増幅する。 | 高。交渉にトークンを大量に消費する。 | 誤解を招く。単純に見えるが実際は違う。 | デモ、ブレインストーミングのスケッチ。 |
| オーケストレーター・ワーカー | 高。オーナー1人、デバッグ窓口1つ。 | 中〜高。単一エージェントの約10〜15倍。 | 中。ロジックの大半はオーケストレーターに集まる。 | 調査、分解、並列化可能な作業。 |
| 範囲限定コラボレーション | 中〜高。リスクは接合部に存在する。 | 中。完全なP2Pより安価。 | より高い。ハンドオフの設計は手間がかかる。 | オーケストレーター配下の専門家ペアリング。 |
| エージェントフロー(DAG) | 高。静的構造がドリフトを未然に防ぐ。 | 低〜中。キャッシュされたステップを再利用できる。 | 設計時は中、実行時は低。 | 繰り返しのパイプライン、バッチ処理。 |
5段階の自律性フレームワーク
知っておく価値があるもう一つの2025年の足場が、「Levels of Autonomy for AI Agents」(arXiv 2506.12469)によって提示された自律性フレームワークです。ガバナンスに関する補足記事はKnight Columbiaにあります。著者らは、SAEの運転自動化レベルに大まかになぞらえながら、AIエージェント向けの5段階を定義しています。
レベル0: 補助(Assistive)。 モデルは提案し、人間が行動します。オートコンプリート、インラインのコード提案、メール下書きの作成など。
レベル1: オペレーター(Operator)。 各アクションを発動するのは依然として人間ですが、エージェントは直接の指示の下でツール呼び出しや複合的なステップを組み立てます。
レベル2: レビュー対象(Reviewer)。 エージェントはプランを提案し、レビュー下で実行します。人間は主要なチェックポイントで承認を行います。
レベル3: 協働者(Collaborator)。 エージェントは限定されたスコープの中でタスク全体を自律的に所有します。人間はステップではなく出力をレビューします。
レベル4: エキスパート(Expert)。 エージェントは複雑な多段階作業を独立して進め、人間はフラグの立った例外時のみ介入します。
レベル5: エージェント(Agent)。 あるドメインにおける完全な自律性。エージェントは目標を設定し、計画し、実行し、最小限の監督のもと自己修正します。
Anthropicの補完研究「Measuring AI agent autonomy in practice」は、関連する論点を示しています。実際のデプロイメントでは、システム全体で動作レベルが均一であることは稀です。「レベル3」のシステムは通常、レベル1のサブコンポーネント(リスクの高いアクション)とレベル4のサブコンポーネント(リスクの低いバックグラウンド作業)を内包します。重要なのは、レベル全体を引き上げることではなく、タスクに合ったレベルを当てはめることです。
狙うレベルは、その下流のすべての役割設計の意思決定を形作ります。レベル2では、ワーカー・エージェントに明確なプラン・レビューのアフォーダンスが必要です。レベル4では、例外フラグ付けと豊富なトレースが必要です。レベル5では、受け入れ基準の形式的な検証が必要です。それ以外では誤った答えを誰も捕まえられないからです。このステップを飛ばすビルダーは、先にアーキテクチャを選び、その後本番で、アーキテクチャが含意するレベルとタスクが許容できるレベルが一致していないことを発見することになります。
実践における自律性レベル：Devinのケース
CognitionのDevinは、2025年に最も引用された教訓の物語になりました。2024年3月に「最初のAIソフトウェアエンジニア」として発表されたDevinは、SWE-bench Verifiedで13.86%のスコアを記録し、当時の最先端でした。マーケティングはレベル4または5の自律性を示唆していました。チケットを渡せば、動くPRが返ってくるというものです。
2025年半ばまでに、複数の独立したレビューはDevinの実世界での成功率をおよそ15%と評価しました。つまり、整えられたベンチマーク・インスタンス以外のタスクでは、約85%という実質的な失敗率です。広く引用されているAnswer.AIのレビューは20回の実行を検証し、14回が完全に失敗し、いくつかは自信を持って間違った出力を生み、結果としてゼロからコードを書くよりもデバッグに時間がかかったと報告しました。
起きたことは、ベンチマーク対本番のギャップが先鋭化したことです。SWE-bench Verifiedのタスクはクリーンです。1つのリポジトリ、よく説明された1つのIssue、明確なテスト信号、制約された面積です。実際のエンジニアリングチケットは雑然としています。曖昧な仕様、横断的な関心事、文書化されていない前提、暗黙知に依存する判断。ベンチマークではレベル3に位置していた同じエージェントが、実環境ではぐらつくレベル2、時にはそれ以下に落ち込みました。
Devinは悪いエージェントの物語ではありません。レベルの不一致の物語です。アーキテクチャが目指したのはレベル5の信頼性、しかし下にある能力が支えられたのは、整えられていない作業ではせいぜいレベル2でした。マーケティングはユーザーに広告されたレベルでシステムを使うよう仕向け、そこで失敗しました。Cognitionのその後の方向転換、つまりユースケースのスコープを狭め、人間の介在を増やし、より誠実な言い回しに変えていったことは、動作レベルを能力と整合させようとする試みです。
教訓は具体的です。最も簡単なベンチマークではなく、最も難しい実タスクで持続できる自律性レベルを選びましょう。役割、監督、エスカレーションの経路を、そのレベルに合わせて設計しましょう。レベル5のマーケティングが欲しいなら、レベル5のシステムを作りましょう。レベル3のシステムを持っているなら、レベル3として売りましょう。
Cursor 2.0とハードウェアに支えられたワークフロー
Cursor 2.0は2026年2月に出荷され、マルチエージェント・コーディングで最も根強かった問題の一つ、ワークスペースの衝突を静かに解決しました。Cursorのバックグラウンドエージェントは、それぞれ独自のgit worktreeを持ったクラウドVM上で実行され、IDEは最大8つを並列で調整できます。
重要なアーキテクチャ上のポイントは、各エージェントが自身のファイルシステムを持つことです。共有のワーキングツリーが存在しないということは、編集途中のマージ衝突が起きない、「エージェントAがエージェントBの変更を上書きした」が起きない、2体のエージェントが同じファイルに触れていたために不安定なテスト実行が起こらない、ということを意味します。エージェントが完了すると、そのブランチは他のPRと同じようにレビューしてマージできます。失敗したら、worktreeを捨てればよいのです。
これは、2000年代に仮想マシンがプロセス分離をもたらしたのと同じ意味で、ハードウェアに支えられた分離です。エージェントのフェンスはもはや「お互いに踏み合わないと約束する」ではなく、「OSが文字通り踏ませない」になりました。
Cemri分類体系の観点でなぜこれが重要か。ハードウェア分離は、エージェント間のミスアライメント失敗の一群を丸ごと取り除きます。状態はworktreeの中に留まります。副作用はVMの中に留まります。オーケストレーター(Cursor自身、あるいはユーザー)が見るのは、各エージェントが生成するdiffだけです。受け入れチェックは構造的なもの(PRはCIを通過するか?)になり、会話的なもの(このエージェントは作業完了と主張するか?)ではなくなります。
Cursor 2.0、AnthropicのClaude Code、OpenAIのCodex CLI、その他の並列エージェントツールを並べて運用している実務家たちは、あるパターンに落ち着いています。3〜8体のエージェントを独立したタスクに対して起動し、統合ダッシュボードで進捗を監視し、勝ったものをマージし、負けたものを捨てる、というものです。コストモデルは「チャットボットに質問する」よりも「ジュニアの契約者を1時間半雇う」に近づきます。出力モデルはチャット応答よりもGitHub PRレビューに近づきます。
Anysphere(Cursor)、Bolt、Lovable、そしてVercel内のv0は、いずれも内部でこのループのバリエーションを動かしています。最も多くのエージェント駆動コードを出荷している企業は、ワークスペース分離を最初に作り上げた企業です。
AIチームメイトのための役割設計
マルチエージェントの失敗が組織設計の問題であると受け入れた瞬間から、行うべき設計の動きは古典的なマネジメントに似てきます。エージェントの各役割には、4つの成果物が必要です。
スコープを絞った責任。 一文で表せること。このエージェントが所有するものと、所有しないもの。散文も書く「リサーチャー」エージェントは、トレンチコートの中に隠れた2人のエージェントです。分けましょう。
構造化された入力ブリーフ。 「Xを調べてくれ」ではありません。問い、エージェントが前提とすべき先行コンテキスト、期待される出力のフォーマット、制約(時間、トークン、ツール)、ソースの優先順位を埋め込むテンプレートです。これは、エージェント版のプロジェクト・ブリーフです。
定義された受け入れ基準。 「完了」がどう見えるのか?多くの場合これはスキーマ(出力は次のZod型に対して検証されなければならない)、あるいは決定論的なチェック(PRはこの3つのテストファイルを通らなければならない)です。決定論的なチェックが使えない場合は、別のレビュアー・エージェントを明示的なルーブリックに沿って走らせます。
エスカレーション経路。 エージェントが詰まったら、何をするのか?妥当なデフォルトはこうです。オーケストレーターに構造化された明確化質問をする、人間にフラグ付き例外として浮上させる、型付きエラーで中止する。間違ったデフォルトは「とにかく続行して即興でしのぐ」です。幻覚した成功はそこから生まれます。
Cemriの失敗モードを一つずつ当てはめれば、この4つの成果物でほとんどがカバーされます。役割の曖昧さは、スコープを絞った責任のもとで死にます。状態の曖昧さは、構造化ブリーフのもとで死にます。説明責任のギャップは、受け入れ基準のもとで死にます。エージェントは交渉する必要がなく、ブリーフとルーブリックを持っているため、調整オーバーヘッドは下がります。仕様のドリフトは、仕様がスキーマに捕まえられていて雰囲気に頼らないため、下がります。
見落とされがちな点は、役割はチャットボットへのプロンプトとしてではなく、契約者への職務記述書として書くべきだということです。契約者は正しい心的モデルです。彼らはブリーフを持ち、成果物を納品し、あなたの会社の全コンテキストを知る必要はなく、仕様を外し続ければ契約を打ち切られます。
ファウンダーのためのマルチエージェント・プレイブック
これがAnthropicの報告、Cemriの論文、Devinの事後検証、そしてCursor 2.0のワークフロー・データから蒸留した実践版です。
レベル5ではなく、レベル2または3から始める。 分布シフトのもとで能力は脆弱です。ベンチマークがレベル4を示していても、あなたの最も難しい実タスクは通常もう1段下です。最も難しいタスクが持続できるレベルを狙いましょう。
ピアツーピアではなく、オーケストレーター・ワーカー型を使う。 1体のエージェントが共有状態を所有します。ワーカーはスコープを絞ったブリーフを受け取ります。範囲を限定したコラボレーションは、慎重に設計された接合部だけで許可されます。グループチャットは禁物です。
一度に一つのエージェント役割を定義する。 何もまだ出荷していないうちにホワイトボードで5体のエージェントシステムを設計したくなる衝動に抵抗しましょう。オーケストレーター1体とワーカー1体を出荷します。1週間観察します。最初のワーカーが失敗するのを見て修正してから、次のワーカーを追加します。
ブリーフは職務記述書のように書く。 責任、入力、受け入れ基準、エスカレーション。役割を4つの短いセクションで書けないなら、その役割はまだ出荷できる段階ではありません。
完全なトレースで計装する。 あらゆるエージェントのアクション、あらゆるツール呼び出し、あらゆる中間出力。マルチエージェントシステムを最終出力だけ読んでデバッグすることはできません。バグはほぼ常に上流にあります。
15倍のトークンコストを予算化する。 Anthropicのリサーチシステムは、単一エージェントのベースラインに比べておよそ15倍のトークンを使いました。それを前提に計画しましょう。15倍でユニットエコノミクスが壊れるなら、その機能にとってマルチエージェントは間違ったパターンです。
重大な行動には人間を介在させ続ける。 「重大」とは通常、顧客向けシステムへの書き込み、外部通信の送信、金銭の支出、データの削除、セキュリティに関わるリソースの変更を意味します。人間のレビューは数秒で済みますが、それを欠くと数か月かかる場合があります。
エージェントの艦隊を組む前にワークスペース分離を構築する。 Cursorの教訓は一般化できます。コードにはgit worktree、データにはスコープを絞ったDBトランザクション、環境に触れる作業には専用VMを。分離は調整よりも安価です。
最初の90日間は、失敗ごとにポストモーテムを実施する。 失敗をCemri分類体系でタグ付けします。パターンは速く現れます。3回目の「エージェントが完了済みの作業をやり直した」失敗は、終了条件を引き締めるべきだという信号です。
このどれも特別なものではありません。有能なエンジニアリング・リーダーが新しい契約者チームをオンボードするときに使うのと同じプレイブックです。マルチエージェントが機能する理由は、同じ問題をより締まったフィードバックループで扱っているからです。
この先どこへ向かうのか
これからの12〜18か月は、これらのパターンをインフラに変えていく時間です。注視すべきいくつかの流れがあります。
エージェント間プロトコル。 GoogleのA2Aプロトコル、IDEやCLIツール全般で登場しつつあるAGENTS.md規約、そしてワーキンググループで進む各種相互運用ドラフトは、エージェントが互いを発見し、ケイパビリティ記述を交換し、認証する方法を標準化しようとする試みです。(Anthropicの「building agents」概説もこの方向を示唆しています。) 目的は、オーケストレーター・ワーカー型パターンをベンダー横断で構成可能にすることであり、特定プロバイダのSDKに縛られないようにすることです。
ケイパビリティ・トークン認可。 今日、多くのエージェントは起動したユーザーの完全なクレデンシャルを継承します。これはレベル3以上では悪い考えです。ケイパビリティ・トークン、つまり狭く、時間制限があり、特定のツール呼び出しとリソースに限定されたトークンが、エージェントが本当に必要とする権限のみを得る方法になります。本番SDKに2026年中に登場するでしょう。
検証済みエージェント・アイデンティティ。 エージェントが組織境界を越えて別のエージェントを呼び始めると、受け取る側は何が呼び出してきたのかを知る必要が出てきます。署名されたエージェント・アイデンティティ、学習と設定のアテステーション、ベンダー横断のアイデンティティ・フォーマットが現在試作されています。モデルはOAuthよりも、Certificate Transparencyに近いものです。
より良い評価。 SWE-bench、MLE-bench、GAIAなどのスイートは、フロンティアモデルが飽和させるほど引き伸ばされてきました。次世代の評価は、これまでベンチマークが避けてきたものを測ろうとするでしょう。長期タスクの完遂、ポリシー遵守の持続、失敗からの回復、成功あたりのコストです。「エージェント信頼性」は、サービスにとっての「アップタイム」のように測定可能な特性になっていくと予想されます。
標準化された失敗タグ付け。 Cemriらは分野に分類体系を与えました。自然な次のステップは、Sentryが例外をタグ付けするのと同じように、分類体系に対してトレースを自動的にタグ付けするツールです。これを早期に整えるファウンダーは、整えない人より一桁速くエージェントシステムをデバッグできるでしょう。
仕事はまだ飛行中です。これらのスレッドはどれも決着していません。しかし次のフェーズの輪郭は見えています。プロンプト工芸は減り、システム工学が増えます。「モデルは何ができるか?」は減り、「私はどんな役割を埋めたいのか、完了とはどう見えるのか?」が増えます。生き残るチームは、エージェントをチームメイトとして扱い、新規採用者に当てるのと同じ厳格さで運用するチームでしょう。役割、ブリーフ、受け入れ基準、エスカレーション経路。有能な組織の退屈な成果物です。
よくある質問
すべてのチームがマルチエージェントシステムを構築すべきですか?
いいえ。ほとんどの本番AI機能は、依然として優れたツールを備えた単一エージェント構成で最もよく機能します。マルチエージェントが見合うのは、タスクが本当に分解可能(独立して並列実行できるサブタスクがある)であり、タスクごとの価値が15倍のトークンコストを正当化し、信頼性が単一エージェント層で先に実証されている場合です。失敗している単一エージェントシステムが、機能するマルチエージェントシステムに変わることはありません。普通は、より高価な失敗システムになります。
本番投入可能な最もシンプルなマルチエージェント・パターンは何ですか?
オーケストレーター1体に、決定論的な受け入れ基準を持つワーカー2体を組み合わせる構成です。オーケストレーターが共有状態を所有します。ワーカーはスコープを絞ったブリーフを受け取ります。出力はオーケストレーターが受理する前にスキーマに対して検証されます。これだけで、分解の恩恵の大半を、より大きなチームの調整オーバーヘッドなしに獲得できます。ワーカー数を増やすのは、このベースラインが信頼できるようになってからです。
15倍のトークンコストに見合う価値はありますか?
出力の価値次第です。Anthropicのリサーチシステムは経済的に意味を持ちます。なぜなら代替手段が、同じタスクに数時間を費やす人間のリサーチャーだからです。価値が低く量が多い作業(意図分類、単純な要約、定型抽出)では、15倍のトークンコストはほぼ常に見合いません。単一エージェント構成か、より小さなモデルを使いましょう。価値が高く量が少ない作業(深いリサーチ、複雑なコーディング、複数ソースの分析)では、計算が成立することが多いです。
サブエージェントを起動するか、より長いプロンプトを使うかは、どう判断しますか?
サブエージェントを起動するのは、その作業が親タスクと異なるコンテキスト要件を持つ場合です。サブタスクが異なるツール、異なるシステムプロンプト、あるいは親のウィンドウを汚染するコンテキストを必要とするなら、独自のエージェントを与えましょう。サブタスクが「次のこれをやって」というだけで、親のコンテキストを共有しているなら、より長いプロンプトかツール呼び出しの方が安価で信頼できます。決め手となる問いはたいていコンテキストに関わるものです。サブタスクが終わった後、このコンテキストをオーケストレーターのメモリに残しておきたいか?
エージェントとAIツールの違いは何ですか?
ツールはモデルが呼び出せる単一の決定論的なケイパビリティです(ウェブ検索、データベースクエリ、コードフォーマッタなど)。エージェントはループです。観察し、計画し、ツールを呼び出し、結果を評価し、次に何をするか決定します。これがしばしば多くのターンにわたって行われます。ツールは名詞、エージェントは動詞です。よく作られたエージェントは多くのツールを使います。内部でモデルを呼び出し、独自のループを回す「ツール」は、実質的にエージェントです。
おわりに
現時点で最も有用だと感じた整理は、マルチエージェント・コーディングのロールアウトを主導しているあるエンジニアリング・リーダーから聞いた言葉です。「私たちはエージェントを賢いものとして考えるのをやめ、無限のスタミナを持つジュニアとして考え始めました。」 ジュニアには明確な役割、書かれたブリーフ、定義された受け入れ基準、そしてエスカレーション経路が必要です。彼らは予測可能な間違いをします。フィードバックで上達します。誰も彼らの仕事を所有していないとき、失敗します。
それが、マルチエージェントの議論の内側に隠れている組織設計のシフトです。2025〜2026年の難問は、もはや能力の問題ではありません。モデルは十分に良くなりました。難問は、人間のチームを運営するのを難しくしてきたのと同じ問題です。誰が何を所有するのか、誰が状態を保持するのか、誰が仕事をチェックするのか、間違ったときに誰が責任を持つのか。Cemriの分類体系、自律性フレームワーク、オーケストレーター・ワーカー型パターン、Devinの事後検証、Cursorの分離モデル。これらはすべて、同じ問いのバリエーションへの答えです。
2026年にエージェント駆動のプロダクトを出荷するファウンダーであれば、退屈な成果物こそがレバレッジです。役割を書きましょう。ブリーフを書きましょう。完了を定義しましょう。ワークスペース分離を構築しましょう。トレースを計装しましょう。重要なところで人間を介在させ続けましょう。これを実践するチームは、2か月は遅く見え、2年は速く見えるでしょう。スキップするチームは、誰かがすでに書いた分類体系に対して失敗モードをタグ付けすることに、残りの1年を費やすことになります。
エージェントは今やチームメイトです。そのように管理しましょう。
