コンテキストが新たな境界線です： プログラム可能なアプリケーション配信でAIエージェントを管理する

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

POST /agent/v1/invoke HTTP/1.1

ホスト: agentmesh.internal

認証: Bearer xyz123

Content-Type: application/json

X-MCPバージョン: 1.0

{

"context": {

    "ユーザー": { ... },

    "目標": "...",

    "prior_messages": [ ... ],

    "task_state": { ... },

    "セキュリティ": { ... }

  },

"input": { "prompt": "では、簡潔なチャートで視覚化しましょう。" }

 }

このコンテキスト ブロックは不可欠です。 それはエージェントの作業記憶として機能します。 エージェントが「知っている」すべてと、行動の前提となるあらゆる想定が含まれています。 すべてのホップでそれを引き継ぎますが、圧縮されず、時には検証もされず、ほぼ確実にターンごとに情報が古くなっていきます。

こうした負担が、最終的にコンテキストのずれを招きます。 ずれは以下の場合に発生します：

• ユーザーが移動した後も、以前の目標やタスクの状態が残り続けます。
• 過去のメッセージが積み重なり、リクエストが膨大になってエージェントに誤解を与えます。
• セキュリティタグは不用意に残ることがあります。
• 複数のエージェントが不要な情報を消去せずに同じスレッドを更新しています。

エージェント＃4がバトンを受け取る頃には、最新でない指示や時代遅れのアクセス制御、そしてもはや誰も気にしない「目標」に基づいて判断しています。 彼らは決して不満を言いません。 自信たっぷりに幻想を見て、その混乱をそのまま次に渡すだけです。

もしまだアプリケーション配信プラットフォームを単なるロードバランサーと考えているなら、その考えを変える時です。 他の人がチェスをしている間に、あなたはチェッカーで遊んでいることになります。

エージェント型アーキテクチャでは、プログラム可能なアプリケーション配信だけが以下の機能を持つレイヤーです。

• あらゆるリクエストを完全に把握できます
• コンテキストを検査し、変換し、ブロックまたはサニタイズする権限
• 特定のエージェントの意見や記憶にとらわれません

エージェントにリクエストごとに膨大な履歴を持ち歩かせないでください。

• prior_messages を直近の N 回分のやり取りに絞り込みます。
• 時間経過や状態変化に応じて目標を自動的に失効させます。
• インテントが継続から新しいタスクに切り替わる際にtask_stateを破棄します。

エージェントが入力を処理する前に、メモリ使用量と認知的衛生を管理できます。

コンテキスト ブロックにsecurity.classification = confidentialとあって、これからパブリックな要約 API にアクセスするなら、エッジにプログラム可能なポリシー監視が必要です。機密フィールドへのアクセスを遮断、編集、またはマスクし、すべてのリクエストでアクセス範囲を厳密にチェックします。 大規模言語モデル（LLM）はポリシーを深く理解しません。単に情報を漏らすだけです。

ユーザーは「四半期の指標を要約する」から「スライドデッキを作成する」へ切り替えましたか？ コンテキストは積み重ねるだけでなく、リセットする必要があります。 リクエストの目的が変わっても、コンテキストに古い目標やタスクの状態が残っているなら、そこでコンテキストを破棄して新たに始めてください。 こうすることでエージェントが昨日の課題を今日のデータで解決しようとするのを防げます。

あなたのアプリケーション配信レイヤーは、以下を追跡すべきです。

• 時間経過に伴うコンテキストブロックのトークンサイズ
• prior_messagesの成長率
• エージェント別の目標とタスクの不一致パターン

そうすれば、コンテキストの過剰膨張やずれを爆発前に見抜けます。 監視があれば、リーダーが「自律エージェント」が自信過剰なインターンのように振る舞う理由を尋ねても、確かな答えを伝えられます。