Building effective agents

概要：この記事は何について書いているのか

この記事は、Anthropic が多くの企業と協働した経験から得た「AIエージェントを効果的に構築するためのベストプラクティス」をまとめたものです。

核心メッセージ：成功しているプロジェクトは、複雑なフレームワークではなく、シンプルで組み合わせ可能なパターンを使っている。

1. 「エージェント」とは何か？

基本的な定義

「エージェント」という言葉は曖昧に使われがちですが、Anthropicは明確に2つに分類しています。

種類 説明 例え
ワークフロー あらかじめ決められた手順でLLMとツールを動かす レシピ通りに料理を作る
エージェント LLM自身がどう進めるか判断しながらタスクを実行する シェフが状況を見ながら即興で料理を作る

ポイント：ワークフローは「決まった道筋」、エージェントは「自分で道を決める」という違いがあります。

2. いつエージェントを使うべきか？

重要な原則：最もシンプルな解決策から始める

シンプル ←―――――――――――――――→ 複雑
単一の LLM 呼び出し → ワークフロー → エージェント

エージェントのトレードオフ：

  • ✅ メリット：複雑なタスクの性能が上がる
  • ❌ デメリット：処理時間が長くなる、コストが高くなる

判断基準：

  • 単純な質問応答 → 単一のLLM呼び出しで十分
  • 決まった手順のタスク → ワークフロー
  • 大規模な柔軟性とモデル駆動型の意思決定が必要 → エージェント

3. フレームワークをいつ、どのように使用すべきか

主要なフレームワーク

  • LangGraph（LangChain製）
  • Amazon Bedrock AI Agent
  • Rivet（GUIでワークフローを構築）
  • Vellum

Anthropicの推奨

「まずは LLM API を直接使うことから始めてください」

理由：

  1. 多くのパターンは数行のコードで実装できる
  2. 抽象化のレイヤーが追加され、基盤となるプロンプトやレスポンスが分かりにくくなり、デバッグが困難
  3. 不必要に複雑な実装になりがち

フレームワークを使う場合の注意：内部で何が起きているかを理解しておくこと。

4. 基本構成要素とパターン

拡張 LLM から始め、シンプルな構成ワークフローから自律エージェントへと、段階的に複雑さを増していきます。

4.1 基盤：拡張LLM（Augmented LLM）

すべてのエージェントシステムの基本となる構成要素です。

3つの拡張機能：

機能 説明 具体例
検索（Retrieval） 外部データを参照する 社内文書を検索して回答
ツール（Tools） 外部システムと連携する カレンダーに予定を追加
メモリ（Memory） 過去の情報を記憶する 前回の会話内容を覚えている

4.2 ワークフロー①：プロンプトチェーン

概念：タスクを順番に処理していく直列のパイプライン

具体例：

  1. マーケティング文章を作成（LLM①）
  2. 品質チェック（ゲート）
  3. 日本語に翻訳（LLM②）

使いどき：

  • タスクが明確なステップに分割できる
  • レイテンシを犠牲にして、各ステップでの精度を高めたい

メリット：各 LLM の仕事が簡単になり、全体の精度が上がる

イメージ：工場の組み立てライン。各工程で専門の作業を行う。

4.3 ワークフロー②：ルーティング

概念：入力を分類して、適切な処理に振り分ける

                    ┌→ [一般的な質問用LLM]
入力 → [分類器] ────┼→ [返金処理用LLM]
                    └→ [技術サポート用LLM]

具体例：

  • カスタマーサポートで、問い合わせ内容に応じて専門チームに振り分け
  • 簡単な質問は軽量モデル（Haiku）、難しい質問は高性能モデル（Sonnet）に振り分け

使いどき：

  • 入力のカテゴリが明確に分かれている
  • カテゴリごとに最適化したい

イメージ：病院の受付。症状に応じて適切な診療科に案内する。

4.4 ワークフロー③：並列化

概念：複数のLLMを同時に動かして、結果を統合する

2つのバリエーションがあります。

パターンA：セクショニング（分割）

タスクを独立した部分に分けて同時処理。

         ┌→ [LLM: セクション1] ─┐
入力 ────┼→ [LLM: セクション2] ─┼→ 結果統合 → 出力
         └→ [LLM: セクション3] ─┘

具体例：

  • ユーザーの質問に回答する LLM と、不適切な内容をチェックするLLMを同時に動かす
  • 論文の「方法」「結果」「考察」を別々に評価する

パターンB：投票（Voting）

同じタスクを複数回実行して、多数決や合議で決定。

         ┌→ [LLM: 評価1] ─┐
入力 ────┼→ [LLM: 評価2] ─┼→ 投票/合議 → 出力
         └→ [LLM: 評価3] ─┘

具体例：

  • コードの脆弱性を複数の観点からチェック
  • コンテンツが不適切かどうかを複数の評価者で判定

使いどき：

  • 並列化することで処理速度を上げたい
  • 複数の視点や試行により、特定の側面に集中的に注意を向けることができ信頼性の高い結果が必要

イメージ：裁判の陪審員制度。複数人の意見を集約して判断。

4.5 ワークフロー④：オーケストレーター・ワーカー

概念：指揮者（オーケストレーター）がタスクを分解し、作業者（ワーカー）に割り振る

                    ┌→ [ワーカーLLM①] ─┐
入力 → [指揮者LLM] ─┼→ [ワーカーLLM②] ─┼→ [指揮者が統合] → 出力
                    └→ [ワーカーLLM③] ─┘

並列化との違い：

  • 並列化：あらかじめサブタスクが決まっている
  • オーケストレーター：指揮者がその場でサブタスクを決める（柔軟性）

具体例：

  • コーディングで複数ファイルを変更する場合、どのファイルを変更するかは内容によって異なる
  • 調査タスクで、どの情報源を調べるかは質問内容による

使いどき：

  • 事前にサブタスクを予測できない
  • 入力によって必要な作業が大きく変わる

イメージ：オーケストラの指揮者。曲に応じて各パートへの指示を変える。

4.6 ワークフロー⑤：評価者・最適化

概念：生成と評価を繰り返して品質を高めるループ

入力 → [生成LLM] → 出力 → [評価LLM] → フィードバック
          ↑                              │
          └──────────── 改善 ────────────┘

具体例：

  • 文学翻訳：翻訳 → 評価（ニュアンスの指摘）→ 翻訳改善 → 評価...
  • 検索タスク：検索 → 評価（情報が足りない）→ 追加検索 → 評価...

使いどき：

  • 明確な評価基準がある
  • 反復することで品質が上がる
  • 人間のフィードバックでも改善できる内容

イメージ：編集者と作家の関係。作家が書き、編集者がフィードバックし、作家が直す。

4.7 エージェント（本格的な自律システム）

概念：LLMが自分で計画を立て、ツールを使い、結果を見て次のアクションを決める

┌────────────────────────────────────────────────┐
│                 エージェントのループ              │
│                                                │
│  [人間の指示] → [計画] → [ツール実行] → [結果確認]  │
│                   ↑                      │      │
│                   └───── 次のアクション ──┘      │
│                                                │
│  ※必要に応じて人間に確認を取る                    │
│  ※終了条件（完了 or 最大試行回数）で停止            │
└────────────────────────────────────────────────┘

重要な特徴：

  1. 環境からのフィードバック：ツールの実行結果などの「実際の情報」を元に判断
  2. 人間の監督：重要な判断ポイントで人間に確認
  3. 停止条件：無限ループを防ぐための制限

使いどき：

  • 必要なステップ数が予測できない
  • 柔軟な判断が必要
  • 環境を十分に信頼できる

注意点：

  • コストが高くなりやすい
  • エラーが連鎖する可能性がある
  • サンドボックス環境での十分なテストが必要

具体例：

  • GitHub の Issue を解決するコーディングエージェント
  • コンピュータを操作して作業を完了させるエージェント

5. パターンの組み合わせ

これらのパターンは独立したものではなく、組み合わせて使うことができます。

例：高度なカスタマーサポートシステム

[ルーティング] でカテゴリ分類
      ↓
[プロンプトチェーン] で段階的に回答作成
      ↓
[評価者・最適化] で回答品質を改善
      ↓
[並列化] で安全性チェックを同時実行

重要：複雑さは必要な時だけ追加する。性能向上が測定できる場合のみ複雑にする。

6. 実践のまとめ：3つの原則

原則1：シンプルさを保つ

複雑なシステムは保守が難しく、デバッグも困難。

原則2：透明性を優先する

エージェントが「何を考えているか」を明示的に見せる。

原則3：ツール設計に注力する（ACI）

  • ACI（Agent-Computer Interface）：エージェントとシステムの接点
  • 人間向け UI（HCI）と同じくらい丁寧に設計する

設計のチェックリスト

  1. LLM の立場で考える：説明を読んだだけで使い方がわかるか？
  2. 例を含める：使用例、エッジケース、入力形式の要件を明示
  3. テストを繰り返す：様々な入力でLLMがどうツールを使うか確認
  4. ポカヨケ：間違いにくい設計にする（例：相対パスではなく絶対パスを要求）