シリコンバレーでの一部の技術者のインタビューで、彼らはよく「AIエージェントがAGIへの道（The road to AGI）である」と述べています。
以前、私はAIエージェントに関する共有デッキを作成したことがあります。ちょうど20日に、アンソロピックが「効果的なエージェントの構築」をテーマにした記事（https://www.anthropic.com/research/building-effective-agents）を公開しました。本日は、私のこれまでの知識とこの記事を基に、AIエージェントの構築ガイドについて整理してみたいと思います。
概念の説明
以下の図は、今年李飛飛氏とマイクロソフト研究所チームが発表した論文からのスクリーンショットで、AIエージェントの基本概念とフレームワークを示しています。以下が参考文献リンクです：https://www.microsoft.com/en-us/research/project/agent-ai/
比較：人間とLLMベースのインテリジェントエージェント資料元：https://arxiv.org/pdf/2309.07864
| 機能モジュール | 人類 | AI インテリジェントエージェント |
|---|---|---|
| 知覚（Perception） | 感覚（視覚、聴覚など）を使って情報を取得し、認知処理を行う | マルチモーダルデータ処理モジュール（テキスト、画像、音声）をLLMが理解可能な表現に変換する |
| 脳（ブレイン） | 記憶、推論、意思決定を通じて情報を統合（経験とデータ）し、結論を出力する | LLMに基づく推論、記憶、意思決定機能 |
| 行動（アクション） | 傘を手渡したり指示を出したりするなど、身体やツールを使用してタスクを完了すること | テキストの生成や物理デバイスの操作など、ツールや機械システムを呼び出してタスクを実行すること |
| フィードバックとイテレーション | 環境からのフィードバックに基づいて認識と行動を修正すること | 各インタラクションでフィードバックを取得し、意思決定とその後の操作を改善するために使用します |
、ただし、アーキテクチャ上において両者に重要な違いがあります：
ワークフロー（Workflows）：
LLM（大規模言語モデル）とツールの実行を調整します。 その行動は予測可能であり、確立された論理によって制約されています。 インテリジェントエージェント（エージェント）：
どのようにツールを使用してタスクを完了するかを決定します。 インテリジェントエージェントはより大きな柔軟性和応用性を持ち、タスクの実行方法に対してより高い制御権を持っています。
いつエージェントを使うか
LLMを使用してアプリケーションを構築する際は、できるだけシンプルな解決策を選択し、必要に応じてのみ複雑さを増すことが推奨されます。これは、つまり、時にはスマートエージェントシステムを構築する必要がないことを意味します。インテリジェントエージェントシステムは通常、より高い遅延とコストを伴いますが、それによりタスクのパフォーマンスが向上します。したがって、これらのトレードオフを実際のニーズに基づいて考慮する必要があります。
シンプルな解決策を優先する
ほとんどのアプリケーションでは、単一のLLM呼び出しを最適化したり、検索メカニズムやコンテキスト例を組み合わせることで十分です。
ワークフローの適用シーン
タスクが明確で、ルールが固定されている場合、ワークフロー（Workflow）はより高い予測可能性と一貫性を提供します。
インテリジェントエージェントの適用シーン
の方が良い選択です。
実現方法
以下は、去年見た『A Basic AI Agent』という図に基づいて整理した内容です。出典：https://lilianweng.github.io/posts/2023-06-23-agent/
1. エージェント（智能代理）
その核心部分は大規模言語モデル（LLM）であり、以下の重要な能力を組み合わせています：
：現在の目標と環境に基づき、行動戦略を策定する。 ：実行結果に応じて継続的に戦略を調整し、行動を改善する。 ：さまざまなツールを活用して特定のタスクを完了する。
記憶力 (Memory)
記憶力は、スマートなエージェントがより賢く動作し、タスクの再帰的な最適化を実現するのに役立ちます。
短期記憶 (Short-term Memory)： 現在のコンテキストを保存し、通常は LLM のトークンウィンドウサイズに依存します。 長期記憶 (Long-term Memory)： : 知識ベースから検索メカニズムを通じて関連情報を抽出する。 ：長期のインタラクションログを記録し、将来の計画や反省のための参考資料とする。
記憶の役割：
：過去の経験に基づいて現在の戦略を最適化する。 ：誤りを特定し、成功体験を总结する。
3. Planning（計画モジュール）
計画能力は以下のいくつかのサブ機能に分かれています：
：目標と実行戦略の妥当性を確認する。 ：行動や計画における問題を積極的に探す。 ：段階的な推論を通じて、複雑な問題を解決する。 ：複雑なタスクを実行可能なサブタスクに分割する。
にAI ウルフゲームを例とする（以前に既に共有済み：LLMのエージェントを使用してウルフゲームをプレイする）。Planningの各モジュールの継続的な最適化を通じて、LLMはゲームの論理と戦略をよりよく理解し、より賢いパフォーマンスを発揮できるようになります。
4. ツール（Tools）
ツールは、スマートエージェントの機能を拡張し、LLM自体の能力を超えた問題を解決可能にします：
：数学演算を実行します。 ：コードを解析・実行し、複雑なプログラミングタスクを処理します。 ：リアルタイムの情報を取得するか、既存の知識を確認します。 ：外部サービスを呼び出して結果を取得します。
：実世界でインテリジェントエージェントがより効率的に行動できるようにする。
5. 行動（アクション）
インテリジェントエージェントの行動方法には以下が含まれます：
：計画に基づいて戦略を実行する。 ：ツールは「拡張」された知能エージェントとして、複雑なまたは技術的なタスクを支援します。
反思（リフレクション）
リフレクションは知能エージェントにとって重要なプロセスであり、実行した行動を振り返り調整することで、システムの知能化レベルと適応能力を向上させます。以下では、https://lilianweng.github.io/posts/2023-06-23-agent/ を基に説明を展開します。
コア構造と機能
自己反射モジュール（LM）
自己チェック：自身の実行精度と効率を分析する。 メタ認知：「反思」を通じて実行戦略と長期的な意思決定を改善する。 外部および内部フィードバックを分析し、反射テキスト（Reflective text）を生成して、その後の行動の調整根拠を提供する。 自己を反省する能力は、スマートエージェントが自身の行動と意思決定の論理を評価できるようにします。 役割： 特性：
軌跡（短期記憶）
環境における動的な変化に迅速に適応します。 行動実行中のコンテキストデータを提供します。 最近の観測（Obs）と報酬（Reward）の軌道を記録し、評価器と行動モジュールにリアルタイムの参照情報を提供します。 役割： 特性：
Evaluator（評価器、LM）
動的な調整戦略をサポートします。 自己反射モジュールと連携し、長期的な改善にデータ面での支援を提供します。 短期記憶内の軌跡を分析し、外部フィードバック（External feedback）を組み合わせて内部フィードバックを生成します。 行動が目標と一致するよう確保し、潜在的な問題や最適化ポイントを識別します。 役割： 特性：
アクター（実行モジュール、LM）
行動の動的調整を行い、環境からのフィードバックに適応できる。 環境（Environment）に直接影響を与える。 計画とフィードバックに基づいて具体的な行動を実行する。 作用： 特性：
経験（長期記憶）
知識の蓄積とタスク間の汎化能力をサポートします。 過去の経験や反省文を保存し、将来の意思決定や行動に歴史的根拠を提供します。 作用： 特性：
システムの特性
自己点検能力（Self-examination）
行動を反射的評価モジュールを通じて動的に最適化する。 進行中の問題をリアルタイムで発見することができる。
動的挙動変更（Dynamically Modify Behavior）
内外部からのフィードバックに基づき、挙動モジュールの戦略と行動を調整する。
適応性と柔軟性（Adaptability and Flexibility）
環境の変化に応じて計画や行動を調整し、高い柔軟性を示すことができる。
デバッグとメンテナンス（Debugging and Maintenance）
自己反射モジュールと評価器がシステムの自己デバッグを支援し、メンテナンスコストを削減します。
ツール（Tools）
ツールについても詳しく説明します。この部分は主にAnthropicの経験に基づいています。どのような知能エージェントシステムを構築する場合でも、ツールはエージェントの重要な要素となります。ツールにより、Claudeは外部サービスやAPIと相互作用でき、APIによってその構造と機能が定義されます。Claudeがツールを呼び出す際には、API応答に「ツール使用ブロック（Tool Use Block）」が含まれます。全体的なプロンプトエンジニアリングと同様に、ツールの定義と仕様も慎重に設計する必要があります。
ツールフォーマットの設計に関する提案
指定のツールを使用する際には、しばしば同じ操作を達成するための複数の方法が存在します。例えば：
ファイルまたは全体のファイルを再書込することで行うことができます。 ：コードをMarkdownまたはJSONに埋め込むことができます。
ソフトウェア工学の観点からは、これらの違いは表面上であり無損失で変換可能ですが、LLMにとって書式の違いによる難易度の差が明確です。例：
ファイルでは、新しいコードの前に変更が必要な行数を事前に計算する必要があります。 JSON形式でコードを記述するには、改行や引用符などのエスケープ文字を処理する必要があります。
以下はツールのフォーマットに関するいくつかの提案です：
十分なトークンのスペースを確保する
モデルがコードを生成する前に十分な「思考」スペースがあることを確認し、論理的な行き止まりに陥ることを防ぎます。
一般的なフォーマットを使用する
モデルがインターネット上でよく目にするフォーマットを優先的に選択し、モデルの馴染みを高めます。
フォーマットの負担を減らす
モデルが追加の計算や複雑なフォーマットの処理、例えば大規模な行数のカウントや文字列のエスケープなどを行う必要を避ける。
ツール設計のベストプラクティスを向上させる
人間とコンピュータのインターフェース（HCI）が多くのデザイン投資を必要とするように、知能型エージェントとツールのインターフェース（ACI）にも同様の関心が必要です。以下にいくつか具体的な提案を示します：
1. モデルの視点に立って考える
ツールの説明やパラメータは直感的ですか？モデルを理解するのに苦労しますか？ 明確な使用例、境界ケース、入力形式の要件、およびそのツールが他のツールとどのように異なるかを示してください。
2. パラメータ名と説明の最適化
パラメータ名と説明をより直感的に設計し、チーム内の新人開発者向けに優れたドキュメントコメント（docstring）を書くようにしてください。 複数の類似したツールを使用する場合、この点は特に重要です。
3. テストとイテレーション
ワークベンチで複数のサンプル入力を実行し、モデルがツールを使用する際のエラーを観察し、継続的に設計を改善します。
4. エラープローフィング設計（ポカヨケ）
ツールのパラメータとインターフェースを調整し、誤使用が発生しづらくします。 例：AnthropicのSWE-benchエージェントでは、モデルがルートディレクトリから外れた後、相対パスを使用すると容易にエラーが発生しました。この問題を解決するために、Anthropicはツールを絶対パスのみを受け付けるように再設計し、モデルはこの方法を採用することで完璧に動作しました。
ツール設計の最適化を通じて、インテリジェントエージェントは複雑なタスクをより効果的に遂行できるようになります。例えば、SWE-bench の実装において、Anthropic は全体的なプロンプトではなく、ツールの最適化に多くの時間を費やしました。このような投資は、ツールの信頼性を向上させるだけでなく、システム全体の使いやすさと精度も向上させます。
エージェントの開発
オプションのフレームワーク
多くのフレームワークが、開発者がインテリジェントエージェントシステムをより簡単に実現するのに役立ちます。それには以下が含まれます：
モジュラーなツールチェーンを提供し、言語モデルの機能を組み合わせることをサポートします。これについては以前、一連の記事を書きました：
統一インターフェースを通じてスマートエージェントを構築およびデプロイする
ドラッグアンドドロップ式の GUI LLM ワークフロービルダー
複雑なワークロードの構築とテストをサポートする GUI ツール
これらのフレームワークは、LLMの呼び出し、ツールの定義と解析、コールの連結などの標準的な低レベルタスクを簡素化し、開発者が迅速に取り組めるようにします。しかし同時に、これらは追加の抽象化層を導入し、底层にあるプロンプトやレスポンスのロジックが見えにくくなり、デバッグが難しくなる可能性があります。さらに、これらのフレームワークは開発者に不要な複雑さを追加する傾向を与えますが、しばしばシンプルな設定で十分です。
開発の提案
LLM APIの直接使用から始める
多くのパターンは、フレームワークを使用せずに少量のコードで直接実装できます。
フレームワークの基礎となるロジックを理解する
フレームワークを使用する場合、その底层コードと動作メカニズムを理解していることを確認してください。 誤った仮定は、多くの顧客問題の一般的な原因です。
基礎構築ブロック：強化型LLM
は、インテリジェントエージェントシステムの基礎構築ブロックです。検索、ツール、記憶などの強化機能を統合することで、LLMは主动生成で検索クエリを作成し、適切なツールを選択し、保持すべき情報を決定することができます。
検索（Retrieval）
知識ベースやリアルタイムデータソースと連携し、タスクに最新で関連性の高いコンテキスト情報を提供します。 例：検索メカニズムを活用して複雑な質問への回答の精度を向上させる。
ツール（Tools）
LLM の能力範囲を拡張し、複雑なタスクを遂行可能にします。 例：電卓を呼び出して数学の計算を行うか、APIを使用してリアルタイム情報を検索する。
メモリ（Memory）
短期および長期の記憶をサポートし、インタラクションとタスク実行を最適化する。 例：タスクのコンテキストを保存し、マルチラウンド対話における文脈理解を支援する。
強化型LLMを実現する際には、以下の2つの側面に重点を置きます。
カスタマイズ能力
具体的な使用ケースに応じて機能を調整し、よりビジネスニーズに合った形にする。 システム設計がタスク目標を満たすことを確認しながら、不必要な複雑さを回避する。
使いやすさとドキュメント化されたインターフェース
LLMに対して明確で使いやすいインターフェースを提供し、開発者が迅速に理解し、強化機能を使用できるようにする。 すべての機能のドキュメントが詳細であり、デバッグとメンテナンスを容易にするようにする。
強化されたLLMは、スマートエージェントシステムの堅固な基盤を提供し、開発者はタスクの要件に応じてこれらの能力を柔軟に拡張でき、より広範なシーンで効率的なアプリケーションを実現できる。
組み合わせ型ワークフロー（Compositional Workflows）
以下は、LLMアプリケーションで一般的ないくつかのワークフローです。これらは、タスクの要件に基づいて適切な実装方法を選択するのに役立ちます。
1. プロンプトチェーン（Prompt Chaining）
タスクを複数のステップに分解し、各LLM呼び出しが前のステップの出力を処理するようにします。中間ステップでチェックポイント（ゲート）を設定してプロセスが正しいか確認できます。
適用シーン
タスクを明確に固定されたサブタスクに分解できる場合。 最低遅延を目指すよりも、精度を優先する場合。
例
：マーケティング文案を生成した後、別の言語に翻訳する。 ：まずアウトラインを作成し、チェックが合格後に内容を書き進める。
2. ルーティング（ルート）
入力の分類を通じて、タスクを異なる後続処理パスまたはツールに分流し、専門的な処理が必要なタスクカテゴリに適用されます。
適用シーン
タスクカテゴリが明確で、分類結果に高い正確性がある場合。 各タスクカテゴリは独自の処理方法を必要とします。
例
：一般的な質問、返金リクエスト、技術サポートを分類して処理する。 ：簡単な質問は小型モデルに割り当て、複雑な質問は高度なモデルに割り当てる。
3. パラレル化（並列化）
複数のタスクを同時に実行し、最終的に結果を集約します。
2つの方法に分かれています：
：タスクを独立したサブタスクに分割して並列処理します。 ：同じタスクを複数回実行して、多様な出力を生成します。
適用シーン
サブタスクは時間を節約するために並列処理できます。 結果の精度を高めるために複数の視点が必要です。
例
：一つのモデルがユーザーのクエリを処理し、もう一つが不適切なコンテンツをフィルタリングします。 ：コードの脆弱性を複数回レビューし、検出の信頼性をより高めます。
4. オーケストレーター-ワーカー
中心となるLLMが動的にタスクを分解し、複数のサブLLMに割り当て、結果を統合します。並列化とは異なり、サブタスクは入力によって動的に決定されます。
適用シーン
複雑なタスクで、サブタスクが事前に定義できない場合。 プロセスを動的に調整する必要があるタスク。
例
：要件に応じて複数ファイルの内容を動的に変更する。 ：複数の情報源を統合し、関連する内容を分析する。
5. Evaluator-Optimizer（評価者-最適化装置）
一つのLLMが結果を生成し、もう一つのLLMがフィードバックを評価し、そのループで最適化を繰り返す直到満足するまで。
適用シーン
タスクに明確な評価基準があり、反復的な最適化で顕著な向上が見られる場合。 LLMが価値のあるフィードバックを生成し、それに基づいて改善できる場合。
例
：LLMの出力を翻訳した後、評価者が改善提案を行う。 ：情報が包括的であることを確認するために、複数回にわたる検索と分析を行う。
上記のワークフローは、異なるシーンに対して構造化された解決策を提供し、タスクの複雑性、正確性、およびパフォーマンスの間でバランスを取るのに役立ちます。
自律型インテリジェントエージェント（Autonomous Agents）
本番環境でその能力を示し始めています。
働き方
タスク開始
エージェントのタスクは、ユーザーのコマンドまたはユーザーとのインタラクティブな議論から始まります。 タスクが明確になると、エージェントは独立して計画を立て、タスクを実行します。必要に応じて、より多くの情報を取得したり判断を求めたりするためにユーザーに戻ることがあります。
実行プロセス
タスクの実行中に、エージェントはツール呼び出し結果やコード実行フィードバックなどを利用して、環境から「真実データ」（Ground Truth）を取得し、タスクの進捗を評価します。 エージェントは、重要なポイントや障害に遭遇したときに停止し、ユーザーにフィードバックを要求できます。
タスク終了
タスクは通常、完了すると終了しますが、制御を維持するために停止条件（例：最大反復回数）を設定することもできます。
特性と実装
エージェントは複雑なタスクを処理できますが、実装は通常比較的シンプルで、主に大規模言語モデル（LLM）が環境に基づいてツールを呼び出すフィードバックループの中で行われます。
設計の重点
ツールセットとそのドキュメントの明確な設計は非常に重要であり、エージェントがツールを正しく理解し使用できるようにする必要があります。 詳しくは上記のツール（「プロンプトエンジニアリングによるツールの最適化」）におけるベストプラクティスをご覧ください。
自律型エージェント（Autonomous Agent）のシーンアプリケーション
適用シーン
オープンな質問に対して、必要なステップを予測するのが困難であり、固定のパスをハードコーディングできない場合。 エージェントが複数のラウンドで操作を行い、その意思決定に対して一定程度の信頼性が必要な場合。 自律型エージェントが信頼できる環境でタスクを実行する際、特に大規模なタスクの拡張に適しています。
注意事項
自律性にはコストが高く、誤りが累積するリスクがあります。 広範なテストをサンドボックス環境で行い、適切なガードレールを設定することを強く推奨します。
例を挙げると🌰
以下は、Anthropicの実装における2つの例で、これらは知能型エージェントの実世界での使用方法を示しています：
Coding Agent
：SWE-bench タスクを解決する。これらのタスクは、タスクの説明に基づいて複数のファイルを修正することを必要とする。 ：スマートエージェントは、タスクの説明に基づきコードベースを分析し、必要なファイル変更を計画し、段階的にタスクを実行し、複雑なコード編集のニーズを完了するために戦略を動的に調整する。
“Computer Use” Reference Implementation
：Claude にコンピュータを使用してタスクを遂行させる。 ：ツールの呼び出しや環境とのインタラクションなどの手段を通じて、エージェントは実際の計算環境で操作を行う能力を持っています。例えば、コマンドの実行、データの検索、または複雑な計算タスクの完了などが挙げられます。
エージェントは自律的な計画とフィードバックメカニズムを通じて、高い柔軟性と拡張性を示します。これは複雑なタスクに対処するための重要なツールですが、その安定性と信頼性を確保するために慎重な設計と厳密なテストが必要です。
エージェントの歴史的発展
AIエージェントの概念と技術は多年にわたり発展し、理論から実用的な応用へと進化してきました。以下は、https://arxiv.org/pdf/2308.11432 を基にした簡潔な振り返りです。
AIエージェントの応用
以下に一部の事例と表示内容を示します：https://x.com/omooretweets/status/1740774601876177375。このランドスケープは以前にも共有したことがあります（
これにより、2023年時点では、AIエージェントの応用がすでに複数の分野にわたっており、その強力な汎化能力と広範な適用性が示されています。2024年には、技術の成熟に伴い、AIエージェントの応用シナリオがさらに多様化しており、後で整理したいと思います。
最近、アンソロピックも今年の例を示しました：
クライアントとの協力により、アンソロピックはAIエージェントに特に適した2種類のユースケースを発見しました。これらのユースケースは、対話と行動を組み合わせ、明確な成功基準があり、フィードバックループが有効で、効果的な人的監督が組み込まれたタスクにおけるインテリジェントエージェントの実際の価値を示しています。
A. カスタマーサポート（顧客サポート）
これは以前、セコイアキャピタルのプレゼンテーションで聞いたのですが、顧客サポートと法務が最も適したシーンであるという話でした。（
カスタマーサポートは、お馴染みのチャットボットインターフェースとツール統合による強化機能を組み合わせており、よりオープンなインテリジェントエージェントの適用において自然な適合点を提供します：
対話が自然な流れで進む
インタラクションのサポートは通常、対話の流れに従いますが、同時に外部情報へのアクセスや具体的なアクションの実行も必要です。
ツールの統合
顧客データ、注文履歴、およびナレッジベース記事を検索するために使用できるツールを提供します。
自動化された操作
プログラミングを通じて返金の実行や工事注文の更新などのタスクを処理します。
成功は数値で測定可能
成功はユーザーが定義した解決基準（問題解決やタスク完了など）によって評価されます。
複数の企業が、使用量に基づく価格モデルを通じてこのアプローチの有効性を確認し、問題解決に成功した場合のみ料金を請求することで、そのエージェントの効果に対する信頼を示しています。
B. コーディングエージェント（コード代理）
ソフトウェア開発分野では、LLMの機能が大きな可能性を示しており、その能力はコード補完から自主的な問題解決へと発展しています。コードエージェントは以下の点で優れたパフォーマンスを発揮します：
解決策の検証可能性
コードの解決策は自動テストによってその正しさを検証できます。
フィードバック駆動型の最適化
エージェントはテスト結果に基づいてコードを反復的に改善できます。
問題空間が明確
ソフトウェア開発の問題空間は通常、構造化されており定義が明確です。
出力品質が測定可能
機能テストを通じて出力品質を客観的に評価します。
Anthropicの実装では、エージェントはプルリクエストの説明に基づいて、SWE-bench Verified ベンチマークテストにおける実際のGitHubの問題を解決できるようになりました。自動化されたテストが機能を検証できる一方で、人間によるレビューが依然として解決策がより広範なシステム要件に適合しているか確認するための鍵となっています。