AIエージェントの仕組み — タスクを分解し自律的に実行する構造

具体例で見る「計画→実行→観察」のループ

「来週の大阪出張について、片道2万円以内の直行便を2つ提案し、あわせて出張先近くのホテルを1件挙げてください」という依頼を受けたエージェントを例に、内部でどう動くかを追ってみます。まずモデルは依頼を「航空券検索」「予算での絞り込み」「ホテル検索」という下位タスクに分解します。これが計画(plan)の段階です。

次に最初のツール呼び出しとして航空券検索APIを実行します(実行/act)。返ってきた検索結果をモデルが読み取り、予算条件に合う便が含まれているかを判定します(観察/observe)。条件に合う便が少なければ、検索条件を調整して再度ツールを呼び出し、十分な候補が揃った時点でホテル検索に移ります。この「計画→実行→観察」を繰り返し、内部で完了と判断するか、あらかじめ設定された最大ステップ数に達するまで続ける構造が、いわゆるReAct(Reasoning and Acting)型のエージェントの基本形です。

ツール呼び出し(Function Calling)が「行動」を可能にする

エージェントが外部に働きかけられるのは、モデル自体が何かを実行しているからではありません。開発者があらかじめ関数の名前・説明・引数の形式をJSON形式で定義しておき、モデルは「この関数をこの引数で呼びたい」という意図をテキストとして出力するだけです。実際の実行(APIコール、ファイル読み込みなど)はモデルの外側にあるアプリケーションコードが担い、その結果を新しいメッセージとして会話履歴に戻します。モデルはその結果を読んで次の一手を決めます。

つまり「エージェント」と呼ばれるものの正体の多くは、モデルの外側でツールの呼び出しと結果の受け渡しを繰り返すオーケストレーション用のループです。この点で、あらかじめ処理順序が固定されたスクリプトによる自動化とは性質が異なります。繰り返し作業をAIで自動化する設計で扱ったように、次に何をすべきかが状況によって変わる判断が必要な場面でこそ、モデルに次の一手を選ばせるエージェント構成の価値が出てきます。

メモリーの限界と設計

エージェントの「記憶」は、多くの場合そのモデルの文脈window(コンテキスト長)そのものです。会話履歴とツール呼び出しの結果はすべて文脈に蓄積されていくため、ステップ数が増えるほど文脈は長くなります。長い文脈では、モデルが文書の中間部分にある情報を見落としやすくなる傾向が研究で指摘されており、単に文脈長の上限に収まっているかどうかだけでなく、その中のどこに重要な情報があるかも実質的な制約になります。

この制約への対処として、古いステップの内容を要約して圧縮する、状態を外部のスクラッチパッドに書き出して必要な時だけ読み戻す、といった設計パターンが使われます。もっとも、要約自体もモデルの判断を経るため、要約の過程で細部が失われるリスクは残ります。メモリー設計は万能の解決策ではなく、失われても致命的でない情報とそうでない情報を区別する設計判断だと捉えるほうが実務的です。

長時間タスクでエージェントが崩れる理由 — 誤差の累積とコンテキスト制限

各ステップには、ツール結果を誤読する、引数を誤って生成する、といった一定の確率で誤りが起こりえます。仮に各ステップの成功率をpと単純化すると、nステップを連続して成功させる確率は理論上pのn乗に近づいていきます。これはあくまで単純化した考え方であり、実際の失敗率はタスクの複雑さやモデルによって大きく異なりますが、ステップ数が増えるほど累積的にリスクが高まるという方向性自体は多くの実装で共通して観察される現象です。

実際に現れる失敗パターンとしては、ツールからエラーが返ってきたにもかかわらず同じ呼び出しを条件を変えず繰り返すループ、途中のツール結果を誤読したまま以降の判断を続ける誤った分岐、文脈が長くなるにつれて冒頭の制約条件を実質的に無視してしまう現象などが挙げられます。いずれもモデル単体の性能というより、ループの設計とエラーの扱い方に起因することが多い点は押さえておく価値があります。

とはいえ、すべての作業をエージェント化すべきではない

ただし、処理の手順があらかじめ完全に決まっているタスクであれば、モデルに次の一手を判断させるエージェント構成よりも、決定的なスクリプトや単純なワークフロー自動化のほうが速く、安く、再現性も高いことがほとんどです。エージェントが価値を持つのは、次に取るべき行動が状況次第で変わり、事前にすべての分岐を書き下すのが現実的でない場面に限られます。この境界線を見誤ると、単純な定型処理にまで不要な自律性とコストを持ち込むことになります。

設計者に残る判断 — 自律性の範囲をどう線引きするか

エージェントの仕組みそのものは、計画・実行・観察のループとツール呼び出しという比較的シンプルな要素の組み合わせです。難しいのは仕組みの理解ではなく、どこまでの判断をモデルに委ね、どこで人間の確認を挟むかという運用上の線引きです。ステップ数の上限、扱えるツールの範囲、失敗時の振る舞いをどう設計するかによって、同じ仕組みでも安定性は大きく変わります。実際に最小構成のエージェントを組んでこの線引きを試した記録は、初めてのAIエージェントを作るで具体的に扱っています。