Anthropic Building Effective AI Agents – Practical Patterns and Guidance

TL;DR

Anthropicは、LLMベースのエージェント構築における1年間の経験を凝縮したガイドを公開しました。これは、拡張LLM、プロンプト・チェイニング、ルーティング、並列化、オーケストレーター・ワーカー、エバリュエーター・オプティマイザー、そして自律型エージェントといった、シンプルで構成可能なパターンが、重量級のフレームワークよりも優れた性能を発揮することを示しており、各パターンの使用時期やツールの設計方法に関する具体的なアドバイスを提供しています。


What qualifies as an "agent"?

エージェントとは、LLMがどのツールを呼び出し、どのようにアクションを順序立てるかを動的に決定し、プロセス全体を制御するシステムのことです。対照的に、ワークフローは、LLMの呼び出しやツールをオーケストレートする固定されたコードパスに従います。この区別が、本ガイドの残りの部分の枠組みとなります。


When to adopt agentic systems

  • Start simple: 検索(retrieval)とインコンテキストな例示を用いて、単一のLLM呼び出しから始めることを推奨します。成果が明らかに改善される場合にのみ、複雑さを追加してください。
  • Trade‑off awareness: エージェントはレイテンシとコストを増加させますが、開拓的な問題に対してはタスクのパフォーマンスを向上させることができます。
  • Choosing between patterns:
    • Workflows → 定義されたタスクを予測可能かつ一貫性のある方法で処理します。
    • Agents → スケール可能な、モデル主導の柔軟な意思決定を行います。

Frameworks vs. direct API use

  • 人気のあるSDK(Claude Agent SDK, Strands Agents SDK, Rivet, Vellum)は、LLM呼び出し、ツール解析、チェイニングを抽象化することで、導入の障壁を下げます。
  • Caution: 抽象化はプロンプトやレスポンスを隠してしまうことがあり、デバッグを困難にし、不必要な複雑さを助長する可能性があります。
  • Recommendation: まずは生のLLM APIから始めてください。フレームワークを使用する場合は、基盤となるコードの可視性を維持してください。

Core building block: the augmented LLM

拡張LLM(augmented LLM)は、ベースモデルに検索、ツール利用、およびメモリを組み合わせたものです。Anthropicのモデルは、検索クエリを生成し、ツールを選択し、何を保持すべきかを決定できます。Model Context Protocolは、サードパーティ製ツールを統合するための標準的なクライアント実装を提供します。


Common workflow patterns

1. Prompt chaining

  • What it is: タスクを逐次的なLLM呼び出しに分解し、必要に応じてプログラム的なゲートを挿入します。
  • When to use: 高い精度が、追加のレイテンシよりも重要となる、固定されたサブタスクの場合。
  • Examples: マーケティングコピーの生成 → 翻訳; アウトライン作成 → 検証 → 完全なドキュメントの執筆。

2. Routing

  • What it is: 入力を分類し、専門化されたダウンストリームのプロンプトやツールに振り分けます。
  • When to use: 個別のカテゴリによって、最適化された処理のメリットが得られるタスク。
  • Examples: カスタマーサービスへの問い合わせを、異なるハンドラーにルーティングします。簡単な質問はClaude Haiku 4.5へ、難しい質問はClaude Sonnet 4.5へ送ります。

3. Parallelization

  • Variations:
    • Sectioning – 独立したサブタスクに分割し、並行して実行します。
    • Voting – 同じプロンプトを複数回実行して、多様な回答を得ます。
  • When to use: 並行処理による速度向上、または複数の視点による信頼性の向上。
  • Examples: ガードレール(安全性のスクリーニング用に別個のモデルを使用); コードの脆弱性レビューを複数のプロンプトで行う; コンテンツ・モデレーションの投票制。

4. Orchestrator‑workers

  • What it is: 中央のLLMが問題をサブタスクに動的に分解し、ワーカーLLMに委任し、結果を結果を統合します。
  • When to use: サブタスクを事前に定義できない、複雑で予測不可能なタスク(例:複数ファイルのコード変更、複数ソースの検索)。

5. Evaluator‑optimizer

  • What it is: 1つのLLMが回答を出力し、2つ目のLLMがそれを評価しフィードバックを提供することで、反復的な洗練のループを形成します。
  • When to use: 明確な評価基準が存在し、反復的な改善が、測定可能な価値を生み出す場合。
  • Examples: 文学的な翻訳におけるニュアンスの批判的検討; 評価者がさらなる調査が必要かどうかを判断するマルチラウンド検索。

Autonomous agents

  • Lifecycle: コマンドまたは対話的なプロンプトを受け取り → プランニング → ツール呼び出しをループ内で実行 → 必要に応じて人間のフィードバックのために一時停止 → 完了または最大反復回数に達した後に終了。
  • Key requirements:
    1. 明確なドキュメントを備えた堅牢なツールセット(Appendix 2を参照)。
    2. 環境からのグラウンドトゥルース(正解)のフィードバック。
    3. 累積的なエラーを軽減するためのガードレールとサンドボックス・テスト。
  • When to use: ステップ数が予測不可能な、開拓的な問題に対して、モデルの意思決定に対する信頼が許容できる場合。
  • Real‑world examples:
    • SWE‑benchタスクを解決するために、複数のファイルを編集するコーディング・エージェント。
    • "Computer use"デモにおいて、Claudeがデスクトップを制御してユーザー指定の目標を達成する。

Combining and customizing patterns

提示されたパターンは構成要素(building blocks)であり、厳格なレシピではありません。開発者は以下を行うべきです:

  • 各段階でのパフォーマンスを測定する。

  • 複雑さを追加する際のみ、測定可能な改善が見られる場合のみ追加する。

  • プロンプト、ツール定義、およびオーケストレーション・ロジックを繰り返し改善(iterate)する。


Core principles for reliable agents

  1. Simplicity – エージェントのデザインを最小限に保つ。
  2. Transparency – プランニング・ステップやツール呼び出しをログに公開する。
  3. Tool engineering – 明確で、よくドキュメント化されたツール・インターフェース(Appendix 2を参照)に投資する。

Appendix 1 – Agents in practice (summary)

  • Customer support: 対話的なフローとツール統合(例:注文データの取得、返金処理)により、測定可能な解決率の指標が得られます。
  • Coding agents: 自動テストにより客観的な検証が可能になります。エージェントはテストのフィードバックバックを用いて、実際のGitHub issueを解決するために反復的に動作します。

Appendix 2 – Prompt engineering your tools

  • Design tips:
    • ツール呼び出しを出力する前に、モデルが思考するための十分なトークンを確保してください。
    • モデルに馴染みのある形式(例:エスケープ処理が過度なJSONではなく、プレーンなコード)を使用してください。
    • 不必要なフォーマットのオーバーヘッドを避けてください(行数カウントのトラック、最小限のエスケープ処理)。
  • Human‑computer interface mindset: ツール仕様は、開発者向けのドキュメント(docstrings)のように扱うべきです。例示、エッジケース、および明確なパラメータ名を含めてください。
  • Testing: Anthropicのworkbenchで広範な例を実行し、誤用パターンをパターンとして抽出します。
  • Poka‑yoke: 引数を構造化して、モデルが間違いを犯しにくくするように設計してください。
  • Case study: SWE‑benchエージェントにおいて、相対パスから絶対パスへの切り替えがパス解決エラーを解消しました。

Final takeaway

LLMエージェントの成功は、最も洗練されたアーキテクチャを構築することではなく、適切な構成可能なパターンを選択し、ツール・インターフェースを、厳格にテストし、結果が明らかに改善される場合にのみ、複雑さを追加することにあります。

Sources

関連