Anthropic、AIエージェント構築ガイドを公開——まず3つの問いを立ててから、マルチエージェントに踏み込むかを決めよ
マルチエージェントシステムは効果を90.2%押し上げる一方、tokenコストも10〜15倍に跳ね上がる。この三問フレームワークで、複雑なアーキテクチャに踏み込むべきかをまず見極めよう。
- Anthropicが企業向けAIエージェント構築ガイドを公開。Coinbase、Intercom、Thomson Reutersなど実顧客の導入事例をもとに、アーキテクチャパターンと選定方法をまとめている。
- 本文全体で6種類のコアアーキテクチャを提示：単一エージェント、階層監督型、協調型、シーケンシャルワークフロー、パラレルワークフロー、評価者-最適化ワークフロー。
- Anthropic内部調査によれば、複数の独立した経路を同時に探索する必要がある複雑タスクにおいて、マルチエージェントシステムは単一エージェントより効果が90.2%高い。ただしtoken消費量は単一エージェントの10〜15倍。
- ガイドは三問の意思決定フレームワーク(どこまでの制御性が必要か、問題は何領域にまたがるか、リソース予算はどれだけか)を提示し、闇雲に最も複雑な案を追うのではなく、どのアーキテクチャを選ぶべきかを判断させる。
- 核心の方法論は「シンプルに始めて段階的に進化させる」こと——まず単一エージェントで価値を検証し、業務ニーズとデータのフィードバックに応じてアップグレードしていく。最初から複雑なシステムを組み上げるのではない。
Anthropicによる企業向けエージェント構築マニュアル
Anthropicは先日、企業向けのAIエージェント構築ガイドを公開した。Coinbase、Intercom、Thomson Reutersなど実顧客の導入事例をまとめ、6種類のアーキテクチャパターンと一連の選定意思決定フレームワークを提示している。
ホワイトペーパー冒頭の一文が立ち位置をはっきり示している——生成AIは質問に答え、AIエージェントは問題を解決する。このマニュアルが答えようとしているのは、その先にあるもっと実務的な問い、同じ業務において単一のAIエージェントで済ませるべきか、それともマルチエージェントシステム一式を組むべきか、というものだ。この選択を実行可能な判断フレームワークに落とし込み、各アーキテクチャに実顧客の定量データを添えている。
なぜ読む価値があるか：ガイドは重要な定量トレードオフを示している。複数の独立した方向性を同時に探索する必要がある複雑タスクにおいて、マルチエージェントシステムは単一エージェントより効果が90.2%高い。だがそれが消費するtoken量は単一エージェントの10〜15倍。この一升一降こそが、本文すべての選定判断の土台となっている。
まずはっきりさせておきたいことがある。AIエージェント(agent)と普通の自動化スクリプトは、動き方が大きく違う。従来の自動化は各ステップを事前に書き切る必要があり、フローはスクリプト通りに一歩ずつ進み、想定していなかった状況に出くわすと止まってしまう。エージェントのやり方は、タスクを評価し、適切なツールを選び、あるやり方を試し、結果が良いか見て、また戦略を調整する——このループを、事が片付くまで回し続ける。
各ステップを事前にすべて書いておく必要がある。フローは固定されトレース可能だが、あらかじめ敷かれた道しか歩けず、境界事例に当たると途切れる。
タスクを受け取ると自分で計画を立てる——問題を読み、口座履歴を調べ、ナレッジベースを繰り、返信を起案し、必要なら人手を介入させる。全過程を中間結果に応じて動的に調整する。
ガイド冒頭には一連の顧客実績が並び、これらのシステムが実際の本番環境でどんな結果を出したかを示している。
この4つの数字が示しているのは規模の大小ではなく、カバー範囲の広さだ。カスタマーサポート、セキュリティオペレーション、不正審査、業界を横断した解決率——まったく異なる4つの仕事すべてで、エージェントが本番環境で耐えられることが証明されている。これらが証明するのは「投資する価値がある」ということであり、「どのアーキテクチャを選ぶべきか」にはまだ答えていない。ガイドはさらに、日常業務によりに近い例も挙げている。ある小売銀行がエージェントで信用リスクの覚書を処理したケースだ。以前はリレーションシップマネージャーが10種類のデータソースを手作業で照合するのに数週間かかっていたが、現在は生産性が20%から60%向上し、与信サイクルタイムが30%短縮された。これらの数字が前提を築く——エージェントは投資する価値がある。だがどのアーキテクチャで実現するかこそ、このガイドが本当に教えようとしていることだ。ガイド全体では6種類のアーキテクチャを扱っているが、実は3つのグループに分かれる。AI自身に判断させるもの(単一エージェント、階層監督型、協調型)、人が事前にフローを書き切っておくもの(シーケンシャル、パラレルワークフロー)、そして品質管理専門のもの(評価者-最適化)だ。以下、シンプルなものから複雑なものへ順に見ていこう。
ステップ1：まず単一エージェントで足りるか見る
ガイドが繰り返し強調する第一原則は「シンプルに始める」ことだ。いきなり複雑なシステムを組まず、まず単一エージェントで問題を解決できるか見よう。そのほうが安く、トラブルシューティングもしやすく、指標もビジネス成果と対応させやすい。
単一エージェントシステムとは、1つのAIエージェントが連続したループを回し続けることを指す——環境を知覚し、次の一手を決め、実行に移す。タスクが完了するか、「一時停止して人手によるレビューを待つ」といった停止条件にぶつかるまでそれを続ける。その核心はいくつかのコンポーネントで組み上げられている。
図中の3つのコンポーネントには専門用語が2つある。ここで説明しておこう。
エージェントを外部システム(データベース、ウェブ検索、社内ツール)につなぐ標準インターフェース群。エージェントはこれによって初めて実際にデータを調べたりツールを呼び出したりできる——ただのチャット相手ではなくなる。AIに万能変換アダプターを装備するようなもので、データベースにつなごうが検索エンジンにつなごうが、インターフェースは統一規格なので、その都度連携用のコードを開発する必要がない。
ある領域の専門知識・標準フロー・ツールの使い方をひとつのモジュールにまとめ、エージェントが必要なときに呼び出す。すべての専門知識をプロンプトに詰め込む必要はない。エージェントに専門の道具箱一式を持たせるようなもので、法律問題に当たれば法律の道具箱を、財務問題に当たれば別の道具箱に持ち替える。1つのエージェントの頭にすべての領域を詰め込む必要はない。
向いている：オープンエンドな問題に直面し、最初はどう進めるべきか見えず、何ステップかかるか、どんな障害にぶつかるかわからない場合。エージェントに自分で進みながら調整させる。
向いていない：一発で100%完璧な答えを出す必要がある場面。この場合、単一エージェントでは力不足になる。専用のSkillsを追加して精度を上げるか、それでも足りなければマルチエージェントを検討する。アップグレード前にまず考えるべきは、単一エージェントに技能を足すだけで十分ではないか、ということだ。
展開して見る：リサーチエージェントが8ステップで複雑なクエリを完遂する流れ
社員がこう尋ねる。「エンジニアリングチームが採用しているリモートワーク効率化ツールを調べて、社内の生産性指標との関連を見てほしい」。このエージェントはMCPでコンテンツライブラリ、業務ツール、開発環境に接続されており、次のように処理する。
- ①質問受信 → ②初期分析：2つのデータソースが必要だと判断する——外部ツールのリサーチと社内指標。外部リサーチは最初は社内データに依存しないため、並行検索に分割してから最後に関連付けできると判断する。
- ③技能起動：リサーチ手法、データ関連付け、ビジネスインサイトの3種の技能を呼び出し、ゼロから推論するのではなく確立されたフレームワークを適用する。
- ④タスク分解と計画：外部ウェブ検索、社内データベース照会、並行実行、関連統合という方針を定める。
- ⑤ツールを並行呼び出し：ウェブ検索(効率化ツールのトレンドを探す)とSQLデータベース(社内生産性指標を照会)を同時に走らせ、2つのツールを並列実行することで総所要時間を大幅に短縮する。
- ⑥反復精緻化：初期結果を見て、より具体的なエンジニアリングチームのデータが必要だと気づき、それに基づいてより的確な二次クエリを追加する。
- ⑦関連統合 → ⑧結果生成：外部トレンドと社内指標をクロス比較し、統合した結論を出力する。
限界に達した合図：マルチエージェントに切り替えるべきシグナル
単一エージェントが根本的な天井にぶつかったとき、初めてマルチエージェントの出番となる。ガイドは3種類の明確なトリガーシグナルを挙げているが、その代償も包み隠さず示している。
マルチエージェントとは、タスクを分解し、それぞれ専門を持つ複数のエージェントに割り振り、各自やり終えたら結果を一貫した回答に統合する、という意味だ。Anthropic内部調査が示す中核の数字は、複数の独立した方向性を同時に探索する必要がある複雑タスクにおいて、マルチエージェントシステムは単一エージェントより効果が90.2%高いというもの。その見立てでは、知能がある臨界点に達すると「マルチエージェントシステムが性能をスケールさせるカギとなる」。なぜなら、群としてのエージェントがこなせることは単体をはるかに超える——それは人間の組織と同じだからだ。
この2本のバーを並べれば、それが本文全体の判断基準だとわかる。効果は確かに大幅に上がるが、コストも同じ倍率で跳ね上がる。もうひとつ、90.2%の適用範囲には注意しておきたい。本書で最も切り取られやすい数字だからだ。これは「複数の独立した方向性を同時に探索する必要がある」複雑タスクでしか計測されていない。あらゆる場面のお墨付きに使ってはいけない。だからこそ警告も率直だ——シンプルな問い合わせで高コストなマルチエージェントフローを起動すべきではない。システムはタスクの価値に応じて投入量を動的に調整できなければならない。
①オープンエンドな問題：何ステップ必要になるか予測しづらく、調査の過程でいつでも方向転換したり、脇道を探索したりする必要がある。
②タスクが複数の無関係な領域にまたがる：研究によれば、ひとつのタスクに互いに無関係な専門領域が2つ以上混じっている場合(たとえば法的条項の審査と財務モデルの計算を同時にやる必要がある場合)、単一エージェントはどちらも中途半端になり、パフォーマンスが急激に低下する。
③広域並行：問題が複数の独立した方向を同時に追う必要があり、並行処理が実質的な性能向上をもたらす。
代償はtokenだけではない。マルチエージェントはトラブルシューティングを難しくする。従来のデバッグ手法はここでは効かない。エージェントは動的に意思決定し、実行のたびに不確定だからだ。意思決定が倍増すると、エージェント同士がどうコミュニケーションし、どうタスクを割り振り、どう結果を統合しているかを捉えるトレーシングが必須になる。そうでなければ、協調にひとたび不具合が起きたときほぼ手の打ちようがなくなる。
階層監督型：1人の統括が複数の専門家を率いる
マルチエージェントに切り替えると決めたあと、最初に答えるべき問いは、このエージェント群をどう組織するかだ——管理者を置くか、置かないか。管理者を置くバージョンが階層監督型と呼ばれ、最も一般的なマルチエージェントパターンでもある。中央の監督者がリクエストを分析し、適切な専門エージェントにタスクを割り振り、結果を統合する。明確な責任の連鎖ができる。
核心のメカニズムはこうだ。階層システムでは、各専門サブエージェントは1つの「ツール」として扱われ、監督者はツール呼び出しの形でどの専門家を呼び起こすかを決める。これは効率的な人間のチームの動き方と同じで、専門家は自分の領域に専念し、コーディネーターが割り振りと統合を担当する。サブエージェント自身がさらにサブエージェントを持つこともでき、この下位層は上位の監督者からは見えない。監督者はサブチームのリーダーとだけやり取りし、その下に何層あるかを知らない。
マーケティングチームの例でフロー全体をたどってみよう。
このパターンで最も厄介な落とし穴はコンテキスト管理と呼ばれるもので、単独で取り上げる価値がある。
システムが長く動き続けると、会話履歴や中間結果がAIの「脳容量」(コンテキストウィンドウ)を埋め尽くし、ウィンドウのオーバーフロー、推論能力の低下、エージェント間の協調不全として現れる。解決策は3つある。
- コンテキスト編集（context editing）：token上限に近づいたら、古くなったツール呼び出しの記録と結果を自動で整理しつつ、会話の流れを途切れさせない。
- メモリツール（memory tools）：情報をコンテキストウィンドウ外のファイルシステムに保存し、必要なときに読み出す。セッションをまたいで保持することもできる。
- ツール自体のスロットリング：ツールにページネーション、範囲選択、フィルタリング、切り捨てを組み込み、妥当なデフォルト値で単回のレスポンスサイズに上限(たとえば2.5万token程度)を設けて、コンテキストが破裂するのを防ぐ。
ガイドもこのパターンがtoken消費量が大きくなることを認めているが、その判断はこうだ——専門知識が必要な高価値タスクや、単一エージェントのコンテキスト上限を超える複雑タスクに対しては、性能面のメリットがこのコストに見合う。
協調型：エージェント同士が対話しながら問題を解く
これが「管理者を置かない」バージョンであり、階層監督型と最も混同されやすいパターンでもある。両者の本質的な違いはただ一点——誰が誰を管理するということがない、という点だ。協調は、中央の権威によって強制されるのではなく、エージェント同士のやり取りから自然に生まれる。
協調型システムでは、エージェントは対等な自律個体であり、直接ピアツーピアで対話し、それぞれの役割を動的に相談しながら、複雑な問題を一緒に解決していく。合意に至るためのメカニズムは3種類ある。
グループチャット形式の議論：複数のエージェントが共有の対話スレッドを開き、話し合いながら問題を解決し、意思決定し、互いに検証する。プロジェクトのグループチャットを組んでいるようなもの。
イベント駆動の協調：「イベント」を共有言語として使い、各アクションを構造化された更新としてブロードキャストし、他のエージェントがそれをもとにタスクを引き受けたりコンテキストを同期したりする。
ブラックボード式の共有ナレッジベース：すべてのエージェントが読み書きできる中央の「黒板」を立て、誰かが発見したことをそこに書き込み、集合的な記憶として使う。
協調型のリスクは、まさにその自由度にこそ潜んでいる。エージェント同士の頻繁な通信は計算コストと複雑さを押し上げる。さらに厄介なのは「創発的な行動」が現れることだ。つまり誰もプログラムしていないのに勝手に出てくる振る舞いのことで、ちょっとした変更がシステム全体の動き方に予測不能な影響を与えかねない。対処の考え方は命令を厳格に下すことではなく、協調のための枠組みをきちんと立てることだ——役割分担、問題解決の方法、投入予算を定義し、同時にエージェントがタスクを際限なくたらい回しにすることを防ぎ、対立解消のメカニズムも整えておく。
この2種類のマルチエージェントパターンを並べてみれば、違いが一目でわかる。下のタブをクリックして2種類の構造を切り替えて見てみよう。
ツリー状の指揮系統。頂点に監督者が1人、下層に専門家がいる。タスクは上から下へ割り振られ、結果は下から上へ集約される。
- 明確な責任の連鎖があり、監査・追跡が可能
- 監督者が業務ルールを強制でき、承認機能を保持できる
- 柔軟性と監督の両方が必要な、カスタマーサポート・コンテンツ制作・データ分析といった中程度の制御性が求められる場面に適する
メッシュ状のピア接続。エージェントはすべて対等で、誰とでも直接対話でき、議論を通じて自ら合意に至る。
- 中心的な意思決定者がおらず、協調はやり取りの中から創発する
- 行動はより予測しづらくなるが、これは探索的な場面では欠陥ではなく特長となる
- リサーチ、ブレインストーミング、複雑な分析といった制御性の要求が低い場面に適する
シーケンシャル vs パラレル：タスクは並んで順番待ちすべきか、同時に走らせるべきか
これまで見てきたのはエージェントが動的に意思決定するパターンだったが、次の2つは事前に書き切られた静的なワークフローオーケストレーション(agentic workflows)であり、エージェントがどんな順序で、どんな条件下でタスクを実行するかを定義する。両者の核心的な違いはひとつだけ——タスクを順番待ちさせるか、同時に走らせるか、だ。
| シーケンシャルワークフロー | パラレルワークフロー | |
|---|---|---|
| 動き方 | 一本の線に沿って順に実行し、各ステップの成果が次のステップの入力になる | 複数の線が同時に実行され、それぞれ独立して結果を出し、最後に統合する |
| 核心的な価値 | 待ち時間と引き換えに精度を上げる——少し時間をかける代わりに、AIの各呼び出しがより焦点の絞られた、間違いにくいシンプルなタスクになる。フローは予測可能で、コストを見積もりやすく、段階ごとにトラブルシューティングできる | 求めるのはスピードと多視点——複数の経路を同時に走らせ、異なる角度から問題をカバーすることで、結論により根拠が持てる |
| 使うべきとき | タスクをきれいに固定のサブタスクに分解でき、明確な線形依存関係があり、監査・追跡が必要な場合(コンプライアンスチェック、承認チェーン、下書き→レビュー→公開) | サブタスクが互いに独立して同時に走らせられ、多視点であることが質を高め、速度が協調コストより重要な場合(多視点が必要なリスク評価、ガードレール審査：あるモデルが作業し別のモデルが不適切なコンテンツを専門にフィルタリングする、複数経路の並行評価) |
| 使うべきでないとき | 数ステップで単一エージェントが片付けられる場合、エージェントに引き継ぎではなく協業が必要な場合、フローに後戻りしての反復が必要な場合 | エージェントが互いの成果の上に積み上げていく必要がある場合、特定の実行順序が必要な場合、共有状態を変更するのに競合解決策がない場合、結果の集約ロジックが複雑すぎてかえって質を落とす場合 |
2種類のフローにはそれぞれ実際の事例が添えられている。シーケンシャルのほうはデータサイエンスのインサイト生成——分析リクエストがまず範囲確定agent(分析タイプを判断しルーティング)を経て、データエンジニアリングagent(データの抽出・クレンジング)に渡り、次に分析agent(統計モデリングを実行するか、複雑なリクエストは人手に転送するとマーク)に渡り、最後に人によるレビューに入る。パラレルのほうは金融リスク評価だ。
評価者-最適化：AI自身に自分の作業を添削させる
これが最後のワークフローで、2つのAIが役割分担し、反復ループの中で品質を基準まで磨き上げる。
1つのAIがコンテンツ生成を担当し、もう1つが専門的に粗探しをし、実行可能なフィードバックを与える。基準に達するまで往復して修正を重ねる——一度きりの生成で済ませるわけではない。ライター1人にエディター1人がつくようなもので、エディターが何度も差し戻し、うなずいて通るまで書き直させ、そこで初めて発表となる。
APIドキュメント生成の事例はこう動く。生成agentがコードベースを分析し、初稿(エンドポイントの説明、パラメータ、サンプル、認証要件)を書く。技術評価agentが実際のコード実装と1つずつ照合し(パラメータの型は正しいか、エンドポイントの網羅は十分か、サンプルは実行できるか)、問題を差し戻す。生成agentがフィードバックを取り込んでまた修正する。
向いている：明確な評価基準があり、反復による磨き込みが目に見える価値をもたらす場面。文学翻訳、安全性要件のあるコード生成、トーンの厳格さが求められる専門文書、多段階の推論と検証が必要なリサーチタスクなど。
向いていない：初稿ですでに基準を満たしている場合、評価基準が主観的で曖昧な場合、時間コストが品質向上のメリットを上回る場合。また、即応性が求められるリアルタイムアプリケーション、基本的な分類のようなシンプルなタスク、token予算が逼迫している環境、そして評価者自身に領域の専門性が欠け、意味のあるフィードバックを出せない場合にも使うべきではない。
三問フレームワーク＋実際の進化ロードマップ1本
まずここまで辿ってきた道筋を整理しよう——単一エージェントで足りるなら人を足すな。3種類のシグナル(オープンエンド、領域横断、広域並行)にぶつかって初めてマルチエージェントに切り替える。マルチエージェントに切り替えたら、まず管理者を置くか置かないかを選ぶ。事前に書き切れるフローはワークフローに任せ、書き切れないものだけエージェント自身の判断に残す。この連鎖を突き詰めると、本書で最も価値のある部分に行き着く——3つの必答問題だ。技術的な複雑さを積み上げるのではなく、まずこの3点を考え抜いてから、アーキテクチャを当てはめよう。以下のセレクターは、自分の状況に応じてクリックすれば、どのアーキテクチャを指すかがわかる。
ガイドはさらに4つ目の問いを補っている——深い領域専門性は必要か? 単一領域で確立されたフローがあるなら、専用のSkillsを備えた単一エージェントで十分。複数の異なる領域が協調を必要とする場合(たとえば法務レビューが財務分析と連携する必要がある場合)に初めて、専用Skillsを備えたマルチエージェントに進む。以下がこの三問チェックリストの完全な日本語版だ。項目は原文と一対一で対応しているので、そのまま自分のプロジェクト評価に当てはめられる。
1. どこまでの制御性が必要か？ 高い制御性が必要（コンプライアンス規制、金融取引、安全に関わる操作）→ 単一エージェントかシーケンシャルワークフローから始める 中程度の制御性が必要（カスタマーサポート、コンテンツ制作、データ分析）→ 階層型マルチエージェントシステムを検討する 低い制御性で足りる（リサーチ、ブレインストーミング、複雑な分析）→ 協調型マルチエージェントも実行可能 2. 問題領域はどれだけ複雑か？ 単一領域の問題（プロダクトに関する質問への回答、返品処理、レポート作成）→ 単一エージェントが効率よく処理できる 複数領域だが予測可能（社員のオンボーディング、コンプライアンスフロー、標準的な分析タスク）→ シーケンシャルまたはパラレルワークフロー 複雑でオープンエンドな問題（戦略分析、リサーチプロジェクト、システムのトラブルシューティング）→ マルチエージェントアーキテクチャ 3. リソース制約は何か？ 予算／tokenに限りがある → 単一エージェント、または入念に設計されたパラレルワークフロー 市場投入までの時間が厳しい → まず単一エージェントを使い、進化の道筋を計画する 長期的な戦略投資 → 最初からモジュール式の進化を前提に設計する 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本：あるEコマースプラットフォームの5段階
締めくくりは1つの実際の道筋——あるEコマースプラットフォームが単一エージェントからマルチエージェントへと進んだ5つの段階だ。いきなり複雑なシステムを組み上げるのではなく、各段階で測定可能な価値が確認できてから複雑さを足していく。
本番システムはしばしばハイブリッドアーキテクチャへと進化していく。階層監督の中にパラレル処理を組み込んだり、シーケンシャルワークフローに動的ルーティングを持たせたり、単一エージェントが境界事例にぶつかったときに自動でマルチエージェントシステムを起動させたりする。ビジネス上の価値が複雑さに見合うとき、これらの組み合わせは単一のパターンだけでは届かない能力を解き放つ。
着地点は常に変わらない——アーキテクチャは要求に合わせて進化させ、シンプルに始め、すべてを計測し、複雑さが測定可能な価値をもたらす場合にのみ足していく。今日における最良のアーキテクチャとは、現在の要件を満たしつつ、明日への道も残しておける、最もシンプルな案のことだ。 Building Effective AI Agents · Anthropic