ペイロードにおけるポリシー: AIエージェントアーキテクチャに備える

AIエージェントは単なるインテリジェントなアプリケーションではありません。 彼らはアプリケーションの動作や意思決定、適応の在り方に根本的な変革をもたらします。 従来のシステムと異なり、エージェントはトラフィックポリシーに従うだけでなく、自分自身のポリシーを持ち込みます。 彼らが送るリクエストにはデータだけでなく、「何をすべきか」「フォールバックの振る舞い」「成功の定義」という組み込まれたロジックが含まれています。

この変革により、意思決定を静的なコントロールプレーンから実行時へと移します。 これによって、長年続いてきたコントロールプレーンとデータプレーンの分離が消え、ロードバランサーやゲートウェイ、プロキシなどのトラフィックインフラは、事前に設定されたルートを受動的に実行するのではなく、リクエストごとのポリシーを主体的に解釈する存在へと変わります。

この論文では、エージェントアーキテクチャがヘルスチェックやフォールバックロジックから可観測性やセキュリティ管理に至るまで、トラフィックエンジニアリングの重要な前提をどのように崩すかを解説します。 静的プールや平均ベースのヘルスメトリクスといった従来の仕組みが、リクエスト単位の意図が重視される現代においてなぜ不足しているのかを説明します。 そして、レイヤー7のインフラは進化しなければ、戦略的に見えない信頼される単なる配管として埋もれてしまうリスクがあると訴えます。 対応するために、あなたの組織はトラフィックの基盤を見直しましょう。実行時にプログラム可能で、コンテキストを理解し、モデルコンテキストプロトコル（MCP）などのエージェントネイティブプロトコルに対応させる必要があります。 フォールバックロジックを再設計し、セマンティックな可観測性を受け入れ、エージェント発信のポリシーの実施をサポートすることも含まれます。 リアルタイムデータラベリングなどの新しいツールが、この変革を強力に支えます。

要するに、トラフィック管理の未来はパケットを届けるだけでなく、目的を達成することにあります。

エージェントアーキテクチャでは、自律的に動作する生成AI搭載のコンポーネント、エージェントが目標に向けたタスクを遂行し、リアルタイムで意思決定を行い、状況に応じて実行内容を柔軟に変化させます。 これらのエージェントは、サービスチェーニングに似た役割を果たしますが、事前設定されたワークフローに依存しません。 代わりに、目標や環境の状態、得られた結果をもとに、実行時に適切な作業の流れを判断します。

従来の、あらかじめ定められたワークフローを持つ中央集権型のシステムから、リアルタイムで実行パスを組み立てる分散型の動的システムへと移行しています。 静的なマイクロサービスの連鎖による予測可能な動作を、ライブデータと意図に基づく柔軟で即応的な意思決定に置き換えます。

エージェントベースシステムは、次のように定義されます。

• 目標達成に基づく行動: エージェントは、静的なワークフローではなく、プロンプトやミッションに従って動きます。 目的に沿っているかを判断しながらAPIを選び、パラメータを調整し、ルートを切り替えます。

  例: 「顧客の苦情を解決する」担当者は、過去の結果に応じて請求、アカウント、メッセージングAPIを使い分けています。

• ポータブルコンテキスト: エージェントは自身のメモリ、状態、ポリシーを持ち歩きます。 モデルコンテキストプロトコル（MCP）や構造化メタデータを使い、各リクエストにこのコンテキストを組み込みます。
• 実行時の適応: インフラストラクチャの判断を待たずに、エージェントはリアルタイムで調整し、再試行や再ルーティング、エスカレーション、実行経路の変更を行います。
• 組み込みの可観測性： すべての行動は自ら説明しています。 エージェントは、なぜ特定のパスを選んだのか、何を評価したのか、目標が達成されたかを報告できます。 これは、単なるログや指標ではなく、行動としての観測性です。

これらが一体となり、アプリケーションの状況を予測可能なものから適応的で進化し続けるものへと変えていきます。

現在のトラフィック管理システムは明確な境界を軸に構築されています。

• コントロール プレーンは、有効なエンドポイントや優先する経路、適用すべきポリシーを明確に示します。
• データ プレーンはリクエストをルーティングし、セキュリティを適用し、負荷を分散させます。

このモデルは、サービス指向アーキテクチャやマイクロサービス環境で長年にわたり効果を発揮してきました。 トラフィックの流れを事前に予測し、ワークロードが一定のパターンで動くことを前提としています。

例:

• ロードバランサーは/api/loginを一つのプールに、/api/imagesを別のプールに振り分けます。
• ヘルスチェックによってノードの状態を利用可能か停止中か判別します。
• 静的なしきい値でフェイルオーバーの条件を判断します。

これらのシステムは、次の要素に基づいて動作します：

• 特定プールやメンバーなどの静的リソースにポリシーと構成が強く結びついていること
• プールやメンバーのような静的な構造
• パス、ヘッダー、プロトコルに基づく決定的ルーティング
• サービス検出、ヘルスチェック、およびフォールバックロジックの集中オーケストレーション

しかし、エージェントベースのシステムは流動性と自律性、そして独自の判断ロジックを取り入れており、そこでの前提を根本から変えます。

エージェント型のアーキテクチャでは、コントロールプレーンとデータプレーンの伝統的な区分が曖昧になりつつあります。 エージェントは単にリクエストを実行するだけでなく、リクエストの内容やフォールバックの条件、成功基準、さらには優先すべきルートまでのロジックを組み込んでいます。 本来はコントロールプレーンの役割であるこれらの情報を、エージェントはリクエストに伴うヘッダーやトークン、メタデータに込めてデータプレーン上を移動させています。

この統合によって、データパスはもはや中央の決定をただ受動的に実行するだけではありません。 データパスはポリシーを即座に積極的に解釈していきます。 リクエストは単なるパケットではなく、ポリシーの意図を持つ情報となりました。 そのため、ロードバランサーやゲートウェイ、ルーティング層は反応するだけの存在から、エージェントが示す意図をリアルタイムで読み取り解釈する役割へと進化させる必要があります。

この変化は、コントロールプレーンを静的かつ集中管理された存在とみなす、アーキテクチャ上の基本的な前提を覆します。 代わりに意思決定のロジックは分散され、可搬性と個別性を備え、リクエストごとに動的に流れ、実行時に適用されます。 これは単なる導入形態の変更ではなく、意思決定の場所と方法そのものが変わるということです。

これは、Kubernetes が基盤となるインフラ—ネットワークやストレージ、さらにはL4トラフィックのルーティングを抽象化し、宣言型の制御面の背後に「配管」としてまとめたことを完成させます。 それらの層を排除したわけではなく、あえて格下げしたのです。 見えなくし、自動化し、新しい意図に基づくシステムの下で機能させました。

エージェントアーキテクチャはインフラだけでなく、スタック全体に対して同じ役割を果たします。

これらの混乱を具体的に理解するために、ローカルのアプリケーション配信の例をご覧ください。

例： 地域のeコマースサイトはADCを使って内部APIのトラフィックを管理しています。 注文処理の速度を最適化するためにAIエージェントを配置しました。 特定のAPIエンドポイント、例えば /api/inventory/check が、リクエストの複雑化やバックエンドデータベースの競合によってパフォーマンス低下を起こしていることを特定しました。 「最速応答」などの従来の負荷分散アルゴリズムは、特定のプールメンバー全体の平均応答時間で性能を計算し、タスクや呼び出し単位での遅延の微妙な違いを捉えられません。

SLAを達成するために、エージェントは取引クエリに最適化された別のノードグループへ在庫確認のリクエストを再ルーティングします。 それぞれのリクエストに、例えばX-Task-Profile: inventory-sensitiveといったコンテキストヘッダーを付与して行います。 ロードバランサーは適切に設定されていれば、このヘッダーを理解し、トラフィックの誘導を行います。 ただ、これらのノードは/api/inventoryに紐づく静的プールに事前割り当てされていないため、トラフィックステアリングサービスはエージェントが渡す指示を尊重しつつ、静的設定に頼らず動的にルーティングを解決できなければなりません。

このシナリオは、プールのような静的な構造の限界と、状況を理解し動的に制御できるトラフィック実行の必要性を示しています。

エージェントベースのシステムは、ネットワークトラフィック管理のいくつかの基本的な前提を覆します。

制御プレーンとデータプレーンの融合: かつては静的ルールに従って行っていたルーティングの判断を、今ではリクエスト自体から導き出します。 これにより、従来の実施ロジックが不要になります。

インテントに基づくルーティング： エージェントは単にエンドポイントではなく、目的に応じてトラフィックをルーティングします。 /api/processのような単一のエンドポイントが、エージェントの指示によって数百もの異なるタスクフローを処理することがあります。

静的プールは時代遅れになります： 従来のプールは固定役割を前提としています。 しかしエージェントは、ある時はGPUアクセス、次にはCPU最適化を必要とするため、プールの縛りが厳しすぎます。

フォールバックとフェイルオーバーは戦略的に進化しています。 フェイルオーバーは以前、「次のサーバへ切り替える」ことを意味していました。 現在ではエージェントがリアルタイムのパフォーマンスや過去の結果を分析し、戦略的に判断して行動します。

トラフィックパターンは繰り返されるのではなく、自然に現れます。 エージェントが必要に応じてワークフローを作ります。 すべてのパスを事前に決めることはできません。ニーズに応じて形成されていきます。

こうした変化により、ロードバランサーやゲートウェイ、可視化システムは流動的でリアルタイムなトラフィック制御に即応する必要があります。

健全性とパフォーマンス指標は常にトラフィック管理の基盤です。 負荷分散の判断は、サーバーの稼働状態、応答速度、負荷の状況を知ることにかかっています。 しかしエージェント駆動型システムでは、健全性は単純な二者択一ではなく、パフォーマンスも広範囲の平均で測れません。 メトリクスは、ターゲットが単に稼働中かどうかではなく、特定のタスクに適しているかどうかを示す必要があります。

なぜ重要なのか： 健全性指標は、トラフィックの誘導、フェイルオーバーの判断、パフォーマンスの最適化に直接影響します。 エージェントネイティブ環境では、リクエストごとに異なる意図があり、それぞれに応じて異なる経路や応答保証が必要です。 従来の方法ではこの要件を満たせません。その理由は：

• 彼らはタスクごとの差異を隠す表面的な集計（平均応答時間など）に頼っています。
• エージェントレベルでの成功や満足度を把握せず、サーバーの視点だけで健全性を評価しています。
• リクエストを実行時の判断で制御すると、トラフィックの均質性は成立しません。

例： APIサーバのプールはヘルスチェックで「正常」とされても、いずれか一つがX-Task-Profile: inventory-sensitiveクエリに対して常に100ms以下で応答できないことがあります。 そのレイテンシープロファイルを期待しているエージェントは、インフラが問題なくても失敗と判断します。

必要なものは以下の通りです：

• 意図と実際の結果をリアルタイムでリクエストごとに可視化するテレメトリ.
• 他のタスクでは正常であっても、一部のタスクではノードのパフォーマンスが低下していることを認識できる、タスク固有の正常性スコアリング。
• エージェントが報告した成功や失敗の情報をリクエストルーティングと優先順位付けのロジックに取り入れて、フィードバックループを機能させます。

データラベリングツールは、移動中のトラフィックにラベルを付け、パフォーマンスとコンテキストの整合性を記録することで、大きな役割を果たします。 これにより、システムは何が起こったかだけでなく、それが行動を起こした主体の目的にかなっていたかを判断できます。

従来のインフラストラクチャでは、再試行やバックアップノードへのリダイレクト、サーキットブレーカーの発動などのフォールバック動作をインフラ層で管理してきました。 ロードバランサーやプロキシ、ゲートウェイでは、あらかじめ設定したしきい値（例えばタイムアウトやエラー率）に基づき、ターゲットへのトラフィックを止めて別ルートを試すタイミングを判断しています。

エージェントアーキテクチャは、従来の考え方を根本から変えます。

エージェントは自らのフォールバック戦略を持ち込みます。 彼らはリクエストに再試行ポリシー、エスカレーションロジック、目標に沿った優先順位を組み込んでいます。 そのため、インフラレベルのフェイルオーバー機構と複雑さや潜在的な衝突が生じます。

なぜそれが重要なのか:

• インフラストラクチャは障害を回復可能と判断しても、エージェントはそれを受け入れられないと見なす場合があります（またはその逆の場合もあります）。
• エージェントもインフラストラクチャも同時にフォールバックを試みることがあり、不要な再試行で遅延が増えたりトラフィックループを引き起こしたりします。
• 平均的なトラフィックを想定して設計されたサーキットブレーカーは、エージェントが依然として最適と判断するサービスへのアクセスを遮断してしまうことがあります。

主なリスク

• 二重フォールバック： エージェントとインフラストラクチャが両方とも再試行し、不必要な負荷をかけています。
• 競合状態： システムが数ミリ秒で問題を解決できても、エージェントはより高コストかつセキュリティの低い選択肢に切り替えてしまいます。
• 確実なフェイルオーバーを損なう原因： 静的なポリシーはエージェントの微妙な違いに対応できません。
• 破損: エージェントのメタデータが壊れているか欠落しており、読み取れません。

適応に関するガイドライン：

• インフラストラクチャは、エージェントが指定したフォールバックの優先順位（例：X-Fallback-Order、X-Timeout-Preferenceを通じて）を認識できるよう進化させるべきです。
• サーキットブレーカーは、グローバルなしきい値ではなく、タスクやエージェントごとの意図に応じたロジックをサポートするよう設定しましょう。
• エージェントが希望する戦略を提案し、ゲートウェイがシステムの状態、負荷、ポリシーに基づいて判断するネゴシエーション対応のフェイルオーバーロジックの導入を検討しましょう。
• エージェントのメタデータが欠落、不完全、またはスキーマ検証に失敗した場合でも、交通システムはデフォルトの実行ロジックを提供し、スムーズに機能低下させることが必要です。
• インフラストラクチャは、システム劣化時にループが発生したりトラフィックが増幅されたりする原因となる再帰的委任や競合エージェントの再試行を速やかに検出し、防ぐ必要があります。

例： リアルタイムの不正チェックを任されたエージェントは、50ミリ秒以内の応答を求めます。 そのフォールバックロジックでは、遅い完全クエリよりもキャッシュ済みの部分結果を優先します。 この状況を把握していないインフラストラクチャは、完全なサービスのバックエンドにルーティングし、ユーザーに遅延を感じさせます。 もっと協調的なモデルなら、エージェントのフォールバック優先度を尊重し、より高速な劣化レスポンスを提供します。

意思決定がスタックの上層に移ると、フォールバック戦略も同様に適応させる必要があります。 サーキットブレーカーや再試行の仕組みは固定的で不透明なままでは通用しません。安全性と公平性を保ちつつ、エージェントの優先事項に合わせて変化させていきましょう。

私たちは、エージェント アーキテクチャが意思決定と調整をリクエスト層に移しても、基盤となるインフラストラクチャがコアシステムの信頼性を確実に守る責任を負っていることをご理解いただけます。 つまり、インフラストラクチャ層での高可用性（HA）やフェイルオーバーの仕組みが不可欠であることに変わりはありません。 むしろ、システムがより動的で自律的に機能するほど、これらの重要性は増していきます。

エージェントは目標や状況に応じてトラフィックを制御しますが、ロードや障害時もサービスの到達可能性と耐障害性を保つために、ネットワークに依存し続けています。 ロードバランサーは到達不能なノードや故障中のサービス、劣化した環境を検知し、エージェントのフォールバック戦略に関係なくリアルタイムでトラフィックを再ルーティングします。

変わらない主要な責任:

• プールメンバーとバックエンドサービスの状態を監視します
• ネットワークの分断やルーティング障害を検知します
• 稼働状況や可用性、システムの劣化を踏まえてトラフィックをルーティングします
• 必要に応じてステートフルサービスやセッションの高可用性を確保します

エージェントは「次の動作」を判断するロジックを持っていますが、「ノードの障害からどれだけ素早く復旧するか」はロードバランサーが責任を持ちます。

適応型でエージェント対応のルーティングロジックは、運用の安定性を損なってはなりません。 適切に監視されたインフラストラクチャは、次の点を確実に維持しなければなりません。

• ノードが使えなくなったときに即座にフェイルオーバーし、トラフィックを効果的に再配分します
• 上流の障害からエージェントとサービスを守る、高耐久なHAトポロジー
• エージェントのフォールバックロジックを妨げず補完する、高速な自動復旧機能

つまり、エージェント駆動型アーキテクチャはフェイルオーバーを不要にするのではなく、むしろその重要性を高めます。 あなたのインフラストラクチャは、より迅速に、より状況を踏まえて反応し、自律的な動きを妨げるボトルネックとならないことが求められます。

エージェントベースのアーキテクチャは、ロードバランサやゲートウェイなどのトラフィックシステムの運用方法に根本的な変化をもたらします。 従来のトラフィックシステムでは、リクエストとは切り離された事前設定のポリシーに基づき判断を下していましたが、エージェント駆動型システムではそのポリシーをリクエスト自体に組み込んでいきます。 これこそがモデルコンテキストプロトコル（MCP）が可能にする、リクエスト単位でのポリシー埋め込み実行の基盤となっています。

このモデルを「ペイロード内ポリシー」と呼びます。 中央集約型のシステムがすべての例外を解析する代わりに、エージェントが退避戦略やノードの優先順位、エラー許容範囲、プライバシー要件などの関連ポリシーを各リクエストに埋め込みます。 あなたのインフラは、それらのポリシー指示をリアルタイムで読み解き、判断し、即座に対応する必要があります。

この新しい実行モデルにより、トラフィック管理の役割が大きく変わります。

• 意思決定者から実行者へ： インフラストラクチャはトラフィックの行き先を決めるのではなく、エージェントの意思決定を確実に実行します。

  例： X-Route-Preference: gpu-optimized を読み取るロードバランサーは、そのノードが元のプールになくても、トラフィックを適切に転送します。

• 実行時にプログラム可能: iRules とポリシーは X-Intent、X-Context、X-Goal といったヘッダーを評価します。 これにより、ロジックは事前設定された経路から動的なインライン解釈に変わります。
• コンテキストに応じたルーティング: ADCや類似するサービスは、ホストやパスだけでなく、IDや意図、コンテキストに基づいてルーティングを行います。
• セマンティック観測性： ログは何が起きたかだけでなく、その理由まで示すべきです。 「レイテンシ閾値突破のためエージェントが経路変更を行いました」は単に「プールBにルーティングされました」よりも役立ちます。

データラベリング技術や類似のツールを活用し、リアルタイムのリクエストコンテキストにタグ付けと分類を行うことで、セマンティックルーティングと可観測性を実現できます。

AIエージェントは単独で動作しません。 レガシーシステムと連携し、従来のAPIを利用し、企業のデータベース内のビジネスロジックを操作し、モノリシックなバックエンドやマイクロサービスの関数も呼び出します。 企業はゼロから始めるのではなく、段階的に進化させる必要があります。

エンタープライズスタックは次の要素が融合しています。

• 金融分野では今も数十年前のSOAP APIを利用しています
• Webアプリケーションの背後にあるRESTfulサービス
• 非同期の在庫システム向けメッセージキュー
• クラウドネイティブ環境のマイクロサービス
• レート制限と複雑な認証がある SaaS API
• LLMと細かく調整されたエージェント

Agentsはすべての領域で連携して動作する方法を習得しなければなりません。 そしてインフラストラクチャは、文脈を理解したポリシー実施により、そのやり取りをリアルタイムで調整できるようになる必要があります。

エージェントは複数のエンドポイントではなく、一つの目的を求めています。 ビジネス機能（例：「注文状況の取得」）を抽象化レイヤーやAPIコンポジションを通じて公開し、エージェントが一つの統一された入口から利用できるようにしましょう。

準備手順： APIゲートウェイやサービスメッシュを活用して、明確な入出力契約を持つタスク指向のエンドポイントを統合しましょう。

従来のログはメソッド、パス、応答時間に注目します。 ですが、エージェントが注目するのは次の点です。

• 課題の内容
• 試みたフォールバック手段
• あなたの目標が達成されたかどうか

準備手順： X-Intent、X-Task-Type、X-Agent-Outcomeといったラベルでトラフィックにタグ付けするセマンティック監視ツールを導入しましょう。

エージェントはフォールバック指示、タイムアウト設定、セキュリティ要件をリクエスト内に含めます。 既存のインフラストラクチャはそのデータを破棄しています。

準備手順： トラフィック ポリシーを拡張して、エージェントのメタデータ（例：X-Route-Preference、X-Fallback-Order、X-Data-Class）を解析し、それに基づいて処理します。 iRulesや類似のランタイムスクリプトから始めましょう。

エージェントは自律的に動きます。 押さえておくべきポイントは次の通りです：

• どのエージェントが誰に代わって行動しているか
• 使用可能なツール
• どの範囲のデータにアクセスを許可するか

準備ステップ： IPホワイトリストや静的RBACだけでなく、アイデンティティベースのアクセス制御と属性ベースのポリシー制御（ABAC）を統合しましょう。

インフラストラクチャとエージェントが復旧を競い合う必要はありません。 一方はランタイムの目標に取り組み、もう一方はシステム全体の安全を守ります。

準備手順: エージェントのフォールバックの範囲（エージェントが管理する範囲）とインフラストラクチャのフェイルオーバー（あなたが管理する範囲）をはっきり区別してください。 交渉ルールと上書き条件を明確に定義しましょう。