Anthropic の最新情報: AI エージェント 2024 年末概要!

データホエール

Datawhaleのヒント

著者: Anthropic Team、編集者: PaperAgent

2025年はエージェントシステムの年になるでしょう。コンピュータの利用、MCP（モデル・コンテキスト・プロトコル）、そして改良されたツールなど、すべてが整いました。今こそ、これらのシステムの構築について考え始める時です。

Anthropic は 2024 年のベストプラクティスをいくつかまとめ、「効果的なエージェントの構築方法」を共有しました。

過去1年間、Anthropicは様々な業界の数十のチームと協力し、大規模言語モデル（LLM）エージェントを構築してきました。最も成功した実装は、複雑なフレームワークや特殊なライブラリの使用を一貫して避け、代わりにシンプルで構成可能なパターンを用いて構築されています。

インテリジェントエージェントとは何ですか?

「エージェント」という用語には複数の定義があります。クライアントによっては、エージェントを、長期間にわたって独立して動作し、様々なツールを用いて複雑なタスクを遂行できる完全自律システムと定義する場合もあります。一方、定義済みのワークフローに従う、より規範的な実装を指す場合もあります。Anthropicでは、これらすべてのバリエーションをエージェントシステムとして分類していますが、ワークフローとエージェントの間には明確なアーキテクチャ上の境界線を設けています。

ワークフローは、事前定義されたコードパスを通じて LLM とツールを調整するシステムです。
一方、エージェントは、LLM 自身のプロセスとツールの使用を動的にガイドし、タスクの実行方法を制御するシステムです。

エージェントを使うべき時（そして使わない時）

LLMを使用してアプリケーションを構築する際は、可能な限りシンプルなソリューションを見つけ、必要な場合にのみ複雑さを増すことをお勧めします。これは、エージェントシステムを全く構築しないことを意味する場合もあります。エージェントシステムは通常、タスクパフォーマンスを向上させるためにレイテンシとコストを犠牲にするため、このトレードオフが妥当な場合を検討する必要があります。

フレームワークをいつ、どのように使用するか

エージェントシステムの実装を容易にするフレームワークは数多くあります。以下に例を示します。

LangChain の LangGraph;
Amazon Bedrock の AI エージェントフレームワーク。
ドラッグアンドドロップ GUI LLM ワークフロービルダーである Rivet。
Vellum は、複雑なワークフローを構築およびテストするためのもう 1 つの GUI ツールです。

これらのフレームワークは、LLMの呼び出し、ツールの定義と解決、呼び出しのリンクといった標準的な低レベルタスクを簡素化するため、容易に始めることができます。しかし、多くの場合、抽象化レイヤーが追加され、背後にあるヒントやレスポンスがわかりにくくなり、デバッグが困難になります。また、よりシンプルな設定で十分なのに、複雑な処理を追加してしまう誘惑に駆られることもあります。

開発者にはLLM APIを直接使用することをお勧めします。多くのパターンはわずか数行のコードで実装できます。フレームワークを使用する場合は、基盤となるコードを理解していることを確認してください。基盤となるメカニズムに関する誤った想定は、お客様によるエラーのよくある原因となります。

ビルディングブロック、ワークフロー、エージェント

このセクションでは、実運用環境で見られるエージェントシステムの一般的なパターンを探ります。まずは基本的な構成要素（拡張LLM）から始め、シンプルな構成ワークフローから自律エージェントへと、徐々に複雑さを増していきます。

ビルダーモジュール: 拡張 LLM

エージェントシステムの基本的な構成要素はLLM（Limited Least Metric）であり、これは検索、ツール、メモリといった機能によって強化されます。現在のモデルはこれらの機能を積極的に活用し、独自の検索クエリを生成し、適切なツールを選択し、保持する情報を決定することができます。

強化されたLLM

実装においては、これらの機能を特定のユースケースに合わせてカスタマイズすること、そしてLLM向けにシンプルで十分にドキュメント化されたインターフェースを提供することという、2つの重要な側面に重点を置くことをお勧めします。これらの機能強化を実装する方法は数多くありますが、その1つとして、最近リリースされたモデルコンテキストプロトコルが挙げられます。これにより、開発者はシンプルなクライアント側実装を通じて、成長を続けるサードパーティ製ツールのエコシステムと統合できるようになります。

このホワイトペーパーの残りの部分では、これらの拡張機能がすべての LLM 呼び出しにアクセスできるものと想定します。

ワークフロー: ヒントリンク

プロンプトチェーンはタスクを一連のステップに分割し、各LLM呼び出しは前の呼び出しの出力を処理します。プロセスが正しく継続されるように、任意の中間ステップに手続きチェック（下図の「ゲート」を参照）を追加できます。

ヒントチェーンワークフロー

このワークフローを使用するタイミング：このワークフローは、タスクを固定されたサブタスクに簡単かつ明確に分割できる状況に最適です。主な目的は、各LLM呼び出しをより単純なタスクにすることで、レイテンシを犠牲にしてより高い精度を達成することです。

ヒントチェーンの役立つ例:

マーケティングコピーを生成し、それをさまざまな言語に翻訳します。
文書のアウトラインを作成し、アウトラインが特定の基準を満たしているかどうかを確認し、アウトラインに基づいて文書を作成します。

ワークフロー: ルーティング

ルーティングは入力を分類し、専門的なフォローアップタスクに誘導します。このワークフローにより、関心の分離とより専門的なヒントの構築が可能になります。このワークフローがなければ、ある種類の入力を最適化すると、他の入力のパフォーマンスに悪影響を与える可能性があります。

ルーティングワークフロー

このワークフローを使用する場合: ルーティングは、別々に処理する方が最適なさまざまなカテゴリがあり、分類が LLM または従来の分類モデル/アルゴリズムによって正確に処理できる複雑なタスクに適しています。

ルーティングの便利な例:

さまざまな種類のカスタマーサービス問い合わせ (一般的な質問、払い戻しリクエスト、テクニカルサポート) を、さまざまな下流のプロセス、プロンプト、およびツールに誘導します。
コストと速度を最適化するために、単純/一般的な問題はより小さなモデル (Claude 3.5 Haiku など) にルーティングされ、難しい/一般的でない問題はより強力なモデル (Claude 3.5 Sonnet など) にルーティングされます。

ワークフロー: 並列化

LLMは、タスクを並行して実行し、その出力をプログラム的に集約できる場合があります。このワークフロー（並列化）は、2つの重要な変化として現れます。

セグメンテーション: タスクを、並行して実行される独立したサブタスクに分解します。
投票: 同じタスクを複数回実行して、異なる出力を取得します。

並列化ワークフロー

このワークフローを使用する場合：並列化は、サブタスクを並列化することで速度を向上できる場合、またはより信頼性の高い結果を得るために複数の視点や試行が必要な場合に効果的です。複数の考慮事項を伴う複雑なタスクでは、各考慮事項を個別のLLM呼び出しで処理することで、それぞれの特定の側面に注意を集中できるため、LLMのパフォーマンスは通常向上します。

並列化の有用な例:

スライス：
ガードレールを実装し、1つのモデルインスタンスでユーザークエリを処理し、別のモデルインスタンスで不適切なコンテンツやリクエストをフィルタリングします。これは、ガードレールとコアレスポンスの両方を同じLLM呼び出しで処理するよりも効果的です。
LLM パフォーマンスを自動的に評価します。各 LLM 呼び出しでは、指定されたプロンプトに基づいてモデルのパフォーマンスのさまざまな側面が評価されます。
投票する：
コードの脆弱性をレビューします。コードのレビューには複数のプロンプトが使用され、問題が見つかった場合はコードにフラグが付けられます。
特定のコンテンツが不適切かどうかを評価するために、複数のプロンプトを使用してさまざまな側面を評価したり、誤検知と誤検知のバランスをとるために異なる投票しきい値が必要になる場合があります。

ワークフロー: オーケストレーターワーカー

オーケストレーターワーカーワークフローでは、中央 LLM がタスクを動的に分解し、ワーカー LLM に委任して、結果を合成します。

オーケストレーターとワーカーのワークフロー

このワークフローを使用する場合：このワークフローは、必要なサブタスクを予測できない複雑なタスク（例えば、コーディングにおいて、変更が必要なファイルの数や各ファイルの変更内容がタスクによって異なる場合）に適しています。トポロジ的には並列化と似ていますが、並列化との主な違いは柔軟性にあります。サブタスクは事前に定義されておらず、オーケストレーターが特定の入力に基づいて決定します。

オーケストレーターワーカーの有用な例:

毎回複数のファイルに複雑な変更を加えるエンコードされた製品。
検索タスクには、複数のソースから情報を収集して分析し、関連性のある可能性のある情報を取得することが含まれます。

ワークフロー: 評価者 - 最適化者

評価者-最適化者のワークフローでは、1 つの LLM 呼び出しが応答を生成し、別の呼び出しがループ内で評価とフィードバックを提供します。

評価者-最適化ワークフロー

このワークフローを使用するタイミング：このワークフローは、明確な評価基準があり、反復的な改善によって測定可能な価値が得られる場合に特に効果的です。適合性の指標として、まず、人間がフィードバックを表明することでLLMの応答が大幅に改善されること、そしてLLMがそのようなフィードバックを提供できることが挙げられます。これは、人間のライターが美しい文書を作成する際に行う反復的なライティングプロセスに似ています。

評価器と最適化器の便利な例:

文学翻訳には、翻訳者 (LLM) が最初は捉えられない微妙な違いがありますが、評価者 (LLM) は有益な批評を提供できます。
複雑な検索タスクでは、包括的な情報を収集するために複数回の検索と分析が必要であり、その後、評価者はさらなる検索が必要かどうかを決定します。

エージェント

インテリジェントエージェントは複雑なタスクを処理できますが、その実装は非常に単純な場合が多いです。通常、環境からのフィードバックに基づくツールを備えたLLMのみを使用します。そのため、ツールセットとそのドキュメントの明確で思慮深い設計が不可欠です。

自律型インテリジェントエージェント

エージェントを使用する場合：エージェントは、必要なステップ数を予測することが困難または不可能で、固定パスをハードコードできないようなオープンエンド問題に使用できます。LLMは複数ラウンド実行される可能性があり、その決定にはある程度の信頼が必要です。エージェントの自律性は、信頼できる環境でのタスクのスケーリングに最適です。

インテリジェントエージェントの自律性は、コストの増加と複合的なエラーの発生可能性の増加を伴います。適切な安全対策を講じたサンドボックス環境で、広範囲にわたるテストを実施することをお勧めします。

インテリジェントエージェントの有用な例:

次の例は、私たち独自の実装からのものです。

コード化されたエージェントは、タスクの説明に従って多数のファイルを編集する SWE ベンチタスクを解決するために使用されます。
「コンピュータの使用」リファレンス実装では、クロードさんがコンピュータを使用してタスクを完了する様子を示します。

インテリジェントエージェントのコーディングの高度なプロセス

これらのパターンを組み合わせてカスタマイズする

これらのビルディングブロックは規範的なものではありません。開発者が様々なユースケースに合わせて形を整え、組み合わせることができる共通のパターンです。他のLLM機能と同様に、成功の鍵はパフォーマンスの測定と反復的な実装です。繰り返しますが、複雑さの追加は、結果が大幅に改善される場合にのみ検討すべきです。

概要要約

LLM分野での成功は、最も複雑なシステムを構築することではありません。ニーズに合ったシステムを構築することにあります。シンプルなプロンプトから始め、包括的な評価を通じて最適化し、シンプルなソリューションでは不十分な場合にのみ、複数ステップのエージェントシステムを追加してください。

インテリジェントエージェントを実装する際には、次の 3 つの基本原則に従うようにしています。

インテリジェントエージェントの設計はシンプルに保ちます。
エージェントの計画された手順を明確に示すことで、透明性を優先する必要があります。
包括的なツールのドキュメントとテストを通じて、エージェントコンピュータインターフェイス (ACI) を慎重に設計します。

フレームワークは迅速な開発開始に役立ちますが、本番環境へのデプロイでは、抽象化レイヤーを減らし、基本的なコンポーネントを使用して構築することを躊躇しないでください。これらの原則に従うことで、強力なだけでなく、信頼性、保守性、そしてユーザーからの信頼も得られるインテリジェントエージェントを作成できます。

付録1：エージェントの実践

お客様との協働により、前述のモデルの実用的価値を示す、特に有望なAIエージェントの2つの応用例を特定しました。どちらの応用例も、明確に定義された成功基準、フィードバックループの実現、そして有意義な人間による監督を統合することで、対話とアクションを必要とするタスクにエージェントが最大限の価値を付加できることを示しています。

A. カスタマーサポート

カスタマーサポートは、使い慣れたチャットボットインターフェースとツール統合による高度な機能を統合します。これは、よりオープンなエージェントにとって自然な選択です。その理由は次のとおりです。

会話の流れに沿った自然なやりとりをサポートしますが、外部の情報や操作へのアクセスも必要です。
ツールを統合して顧客データ、注文履歴、ナレッジベースの記事を抽出できます。
払い戻しやチケットの更新はプログラムで処理できます。
成功は、ユーザー定義の解像度を使用して明示的に測定できます。

いくつかの企業は、成功したソリューションに対してのみ料金を請求する使用量ベースの価格設定モデルを通じてこのアプローチの実現可能性を実証し、エージェントの効率性に対する信頼を示しました。

B. エンコードエージェント

ソフトウェア開発分野は、コード補完から自律的な問題解決へと進化し、LLM機能の大きな可能性を実証してきました。エージェントが特に効果的なのは、以下の理由からです。

コードソリューションは自動テストを通じて検証できます。
エージェントはテスト結果をフィードバックとして使用してソリューションを反復できます。
問題領域は明確に定義され、明確に構造化されています。
出力品質を客観的に測定できます。

弊社の実装では、エージェントはプルリクエストの説明のみに基づいて、SWE-bench Verified ベンチマークにおける実際の GitHub の問題を解決できるようになりました。ただし、自動テストは機能検証に役立ちますが、ソリューションがより広範なシステム要件を満たしていることを確認するためには、人間によるレビューが依然として不可欠です。

付録2: ツールを素早く設計する

構築するエージェントシステムの種類に関わらず、ツールはエージェントにとって重要なコンポーネントとなるでしょう。外部サービスやAPIの構造と定義をAPIで正確に指定することで、ツールはClaudeがそれらとやり取りすることを可能にします。Claudeが応答する際にツールを呼び出す場合は、APIレスポンスにツール使用ブロックが含まれます。ツールの定義と仕様は、全体的なエンジニアリング作業と同様に注意を払う必要があります。この短い付録では、ツールをタイムリーにエンジニアリングする方法について説明します。

通常、同じ操作を指定する方法は複数あります。例えば、ファイル編集を指定するには、diff を書き込むか、ファイル全体を書き換えます。構造化された出力の場合は、Markdown または JSON 形式でコードを返すことができます。ソフトウェアエンジニアリングでは、これらの違いは表面的なものであり、品質を損なうことなく、ある形式から別の形式に変換できます。しかし、LLM では、一部の形式は他の形式よりも記述が難しくなります。diff を書き込むには、新しいコードを書き込む前に、ブロックヘッダーの行数が何行変更されたかを把握する必要があります。JSON 形式でコードを記述する場合は（Markdown 形式と比較して）、改行文字と引用符のエスケープ処理がさらに必要になります。

ツールの形式を決定するための推奨事項は次のとおりです。

モデルが行き詰まる前に「考える」のに十分なラベルをモデルに与えます。
モデルがインターネット上のテキストに自然に表示される形式と同様の形式を維持します。
何千行ものコードを正確に数えたり、記述するコードに対して文字列をエスケープしたりする必要があるなど、フォーマットの「オーバーヘッド」がないことを確認します。

一つの目安として、これまでヒューマン・コンピュータ・インターフェース（HCI）にどれだけの労力を費やしてきたかを考え、優れたエージェント・コンピュータ・インターフェース（ACI）の構築にも同等の労力を費やす計画を立てましょう。その方法について、いくつかアイデアをご紹介します。

モデルの視点から考えてみましょう。説明とパラメータに基づいて、ツールの使用方法は明らかでしょうか、それとも慎重な検討が必要でしょうか？もしそうであれば、モデルもそれに従う可能性が高いでしょう。優れたツール定義には通常、使用例、極端なケース、入力形式の要件、そして他のツールとの明確な境界が含まれています。
パラメータ名や説明をどのように変更すれば、より分かりやすくなるでしょうか？チームの若手開発者向けに、分かりやすいドキュメントを書くようなものだと考えてみてください。これは、類似のツールを多数使用する場合、特に重要です。
モデルがツールをどのように使用するかをテストします。ワークベンチで多くのサンプル入力を実行し、モデルがどのような間違いをするかを確認してから、反復します。
エラー防止方法: 議論を変更して、間違いを起こしにくくします。

SWE-bench 向けエージェントの構築にあたっては、全体的なヒントよりもツールの最適化に多くの時間を費やしました。例えば、エージェントをルートディレクトリから移動した後、相対ファイルパスを使用するツールを使用するとモデルがエラーをスローすることがわかりました。これを修正するために、ツールを常に絶対ファイルパスを要求するように変更したところ、モデルがこのアプローチを完璧に実行していることがわかりました。

 https://github.com/anthropics/anthropic-cookbook/tree/main/patterns/agentshttps://www.anthropic.com/research/building-effective-agents

いいね！（3件のいいね！）↓

618ZXW