効果的なエージェントの構築
原文: Building effective agents - Anthropic Engineering Blog (2024年12月)
| パターン/概念 | Claude Codeで活用可能か | 備考 |
|---|---|---|
| 拡張LLM（基盤） | ✅ 活用可能 | Claude Codeはツール統合、検索、メモリ機能を備えている |
| プロンプトチェーン | ✅ 活用可能 | 複数のプロンプトを順次実行することで実現可能 |
| ルーティング | ⚠️ 部分的 | Claude Code自体が自動ルーティングを行う。ユーザーが明示的に制御することは限定的 |
| 並列化 | ⚠️ 部分的 | Claude Codeは内部で並列ツール呼び出しを行うが、ユーザーが明示的に制御することは困難 |
| オーケストレーター・ワーカー | ✅ 活用可能 | Claude Codeをオーケストレーターとして使い、サブタスクを委譲可能 |
| 評価者・最適化者 | ✅ 活用可能 | 生成→評価→修正のループを手動で実行可能 |
| 自律エージェント | ✅ 活用可能 | Claude Code自体がこのパターンで動作する |
| ツール設計原則 | ✅ 非常に重要 | MCPサーバー構築時に直接適用可能 |
| ACIデザイン | ✅ 非常に重要 | カスタムツール・スキル開発に直接適用可能 |
総評: この記事の知見の大部分はClaude Codeの利用・拡張に直接適用可能です。特にMCPサーバーやスキルを開発する際のツール設計原則は必読です。
概要
Anthropicは、様々な業界でLLMエージェントを構築する数十のチームと協業してきた経験から、重要な知見を得ました。核心的な発見は次のとおりです：
最も成功した実装は、複雑なフレームワークではなく、シンプルで構成可能なパターンを使用している
主要な定義
エージェンティックシステムには2つの異なるアーキテクチャがあります：
- ワークフロー: LLMとツールが事前定義されたコードパスを通じてオーケストレーションされるシステム
- エージェント: LLMが自身のプロセスとツールの使用を動的に指示するシステム
エージェントを使うべき時
まず最もシンプルな解決策を見つけることが重要です。エージェンティックシステムは、レイテンシとコストの増加と引き換えにより良いタスクパフォーマンスを得るものです。
- ワークフロー: 明確に定義されたタスクに適している
- エージェント: 柔軟性とモデル主導の意思決定が大規模に重要な場合に適している
多くのアプリケーションでは、検索機能を備えた単一のLLM呼び出しを最適化するだけで十分です。
フレームワークに関する考慮事項
利用可能なフレームワークには以下があります：
- Claude Agent SDK
- Strands Agents SDK（AWS）
- Rivet
- Vellum
フレームワークは初期セットアップを簡素化しますが、基盤となるプロンプトとレスポンスを隠蔽するためデバッグを複雑にする可能性があります。
推奨事項: LLM APIを直接使用することから始め、フレームワークを採用する前にその基盤となる仕組みを理解してください。
ビルディングブロックとパターン
拡張LLM（基盤）
基本コンポーネントは、LLMと検索、ツール、メモリ機能を組み合わせたものです。シンプルなクライアント実装を通じてサードパーティツールとの統合を可能にするModel Context Protocol（MCP）があります。
重要な仕様: 実装において2つの重要な側面に焦点を当てることを推奨します：
- これらの機能を特定のユースケースに合わせて調整すること
- LLMに対して簡単で、よく文書化されたインターフェースを提供すること
ワークフローパターン
1. プロンプトチェーン
タスクを順次ステップに分解し、各LLM呼び出しが前の出力を処理します。中間ステップにはプログラムによるゲートを設けます。
使用場面:
- 固定サブタスクに分解可能なタスク
- レイテンシと精度のトレードオフが許容される場合
- 各LLM呼び出しをシンプルにしたい場合
具体例:
- マーケティングコピーを生成し、その後別の言語に翻訳する
- ドキュメントのアウトラインを作成し、そのアウトラインが特定の基準を満たしているか確認してから、アウトラインに基づいてドキュメントを作成する
2. ルーティング
入力を分類し、専門化された下流タスクに振り分けます。
使用場面:
- 明確なカテゴリを持つ複雑なタスク
- LLMまたは従来モデルで正確な分類が可能な場合
- 関心事の分離が必要な場合
具体例:
- 異なる種類の顧客サービスクエリ（一般的な質問、返金リクエスト、テクニカルサポート）を異なる下流プロセス、プロンプト、ツールに振り分ける
- 簡単で一般的な質問をClaude Haiku 4.5のような小型でコスト効率の良いモデルにルーティングし、難しい/珍しい質問をClaude Sonnet 4.5のようなより高性能なモデルにルーティングする
3. 並列化
複数のLLMタスクを同時に実行し、プログラムで出力を集約します。
2つのバリエーション:
セクショニング: タスクを独立した並列サブタスクに分割
- 実装例: あるモデルインスタンスがユーザークエリを処理し、別のインスタンスが不適切なコンテンツやリクエストをスクリーニングするガードレールの実装
- 実装例: LLMパフォーマンス評価の自動化（各LLM呼び出しが異なる側面を評価）
投票: 同じタスクを複数回実行し、多様な出力を得る
- 実装例: 脆弱性についてコードをレビューする際、複数の異なるプロンプトがコードをレビューしてフラグを立てる
- 実装例: コンテンツが不適切かどうかを評価する際、複数のプロンプトが異なる側面を評価する
4. オーケストレーター・ワーカー
中央のLLMがタスクを動的に分解し、ワーカーLLMに委譲して結果を統合します。
使用場面:
- 予測不可能なサブタスクを持つ複雑なタスク
- 柔軟性が必要な場合（サブタスクはオーケストレーターによって決定）
- 並列化とは異なり、事前定義されていない場合
具体例:
- 毎回複数のファイルに複雑な変更を加えるコーディング製品
- 複数のソースから情報を収集・分析する検索タスク
5. 評価者・最適化者
一方のLLMがレスポンスを生成し、もう一方がループ内で評価とフィードバックを提供します。
使用場面:
- 明確な評価基準が存在する場合
- 反復的な改善が測定可能な価値を提供する場合
- フィードバックによってLLMのレスポンスが明らかに改善される場合
具体例:
- 文学翻訳：翻訳者LLMが最初に捉えきれないニュアンスがあるが、評価者LLMが有用な批評を提供できる場合
- 複雑な検索タスク：包括的な情報を収集するために複数ラウンドの検索と分析が必要で、評価者がさらなる検索が必要かどうかを判断する場合
自律エージェント
エージェントは初期タスクの明確化を受けた後、独立して動作し、必要に応じて追加情報や判断を求めて戻ってくることがあります。
主要な特徴:
- ユーザーコマンドまたは対話的な議論から開始
- タスクの明確化後は独立して動作
- 各ステップで環境からの「グラウンドトゥルース」を取得
- チェックポイントで人間のフィードバックをサポート
使用場面:
- 予測不可能なステップ要件を持つオープンエンドな問題
- 固定パスをハードコードできない場合
- モデルの意思決定への信頼が必要な場合
- 制御された環境でのタスクのスケーリング
実装に関する注記: 「エージェントは洗練されたタスクを処理できますが、その実装は多くの場合シンプルです。基本的には、環境からのフィードバックに基づいてループ内でツールを使用するLLMにすぎません。」
具体例:
- タスク説明に基づいて多くのファイルを編集するSWE-benchタスクを解決するコーディングエージェント
- Claudeがコンピュータを使用してタスクを達成する（コンピュータ使用の参照実装）
実践的なアプリケーション
カスタマーサポート
エージェントは自然にチャットボットインターフェースとツール統合を組み合わせ、顧客データ、注文履歴、ナレッジベースへのアクセスを可能にします。成功した解決に対してのみ課金する使用量ベースの価格モデルを採用している企業もあります。
コーディングエージェント
ソフトウェア開発は以下の点でエージェントに適しています：
- 自動テストによる検証可能なソリューション
- テスト結果を使用した反復的な改善
- 明確に定義された問題空間
- 客観的な品質測定
Anthropicの実装は、SWE-bench Verifiedベンチマークを通じて実際のGitHub issueを解決しますが、人間によるレビューは引き続き不可欠です。
コア実装原則
- エージェント設計のシンプルさを維持する
- 明示的な計画ステップを通じて透明性を優先する
- 徹底したツール文書化とテストを通じてエージェント・コンピュータ・インターフェース（ACI）を慎重に作成する
ツールエンジニアリング
ツールは、全体的なプロンプトと同等のプロンプトエンジニアリングの労力を費やす価値があります。
フォーマット選択の原則
- 「モデルが行き詰まる前に考えるのに十分なトークンを与える」
- 「フォーマットをモデルがインターネット上のテキストで自然に見たものに近づける」
- 「数千行のコードの正確なカウントを維持する必要があるなど、フォーマットのオーバーヘッドがないことを確認する」
エージェント・コンピュータ・インターフェース（ACI）設計アプローチ
モデルの立場に立つ: ツールの使用方法が説明とパラメータから明らかであることを確認します。使用例、エッジケース、入力フォーマットの要件、他のツールとの明確な境界を含めてください。
パラメータの命名: 説明を曖昧でないものにし、「ジュニア開発者向けのドキュメントストリング」として扱います。
テスト: 「ワークベンチで多くのサンプル入力を実行し、モデルがどのようなミスをするかを確認して反復する」
エラー防止: 「ツールをポカヨケする。ミスをしにくいように引数を変更する」
実例: 「実際には、全体的なプロンプトよりもツールの最適化に多くの時間を費やしました。例えば、エージェントがルートディレクトリから移動した後、相対ファイルパスを使用するツールでモデルがミスをすることがわかりました。これを修正するために、ツールを常に絶対ファイルパスを要求するように変更しました。そして、モデルがこの方法を完璧に使用することがわかりました。」
成功のためのフレームワーク
全体的なメッセージ：
LLM空間での成功は、最も洗練されたシステムを構築することではありません。ニーズに合った適切なシステムを構築することです。
シンプルに始め、評価を通じて最適化し、シンプルなアプローチが明らかに不足している場合にのみ複雑さを導入してください。フレームワークはクイックスタートを可能にしますが、本番デプロイの前に徹底的に理解しておく必要があります。
参考リンク
- 原文記事 - Anthropic Engineering Blog
- Claude Agent SDK - Anthropic公式SDK
- Model Context Protocol (MCP) - サードパーティツール統合のためのプロトコル