Anthropicが企業向けAI Agentアーキテクチャガイドを発表——まず3つの問いに答えてから、マルチエージェントを導入するか決めよ
マルチエージェントシステムは効果を90.2%押し上げるが、トークンコストも10〜15倍に膨らむ。この三問フレームワークで、複雑なアーキテクチャを導入すべきか先に見極めよう。
- AnthropicがAI Agentの企業導入ガイドを発表。Coinbase、Intercom、Thomson Reutersなど実顧客の実運用事例を基に、アーキテクチャパターンと選定方法をまとめている。
- 本文が示す中核アーキテクチャは6種類——シングルエージェント、階層型スーパーバイザー方式、協調型、順次ワークフロー、並列ワークフロー、評価者-最適化者ワークフロー。
- Anthropicの社内研究によれば、複数の独立した経路を同時に探索する必要がある複雑タスクにおいて、マルチエージェントシステムはシングルエージェントより効果が90.2%高い。ただしトークン消費量はシングルエージェントの10〜15倍。
- ガイドは「どれだけの制御性が必要か」「問題がいくつの領域にまたがるか」「リソース予算はどれほどか」という三問の意思決定フレームワークを示し、闇雲に最も複雑な方式を追うのではなく、どのアーキテクチャを選ぶべきかを判断する助けとする。
- 核心の方法論は「シンプルから始めて段階的に進化させる」こと——まずシングルエージェントで価値を検証し、その後ビジネスニーズとデータのフィードバックに応じてアップグレードする。最初から複雑なシステムを組むべきではない。
Anthropicが送る企業向けagentアーキテクチャ手引書
Anthropicが最近発表したAI Agentの企業向けアーキテクチャガイドは、Coinbase、Intercom、Thomson Reutersなど顧客の実際の導入事例をまとめ、6種類のアーキテクチャパターンと1つの選定意思決定フレームワークを提示している。
ホワイトペーパーの冒頭一文で立ち位置は明確にされている——生成AIは質問に答え、AI agentは問題を解決する。そしてこの手引書が答えようとするのは、その先にあるもっと実務的な問い、すなわち同じ業務に対して、1つのAI agentに単独で任せるべきか、それともマルチエージェントシステム一式を組むべきかという選択だ。これを実行可能な判断フレームワークに落とし込み、各アーキテクチャに実顧客の定量データを添えている。
読む価値がある理由：ガイドは重要な定量的トレードオフを示している。複数の独立した方向性を同時に探索する必要がある複雑タスクにおいて、マルチエージェントシステムの効果はシングルエージェントより90.2%高い。ただし消費するトークン量はシングルエージェントの10〜15倍にのぼる。この一方の上昇と一方の下落こそが、全文すべてのアーキテクチャ選定判断の土台になっている。
まずはっきりさせておきたいことがある。AI agent（エージェント）と通常の自動化スクリプトは、動作の仕組みが大きく異なる。従来の自動化は各ステップを事前にすべて書き込んでおく必要があり、プロセスはスクリプト通り一歩ずつ進み、事前に想定していない状況に遭遇すると止まってしまう。agentのやり方はこうだ——タスクを評価し、適切なツールを選び、ある方法を試し、結果の良し悪しを見て、戦略を調整し、事が片付くまでこのループを回し続ける。
すべてのステップを事前に用意しておく必要がある。プロセスは固定的で追跡可能だが、事前に敷かれた一本道しか歩めず、想定外のケースに出会うと処理が途切れる。
タスクを受け取ると自分で計画を立てる——質問を読み、口座履歴を調べ、ナレッジベースを検索し、返信の下書きを作り、必要なら人間にエスカレーションする。すべて中間結果に応じて動的に調整しながら進める。
ガイドの冒頭には、これらのシステムが実際の本番環境でどのような成果を出したかを示す顧客成績が並んでいる。
この4つの数字が示すのは規模ではなく、カバー範囲だ——カスタマーサポート、セキュリティオペレーション、不正審査、業種横断の解決率という、まったく異なる4種類の業務がどれも本番環境でagentに支えられて動いている。これが証明するのは「投資する価値がある」ということであり、「どのアーキテクチャを選ぶべきか」にはまだ答えていない。ガイドはさらに、日常業務によりリアルなもう1つの事例を挙げている——ある小売銀行では、信用リスク覚書の処理にagentを使っている。以前は関係担当者が10種のデータソースを手作業で確認するのに数週間かかっていたが、いまは20%〜60%の生産性向上をもたらし、信用審査の回転時間は30%短縮された。これらの数字が前提を確立している——agentは投資する価値がある、しかしどのアーキテクチャで実現するかこそが、このガイドが本当に教えたいことだ。全部で6種類のアーキテクチャが語られるが、実は3つの家系に分かれる。AI自身に判断させるもの（シングルエージェント、階層型スーパーバイザー方式、協調型）、人間が事前にプロセスを固定するもの（順次、並列ワークフロー）、そして品質管理専任のもの（評価者-最適化者）だ。以下、シンプルなものから複雑なものへ順に見ていこう。
第一歩：まずシングルエージェントで足りるか見極める
ガイドが繰り返し強調する第一原則は「シンプルから始める」ことだ。いきなり複雑なシステムを組むのではなく、まずシングルエージェントで問題を解決できないか見る。その方が安く、デバッグしやすく、指標もビジネス成果と結びつけやすい。
シングルエージェントシステムとは、1つのAI agentが連続したループを回すことを指す——環境を感知し、次の一手を決め、実行に移す。これをタスクが完了するか、「一時停止して人間の確認を待つ」といった停止条件に達するまで繰り返す。その中核はいくつかのコンポーネントで組み立てられている。
図中の3つのコンポーネントのうち、2つは専門用語なので先に説明しておく。
agentが外部システム（データベース、ウェブ検索、社内ツール）と接続するための標準インターフェース一式。agentはこれを使って初めて実際にデータを調べたりツールを操作したりできる。ただおしゃべりするだけの存在ではなくなる。AIに万能変換アダプタを装備するようなもので、データベースにつなぐにも検索エンジンにつなぐにも接続規格が統一されているため、毎回個別に連携コードを開発する必要がない。
特定領域の専門知識、標準プロセス、ツールの使い方をひとつのモジュールにパッケージ化し、agentが必要な時に呼び出せるようにしたもの。専門知識をすべてプロンプトに詰め込む必要はない。agentに専用のツールボックス一式を持たせるようなもので、法律の問題に出会えば法律ツールボックスを取り出し、財務の問題ならそれ用に入れ替える。1つのagentがすべての領域の知識を頭に詰め込む必要はない。
適している：オープンエンドな問題に直面し、最初はどう進めるべきかがはっきり見えない場合。何ステップかかるか、どんな障害に当たるかわからない中で、agentが自分で状況を見ながら調整していく。
避けるべき：一発で100%完璧な答えを出す必要がある場面。この場合シングルエージェントでは力不足であり、専用のSkillsを追加して精度を高めるか、それでもだめならマルチエージェントの導入を検討すべきだ。アップグレードの前にまず考えるべきは、シングルエージェントにスキルを追加するだけで十分ではないかということだ。
展開して見る：あるリサーチagentが8ステップで複雑なクエリをこなす様子
社員がこう尋ねる。「エンジニアリングチームが採用しているリモートワーク効率化ツールを調べて、社内の生産性指標と関連するものがあるか見てほしい」。このagentはMCPでコンテンツライブラリ、業務ツール、開発環境に接続されており、次のように処理する。
- ①質問受領 → ②初期分析：これには2つのデータソース——外部ツールの調査と社内指標——が必要で、外部調査は最初は社内データに依存しないため並列検索に分割でき、最後に関連付ければよいと判断する。
- ③スキル起動：リサーチ手法、データ関連付け、ビジネスインサイトの3種のスキルを呼び出し、ゼロから推論するのではなく確立されたフレームワークを適用する。
- ④タスク分解と計画：外部ウェブ検索、社内データベース照会、並列実行、関連付けと統合という方針を定める。
- ⑤並列でツール呼び出し：ウェブ検索（効率化ツールのトレンドを探す）とSQLデータベース（社内の生産性指標を照会する）を同時に実行し、2つのツールを並行させることで総所要時間を大幅に短縮する。
- ⑥反復的な精緻化：初期結果を見て、よりエンジニアリングチームに特化したデータが必要だと気づき、より的確な二次クエリを追加する。
- ⑦統合と関連付け → ⑧結果生成：外部トレンドと社内指標を突き合わせて比較し、統合された結論を出力する。
限界に到達：マルチエージェントへ移行すべきシグナル
シングルエージェントが根本的な天井にぶつかったとき、初めてマルチエージェントの出番となる。ガイドは3つの明確なトリガーシグナルを示す一方、その代償もはっきりと提示している。
マルチエージェントとは、タスクを分割し、それぞれ専門性を持つ複数のagentに割り当て、各自の作業完了後に結果を一貫性のある回答へと統合することを指す。Anthropicの社内研究が示す核心の数字は、複数の独立した方向性を同時に探索する必要がある複雑タスクにおいて、マルチエージェントシステムはシングルエージェントより効果が90.2%高いというものだ。その判断によれば、知能がある臨界点に達すると「マルチエージェントシステムはパフォーマンスをスケールさせるための鍵となる経路」になる。なぜなら、群れとしてのagentが達成できることは単体をはるかに超えるからで、これは人間の組織と同じだという。
この2本のバーを並べれば、全文の要となる基準がわかる——効果は確かに大幅に上がるが、コストも倍々で膨らんでいく。もう一点、90.2%という数字の適用範囲には注意が必要だ。これは全書で最も文脈を切り離して誤用されやすい数字であり、「複数の独立した方向性を同時に探索する必要がある」複雑タスクでのみ測定されたものだ。すべての場面の裏付けに使うべきではない。だからこその警告も直接的だ——単純なクエリで高コストなマルチエージェントプロセスを起動させるべきではなく、システムはタスクの価値に応じて投入量を動的に調整できる必要がある。
①オープンエンドな問題：何ステップ必要か予測しづらく、調査の過程で随時方向転換し、脇道を探る必要がある。
②タスクが複数の無関係な領域にまたがる：研究によれば、1つのタスクに2つ以上の互いに無関係な専門領域（例えば法的条項の審査と財務モデルの計算を同時に行う場合）が混在すると、シングルエージェントはあちらを立てればこちらが立たずの状態になり、パフォーマンスが急激に低下する。
③広域並列：問題が複数の独立した方向性を同時に追う必要があり、並列処理が実質的なパフォーマンス向上をもたらす。
代価はトークンだけにとどまらない。マルチエージェントはトラブルシューティングを難しくする。従来のデバッグ手法はここでは通用しない。なぜならagentは動的に判断し、実行のたびに結果が変わる不確実な存在だからだ。判断の数が倍々で増えていくため、agent同士がどう連携し、どうタスクを割り振り、どう結果を統合しているかを捕捉できるトレーシングが必須になる。そうでなければ、連携に問題が起きたときにほとんど手の打ちようがなくなる。
階層型スーパーバイザー方式：1人の統括者が複数の専門家を率いる
マルチエージェントの導入を決めた後、最初に答えるべき問いは、このagent群をどう組織するかだ——管理者を置くか、置かないか。管理者を置くバージョンが階層型スーパーバイザー方式であり、最も一般的なマルチエージェントパターンでもある。中央のスーパーバイザーがリクエストを分析し、適切な専門家agentにタスクを割り振り、結果を統合する。これにより明確な責任の連鎖が形成される。
核心のメカニズムはこうだ——階層型システムでは、各専門家サブエージェントは「ツール」として扱われ、スーパーバイザーはツール呼び出しの形でどの専門家を起動するかを決定する。これは優秀な人間のチームの運営方法と同じで、専門家は自分の領域に集中し、コーディネーターが割り振りと統合を担う。サブエージェント自身もさらにサブエージェントを持つことができ、これら下層はさらに上位のスーパーバイザーからは見えないようになっている。スーパーバイザーはサブチームのリーダーとだけやり取りし、その下に何層あるかは把握していない。
マーケティングチームの例でこの流れを見てみよう。
このパターンで最も厄介な落とし穴はコンテキスト管理であり、これは単独で取り上げる価値がある。
システムが長時間稼働すると、会話履歴と中間結果がAIの「脳容量」（コンテキストウィンドウ）を埋め尽くし、ウィンドウのオーバーフロー、推論能力の低下、agent間の連携不全として現れる。解決策は3つある。
- コンテキスト編集（context editing）：トークン上限に近づいたら、過去のツール呼び出し記録や結果を自動でクリーンアップしつつ、会話の流れを途切れさせない。
- メモリツール（memory tools）：情報をコンテキストウィンドウの外にあるファイルシステムに保存し、必要な時に読み込む。セッションをまたいで保持することもできる。
- ツール自体のスロットリング：ツールにページング、範囲選択、フィルタリング、切り捨てを追加し、妥当なデフォルト値で単発の応答サイズに上限（例えば2万5000トークン前後）を設け、コンテキストが破裂するのを防ぐ。
ガイドもこのパターンがトークン使用量をより高めることを認めているが、その判断は採算が合うというものだ。専門知識を要する、あるいはシングルエージェントのコンテキスト上限を超える高価値・複雑タスクに対しては、パフォーマンス上の利益がこのコストを正当化するというわけだ。
協調型：agent同士が対話しながら問題を解決する
これが「管理者を置かない」バージョンであり、階層型スーパーバイザー方式と最も混同されやすいものでもある。この2つの本質的な違いはただ1点——誰が誰を管理するかがない、ということだ。連携はagent同士のやり取りから自然に生まれるものであり、中央の権威によって強制されるものではない。
協調型システムでは、agentは対等で自律的な個体であり、直接ピアツーピアで対話し、動的に各自の役割を相談しながら、複雑な問題を共同で解決していく。これを実現するために3種類のメカニズムが使われる。
グループチャット式ディスカッション：複数のagentが共有の会話スレッドを立て、話し合いながら問題を解決し、意思決定し、互いに検証する。プロジェクトグループを作るのに似ている。
イベント駆動型連携：「イベント」を共通言語とし、あらゆる動作を構造化された更新としてブロードキャストする。他のagentはそれを基に作業を引き受け、コンテキストを同期する。
ブラックボード式ナレッジ共有：すべてのagentが読み書きできる中央「ブラックボード」を立て、発見があれば誰でもそこに書き込み、集合的な記憶として使う。
協調型のリスクはまさにその自由度にある。agent同士の頻繁な通信は計算コストと複雑さを押し上げる。さらに厄介なのは「創発的行動」が生まれることだ——誰も意図的にプログラムしたわけではないのに自然発生する振る舞いのことで、小さな変更がシステム全体の動きに予測不能な影響を与える可能性がある。対応策は命令を強制することではなく、協調のフレームワークを立てることにある。役割分担、問題解決の方法、投入予算を定義し、同時にagentがタスクを無限にたらい回しにするのを防ぎ、対立解消のメカニズムを整えておく。
この2つのマルチエージェントパターンを並べれば、違いが一目でわかる。以下のタブを切り替えて2種類の構造を見比べてみよう。
ツリー状の指揮系統。スーパーバイザーが頂点に立ち、専門家が下層に並ぶ。タスクは上から下へ割り振られ、結果は下から上へ集約される。
- 明確な責任連鎖があり、監査・追跡可能
- スーパーバイザーが業務ルールを強制でき、監督権を保持できる
- カスタマーサポート、コンテンツ制作、データ分析など、柔軟性と監督の両方が求められる中程度の制御性のシーンに適している
メッシュ状の対等な接続。agentはすべて対等で、誰とでも直接対話でき、話し合いによって自ら合意を形成する。
- 中央の意思決定者はおらず、連携は相互作用から創発する
- 行動はより予測しづらい。これは探索的なシーンにおいては欠陥ではなく特性である
- 研究、ブレインストーミング、複雑な分析など、低い制御性しか求められないシーンに適している
順次 vs 並列：タスクは並んで待つべきか、同時に走るべきか
前述のいくつかはagentが動的に判断するものだったが、続く2種類は事前に固定された静的なワークフローオーケストレーション（agentic workflows）であり、agentがどんな順序で、どんな条件下でタスクを実行するかを定義する。核心的な違いはただ1つ——タスクを並んで待たせるか、同時に走らせるかだ。
| 順次ワークフロー | 並列ワークフロー | |
|---|---|---|
| 動き方 | 1本の線に沿って順に実行され、各ステップの出力が次のステップの入力になる | 複数の線が同時に実行され、それぞれ独立して結果を出し、最後に統合される |
| 核心的な価値 | 待ち時間で正確性を買う——時間を少し多めにかける代わりに、AIの各呼び出しをより集中的で誤りにくいシンプルなタスクにできる。プロセスは予測可能で、コストを見積もりやすく、段階ごとにトラブルシューティングできる | 求めるのはスピードと複数視点——複数の経路を同時に走らせ、異なる角度から問題を網羅することで、結論により説得力を持たせる |
| 使うべき場面 | タスクをきれいに固定のサブタスクに分割でき、明確な線形依存関係があり、監査・追跡が必要な場合（コンプライアンスチェック、承認フロー、下書き→レビュー→公開） | サブタスクが互いに独立していて同時に実行でき、複数視点が品質向上に寄与し、速度が連携コストより重要な場合（リスク評価は複数視点が必要、ガードレール審査：あるモデルが作業しもう一方が不適切なコンテンツを専門にふるいにかける、複数経路での並列評価） |
| 避けるべき場面 | 数ステップでシングルエージェントで済む場合、agentが引き継ぎではなく協調を必要とする場合、プロセスが後戻りして反復する必要がある場合 | agentが互いの成果の上に積み重ねる必要がある場合、特定の実行順序が必要な場合、共有状態を変更するのに対立解消戦略がない場合、結果の集約ロジックが複雑すぎてかえって品質を下げる場合 |
2種類のワークフローにはそれぞれ実際の事例が添えられている。順次の例はデータサイエンスのインサイトだ——分析リクエストはまず判定agent（分析タイプを判断し、ルーティングする）を通過し、次にデータエンジニアリングagent（データを抽出・クレンジングする）、続いて分析agent（統計モデリングを実行、または複雑なリクエストは人間へエスカレーション）、最後に人間によるレビューへと進む。並列の例は金融リスク評価だ。
評価者-最適化者：AIに自分の課題を自己添削させる
これが最後のワークフローパターンで、2つのAIが役割分担し、繰り返しのループの中で品質を基準に達するまで磨き上げる。
1つのAIがコンテンツ生成を担当し、もう1つが問題点を専門にチェックし、実行可能なフィードバックを与える。基準に達するまで何度もやり取りして修正するのであって、一度作って終わりにするものではない。ライターと編集者を組ませるようなもので、編集者は何度も突き返して書き直させ、うなずいて通ったところで初めて発表される。
APIドキュメント生成の事例はこう進む——生成agentがコードベースを分析し、初稿（エンドポイントの説明、パラメータ、サンプル、認証要件）を書く。技術評価agentが実際のコード実装と照らし合わせて1つずつ確認する（パラメータの型は正しいか、エンドポイントは網羅されているか、サンプルは動くか）。問題があれば差し戻し、生成agentがフィードバックを取り込んで修正する。
適している：明確な評価基準があり、繰り返し磨くことで見える価値をもたらせる場面。文学翻訳、安全要件のあるコード生成、口調に厳格な要求のある専門文書、複数ステップの推論と検証が必要なリサーチタスクなど。
避けるべき：一発目の原稿ですでに基準を満たしている場合、評価基準が主観的で曖昧な場合、時間コストが品質向上分を上回る場合。また即応性が求められるリアルタイムアプリケーション、基礎的な分類のような単純タスク、トークン予算が逼迫している環境、そして評価agent自体が専門性を欠き有意味なフィードバックを出せない状況にも使うべきではない。
三問フレームワーク + 1本のリアルな進化ロードマップ
まずここまでの流れをまっすぐに引き直そう——シングルエージェントで足りるなら人を追加する必要はない。3種類のシグナル（オープンエンド、領域横断、広域並列）に当たって初めてマルチエージェントに移る。マルチエージェントに移ったら、まず管理者を置くか置かないかを選ぶ。事前に固定できるプロセスはワークフローに任せ、固定できないものだけがagent自身の判断に委ねられる。この連鎖を収束させると、本書で最も価値のある部分——3つの必答の問いに行き着く。まずこの3点をはっきりさせてから、技術的な複雑さを積み上げるのではなく、それに応じてアーキテクチャを選ぶべきだ。以下のセレクターを、自分の状況に合わせてクリックしてみれば、どのアーキテクチャを指し示すかがわかる。
ガイドはさらに4つ目の問いを補っている——深い領域専門性が必要かどうか？単一領域で確立されたプロセスがあるなら、専用のSkillsを備えたシングルエージェントで十分。複数の異なる領域が協調する必要がある場合（例えば法務審査が財務分析と連携しなければならないケース）に初めて、専用のSkillsを備えたマルチエージェントを導入する。以下はこの三問チェックリストの完全な日本語版であり、項目は原文と一対一で対応している。そのまま自分の状況に当てはめて使ってほしい。
1. どれだけの制御性が必要か？ 高い制御性が求められる場合（規制コンプライアンス、金融取引、安全に関わる業務）→ シングルエージェントまたは順次ワークフローから始める 中程度の制御性が求められる場合（カスタマーサポート、コンテンツ制作、データ分析）→ 階層型マルチエージェントシステムを検討する 低い制御性が求められる場合（研究、ブレインストーミング、複雑な分析）→ 協調型マルチエージェントも実現可能 2. 問題領域はどれほど複雑か？ 単一領域の問題（製品質問への回答、返品処理、レポート生成）→ シングルエージェントで効率よく処理できる 複数領域だが予測可能な問題（従業員オンボーディング、コンプライアンスワークフロー、標準的な分析タスク）→ 順次または並列ワークフロー 複雑でオープンエンドな問題（戦略分析、リサーチプロジェクト、システム障害対応)→ マルチエージェントアーキテクチャ 3. リソースの制約は何か？ 予算/トークンが限られている → シングルエージェント、または丁寧に設計された並列ワークフロー 市場投入までの時間がタイト → まずシングルエージェントを使い、進化の経路を計画する 長期的な戦略投資 → 最初からモジュール式の進化を前提に設計する 4. 深い領域専門性が必要か？ 単一領域で確立されたプロセスがある → 専用Skillsを備えたシングルエージェント 複数の異なる領域が協調を必要とする → 専用Skillsを備えたマルチエージェントシステム
各パターンの適用シーン早見表
上記の制約条件を、具体的にどの業務がどのカテゴリに属するかを判断する際にそのまま参照できる対応表にした。
シングルエージェントが最も適しているのは： - カテゴリの境界が明確なカスタマーサポートプロセス - 業務ルールが明確な文書処理 - コードレビューと基礎的な開発タスク - 定型分析とレポート作成 順次ワークフローが最も適しているのは： - 複数ステップの承認プロセス - コンテンツ制作パイプライン（下書き → レビュー → 公開） - データ変換と検証 - 複数基準によるコンプライアンスチェック 並列ワークフローが最も適しているのは： - 複数視点が品質を高めるシーン - 各分析が互いに独立していて同時に実行できるシーン - 速度が連携コストより重要なシーン - 多様な視点が必要なリスク評価 マルチエージェントシステムが最も適しているのは： - 複数領域の専門性が必要な複雑な問題 - リサーチと分析プロジェクト - 複数システムにまたがる動的な顧客対応 - 戦略計画と意思決定支援
英語原文対照（三問チェックリスト / 早見表 / 進化テンプレート）
1. What level of control do you need? High control requirements (regulatory compliance, financial transactions, safety-critical operations) → Start with single agents or sequential workflows Moderate control requirements (customer support, content creation, data analysis) → Consider hierarchical multi-agent systems Low control requirements (research, brainstorming, complex analysis) → Collaborative multi-agent systems become viable 2. How complex is your problem domain? Single domain problems (answering product questions, processing returns, generating reports) → Single agents handle these efficiently Multi-domain but predictable problems (employee onboarding, compliance workflows, standard analysis tasks) → Sequential or parallel workflows Complex, open-ended problems (strategic analysis, research projects, system troubleshooting) → Multi-agent architectures 3. What are your resource constraints? Limited budget/tokens → Single agents or carefully designed parallel workflows Time-to-market pressure → Start with single agents, plan an evolution path Long-term strategic initiative → Design for modular evolution 4. Do you need deep domain expertise? Single domain with established workflows → Single agent with specialized Skills Multiple distinct domains requiring coordination → Multi-agent systems with specialized Skills Single agents work best for: customer service / document processing / code review / routine analysis and reporting Sequential workflows work best for: multi-step approvals / content pipelines (draft → review → publish) / data transformation / compliance checking Parallel workflows work best for: multiple perspectives / independent analyses / speed over coordination / diverse-viewpoint risk assessment Multi-Agent systems work best for: complex problem-solving / research and analysis / dynamic multi-system interactions / strategic planning Phase 1: Single agent for customer inquiries (proving value) Phase 2: Routing pattern separating order status, product questions, complaints Phase 3: Specialized agents for each category with shared context Phase 4: Multi-agent system with inventory, payment, and shipping coordination Phase 5: Evaluator agents for quality assurance and continuous improvement
1本のリアルな進化ロードマップ：あるECプラットフォームの5段階
締めくくりは1本のリアルな道のりだ——あるECプラットフォームがシングルエージェントからマルチエージェントへと歩んだ5つの段階。これは一足飛びに複雑なシステムを組んだわけではなく、各段階で測定可能な価値が確認できてから複雑さを加えている。
本番システムはさらにハイブリッドアーキテクチャへと進化することが多い——階層型スーパーバイザーの中に並列処理を組み込む、順次ワークフローに動的ルーティングを持たせる、シングルエージェントが境界事例に遭遇した際に自動でマルチエージェントシステムを起動する、といった具合だ。ビジネス価値が複雑さに見合うだけあれば、これらの組み合わせは単一パターンでは実現できない能力を解き放つ。
着地点は常にこの一言に尽きる——アーキテクチャはニーズに応じて進化させる。シンプルから始め、すべてを測定し、複雑さが測定可能な価値をもたらすときにだけ追加する。今日の最良のアーキテクチャとは、現在の要求を満たしながら、明日への道を残しておく最もシンプルな案である。 Building Effective AI Agents · Anthropic
AI agentは複雑であるほど強いわけではない——まず3つの問いを立ててから、1つで動かすか群れで動かすか決めよう
Anthropicが企業向けagentアーキテクチャガイドを出した。6種類の作り方を3つの家系にまとめ、三問の選定法とセットにして、このページで一気に説明する。
↓ 1ページで読み切る · 動く図が1枚ある
AI agent（自分で次の一手を判断し、ツールを選び、試行錯誤しながら調整できるAI。固定で書かれたスクリプトを一歩ずつなぞるだけの存在ではない）は、企業でますます複雑な業務に使われるようになっている。厄介なのは、その作り方が何通りもあり、いきなり最も複雑な方式を組んでしまうと、たいてい無駄にお金を使うことになる点だ。
スクリプトは事前に敷かれた一本道しか歩めず、自分で評価したり、手を変えたり、試行錯誤したりはできない。これこそagentが補う能力だ——タスクを評価し、ツールを選び、結果を見て調整する
しかし「自分で対応できる」ことは「なんでも組んでいい」ことを意味しない。作り方を誤った代償は非常に実際的だ。本来1つのagentで済むはずの仕事に、わざわざマルチエージェント一式を組んでしまうと、token（AIが文章処理に使う課金単位。使うほど請求額が高くなる）が10〜15倍も消えることがある。このガイドが教えるのは、まさにその選び方だ。
ガイドはagentの作り方を6種類にまとめているが、実は3つの家系に分かれる。AI自身に判断させるもの（1つのagentが単独でこなす、1人の統括者が専門家を率いる、複数の対等なagentが互いに対話する）、プロセスを事前に固定するもの（並んで進む順次、同時に走る並列）、品質管理専任のもの（2つのAIが一方は書き、もう一方が問題点をチェックして交互に修正する）だ。最も混同しやすいのは最初の家系の3種類。以下の図では「小互が競合分析レポートを1本作る」という例でこの3つを並べて示す。後者の家系の3種類は本文で図解している。
アーキテクチャの選定は技術的な複雑さを積み上げていくべきものではなく、まず3つの問いに答え、その答えが直接どのアーキテクチャを使うべきかを指し示す。
感覚に頼るか、あるいは「複雑なほど高度」だと決めつけて、いきなりマルチエージェントを組んでしまう。
まず3つの問いを立て、それに応じて選び、割に合う場合だけ手数を増やす。
- どれだけの制御性が必要か？規制当局や監査に一つ一つ説明できる必要がある → シングルエージェントまたは順次ワークフロー。多少の不確実性を許容できる → その時初めてマルチエージェントを検討する。
- 問題はいくつの領域にまたがるか？単一領域（製品の質問に答える、レポートを出す）→ 1つのagentで十分。複数の無関係な領域にまたがる → その時初めてマルチエージェントに移る。
- 予算はどれくらいあるか？トークンが逼迫している → シングルエージェント。長期投資である → 最初のagentの段階からアップグレード用のインターフェースを残しておく。
本文ではこの三問をクリック操作できるセレクターに仕立て、さらに「どんな場面でどれを使うか」の早見表と、あるECプラットフォームがシングルエージェントからマルチエージェントへ進んだ5段階のリアルなアップグレードロードマップを添えている。そのまま参照できる。
マルチエージェントは確かに強力だが、その分代償もある。まずこの勘定を平らにしてから、導入するかどうかを決めよう。
同一バッチのクエリを処理
同一バッチのクエリ
これらの数字はすべてAnthropicの社内研究または顧客の自己申告に基づいており、第三者による独立再現はない。方法論は参考にできるが、数字は割り引いて見るべきだ。
とりあえず一番ガチなやつ組もう！
がこんなに何倍も燃えた
なんでこんなに高いの?!
→ 1つで十分
→ 1つで足りる
→ 群れは導入しない
その価値を証明する。
「より複雑」を
「より良い」と
混同するな。