필사 모드: 効果的なAIエージェントを作る — 5つのワークフローパターンとエージェントのリファレンス

• はじめに — ワークフロー、エージェント、そして増強されたLLM
• 5つのワークフローパターン
• 自律エージェント — ループ、そしていつ持ち出すか
• 失敗モード — 過剰設計、暴走ループ、コストとレイテンシ
• フレームワーク — 速い着手、デバッグの代償
• おわりに — 単純さ・透明性・ACI
• 参考資料

はじめに — ワークフロー、エージェント、そして増強されたLLM

「エージェント」という言葉がインフレを起こす一方で、Anthropicのエンジニアリングガイド Building Effective Agents は、めずらしく落ち着いた定義から始まります。この記事は、そのガイドを実務で開くリファレンスとして再構成したものです。中心にある区別は1つです。

• ワークフロー(workflow)。 LLMとツールが、人があらかじめ定めたコード経路(「predefined code paths」、Anthropic)で編成されるシステムです。流れは開発者が固定します。
• エージェント(agent)。 LLMが自らのプロセスとツール使用を動的に指揮し、どうタスクを達成するかの制御を握るシステムです。流れはモデルが実行時に決めます。

この2つの上に、ガイド全体を貫く助言が1つあります。最も高度なシステムではなく、 ニーズに合った正しいシステム を作れ、というものです。単純なプロンプトから始め、包括的な評価で最適化し、より単純な解では足りないときだけ多段のエージェントシステムを足す、と述べます。

すべてのパターンの底には 増強されたLLM(augmented LLM) があります。ただテキストを吐くモデルではなく、3つの能力を備えたモデルです。

• 検索(retrieval)。 自ら検索クエリを生成し、必要な情報を引き寄せます。
• ツール(tools)。 状況に合うツールを選び、外部システムに実際の行動を起こします。
• メモリ(memory)。 何を残し何を捨てるかを判断し、次のステップへ引き継ぎます。

ツール統合は Model Context Protocol(MCP) のような標準で繋ぐことを勧めています。このブロックが、以下すべてのパターンの原子単位です。

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

まず腹に入れておくこと。以下の5つはすべて ワークフロー です。LLM呼び出しが何度現れても、その順序と配線はコードが固定します。自律エージェントは次の節で別に扱います。

表はクイックリファレンスで、各パターンが実際にどう動くかを以下に1行ずつ足します。

• プロンプトチェイニング。 タスクを順次ステップに分け、各LLM呼び出しが前ステップの出力を入力として受け取ります。ステップ間にプログラム的なゲート(形式・条件チェック)を置き、崩れた出力が次へ漏れるのを防ぎます。レイテンシは増えますが、呼び出しごとに1つに集中させるので精度が上がります。
• ルーティング。 まず入力を分類し、専用のプロンプトやモデルへ流します。関心が分離され、経路ごとに個別に最適化でき、1つのプロンプトに全ケースを詰め込むときの品質低下を避けられます。
• 並列化。 セクショニングは独立した下位タスクを同時に回してレイテンシを削り、ボーティングは同じ入力を複数回回して結果を集約します(多数決・合意)。回答生成と安全スクリーニングを分けるガードレールのように、1つの呼び出しに混ぜると互いに邪魔になるものを切り離すときに特に有効です。
• オーケストレーター/ワーカー。 中央のLLMが問題を実行時に下位タスクへ分解し、ワーカーに委譲して結果を統合します。下位タスクの数と形をコードではなくモデルが決める点が並列化との決定的な違いで、だからこのパターンはワークフローとエージェントの境界に立ちます。
• エバリュエーター/オプティマイザー。 一方のLLMが草案を作り、もう一方が評価とフィードバックを与えるループを回します。明確な評価基準があり、反復が結果を実際に改善するときにのみ元を取ります — 基準が曖昧なら、ループはコストを燃やすだけです。

最後に、この5つは排他的ではありません。実際のシステムはたいていこれらを重ねて使います — ルーティングの後にプロンプトチェイニングを置いたり、オーケストレーターのワーカーが内部で並列化を呼んだり、といった具合です。パターンはレゴブロックであって、宗教ではありません。

自律エージェント — ループ、そしていつ持ち出すか

自律エージェントは華やかに見えますが、実装はたいてい単純です。Anthropicの言い方を借りれば、エージェントは 環境フィードバックに基づいてループの中でツールを使うLLM に近いものです。各ステップでツールの結果やコード実行の出力といった「グラウンドトゥルース(ground truth)」を得て、自ら進捗を判断します。

エージェントのループ (概念)
  1. 人が目標を与える (または対話で範囲を絞る)
  2. LLMが計画し、ツールを呼ぶ
  3. 環境が結果を返す   = グラウンドトゥルース
  4. LLMが結果を見て判断する: 終わったか? それとも2へ戻って反復
  5. 停止条件: 完了判定 ・ ステップ予算 ・ 人のチェックポイント

ここで肝心なのは「グラウンドトゥルース」です。エージェントを単なるチャットボットと分けるのは、各ステップで環境から来る実際の信号 — ツールが成功したか、コードが通ったか — で自らの判断を正す点です。このフィードバックの輪がなければ、それはただ複数回呼ばれるプロンプトにすぎません。

いつワークフローの代わりにエージェントを使うか。 よく定義されたタスクで、予測可能性と一貫性が重要ならワークフローが勝ります。必要なステップ数を予測できず、固定経路をハードコードできないときに、はじめてエージェントが元を取ります。ただし代償があります。ガイドは、エージェント的システムは「レイテンシとコストを、より良いタスク性能と引き換える(trade latency and cost for better task performance)」と明言します。この交換が理にかなう瞬間にだけ持ち出すべきです。手早い判断チェックリスト:

• ステップ数と経路を事前に描けるか → ならばワークフロー。
• 同じ入力に対して一貫し再現可能な結果が重要か → ワークフロー。
• 必要なツールとステップが入力ごとに変わり予測できないか → エージェント。
• 増えるレイテンシとコストを性能向上で正当化できるか → できないならエージェントは見送る。

ACIが半分を占める。 エージェントの成否はツール設計に大きく依存します。Anthropicはこれをエージェント/コンピュータ・インターフェース(agent-computer interface、ACI)と呼び、人にAPIを文書化するのと同じ丁寧さで、ツールを文書化しテストせよと強調します。曖昧なスキーマと薄いツール説明は、エージェント失敗の最も多い根本原因です。

付録は、エージェントがよく合う2つの領域を挙げます。 カスタマーサポート は会話の流れに乗りつつ外部情報と行動(照会・返金など)を必要とし、成功は解決件数で明確に測れます — 一部の企業は、成功した解決にのみ課金する従量課金を使うほど自信を見せています。

コーディング は解を自動テストで検証できるため特によく合います。エージェントはテスト結果をフィードバックに反復し、AnthropicはSWE-bench VerifiedでPR説明だけから実際のGitHubイシューを解いた事例を挙げます。それでも、解がより広いシステム要件に合うかは、依然として人のレビューが不可欠です。

失敗モード — 過剰設計、暴走ループ、コストとレイテンシ

リファレンスが有用であるためには、うまくいく絵だけでなく、よく壊れる箇所も記録する必要があります。

• 過剰設計と早すぎるフレームワーク。 最初の一手として重いエージェントフレームワークを持ち出すのが、最も多い失敗です。フレームワークは着手を容易にしますが、下にあるプロンプトと応答を覆い隠す抽象化の層を足し、デバッグを難しくするとガイドは警告します。LLM APIを直接使うところから始め、複雑さは「それが結果を明確に改善するときにのみ(only when it demonstrably improves outcomes)」足してください。
• 暴走するループ。 エージェントは本質的にループなので、停止条件がないと同じ誤りを繰り返し、トークンとコストを燃やします。ステップ上限、タイムアウト、人のチェックポイントを必ず入れましょう。計画ステップを外に見せる 透明性 が、こうした暴走を早期に捕まえます。
• コストとレイテンシ。 すべてのステップが追加のLLM呼び出しです。マルチエージェントやボーティングはトークンを何倍も使います。まずユーザー向けのレイテンシ予算に実際に収まるか測ってください — 性能が上がっても、応答が遅すぎれば製品では使えません。
• ツール設計の放置。 先に述べたACIをプロンプトと同じ丁寧さで扱わなければ、どれほど強いモデルでも、まずい設計のツールの前で迷います。
• 評価の省略。 エージェントの複雑さを乗せながら、それが単純なベースラインより実際に優れているかを測らないこと。ガイドの処方は明確です — 単純なプロンプトを包括的な評価で磨き、より単純な解では足りないときにのみ複雑さを足すこと。

フレームワーク — 速い着手、デバッグの代償

ガイドはエージェントフレームワークを正面から扱います。Claude Agent SDKのようなSDKや、Rivet・VellumのようなGUIビルダーは着手の敷居を下げてくれますが、代償があります — 下にあるプロンプトと応答を覆い隠す抽象化の層を足し、実際に何がモデルへ入り、何が出てくるのかを見えにくくして、デバッグを複雑にします。

そこで推奨は淡白です。LLM APIを直接使って基礎を理解したうえで、その抽象化が正確に何をしてくれるのかを知ってからフレームワークを導入せよ、というものです。フレームワークが悪いという話ではなく、土台を知らないまま乗せた利便性は、問題が起きたときにかえって足を引っ張るという話です。

おわりに — 単純さ・透明性・ACI

ガイドが示すエージェント実装の3つの核心原則が、きれいな要約になります。

• 単純さ。 設計を単純に保ち、複雑さは結果が明確に改善するときにのみ足します。
• 透明性。 エージェントの計画ステップを隠さず、明示的に見せます。
• ACI。 十分なツール文書化とテストを通じて、エージェント/コンピュータ・インターフェースを丁寧に作ります。

実務に残る教訓は淡白です。ほとんどの本番の問題は、単一のLLM呼び出しか、1つか2つのワークフローパターンで十分に解けます。本当に自律エージェントが必要な瞬間は思うよりまれで、そのまれさを認める判断そのものが良いエンジニアリングです。成功とは最も高度なシステムを建てることではなく、ニーズに合った正しいものを選ぶこと — その一文が、このリファレンスの要点です。

参考資料

• Anthropic — Building Effective Agents (エンジニアリングガイド、原典)
• Anthropic Cookbook — patterns/agents (5パターンの最小実装コード)
• Model Context Protocol — Introduction (ツール統合の標準)