この記事は、LLM エージェントを構築する数十のチームにわたって Anthropic が観察したことを報告しており、その主要な発見は否定的なものである。最も成功した実装は、複雑なフレームワークや専門的なライブラリを使っておらず、シンプルで組み合わせ可能なパターンを使っていた。記事の大部分はそれらのパターンの目録であり、単一の拡張されたモデル呼び出しから自律型エージェントまで、複雑さの小さい順に並べられ、それぞれについてどのような場合に適切な選択となるかが述べられている。
語彙面での中心的な工夫は、論証によって決着をつけることを控えた区別にある。Anthropic はすべてをエージェント型システムという見出しのもとにまとめ、そのうえで 2 種類を区別する。LLM とツールが事前に定義されたコードパスを通じてオーケストレーションされるワークフローと、LLM が自らのプロセスとツールの使用を動的に指揮し、タスクをどう達成するかの制御を保持するエージェントである。この区別の実際上の重みは、それに付された推奨にある。ワークフローは明確に定義されたタスクに予測可能性と一貫性をもたらし、エージェントは柔軟性とモデル主導の意思決定が大規模に必要な場合により良い選択となる。そして多くのアプリケーションでは、検索とコンテキスト内の例示によって単一の LLM 呼び出しを最適化すれば十分である。
記事には、そこで説明されているツールの状況の多くが 2024 年 12 月以降に変化したという注記があり、現在のアプローチについてはマネージドエージェントに関する Anthropic のより新しい文章を参照するよう読者に案内している。
要点
- 示されている一般的な原則は、可能な限りシンプルな解決策を見つけ、必要な場合にのみ複雑さを増やすことである。記事によれば、これはエージェント型システムをまったく構築しないことを意味する場合もある。エージェント型システムは、レイテンシとコストをタスクの性能と引き換えにするからである。
- フレームワークについては、LLM の API を直接使うことから始めるよう推奨している。多くのパターンは数行のコードで実装できるというのが理由である。フレームワークは低レベルのタスクを簡単にするが、プロンプトとレスポンスを覆い隠す抽象化レイヤーを加え、デバッグを難しくし、よりシンプルな構成なら不要な複雑さを招くとされる。フレームワークが内部で何をしているかについての誤った思い込みが、顧客のエラーのよくある原因として挙げられている。
- 基礎となる構成要素は 拡張 LLM である。これは検索、ツール、メモリで拡張されたモデルであり、自ら検索クエリを生成し、ツールを選択し、何を保持するかを決める。記事は、これらの機能をユースケースに合わせて調整し、モデルに使いやすくよく文書化されたインターフェースを与えることを推奨しており、それらを実装する方法の 1 つとして Model Context Protocol を挙げている。
- プロンプトチェイニングは、タスクを固定された順序に分解し、各呼び出しが前の出力を処理する。ステップの間には任意でプログラムによるゲートを置く。その目的は、各呼び出しを容易にすることでレイテンシを精度と引き換えにすることだとされ、固定されたサブタスクにきれいに分解できるタスクに適している。
- ルーティングは、入力を分類して専門化された後続処理に振り向けるもので、関心の分離とより専門化されたプロンプトを可能にする。記事は、これがなければ、ある種類の入力に向けた最適化が他の入力に対する性能を損ないうると指摘している。例として、サポートの問い合わせの種類ごとに異なる下流のプロセスに振り向けることや、簡単な質問は小さなモデルに、難しい質問はより高性能なモデルに送ることが挙げられている。
- 並列化には 2 つの変種がある。タスクを独立したサブタスクに分割して並列に実行するセクショニングと、多様な出力を得るために同じタスクを複数回実行する投票である。記事によれば、複数の考慮事項を含む複雑なタスクでは、一般に各考慮事項に個別の呼び出しを割り当てたほうが LLM の性能が良くなる。
- セクショニングの例の 1 つはガードレールの構成であり、あるモデルインスタンスがユーザーのクエリを処理する一方で、別のインスタンスが不適切な内容がないかを審査する。記事によれば、これは 1 つの呼び出しで両方を行わせるよりも性能が良くなる傾向がある。
- オーケストレーター・ワーカーでは、中央の LLM がタスクを動的に分解し、ワーカー LLM に委任し、結果を統合する。記事はこれを並列化と、構成ではなく柔軟性によって区別している。サブタスクは事前に定義されるのではなく、入力に応じてオーケストレーターが決定する。名前の挙がった例は、複数のファイルにまたがる複雑な変更を行うコーディング製品と、複数の情報源にわたる検索である。
- 評価者・最適化者は、ある呼び出しに応答を生成させ、別の呼び出しにそれを評価させるループを組む。例として、評価者が翻訳者の見落とした批評を提供できる文芸翻訳と、さらなる検索が必要かどうかを評価者が判断する複雑な検索が挙げられている。
- エージェントは、人間からのコマンドや議論から始まり、その後は計画を立てて独立して動作するものとして説明されている。記事は、エージェントが進捗を評価するために、各ステップで環境から「グラウンドトゥルース」（ツール呼び出しの結果やコードの実行結果）を得なければならないことを強調しており、チェックポイントや障害に直面した際には人間のフィードバックを求めて一時停止できるとしている。
- タスクが高度であっても、実装は単純なものとして特徴づけられている。エージェントは「典型的には、環境からのフィードバックに基づいてループの中でツールを使う LLM にすぎない」のであり、記事はこれを、ツールセットとそのドキュメントを慎重に設計しなければならない理由として挙げている。
- 最大反復回数のような停止条件を組み込むことは、制御を維持するための一般的な慣行として説明されている。記事は、自律性の代償として高いコストと誤りの累積を挙げ、適切な ガードレール を備えたサンドボックス環境での広範なテストを推奨している。
- エージェントは、必要なステップ数を予測できず、固定された経路をハードコードできない、オープンエンドな問題に適しているとされる。また、モデルの意思決定に対してある程度の信頼が必要であり、記事はこれを信頼できる環境でエージェントをデプロイすることと結びつけている。
- エージェントを実装するための結びの原則として 3 つが示されている。設計のシンプルさを保つこと、計画のステップを明示的に示して透明性を優先すること、そして徹底したツールのドキュメント化とテストによってエージェント・コンピュータ・インターフェースを慎重に作り込むことである。
- これらのパターンは、組み合わせて使う規範的でない構成要素として明示的に提示されており、結果を明確に改善する場合にのみ複雑さを加えるべきだという指示が繰り返されている。
背景
根拠となっているのは Anthropic 自身のコンサルティング経験、すなわち数十の顧客チームとの協働と自社でのエージェント構築であり、定性的に報告されている。いずれのパターンにも測定は伴っておらず、記事はその目録が網羅的だとも主張していない。自社のものとして挙げている 2 つのエージェントの例は、SWE-bench のタスクのためのコーディングエージェントと、コンピュータ操作（Computer Use）のリファレンス実装である。
記事は、「エージェント」が他者によってさまざまに定義されていることに注意を払っている。それが、1 つの定義を主張するのではなく「エージェント型システム」という包括的な用語を導入する理由であり、また、記事が実際に引く線が、どの用法が正しいかについての主張ではなく、アーキテクチャ上のもの（誰がプロセスを指揮するか）である理由でもある。
記事自身の日付に関する注記は、読み方にとって重要である。Anthropic は、説明されているツールの状況の多くが 2024 年 12 月以降に変化したと述べ、現在のアプローチについては後の文章を参照するよう案内している。したがって、パターンの目録は持続的なものとして読み、個々のフレームワークや製品への言及はそうではないものとして読むべきである。