以下の内容は Anthropic 公式サイトの技術記事を転載し、AI によって翻訳されたものです。原文の全文は、こちらのリンクからご覧いただけます：https://www.anthropic.com/engineering/building-effective-agents
私たちは、あらゆる業界で LLM エージェントを構築している数十のチームと協力してきました。一貫して、最も成功している実装は、複雑なフレームワークではなく、シンプルで構成可能なパターンを使用しています。
過去 1 年間、私たちは大言語モデル (LLM) エージェントを構築している数十のチームと協力してきました。一貫して、最も成功した実装は、複雑なフレームワークや特殊なライブラリを使用したものではありませんでした。代わりに、それらはシンプルで構成可能なパターンを使用して構築されていました。
本記事では、お客様との協力や自社でのエージェント開発から学んだ教訓を共有し、開発者が効果的なエージェントを構築するための実践的なアドバイスを提供します。
エージェントとは何か？#
「エージェント」はいくつかの方法で定義されます。あるお客様は、エージェントを、さまざまなツールを使用して複雑なタスクを長期間自律的に実行する完全自律型システムと定義しています。また、定義済みのワークフローに従うより規定的な実装を指すためにこの用語を使用する方もいます。Anthropic では、これらすべてのバリエーションをエージェント型システム (agentic systems) と分類していますが、アーキテクチャとしてワークフロー (workflows) とエージェント (agents) を明確に区別しています。
- ワークフロー：LLM とツールが定義済みのコードパスを通じてオーケストレーションされるシステム。
- エージェント：LLM が自身のプロセスやツール使用を動的に指示し、タスクの達成方法を自ら制御するシステム。
以下では、これら両方のタイプのエージェント型システムについて詳しく説明します。付録 1（「エージェントの例」）では、お客様がこの種のシステムに特に価値を見出した 2 つの領域について説明します。
エージェントをいつ使うべきか（あるいは使うべきでないか）#
LLM を使用してアプリケーションを構築する際は、まず最もシンプルな解決策を探し、必要な場合にのみ複雑さを増していくことを推奨します。これは、エージェント型システムをまったく構築しないことを意味する場合もあります。エージェント型システムは、多くの場合、タスクのパフォーマンス向上のためにレイテンシとコストを犠牲にします。このトレードオフがいつ理にかなうかを検討する必要があります。
高い複雑さが正当化される場合、ワークフローは定義の明確なタスクに対して予測可能性と一貫性を提供します。一方、エージェントは柔軟性とモデル駆動型の意思決定が大規模に必要とされる場合に適した選択肢となります。しかし、多くのアプリケーションでは、検索（retrieval）とコンテキスト内での例示を用いて単一の LLM コールを最適化するだけで十分です。
フレームワークの使用時期と方法#
エージェント型システムの構築を容易にするフレームワークは多数存在します：
- Claude Agent SDK
- AWS Strands Agents SDK
- Rivet: ドラッグアンドドロップで LLM ワークフローを構築できる GUI ツール
- Vellum: 複雑なワークフローを構築・テストするための別の GUI ツール
これらのフレームワークは、LLM の呼び出し、ツールの定義と解析、呼び出しの連結など、標準的な低レベルのタスクを簡素化することで、簡単に使い始めることができます。しかし、抽象化レイヤーが追加されることで、背後にあるプロンプトやレスポンスが見えにくくなり、デバッグが困難になることがよくあります。また、シンプルな構成で十分な場合に不必要な複雑さを加えたくなる誘惑にも駆られます。
開発者の皆様には、まず LLM API を直接使用することをお勧めします。多くのパターンは数行のコードで実装可能です。フレームワークを使用する場合は、その内部コードを理解するようにしてください。内部の挙動に関する誤った推測は、よくあるエラーの原因です。
サンプルの実装については、Cookbook をご覧ください。
構成要素、ワークフロー、エージェント#
このセクションでは、本番環境で見られる一般的なエージェント型システムのパターンについて詳しく説明します。まず、基礎となる構成要素である「拡張 LLM」から始め、シンプルな構成ワークフローから自律型エージェントへと、段階的に複雑さを増していきます。
構成要素：拡張 LLM#
エージェント型システムの基本要素は、検索、ツール、メモリなどの機能（拡張）を加えた LLM です。現在のモデルは、自ら検索クエリを生成し、適切なツールを選択し、保持すべき情報を決定するなど、これらの機能を能動的に活用できます。
拡張 LLM
実装においては、これらの能力を特定のユースケースに合わせて調整すること、およびモデルに対して使いやすく文書化されたインターフェースを提供することの 2 点に重点を置くことをお勧めします。最近リリースされた Model Context Protocol (MCP) を使用すると、サードパーティ製ツールのエコシステムを簡単に統合できます。
以下では、各 LLM 呼び出しがこれらの拡張機能にアクセスできることを前提とします。
ワークフロー：プロンプト・チェイニング (Prompt chaining)#
プロンプト・チェイニングは、タスクを一連のステップに分解し、各 LLM 呼び出しが前の呼び出しの出力を処理する手法です。プロセスが軌道に乗っていることを確認するために、中間ステップにプログラム的なチェック（下図の “gate”）を追加できます。
プロンプト・チェイニング・ワークフロー
いつこのワークフローを使うべきか： タスクが固定のサブタスクに容易かつ明確に分解できる場合に最適です。主な目標は、各 LLM 呼び出しをより簡単なタスクにすることで、精度の向上を図ることです。
有用な例：
- マーケティングコピーを生成し、それを別の言語に翻訳する。
- 文書の構成案を作成し、基準を満たしているかチェックした上で、その構成案に基づいて文書を執筆する。
ワークフロー：ルーティング (Routing)#
ルーティングは、入力を分類し、それを専門のフォローアップタスクに振り分けます。このワークフローにより、関心の分離（Separation of Concerns）が可能になり、より専門的なプロンプトを構築できます。
ルーティング・ワークフロー
いつこのワークフローを使うべきか： 複雑なタスクにおいて、明確に分けられたカテゴリが存在し、分類が LLM や従来のアルゴリズムによって正確に行える場合に適しています。
有用な例：
- 異なる種類のカスタマーサービスへの問い合わせ（一般的な質問、返金リクエスト、技術サポート）を、それぞれ異なる下流のプロセス、プロンプト、ツールに振り分ける。
- 簡単な質問は低コストな Claude 4.5 Haiku に、複雑な質問は Claude 4.5 Sonnet にルーティングしてパフォーマンスを最適化する。
ワークフロー：並列化 (Parallelization)#
LLM が同時にタスクに取り組み、その出力をプログラムで集約する手法です。主に 2 つのバリエーションがあります：
- セクショニング：タスクを独立したサブタスクに分解して並列実行する。
- 投票 (Voting)：同じタスクを複数回実行し、多様な出力を得る。
並列化ワークフロー
いつこのワークフローを使うべきか： 並列処理によって速度を向上させたい場合や、高い信頼性を得るために複数の視点や試行が必要な場合に効果的です。
有用な例：
- セクショニング：ガードレールとして、あるモデルインスタンスがユーザーの回答を処理する一方で、別のインスタンスで不適切な内容がないかチェックする。
- 投票：コードの脆弱性をチェックする際、複数のプロンプトでレビューし、問題が見つかった場合にフラグを立てる。
ワークフロー：オーケストレーター・ワーカー (Orchestrator-workers)#
中央の LLM が動的にタスクを分解し、ワーカー LLM に割り当て、結果を合成するワークフローです。
オーケストレーター・ワーカー・ワークフロー
いつこのワークフローを使うべきか： 必要なサブタスクが予測できない複雑なタスク（プログラミングなど）に適しています。並列化との主な違いは、サブタスクが事前に定義されているのではなく、オーケストレーターによって動的に決定される柔軟性にあります。
ワークフロー：エバリュエーター・オプティマイザー (Evaluator-optimizer)#
一つの LLM が回答を生成し、別の LLM が評価とフィードバックを提供してループを回します。
エバリュエーター・オプティマイザー・ワークフロー
いつこのワークフローを使うべきか： 明確な評価基準があり、反復的な改善が測定可能な価値をもたらす場合に特に効果的です。
エージェント (Agents)#
LLM が複雑な入力の理解、推論と計画、ツールの信頼性の高い使用、エラーからの回復といった主要な能力において成熟するにつれ、エージェントが本番環境で登場し始めています。エージェントは自律的に計画を立てて行動し、実行中は環境からの「グラウンドトゥルース（事実）」を確認しながら進みます。
自律型エージェント
いつエージェントを使うべきか： 固定のパスをハードコードできない開放的な問題に適しています。自律性はコストやエラーの蓄積を伴う可能性があるため、サンドボックス環境での広範なテストが不可欠です。
(付録などは必要に応じて省略または要約されています。)