コンテキストが新たな境界に：プログラマブルなアプリケーションデリバリによるAIエージェントのガバナンス

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

AIOpsには、「MCPは単なるAPIの一種にすぎない」という危険な誤解が根強く残っています。

そうですね。SOAPも、誇大妄想を抱いたXMLにすぎませんでした。

エージェントベースのアーキテクチャ、特にModel Context Protocol（MCP）を基盤とするものは、リクエストのたびに引き継がれる明示的なコンテキストブロックに依存します。これは、ニューラルネットワークによる勘や「LLMの記憶」の話ではありません。シリアライズされた構造化済みの運用コンテキスト、つまり感覚ではなくJSONのようなものが呼び出しのたびに渡され、エージェントが目標、役割、ポリシー、ワークフローの状態を把握し続けるのに役立ちます。

しかし、現実にはコンテキストドリフトが発生します。そうなると、エージェントは単に混乱するだけではありません。誤った判断を正しいと確信し、動作が予測不能になり、さらには明らかに危険な状態に陥ることもあります。

問題は、すでにAIエージェントを試し、導入している人々が一歩先を行っていることです。実際、そのとおりです。F5の最新調査によると、9%がすでにAIエージェントを本番環境に導入し、29%が今後に向けた正式なアプローチを策定済みで、さらに50%が検討を進める「初期段階」にあります。AIエージェントをまだ検討すらしていないのは、わずか11%です。

その動きは急速です。業界全体を上回る速さで進んでいます。

実用的なコンプライアンスツールも、セキュリティ対策も、ベストプラクティスもありません。新しいテクノロジーの登場と同時に生じるセキュリティリスクに対処するための既存の選択肢は、事実上存在しません。

ただし、プログラマビリティは例外です。ここで役立つのが、アプリケーションデリバリおよびセキュリティプラットフォームです。単なる「ダムパイプ」ではなく、認知の健全性とコンテキストの規律を守る、プログラム可能なゲートキーパーとして機能します。

コンテキストが実際に伝わる仕組み

コンテキストは抽象的な概念ではありません。ペイロード内に実際に含まれています。実際のMCPリクエストは次のようになります。

POST /agent/v1/invoke HTTP/1.1

Host: agentmesh.internal

Authorization: Bearer xyz123

Content-Type: application/json

X-MCP-Version: 1.0

{

"context": {

"user": { ... },

"goal": "...",

"prior_messages": [ ... ],

"task_state": { ... },

"security": { ... }

},

"input": { "prompt": "Now visualize it with a quick chart." }

}

このコンテキストブロックは省略できません。エージェントの作業メモリとして、エージェントが「把握している」すべての情報と、行動の前提となるあらゆる仮定が含まれています。処理が次の段階へ進むたびに、圧縮されないまま引き継がれ、検証されないこともあり、ほぼ常にターンを重ねるごとに情報が古くなっていきます。

コンテキストが変質する仕組み（そして、それが重要な理由）

最終的にコンテキストドリフトを引き起こすのは、こうした余分な情報です。ドリフトは次の場合に発生します。

• ユーザーが次の作業に移った後も、以前の目標やタスクの状態が残り続ける。
• 過去のメッセージが蓄積すると、リクエストが肥大化し、エージェントの判断を誤らせます。
• セキュリティタグが、本来不要な箇所に残り続けます。
• 複数のエージェントが不要な情報を削除せずに同じスレッドを更新します。

エージェント#4に処理が引き継がれる頃には、古くなった指示、時代遅れのアクセス制御、そして誰も気にかけなくなった「目標」に基づいて判断するようになっています。エージェントは不満を口にしません。ただ自信満々にハルシネーションを起こし、その混乱を後続の処理へ引き継いでいきます。

プログラマビリティ：本当に必要なコンテキスト管理役

アプリケーションデリバリープラットフォームを、いまだに単なるロードバランサーだと考えているなら、おめでとうございます。世の中がチェスを指している中で、あなたはチェッカーをしているようなものです。

エージェント型アーキテクチャにおいて、プログラム可能なアプリケーションデリバリーは、以下を備えた唯一のレイヤーです。

• すべてのリクエストを完全に可視化
• コンテキストを検査、変換、ブロック、またはサニタイズする権限
• 特定のエージェントの見解やメモリに依存しないこと

エッジでのコンテキストの切り捨て

リクエストのたびに、エージェントに人類の全歴史を持ち回らせないでください。

• 直近N回のやり取りだけを残すように、prior_messagesを削減します。
• 時間の経過または状態の変化に基づいて、目標を自動的に失効させます。
• Drop task_state when intent switches from continuation to new-task.

これで、エージェントが入力を処理する前の段階で、メモリバジェットと認知的衛生を適用できるようになります。

分類とポリシーの適用

コンテキストブロックに「security.classification = confidential」と指定されているにもかかわらず、パブリックな要約APIを呼び出そうとしている場合は、エッジにプログラム可能なポリシー制御機能を配置し、機密フィールドのブロック、墨消し、マスキングを行うとともに、リクエストごとにアクセス範囲を検証する必要があります。大規模言語モデル（LLM）がポリシーの妥当性を判断してくれるわけではなく、そのままでは情報が漏えいします。

意図のドリフト検出

ユーザーの要求が「四半期指標を要約する」から「スライド資料を作成する」に変わった場合、コンテキストは単に蓄積するのではなく、リセットする必要があります。要求の意図が変わったにもかかわらず、古い目標やタスクの状態がコンテキストに残っている場合は、そのコンテキストを破棄して最初からやり直します。これにより、エージェントが今日のデータを使って昨日の問題を解こうとする事態を回避できます。

テレメトリとドリフトの監視

アプリケーションデリバリーレイヤーでは、以下を追跡する必要があります。

• コンテキストブロックのトークンサイズの経時変化
• 増加率：prior_messages
• エージェントごとの目標とタスクの不一致パターン

このようにして、コンテキストの肥大化やドリフトが深刻化する前に兆候を捉えられます。経営層から、なぜ「自律型エージェント」が自信過剰なインターンのように振る舞うのかと問われても、モニタリングによって具体的な根拠を示せます。

必要なのは、ファイアウォールだけでなく、コンテキストを整理する仕組み

LLMは、与えられたコンテキストをすべて無差別に取り込み、注意しなければ混乱を招きます。コンテキストがずれたり、目標が古くなったり、タスク履歴が悪影響を及ぼす状態になったりしても、エージェントは警告してくれません。プログラム可能なデリバリーレイヤーには、警告する機能があるだけでなく、それが不可欠です。

中立的な立場ですべてを把握し、ポリシーを適用できる唯一のレイヤーです。

エージェント型AIの時代、アプリケーションデリバリープラットフォームの役割は、単なるトラフィックのルーティングにとどまりません。セマンティックファイアウォールとして機能し、コンプライアンスを監視するとともに、エージェントがrootアクセス権を持つ自信過剰な嘘つきになるのを防ぐ、最後にして最大の頼みの綱です。

ドリフトと肥大化を放置すれば、失うのは制御だけではありません。AIスタック全体への信頼も失うことになります。

著者について

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

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

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