※はじめに（免責事項）
本記事執筆者は英語が得意ではありません。極力丁寧に論文を読み込んで作成しましたが、解釈に誤りが含まれている可能性があります。
正確な情報や詳細なニュアンスについては、必ず情報の裏取り（原典の確認）を行ってください。

昨今のAIトレンドでは「自律型エージェント（Autonomous Agents）」という言葉がバズワード化しており、「何か凄いことを勝手にやってくれる魔法の杖」として期待されがちです。しかし、実務でデータサイエンスやシステム開発に携わっていると、**「自律性が高まれば高まるほど、挙動が予測不能になり、制御不能なエラー（幻覚やループ）に悩まされる」**というジレンマに直面します。

そんな中、Claudeの開発元であるAnthropicが公開した本論文は、「最初から複雑なエージェントを作るな。単純なワークフローから始めよ」という、非常に実用重視（Pragmatic）な提言を行っています。エンジニアリングとしてLLMをどう手なずけるか、その指針として非常に有用だと感じたため、内容を整理しました。

『Building effective agents』を読んで勉強しました。

論文の概要

タイトル: Building effective agents
著者/組織: Anthropic
URL: https://www.anthropic.com/engineering/building-effective-agents
一言でいうと: AI実装の成功の鍵は、複雑な自律エージェントではなく、単純で構成可能（Composable）な「ワークフロー」の積み重ねにある。

1. 拡張LLM・ワークフロー・エージェントの違い

開発において、まず意識すべきはシステムにおける「制御権（Control）」がどこにあるかです。Anthropicは、システムを構築する際に以下の3つのレベルを明確に区別しています。

これらは対立するものではなく、「拡張LLM」を構成要素（ビルディングブロック）とし、それをどう組み合わせるかによって「ワークフロー」や「エージェント」になるという関係性です。

カテゴリ	定義	制御の所在	特徴・適性
拡張LLM (Augmented LLM)	検索機能（RAG）、ツール、メモリなどで強化された単一のLLM呼び出し。	単一の呼び出し	エージェントシステムの最も基本的な構成単位。検索やコンテキスト内での例示（Few-shot）だけで解決できる単純なタスクに向いています。
ワークフロー (Workflows)	事前に定義されたコードパスを通じてLLMとツールが連携するシステム。	コード（人間）	プロセスは固定されており、予測可能性と一貫性が高いのが特徴。手順が明確で、確実に実行される必要がある定型タスク（例：翻訳フロー）に向いています。
エージェント (Agents)	LLMがプロセスやツールの使用を動的に指示し、タスク実行を自律制御するシステム。	LLM（モデル）	モデルが「次になにをするか」を決定するため柔軟性が高い反面、コストと予測不可能性が増します。手順を事前に定義できないオープンエンドな問題に向いています。

核心メッセージ:

"Start with a simple prompt, optimize it, then add complexity only when necessary."
（単純なプロンプトから始め、最適化し、必要な場合にのみ複雑さを加えよ。）

2. エージェントシステム構築のための5つのパターン

複雑なシステムも、基本的には以下のシンプルなパターンの組み合わせ（Building Blocks）で構築可能です。論文では主要な5つのパターンが紹介されています。

パターン名	仕組み	メリット・目的	具体的なユースケース
A. プロンプトチェーン (Prompt Chaining)	タスクを順次ステップに分解し、前の出力を次の入力として使用する。	各ステップのタスクを単純化することで、LLMの精度が向上し、エラーを特定しやすくなる。	・記事構成作成 → 本文執筆 → 翻訳・ドキュメントのアウトライン作成 → 検証 → 執筆
B. ルーティング (Routing)	入力を分類し、最適な後続プロセス（特化プロンプトやツール）へ誘導する。	関心の分離ができる。難易度に応じてモデル（Haiku/Sonnet等）を使い分けることでコスト最適化が可能。	・カスタマーサポート（返金/技術質問の振り分け）・簡単な質問は安価なモデル、複雑な質問は高性能モデルで処理
C. 並列化 (Parallelization)	複数のタスクを同時に実行し、プログラム的に結果を集約する。	セクショニング: 独立タスクの同時処理で高速化。投票: 複数視点を取り入れ、見逃し（False Negative）を防ぐ。	・回答生成と同時にガードレールチェックを行う・コードの脆弱性チェックを複数の異なるプロンプトで行う
D. オーケストレーターとワーカー (Orchestrator-Workers)	中央のLLM（オーケストレーター）がタスクを動的に分解・委譲し、結果を統合する。	サブタスクを事前に定義できない複雑な問題に対し、動的に対応できる柔軟性がある。	・複数のファイルを変更するコーディングタスク・複数のソースから情報を集めて分析する調査
E. 評価者と最適化者 (Evaluator-Optimizer)	生成役（Actor）と評価役（Critic）のループ構造。	人間が推敲するように、フィードバックループを回して品質を反復的に高める。	・翻訳のニュアンス修正・複雑な検索タスク（情報不足なら再検索する判断など）

3. エージェントシステム構築のための5つのパターン（詳細解説）

Anthropicの論文では、複雑なエージェントシステムも、実は**単純なパターンの組み合わせ（Building Blocks）**で構築できると説いています。ここでは、推奨されている5つの基本パターンについて、その仕組みと実装のポイントを詳しく解説します。

A. プロンプトチェーン (Prompt Chaining)

「分割して統治せよ」の基本形

プロンプトチェーンは、一つの大きなタスクを、論理的な順序に従って複数の小さなステップに分解する手法です。前のステップの出力（Output）が、そのまま次のステップの入力（Input）になります。

なぜ有効か？
LLMは一度に多くの指示を与えられると、注意力が散漫になり（幻覚など）、精度が低下する傾向があります。タスクを分解することで、各ステップのLLMは「一つのこと」に集中でき、全体の成功率が劇的に向上します。
実装のポイント
各ステップの間に「ゲート（Gate）」を設けることが可能です。例えば、ステップ1の出力が期待通りかプログラムで判定し、NGならリトライ、OKならステップ2へ進むといった制御を加えることで、エラーの連鎖を防げます。
ユースケース
- マーケティング資料作成：【ステップ1】ターゲット分析 →【ステップ2】キャッチコピー案作成 →【ステップ3】本文執筆 →【ステップ4】多言語翻訳。

B. ルーティング (Routing)

「適材適所」による最適化

ルーティングは、入力されたクエリの内容を分析・分類し、その後の処理ルートを分岐させるパターンです。

なぜ有効か？
すべてのタスクに最高性能（かつ高価・低速）なモデルを使う必要はありません。ルーティングを挟むことで、「単純な質問」と「複雑な推論」を切り分け、コストとレイテンシを最適化できます。また、特定のカテゴリ（例：プログラミング質問）に特化したプロンプトを用意することで、専門性を高めることも可能です。
実装のポイント
ルーター役のLLM自体は、単純な分類タスクを行うだけなので、軽量モデル（Claude 3 Haikuなど）が適しています。
ユースケース
- カスタマーサポート：問い合わせ内容を「返品」「技術トラブル」「契約変更」に分類し、それぞれ専用の対応フロー（または人間の担当者）へ誘導する。

C. 並列化 (Parallelization)

「同時処理」による高速化と信頼性向上

並列化は、LLMに複数のタスクを同時に実行させ、その結果をプログラム的に集約する手法です。大きく分けて「セクショニング（分割）」と「投票（Voting）」の2つのアプローチがあります。

セクショニング (Sectioning):
大きなタスクを独立したサブタスクに分割し、並行して処理します。
- メリット: シーケンシャル（順次）に処理する場合に比べ、処理時間を大幅に短縮できます。
投票 (Voting):
同じタスクを、異なるプロンプトやモデルで複数回実行させます。
- メリット: 「見落とし（False Negative）」を減らし、信頼性を高めることができます。例えば、3つのモデルのうち2つ以上が「有害」と判定した場合のみブロックする、といった多数決ロジックが組めます。

D. オーケストレーターとワーカー (Orchestrator-Workers)

「動的な指揮官」による柔軟な対応

「プロンプトチェーン」が事前に決められた手順（静的）であるのに対し、このパターンでは「オーケストレーター」と呼ばれる中央のLLMが、入力に応じて動的にサブタスクを分解し、それぞれのタスクを「ワーカー」LLMに割り当てます。

なぜ有効か？
「どのようなサブタスクが必要か」が、実行時まで分からないような複雑な問題に対応できます。オーケストレーターは全体の進行管理と結果の統合を担当し、ワーカーは個別の専門タスクに集中します。
実装のポイント
オーケストレーターには高い推論能力を持つ高性能モデル（Claude 3.5 Sonnet/Opusなど）が必要です。また、ワーカーから戻ってきた結果をオーケストレーターが正しく解釈できるよう、入出力のフォーマット（JSONなど）を厳格に定義することが重要です。
ユースケース
- コーディング支援：「機能Xを追加して」という指示に対し、オーケストレーターが「ファイルAの変更」「ファイルBの新規作成」「テストコードの追加」というサブタスクを動的に生成し、実行させる。

E. 評価者と最適化者 (Evaluator-Optimizer)

「推敲」による品質の限界突破

LLMが生成した回答（Draft）に対し、別のLLM（Evaluator）が評価とフィードバックを行い、それに基づいて元のLLM（Optimizer）が修正を行うループ構造です。

なぜ有効か？
人間が文章を書くとき、一度書いて終わりではなく、読み直して推敲することで質を高めます。このプロセスを模倣することで、単発の生成では到達できない高品質な出力を得ることができます。
実装のポイント
「何をもって良しとするか」という評価基準（Criteria）を明確にプロンプトに含めることが成功の鍵です。また、無限ループに陥らないよう、最大反復回数などの停止条件（Stop Condition）を必ず設定する必要があります。
ユースケース
- 高品質翻訳：翻訳結果に対し、「原文のニュアンスが落ちていないか？」「自然な表現か？」を評価させ、合格点が出るまで修正を繰り返す。

4. ACI (Agent-Computer Interface) という考え方

人間向けのUI（HCI）があるように、エージェントにはエージェント向けのインターフェース（ACI）が必要です。

ポカヨケ: 引数ミスを防ぐ設計（例：相対パスではなく絶対パスを強制する）。
フォーマット: モデルにとって扱いやすい形式（JSONよりMarkdownの方がトークン効率や記述ミスにおいて有利な場合がある）を選択する。

個人的感想

データサイエンティストとしての視点から、この論文は「エンジニアリングの基本に立ち返れ」という非常に健全なメッセージだと感じました。

1. 確率的挙動の制御とデバッグ可能性
LLMは本質的に確率的（Probabilistic）なシステムです。完全に自律的なエージェントは、入力 $x$ に対して出力 $y$ が常に変動する可能性があり、実運用時の品質保証（QA）が極めて困難です。
論文で推奨されている「ワークフロー」や「プロンプトチェーン」のアプローチは、この確率的なブラックボックスを、決定論的（Deterministic）なコードで極力ラップして小さく分割する試みと言えます。これにより、各ステップでの単体テストが可能になり、システム全体の堅牢性が劇的に向上します。

2. ルーティングによるコスト対効果の最適化
実務で特に重要なのが「ルーティング」の概念です。すべてのクエリに最高性能のモデル（例：Claude 3.5 SonnetやGPT-4o）を使うと、APIコストが膨大になります。
「クエリの難易度判定」という分類タスクを一層挟むことで、簡単なタスクは安価なモデルに流す。これは機械学習パイプラインにおける**「モデル蒸留」や「カスケード処理」の実装パターン**として非常に理にかなっています。

3. 「評価者（Evaluator）」の重要性
RAGやエージェント開発において、最も頭を悩ませるのは「精度評価」です。「Evaluator-Optimizer」パターンは、推論時に自己評価を行うことで精度を高める手法ですが、これは**「人間のフィードバック（RLHF）」を擬似的に推論時間内（Inference-time）に行っている**とも解釈できます。
ただし、これを行うとトークン消費量が倍増するため、ここでも「本当にその精度が必要か？」というROI（費用対効果）の視点が不可欠になると感じました。

参考文献

出典・ライセンス情報

この記事は、以下の論文を要約・翻訳（または解説）したものです。

タイトル: Building effective agents
著者: Anthropic
ライセンス: (Web記事のため明記なし。詳細は元URL参照)
URL: https://www.anthropic.com/engineering/building-effective-agents