レッスン1: なぜ複数のエージェントか: 単一コンテキストの限界

学習目標:

• 長いタスクで単一のエージェントがぶつかる2つの具体的な限界を挙げる: コンテキストの汚染と注意の希釈
• Anthropicが報告したトークンコストの数値を使い、タスクを複数のエージェントに分割する価値があるかどうかを判断する
• 調整のオーバーヘッドが効果を上回るケースを認識し、今日のマルチエージェントシステムが不得意なタスクの種類を述べる

前提: このシリーズの最初の5つのコース（プロンプトの書き方、ツール呼び出しプロトコルの理解、エージェントのメモリと状態の知識、基本的なJSの読解力） | 次: レッスン2 >>

1つのエージェントがすべてを行うとぶつかる壁

単一のエージェントにこんなタスクを渡したとしましょう: 「3つのクラウドプロバイダーが過去1年間でどのように価格を変更したかを調査し、横並びで比較して、どれを選ぶべきかについて2000語の推奨レポートを書く」

1つのエージェントはこう進めます: 最初のプロバイダーの価格ページを検索して、長いHTMLブロックと価格表を読み込む。2つ目を検索し、また長いブロック。3つ目のプロバイダーの変更履歴を検索し、おそらく何度かページをめくる。途中で無関係か古い結果をいくつか見つけ、それらも読み込む。最後に、どんどん長くなっていくこの単一の会話を元に、2000語の推奨レポートを書きます。

これ自体に間違いはありません。前のコースで既に見たように、これがエージェントの動き方です: コンテキストを読み、次のステップを決め、ツールを呼び出し、結果をコンテキストに戻し、繰り返す。問題が現れるのは、タスクがより長く複雑になったときです。その単一の、絶えず成長するコンテキストが、静かに最終結果を2つの場所で引きずり下ろします。

コンテキストの汚染: 初期の間違いが消えない

調査の途中で、エージェントは誤解を招く結果を見つけます——もう有効でない価格を引用した古いブログ記事かもしれません。何かおかしいことに気づかず、実際のデータとして扱い、それを元に推論を進め、さらにはプロバイダーの1つについての初期の判断にそれを書き込んでしまいます。

一度その間違った判断が存在すると、消えません。会話履歴に残り続け、以降のすべての推論ステップの背景の一部になります。エージェントが権威ある最新の価格ページを見つける頃には、矛盾する2つの事実が同じコンテキストウィンドウに存在し、モデルはどちらを信頼すべきかをうまく判断できないかもしれません——特に間違った方が早く現れ、途中で参照されたときには。

これがコンテキストの汚染です: 初期ステップからのエラーや無関係な断片が、後のすべての推論が依存する1つのコンテキストに混ざり込み、後から来る正しい情報でもそれを完全に洗い流すのは困難です。Anthropicが述べるように、"as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases"（コンテキストウィンドウ内のトークン数が増えると、そのコンテキストから情報を正確に思い出すモデルの能力は低下する）¹。タスクが長く、中間ステップが多いほど、この種の汚染が蓄積する機会が増えます。

注意の希釈: 読めば読むほど、見えるものがぼやける

2つ目の問題は1つ目とは異なります。情報が間違っているのではなく、多すぎること自体がコストなのです。3つのプロバイダーの価格ページと変更履歴は、数万語の生コンテンツになり、すべて1つのコンテキストウィンドウに積み上げられます。モデルが最終的な推奨レポートを書くとき、原理的には数万語にわたるすべての詳細を一度に保持しなければなりませんが、コンテキストが大きくなるにつれて、そのいずれかへの注意は薄く広がります。

これが注意の希釈です。Anthropicは注意の予算として枠組みを示しています: "LLMs have an 'attention budget' that they draw on when parsing large volumes of context"（LLMは大量のコンテキストを解析する際に引き出す「注意の予算」を持っている）そして"Every new token introduced depletes this budget by some amount"（新しく導入されたトークンはそれぞれ、この予算をある程度消費する）¹。1つのコンテキストウィンドウに詰め込むほど、どの単一の詳細にも残っている予算が少なくなり、多くの詳細を同時に正確に保持する必要があるタスク——要約、比較——で、見落としやミスが起こりやすくなります。

コンテキストの汚染と注意の希釈を合わせると、単一コンテキスト経路の上限が見えます: タスクが十分に長くなると、1つのエージェントが最初から最後まで運ぶと品質は着実に低下します。Anthropicはこの低下を"a performance gradient rather than a hard cliff"（ハードな崖というより性能の勾配）¹と説明し、より長いプロンプトだけではめったにそれを取り戻せません。

マルチエージェントシステム: 長いタスクを複数のコンテキストに分割する

マルチエージェントの答えは、1つの大きなタスクを部分に分け、それぞれを独立した別々のエージェントに渡すことです。すべてを同じ絶えず成長するコンテキストに詰め込むのではなく。Anthropicの定義: "A multi-agent system consists of multiple agents (LLMs autonomously using tools in a loop) working together."（マルチエージェントシステムは、複数のエージェント（ループ内でツールを自律的に使用するLLM）が協力して作業するものである）²

クラウド調査の例に戻りましょう: 1つのエージェントが3社すべての資料を最初から最後まで読むのではなく、3つのエージェントがそれぞれ1社に集中し、それぞれが独自の別々のコンテキストウィンドウを持ち、互いに邪魔しないようにします²。最初の会社を調査中に拾った古いブログ記事は、その1つのエージェントのコンテキストだけを汚染します。他の2社についての推論には決して混ざり込みません。Anthropicはこれを「関心の分離」と呼んでいます——個別のツール、プロンプト、探索パスが経路依存を減らす²。そして各エージェントが扱う必要のある生コンテンツは「3社すべての資料」から「1社の資料」に減り、注意の希釈の問題も和らぎます。この構造がどう動くか——1つの中央エージェントがタスクを分割し、複数のエージェントが並行して作業し、結果が集約される——は次のレッスンで扱います。

コスト: マルチエージェントはより高価

エージェント間での分割は無料ではありません。各サブエージェントはタスクの背景を再び読み込み、独自の推論を整理する必要があり、それはトークンを消費します。そして最終ステップで複数のエージェントの結果を集約し、それもまたトークンを消費します。Anthropicの測定値: "In our data, agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats."（我々のデータでは、エージェントは通常、チャットのやり取りよりも約4倍多くのトークンを使用し、マルチエージェントシステムはチャットよりも約15倍多くのトークンを使用する）²

15倍は小さな数字ではありません。つまり、マルチエージェントシステムを導入するのは、タスク自体がその追加のトークンコストを正当化できるほど価値がある場合にのみ効果があるということです——Anthropicが述べるように、"For economic viability, multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance."（経済的な実行可能性のために、マルチエージェントシステムは、タスクの価値が向上したパフォーマンスに見合うほど高いタスクを必要とする）²

いくつのサブエージェントを実行するかも、「多ければ多いほど良い」という判断ではありません。Anthropicはスケーリングの経験則を提供しています: 単純な事実確認は1つのエージェントと3から10のツール呼び出しで十分。直接比較には10から15の呼び出しをそれぞれ行う2から4のサブエージェントが必要かもしれない。そして明確に分割された責任を持つほど複雑な調査だけが、10を超えるサブエージェントの価値がある²。初期には、チームは反例にぶつかりました——単純なクエリに50のサブエージェントを生成したり、存在しないソースをウェブで果てしなく探し回ったり、不要な更新を山ほど送り合ってエージェント同士が邪魔し合ったり²。

その経験則の背後にある態度は、Anthropicがエージェントアーキテクチャについて別の記事で与えるアドバイスと一致しています: "you should consider adding complexity only when it demonstrably improves outcomes."（結果が明らかに改善される場合にのみ、複雑さを追加することを検討すべきである）³。まずタスクを1つのエージェントで動かし、実際にどこで詰まるか——コンテキストの汚染か注意の希釈か——を観察し、それから複数のエージェントを導入するかどうか、どのステップで導入するかを決めます。最初から複雑なマルチエージェントシステムを立ち上げるよりも良いです。

マルチエージェントを使わない場合: 調整のオーバーヘッドが効果を上回る

マルチエージェントシステムの価値は1つの前提に依存しています: タスクをそれぞれ独立して処理できる部分に分割できること。この前提が崩れると、分割自体が余分な重荷になります。これが調整のオーバーヘッドです: 複数のエージェントが作業を分割し協力するために費やされる追加の時間とトークンで、タスクの分割、結果の集約、エージェントの矛盾する出力の調整を含みます。タスクに本当に並列化できるものがあまりない場合、調整のオーバーヘッドは分割が買うものを簡単に上回ります。

Anthropicは不適合な種類のタスクを1つ挙げています: "most coding tasks involve fewer truly parallelizable tasks than research, and LLM agents are not yet great at coordinating and delegating to other agents in real time."（ほとんどのコーディングタスクは、調査よりも真に並列化可能なタスクが少なく、LLMエージェントは他のエージェントとリアルタイムで調整および委任することにまだ長けていない）²。バグの修正は通常、コード内の互いに連動する複数のロジックを理解することを意味し、前から後ろまで密結合していて、異なるエージェントのために互いに踏み合わずにきれいに分割することは困難です。これは深さ優先タスクに近いです: 答えは段階的に取り組む必要がある1つの推論の連鎖の中にあり、いくつかの無関係な方向に散らばっているわけではありません。対照的に、Anthropicがマルチエージェントシステムが本当に優れていると発見したのは、高価値の作業です——"multi-agent systems excel at valuable tasks that involve heavy parallelization, information that exceeds single context windows, and interfacing with numerous complex tools"（マルチエージェントシステムは、大量の並列化、単一のコンテキストウィンドウを超える情報、多数の複雑なツールとのインターフェースを含む価値あるタスクに優れている）²——そしてクラウド価格の調査や複数のドキュメントの横並び比較は幅優先タスクです: 答えは互いの中間結果に依存することなく、別々に追いかけることができるいくつかの比較的独立した方向に広がっています。

タスクをマルチエージェントにすべきかどうかを決めるには、3つの質問から始めます: タスクを互いに独立したサブタスクに分割できるか？分割後、総情報量は単一のコンテキストウィンドウが保持できるものを超えるか？タスクはその追加のトークンコストをカバーするほど価値があるか？1つでも答えが「いいえ」または「その価値はない」に傾く場合、タスクを誠実に単一エージェントシステムで完了させることは、通常、複数のエージェントに無理に押し込むよりも良い選択です。

まとめ

• 単一のエージェントが最初から最後までそれを行うと、長いタスクで2つの具体的な限界にぶつかります: コンテキストの汚染（初期のエラーや無関係な断片が後の推論に混ざり込み、洗い流すことが困難）と注意の希釈（1つのコンテキストに詰め込むほど、モデルがどの単一の詳細にも注意を払わなくなる）。
• マルチエージェントシステムは、それぞれがツールを独立して使用する複数のエージェントが協力して作業するものであり²、各エージェントに独自のコンテキストウィンドウを与えることで汚染と希釈を緩和します。
• マルチエージェントは無料ではありません: Anthropicのデータによると、平均してチャットのやり取りの約15倍のトークンを使用するため、タスクの価値が十分に高い場合にのみ効果があります²。いくつのサブエージェントを実行するかについても、「多ければ多いほど良い」ではなく、Anthropicのスケーリング経験則に頼ることができます²。
• より安全な姿勢は、まずタスクを単一のエージェントで動作させ、結果が明らかに改善される場合にのみ複雑さを追加することを検討することです³。
• エージェント間で分割するかどうかを決定するには、次のように尋ねます: タスクは独立したサブタスクに分割できるか？情報は単一のコンテキストを超えるか？価値は追加のトークンコストに見合うか？Anthropicは、コーディング型、深さ優先、密結合のタスクは並列化が不十分でマルチエージェントの強みではないと明言しています²。別々に追いかけることができる幅優先の調査タスクです。

レッスン2: オーケストレーターとサブエージェント: ファンアウトと集約 >>