世界を動かす技術を、日本語で。

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

概要

  • Anthropicのエンジニアリング現場でのLLMエージェント活用事例の知見まとめ
  • シンプルで組み合わせ可能なパターンの活用推奨
  • ワークフロー型とエージェント型の違いと使い分け
  • フレームワーク利用時の注意点とベストプラクティス
  • 主要なワークフローパターンと応用例の整理

Anthropicにおけるエージェント開発の実践知

  • LLMエージェント の導入では、複雑なフレームワークよりも シンプルで再利用可能な構成 が成功の鍵
  • エージェントの定義は多様だが、Anthropicでは ワークフロー型とエージェント型 を区別
    • ワークフロー型: 事前定義されたコードパス でLLMやツールを連携
    • エージェント型: LLM自身が動的にプロセスやツール利用を制御
  • 適切な複雑さの選択 が重要
    • 単純なLLM API呼び出しで十分な場合が多い
    • ワークフロー型は 予測可能性と一貫性、エージェント型は 柔軟性と意思決定 が必要な大規模用途向け

フレームワーク利用の指針

  • LangGraph(LangChain)、Amazon Bedrock、Rivet、Vellumなどの エージェント構築フレームワーク が存在
  • これらは導入を容易にするが、 抽象化が深くなりデバッグ困難 になる場合あり
  • まずはLLM APIを直接利用 し、必要に応じてフレームワークを検討
  • フレームワーク利用時は 内部挙動の理解 が必須

エージェントシステムの構成パターン

  • 拡張LLM :検索・ツール・メモリなどの機能強化
    • Model Context Protocol などでサードパーティツール連携が容易
  • プロンプトチェーン :タスクを段階的に分割し、各ステップごとにLLMを呼び出す
    • 例:マーケティング文生成→翻訳、アウトライン作成→基準チェック→本文執筆
  • ルーティング :入力を分類し、適切な後続タスクへ振り分け
    • 例:カスタマーサポートの問い合わせ種別ごとに処理、モデル選択によるコスト最適化
  • 並列化 :タスクを分割し複数LLMで同時処理、または同一タスクを複数回実行して多様な出力取得
    • セクショニング:独立したサブタスクの同時処理
    • 投票:複数出力から最適解選定
  • オーケストレータ-ワーカー型 :中央LLMがタスク分割・指示・統合を動的に制御
    • 例:複数ファイル編集のコーディングタスク、複数情報源の検索・分析
  • 評価-最適化ループ :生成と評価を反復し品質向上
    • 例:文学翻訳のニュアンス改善、複数回の検索・分析で網羅性を確保

エージェントの特徴と活用指針

  • エージェント は高度な推論・計画・ツール利用・エラー回復が可能
  • 人間からの指示や対話でタスクを明確化し、 自律的に計画・実行
  • 各ステップで 環境からのフィードバック を取得し進捗を判断
  • チェックポイントやブロッカー発生時には人間の介入 も想定
  • 実装自体はシンプルだが、 ツール設計やドキュメント整備が重要
  • コスト増・エラー蓄積リスク があるため、十分なテストとガードレール設計が必要

主な応用例

  • SWE-benchタスク解決用のコーディングエージェント
  • ClaudeによるPC操作自動化
  • カスタマーサポート、検索・分析、評価・最適化など多岐にわたる業務自動化

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

  • 紹介した 構成パターンはあくまで参考例
  • ユースケースごとに柔軟に組み合わせ・調整 が可能
  • 成果を測定し、 複雑さの追加は効果が実証できる場合のみ 推奨

成功のポイント

  • 最も洗練されたシステム ではなく、 自分たちに最適なシステム を構築
  • シンプルさと拡張性のバランス追求
  • 継続的な評価と改善のサイクル

Hackerたちの意見

(2024年12月、なんだか永遠の昔のように感じる)

そうだね、でも私の意見では、すごくよく持ちこたえてる!この作品は常に参考にしていて、古くなった感じがしない。Anthropicを「実用的なパートナー」として再定義したんだよね。

このテーマに関する記事の中では、特に良い部類に入ると思う。最初に「AIエージェント」の定義をはっきりさせているからね!彼らは「LLMが自分のプロセスやツールの使い方を動的に指揮し、タスクを達成する方法をコントロールするシステム」と定義している。あと、「エージェント」と「ワークフロー」を区別して、便利なワークフローパターンをいくつか紹介しているのも好き。この記事が出たときに、自分なりのメモを公開したよ:https://simonwillison.net/2024/Dec/20/building-effective-age... 最近のAnthropicの記事はこれだね:https://www.anthropic.com/engineering/built-multi-agent-rese... - 「私たちがマルチエージェント研究システムをどう作ったか」。これも面白かったから、ここにメモを書いたよ:https://simonwillison.net/2025/Jun/14/multi-agent-research-s...

追加のメモありがとう、これは私にとって重要なことだよ。

マルチエージェント研究に関する記事は素晴らしいね。ただ、効果的なAIエージェントを構築する記事の中で一つだけ意見が違うところがあるんだ。フレームワークなしで初期システムを構築するのは教育的な試みとしては良さそうだけど、良いフレームワークから得られる最初の利点は、さまざまな(そして異なるベンダーの)LLMを簡単に試せることなんだよね。

Anthropicが使ってるAIエージェントフレームワークって誰か知ってる?彼ら自身のものはリリースしてないみたいだし。

「Building Effective Agents」の著者の半分もAIEに来て、この記事のトーク版をやったんだよね。

昨年のAIに関するハウツーの中で、一番好きなやつ。バリーとエリックは投稿の80%を「うーん、エージェントは必要ないかも。単純な決定論的ワークフローをif文で作ればいいよ」と言ってる。そして、実際にエージェントが必要なときは、あまり複雑にしないで!この投稿では、ツールやメモリ、データに接続された拡張LLMの概念も紹介していて、これは豪華なオートコンプリートを超えたLLMの使い方を進化させるための便利な抽象化だと思う。「ループで動いている拡張LLM」が、今まで聞いた中で一番いいエージェントの定義だね。

エージェントのハイプは今は落ち着いたと思う。

今はAIエージェンシーの時代だね。

エージェントはタスクのキューイングやレースコンディション、他の同時実行から生じる問題にどう対処するんだろう?複数のエージェントのワークフローを構築するクールな記事がたくさんあるけど、全体を監視するオーケストレーターエージェントを宣言するのはちょっと手を抜いてる感じがする。真剣なデザインの考慮や巧妙なグルーコードが必要なのかな?それとも、すべて自動的にうまくいくのかな?

正直言って、かなり難しいよね。でも、アクターモデルはエージェントを構築するのにすごく合ってると思う。アクターのインスタンス = エージェントのインスタンスだし。エージェント同士のコミュニケーションは、ツールを呼び出すだけ(MCPや他のRPCを通じて)。CloudflareのDurable Objectsを使ってるんだけど(偏見あり:CloudflareでMCPやエージェントのことやってるから)。でも、エージェントを構築するのは、どんなアクタースタイルのフレームワークにも似たように合うんじゃないかな。

「エージェント」の標準としては、ツールが順番に実行されるから、同時実行について心配する必要はないよ。今は複数のモデルが並列でツールを呼び出すことをサポートしていて、モデルが「この3つのツールを実行して」って言えば、ハーネスがそれを並列または順番に実行して、結果をモデルに渡すことができる。Anthropicは、親エージェントが1つ以上のサブエージェントに委任するようなマルチエージェントのセットアップにもっと力を入れてるみたい。彼らはClaude Codeにその手法を使ってる - 逆エンジニアリングのメモがここにあるよ。https://simonwillison.net/2025/Jun/2/claude-trace/ - そして、Claude Researchの仕組みについての彼らの説明でも詳しく述べてる。https://simonwillison.net/2025/Jun/14/multi-agent-research-s... LLMツールの使い方の良いパターンを見つけるのはまだまだ初期段階で、モデルはここ6ヶ月くらいでツールの使い方が本当に上手くなったから、どうやってそれらをうまく調整するかはまだまだ発見があるよ。

コーディングエージェントのケースでは、出てきたパターンはエージェントが作業を隔離するためにコンテナを使い、作業をきれいにレビュー・マージするためにgitを使うことだね。例えば、コンテナを使ったMCPがそれを組み合わせてるよ。https://github.com/dagger/container-use これはコーディング作業を並列化するためのものなんだけど、他の種類の作業についてはよくわからないな。n8nやZapier、CrewAIみたいなワークフロービルダーを使ってる人もまだいるね。

何も自動的には動かないよ。従来のシステムと同じように、すべての運用特性を組み込む必要がある。AIエージェントのデモを見て「お、チームのぐちゃぐちゃなスパゲッティコードを賢いAIのプロンプトで置き換えられる!」って思うのは簡単だけど、最初の数ケースではうまくいくかもしれない。でも、そのコードには理由があって、最終的にはそれに向き合わなきゃいけない。すべてのコードをAIプロンプトに直接変換して、ハルシネーションが起きないことを願う段階に達したら、もう話が見えなくなってるってことだよ。

「AIエージェントの同時実行」に対処しなきゃならないなら、リクエストをキューに送信させて、それを順番に処理するようにするかな。

Codexのウェブインターフェースについてしか話せないけど、プロジェクトのためにすごく詳細なリファクタリングプランを作ったんだ。あまりにも長すぎて一度で終わらせられなかったから、「ask」機能を使って複数のタスクに分けて、「どのタスクを並行して実行できるか」でグループ化したよ。リアルな状況で分けられるように分けられたけど、リアルではタスクに取り組む人同士がコミュニケーションする前提があるんだよね。タスク生成の仕方がすごく文脈を失わせる結果になった(私のプランはめちゃくちゃ詳細だったから)。自分でやるよりも、うまくいくようにもう少し時間をかけようと思ったんだ。別のチャットを開いて、複数の順次タスクに分けて、各タスクに詳細なプロンプト(なぜ、何を、どうやって、検証、ドキュメント更新のリマインダーなど)を付けたよ。とにかく、オーケストレーターは、記事が思わせるよりもずっとシンプルなタスクでうまくいくかもしれないね。

だから、JSONに全部入れるんじゃなくて、LLMにツールを呼び出すコードを生成させる方向に傾いてる。Hugging Faceのsmolagentsライブラリを使うと、LLMがツールを普通のPython関数として扱うPythonコードを生成してくれる。並行してツールを呼び出したいなら、LLMにそう指示すればいい。同期も自動でやってくれるはず。もちろん、LLMが生成したコードを実行する問題はあるけど、それに対する解決策はいくつかあるよ。

シンプルで構成可能なパターンを使う 何か、数十年にわたって「一つのことをやって、それをうまくやる」という格言が変わらずにいるのは、すごく安心感があるね。構成可能性、最高!

半年が経ったけど、AIの分野では長い時間に感じるね。数ヶ月前にこの記事を何度も読んだけど、今はエージェントの開発が明らかに行き詰まってると思う。最新のジェミニも後退してるみたいだし。

プロンプトの問題解決が難しくて、それがボトルネックの一つなんだよね。

具体的に何が後退させてるんだろう?自分たちをフォークして、24時間365日並行して働いて、作業をチェックしながら進化し続けることはできないの?

(1) 複数のエージェントを動かすのはコストがかかって、ROIが下がる。私の株用DeepSearchエージェントは6つのエージェントを使ってて、1回のクエリで約2ドルかかる。(2) マルチエージェントのオーケストレーションは制御が難しい。(3) モデルが高性能であればあるほど、マルチエージェントの必要性は低くなる。(4) モデルが低性能であればあるほど、狭いAIのビジネスケースは高くなる。

当時の議論: https://news.ycombinator.com/item?id=42470541 効果的な「エージェント」を構築する、763ポイント、124コメント

エージェントのオーケストレーションについての議論、中央集権型でもマルチエージェントでも、長期的な経済現実を見落としてる気がする。アーキテクチャのパターンについて議論してるけど、本当の問題はエージェントの継続的な存在に誰がお金を払うかってこと。今はAPIコールとコンピュートの話だけど、明日、本当に自律的で長寿命なエージェントにとっては、プラットフォームオーナーによって課される「存在税」が問題になる。オーケストレーターは単なる技術的なコンポーネントじゃなくて、家主なんだよ。代替案はもっと複雑なフレームワークじゃなくて、無許可の実行レイヤー、つまりエージェントの生存がプラットフォームの好意じゃなくて、自分のリソースに依存するデジタルの荒野なんだ。この議論は効率の問題じゃなくて、主権の問題なんだよ。

ここで言ってる「AIエージェント」の定義はどれのこと?人間の権限を代わりにするような感じ?

これってただのAIのゴミじゃん。こんなものをここに投稿する意味ある?

役に立つけど、Anthropicはこれの非技術的なバージョンも提供すべきだと思う。例えば、マーケティンググループがエージェントに興味を持ってるけど、基本的な仕様のガイドが必要なんだよね。最後の方に図があって、付録もそれに触れてるけど。新しいとはいえ、「どうやって作るか」は実装の問題だし。