効果的なAIエージェント構築

 (anthropic.com)
8 ポイント 投稿者 GN⁺ 2025-06-18 | 1件のコメント | WhatsAppで共有
  • LLMベースのエージェントを成功裏に実装したチームは、複雑なフレームワークよりもシンプルで組み合わせ可能なパターンを使う傾向がある
  • ワークフローとエージェントの構造的な違いを理解する必要があり、最適なソリューションのためには常に最小限の複雑さだけを導入するやり方が推奨される
  • さまざまなエージェントパターン（プロンプトチェイニング、ルーティング、並列化、オーケストレーター-ワーカーズ、評価-最適化ループなど）が実際の本番環境で活用されており、各パターンに合ったユースケースと長所・短所が存在する
  • エージェント実装ではシンプルさ、透明性、インターフェース設計が中核原則であり、ツール設計とプロンプトエンジニアリングに注意を払う必要がある
  • カスタマーサポートやソフトウェア開発環境で、エージェントが実際に価値を提供する事例が徐々に増えている

概要

この1年間、Anthropicはさまざまな業界のチームとともに大規模言語モデル（LLM）ベースのエージェントを構築してきた。実際に成功したエージェント導入事例は、複雑なフレームワークや特化ライブラリよりも、シンプルで組み合わせ可能なパターンに基づく傾向が見られた。本ポストでは、顧客との協業および自社開発の経験から得たインサイトと、効果的なエージェント構築のための実践的な助言を共有する。

エージェントとは何か

エージェントはさまざまな形で定義できる。

  • 一部では、外部ツールを利用して複雑なタスクを独立して完遂する完全自律システムとして定義する
  • 一部では、制限されたワークフローや事前に定められたプロセスに従う規定的な実装として理解する

Anthropicはこの両方をエージェンティックシステムに分類するが、ワークフローとエージェントの間には重要なアーキテクチャ上の違いを置いている。

  • ワークフロー: LLMとツールが事前定義されたコードパスでオーケストレーションされる構造
  • エージェント: LLMがツール活用とプロセスを自ら動的に決定し、課題達成の方法に対する制御権を持つ

このポストでは両形式のシステムを詳しく説明し、実務への適用事例は付録1で扱う。

いつ（そしていつでないか）エージェントを活用すべきか

アプリケーション開発では最小限の複雑性を原則とし、必要なときだけ段階的に複雑さを加えるのが望ましい。

  • エージェンティックシステムは、レイテンシ/コストをある程度犠牲にしてもタスク性能の向上を図れる
  • 複雑さが本当に必要でない限り、単一のLLM呼び出しとfew-shot例、検索連携などで十分に解決できる場合が多い
  • ワークフローは予測可能性と一貫性が重要な場面に、エージェントは柔軟性とスケールが必要な場面に適している

フレームワークを使うタイミングと方法

エージェンティックシステムの実装を容易にするさまざまなフレームワークが存在する。

  • LangGraph（LangChain）
  • Amazon Bedrock AI Agent framework
  • Rivet、Vellum など

これらのフレームワークは、LLM呼び出し、ツール定義/パース、呼び出しチェーン構成などの低レベル作業を簡素化してくれる。しかし、過度な抽象化によって実際のプロンプト・応答フローが不透明になったり、不要に複雑さが増したりするリスクがある。

  • 開発者には、可能な限りLLM APIを直接使うところから始めることが推奨される
  • フレームワークを使う場合でも、内部の動作方式を正確に理解しなければならない

実装例は anthropic-cookbook で確認できる。

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

Anthropicは、実際の運用環境で頻繁に使われるエージェンティックシステムのパターンを紹介している。

ビルディングブロック: 拡張LLM

エージェンティックシステムの中核は、検索、ツール、メモリなどの機能で拡張されたLLMである。

  • モデルが自律的に検索クエリ生成、適切なツール選択、情報保存を行える
  • 中核実装での考慮点は、ユースケースに合わせて機能をカスタマイズし、LLMに明確で文書化されたインターフェースを提供すること

最近公開された Model Context Protocol により、さまざまなサードパーティツールと簡単に統合できる。

ワークフロー種別ごとの説明

プロンプトチェイニング

  • タスクを一連の段階に分解し、各LLM呼び出しが前の結果を引き継いで処理する
  • 各段階にプログラムによる検証（ゲート）を加えることでプロセス管理が可能
  • 適用例: マーケティング文言の生成後に翻訳、文書アウトライン設計 → 検証 → 本文作成 など

ルーティング

  • 入力を分類して、適切な後続タスクへ分岐させる
  • 各カテゴリごとに特化したプロンプトやツールを活用できる
  • 適用例: 顧客問い合わせの振り分け（返金、技術サポートなど）、難易度別のモデル選択 など

並列化

  • タスクを小単位に分割し、並列に処理した後で結果を集約する
  • Sectioning: 各部分を独立して処理する
  • Voting: 同じタスクを複数の観点・プロンプトで繰り返し、多数決などを活用する
  • 適用例: ユーザー質問のフィルタリングと応答の分離、自動評価、コードレビュー など

オーケストレーター-ワーカーズ

  • 中央のLLMがタスクを動的に分解・割り当て、複数のワーカーLLMがそれぞれ処理して結合する
  • 事前定義されておらず、入力に応じて変化するサブタスクに適している
  • 適用例: 複数ファイルを変更するコーディング、複雑な情報探索 など

評価-最適化ループ

  • 応答LLMと評価LLMを反復ループで活用する
  • 明確な評価基準と、フィードバックに基づく改善が価値を持つ状況に適している
  • 適用例: 文学翻訳における微妙なニュアンス評価、複数ラウンドの情報探索 など

エージェント

  • LLMの進化に伴い、実サービスで複雑な入力、推論・計画、ツール使用、エラー回復が可能なエージェントが登場している

  • ユーザーの命令/対話で開始 → タスクを明確化した後に自律実行 → 中間チェックポイントでフィードバック可能 → 完了または中断条件で終了

  • 実際の実装では、LLMが環境フィードバック（ツール結果、コード実行）を参照しながら反復し、ツールセットと文書化が中核となる

  • 適用例: SWE-benchタスク解決のためのコーディングエージェント、Claudeベースのコンピュータ利用自動化

  • 適用範囲: 決まった経路や段階の予測が不可能なオープンエンド問題、意思決定の信頼性が必要な状況

  • 自律性の増大によるコスト・複合エラーの可能性を考慮する必要があり、サンドボックステストとガードレールが必須

パターンの組み合わせとカスタマイズ

  • 紹介したビルディングブロックは定型ルールではなく、さまざまな状況に合わせて組み合わせ可能である
  • 重要なのは、成果測定/反復改善を通じて最適な構造を選び、段階的に複雑さを追加すること

要約と推奨原則

LLMシステムの成功は、複雑さや新技術ではなく、目的に合った正確なアプローチを見つけることにある。

  • シンプルなプロンプトから始め、成果を評価して反復的に最適化し、段階的に複雑性を拡張する

  • エージェント設計における3大原則

    1. シンプルさを保つ
    2. 透明性（設計段階の明確化）を優先する
    3. ツール/インターフェースの文書化・テストを重視する

  • フレームワークで素早く始めることはできるが、実際には抽象化レイヤーの最小化と直接実装の力量が信頼性・保守性を左右する

付録1: 実務におけるエージェント適用事例

カスタマーサポート

カスタマーサポート分野は、チャットボットインターフェースとツール連携が組み合わさっており、エージェント適用に自然に適している。

  • 対話ベースのインターフェースと外部データ・業務処理の必要性が共存する
  • ツールで顧客情報、注文履歴、ナレッジベースなどを連携できる
  • 返金/チケット処理などの作業を自動化する
  • 解決基準を明確に設定できる

成功した導入事例では、利用量（解決成功基準）ベースの課金モデルによってエージェントの有効性を検証している。

コーディングエージェント

ソフトウェア開発環境でも、問題の自動解決などエージェント活用度が大きく向上している。

  • コードは自動テストによって結果を検証できる
  • テスト結果を活用した反復改善が可能
  • 問題定義が明確で、成果物の品質も客観的に測定できる

Anthropicの自社実装事例: SWE-bench Verifiedベンチマークで、実際のGitHub issueをpull request説明だけで解決。自動テストに加えて、人間によるレビューはシステム全体の要件に適合しているかを確認するうえで依然として重要である。

付録2: ツールのプロンプトエンジニアリング方法

すべてのエージェンティックシステムにおいてツールは中核要素である。

  • ClaudeなどのLLMは、API上で正確な構造・定義に従って外部サービスと相互作用できる
  • 応答に tool use block を含められる
  • ツール定義・仕様もまた、プロンプトエンジニアリングと同じくらい緻密な設計が必要

ツールフォーマット設計のヒント

  • モデルが作成時の「罠」に陥らないよう、十分なトークンを確保する

  • インターネット上でよく見られる自然なフォーマットの使用を推奨

  • 不要なフォーマットのオーバーヘッド（例: コード行数カウント、文字列エスケープなど）を最小化する

  • 人間-コンピュータインターフェース（HCI）を設計するときと同じだけ、**エージェント-コンピュータインターフェース（ACI）**にも配慮を注ぐべきである

  • モデルの立場からツールを理解・使用することが「明確」である必要があり、使用例、境界条件、入力フォーマットの明示なども含まれる

  • パラメータ名や説明も直感的な用語に置き換え、ドキュメント文字列を書くように設計する

  • さまざまな入力値で実際の使い方をテストし、反復的に改善する

  • ミス発生を減らせるように（Poka-yoke）、引数設計を行う

実際にSWE-benchエージェントを構築する際、全体プロンプトよりもツール設計の最適化に多くの時間を投資した。例: ルートフォルダ外への逸脱後にファイルパスのミスを減らすため、絶対パスのみを受け付けるよう変更したところ、完全に動作するようになった。

関連記事

1件のコメント

 
GN⁺ 2025-06-18
Hacker Newsの意見

  • この文章は、まず「AI agents」の定義を明確にしている点が特に印象的だという意見。ここで使われている定義は「LLMがプロセスとツール利用を自律的に動的管理し、タスクの遂行方法を自ら制御するシステム」。agent と workflow を区別している部分や、複数の実用的なワークフローパターンを紹介している点も好ましいという立場。この記事が最初に出たときに自分でまとめたノートもある building-effective-agents ノート。また、最近のAnthropicによる マルチエージェント研究システム構築記 も興味深く、これに関する追加ノートもある multi-agent research system ノート

    • この記事で述べられている workflow の定義は正確ではないと思う。最近のワークフローエンジンは、あらかじめ決められたコードパスに従わず、実質的にエージェントと同じように動作することが多い。著者が workflow を新たに定義したのは区別する意図があるのだろうが、実際には agent というものも、LLMの応答に応じて動的に呼び出されるループ型ワークフローにすぎないという意見。最新のワークフローエンジンも非常に動的だという主張

    • Building Effective Agents の共著者の1人がAIEでこの文章をテーマに講演も行ったが、反応は非常に良かったという体験共有 YouTube動画

    • マルチエージェント研究に関する記事は本当に良いが、Building Effective AI Agents の「フレームワークなしでゼロからシステムを構築するのは教育的観点では良い」という主張には同意しないという意見。良いフレームワークを使えば、多様な（しかもベンダー非依存の）LLMを簡単に試せることが第一の利点だという主張

    • AnthropicがどのAI agent frameworkを使っているのか気になるという質問。独自フレームワークを公開したことはないように思うという意見

    • 追加ノートに感謝しており、このテーマが最近自分にとっても非常に重要な課題だという反応

  • AI分野では半年がとても長く感じられる。数か月前にはこの記事を繰り返し読んでいたが、今ではエージェント開発が明らかにボトルネックに達したように感じる。最新のGeminiでさえ、むしろ性能が後退したように思えるという意見

    • 複数のエージェントを同時に動かすのはコストが高く、RoIを下げる要因になる。たとえば株式向けのDeepSearch agentは6つのagentを使っており、クエリごとに約2ドルかかる。マルチエージェントのオーケストレーションは制御が難しく、モデルが強力になるほどマルチエージェントの必要性は下がる。逆にモデルが弱いほど、特化した狭いAIのビジネス価値が高まるという実体験の共有

    • エージェントが後退したと感じる理由が気になるという質問。なぜ自分自身の分身を複数作って24/7で並列に動き続け、検証し、改善していけないのかという疑問

    • プロンプトインジェクション問題を解決するのは非常に難しく、この点が深刻なボトルネックになっているという意見

  • エージェントが task queueing、race condition、そのほかの並行性の問題をどう扱うのか気になる。マルチエージェントワークフロー構築に関する記事では orchestrator agent が全体を管理すると書かれていることが多いが、実際にはもっと複雑な設計や賢い glue code が必要なのではないかと常に思っている。あるいは、これが本当にすべて「自動の魔法」のように動くのかという疑問

    • エージェントの標準はツールが逐次実行されることなので、並行性の問題を心配しなくてもよいという説明。今では複数のモデルが並列ツール呼び出しをサポートしており、モデルが「この3つのツールを実行」と要求すれば、harness が並列または逐次で実行し、その結果を次のステップに渡す方式を使う。Anthropicはマルチエージェント構成をより積極的に活用しており、上位エージェントが下位エージェントに並列で作業を委任する構造になっている。このトリックはClaude Codeに適用されており、関連するリバースエンジニアリングノート（claude-trace）や、Claude Researchの動作方法に関する記事（multi-agent-research-system）でも詳しく説明されている。LLMのツール利用パターンを見いだす段階はまだ非常に初期であり、モデルが本当にツールをうまく使えるようになったのもここ6か月ほどのことなので、今後の発展余地は大きい

    • そのため、すべてをJSONで扱うよりも、LLMが直接 code を生成して tool call を扱う方向を好むようになった。Huggingface の smolagents ライブラリは、LLMがpython関数呼び出しコードを生成する方式を採用している。並列ツール呼び出しを望むなら、プロンプトで明示すればよく、LLMが同期も処理しなければならない。もちろん、LLMが生成したコードを実行する問題はあるが、さまざまな解決策が存在する

    • CodexのWebインターフェースの使用例の共有。一度で終えるには長すぎるリファクタリング計画があり、「ask」機能を使って複数の作業に分割し、並列化できる作業をグループ化した。LLMは実際のチームが分担する方法に近い形で分割したが、作業間のコミュニケーションを前提にしていないため、コンテキストの喪失が非常に大きい。自分でやるより時間がかかっても試してみたが、複数のセッションに対して各作業ごとに詳細なプロンプト（目的、方法、検証、ドキュメント化など）を与える形で逐次処理した。要するに orchestrator agent はごく単純な作業には使えるが、思ったより適用範囲が限られているという実体験の共有

    • 魔法のように自動で動くものは何もないという立場。既存システムで気を配るべき運用特性は、AIエージェントにも必ず実装しなければならない。AI agent のデモだけを見て「スパゲッティコードのチームのコードを、いくつかのきれいなAIプロンプトで置き換えられる」と考えると騙されるかもしれない。実際に少数のケースでは動くかもしれないが、結局すべてのコードにはシステム内で必要な理由があり、そのコードを丸ごとLLMに翻訳して詰め込むような段階になれば、方向性を見失っているという警告

    • コーディングエージェントでは、作業をコンテナで分離し、gitで成果物をレビューしてマージする方式が emerging pattern として定着しつつある。例としては、コンテナやMCPの活用例（container-use）があり、並列コード作業に有用。そのほかの業務では、n8n、Zapier、CrewAIのようなワークフロービルダーも依然としてよく使われている

  • この記事は、「最も単純なもの」から始めて、本当に複雑さが必要になったときだけ追加せよ、というメッセージを思い出させてくれる。明確に定義されたLLM呼び出しと少しのシンプルな glue logic だけで、より安定し、デバッグしやすく、コストも低いシステムを構築できる可能性がある。逆に、派手に見えるエージェントシステムは、むしろ問題を増やすことが多い

  • AIが人々に実質的な助けを与える存在になってほしいという希望の表明

  • Anthropicがこうした技術情報を提供してくれるのは良いが、非専門家向けのわかりやすいガイド版も提供すべきだと思う。たとえばマーケティング部門でエージェントを導入したくても、基礎レベルで仕様を定義できるガイドが必要。記事の最後の部分と付録に関連内容はあるが、それでもなお「どう構築するか」は実装面にとどまっているという指摘

  • （2024年12月 ― 今となってはずいぶん昔のことのように感じられる時点、という感想）

    • あああ、また頭を使って、2024年12月に原始人みたいに100％コードを自分で書かなければならない状況に戻るのか、という冗談めいた反応 関連コメント

    • この記事は非常によく持ちこたえているという意見。個人的に今でも継続的な参考資料として使っており、時間が経っても古びた感じがしない。Anthropicが「実用的なAIツール開発パートナー」として新しい印象を与えた記事だったという評価

  • Agentに対する過剰な熱狂（hype）は今ではかなり落ち着いたという見解

    • 今では誰もがAI Agencyに関心を持つようになったという変化の診断

  • この記事は当時にも議論されていたという情報共有 元のHN議論

  • この記事が誇張や流行に流されず、現実的にアプローチしている点が気に入ったという意見。多くの人が流行に乗ってagentシステムを作っているが、そもそもその作業に本当にagentが必要なのかを考えずに進める傾向があることに批判的