Anthropicが語る、成功するAIエージェント設計の原則［翻訳記事］

> # TL;DR
>
> - LLM/AIエージェント構築は
> - 常にシンプルさを基本原則とし、必要なときにだけ複雑さを加える
> - 「フレームワークは深く理解したうえで導入」し、「ワークフロー・エージェントのパターン（チェイニング、ルーティング、並列化、評価者-最適化者など）を実環境と目的に合わせて組み合わせてテストし、ツール（API）の設計・文書化・テストを丁寧に行うこと」。

1. 成功するLLMエージェントの設計原則

• シンプルさに集中: 成功している実装は、複雑なフレームワークに依存するよりも、シンプルで組み合わせ可能な（compoundable）パターンを活用する傾向が強い。
• 必要なときだけ複雑性を追加: 基本構造はできるだけシンプルに設計し、どうしても必要な場合にのみ複雑性を導入するのが効率的。
• （原文: 「最も成功した実装は特殊なライブラリや複雑なフレームワークに依存していませんでした……シンプルで、しかもモジュール的に組み合わせ可能なパターンを土台に構築されていました。」）

2. ワークフロー vs エージェントの概念整理

• ワークフロー（Workflows）: LLMとツールが事前定義されたルート（コードパス）に従って処理する。
• エージェント（Agents）: LLMが自らタスクとツール利用を動的に管理する（意思決定の主体がLLM）。
• （原文: 「ワークフローはLLMとツールが事前定義されたコードパスに沿って調整され……エージェントはLLMが自分のプロセスとツールの使い方を動的に指示します」）

3. エージェント導入の判断基準

• シンプルな方法から始め、必要に応じて段階的に複雑化: 最初はシンプルなLLM呼び出しや検索などで始め、不足があれば段階的に Workflows/Agents を導入する。
• 予測可能性・一貫性が重要 → ワークフローの活用が適している
• 大規模な柔軟性・モデル主導の意思決定 が必要 → エージェントのほうが適している

4. フレームワーク導入の原則

• LangGraph、Bedrock、Rivet、Vellum などさまざまなツール／フレームワークがあるが、
• まずはLLM APIを直接使うところから始め、必要なときだけフレームワーク導入を推奨。
• フレームワークを使う際は、内部動作に対する 深い理解が必須（抽象化によって問題解決が難しくなることがある）
• （原文: 「開発者にはまずLLM APIを直接利用する方法から始めることを勧めています」）

5. 実践パターン別のワークフローと例

• 拡張LLM（Augmented LLM）: 検索、ツール接続、メモリなどのビルトイン拡張機能を追加（具体的なインターフェース設計と文書化が重要）
• プロンプトチェイニング（Prompt Chaining）: 1つの課題を複数のLLM呼び出し（段階）に分け、明確さと正確性を確保する。
  • 例: マーケティングコピー生成→翻訳、文書ドラフト→レビュー→執筆
• ルーティング（Routing）: 入力を分類した後、それに合った処理・ツールへ分岐
  • 例: 顧客問い合わせの種類別ルーティング、難しい質問だけ高性能モデルへ渡す
• 並列化（Parallelization）:
  • セクショニング（Sectioning）: 作業を複数のサブタスクに分けて同時処理
  • 投票（Voting）: 同じ作業を複数回試行して最良の結果を決める
  • 例: コード脆弱性レビュー、LLM評価の自動化
• オーケストレーター-ワーカー（Orchestrator-Workers）: マスターエージェントが下位タスクを割り振り・統合する。
  • 例: 複雑なコーディング作業で必要な部分だけをリアルタイムに割り振る、複数のデータを収集・統合する
• 評価者-最適化者（Evaluator-Optimizer）: あるLLMが回答を作り、別のLLMがその回答を評価・フィードバックして改善を繰り返す
  • 例: 翻訳結果の反復改善、複雑な情報収集

6. 実際の産業適用事例

• カスタマーサポート: チャットボット+ツール統合、顧客データ／注文／返金作業の自動化、成功可否は「問題解決」を基準に明確に測れる。実際に Usage-based 課金を適用するなどの企業事例もある。
• コーディングエージェント: 自動テストのフィードバックを基に反復・改善し、SWE-bench などで実証されている。問題領域と結果品質を明確に測定できる。ただし、最終レビューには常に人間の介入が必要。

7. ツール向けプロンプトエンジニアリング（付録2）のヒント

• LLMが使いやすいフォーマット と十分なトークン割り当てを推奨
• ツール説明（usage、例、エッジケース、境界設定など）を明確に
• 実際のモデル利用のされ方を テスト ⇒ 改善（ワークベンチなどを利用）
• 些細なミスも防げる poka-yoke 方式で設計
• （原文: 「良いツール定義には使用例、エッジケース、入力形式の要件、そして他ツールとの明確な境界が含まれているのが望ましいです。」）

8. 核心原則

• シンプルさを保つ（Keep it simple）
• エージェントの計画プロセス（Planning）の透明性 が必須
• ツール・インターフェースの明確な文書化とテスト
• フレームワークは初期速度には有利だが、抽象化は最小限に し、直接制御を推奨