👨‍👨‍👧‍👦

AIエージェント構築ガイド：8本の資料を横断して要点を整理

に公開
AI
prompt
Agent
idea

AIエージェント構築ガイド：8本の資料を横断して要点を整理（2025-09-11時点）

以下のリンクに含まれる内容を読み合わせ、重なり・相違・実装の勘所をまとめました。
対象資料：Anthropicの実践ガイド、OpenAIの公式PDF、LangChainの「Context Engineering」、Cognitionの提言、Lilian Wengの体系記事、長文コンテキストの失敗例、Anthropicのマルチエージェント研究の要点まとめ（Zenn）、および添付画像（トピックのアイキャッチ）。

まず全体像（要約）

  • 「まずは単純に、必要なときだけ複雑に」：多くの成功事例は、巨大なフレームワークよりもシンプルで合成可能なパターンから始めている。複雑化（マルチエージェント化など）は効果が実証できる段階で段階的に導入するのがよい。(t.co)
  • OpenAIの公式観点：エージェントは「LLMがツールを使いながら自律的にワークフローを遂行する仕組み」。まず単一エージェント＋ツールで作り、必要に応じてマネージャー型や分散（ハンドオフ）型のマルチエージェントへ拡張する。評価・ガードレール・人手介入の設計が中核。
  • コンテキストは生命線：エージェントが長時間・多ツールで動くほど「何を文脈に入れるか（Context Engineering）」が最重要課題になる。選ぶ／書く／圧縮する／隔離する、の4戦略で制御するのが現在の主流。(t.co)
  • 「長いコンテキスト＝強い」ではない：長大なプロンプトは中毒・混乱・衝突・分散注意などの故障モードを誘発し、性能を落とす。要約・選別・ツール選定のRAG化などで必要最小限を入れるべき。(t.co)
  • マルチエージェントは両刃：Anthropicは調査系などで有効事例を提示する一方、Cognitionは**「むやみにマルチにするな」**と警鐘。並列化の旨味はあるが、文脈共有と意思決定の一貫性を壊しやすい。(t.co)
  • 古典だが有用：Lilian Wengの総論は、計画・記憶・ツール使用を柱に据えたエージェント設計の基礎を整理。現在の議論の土台。(t.co)

各資料の要旨（時系列順）

1) Lilian Weng「LLM Powered Autonomous Agents」（2023-06-23）

  • エージェントを計画（Task分解・自己反省）／記憶（短期・長期）／ツール使用で構成。ReAct、Reflexion、CoH、ToTなど代表手法を概説。(t.co)

2) Anthropic「Building effective agents」（2024-12-19）

  • 単純で合成可能なパターンから始める勧告。ワークフロー（固定経路）とエージェント（動的決定）の峻別。プロンプト連鎖／ルーティング／並列化／オーケストレーター-ワーカー／評価者-最適化ループなどの設計パターンを提示。(t.co)

3) OpenAI「A practical guide to building agents」（公式PDF）

  • 定義：LLMが意思決定し、ツールで外部作用し、失敗時は停止・移譲できるシステム。

  • いつ作るか：ルール自動化が苦手な曖昧・例外多い業務や非構造データ中心の業務で効果が高い。

  • 基礎：モデル選定→ツール設計（Data/Action/Orchestration）→明確な指示（手順化・分岐・例外）→オーケストレーションへ。

  • オーケストレーション：

    • 単一エージェントを基本に、ループ（run）で終了条件まで回す。
    • マルチはマネージャー型（エージェントをツールとして呼び出す）と分散ハンドオフ型（状態を渡して引き継ぐ）。

  • ガードレール：関連性・安全・PII・モデレーション・ツール安全度などを層状防御で。人手介入も明示。

4) LangChain「Context Engineering」（2025-07-02）

  • 選んで入れる／外に書く（スクラッチパッド・記憶）／圧縮（要約・トリミング）／隔離（サブエージェントやサンドボックス・状態オブジェクト）の4類型に整理。LangGraph/LangSmithで状態管理・長期記憶・評価を支援。(t.co)

5) Drew Breunig「How Long Contexts Fail」（2025-06-22）

  • 失敗モードを4Cで整理：Poisoning／Distraction／Confusion／Clash。

    • 例：ツールを多く渡すほど関数呼び出し精度が低下（BerkeleyのFunction-Calling L/B観察）、段階的プロンプト“分割”で大幅性能低下（Microsoft+Salesforceの研究）。(t.co)

6) Anthropic「How we built our multi-agent research system」要点（Zennの抄訳・解説、2025-06-15）

  • オーケストレーター-ワーカー構成で調査を並列化。トークン投下量が性能に強く相関、ただしコストは高騰（通常チャット比で単体≈4倍、マルチ≈15倍という目安）。プロンプト設計・ツール選定・人員（エージェント数）配分の運用則を提示。(t.co)

7) Cognition「Don’t Build Multi-Agents」（2025-06-12）

  • 原則1：文脈を共有（完全なトレース共有）、原則2：行為は暗黙の決定を内包（矛盾は破局）。
  • マルチは意思決定の分散と文脈不整合で壊れやすい。基本は単一スレッドの直列エージェント＋履歴圧縮モデル（必要なら微調整モデル）で長期運転。(t.co)

共通テーマと相違点

  • 共通

    • 最小構成→実証→拡張の順で進める（単一エージェント＋ツールから）。(t.co)
    • コンテキスト管理が決定打。長ければ良いわけではなく、選別・要約・隔離が鍵。(t.co)
    • 評価とガードレールを早期から組み込む（関連性・安全・PII・人手介入）。

  • 相違

    • マルチエージェントの評価：Anthropicは調査系での有効性を主張（並列思考容量の増加）。Cognitionは実運用では脆いとし、文脈共有と意思決定一貫性を満たせない設計は避けるべきと警告。(t.co)

実装の勘所（具体）

1) いつエージェント化するか

  • 曖昧さ・例外が多い／ルール保守が困難／非構造データ主体の業務（例：返金審査、保険請求、複雑なCS対応）。

2) 設計の順序

  1. モデル選定：まず最強モデルでベースライン→小型モデルへ置換でコスト・遅延最適化。

  2. ツール設計：

    • Data（検索・R/W取得）／Action（副作用）／Orchestration（他エージェント呼び出し）を明確化。

  3. インストラクション：既存手順をLLM向け手順に落とし込み、明確なアクションと分岐・例外を定義。

  4. オーケストレーション：

    • 基本は単一（runループ＋終了条件）。
    • マルチはマネージャー型（サブエージェントをツールとして呼ぶ）かハンドオフ型（状態ごと移譲）。どちらも文脈の受け渡しを設計。

3) コンテキスト設計（Context Engineering 4手）

  • Write（外に書く）：スクラッチパッド・長期記憶。長対話の要約や計画の保存に使う。(t.co)
  • Select（選ぶ）：メモリ/RAG/ツール定義もRAGで選択して過多を防ぐ。(t.co)
  • Compress（圧縮）：階層・再帰要約、自動コンパクト等で履歴を縮約。(t.co)
  • Isolate（隔離）：サブエージェントやサンドボックス実行、状態オブジェクトで重いデータをLLM外に保持。(t.co)

4) 長文文脈の落とし穴（対策）

  • 4C対策

    • Poisoning：要約時の事実検証／ツール結果の書き戻しレビュー。(t.co)
    • Distraction：モデル毎の**注意上限（Distraction ceiling）**を把握し、閾値超えで要約・トリム。(t.co)
    • Confusion：ツールのRAG選択で同時提示数を絞る。(t.co)
    • Clash：段階取得の際は**初期仮説の“残骸”**を残さない要約・整合処理。(t.co)

5) 評価と運用

  • 自動評価の導入（正解率・成功解決率・ツール誤用率・トークン/成功あたりコスト）。人手介入の基準：失敗閾値超過、高リスク行為（返金・支払など）。

6) コスト設計の現実

  • 調査系マルチ構成は性能↑だがトークン激増（例示：単体≈4倍、マルチ≈15倍）。まず単一強化と新モデル移行で効率を上げ、その後に並列化を検討。(t.co)

役立つ設計パターン（いつ使うか）

  • プロンプト連鎖（Prompt Chaining）：工程を分割、各工程を小タスク化して精度↑。校正→翻訳など。(t.co)
  • ルーティング：問い合わせ種別で下流処理・モデルを切り替え（例：Haikuへ簡易質問、Sonnetへ難問）。(t.co)
  • 並列化（セクショニング／投票）：複数視点での評価・検知、スピード最適化。(t.co)
  • オーケストレーター-ワーカー：未知の下位タスク数が多い開発・検索で有効。(t.co)
  • 評価者-最適化ループ：明確な基準がある場合に反復改善。(t.co)
  • マネージャー型マルチ：各専門エージェントをツール化して呼ぶ（文脈一元化しやすい）。
  • 分散ハンドオフ型マルチ：役割ごとに実行権限を移譲（トリアージ→専任）する運用向け。

最小構成チェックリスト

  • 問題特性は曖昧・例外多い・非構造か？（そうでなければ従来自動化を検討）

  • 単一エージェントで開始（終了条件・リトライ上限・失敗時停止を実装）。

  • ツールは最小限から（Data/Action/Orchestrationを明記、説明文は短く用途を限定）。

  • Context Engineering：

    • 重要事実はスクラッチパッドへ書き出し
    • RAGで選別し、閾値超えで要約
    • 必要ならサンドボックス／状態で隔離 (t.co)

  • ガードレール＋人手介入を初期から（関連性・安全・PII・ツール安全度、エスカレーション条件）。

  • 効果検証：成功率・コスト/成功・ツール誤用率をダッシュボード化し、小型モデル置換で最適化。

まとめ（実務メッセージ）

  1. まず単一エージェント＋少数ツールで価値検証 → 評価とガードレールを敷いてから段階的に拡張。
  2. 文脈を“設計”する：入れる・書く・縮める・分けるを意図的に。長文一括投入は避ける。(t.co)
  3. マルチは目的限定：調査の並列や役割分担には効くが、文脈共有と意思決定整合の設計ができないなら避ける。(t.co)

出典

  • Anthropic: “Building effective agents” (2024-12-19). (t.co)
  • OpenAI: “A practical guide to building agents” (公式PDF).
  • LangChain: “Context Engineering” (2025-07-02). (t.co)
  • Drew Breunig: “How Long Contexts Fail” (2025-06-22). (t.co)
  • Zenn（ML_Bear）: Anthropic「How we built our multi-agent research system」要点（2025-06-15/17）。(t.co)
  • Cognition: “Don’t Build Multi-Agents” (2025-06-12). (t.co)
  • Lilian Weng: “LLM Powered Autonomous Agents” (2023-06-23). (t.co)

Discussion