AIエージェントが意思決定をスタックの上位層へ移行

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

10年かけて磨き上げてきたアーキテクチャが、2年前には影も形もなかった何かに、今まさに一蹴されようとしている――そう気づく瞬間をご存じでしょうか。

エージェントアーキテクチャの時代へようこそ。

これは、一般的な自動化スクリプトやAIラッパーとは異なります。エージェントは目標に基づいて生成的に動作し、自律性をますます高めています。単にAPIを呼び出すだけでなく、APIを介して自ら進むべき道筋を決定します。さらに重要なのは、エージェントが独自のポリシーを持ち込むことです。

エージェントが送信する各リクエストには、次の情報が含まれる可能性があります。

インテントヘッダー（X-Goal, X-Context, X-Route-Preference）実環境でのSLAの重要度に基づくフォールバック指示 前回うまくいかなかったことの記録 「成功」とはどのような状態かを示すヒント（先に言うと、「200 OK」ではありません）

これは、動的な意思決定です。中央集約型の事前に計画されたオーケストレーションではありません。実行時の委任であり、インフラストラクチャの仕組みを変えていくものです。

これが重要な理由（思っているより早く）

現時点では、ほとんどのエンタープライズシステムでこうした摩擦はまだ顕在化していません。初期段階のエージェントは、依然としてチャットボットやコパイロット、あるいは単独で機能する生産性向上ツールにとどまっています。

しかし、エージェントがビジネスワークフロー（受注処理、保険金請求処理、トリアージ、フルフィルメントなど）に組み込まれるようになると、実際のシステムとの連携が始まります。つまり、次のようなことが起こります。

• インフラストラクチャは、エージェントが担うロジックを解釈する必要があります
• ゲートウェイは、JWTやパスだけでなく、より多くの情報を解析する必要があります
• ロードバランサーは、「最速」ではなく「このタスクに最適」という観点で判断する必要があります

まだ危機的な状況ではありません。しかし、その時は迫っています。問題が顕在化したとき、原因となるのは帯域幅の不足ではなく、エージェントの意思決定方法とインフラストラクチャのトラフィック処理方法の不整合です。

変化：適用から実行へ

アーキテクチャ上の本質は、エージェントによって意思決定がスタックの上位レイヤーへ移行していることです。

リクエストがコントロールプレーンになります。

インフラストラクチャに「どうすればよいですか」と尋ねるのではありません。「必要なのはこれです。このように動作してください。では、実行してください」と指示します。

システムがそれを通常のリクエスト、つまり単なる別のGETやPOSTとして扱うと、フォールバックロジックが競合し、再試行が重複します。その結果、ダッシュボードには現れない原因によって、エージェントのパフォーマンスが低下します。

インフラに障害が発生したからではありません。インフラが応答を受け取れていなかったからです。

その背景

この変化は理論上のものではなく、実際のフレームワークを通じて具体化しつつあります。たとえば、Model Context Protocol (MCP)、Agent-to-Agent (A2A)通信モデル、さらにはポリシーで制御されたタスクルーティングに関する初期の取り組みも、すべて同じ方向性を示しています。

• MCPは、目標、制約、フォールバックオプションを含む完全なコンテキストをリクエストペイロード自体に組み込みます。
• A2Aプロトコルにより、中央のオーケストレーターを介さずに、エージェント間でタスクを調整し、意思決定を動的に引き継ぐことができます。
• ランタイムでのタスク委任では、構造化メタデータを使用することで、実行時にインフラストラクチャが判断するのではなく、解釈できるようになります。

構文、構造、抽象化の方法は異なりますが、いずれも同じアーキテクチャ上の結果に行き着きます。つまり、ペイロードにポリシーを、リクエストに目的を組み込むということです。

そして、リクエストがロジックを担うようになれば、インフラストラクチャに残された選択肢は2つです。適応するか、単にペイロードを運ぶだけのパイプラインになるかです。

問題になる前に今できること

既存環境を全面的に刷新する必要はありません。変化がまだ初期段階にある今、先手を打つことが重要です。まずはここから始めましょう。

1. コンテキストを取得
   ログに記録：X-Intent, X-Task-Profileのほか、エージェントが何を達成しようとしているかを示す可能性のあるメタデータも記録します。オブザーバビリティの対象がURIまでにとどまっているなら、すでに対応が遅れています。
2. 「可用性」ではなく「タスク適合性」で考える
   バックエンドが稼働していても、十分に機能するとは限りません。SLA、レイテンシのしきい値、インテントを考慮した健全性モデルの検証を始めましょう。
3. ポリシーを高度化する
   既存のアプリケーションデリバリおよびセキュリティプラットフォームにはスクリプティングレイヤーがあります。これを活用し、インテントヘッダーの解析を始めましょう。サービスパスだけでなく、リクエストの目的に基づいてルーティングルールを変更します。
4. 適応型の適用に備える
   静的な設定ファイルでフォールバックロジックを定義するのではなく、リクエスト自体に埋め込まれたフォールバックの「指示」をインフラストラクチャで適用する方法を検討し始めてください。
5. フィードバックループを構築する
   エージェントが過去のパフォーマンスに基づいてトラフィックを再ルーティングする場合、そのループに関与する必要があります。結果に関するコンテキストをトラフィック管理システムとヘルス監視システムにフィードバックしてください。

最後に：役割がなくなるのではなく、新たな役割へと移行する

エージェント主導型アーキテクチャでも、インフラストラクチャがなくなるわけではありません。ただし、その役割は変わります。意思決定を担う存在から、決定事項をインテリジェントに実行する存在へと移行します。

その転換に早期に取り組めば、来るべき波に備えられます。そして、その波は確実に近づいています。

多くの人が考えているよりも早く。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事