🤖
概念 #anthropic #agents #llm #workflow #orchestration #ai-engineering 📚 Anthropic Research - プロダクト

効果的なAIエージェントの構築 - Anthropicガイド

概要

Anthropicがエージェント構築チームを支援した経験から得た知見をまとめたガイド(2024年12月公開)。最も成功した実装は複雑なフレームワークではなく、シンプルで組み合わせ可能なパターンを使っていたという核心的な発見を伝える。

要点

  • 「ワークフロー」と「エージェント」を明確に区別する — ワークフローは事前定義コードパスによる制御、エージェントはLLM自身が動的にプロセスを決定する
  • 複雑さを増やすのは、シンプルな解決策が明確に失敗した時だけにする
  • エージェントシステムはレイテンシとコストの増加と引き換えに高い性能を得る
  • ツール設計(ACI: Agent-Computer Interface)にはHCIと同等の注力が必要

主要概念・技術

ワークフロー vs エージェントの定義

種類定義特徴
ワークフローLLMとツールを事前定義コードパスで制御するシステム予測可能、コスト低
エージェントLLMが自律的にプロセスとツール使用を決定するシステム柔軟、複雑なタスク向き

拡張LLM(基盤ブロック)

全てのアーキテクチャの基礎となるのは、検索・ツール・メモリで強化されたLLM。AnthropicのModel Context Protocol(MCP)がサードパーティツール統合の標準として機能する。

5つのコアワークフローパターン

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

タスクを固定ステップに分解し、LLMを順次呼び出す。各ステップ間にプログラム的な品質チェック(ゲート)を挟む。

入力 → LLM①(草案) → 品質チェック → LLM②(改良) → 出力

適用例: 文書作成→翻訳→フォーマット変換のような固定フロー

2. ルーティング(Routing)

入力を分類し、最適な処理パイプラインに振り分ける。異なるカテゴリに最適化された処理を実現できる。

入力 → 分類LLM → [カテゴリA処理 | カテゴリB処理 | カテゴリC処理]

適用例: カスタマーサポートでの問い合わせ種別分類

3. 並列化(Parallelization)

複数のLLM処理を同時実行する。2つのアプローチがある:

  • セクション分割: 独立したサブタスクを並列処理
  • 投票(Voting): 同一タスクに複数の視点を適用して精度向上

適用例: 大量文書の並列要約、セキュリティレビューでの多角的チェック

4. オーケストレーター・ワーカー(Orchestrator-Workers)

中央のオーケストレーターLLMが動的にサブタスクをワーカーLLMに委譲する。必要なサブタスクが事前に予測できない場合に適する。

オーケストレーターLLM
  ├── ワーカーLLM①(コード生成)
  ├── ワーカーLLM②(テスト作成)
  └── ワーカーLLM③(ドキュメント)

適用例: コーディングタスク、複雑な調査タスク

5. エバリュエーター・オプティマイザー(Evaluator-Optimizer)

生成モデルと評価モデルが役割分担して反復的に改善する。明確な評価基準が存在する場合に効果的。

生成LLM → 出力 → 評価LLM → フィードバック → 生成LLM(再試行)

適用例: 翻訳品質の反復改善、コードレビューサイクル

自律エージェントのパターン

LLMの推論力とツール信頼性の向上に伴い、自律エージェントが現実的になってきた。ただし以下の前提が必要:

  • サンドボックス環境での徹底的なテスト
  • 人間によるチェックポイントの設置
  • エラーが複合的に拡大するリスクへの対処

実例:

  • カスタマーサポート: 顧客データへのアクセス、返金処理ツールを組み合わせ、解決率で成功を計測
  • コーディングエージェント: 自動テストのフィードバックでイテレーション。SWE-benchで実際のGitHub issueを解決可能に

実装の3原則

  1. シンプルさ: エージェント設計を可能な限りシンプルに保つ
  2. 透明性: 計画ステップを明示的に表示する
  3. ACI(Agent-Computer Interface): ツールのドキュメントとテストにHCI同等の工数を投入する

ツール設計のベストプラクティス

ツール定義の最適化に多くの努力を割くべき理由は、LLMがツールをどう使うかが成否を左右するから。

  • フォーマット選択: LLMの認知負荷を最小化するフォーマットを選ぶ。正確な行数指定や過剰なエスケープは避ける
  • ドキュメント: 使用例・エッジケース・入力要件・ツールの境界を記載する
  • テスト: 実例を流して間違いを特定し反復する
  • ポカヨケ設計: 相対パスより絶対パスを使うなど、間違いを起こしにくくする

まとめ

「LLM分野での成功は、最も洗練されたシステムを構築することではない。自分のニーズに合った正しいシステムを構築することにある」

フレームワークは開発を加速できるが、基盤となるコードを理解していないと一般的なエラーを防げない。複雑さは価値が証明された時にのみ追加する。

出典: https://www.anthropic.com/research/building-effective-agents