第1章 エージェントアーキテクチャ

学習目標

• ワークフローとエージェントの違いを説明し、一つのシステム内で両者が混在する箇所を見つけます。
• プロンプトチェイニング・ルーティング・並列化・オーケストレーター-ワーカー・評価者-オプティマイザーの適用条件と失敗の傾向を区別します。
• マルチエージェント構成がコストを増やす原因を説明し、成功したタスクあたりのコストで導入を判断します。
• handoffとagent-as-tool、LLMオーケストレーションとコードオーケストレーションから適切な接続方式を選びます。
• 最も単純な構成から出発し、根拠が得られたときだけ複雑度を上げる判断手順を適用します。

はじめに

あるチームが顧客問い合わせの処理を「エージェントで」作り直しました。モデルが自らツールを選び、必要なら別のエージェントに仕事を渡す構成です。デモは見事でした。ところが運用開始から1か月で三つの不満が出ました。同じ質問でも処理経路が毎回違って再現できず、応答が遅くなり、請求額が予想の3倍になったのです。ログを開くと、問い合わせの大半は処理順序がいつも同じ定型リクエストでした。決まった路線を走ればよい仕事に、毎回タクシーを呼んで道を尋ねていたわけです。

この章では、こうした失敗を避ける方法を扱います。ワークフローとエージェントを区別し、エージェントが必要な業務を見極めてから、五つのワークフローパターンと自律・マルチエージェントのコストを分解します。続いて、エージェントの接続方式と最も単純な構成から始める判断手順を整理し、「さらに深く」では混合設計と相関した誤りを見ていきます。

重要な概念

ワークフローとエージェント

Anthropicの「Building effective agents」は、両者を次のように分けています。ワークフローは、LLMとツールがあらかじめ決められたコードの経路で連携するシステムで、エージェントは、LLMが自らの進め方とツールの使い方を動的に決めるシステムです。同じ記事は、ワークフローは明確に定義されたタスクに予測可能性と一貫性をもたらし、エージェントは大規模な運用で柔軟性とモデル主導の判断が必要な場合に適していると整理しています。

ワークフローが決まった路線を走るバスだとすれば、エージェントは行き先だけを聞いて道を選ぶタクシーです。路線が決まっている仕事にタクシーを呼べば、コストが増えるうえに経路も予測しにくくなります。反対に、路地ごとに道が違う仕事でバスに固執すると、乗客の目的地にたどり着けません。

この区別はシステム全体に貼るラベルではありません。一つのシステム内でも、段階によって次の行動を決める主体は異なります。問い合わせの分類と権限確認はコードが決め、分類された問い合わせの一部の調査だけをモデル自身が進める、といった形です。設計書には「このシステムはエージェントである」ではなく、「この段階の次の行動を誰が決めるか」を書く必要があります。

エージェントが必要な業務

エージェントは、レイテンシとコストを代償に、より高いタスク性能を得る選択です。Anthropicは、最も単純な解決策を先に探し、必要なときだけ複雑さを上げるよう勧めています。また、多くのアプリケーションでは、検索と例を付けた単一のLLM呼び出しを最適化すれば、おおむね十分だとしています。

OpenAIの「A practical guide to building agents」は、エージェントの導入を検討する業務の基準を三つ挙げています。

ガイドは、まずこの基準を明確に満たすか確認し、満たさなければ決定的（deterministic）な解決策で十分な場合があると付け加えています。決定的とは、同じ入力に対し常に同じ経路と結果を返すという意味です。決まった書式のファイルを検証してアップロードする仕事のようにルールが単純で安定していれば、通常のコードのほうがエージェントより安く正確です。

拡張LLMとエージェントループ

どの構成も、基本となる部品は同じです。Anthropicは、検索・ツール・メモリなどの拡張機能を備えたLLMを拡張LLM（Augmented LLM）と呼びます。OpenAIのガイドも、エージェントをモデル、ツール、指示という三つの要素で説明します。ツールはさらに三種類に分かれます。文脈と情報を取得するデータツール、外部システムに働きかけるアクションツール、別のエージェントをツールとして呼ぶオーケストレーションツールです。

エージェントは、これらの部品をループで動かします。モデルが次の行動を選び、ツールを実行し、その結果をモデルに戻します。Anthropicは、各段階で環境から実際の結果（同社の表現では「ground truth」）、例えばツールの結果やコードの実行結果を得て進行を判断すべきだと説明しています。また、チェックポイントや行き詰まった箇所で、人のフィードバックを得るために停止できます。実際の結果ではなくモデルの推測だけでループが回ると、誤りが蓄積します。

プロンプトチェイニングとゲート

プロンプトチェイニングはタスクを一連の固定されたサブステップに分割し、前の呼び出しの出力を次の呼び出しの入力に渡します。段階の間には、コードによる検査、つまりゲートを置けます。Anthropicの例は、マーケティングコピーの作成と翻訳、概要を作って基準に合うか確認してから本文を書く処理です。タスクを固定された段階にきれいに分けられる場合に使います。

チェイニングの設計では、まず段階間のデータ契約を決めます。前の段階が何をどの形式で渡し、次の段階が何を前提にするかをスキーマで固定します。

1. 各段階の出力スキーマを決める（フィールド、単位、許容範囲）。
2. ゲートでスキーマと業務ルールをコードで検査する。
3. 検査に失敗したら、その段階だけを再実行するか、人に引き継ぐ。
4. 段階ごとのレイテンシを合計し、全体のレイテンシ予算に収まるか確認する。

チェイニングの代表的な失敗は誤りの伝播です。最初の段階で単位を読み違えると、後の段階はその数字でもっともらしい文章を書きます。ゲートはこの伝播を断つ装置です。また、段階が増えるほどレイテンシが加算されるため、分割の利点（呼び出しごとの集中度）がレイテンシのコストを上回るか検討する必要があります。

ルーティング

ルーティングは入力を分類し、専門化された後続処理に送ります。別々に扱ったほうがよい明確なカテゴリーがある場合に使います。Anthropicは、顧客問い合わせを種類ごとに分ける例と、簡単な質問は小さく高速なモデルに、難しい質問はより強力なモデルに送る例を挙げています。

ルーターの設計で精度と同じくらい重要なのが、誤分類のコストです。返金の問い合わせを一般案内に誤って送る場合と、一般案内を返金処理に送る場合では被害が異なります。そのため、ルーターでは次も併せて設計します。

分類自体には、ルール、小さなモデル、構造化出力を返すLLM呼び出しのどれを使っても構いません。カテゴリーが安定していればコードや小さなモデルが安く、境界が自然言語のニュアンスに依存するならLLMによる分類が適しています。

並列化：セクショニングと投票

並列化には二つの変形があります。セクショニング（sectioning）は互いに独立したサブタスクを同時に実行し、投票（voting）は同じタスクを複数回実行して複数の出力を集めます。Anthropicはセクショニングの例として、一つのモデルが回答を生成する間に別のモデルが不適切なリクエストを排除するガードレール構成を挙げています。投票の例は、複数のプロンプトでそれぞれコードの脆弱性を探す構成や、異なる閾値でコンテンツの適合性を判定する構成です。速度を上げたいときや、複数の観点と試行で信頼性の高い結果を得たいときに使います。

並列化の効果を計算するときは、クリティカルパスを見ます。全体の時間は、最も時間がかかる経路と結果を統合する時間で決まります。ワーカーを10個同時に起動しても、全体の時間は最も遅いワーカーの実行時間と結果の集約にかかる時間の合計より短くなりません。また、同時実行数は外部APIの上限に制限される場合があり、一つのワーカーが失敗した際に部分的な結果を使うか、全体を再実行するかも事前に決める必要があります。

投票は呼び出し数に応じてコストが増えます。判断があいまいで、一度の誤りのコストが大きい箇所に限定してください。

オーケストレーター-ワーカー

オーケストレーター-ワーカーは、中央のLLMがタスクを動的に分割してワーカーLLMに任せ、結果を統合する構成です。並列化と見た目は似ていますが、決定的な違いがあります。並列化は設計時にサブタスクが決まっているのに対し、オーケストレーター-ワーカーは入力を見るまでサブタスクを予測できません。Anthropicの例は、複数のファイルを修正するコーディングツールと、複数の出典を調べる検索タスクです。

このパターンの成否は委任契約で決まります。Anthropicのリサーチシステムの記事では、サブエージェントごとに目標、出力形式、使うツールと出典に関する指示、明確なタスク境界が必要だとしています。指示があいまいなために、3個のサブエージェントのうち2個が同じサプライチェーンのテーマを重複調査した例も紹介しています。委任の指示には次の四つを必ず入れてください。

目標：2024〜2026年の韓国内の電気自動車充電料金の政策変更だけを調査する。
出力形式：年・政策名・変更内容・出典URLの列を持つ表。20行以内。
ツールと出典：政府・公的機関のサイトを優先し、ブログの要約は使わない。
境界：海外の政策と充電器の普及統計は別のワーカーが担当する。

さらに、再委任の深さ（ワーカーが別のワーカーを作れるか）とワーカー総数の上限を、コードで制限する必要があります。

評価者-オプティマイザー

評価者-オプティマイザーは、一方の呼び出しが生成を行い、もう一方の呼び出しが評価とフィードバックを返すループです。Anthropicは、評価基準が明確で、反復改善の価値を測定できる場合に使うよう勧めています。条件は二つの点で確認します。人がフィードバックすると結果が実際に改善するか、モデルがそのようなフィードバックを自ら作れるかです。例として、翻訳家の批評のように微妙な違いを捉える必要のある文学翻訳や、評価者が追加調査の要否を判断する複数回の検索が挙げられています。

ループには終わりが必要です。評価者がいつまでも「もう少し」と言い続けることがあるためです。最大反復回数、スコアが上がらなくなったら止める条件、反復間の改善幅の下限をコードに置きます。収束せずに終了した場合は、最後の結果と評価記録を一緒に残し、人が判断できるようにします。

自律エージェントと停止条件

必要な段階数を予測しにくい、または事前にコードで固定できないオープンエンドの問題には、自律エージェントを使います。Anthropicは、その場合にはモデルの判断をある程度信頼できる必要があり、コストが高く誤りも蓄積し得るため、サンドボックス環境で十分に試験して適切なガードレールを設けるよう勧めています。制御を保つため、最大反復回数などの停止条件を組み込みます。具体的な設計は第5章で扱います。

同じ記事は、エージェント設計の三つの原則を挙げています。設計を単純に保つこと、エージェントの計画段階を明示すること、徹底したツールの文書化と試験によってエージェント-コンピューターインターフェース（ACI）を磨くことです。三つ目の原則が第2章のテーマです。

マルチエージェントのコスト

Anthropicのリサーチシステムの事例では、エージェントはチャットの約4倍、マルチエージェントシステムは約15倍のトークンを使いました。BrowseComp評価の分析では、三つの要因が性能の分散（差）の95%を説明し、トークン使用量だけで約80%を説明しました。残る二つはツール呼び出し回数とモデル選択です。マルチエージェントの利点の多くは「複数のウィンドウにわたって、より多くのトークンを使える」ことから生まれます。

そのため同記事は、マルチエージェントは並列化の余地が大きく、情報が一つのウィンドウに収まらない価値の高いタスクに適し、すべてのエージェントが同じ文脈を共有する必要があるタスクや、エージェント間の依存性が強いタスクには適さないと整理しています。大半のコーディングタスクは、リサーチよりも本当に並列化できる部分が少なく、適合度が低いとも述べています。

コストはトークンだけではありません。

比較指標は総コストではなく、成功したタスクあたりのコストであるべきです。総コストが2倍でも成功率が3倍になれば得になりますし、コストが同じでも成功率が変わらなければ損になります。

オーケストレーション：LLMが決めるか、コードが決めるか

OpenAI Agents SDKのドキュメントは二つの方式を区別します。LLMオーケストレーションはモデルが計画して次の段階を選ぶため、オープンエンドのタスクに適します。コードオーケストレーションは流れをコードで決め、速度・コスト・性能の面でより決定的で予測可能です。ドキュメントが挙げる手法は、構造化出力でタスクを分類して次のエージェントを選ぶこと、あるエージェントの出力を次の入力につなぐこと、評価エージェントが合格を宣言するまでwhileループを回すこと、asyncio.gatherなどの基本機能で独立したエージェントを並列実行することです。

エージェントをつなぐ方法も二つあります。

handoffは一回の実行（ターン）の中で起こり、次のターンをどのエージェントから始めるかは、アプリケーションが実行を呼び出す際に決めます。OpenAIのガイドは同じ区別をマネージャーパターン（エージェントをツールとして呼ぶ）と分散パターン（同僚間のhandoff）と呼びます。マルチエージェントをグラフで見ると、マネージャーパターンの辺はツール呼び出しで、分散パターンの辺は実行を渡すhandoffだと説明しています。一般的な推奨は、まず単一エージェントの能力を最大限に引き出すことです。分割の兆候は二つあります。プロンプトにif-then-elseの分岐が多すぎてテンプレートを拡張しにくい場合と、ツールの多さよりも類似や重複によって誤ったツールを選ぶ場合です。ガイドには、区別が明確な15個以上のツールを扱える実装もあれば、重複する10個未満のツールで迷う実装もあると記されています。

Google ADKのシーケンシャル・ループ・パラレルのワークフローエージェントも、コードオーケストレーションの例です。あらかじめ決めたロジックで動き、オーケストレーションにモデルを使わないため決定的です。ただし、PythonとGoのADK 2.0からは、このテンプレート型のワークフローがグラフベース・動的なワークフローに置き換えられたので、使用する言語とバージョンのドキュメントを確認してください。

最も単純な構成から選ぶ

構成の選択は、はしごを一段ずつ上るようなものです。下の段で失敗が測定されたときだけ、上の段に進みます。

判断はアーキテクチャ決定記録（ADR）として残します。ADRは、何をなぜ選んだかを記す短い文書です。比較した案（少なくとも一段下の構成）、同じ課題セットで測定した品質・レイテンシ・コスト、採用しなかった案と理由、判断を見直す条件を書きます。半年後に誰かが「なぜこんなに複雑なのか」と尋ねたときの答えになる文書であり、反対に「もう単純化してよい」という根拠もここから得られます。

さらに深く

骨格はコード、判断はモデル

実務で最もよく使われ、堅牢な構成は、ワークフローとエージェントの混合です。状態遷移、業務ルール、権限、予算はコードが管理し、解釈・計画・文章生成のようにルールで表しにくい判断だけをモデルに任せます。たとえるなら、線路はコードが敷き、各駅で乗客に何を案内するかはモデルが決める構成です。

この構成の中心となるルールは、提案と実行の分離です。モデルは「次に返金ツールをこの引数で呼ぼう」と提案し、コードは現在の状態で許されるか、予算内か、承認が必要かを検査してから実行します。モデルが間違えたりだまされたりしても、コードの検査が被害を防ぎます。一方、すべての分岐をコードで固定すると業務ルールが変わるたびに修正が必要になるため、判断の余地は広く取りつつ、出口に検問を置きます。

同意は検証ではない

マルチエージェントや投票の構成で「三つのエージェントがすべて同じ答えを出した」という事実は、思ったほど強い証拠ではありません。同じモデル、同系統のプロンプト、同じ検索結果を使うエージェントは、同じように間違えます。これを相関した誤りといいます。同じ誤報を読んだ3人が口をそろえても、誤報が事実にはならないのと同じです。

検証の力は独立性から生まれます。役割よりも根拠を分ける必要があります。異なる出典を参照させる、生成とは別の方法（コード検査、原文との照合）で確認する、一つのエージェントには反証だけを探させる、といった方法です。そして投票結果を使う前に、評価セットで「単一呼び出しより実際に誤りが減ったか」を測定します。

フレームワークを使うとき

エージェントのフレームワークは導入を容易にします。しかしAnthropicは、下にあるプロンプトと応答を隠す抽象化層によってデバッグが難しくなり、単純な構成で十分な場合も複雑さを加えたくなると指摘しています。そのうえで、LLM APIを直接使うことから始め、フレームワークを使うならその内部実装を理解するよう勧めています。

実務の基準は一つです。モデルに実際に渡されるプロンプト、ツール定義、ツール結果を、いつでも原文のまま確認できなければなりません。まずトレーシング（第4章）とリクエストログで、この可視性を確保してください。

実務の場面

ぬくもりの道：定型リクエストにタクシーを呼ばない

旅行プラットフォーム「ぬくもりの道」は、旅程のおすすめ機能を一つの自律エージェントで作りました。エージェントは航空券・宿泊・観光地のツールを行き来し、平均23回のツール呼び出し、応答まで40秒を要し、同じリクエストでも経路が毎回異なっていました。

チームはリクエストログ2,000件を分類しました。87%は「都市・期間・予算」が指定された定型リクエストで、処理は航空券・宿泊の検索 → 旅程の下書き → 予算検査とほぼ同じでした。「両親と行けそうな静かな場所」のようなオープンなリクエストは13%だけでした。

案は三つありました。第一は、より強力なモデルへの変更です。経路の不安定さとコストの問題が残るため却下しました。第二は、全リクエストを固定のチェイニングに変える案です。試行20件でオープンなリクエストの品質低下が確認され、却下しました。第三は、一度の分類呼び出しで両者を分けるルーティングを置き、定型リクエストは航空券・宿泊を並列検索する固定のチェイニングとコードによる予算ゲートに送り、オープンなリクエストだけを最大ターン数を決めたエージェントに送る案です。チームは第三案を選び、分類の確信度が低いリクエストはエージェント側に送って品質低下のリスクを抑えました。

定型リクエストの応答時間は9秒に短縮され、リクエストあたりのコストは60%以上下がり、オープンなリクエストの品質は評価セット上で変わりませんでした。ADRには「オープンなリクエストの割合が30%を超えたら構成を再検討する」という条件を残しました。根拠は「エージェントが悪い」ということではありません。予測可能な多数のリクエストに、予測不可能な少数のための構成を使っていた点にありました。

松風エネルギー：リレー式エージェント構成を取り除く

都市ガス会社「松風エネルギー」の顧客品質チームは、毎週、苦情の原因を分析する報告書を作成しています。当初は、収集・分析・執筆・レビューの四つのエージェントがリレーのように順番に仕事を渡す構成でした。全エージェントが同じ週次の苦情データ約4,000件を読み直し、報告書1本のトークンは単一エージェントの試作品の7倍でした。品質スコアは試作品より少し高かったものの、レビューエージェントが執筆エージェントの結論をほぼそのまま承認していることが、トランスクリプトから明らかになりました。

チームは同じ30週分の課題で、従来のリレー構成、単一エージェント、混合構成の三つを比較しました。混合構成では収集と分類をコードと小さなモデルのルーターで処理し、原因分析だけを地域別ワーカーに分けて並列調査させました。執筆は評価基準表が明確な評価者-オプティマイザーループ（最大3回）で行いました。

その結果、混合構成の成功した報告書あたりのコストはリレー構成の3分の1で、品質は同等以上でした。レビューエージェントは取り除きました。同じデータを見た同じモデルの「同意」が検証として機能していなかったからです。代わりに、報告書の数値はコードで元データと照合しました。採用しなかった案は「エージェント数は維持し、モデルだけを小さくする」でした。コストは減っても、重複した読み込みと調整コストという構造的な原因が残ると判断したためです。

間違えやすいポイント

1. 「エージェントはワークフローより常に優れている」 デモが印象的だと、より賢い構成に見えます。しかし自律性にはコスト、レイテンシ、予測不可能性が伴います。段階が固定された仕事では、ワークフローのほうが速く、安く、再現可能です。
2. 「専門エージェントを多く置くほど品質が上がる」 人の組織のように分業すれば専門性が生まれそうですが、性能向上の多くはトークンを多く使った結果です。文脈の共有と依存性が大きいタスクでは、調整コストが利点を上回ります。
3. 「handoffで渡せば結果が元のエージェントに戻る」 関数呼び出しに見えるため誤解しがちですが、handoffは制御権を渡します。結果を受け取って続けて使いたいなら、agent-as-toolが適切です。
4. 「並列実行すれば全体時間はワーカー数で割った分だけ減る」 割り算で見積もりがちですが、全体時間はクリティカルパスと統合段階で決まります。まず依存関係と外部の上限を描きます。
5. 「複数のエージェントが同意すれば正しい答えだ」 多数決は信頼できそうですが、同じ根拠を見た同じモデルは同じように間違えます。独立した根拠や別の方法で検証します。
6. 「評価者-オプティマイザーループは品質が上がるまで回せばよい」 反復するほど改善しそうですが、終了条件がなければコストが無限に増え得ます。最大反復回数と改善幅の下限をコードに置きます。
7. 「ツールが多くて混乱するからエージェントを分けるべきだ」 個数は目立つため原因に見えますが、類似性が問題の場合が多くあります。まず名前、パラメーター、説明を直し、それでも解決しない場合に分割します。

ひと目でわかるまとめ

公式ドキュメントで確認する

• Anthropic: Building effective agents — ワークフロー・エージェントの定義、五つのパターンと適用条件、三つの原則、フレームワークに関する助言
• Anthropic: How we built our multi-agent research system — トークンの倍率と性能要因、委任の指示の要素、タスク規模に応じた作業量の調整
• OpenAI: A practical guide to building agents — エージェントを検討する業務の基準、単一エージェント優先、マネージャー・分散パターン
• OpenAI Agents SDK: Agent orchestration — LLM・コードオーケストレーション、handoffとagents as tools
• Google ADK: Workflow agents — 決定的なワークフローエージェントとADK 2.0の変更案内

セルフチェック

1-1. ワークフローとエージェントを分ける基準を一文で書き、一つのシステムに両者が含まれる例を一つ挙げてください。

1-2. 並列化の二つの変形がそれぞれ何を得るためのものか、また投票を全段階のデフォルトにしない理由を説明してください。

1-3. オーケストレーターがサブエージェントに仕事を任せる際、委任の指示に含める四つの要素を挙げ、一つ欠けた場合に生じる症状を一つ説明してください。

1-4. 評価者-オプティマイザーループがコストを無限に使わないよう、ループ外のコードが持つべき仕組みを二つ挙げてください。

1-5. handoffとagent-as-toolについて、会話の制御権と最終回答を出す主体の違いを説明してください。

1-6. AnthropicのBrowseComp分析で、性能分散の大半をトークン使用量が説明したという観察から、導入判断で総コストの代わりに何を比較すべきか説明してください。

1-7. 毎週社内通知50件を読み、部署別の要約を送る機能を設計してください。最も単純な構成、その構成では不十分になったことを示す測定上の兆候、その際に移る次の構成を順番に書いてください。

実習課題