AIエージェントの仕組み：LLMからフィードバックループまで

ChatGPTに質問を入力して回答を得るのと、「自社の競合を調査して比較表を作成し、メールで送って」と依頼し、それが複数ステップで自動的に実行されるのとは全く別の話です。後者が今日「AIエージェント」と呼ばれるもので、その内部動作を理解するには、テキストを予測するだけのモデルを、自ら決定し行動し軌道修正するシステムに変える6つの要素を分解する必要があります。

AIエージェントとは

AIエージェントとは、LLM（大規模言語モデル）を中心に構築されたシステムで、複数ステップのタスクを自律的に実行し、タスクの現在状態に基づいて各ステップで取るべきアクションを自ら決定します。通常のチャットボットとの本質的な違いは、背後にあるモデル（多くの場合同じ）ではなく、その周辺アーキテクチャ、すなわちステップ間のメモリ、計画サイクル、ツールへのアクセス、タスク完了まで繰り返すメカニズムにあります。

これにより、システムが実行できる作業の種類が根本的に変わります。チャットボットは質問に答えて終わりですが、エージェントは調査し、結果を読み、情報不足に気づき、別のキーワードで再検索し、すべてを整理してから最終回答を提供することができ、ユーザーが各ステップを仲介する必要はありません。

この用語は、リポジトリ全体を編集するコードエージェント、フォーム入力やボタンクリックを行うブラウザエージェント、顧客対応前に内部システムを参照するカスタマーサービスエージェントなど、外見が大きく異なる製品を包括する傘のようなものです。これらに共通するのは、この記事で詳述する6つの要素の構造です。各要素を個別に理解することで、異なる製品を公平に比較でき、画面上の最終結果だけで判断することを避けられます。

また、エージェントではないものも明確にしておきます。エージェントは「自由意志」を持つシステムではなく、開発者が定義した範囲外の決定は行いません。利用可能なツールセット、反復回数の制限、成功基準はすべて事前に設定されています。エージェントの自律性はこれらの制限内で現実のものですが、制限自体は人間が定義し続けます。

LLM：推論エンジン

LLMは次に何をするかを決定するコンポーネントですが、よくある誤解を解いておきます。モデルは呼び出し間で何も「記憶」しません。エージェントが決定を必要とするたびに、新しい完全なプロンプト（履歴、ツールの結果、指示を含む）を構築し、モデルに送信します。モデルはステートレスに応答し、組み込みのメモリはありません。

LLMが複数ステップにわたって「推論」しているように見えるのは、chain-of-thoughtと呼ばれる手法によるものです。モデルは最終回答に直接ジャンプするのではなく、最終アクションを決定する前に中間的な推論ステップを明示するように誘導されます。これにより、複雑な決定の品質が大幅に向上します。「考えながら書く」というプロセス自体が、モデルが重要な論理ステップを飛ばすのを防ぐからです。

実際には、エージェント内のLLMは非常に特定の役割を果たします。現在の状態（何が行われたか、ツールが何を返したか、元の目標は何か）を確認し、次のアクション（ツールの呼び出し、ユーザーへの追加情報の要求、タスク完了の判断）を決定します。

初心者を驚かせる点の一つは、同じモデル、同じプロンプトでも、実行ごとにわずかに異なる決定が生成されることです。これは、LLMのテキスト生成が確率的であり、決定論的ではないためで、温度と呼ばれるパラメータで制御されます。送金やデータ削除などの敏感な決定を行うエージェントでは、温度を低く設定してばらつきを減らし、動作をより予測可能にすることが一般的です（完全に決定論的になるわけではありません）。

また、エージェントの「LLM」は単一のモデル呼び出しであることは稀です。より洗練されたシステムでは、異なるステップに異なるモデルを使用します。単純なルーティング決定には安価で高速なモデル、深い推論が必要なステップにはより大きく高価なモデルを使用します。この役割分担により、品質を犠牲にすることなくコストを抑えられます。

メモリ

モデル自体は何も保存しないため、エージェントの「メモリ」はすべて、実際にはコンテキストエンジニアリング、つまり各呼び出しでプロンプトに何を戻すかを決定することです。実用的には2つのタイプがあります。

• 短期メモリ：現在の会話または実行の履歴で、モデルのコンテキストウィンドウ内に収まります。エージェントのステップごとに成長し、長いタスクではトークン制限を超えないように要約が必要になる場合があります。
• 長期メモリ：1回の実行を超えて保持する必要がある情報で、モデルの外部（データベース、ファイル、ベクトルインデックス）に保存され、関連するときにオンデマンドで取得されます。これに最も一般的な手法はRAG（検索拡張生成）です。応答前に、外部メモリから最も関連性の高い部分を検索し、プロンプトに注入します。

具体例で違いを理解しましょう。プログラミングエージェントがプロジェクトのコードを読む場合、現在開いているファイルは短期メモリとして保持しますが、チームの規約（「常に厳格なTypeScriptを使用」「ライブラリXは絶対に使用しない」など）は、新しいセッションごとに再読み込みされる設定ファイルに長期メモリとして保存されることがよくあります。

モデルのコンテキストウィンドウはどれだけ大きくても物理的なトークン制限があり、各トークンはコストと処理時間を消費します。そのため、エージェントを構築する際には、短期メモリに何を保持する価値があるか、何を要約または破棄できるかについて常に決定を下す必要があります。一般的な手法は段階的圧縮です。一定のステップ数ごとに、エージェント自体がそれまでの経過を要約し、生の履歴をその要約に置き換えて、よりコンパクトなコンテキストで実行を続けます。

RAGベースの長期メモリでは、背後でベクトルデータベースが使用されることがよくあります。情報の各断片は、その意味を表す数値ベクトル（埋め込み）に変換され、検索は正確な単語を探すのではなく、現在のクエリと意味的に最も類似したベクトルを探します。そのため、適切に設定されたRAGを持つエージェントは、ユーザーが入力した単語と完全に異なる単語を使用していても、関連するドキュメントを見つけることができます。

計画

複雑なタスクに直面した場合、エージェントが単一のモデル呼び出しですべてを解決することは稀です。現在最も一般的なパターンは、2022年に発表されたReAct（推論と行動）です。モデルは「考える」（何をすべきか推論する）と「行動する」（ツールを呼び出す）を交互に行い、各アクションの結果を観察してから次のアクションを決定します。一度に全体の計画を予測しようとはしません。

「計画して実行」パターンも存在します。モデルが最初に複数ステップの完全な計画を書き、その後で一つずつ実行を開始します。このパターンはより予測可能ですが、柔軟性に欠けます。途中のステップが失敗したり、新しい情報が明らかになったりした場合、エージェントは再計画する必要がありますが、この設計ではそれが自動的に処理されるとは限りません。

実際には、ほとんどの本番エージェントは両方を混合します。最初におおまかな計画を立て、実際の結果に基づいて数ステップごとに修正します。盲目的に最初から最後まで従うわけではありません。

ReActパターンの具体例：エージェントに「製品Xの在庫がある最寄りの店舗の営業時間を教えて」と尋ねます。一度に作成された固定計画はおそらく失敗します。なぜなら、エージェントはどの店舗が存在するか、どの店舗に製品があるかをまだ知らないからです。ReActでは、モデルはまず推論し（「近くの店舗を見つける必要がある」）、行動し（位置情報検索ツールを呼び出す）、結果を観察し、再び推論し（「今度は各店舗の在庫を確認する必要がある」）、再び行動し、十分な情報が得られた時点で最終回答を生成します。各決定は前の結果に依存するため、単一の固定計画では予測不可能です。

また、計画の深さの問題もあります。単純なタスクでは明示的な計画ステップをスキップしてツール選択に直接進むことができますが、多くのサブタスク間の依存関係がある複雑なタスクでは、明示的に計画を書き、場合によっては実行開始前にユーザーに表示して承認や調整を求めることが有益です。

ツール

ツールは、エージェントにテキスト生成を超えて現実世界で行動する能力を与えます。ウェブ検索、コード実行、データベース照会、メール送信などです。その背後にある技術的メカニズムはfunction calling（またはtool calling）です。開発者は各利用可能ツールを名前、説明、受け付けるパラメータのスキーマとともに記述し、モデルはどのツールをどの引数で呼び出すかを示す構造化された応答を返します。

モデル自体は決してツールを実行しません。モデルは呼び出しを決定しフォーマットするだけで、実際にコードを実行したり、HTTPリクエストを行ったり、データベースを照会したりするのはモデル周辺のソフトウェアです。この分離は重要です。つまり、同じ「脳」を、再トレーニングすることなく、プロンプトで利用可能な関数を再設定するだけで、まったく異なるツールに接続できるということです。

Model Context Protocol（MCPに関する前回の記事で詳述）は、まさにこれらのツールを記述・発見する方法を標準化し、エージェントが使用する外部サービスごとに個別の統合を必要としないようにします。

実際には、エージェントのツールはいくつかの繰り返しカテゴリに分類されることがよくあります。情報の検索と読み取り（ウェブ、ドキュメント、データベース）、外部システムへのアクション（メール送信、チケット作成、スプレッドシート更新）、コード実行（スクリプト実行、SQLクエリ、ターミナルコマンド）、ユーザーとの通信（確認依頼、明確化の質問）などです。適切に設計されたエージェントは、通常、システム内のすべてのツールに一度にアクセスできるわけではなく、タスクに必要なサブセットのみにアクセスできます。これは従来のシステムセキュリティで使用される最小権限の原則に従います。

各ツールの説明の質は見た目以上に重要です。あいまいな名前（process_dataなど）と一行の説明では、モデルがいつ使用すべきかを判断するのに十分なコンテキストがないため、誤った呼び出しや不正な形式の呼び出しが発生しやすくなります。具体的な説明と使用例、明確な制限（ツールが何をしないか）を記載することで、この段階でのエラー率を大幅に削減できます。

実行

実行は、ランタイムまたはエージェントオーケストレーターと呼ばれるソフトウェア層で、LLMの決定を受け取り、実際に実行します。適切なAPIを呼び出し、コマンドを実行し、応答を待ち、呼び出しが失敗した場合はエラーを処理します。ここにはセキュリティ層も含まれます。モデルが生成したコードのサンドボックス化、各呼び出しのタイムアウト、不可逆的な操作を実行する前のパラメータ検証などです。

混乱を招く詳細の一つは、すべての実行が逐次的ではないことです。より洗練されたエージェントは、相互に独立した複数のツールを並行して起動できます。例えば、3つの異なるソースを同時に検索することで、ツールを一つずつ呼び出して各応答を待つよりも全体のタスク時間を大幅に短縮できます。

この層でのエラー処理が、脆弱なエージェントと信頼できるエージェントを分けます。ツール呼び出しは数十の理由で失敗する可能性があります。外部APIのダウン、パラメータの不正な形式、権限の拒否、タイムアウトなどです。適切に構築されたオーケストレーターは、各タイプの失敗を個別にキャッチし、どう対処するかを決定します。自動的に再試行する（永久失敗を無限に繰り返さないように試行回数制限付き）、エラーを観測としてLLMに返して別のアプローチを試させる、または自動オプションが解決しない場合は問題を人間の介入にエスカレーションします。

ツールがモデル自身が生成したコードの実行を含む場合、サンドボックス化は特に重要です。このコードをエージェントが動作する同じ環境で直接実行することは実際のリスクであるため、真面目な実装では、この実行をデフォルトでネットワークや機密ファイルにアクセスできない使い捨てのコンテナや仮想マシンに隔離し、特定のタスクに本当に必要なものだけを解放します。

フィードバックループ

ツールが実行された後、その結果は消えずにコンテキストに戻り、LLMが次の決定で考慮すべき新しい情報となります。このサイクル（状態の認識、計画、行動、結果の観察、コンテキストの更新）は、次の2つのいずれかが発生するまで必要なだけ繰り返されます。モデルがタスクが完了したと判断するか、エージェントが最大反復回数や総実行時間などの安全制限に達するかです。

この反復回数制限は細かい詳細ではありません。これがないと、適切に設定されていないエージェントが同じアクションを繰り返し、タスクが完了したと見なさず、無期限にトークン（と費用）を消費するループに陥る可能性があります。そのため、ほとんどすべての真面目なエージェントフレームワークには、何らかのストッパーが組み込まれています。最大ステップカウンター、成功基準の明示的なチェック、または一定回数の試行で進展がない場合の人間の確認要求などです。

2種類の停止を区別する価値があります。「正常」停止は、LLMが現在の状態を元の目標に対して評価し、すべての基準が満たされたと明示的に結論付けた場合です。制限による停止は、エージェントが反復回数または許可された時間/コストの予算を使い果たした場合で、この場合の期待される動作は単に停止することではなく、その時点までに何が行われたか、なぜタスクを単独で完了できなかったかをユーザーに報告することです。

本番システムでますます一般的になっているパターンはhuman-in-the-loopです。高リスクのアクション（送金、データ削除、公的なコミュニケーションの送信）の場合、フィードバックループには、エージェントがそれが正しいアクションであると単独で決定した場合でも、次の反復に進む前に人間の承認を待つ必須の一時停止が含まれます。

完全なサイクル（図解）

6つの要素を組み合わせると、AIエージェントのサイクルは次のようになります。

この設計の中心点は、戻りの矢印が単なる装飾ではないことです。これがエージェントを単純な固定ステップの自動化フローから区別します。エージェントはサイクルの各周回で、続行する必要があるか、目標を達成したかを決定します。

チャットボット vs エージェント

両者を並べて比較する価値があります。最終製品を使うユーザーにとって、その境界線は必ずしも明白ではないからです。

側面	従来のチャットボット	AIエージェント
応答構造	一問一答	目標達成まで連鎖する複数ステップ
ツールアクセス	稀またはなし	中心的な機能（function callingまたはMCP経由）
ステップ間メモリ	現在の会話履歴のみ	短期・長期、多くの場合外部検索（RAG）付き
決定の自律性	低い（ユーザーが各やり取りを誘導）	高い（システム自身が次のステップを決定）
停止基準	生成メッセージの終了	タスクの成功基準または反復回数制限

実際には、境界線はスペクトラムであり、明確な線ではありません。多くの製品は今日、いくつかの単純なツールがプラグインされたチャットボットであり、完全な計画サイクルには至っていません。「エージェント」という用語は、ユーザーが明示的に要求したときに関数を実行するだけでなく、実際に自身の次のステップを決定するシステムに予約される傾向があります。

製品を評価する際に両者を区別する実用的なテスト：少なくとも3つの相互依存ステップを必要とするタスクを、ステップバイステップの詳細なしで、望ましい結果だけを伝えて依頼します。チャットボットは追加の指示を求めるか、単一の表面的な応答ですべてを解決しようとする傾向があります。真のエージェントはリクエストをサブタスクに分解し、ツールを使用して各サブタスクを解決し、サイクル全体を単独で完了した後にのみ最終結果を提供します。

完全な例

これを具体的にするために、架空の市場調査エージェントが「ブラジルにおける自社の主要競合他社3社を調査し、概要をメールで送って」という依頼を受けた場合を追跡します。

ステップ1、計画：LLMがリクエストをサブタスクに分解します。競合他社の検索、各社のデータ収集、概要の作成、メール送信。この初期計画は実行の短期メモリに保存されます。

ステップ2、最初のツール：エージェントが「[企業名] ブラジル 主要競合他社」というクエリでウェブ検索ツールを呼び出します。結果（名前とリンクのリスト）が観測として返ってきます。

ステップ3、フィードバックと再計画：LLMが検索結果に5つの名前があるが、必要なのは3つだけであることを観測します。最も関連性の高いものをフィルタリングし、各社に対して公開基本データ（規模、主要製品、市場プレゼンス）を抽出する新しいツールを呼び出すことを決定します。

ステップ4、並列実行：3つの競合他社は相互に独立しているため、オーケストレーターは3つの抽出呼び出しを同時に起動し、全体の時間を節約します。

ステップ5、統合：3つのデータセットが短期メモリにある状態で、LLMが比較概要のテキストを生成し、フォーマットします。

ステップ6、最後のツール：エージェントがメール送信ツールを呼び出し、生成された概要をメッセージ本文として渡します。

ステップ7、完了：LLMが送信確認を観測し、初期計画のすべての項目が満たされたことを確認し、サイクルを終了し、タスクが完了したことをユーザーに応答します。

ユーザーはステップ間で一度も介入する必要がなかったことに注目してください。これは、6つの要素（LLM、メモリ、計画、ツール、実行、フィードバックループ）のそれぞれが、前のセクションで説明された役割を正確に果たしたからです。

FAQ

AIエージェントには常に長期メモリが必要ですか？

いいえ。単一セッションで解決される単純なタスクは、短期メモリ（現在の実行履歴）だけで機能します。長期メモリは、エージェントが異なる実行間で何かを記憶する必要がある場合に重要です。

エージェントは通常、停止するまでに何回反復しますか？

タスクの複雑さと使用されるフレームワークの設定によって大きく異なりますが、ほとんどの本番システムは明示的な制限を設定しており、通常5〜25回の反復です。無限ループを防ぐためです。

プラグイン付きのチャットボットはすでにエージェントですか？

自律性の程度によります。ユーザーが各アクションを明示的に要求する必要がある場合は、ツール付きチャットボットに近いです。システムが目標を達成するために必要なアクションの順序を自ら決定する場合、それはエージェントの動作です。

実行中にツールが失敗したらどうなりますか？

オーケストレーターによります。堅牢な実装では、エラーを観測の一部として返し、LLMが再試行するか、別のアプローチを試すか、ユーザーに失敗を報告するかを決定します。サイクル全体を停止させることはありません。

エージェントは複数のLLMを同時に使用できますか？

はい、そしてますます一般的になっています。より小さく安価なモデルが単純なルーティング決定を担当し、より大きなモデルが深い推論を必要とするステップのみを担当することで、品質を損なうことなく全体的な実行コストを抑えられます。

専門用語を除けば、AIエージェントは新しい孤立したテクノロジーではなく、既知の要素（言語モデル、何らかのメモリ、ツールへのアクセス）を、目標が達成されるまで繰り返すサイクルに編成する特定の方法です。これら6つの要素を個別に理解することで、特定のエージェントがなぜ失敗するのか、ループに陥るのか、不完全な結果を出力するのかを診断できるようになり、システム全体をブラックボックスとして扱うことを避けられます。