はじめに
昨日、Anthropic主催の「Builder Summit」に参加してきました！🎉
会場はとても活気があり、AI技術の最前線で活躍する開発者や研究者たちが集まっていて、エネルギーに溢れていました。
今回特に印象的だったのが、Anthropicの研究者であるHanna（ハンナ）氏とStephanie（ステファニー）氏による「効率的なエージェントの構築」というセッションです。
登壇者のHanna（ハンナ）氏とStephanie（ステファニー）氏
このセッションでは、効果的なAIエージェントを構築するための最新の推奨事項、ベストプラクティス、そして実世界のユースケースまでが詳しく解説されました。
本記事では、このセッションで学んだ内容を詳しくまとめていきます。
対象読者
- AIエージェントの構築に興味がある方
- Claudeなどの大規模言語モデルを活用した開発を行っている方
- エージェント的な処理をどう実装すべきか悩んでいる方
セッション概要
登壇者：Hanna（ハンナ）、Stephanie（ステファニー）
所属：Anthropic研究者
アジェンダ：
- エージェントとは何か
- エージェント構築のベストプラクティス
- 実世界のユースケースへの適用
それでは、各セクションを詳しく見ていきましょう。
1. エージェントとは何か
LLM活用の進化
LLMの活用方法は、シンプルなものから複雑なものへと進化してきました。
エージェントとは：私たちがどのようにしてここに至ったが
単一のLLM機能
最もシンプルな形態です。
- 顧客が入力 → LLMを呼び出し → 出力をそのままユーザーに返す
- 最も基本的な実装
ワークフロー
- 事前に定義されたコードパターンで編成されたLLMコール
- 複数のLLMコールを並行、連鎖、またはコードを挟んで実行
- すべてのLLMコールを集約して最終出力を形成
エージェント
- より高度な自律性を持つ
- 独自のプロセスやツールの使用を動的に指示できる
- より大きな主体性（agency）と能力を獲得
- 同時に、より大きなコスト、レイテンシー、リスクも伴う
重要なポイント：これら3つはアプリケーション内に同時に存在可能です。エージェントはワークフロー内のノードにもなり得ます。
エージェント的ループ（Agentic Loop）
エージェントの本質は、**「ループの中でツールを使用するLLM」**です。
エージェントループ：計画→実行→反省のサイクル
エージェントは以下の3ステップを繰り返します：
指示（Directive）
↓
┌─────────────────────┐
│ 計画（Plan） │ ← 環境を観察・推論
│ ↓ │
│ 実行（Act） │ ← ツール/MCPで自律的決定
│ ↓ │
│ 反省（Reflect） │ ← フィードバックから学習
└─────────────────────┘
↓
成果（Outcome）
ループの3ステップ
1. 計画（Plan）
- 現在のコンテキストに基づいて推論
- 環境を観察
- 次の行動を決定
2. 実行（Act）
- ツールやMCP（モデル・コンテキスト・プロトコル）を使用
- 目標に沿った自律的な決定
3. 反省（Reflect）
- 環境がどのように更新されたかを確認
- フィードバックから学習
- アプローチを調整
実装例：Claude plays Pokemon
エージェント的ループの実装を、実際のユースケースで見てみましょう。
Claudeがポケモンをプレイ：エージェントループの実践
動作フロー
- 計画：現在のゲーム状態を見て計画（例：「ママに話しかける」）
- 実行：パラメータ「A」で「ボタンを押す」ツールを起動
- 反省：計画がうまくいったか確認
- 次の計画に戻る
実装の詳細
プロンプト、ツール、コアループの関係性
ツール
- 知識ベースの更新
- エミュレータの使用
- ナビゲーター
システムプロンプト
- ポケモンのゲームについて
- 何をすべきかを指示
知識ベース（長期記憶）
- Pythonの辞書のようなもの
- 読み書き可能
- 例：「ピカチュウが好き」といった情報を記憶
会話履歴の管理
- コンテキストウィンドウの終わりに達したら要約してクリア
エージェントの一般的な実装（コード）
エージェントの基本構造は、以下のようなコードで表現できます：
# エージェントの構成要素
environment = ... # エージェントが行動する環境
tools = ... # 環境と対話するためのツール
system_prompt = ... # 目標、制約、振る舞い方
context = ... # 会話履歴、環境、ツール、プロンプトの表現
# エージェントループ
while True:
context = load_context(environment, tools, system_prompt, history)
response = llm.call(context)
if response.has_tool_call:
tool_result = execute_tool(response.tool_call)
context.update(tool_result)
else:
return response.output
このシンプルなループ構造が、エージェントの核となっています。
3つのエージェントタイプの比較
エージェントは、環境・ツール・プロンプトが異なるだけで、すべて同じバックボーン（エージェント的ループ）を共有しています。
より具体的に：環境・ツール・プロンプトの違い
コーディングエージェント
- 環境：ターミナル、ファイルシステム
- ツール：bash, grep, ファイルの読み書き
- プロンプト：コーディングスタイル、ルール
コンピュータ使用エージェント
- 環境：あなたのPC
- ツール：クリック、タイプ、スクリーンショット
- プロンプト：OS情報、操作ヒント
検索エージェント
- 環境：Web、ローカルファイル
- ツール：検索、取得（フェッチ）
- プロンプト：アクセス範囲、出力形式
2. エージェント構築のベストプラクティス
効率的なエージェントを構築するためには、4つの重要な観点があります。
2.1 環境（いつエージェントを構築すべきか）
エージェントはすべてのユースケースに適しているわけではありません。以下のチェックリストで判断しましょう。
チェックリスト：エージェントを構築すべきか
✅ チェックリスト
1. そのタスクは十分に複雑か？
- 決定木に分解できるなら、ワークフローやアルゴリズムの方が効率的
- ワークフローの方がコスト効率が高く、制御も容易
- エージェントを使うのは、決定木で処理できないほど複雑な場合のみ
判断基準：
- いいえ（決定木で対応可能）→ ワークフロー
- はい（決定木では不可能）→ エージェント
2. そのタスクには十分に価値があるか？
- エージェントに投資するコストに見合う価値があるか
- 例：1タスク10セント予算の場合
- 30,000トークンしか買えない
- エージェント的ループを数回回すだけで終わる
- この場合、一般的なシナリオはワークフロー、複雑なものだけエージェントに回す方が合理的
判断基準：
- <0.1ドル以下 → ワークフロー
- 1ドル以上 → エージェント
3. タスクのすべての部分が実行可能か？
- エージェント的ループで頻繁に失敗すると、コストとレイテンシーが増大
- 失敗が多い場合、タスクのスコープを狭める
- 既存のタスクをより小さく、より簡単なサブタスクに分割
判断基準：
- いいえ（失敗が多い）→ 対象範囲を縮小
- はい（実行可能）→ エージェント
4. エラーまたはエラー発見にかかるコストは？
- ハイステークス（重大）なエラーや、発見困難なエラーは問題
- 対策：
- 読み取り専用アクセスのみを与える
- ヒューマン・イン・ザ・ループ（人間の承認を頻繁に求める）
⚠️ 注意：これらの制限はスケーラビリティを制限する
判断基準：
- 高（エラーコストが高い）→ 読み取り専用またはヒューマン・イン・ザ・ループ（人間の関与）
- 低 → エージェント
具体例：コーディング（すべての条件を満たす理想例）
| 基準 | 評価 | 理由 |
|---|---|---|
| ✅ 複雑性 | 高い | デザインドキュメント→PRは決定木では不可能 |
| ✅ 価値 | 高い | 良いコードを書くことには大きな価値 |
| ✅ 実行可能性 | 高い | 最新Claudeモデルはコーディングが得意 |
| ✅ エラーコスト | 低い | ユニットテストやCIで検証可能 |
結論：これらの理由から、コーディングはエージェントの優れたユースケースであり、コーディングエージェントが爆発的に増えている
2.2 ツール設計
基本的な設計原則
明確で理解しやすいツールを設計：
- コンテキストをほとんど持たない人間にツールを渡した場合
- その人が呼び出し方、いつ呼び出すべきかを簡単に理解できるべき
パラメータの設計：
- スキーマや型を慎重に考える
- 例：数値は
stringではなくintegerやfloatとして型付け - これらの慎重な考慮が、エージェントの精度を向上させる
ツールの出力設計
エラー時
- エージェントが何が悪かったかを理解できる十分な情報
- 自らデバッグして次のイテレーションに進めるようにする
成功時
- 発生した可能性のある状態の変化をすべて含める
- エージェントが次のステップを計画できるようにする
ツールスキャフォールディング（Tool Scaffolding）
多数のツールを扱う際、エージェントは苦労します。以下の戦略が有効です：
1. 動的ツール発見（Dynamic Tool Discovery）
- すべてのツールをリストアップせず、高レベルのツールセット（MCP）を提示
- エージェントが必要に応じて「ダブルクリック」して詳細を確認
2. ツール検索ツール（Tool Search Tool）
- メタツールを提供
- 他のすべてのツールの中から最も関連性の高いツールを検索
3. 検証ツール
- エージェントが自律的に動作を検証・テストできるツール
- ユーザーに戻る必要性を減らす
ツール設計のヒント
Claudeを活用：
- ツール作成時、Claudeをコードレビュアーとして使用
- 作成中のツールが理解しやすく使用可能かをチェック
- 反復的なやり取りで納得のいく設計にたどり着く
2.3 プロンプティングとコンテキストエンジニアリング
システムプロンプトの設計
重要性
- エージェントに何を達成してほしいかを伝える
- 指示の形で、通常は自然言語で記述
- 従うべきルールを理解させる上で不可欠
推奨手法
- Anthropic Workbenchを使用
- Claudeと何度もやり取りして改善
- どの部分が改善できるか、どうすればより良い生成ができるかを理解
エージェント的ループの各ターン
初期段階
- システムプロンプト
- 最初のユーザーメッセージ
- ツールの説明
- 追加コンテキスト（検索、アップロードされたドキュメント）
ループの継続
- エージェントが自然言語の応答やツール呼び出しを生成
- ツールの結果（エラーや出力）を処理
- 次に何をすべきかを決定
- コンテキストが更新され、積み上がっていく
コンテキストの腐敗（Context Rot）
問題
- タスクが非常に複雑になると、コンテキストが長くなりすぎる
- コンテキストウィンドウの上限に達する前から、パフォーマンスが低下
原因
1. コンテキストの汚染（Context Contamination）
- エージェントがハルシネーション（幻覚）を起こす
- ツール結果でエラーを犯す
- それらを継続的に参照し続け、コンテキストを汚染
2. コンテキストの散漫（Context Distraction）
- システムプロンプトやトレーニングで学んだことよりも
- コンテキストの最新のステップに集中しすぎる
解決策：コンテキストエンジニアリング
4つの基本原則があります：
1. キュレーション（Curate）
- タスク完了に関連するものだけに厳選
- システムプロンプトとユーザーメッセージを簡潔に
- そのターンで完了すべきことに関連するものだけにする
2. 永続化（Persist）
- エージェントが複数のターンにわたってコンテキストを保存
- 例：メモリツール
3. 分割（Isolate）
- 既存のタスクを複数のサブタスクに分割
- コンテキストを分離
- コンテキストを小さく、関連性の高いものに保つ
4. 圧縮（Compress）
- コンテキストウィンドウの上限に達したとき
- タスク続行に必要な最も関連性の高いトークンだけを保持
Claude開発者プラットフォームで利用可能：
- ツール結果のクリアリング
- メモリ
- コンパクション（圧縮）
プロンプトキャッシングとの使い分け
プロンプトキャッシングを選ぶべき場合：
- コンテキストが長くなってもClaudeの性能が低下しない
- 長いコンテキストウィンドウにさえ達していない
- コストとレイテンシーを最適化したい
- 複数のターンにわたってコンテキストが同じまま
⚠️ 注意：コンテキスト管理は操作が難しい場合がある
2.4 テストと評価
よくある間違い
1. 経験的テストの欠如
- おもちゃのプロンプトやデータを使用
- データ品質やインフラの問題を見落とす
- エージェント自体の失敗と区別できない
2. 間違ったメトリクスへの焦点
- 例：コーディングエージェントでレイテンシーを過度に重視
- 知性（Intelligence）が指数関数的な利益をもたらすことを無視
3. 主観的な「雰囲気」への依存
- 再実行可能なテストスイートを持たない
- 一度きりの対話に頼る
- 「なんとなく良さそう」という評価
ベストプラクティス
1. 包括的な評価スイート
- 実世界で遭遇すると予想されるすべてのケースを網羅
- フルカバレッジを実装
2. テレメトリへの投資
- 失敗と成功の両方に対する可観測性（Observability）
- ログの監視と分析
3. 実世界のユースケースでのテスト
- これが最も重要
- 本番環境に近い条件でテスト
3. 実世界のユースケース
実際のエージェントの実装例を見ていきましょう。
3.1 コーディングエージェント
コーディングエージェントの構成
環境
- ファイルシステム
- ターミナル
ツール
- bash
- grep
- ファイルの読み書き
- 適切なツールを与える（過度なアクセスは避ける）
- アクセスさせたくないものは与えない
プロンプト
コーディングスタイル
ルールやガードレール：
- 例：ファイルを削除しない
- 例：git push前に許可を得る
推奨される振る舞い：
- 例：テストを先に書く
動作フロー
- 人間がターミナルでクエリを投げる
- LLMとタスクを明確化
- コーディング準備ができる
- ファイルを検索、読み取り、コンテキストを収集
- コーディング開始
- ファイルを編集、テストを実行
- 満足のいく結果が得られるまで繰り返し
- 人間に出力を返す
- 変更されたファイルのリスト
- パスしたテストのリスト
- 出力内容の要約
段階的な使用
- 小さなユースケースでテストを始める
- 信頼できるようになるにつれて、より大きなタスクを与える
- タスクが大きくなるにつれて、コンテキストが成長
- メモリやコンテキスト編集の機能を追加することを検討
3.2 コンピュータ使用エージェント（Computer Use Agent）
環境
あなたのコンピュータ
ツール
- マウスのクリック
- キーボードでのタイピング
- 移動
- 注：ClaudeはPC操作ツールでトレーニング済み
- APIやClaude開発者プラットフォームを通じて利用可能
プロンプト
- オペレーティングシステム（OS）は何か
- 注意点
- インターネットアクセスを与えるか否か
- コンピュータ内での移動方法に関するヒント
ヒューマン・イン・ザ・ループ（HITL）
⚠️ 重要：
- Claudeにコンピュータを自由に操作させない
- 何かをする前に許可を得るようにする
使用例
ユーザー：日本への旅行を予約して
エージェント：
- ブラウザをクリックして開く
- ホテルやフライトを調べる
- スクリーンショットを撮って何を見ているか確認
- 「承認を得るまでは、実際には何も予約しない」
3.3 検索エージェント
エージェントによる検索プロセス
環境
テキストコーパス（本文集）：
- 組織のデータ
- Web全体
- 法的文書
- ローカルファイルシステム
ツール
- 検索ツール
- 取得（フェッチ）ツール（ドキュメント全体を取得）
プロンプト
1. アクセス可能なテキストボディの説明
- Web全体にアクセスできるのか
- Webの一部なのか
- ドキュメントの種類は何か
2. 出力フォーマットの指定（重要）
- 単一の回答なのか
- 引用付きの詳細なレポートなのか
- 最も関連性の高い検索結果のリストなのか
⚠️ 注意：出力フォーマットを指定しないと、エージェントは検索を延々と続けてしまう
動作例
ユーザー：ニューヨーク市のアパートに関する詳細を調べて
エージェント：
- 一連の検索結果を実行
- 検索結果で見つけたものに基づいて
- さらなるフォローアップ検索
- Webやファイルシステムからのドキュメント取得
- 情報を統合
- ニューヨーク市のアパートに関する詳細な回答を作成
4. Anthropicプロダクトでの応用
実際にAnthropicの製品で、これらのエージェント技術がどのように活用されているか見ていきます。
Claude plays Pokemon
- エージェント的ループの実装例
- システムプロンプト、ツール、知識ベース（長期記憶）を活用
- ゲーム全体をプレイ
Claude Code
長期にわたるコーディングタスクに対応：
機能
メモリツール
- 過去に何をしたか覚えている
claude.mdファイル
- カスタムで記述可能
- 異なるリポジトリでのコーディングスタイル
- 従うべきガイドラインを認識
コンパクション（圧縮）ツール
- コンテキストウィンドウの終わりに達したとき
- 会話履歴をクリアして作業継続
Research Product（Claude AI）
概要
- マルチエージェントによるディープリサーチ製品
- ユーザーがディープなリサーチ質問を投げる
- Claudeが調査を行い、引用付きの詳細なレポートを返す
長いコンテキストへの対応：サブエージェントの使用
メインエージェント
↓ タスクを小さなサブタスクに分割
↓
┌───────────────────────────┐
│ サブエージェント1 サブエージェント2 サブエージェント3 │
│ (異なるプロンプト) (異なるプロンプト) (異なるプロンプト) │
│ ↓ ↓ ↓ │
│ 検索・取得 検索・取得 検索・取得 │
└───────────────────────────┘
↓ 情報を持ち帰る
メインエージェント
↓ すべてを統合
ユーザーのためのレポート生成
メインエージェントの役割
- リサーチタスクを複数のサブタスクに分割
- サブエージェントを起動
- すべての情報を統合してレポート生成
サブエージェントの役割
- それぞれ異なるプロンプトを受け取る
- 検索や取得を実行
- メインエージェントに情報を持ち帰る
まとめ
エージェント構築の核心
今回のセッションで学んだエージェント構築の核心をまとめます。
1. 適切なユースケースを選ぶ
- 複雑性、価値、実行可能性、エラーコストを評価
- すべてのタスクにエージェントが適しているわけではない
- ワークフローで解決できるなら、そちらを選ぶ
2. 明確で理解しやすいツールを設計
- 十分な情報を含む出力
- スカフォールディングで複雑性を管理
- 検証ツールで自律性を高める
- Claudeをレビュアーとして活用
3. コンテキストエンジニアリングを活用
- キュレーション：関連情報のみに絞る
- 永続化：必要な情報をメモリに保存
- 分割：サブタスクに分け、コンテキストを分離
- 圧縮：関連トークンのみ保持
4. 包括的なテストと評価
- 実世界のユースケースでテスト
- 可観測性への投資
- 主観的な評価を避ける
- フルカバレッジの評価スイートを構築
エージェントの本質
「エージェントとは、ループの中でツールを使用するLLM」
環境、ツール、プロンプトを適切に設計し、ベストプラクティスに従うことで、エージェントに成功のための最良のチャンスを与えることができます。
所感
このセッションを通じて、エージェントの本質的な構造から実装の詳細、実世界での応用まで、体系的に学ぶことができました。
特に印象的だったのは、「すべてのタスクにエージェントが必要なわけではない」というメッセージです。複雑性、価値、実行可能性、エラーコストを冷静に評価し、適切な技術を選択することの重要性を改めて認識しました。
また、コンテキストエンジニアリングの4原則（キュレーション、永続化、分割、圧縮）は、長期的なタスクに取り組むエージェントを構築する上で非常に実践的な指針となりそうです。
Anthropic Builder Summitは、AI技術の最前線に触れることができる貴重な機会でした。今後のエージェント開発に、今回学んだ知見を活かしていきたいと思います。
参考リンク
関連記事
同じイベントの別セッションのレポートもぜひご覧ください：
公式リソース
本資料は、Anthropicの研究者HannaとStephanieによるプレゼンテーション「効率的なエージェントの構築」の内容を整理したものです。
Discussion