【Anthropic Tokyo Builder Summit レポート】効率的なエージェント構築のベストプラクティス
2025年10月28日、八芳園で開催された Anthropic Tokyo Builder Summit にて、Anthropic の Stephanie Pang 氏（Claude Skills エンジニア）と Hannah Li 氏（ファインチューニングエンジニア）による「効率的なエージェントの構築」セッションが行われました。本記事では、エージェント構築における最新のベストプラクティスについて、セッションの内容をまとめます。
1. エージェント構築前のチェックリスト
エージェントはすべてのユースケースに適しているわけではありません。構築前に以下の4つの質問を確認することが重要です。
そのタスクは十分に複雑か？
タスクがディシジョンツリーとして分解できる場合、エージェントよりもアルゴリズムやワークフローとして実装する方が効果的です。ワークフローの方がコスト効率が良く、制御も容易です。
そのタスクには十分に価値があるか？
例えば、大量のカスタマーサポートケースで現状1タスクあたり10セント程度しかコストがかかっていないとします。10セントをトークン数に換算すると30,000トークン程度にしかならず、このトークン数ではエージェントに必要な十分なターン数を実行できません。このような場合は、一般的なシナリオをワークフローで処理し、本当に複雑なケースだけをエージェントに回すことを検討すべきです。
タスクの全ての部分が実行可能か？
エージェントループのボトルネックは、開発者にとってコストと待機時間の増加につながります。エージェントがタスクにおいて頻繁に失敗する場合、タスクのスコープを縮小したり、より小さなサブタスクに分割したりすることを検討してください。
エラーまたはエラー発見にかかるコストは？
エラーが高リスクであったり発見が困難な場合、エージェントを長時間自律的に動作させることは難しくなります。対策として、エージェントに読み取り専用アクセスのみを与えたり、Human-in-the-loopパラダイムを採用して、より頻繁に許可を求めるようにすることができます。ただし、これらの制限はエージェントのスケーラビリティを制限することになります。
具体例： コーディングタスク
コーディングはエージェントに適したユースケースとして代表的なものです。
- 複雑性：デザインからPRまでのプロセスはディシジョンツリーに収まらない ✓
- 価値：良いコードを書くことには高い価値がある ✓
- 実行可能性：最新のClaudeモデルはコーディングに優れている ✓
- エラーコスト：ユニットテストやCIで検証可能 ✓
これらの理由から、Claudeを使ったコーディングエージェントが急増しています。
2. ツール設計のベストプラクティス
基本設計原則
ツールは明確で理解しやすいものである必要があります。人間に対してタスクを振る時と同様に、環境やタスクについて詳しくない相手にツールを渡す際には、そのツールをいつ、どのように呼び出すべきかを簡単に理解できるように気を使う必要があります。
また、パラメータのスキーマと型を慎重に検討することが重要です。例えば、数値を想定しているパラメータは、文字列ではなく整数や浮動小数点数として型付けすべきです。
ツール出力の設計
- エラー出力: エラー発生時には、エージェントが何が問題だったかを理解し、自力でデバッグ・改善できるだけの十分な情報を含める
- 成功出力: 状態の変化を含めることで、エージェントが次のステップを計画できるようにする
ツールの階層化 (tool scaffolding)
複雑なタスクでは多くのツールが必要になりますが、エージェントが同時に大量のツールを扱うにはまだまだ課題があります。エージェントが適切なツールを発見できるようにするには以下のようなテクニックがあります。
- 動的ツール発見: すべてのツールをコンテキストウィンドウにリストするのではなく、高レベルのツールセットや MCP（Model Context Protocol）を提示し、Claude がそれらを「ダブルクリック」して詳細なツールを確認できるようにする。
- Tool Search Tool: メタツールとして、すべてのツールの中から最も関連性の高いものを検索できる機能を提供する。
Claude を活用した設計
ツール設計時に Claude をコードレビュアーとして活用し、作成したツールが理解しやすく使いやすいかをチェックさせることも有効です。Claude と繰り返しやり取りしながら改善することで、より良い設計に到達できます。
また、エージェントが自律的に長時間作業できるようにするには、自己検証ツールを提供することが重要です。これは、エージェントが作業の途中で自分の出力や進捗を確認できるツールのことです。
例えば、コーディングエージェントの場合、以下のような検証を行います。
- ユニットテストを実行して、書いたコードが正しく動作するか確認
- リンターを実行して、コードスタイルをチェック
- ビルドツールで、変更がコンパイルエラーを起こしていないか確認
これらのツールがあることで、エージェントは「ユーザーに結果を返して確認してもらう」という往復を減らし、自律的に作業を続けることができます。検証ツールがない場合、エージェントは各ステップでユーザーの確認を待つ必要があり、自律性とスケーラビリティが制限されます。
3. プロンプト設計とコンテキスト管理
システムプロンプトの設計
効果的なシステムプロンプトは、エージェントがタスクと従うべきルールを理解するために不可欠です。Anthropic Workbenchを使用してClaudeと繰り返し対話し、システムプロンプトのどの部分を改善できるかを理解することが有効です。
コンテキスト腐敗 （Context Rot） の問題
複雑なタスクでは、コンテキストが非常に長くなり、コンテキストウィンドウの限界に近づきます。その結果、 コンテキスト腐敗 (context rot) と呼ばれる現象が発生し、最終的なコンテキストウィンドウに達していないとしてもエージェントのパフォーマンスが低下します。
コンテキスト腐敗の主な原因としては以下のようなものがあります。
- コンテキスト汚染 （Context Contamination）: エージェントがハルシネーションを起こしたり、結果にエラーを含めたりした場合、それらを参照し続けてコンテキストを汚染する可能性がある。
- コンテキストの散漫 （Context Distraction）: エージェントが最新のステップに過度に注目し、システムプロンプトの指示やトレーニングで学習した内容を軽視することがある。
コンテキストエンジニアリングの4原則
Anthropicが最近リリースしたコンテキストエンジニアリング機能により、開発者はエージェントの各ターンでコンテキストを管理できます。
- キュレーション：タスク完了に関連するものだけにコンテキストを絞る
- 永続化：メモリツールなどを使って、複数ターンにわたってコンテキストを保存する
- 分離：既存のタスクを複数のサブタスクに分割し、それぞれのコンテキストを独立させる
- 圧縮：コンテキストウィンドウの限界に達した場合、エージェントがタスクを継続するために必要な最も関連性の高いトークンのみを保持する
これらの機能は、Tool Result Clearing、Memory、Compactionなどの形でCloud Developer Platformで利用可能です。
プロンプトキャッシュの活用
タスクにおいてClaudeが長いコンテキストでも性能低下せず、コンテキストウィンドウの上限にも達していない場合は、プロンプトキャッシュの利用を検討すべきです。これはコストとレイテンシーを最適化するための手段であり、複数のエージェントターンにわたってコンテキストが同じままであることを前提としています。
4. テストと評価
よくある失敗パターン
実証的なテストの不実施・データの品質とインフラの見過ごし
本番のタスクとは異なるおもちゃのプロンプトやおもちゃのデータを使用すると、データ品質やインフラの問題を見落としてしまうかもしれません。本来セットアップの問題だったものが、エージェント技術自体の失敗として扱われてしまうこともあります。
間違った指標に焦点を当てる
例えば、コーディングエージェントのように知能が指数関数的な利益をもたらす場合に、レイテンシーを過度に重視してしまうことがあります。
主観的な「雰囲気」評価への依存
再実行可能なテストケースを整備せず、エージェントとの一回限りのやり取りに基づく主観的な「雰囲気」だけに頼ってしまうことがあります。
推奨される評価方法
- 包括的な評価フレームワークの導入: 実世界で遭遇すると予想されるすべてのケースを完全にカバーする
- テレメトリーへの投資: エージェントが失敗・成功しているケースへの可観測性を確保
- 実世界のユースケースを用いたテストの実施: 最も重要な要素
5. 実践例： 3つのエージェントタイプ
コーディングエージェント
環境：ファイルシステムとターミナル
ツール：grep、bash、edit file、write file など
ツール選択時の注意点
- タスクを遂行するための適切なツールを与えるが、不要なアクセスは与えない
- フロントエンドタスクの場合、UIを視覚的にテストできるMCPやツールを検討
- bashツールには任意のアクセスを与えず、必要なファイルシステム部分のみにアクセスを制限
プロンプト
- コーディングスタイル
- リポジトリの構造に関する詳細
- ルールやガードレール（ファイルを削除しない、許可なくgitにpushしないなど）
- 推奨される動作（テストを先に書くなど）
動作フロー
- ユーザーがターミナルからクエリを入力
- LLMがタスクを洗練・明確化
- コンテキストを取得し、ツール呼び出しを開始
- ファイルを検索・読み取り、編集、テストを実行
- 満足のいく結果が得られるまで繰り返し
- 人間に出力を返す（変更されたファイルのリスト、合格したテストなど）
スケーリング
より大きなタスクを与えるにつれてコンテキストが増大するため、メモリやコンテキスト編集機能の追加を検討する。
コンピュータ使用エージェント
環境：コンピューター
ツール：マウスクリック、キーボード入力、移動など
Claudeはコンピュータを使用できるようにトレーニングされており、その実装はAPIとCloud Developer Platformを通じて利用可能です。
プロンプト
- オペレーティングシステムの種類
- インターネットアクセスの有無などの注意事項
- コンピュータ内での移動方法のヒント
Human-in-the-loop
コンピュータへの自由なアクセスを与えず、特定のアクションの前に許可を求めるようにすることが推奨されます。
動作例
- ユーザーが日本旅行の予約を依頼
- エージェントがブラウザを開き、ホテルやフライトを検索
- スクリーンショットで自分の行動を確認
- ただし、承認を得るまで実際の予約は行わない
検索エージェント
環境：組織データやWeb全体などのテキストの集合
ツール：検索ツール、ドキュメント全体を取得するfetchツール
プロンプト
- アクセス可能なテキストの範囲（Web全体、Web の一部、特定の種類のドキュメントなど）
- ドキュメントの種類（法的文書、ローカルファイルシステムなど）
- 出力形式の指定
出力形式の重要性
「今日のニューヨークの天気」のような単純なクエリと異なり、深いリサーチにおいては、いつエージェントが検索を停止すべきかが不明確です。出力形式を明確にすることで（単一の回答、引用付きの詳細レポート、最も関連性の高い検索結果のリストなど）、エージェントの動作を制御できます。
動作例
- ユーザーがニューヨークのアパートメントについて検索を依頼
- エージェントが一連の検索を実行
- 検索結果に基づいて追加の検索を行うか、Webやファイルシステムからドキュメントを取得
- 情報を統合してニューヨークのアパートメントに関する詳細な回答を作成
6. Anthropic製品での実装例
Claude Code
Claude Codeでは、長時間のコーディングタスクに対応するために以下の機能を実装しています。
- メモリツール：過去に行った作業を記憶
- Claude.mdファイル：カスタムファイルを作成し、異なるリポジトリでのコーディングスタイルやガイドラインを記述
- コンパクションツール：コンテキストウィンドウの終わりに達したときに会話履歴をクリアし、タスクを継続
Deep Research （Claude.ai）
Deep Researchは、低コンテキストで動作するマルチエージェントシステムです。
- メインエージェントが調査タスクを小さなサブタスクに分解
- 複数のサブエージェントを起動し、それぞれに異なるプロンプトを与える
- 各サブエージェントが検索・取得を行い、メインエージェントに情報を返す
- メインエージェントがすべての情報を統合し、ユーザー向けのレポートを生成
まとめ
効率的なエージェントを構築するための重要なポイントは以下のとおりです。
- 適切なユースケースを選ぶ：複雑性、価値、実行可能性、エラーコストの4つの基準でチェック
- 明確なツール設計：理解しやすく、適切なエラー処理と出力を備えたツールを設計
- コンテキスト管理：コンテキスト腐敗を避けるため、キュレーション、永続化、分離、圧縮の4原則を適用
- 堅牢なテストと評価：実世界のユースケースで包括的なテストを実施
これらのベストプラクティスに従うことで、エージェントの成功確率を大幅に高めることができます。
本記事は、2025年10月28日のAnthropic Tokyo Builder Summitでの「効率的なエージェントの構築」セッション（登壇者：Stephanie Pang、Hannah Li）の内容をまとめたものです。
Discussion