効果的なAIエージェントの構築
(anthropic.com)- Anthropicの現場での経験では、成功するLLMエージェントは複雑なフレームワークよりも、シンプルで組み合わせ可能なパターンから出発することが多い
- エージェント型システムは、定められたコードパスに従うワークフローと、LLMが手順やツール利用を動的に決定するエージェントに分かれる
- 多くのLLMアプリケーションは、単一のLLM呼び出しに検索とインコンテキスト例を加える程度で十分であり、複雑さは評価によって効果が確認されたときにのみ増やすべき
- フレームワークは立ち上がりを速くしてくれるが、プロンプトと応答を隠す抽象化レイヤーのためにデバッグを難しくすることがある
- 自律エージェントはオープンエンドな問題に強い一方で、コスト増加とエラー蓄積のリスクがあるため、サンドボックステスト、ガードレール、明確なツール設計が必要
エージェント型システムの基本的な区分
- エージェント型システムは、長期間にわたり独立して動作する完全自律システムから、事前定義されたワークフローに従う実装まで、広く使われる用語
- Anthropicはこれらのバリエーションをすべてエージェント型システムとみなしつつ、アーキテクチャ上は次の2つに分けている
- ワークフロー: LLMとツールが事前定義されたコードパスに沿ってオーケストレーションされる
- エージェント: LLMがタスクの実行方法、手順、ツール利用を動的に指示し制御する
いつエージェントを使うかを判断する基準
- LLMアプリケーションは、可能な限り最もシンプルな解決策から始め、必要なときだけ複雑さを高める進め方が推奨される
- エージェント型システムは、より高いタスク性能を得る代わりにレイテンシとコストを受け入れる構造なので、このトレードオフが本当に必要かを先に確認すべき
- 複雑さが必要な場合でも、選択基準は異なる
- よく定義されたタスクには、ワークフローが予測可能性と一貫性を提供する
- 大規模な柔軟性とモデル主導の意思決定が必要なタスクには、エージェントの方が適している
- 多くのアプリケーションは、検索とインコンテキスト例によって単一のLLM呼び出しを最適化するだけで十分
フレームワーク使用の基準
- エージェント型システム実装ツールとして、Claude Agent SDK、Strands Agents SDK by AWS、Rivet、Vellumが紹介されている
- こうしたフレームワークは、LLM呼び出し、ツール定義とパース、呼び出し接続といった低レベルの標準作業を単純化し、立ち上がりを速くする
- ただし追加の抽象化レイヤーは、実際のプロンプトと応答を隠してデバッグを難しくすることがある
- シンプルな構成で十分な場面でも、不必要な複雑さを加える方向に誘導することがある
- 開発者はまず、LLM APIを直接使う方法から始めるのがよい
- 多くのパターンは数行のコードで実装できる
- フレームワークを使う場合でも、内部コードの動作を理解する必要がある
- 内部動作についての誤った前提は、顧客向け障害のよくある原因
- サンプル実装はcookbookで確認できる
基本ビルディングブロック: 拡張LLM
- エージェント型システムの基本ビルディングブロックは、検索、ツール、メモリなどの機能で強化された拡張LLM
- 現在のモデルは、検索クエリを自ら作成し、適切なツールを選び、どの情報を保持するかを決める形で、これらの機能を能動的に利用できる
- 実装では、次の2点に集中すべき
- ユースケースに合わせて機能を調整する
- LLMが使いやすい文書化されたインターフェースを提供する
- 実装方法の1つとして、Model Context Protocolが紹介されている
- 開発者はシンプルなclient implementationを通じて、サードパーティーツールのエコシステムと統合できる
ワークフローパターン
-
プロンプトチェイニング
- プロンプトチェイニングは、タスクを順次段階に分け、各LLM呼び出しが前の呼び出しの出力を処理する方式
- 中間段階ごとにプログラム的なチェックを入れ、プロセスが正常な経路にあるか確認できる
- タスクが固定されたサブタスクへきれいに分解できる場合に適している
- 主なトレードオフは、レイテンシを受け入れる代わりに各LLM呼び出しの難度を下げて精度を高めること
- 例
- マーケティング文言を生成した後、別の言語へ翻訳する
- 文書のアウトラインを作成し、基準を満たしているか確認し、そのアウトラインに基づいて文書を書く
-
ルーティング
- ルーティングは、入力を分類してから特化した後続処理へ送る方式
- 関心事を分離し、より特化したプロンプトを作れる
- この構造がないと、ある種類の入力への最適化が別の入力の性能を損なうことがある
- 異なるカテゴリが個別処理に適しており、LLMまたは従来型の分類モデル/アルゴリズムが正確に分類できる場合にうまく機能する
- 例
- 一般的な質問、返金依頼、技術サポートといったカスタマーサービスの問い合わせを、それぞれ異なるプロセス、プロンプト、ツールへ振り分ける
- 簡単・一般的な質問はClaude Haiku 4.5のような小さくコスト効率の高いモデルへ、難しいまたは特殊な質問はClaude Sonnet 4.5のようなより強力なモデルへルーティングする
-
並列化
- 並列化は、LLMが1つのタスクを同時に処理し、出力をプログラム的に集約する方式
- 2つの主要なバリエーションがある
- セクショニング: タスクを独立したサブタスクに分けて並列実行する
- 投票: 同じタスクを複数回実行して多様な出力を得る
- サブタスクを分けて速度を上げられる場合や、より高い信頼性のために複数の観点や試行が必要な場合に効果的
- 複雑なタスクで各考慮事項を別々のLLM呼び出しが担当すると、特定の側面により集中できる
- 例
- あるモデルインスタンスがユーザークエリを処理し、別のインスタンスが不適切なコンテンツやリクエストを検査するガードレール
- LLM性能評価において、各呼び出しがモデル性能の異なる側面を評価する
- 複数のプロンプトがコード脆弱性をレビューし、問題が見つかればフラグを立てる
- コンテンツ不適切性評価で、複数のプロンプトと投票しきい値を活用し、偽陽性と偽陰性のバランスを調整する
-
オーケストレーター-ワーカー
- オーケストレーター-ワーカーは、中央のLLMがタスクを動的に分解し、ワーカーLLMへ委任したうえで結果を統合する方式
- 必要なサブタスクを事前に予測できない複雑なタスクに適している
- 並列化と似て見えるが、核心的な違いは柔軟性
- 並列化ではサブタスクが事前定義されている
- オーケストレーター-ワーカーでは入力に応じてオーケストレーターがサブタスクを決める
- 例
- 毎回複数ファイルに複雑な変更を行うコーディング製品
- 複数の情報源から関連しそうな情報を収集・分析する検索タスク
-
評価者-最適化器
- 評価者-最適化器は、1つのLLM呼び出しが応答を生成し、別のLLM呼び出しが評価とフィードバックを提供するループ構造
- 明確な評価基準があり、反復的な改善が測定可能な価値をもたらすときに特に効果的
- 適しているサインは2つある
- 人がフィードバックを明確に表現すると、LLMの応答が実際に改善する
- LLMがそのようなフィードバックを提供できる
- 人間の書き手が洗練された文書を作る際にたどる反復的な執筆プロセスに似ている
- 例
- 翻訳LLMが最初は見落とすかもしれないニュアンスを、評価者LLMが批評する文学翻訳
- 評価者が追加の検索が必要かどうかを判断する複雑な検索タスク
自律エージェント
- エージェントは、LLMが複雑な入力理解、推論と計画、安定したツール利用、エラー回復の能力を備えるようになったことで、本番環境で使われ始めている
- タスクは人間の命令や会話によって始まる
- タスクが明確になると、エージェントが計画を立てて独立して動作する
- 追加情報や判断が必要であれば、人間に戻ることもできる
- 実行中は、各段階で環境から実際の検証シグナルを得ることが重要
- 例: ツール呼び出し結果、コード実行結果
- これにより進捗を評価する
- エージェントは、チェックポイントや行き詰まり時に人間のフィードバックを得るため停止できる
- タスクは完了時に終了することが多いが、制御を維持するため最大反復回数のような停止条件を置くのも一般的
- 実装自体はしばしばシンプル
- エージェントは通常、環境フィードバックに基づくループ内でツールを使うLLM
- したがって、ツールセットとドキュメントを明確かつ慎重に設計する必要がある
- 使用条件
- 必要なステップ数を予測しにくい、または不可能なオープンエンドの問題
- 固定経路をハードコードできないタスク
- LLMが複数ターンにわたって動作でき、意思決定にある程度の信頼が必要な状況
- 制約
- 自律性はより高いコストとエラー蓄積の可能性を伴う
- サンドボックス環境での広範なテストと適切なガードレールが推奨される
- 例
- 複数ファイルの編集が必要なSWE-bench tasksを解くコーディングエージェント
- Claudeがコンピュータを操作して作業を行う“computer use” reference implementation
パターンの組み合わせとカスタマイズ
- 提示されたビルディングブロックは固定的な処方ではなく、開発者がユースケースに合わせて調整し組み合わせられる共通パターン
- 成功の鍵は、LLM機能全般と同様に、性能を測定し実装を反復的に改善することにある
- 複雑さは、結果が実際に改善するときにのみ追加すべき
実装原則
- LLM分野での成功は、最も洗練されたシステムを作ることではなく、必要に合った正しいシステムを作ることにある
- 推奨される順序は次の通り
- シンプルなプロンプトから始める
- 包括的な評価でプロンプトを最適化する
- シンプルな解決策で不足する場合にのみ、多段階のエージェント型システムを追加する
- エージェント実装では3つの原則が重要
- 設計のシンプルさを保つ
- エージェントの計画段階を明示的に見せて透明性を優先する
- 徹底したツールドキュメントとテストによってagent-computer interface、すなわちACIを慎重に設計する
- フレームワークは素早い立ち上がりに役立つが、本番へ移る際には抽象化レイヤーを減らし、基本コンポーネントで構築するやり方も必要
実際の適用領域
-
カスタマーサポート
- カスタマーサポートは、なじみのあるチャットボットインターフェースに、ツール統合による機能拡張を組み合わせる
- よりオープンエンドなエージェントに自然に適している理由がある
- サポートのやり取りは会話の流れに従いつつ、外部情報や作業へのアクセスが必要
- ツールは顧客データ、注文履歴、ナレッジベース文書を取得するよう統合できる
- 返金処理やチケット更新のような作業をプログラム的に処理できる
- 成功可否を、ユーザーが定義した解決という形で明確に測定できる
- 複数の企業が、解決に成功した件数に対してのみ課金する従量課金モデルにより、このアプローチの実現可能性を示している
-
コーディングエージェント
- ソフトウェア開発分野では、コード補完から自律的な問題解決へとLLM機能が進化し、大きな可能性を示してきた
- エージェントが効果的な理由がある
- コードの解決策は自動テストで検証できる
- エージェントはテスト結果をフィードバックとして解決策を反復改善できる
- 問題空間がよく定義され構造化されている
- 出力品質を客観的に測定できる
- Anthropicの実装では、エージェントがpull requestの説明だけでSWE-bench Verifiedベンチマークの実際のGitHub issueを解決できる
- 自動テストが機能検証に役立つとしても、解決策がより広いシステム要件に合っているかを確認するには、人間のレビューが依然として重要
ツールのプロンプトエンジニアリング
- どのようなエージェント型システムでも、ツールは重要な構成要素になる可能性が高い
- Toolsは、Claudeが外部サービスやAPIと相互作用できるようにする
- APIで正確な構造と定義を指定する
- Claudeがツール呼び出しを計画すると、API応答にtool use blockが含まれる
- ツール定義と仕様は、プロンプト全体と同じくらいプロンプトエンジニアリング上の注意を払うべき
-
ツール形式の選択
- 同じタスクでも複数の指定方法がありうる
- ファイル編集はdiffで書くことも、ファイル全体の書き換えとして指定することもできる
- 構造化出力はMarkdown内のコードとして返すことも、JSON内のコードとして返すこともできる
- ソフトウェアエンジニアリングの観点では損失なく変換可能な形式差に見えても、LLMにとってはある形式の方がはるかに書きづらい
- diffを書くには、新しいコードを書く前にチャンクヘッダーで何行変わるかを把握する必要がある
- JSON内にコードを書くと、改行と引用符のエスケープが追加で必要になる
- ツール形式を選ぶ際は、モデルが不要な形式的負担に閉じ込められないようにすべき
- 行き止まりの形式に入る前に、十分な思考トークンを与える
- モデルがインターネット上のテキストで自然に見てきた形式に近づける
- 数千行のコードの正確な行数を数えることや、コード文字列をエスケープするような形式的オーバーヘッドを取り除く
- 同じタスクでも複数の指定方法がありうる
-
ACI設計
- 人間-コンピュータインターフェース(HCI)に投じるのと同じだけの努力を、**agent-computer interface(ACI)**設計にも投資すべき
- 良いツール定義には、使用例、エッジケース、入力形式要件、他ツールとの明確な境界が含まれることが多い
- パラメータ名と説明は、モデルがより理解しやすいよう調整すべき
- チームのジュニア開発者向けに優れたdocstringを書くのに似ている
- 似たツールが多い場合は特に重要
- モデルのツール利用はテストすべき
- SWE-bench向けエージェントを作る際、プロンプト全体よりもツール最適化に多くの時間を費やした
- エージェントがルートディレクトリ外へ移動した後、相対ファイルパスを使うツールでミスする問題があった
- ツールが常に絶対ファイルパスを要求するよう変更すると、モデルはこの方法をエラーなく使えた
1件のコメント
Hacker News の意見
この記事は、このテーマに関して今でも優れた記事の一つだと思う。特に冒頭で AIエージェントをどういう意味で使っているのかを明確に定義している点がよかった
ここでは「LLMが自身の処理過程とツール利用を動的に指示し、タスクをどう達成するかについての制御権を維持するシステム」と定義している
また、「エージェント」と「ワークフロー」を区別し、有用なワークフローパターンを複数説明しているやり方もよかった
初出時にこの記事についてメモを残した: https://simonwillison.net/2024/Dec/20/building-effective-age...
Anthropicのより最近の記事には https://www.anthropic.com/engineering/built-multi-agent-rese... — “How we built our multi-agent research system” があり、これも非常に興味深かったのでメモをまとめた: https://simonwillison.net/2025/Jun/14/multi-agent-research-s...
学習目的ならよさそうだが、よいフレームワークの第一の利点は、異なるプロバイダーのLLMを簡単に試せることにある
ワークフローを再定義して区別しようとしているように見えるが、ほとんどのエージェントはLLMの応答に応じて動的に何かを呼び出す反復型ワークフローにすぎない。現代のワークフローエンジンは非常に動的だ
「LLM呼び出し、ツール定義とパース、呼び出しの連結といった標準的な低レベル作業を単純化し、始めやすくはしてくれるが、しばしば追加の抽象化レイヤーを作って基本のプロンプトと応答を隠し、デバッグを難しくする。より単純な構成で十分なときでも複雑さを加えたくさせる。開発者にはLLM APIを直接使うことから始めるのを勧める」という助言が、記事全体で断然最高だと思う
本質的には文字列の配列をWebサービスに送るだけのことに、巨大なフレームワークを使うのは筋が通らない
会社のプロジェクトでも LangChain と LangGraph を取り除いたが、実際には価値がなく、複雑さを増やしただけだった。フレームワークのボイラープレートに対処する必要があり、むしろ使わない場合より多くのコードを書くことになった
Stable Diffusionで画像生成のステップをすべて回したり、シェーダーコードを直接書いたりすることもできるが、フローや作業が1つより多く、実験中なら、comfy-UIやシェーダーグラフを使うほうがはるかに整理される
半年が過ぎたが、AI分野ではかなり長い時間のように感じる。数か月前にこの記事を繰り返し読んだものの、今はエージェント開発が明らかにボトルネックに達したように思う
最新のGeminiでさえ後退したように見える
マルチエージェントのオーケストレーションは制御が難しく、モデル性能が上がるほどマルチエージェントの必要性は下がる。逆にモデル性能が低いほど、狭い範囲のAIのほうがビジネス上は妥当になる
実運用環境で会社のコストを削減し、本当に価値のある仕事をするエージェントの例はある？ ポテトチップスの袋の空きスペースを埋めるための文章を書くようなものではないケースの話
https://www.gbif.org/news/6aw2VFiEHYlqb48w86uKSf/chatipt-sys...
まだベータ版
プレスリリースによると、Rukaya Johaadien のチャットボットは、生物多様性データを持っているものの、データ公開が初めて、あるいはまれな学生・研究者に対話型の支援を提供する。スプレッドシートを整理・標準化し、基本的なメタデータを作成し、適切に構造化されたデータセットを Darwin Core Archive として GBIF.org に公開するよう案内する
これまで博士・修士課程の研究や小規模な生物多様性研究から得られた高品質なデータを大規模に公開するのは難しかった。データ標準化には通常、プログラミング言語、データ管理手法、専門ソフトウェアに関する知識が必要だったため
GBIF ネットワークのデータ共有中核アプリである Integrated Publishing Toolkit(IPT) にアクセスする過程も初心者には難しい。ノード担当者の時間とリソースは限られており、たまに使うユーザーは毎年正確な手順や細部を忘れがちなので、研修だけではロジスティクス面・言語面の障壁を乗り越えるのが難しいという
「データ標準化は難しく、生物学者はコーディングや Excel が好きだから生物学者になったわけではないので、潜在的に価値のあるデータが大量に捨てられている。大規模言語モデルがコード生成やデータ作業に非常に強くなったことを見て、非技術系ユーザーを日常的な質問で案内し、乱雑なデータを可能な限り処理したうえで、GBIF に素早く自動公開するツールを作った」と説明している
入ってくるすべてのアラートやチケットごとに、エージェントが関連 API、データベースなどを対象に事前調査を行い、誤検知を特定し、本当の問題により多くの文脈を提供する。人の時間を減らし、処理速度を上げる
同じエージェント的推論を探索作業にも使っており、単純な text-to-SQL を超えて、LLM が 2〜10 分間 Splunk、Databricks などを代わりに調査する
内部的には、データベース上のセマンティックレイヤー、大規模なログ・テキスト・データフレーム分析器のようなツールを持っている
記事に出てきたものとほぼ同じ構成で自作した n8n ワークフローを使ってみた。簡単な質問に答えてもらうのに 3 ドルと最低 3 分かかった
当面は普通の検索を使い続けるつもり
この記事は、動く最も単純なものから始め、本当に必要なときだけ複雑さを加えるべきだということをよく思い出させてくれる
明確に定義された LLM 呼び出しをいくつかと、軽い接着ロジックだけでも、たいていはより安定し、デバッグしやすく、実行コストもずっと安いシステムになる。派手で機能の多いエージェントは、解決する問題よりも生み出す問題のほうが多いことが多い
実運用環境で、ワークフローではなく本物のエージェントを持つ会社で働いている立場として、ここで「LangGraph のようなエージェントフレームワークを使え」という冒頭の一文にはまったく同意できない
私たちもまさにそうしたが、1 か月で全部捨てざるを得ず、その後ゼロから作り直して、今ではかなりうまくスケールするシステムになっている
公平に言えば、エージェントフレームワークを使う余地はあるかもしれない。しかしエージェント分野は、十分に良いフレームワークが出てくるにはまだあまりに初期段階だ
ある程度は逆の考えも持っていて、エージェント分野は動きが速すぎて、十分に良いフレームワークがそもそも出てこない可能性もあると思っている
フレームワークは始めやすくしてくれるが、追加の抽象化レイヤーがプロンプトとレスポンスを覆い隠してデバッグを難しくし、より単純な構成で十分なときにも複雑さを追加してしまうことがある。だから多くのパターンは数行のコードで実装できるので、LLM API を直接使うところから始めることを勧めている
実用的なチームの多くは LangChain、LangGraph、Haystack、Crew のようなものを捨て、より単純な社内コードへ移ったというコメントをよく見たが、現実にツール呼び出しのような部分が実際どう実装されているのかは、まだあまり感覚がつかめていない
作業の土台にしたリンクやドキュメントがあれば共有してもらえる？
2024 年 12 月の記事なのに、不思議なほど大昔のように感じる
AI ツール開発において Anthropic を「実用的なパートナー」として見直すきっかけになった記事だった
https://news.ycombinator.com/item?id=44260988
もう エージェント hype は少し落ち着いたようだ
「単純で組み合わせ可能なパターンを使え」という言葉が、不思議なほど安心感がある
「一つのことをうまくやれ」という格言が、数十年経ってもなお有効なのがいい。組み合わせ可能性は最高だ