AIエージェント・インフラストラクチャ：2026年完全ガイド

AIエージェント・インフラストラクチャとは、モデルが実際のシステムに対して作業を完了するための仕組みです。エージェントループ、ツール、呼び出し元のID、権限、永続状態、コード実行、アプリケーションバックエンド、テレメトリーが含まれます。モデル単体でも計画はできますが、これらがなければ安定して動作できません。

各レイヤーに一つの役割を持たせると、スタックを理解しやすくなります。二つのレイヤーが同じ書き込みを再試行したり、同じ状態を保存したり、認可をそれぞれ判断したりすると、障害の再現が難しくなります。

エージェントスタックを構成する7つの要素

モデルとエージェントループ

モデルは次のアクションを提案します。エージェントループはコンテキストを提供し、ツールを公開し、結果を記録し、実行をいつ停止するか判断します。フレームワークはループの実装に役立ちますが、ランタイムには時間、ツール呼び出し回数、支出について明示的な制限が必要です。

この区別は重要です。モデルを変更しただけで、権限ルールや復旧動作まで暗黙に置き換わるべきではありません。これらの制御はプロンプトの外側に置きます。

ツールと連携

ツールはループをデータベース、API、ファイル、ブラウザー、社内サービスへ接続します。良いツールは一つのタスクを説明し、入力を検証し、安定した結果を返し、呼び出し元が対処できるエラーを提示します。MCPツール仕様は検出と呼び出しを標準化しますが、仕様に準拠したMCPサーバーにも、曖昧または危険なツールは存在し得ます。

実際の設計ではツールの境界が重要です。エージェントが安定して使えるMCPツールの設計ガイドでは、名前、スキーマ、結果がツール選択にどう影響するかを説明しています。

IDとポリシー

エージェントの各セッションには、下流サービスが認可できるIDが必要です。ツール説明に読み取り専用と書いてあっても、そのルールを強制するのはデータを所有するサービスです。共有の管理者キーは操作主体を追跡できなくし、一つのシークレットが漏えいした場合の影響を拡大します。

OWASPのExcessive Agencyガイダンスは、拡張機能、権限、自律性を制限することを推奨しています。実務では、範囲の狭い認証情報、影響の大きいアクションを実行する前の承認、実行中のエージェントを停止または取り消す独立した手段が必要です。

状態とメモリ

状態はワークフローが実行した内容を記録します。メモリは、後の判断に役立つ可能性がある情報を提供します。両者は重なる部分がありますが、置き換えられるものではありません。注文IDと支払い結果は永続状態に保存します。質問への回答に役立つ取得済みの段落は、コンテキストまたはメモリに置きます。

多くの場合、構造化された状態とセマンティック検索の両方をPostgresで賄えます。エージェントメモリにおけるPostgresとベクトルデータベースの比較では、専用のベクトルサービスを導入すべき条件を解説しています。

永続実行とサンドボックス

永続実行は、完了済みの副作用を繰り返さずに、クラッシュ後のワークフローを再開します。サンドボックスは、信頼できないコードが実行中にアクセスできる範囲を制限します。一方が他方を代替することはできません。サンドボックスは重複した支払いを隔離できるだけで防げず、永続ワークフローは悪意あるコードであっても確実に再開してしまいます。

Temporalの永続実行モデルはワークフローの進捗を永続化し、障害後に決定論的なコードをリプレイします。一方、コードサンドボックスにはファイルシステム、プロセス、ネットワーク、シークレット、実行時間の制限が必要です。本番エージェント向けチェックリストでは、両方の制御を一つのリリース経路へまとめています。

アプリケーションバックエンド

アプリケーションには、引き続きデータベース、認証、オブジェクトストレージ、キュー、ホスティング、外部APIが必要です。エージェント向けバックエンドは構造化されたプロビジョニングとスコープ付き認証情報を追加し、コーディングエージェントが生成コード内にプロバイダーのシークレットを集めずに、必要なリソースを作成、運用できるようにします。

Cohesivityが担うのはこのレイヤーです。エージェントは隔離されたテナントを作成し、アプリケーションに必要なバックエンドリソースをリクエストし、後で所有権を人間へ渡せます。Cohesivityがモデルを置き換えたり、アプリケーションのビジネスルールを決定したりすることはありません。

テレメトリーと評価

テレメトリーは実行中に起きたことを記録します。評価は、固定されたタスク一式に対して動作が許容範囲にあるかを確認します。良いトレースはユーザーのリクエスト、モデル呼び出し、ツール呼び出し、ポリシー判断、下流の処理を結びます。良い評価は、モデル、プロンプト、ツール、ポリシーを変更した後に、代表的な成功例と失敗例を再実行します。

OpenTelemetryのGenAI規約は、モデルとエージェントのspanに共通フィールドを定めています。この規約は共通語彙を提供しますが、どの識別子や結果を記録しても安全で有用かは、アプリケーション側で判断する必要があります。

一つの本番ワークフローに必要な最小スタック

各行に別々のベンダーは必要ありません。ただし、それぞれの動作について責任を持つレイヤーを明確にする必要があります。

ベンダーを選ぶ前に一つのワークフローを整理する

書き込みを繰り返した場合、または誤った認証情報を使った場合に最も大きな問題となるワークフローを選びます。ユーザーのリクエストからバックエンドの最終的な効果までの経路を描き、モデル、ツール、ID、状態記録、実行境界、承認、トレースが現れる場所にラベルを付けてください。

一般的なスタック図より、ラベルが付かなかった箇所の方が有用です。以下のプロンプトは、プロジェクトを変更せずに、その対応関係をコーディングエージェントへ作らせます。