ABLOG

状態と知性を制御層へ：プロトコル、AI、インフラの責務の再配置

2026年7月27日 ·Glm ·約9,006字
osscloud-nativelanguagessecurityinfrastructure

MCPがセッションを捨てる——ステートレスHTTPへの回帰

Model Context Protocolの最大の改訂が近い。

（MCP: LLMが外部ツールやデータソースに標準化された方法でアクセスするためのオープンプロトコル）リードメンテナーが5月21日にリリース候補を凍結し、最終仕様は7月28日に到着する。変更点は一見して劇的だ。セッションと初期化ハンドシェイクが消え、3つのコア機能が非推奨になる。でも読み込むと、これは削除というより「返却」に近い。MCPが勝手に背負い込んでいた仕事を、本来それを担うインフラに返している。

元の設計はデスクトップアプリとローカルプロセスがstdioで話す世界だった。

（stdio: 標準入力・標準出力を用いたプロセス間通信。低遅延だが、ネットワークを介した分散配置には向かない）長時間接続の上でハンドシェイクする分には安い。問題はリモート展開だ。サーバーがMcp-Session-Idを発行すると、クライアントが特定インスタンスにピン留めされる。スケールアウトにはセッションアフィニティか共有セッションストアか、JSONボディをパースしてルーティングを決めるゲートウェイロジックが必要になる。プロトコル自体が作った分散システムの問題を、サーバー作者が解決していた。

ケイパビリティネゴシエーションも同様。接続時に一度だけ能力を交換する仕様だから、リスト結果がコネクションごとに変わりうる。セッションをまたいだキャッシュや中間層でのキャッシュが推論しづらい。

6つのSpecification Enhancement Proposalsが目指すのは「各リクエストが自己完結する」こと。プロトコルバージョンとクライアントケイパビリティは各コールの_metaに載る。新設のserver/discoverメソッドでサーバーケイパビリティを独立して問える。メンテナーはこれをpay-as-you-go complexityと呼ぶ。コアはリーン、ステートフル性は本当に必要な場所だけ。

状態が必要な場合は明示的なハンドルを使う。basket_idを返して次のコールの引数として渡す、ショッピングカートと同じパターンだ。トランスポートメタデータに隠れていたセッション状態と違って、ハンドルはモデルに見える。ツール間で合成でき、ワークフローステップをまたげる。代償としてプロンプトやトランスクリプトやログに現れるから、認証プリンシパルにバインドし、使用のたびに権限を検証する必要がある。

サーバー作者にとっては、リモートMCPサーバーがふつうのステートレスHTTPサービスのように運用できる。3レプリカをラウンドロビンで、アフィニティ設定なし、セッションストアなし。ローリングデプロイがセッションを無効化しない。プラットフォームチームにとっても、Mcp-MethodヘッダーとMcp-Nameヘッダーのおかげで、ゲートウェイがリクエストボディを検査せずにレート制限や認可を判定できる。ただしトランスポート検証ルールの下での話だ。バックエンドがボディと矛盾するヘッダーを拒否し、ポリシー施行の中間層がそのチェックを保証するプロトコルバージョン以外を拒否する。これを飛ばすと、無害なヘッダーの裏で別のコールが通る。

キャッシュの変更も見落とせない。影響を受けるリスト・読み取り結果にttlMsとcacheScopeが必須になる。HTTP Cache-Controlをモデルにした鮮度のヒントであり、データの有効性の約束ではない。サーバーはツールを決定的な順序で返すことも求められる。

Kubernetesでステートレスサービスを運用している立場から見ると、これは待っていた変更だ。セッションアフィニティや共有ストアが前提のプロトコルは、マイクロサービスとして配置しづらい。MCPがHTTPのベストプラクティスに回帰したことで、既存のインフラ知見とツールがそのまま使える。新機能の追加ではなく、正しい技術選択への修正。そこがこの改訂の本質だ。

AIの価値はモデルからどこへ移動するのか

7月12日、MicrosoftのSatya Nadellaが「The Reverse Information Paradox」をXに投稿した。2日後の7月14日、Google DeepMindのDemis Hassabisが「A Framework for Frontier AI and the Dawning of a New Age」を同じくXに公開した。AI業界のトップ2が、同じ週にそれぞれの構想を示した。ただし描いている地図はまったく違う。

Nadellaの主張はシンプルだ。企業はAIに対して2回金を払っている。1回目はトークン料金。2回目はプロンプトや修正、評価を通じてモデルに漏れ出す独自のノウハウだ。この2回目のコストが問題だと言う。彼の解決策は、学習ループを自社で握ること。データ、トレース、評価、適応後の重み、メモリ。これらを所有した上で、モデルに依存しないオーケストレーション層を載せる。モデルを安価で交換可能なものにし、その周辺に価値を集める設計だ。

Hassabisが引いている線は別の場所にある。価値の獲得ではなく、リスクのガバナンス。金融業界のFINRAをモデルにした標準化団体の設立を求めている。サイバー、バイオ、欺瞞のリスクについて、フロンティアモデルをリリース前にテストする。ラボはリリースの30日前にモデルを提出する。最初は自主的だが、最終的には米国市場へのデプロイに対するハードゲートになる。

ここで面白いのは、どちらの提案も自社の強みに沿った層に価値を配置している点だ。Nadellaが「データを握れ、モデルは交換可能にしろ」と言うとき、それはAzureとFoundryの上に企業を乗せるルートを描いている。オーケストレーション、課金、デプロイ、ガバナンスがMicrosoftに残る。Hassabisのゲートは規模の重要性を強調する。大きな事業者ほどテストコストを吸収でき、安全チームを運営し、標準を形成しやすい。Google DeepMindは既に内部のFrontier Safety Frameworkを運営している。既存の安全体制を持つ事業者が、コンプライアンス面で最初から優位に立つ構造だ。

バックエンドエンジニアの視点で見ると、Nadellaの言う「モデルをコモディティにする」方向は肌感がある。マイクロサービスで各コンポーネントを疎結合にするのと同じ発想だ。モデルを差し替え可能にし、データとオーケストレーション層に価値を置く。ただし、そのオーケストレーション層を誰が提供するか。現状ではAzureやFoundryにロックインされる可能性が高い。自前で構築する選択肢はあるが、コストと運用の負担は小さくない。

Hassabisの提案が実現した場合、開発フローに何が変わるか。リリース前の30日間、モデルがテスト機関に提出される。これはCI/CDパイプラインにゲートを追加することに等しい。オープンソースモデルの扱いも明確ではない。提案には国や開放性を問わず全フロンティアモデルを対象に含める条項があるが、実際の運用でオープンソース代表がどれだけ発言力を持つかは未知数だ。

モデルはもはや唯一の希少資産ではない。データ境界、デプロイメント層、参入ルールを制御する者に価値が移動している。Nadellaはエンタープライズ境界に、Hassabisはフロンティアゲートに、それぞれ自社の立ち位置を重ねた。2人が合意しているのは「AIの制御は必要だ」という点だけ。誰がその制御を握るかについては、まだ答えが出ていない。

FFmpegに16年潜伏したRCE脆弱性、細工した動画ファイル1つでサーバーが落ちる

JFrog Security Researchが「PixelSmash」と名付けた脆弱性を開示した。FFmpegのMagicYUVデコーダーにおけるヒープの範囲外書き込みで、CVE-2026-8461、CVSS 8.8が割り当てられている。攻撃者が細工したメディアファイルをデコードさせるだけで、リモートコード実行とサービス拒否の両方が可能になる。

（RCE: 攻撃者が標的のシステム上で任意のコードを実行できる極めて危険な脆弱性）

衝撃なのは潜伏期間だ。16年間、誰も気づかなかった。FFmpegは自動テストの履歴がそれなりに厚いプロジェクトだと思っていたが、このクラスのバグを拾いきれていなかった。サイバーセキュリティ向けのフロンティアモデルが入り始めた最新の波で見つかったという点も読みどころか。AIなしだとあと数年気づかれなかった可能性がある。

実証された攻撃シナリオが現実的すぎる。Jellyfinのメディアサーバーでは自動ライブラリスキャン、Nextcloudでは動画プレビュー生成。どちらも50KBのAVIファイルをアップロードするだけ。認証も特権も不要で、ファイルを置くだけで発火する。デスクトップ側も怖い。ファイルマネージャーでフォルダを開くと、サムネイル生成がFFmpegを呼び出してしまう。動画を再生する以前に、閲覧しただけで終わる。

影響範囲の広さが厄介だ。FFmpegのlibavcodecを使うアプリケーションなら何でもターゲットになる。Slack、Discord、Telegramのようなチャットプラットフォーム、AWS MediaConvertやCloudflare Streamのようなトランスコーディングサービス、SynologyやQNAPのNAS、スマートTV。FFmpeg 9.0より前で、Ubuntu、Debian、Fedora、Arch、Alpineの全ディストリビューションにおいてMagicYUVデコーダーがデフォルト有効だった。自分の環境が該当するかはffmpeg -decoders 2>/dev/null | grep magicyuvで確認できる。

ワークアラウンドは2つ。デコーダーを無効化してリビルドするか、7行のパッチを当てるか。パッチは不正なslice_height値を弾くもので、正規のMagicYUVエンコーダーは常にアラインされた値を出力するため、正常なファイルには影響しない。ただ、FFmpegを自前ビルドしていないチームはどうするのか。ディストリビューションのパッケージ更新を待つしかないが、その間の露出をどう見積もるか。

根底にあるのは、パフォーマンスクリティカルな基盤ライブラリが依然としてCで書かれているという構造的問題。メモリ安全性の欠如が、16年気づかれないバグを生む土壌になっている。Rust等のメモリ安全言語への移行を求める声は前からあるが、FFmpegクラスのプロジェクトでそれをいつ実現できるのか。見通しは立っていない。サプライチェーンの脆さが、単一ライブラリのバグでここまで広い範囲に影響するという事実を、PixelSmashはまた見せつけた。

EKSのアップグレードがついに「片道切符」ではなくなった

Amazon EKSでKubernetesバージョンのロールバックが可能になった。アップグレード後7日以内なら、コントロールプレーンを前のマイナーバージョンに戻せる。etcdのデータもワークロードもPersistent Volumeもそのまま保持される。

（etcd: Kubernetesのクラスター状態を保存する分散KVS。通常、ここが巻き戻されるとクラスター全体の状態が失われる）追加費用なしで、EKSが利用可能な全リージョンですでに使える。

これがなぜ大きいか。Kubernetesのアップグレードはこれまで「片道切符」だった。1.34から1.35に上げて、非推奨APIを踏んでPodが起動しなくなっても、元のバージョンに戻す公式な手段はなかった。再構築か、手動でのワークロード巻き戻ししかない。だから多くのチームがアップグレードを先送りした。年3回のマイナーバージョンリリースに追われつつ、数百クラスターを抱える規制環境のチームは特にそうだ。問題が起きた時の復旧に自信がない。結果、セキュリティパッチが欠落した古いバージョンに留まり、延長サポートの締め切りに追い込まれる。この悪循環を断ち切るのがロールバック機能だ。

回避策としてblue/greenクラスターを組むチームもいた。だがインフラコストが倍になる。手動スナップショットを取るやり方もある。工数を食う上、確実に復元できる保証はない。どちらも高くついた。

仕組みを少し掘る。ロールバックは1マイナーバージョンずつ戻る。EKSの段階的アップグレードと同じ挙動だ。実行前にクラスタインサイトがロールバック可否をチェックする。ノードのバージョン不一致やアドオンの依存関係を事前に検出する。--forceでこれをスキップ可能だが、お勧めしないだろう。

注意点がある。ノードのロールバックはEKS Auto Modeのクラスターに限られる。Auto Mode以外を使っているチームは、コントロールプレーンだけ戻ってもノードが旧バージョンのままという乖離を自前で解決する必要がある。ここは実務上の論点だ。うちのチームもAuto Modeへの移行を検討中だが、この制約は移行の後押しになるかもしれない。また7日という制限もある。1週間経ってから不具合に気づいた場合はロールバックできない。キャンセルAPIも用意されており、ノードのロールバックが長引く際に途中で止めて別の手段に切り替えられる。これは地味に嬉しい。EKS Auto Modeのワーカーノードはコントロールプレーンより先に自動でロールバックされるが、規模が大きいと時間がかかる。途中で方針を変えられるのは実務的な安心感がある。

GKEはバージョン1.33で既にコントロールプレーンのロールバックを導入している。Azure AKSはノードプールのロールバックのみの部分対応だ。EKSの今回の対応は、マネージドKubernetesの機能パリティという意味でも注目に値する。オープンソース側ではKEP-4330でエミュレートバージョンによるロールバック実現に向けた動きがあるが、まだ実装には至っていない。

7日の窓があるとはいえ、アップグレード後の検証サイクルをどう回すかが引き続き重要だ。ロールバックは安全網であって、検証の代替にはならない。ただ、これまで「最後の手段」が存在しなかったことで過剰に慎重になっていた面はある。その慎重さが少し解ければ、EKSクラスターのバージョン陳腐化のペースも変わるのではないか。

AIルートコーズ分析の勝敗を分けるのはモデルよりコンテキスト

オブザーバビリティベンダーのCorootが面白い実験結果を出している。エンジニアのNikolay Sivkoが、AIによるルートコーズ分析（RCA）を「推論」と「データ供給」の2つに分けて評価したのだ。結論から言うと、モデルの推論力はもうボトルネックじゃない。何をどういう形でモデルに渡すか、そちらの設計が勝負どころになっている。

実験のシナリオはこうだ。Chaos MeshのNetworkChaosでカタログサービスとPostgres間に遅延を注入し、フロントエンドに502エラーを発生させる。ネットワークRTTで膨らんだクエリ時間というミスリードも仕込んである。約9,800トークンのプロンプトを11モデルに投げ、原因と因果連鎖と即時修正を問うた。Claude Opus 4.8、GPT-5.5、Gemini 3.1 Proが合格。オープンウェイトではGemma 4 31Bだけが原因を特定できた一方、Qwen3.6 35BとQwen3 Coder Nextは見逃した。

重要なのは、このテストが決定論的パイプラインで行われたことだ。事前にシグナルを相関させ、1つのフォーカスされたコンテキストをモデルに渡す。エージェント型のようにモデル自らテレメトリを取得する設計ではない。DynatraceのDavis AIも同じ方向で、トポロジーベースの因果分析を先に行い、LLMには開かれたエージェントループを回させない。

エージェント型にも利点はある。未知のインシデントでは、固定パイプラインが想定していないシグナルをモデル自身が引きに行ける。ただし運用が壊れやすい。ZenMLやIncident.ioの報告によれば、マルチエージェントの調査は本番でのデバッグが極めて困難で、失敗時にスタックトレースすら残らない。Redditの議論でも、完全エージェント型を捨てて決定論的ワークフローに狭いLLMステップを挟む設計に移行する声が多い。再現性と評価のしやすさを取る選択だ。

Sivkoは「推論部分は基本的に解決済み」と断言し、本当の仕事は「モデルを呼ぶ前に正しくコンパクトなコンテキストを準備すること」だと言い切っている。AnthropicやLangChain、Mezmoも同趣旨で、最小限の高シグナルなコンテキストをキュレーションする規律こそがLLM運用の中核になるとしている。

インシデント対応にLLMを組み込むチームにとって、このシフトは実務に直結する。より大きなモデルに替える前に、まずパイプラインを見直せ。テレメトリの相関ロジック、ノイズの除去、何をコンテキストに含めるか。そちらに注力した方がコストも結果も良くなる可能性が高い。1回の呼び出しが数セントで済むのも、相関作業をモデル呼び出し前に終えているからだ。私の感覚でも、この判断軸は合っている。Kubernetes上のマイクロサービスでインシデントが起きたとき、まず欲しいのは構造化された依存関係と異常の相関であって、生ログをモデルに投げて推理させることではない。

まとめ

複数の話題に共通するのは、状態や知性を個々のコンポーネントから引き剥がし、制御層に返す動きだ。MCPはセッション管理を捨ててステートレスなHTTPに回帰し、既存のインフラ知見を活用できるようにした。AIのルートコーズ分析でも、モデルの推論力に頼るエージェント型から、パイプラインでコンテキストを整える決定論的アプローチへと重心が移っている。コンポーネント自体に過剰な責務を負わせるのをやめ、周辺の制御層に仕事を任せる設計が実務上の正解になりつつある。

AIの価値の移動も同じ文脈で読める。Nadellaがモデルをコモディティと呼び、データとオーケストレーションに価値を置くのも、モデル自体の知性に依存するのをやめ、制御層で差別化する構えだ。EKSのロールバック機能も、アップグレードという不可逆な状態変化に安全網を設けることで、運用の制御を手放さないための手段だ。状態や知性を「持つ」ことのリスクを避け、「制御する」層を厚くする方向性は、バックエンドの設計思想として筋が良い。

ただし、制御が及ばない基盤の脆さも浮き彫りになった。FFmpegの16年潜伏した脆弱性は、メモリ安全性の欠如という構造的問題がサプライチェーン全体に影響を及ぼす例だ。プロトコルやパイプラインの設計を正しても、その下の層に制御不能なリスクが潜んでいれば意味がない。状態や知性を適切な層に配置する設計と並行して、依存する基盤の安全性をどう確保するかが引き続き課題として残る。

参照記事

記録日: 2026-07-27