AIエージェントの作り方のパターン
Anthropic OpenAI Google Cloud Microsoft AWS LangChainの一次資料をもとにしたAIエージェントの設計パターンまとめ
全体の前提
AIエージェントは「自律性」より「型（デザインパターン）」で捉えると設計しやすい
各社の公開資料は意外なほど同じ方向を向いている
最初からマルチエージェントを前提にしない
単純な構成（single-agent）から始め、必要に応じて段階的に拡張する
ツール・文脈・評価を設計対象として扱う
推奨される設計の順番
まず型で考える
single-agentで始める
文脈を整える
必要なら評価と観測を入れる
そのうえでマルチエージェントや高度なオーケストレーションを検討する
派手な事例集より、設計の前提を整える一次ドキュメントが頼りになる
各社資料の役割分担
Anthropicは「型」を教える
Google CloudとMicrosoftは「どの型を選ぶか」を教える
OpenAIは「どう作り、どう評価するか」を教える
LangChainは「コードにどう落とすか」を見せる
AWSは「どう本番設計に載せるか」を補う
ワークフローとエージェントの区別（Anthropic）
Building Effective AI Agents（型・augmented LLM・自律ループ・3原則・フレームワーク各セクションの出典）
エージェンティックシステムは2種類に大別される
ワークフロー: LLMとツールが事前定義されたコードパスでオーケストレーションされる
エージェント: LLMが自らのプロセスとツール利用を動的に制御する
最もシンプルな解から始め、必要なときだけ複雑さを足すのが原則
エージェンティックシステムはレイテンシとコストを犠牲にタスク性能を上げるトレードオフ
多くの用途ではRAGやin-context例付きの単一LLM呼び出しで十分
エージェントの簡潔な定義: LLMがツールをループで自律的に使うもの
基本構成要素: augmented LLM（Anthropic）
エージェンティックシステムの基本ブロックは拡張されたLLM
拡張とはretrieval・ツール・メモリ
モデルが自ら検索クエリ生成・ツール選択・保持情報の判断を行う
ワークフローの型（Anthropic）
再利用可能で組み合わせ可能なパターンとして整理されている
prompt chaining
タスクを順次のステップに分解し、各LLM呼び出しが前の出力を処理
途中にgate（プログラム的検査）を挟める
タスクを綺麗に固定サブタスクへ分解でき、レイテンシと引き換えに精度を上げたいときに有効
routing
入力を分類し、専門化された後続タスクへ振り分ける
関心の分離ができ、特化したプロンプトを作れる
簡単な質問は安価なモデル、難しい質問は高性能モデルへ振り分けるのにも使える
parallelization
sectioning: 独立サブタスクを並列実行
voting: 同一タスクを複数回実行し多様な出力を得る
並列化で高速化、または複数視点で確度を上げたいときに有効
orchestrator-workers
中央LLMが動的にタスクを分解し、worker LLMへ委譲して結果を統合
parallelizationとの違いはサブタスクが事前定義でなくオーケストレーターが動的に決める点
変更ファイル数が読めないコーディングなどに向く
evaluator-optimizer
一方のLLMが生成し、他方が評価とフィードバックをループで返す
明確な評価基準があり、反復的改善が効くときに有効
文芸翻訳や多段の検索タスクなど
エージェント（自律ループ）（Anthropic）
環境フィードバックに基づきツールをループで使う
各ステップで環境からground truth（ツール結果やコード実行結果）を得て進捗を評価
チェックポイントや障害時に人間へ戻れる
停止条件（最大反復数など）で制御を保つ
ステップ数を予測できないオープンエンドな問題に向くが、コスト増とエラー蓄積のリスク
サンドボックスでの十分なテストとガードレールを推奨
エージェント設計の3原則（Anthropic）
simplicity: 設計を単純に保つ
transparency: エージェントの計画ステップを明示する
ACI（agent-computer interface）: ツールのドキュメントとテストを丁寧に作り込む
人間向けのHCIと同じだけ労力を投じる
SWE-benchではプロンプトよりツール最適化に多くの時間を費やした
フレームワークの扱い（Anthropic）
Claude Agent SDK・Strands Agents SDK（AWS）・Rivet・Vellumなどがある
抽象化層がプロンプトや応答を隠しデバッグを難しくしうる
まずLLM APIを直接使うことを推奨、多くのパターンは数行で実装できる
文脈設計（context engineering）（Anthropic）
Effective context engineering for AI agents
文脈は有限のリソースで、プロンプト工学の自然な発展形
context rot: トークン数が増えると想起精度が落ちる
モデルにはattention budgetがあり、新しいトークンごとに消費される
良い文脈設計とは、望む結果の確率を最大化する最小の高シグナルなトークン集合を見つけること
文脈の構成要素
system promptはright altitude（過度なハードコードと曖昧すぎの中間）で書く
ツールはトークン効率よく、機能重複を避ける
examplesは多様で正準的な少数を厳選（few-shot prompting）
文脈の取得戦略
just-in-time: file path等の軽量な識別子を保持し、実行時に動的ロード
事前retrievalと動的探索のhybridも有効
progressive disclosure: 探索を通じて段階的に文脈を発見
長時間タスクの技法
compaction: 文脈上限に近づいた会話を要約し、新しい文脈窓を再初期化
structured note-taking（agentic memory）: NOTES.md等に外部記憶を書き出し後で読み戻す
sub-agentアーキテクチャ: 専門サブエージェントがクリーンな文脈で集中処理し、要約のみ返す
評価の考え方（Anthropic「Demystifying evals」）
Demystifying evals for AI agents
エージェントの評価をどう設計するかを整理
実運用での改善ループを回すうえで重要
設計パターンの選び方（Google Cloud）
Choose a design pattern for your agentic AI system
Agentic AI architecture guides（Google Cloudの関連資料まとめ・入口）
agent design patternはシステム構成とオーケストレーションの設計枠組み
要件定義の4軸
task characteristics: 事前定義ワークフローで済むか、オープンエンドか
latency/performance: 速度優先か精度優先か
cost: 1リクエストで複数モデル呼び出しを許容できるか
human involvement: 高リスクや主観判断で人間が要るか
予測可能で構造的なら非エージェント解の方が安価なこともある
single-agent system
model＋ツール群＋包括的なsystem promptで自律的にタスク処理
開発初期はまずここから始め、コアロジック・プロンプト・ツール定義を磨く
ツールが増え複雑化すると性能低下しうる→ReActやマルチエージェントへ
multi-agent system
大目標を小タスクに分解し専門エージェントへ割り当てる
モジュール設計でスケーラビリティ・信頼性・保守性が向上
文脈設計（隔離・永続化・圧縮）が必須、評価/セキュリティ/コストの考慮が増える
deterministic（決定的）なワークフロー向け
sequential pattern: 固定の線形順、出力が次の入力。model orchestration不要
parallel pattern（concurrent）: 複数サブエージェントが同時実行し結果を統合。model orchestration不要
iterative refinement pattern: ループで出力を段階的に改善。品質優先
動的オーケストレーションが要るワークフロー向け
single agent pattern: 構造的な多段タスク、プロトタイプ向け
coordinator pattern: 中央coordinatorがmodelで動的にルーティング。parallelとの違いはmodel orchestrationの有無
hierarchical task decomposition pattern: 多階層でrootが分解し下位へ委譲。coordinatorの実装
swarm pattern: all-to-all通信、中央監督なし、dispatcherは通信仲介のみ。明示的exit条件必須
反復を伴うワークフロー向け
ReAct pattern: thought→action→observationのループ。モデル推論の質に依存
loop pattern: 終了条件まで反復。無限ループのリスク
review and critique pattern（generator and critic）: 生成→criticが評価→承認/却下/差し戻し。loopの実装
特殊要件のワークフロー向け
human-in-the-loop pattern: チェックポイントで人間が承認/修正/入力
custom logic pattern: コードで条件分岐、最大の柔軟性、複数パターンの混合
構成要素の選び方（Google Cloud）
Choose your agentic AI architecture components
設計パターンを決めた次に、構成要素（model・ツール・基盤など）をどう選ぶかを整理
オーケストレーションパターン（Microsoft）
AI Agent Orchestration Patterns
Azure Architecture Center / AI Architecture Design（AIシステム設計全体の入口）
複雑さのスペクトラム
direct model call: プロンプト工学で解ける単発タスク。エージェント不要
single agent with tools: 1ドメイン内の多様なクエリ。多くの企業用途の既定解。反復上限を設定
multi-agent orchestration: 横断的・複数ドメイン、セキュリティ境界が要る場合
信頼して使える最小の複雑さを選ぶ
sequential orchestration
別名pipeline・prompt chaining・linear delegation
LLMエージェントを事前定義の線形順で連結。次のエージェントは決定的に決まる
concurrent orchestration
別名parallel・fan-out/fan-in・scatter-gather・map-reduce
複数エージェントが同一入力を同時処理。集約はvoting・重み付けマージ・要約など
group chat orchestration
別名roundtable・multi-agent debate・council
共有スレッドで議論し合意形成。chat managerが発言順を制御
エージェントは通常read-only。HITLと相性が良い。3エージェント以下を推奨
maker-checker loop: makerが生成、checkerが基準で評価し差し戻す。evaluator-optimizerの一種
handoff orchestration
別名routing・triage・transfer・dispatch・delegation
各エージェントが自分で処理するか適切なエージェントへ委譲するか判断。1度に1エージェントが完全に制御を持つ
magentic orchestration
別名dynamic orchestration・task-ledger-based orchestration・adaptive planning
manager agentがtask ledgerを動的に構築・改訂し、計画立案そのものに重きを置く
解法が事前に決まらないオープンエンド問題向け。group chatの拡張
実装上の考慮事項
単一エージェントで解けるなら分割しない
deterministic routingの制御はコード/SDK定義で得やすい
文脈・状態管理: エージェント遷移で文脈が膨張、compactionや永続化で対処
信頼性: timeout/retry、circuit breaker、出力検証、graceful degradation
セキュリティ: 最小権限、security trimming、複数地点でのガードレール
コスト最適化: タスクの複雑さに応じてエージェントごとにmodelを割り当てる
可観測性とテスト: 全操作とhandoffを計装、LLM-as-judgeで評価
アンチパターン: 不要な複雑さ、特化しないエージェント追加、可変状態の共有
エージェントの構築（composable primitives）（OpenAI）
Building agents
Agents SDK（handoff・tools・traceなど実装の具体）
エージェントの定義: instructions（すべきこと）＋guardrails（すべきでないこと）＋ツール（できること）
4つのプリミティブ
models・ツール・state/memory・orchestration
モデル選択
reasoning model: chain of thoughtで考えてから答える。計画・数学・コード・多ツールに向く
非reasoning model: 高速・安価で会話的UXや単純タスクに向く
まず汎用フラッグシップから試し、用途に応じて軽量/高性能へ
構築の選択肢
Responses API: 柔軟でstateful、コアロジックを自分で組む
Agents SDK: 高水準の抽象化、エージェントループやhandoffを肩代わり
Agents SDKのプリミティブ
Agent（model＋instructions＋ツール）
Handoff（委譲先のエージェント）
Guardrail（不適切入力を弾く方針）
Session（会話履歴を自動保持）
tracingでツール呼び出しや発火ガードレールを観測
組み込みツール
web search・file search（RAG）・code interpreter・computer use・image generation・MCP
既存の組み込みツールがあればまずそれを使い、必要ならfunction callingで自作
マルチエージェント連携
最終手段。タスクが重ならず、指示が複雑またはツールが多すぎる場合に検討
routing agentが判断し適切なエージェントへhandoff
agent-as-tool: 一方のエージェントを他方の呼び出し可能ツールとして公開
ベストプラクティス
入力にガードレール、出力にstructured outputs（厳密なJSONスキーマで制約）
安全性（OpenAI「Safety in building agents」）
Safety in building agents
エージェントが任意テキストを処理してツール呼び出しへ影響させるとリスクが上がる
structured outputsや分離はリスクを下げるが完全には消えない
エージェント評価（OpenAI「Agent evals」「Trace grading」）
Agent evals
Trace grading
再現可能な評価でエージェント品質を測る
trace grading: 最終回答だけでなく、途中の意思決定やツール呼び出しの過程まで評価
ワークフローレベルのエラー特定に有効
本番向けパターンの体系（AWS）
Agentic AI patterns and workflows on AWS
Agentic workflow patterns
LLM workflows
agentic patternは目標指向AIエージェントを設計・オーケストレーションする再利用可能な枠組み
event-driven／サーバーレスからcognition-augmentedシステムへの発展と位置づける
3つの分類
agent patterns: 個々のエージェントの構造と振る舞い（reasoning agent・RAG agent・coding agent・voice interface・workflow orchestrator・マルチエージェント）
LLM workflows: LLMでの推論。prompting戦略とplanning機構
agentic workflow patterns: 複数エージェント・ツール・環境の相互作用
agentic workflow patterns の中身
prompt chaining saga
routing dynamic dispatch
parallelization scatter-gather
saga orchestration
evaluator reflect-refine loop
sagaの概念で分散システム的な信頼性と可監査性を担保する点が特徴
コード実装の入口とパターン（LangChain）
Multi-agent
Subagents
Router pattern: multi-source knowledge base
Agents（LangChainでのエージェント実装の基本）
複雑なタスクでも適切なツールとプロンプトがあればsingle agentで十分なことが多い
必要になってからsubagentsやrouterへ進めばよい
multi-agentが欲しくなる理由
context management: 文脈窓を溢れさせず専門知識を渡す
distributed development: チームが独立して機能を開発・保守
parallelization: サブタスクを並列実行
中心にあるのは文脈設計（各エージェントが何を見るか）
主要パターン
subagents: main agentがsubagentをツールとして調整。全ルーティングが中央を通る
handoffs: 状態変化で動的にルーティング/設定変更し制御を移譲
skills: 専門プロンプトと知識を必要時にロードし、単一エージェントが制御を保つ
router: 分類ステップが入力を専門エージェントへ振り分け、結果を統合
custom workflow: LangGraphで決定的ロジックとエージェント的挙動を混合
性能特性
statefulなhandoffs/skillsは反復リクエストで40〜50%の呼び出しを節約
並列実行できるsubagents/routerはmulti-domainタスクで効率的
skillsは呼び出し数は少ないが文脈蓄積でトークンが増えやすい
パターン名の対応関係（横断メモ）
順次連結: prompt chaining（Anthropic）≒sequential（Google CloudMicrosoft）≒prompt chaining saga（AWS）
振り分け: routing（Anthropic）≒handoff（Microsoft）≒coordinator/router（Google CloudLangChain）≒routing dynamic dispatch（AWS）
並列: parallelization（Anthropic）≒concurrent/parallel（MicrosoftGoogle Cloud）≒parallelization scatter-gather（AWS）
委譲統合: orchestrator-workers（Anthropic）≒hierarchical task decomposition（Google Cloud）≒subagents（LangChain）
生成と批評: evaluator-optimizer（Anthropic）≒review and critique/iterative refinement（Google Cloud）≒maker-checker（Microsoft）≒evaluator reflect-refine loop（AWS）