境界線を引き直す：認可・データ同期・モデル依存の責務再定義

MCPの企業向け認可拡張「EMA」がstableに。SSOで一括管理する何が変わるか

MCPの「Enterprise-Managed Authorization」拡張がstableになった。

（MCP: Model Context Protocol。AIモデルが外部ツールやデータソースに安全にアクセスするための共通規格）AnthropicはClaude、Claude Code、Claude Coworkで、MicrosoftはVisual Studio Codeでサポートを開始している。IdPとしてはOktaが最初に対応した。

なぜこれが大事か。これまでのMCPの認可モデルは個人ユース向けに作られていたからだ。MCPサーバーに接続するたび、従業員がOAuthの同意画面をクリックする必要があった。数十のツールを繋ごうとすれば、その分だけ手間がかかる。企業のセキュリティチームから見ると問題はもっと深刻だ。一貫したポリシーの適用も、統一された監査ログの取得もできない。従業員が個人アカウントで仕事用のツールに繋ぐリスクも抱えていた。

EMAはIdPを中央の管理プレーンにする。IETFドラフトの「ID-JAG（Identity Assertion JWT Authorization Grant）」というOAuth拡張を使うのがポイントだ。

（ID-JAGは、信頼されたIdPが発行するJWTを用いて、ユーザーの介在なしにアクセストークンを取得するフローを定義する仕様）SSOのフローの中で、IdPがユーザーとアプリケーションの両方を保証する署名付きアサーションを発行する。同意画面なしで、MCPサーバーの認可サーバーからスコープ付きアクセストークンを取得できる仕組み。OktaはこれをCross App Accessという名前で提供している。

開発者のワークフローはどう変わるか。IT管理者が組織やチームに対してMCPサーバーへのアクセスを一度設定すれば、従業員はSSOでログインするだけでアクセスを継承できる。退職時のアカウント無効化で、MCPへのアクセスも同時に切断される。スプレッド化していた個別の承認作業が消える。AsanaやAtlassian、Canva、Figma、Linear、Supabaseなどがすでにサーバー側で対応しており、Slackも追加予定だ。

ただし、ここで押さえておくべき論点がある。EMAが制御するのは「誰がどのサーバーに接続できるか」までだ。特定のリソースに対して、特定のアクションを許可するかどうかという「きめ細かい認可」は別のポリシーエンジンやゲートウェイが担当する。IdPは接続の入口を管理するが、エージェントが実行する操作の危険度を判断する役割は持たない。

実務で導入するなら、この「接続の制御」と「操作の認可」の境界線をどこに引くかが最初の設計論点になるはずだ。IdPの設定だけで安心してしまうと、広すぎる権限をエージェントに渡すことになりかねない。認証と認可の責務を分けて整理しておけるか。そこがEMAを実際に回す上での鍵だろう。

Netflixがカメラファイル処理をFilmLight APIに委ねた理由とステートレススケールの実態

Netflixがグローバルな映画・テレビ制作ワークフロー向けのカメラファイル処理システムを公開した。1日あたりテラバイト単位のカメラデータを処理する。取り込み、バリデーション、メタデータ抽出、標準フォーマットへの変換までを担う。カメラフォーマットの不統一、断片化されたツール、分散チーム間の手動ハンドリング。これらが課題だった。

ここで面白いのが、Netflixが画像処理エンジンを自前で一から作っていない点だ。デベイヤリングや色変換といったイメージサイエンス領域はFilmLight API（FLAPI）に任せている。NetflixのエンジニアEric Reineckeは課題を「イメージサイエンス、大規模コンピューティング、映画制作者のワークフローの交差点」と表現している。FilmLightが専門タスクを処理し、Netflixはオーケストレーション、スケーラビリティ、ワークフローの整合性に集中する。自前主義に陥りがちな巨大企業が、専門領域は既存のAPIに頼る判断をした。この棲み分けは理にかなっている。

ワークフローの観点で注目したいのは、コンテナベースのステートレス実行モデルで水平スケールさせていることだ。メディア処理の負荷は変動が激しい。デイリー生成やVFXターンオーバーのようなピーク時には、大量のカメラファイルを厳しい時間枠で処理しなければならない。ステートレスにすることで、需要に応じたスケールアウトと、不要になったリソースの迅速な解放が可能になる。普段Kubernetesでマイクロサービスを動かしている立場からすると、ステートレス設計の利点はよく分かる。ただ、メディア処理のような重いワークロードをステートレスで水平スケールさせる場合、コンピュートリソースの確保とオーケストレーションのオーバーヘッドがどこまで許容されるのか。気になるところだ。

もう一つ、メタデータの正規化も重要な論点だ。取り込み段階でメタデータを統一スキーマに正規化し、編集、VFX、制作追跡システムで一貫した解釈を保証する。下流の不整合を減らすアプローチとして、データパイプラインの基本でありながら、現場では往々にして後回しになりがちな部分だ。Netflixはこれを自動化と反復可能なタスクの削減で解決している。

FilmLight APIを中核に据え、ステートレスなコンテナ環境でスケールさせる。Netflixの選択は、得意な領域に注力し、それ以外は既存の強力なツールに委ねるという実務的なアプローチだ。メディア処理のスパイクにどう対応するか。その答えの一つとして参考になる。

データを動かさない設計が次の主戦場

Postgresは30年の歴史の中で、トランザクショナルデータベースとしての信頼性を築いてきた。顧客データ、金融取引、アプリケーションの状態。そうした基幹データを預かる場所として、多くの組織がPostgresを信頼してきた。

だが直近のPostgresエコシステムで起きている重要な変化は、保存の話ではない。データを動かす必要性を減らすことだ。

現代のソフトウェアアーキテクチャでは、データは一つの場所に留まらない。運用系で生まれたデータは、データウェアハウス、検索プラットフォーム、機械学習環境、AIアプリケーションへ次々に流れていく。新しいシステムがそれぞれ正当なビジネス課題を解決する一方で、データの行き先とコピーが増え続ける。

このアプローチのコストはインフラ費用だけではない。コピーが増えるたびにレイテンシが生まれ、不整合のリスクが高まり、同期を保つ運用負荷が積み上がる。記事の指摘通り、多くの組織がデータを保存するのと同じくらいの労力を、データを移動させることに費やしている。

AIがこの古い問題に改めて光を当てている。AIが問題を作ったわけではない。長年静かに膨らんでいた制約を露呈させた。多くのAIアプリケーションは、現在の運用コンテキストへのアクセスに依存している。データがないのではなく、データが複数のシステムに散らばり、それぞれがコピーを持ち、独自のレイテンシと同期プロセスを持っている。AIが突きつける問いは単純だ。同じデータのコピーは、実際いくつ必要なのか。

Postgresの周辺では、論理レプリケーション、変更データキャプチャ（CDC）、外部データラッパーといった技術が、この課題に取り組んでいる。Postgresを単なるデータの発生源としてではなく、より大きなデータエコシステムと直接つながる存在にする試みだ。

データベースの評価軸が、保存とパフォーマンスから相互運用性へと移っている。この転換は、マイクロサービスでデータを分散させる設計において直結する問題だ。各サービスが持つデータをどう同期し、どう鮮度を保つか。パイプラインを増やすたびに運用の複雑さが増す。データを「速く移動させる」のではなく、「移動そのものを減らす」方向でアーキテクチャを見直す時期に来ているのかもしれない。

ホステッドモデルが1午後で消えたとき、オープンウェイトはセカンドソースになった

2026年6月12日午後5時21分（東部時間）、米政府がAnthropicに輸出管理規制に基づく命令を突きつけた。対象はローンチからわずか9日目のClaude Fable 5とMythos 5。政府側はFable 5のジェイルブレイク手法を発見したと判断し、外国人すべてのアクセス停止を求めた。Anthropicは外国人と国内ユーザーをきれいに分離できず、全世界の全顧客向けに両モデルを無効化した。Fable 5でエージェント自動化を組んでいたチームは、その日の午後でエンジンを失った。

ここで面白いのは、同じ週にオープンウェイトの代替が3つも出揃ったことだ。CohereのNorth Mini Codeは6月9日、Fable 5と同日にローンチ済みだった。30Bパラメータのうちトークンあたり3Bのみを活性化するMoE構成で、単一H100で動く。

（MoE: Mixture of Experts。全パラメータではなく、入力に応じて一部の専門ネットワークのみを活性化させることで、推論コストを抑えつつ高性能を維持する手法）Apache 2.0ライセンスなので法務レビューなしで自前ホストできる。MoonshotのKimi K2.7-Codeは6月12日、禁止令と同日リリース。1Tパラメータ・32B活性化のコーディング特化モデルで、ウェイトもダウンロード可能だ。ZhipuのGLM 5.2は6月13日、命令到達時刻と同じ午後5時21分に合わせて投入した。どれもフロントティアより安く、既存のエージェントハーネスと統合できる。

ハードウェア調達で「セカンドソース」の概念は当たり前だ。単一サプライヤーが途絶えたとき、代替品リストがあるチームだけが止まらずに済む。今回のFable 5停止は、AIモデルでも同じリスクが現実になった事例だ。APIでホステッドモデルを呼ぶ構成は導入が楽だが、供給者が政府命令1通で消えるなら、その依存はいつでも同じ目に遭う。

オープンウェイトの利点は「自前でホストできる」点に尽きる。自社インフラに載せたモデルは、外部の輸出規制で止まらない。North Mini CodeのようにH100 1台で動くモデルなら、オンプレ要件の厳しい金融や医療でも採用ハードルが下がる。ただしKimi K2.7-Codeのウェイトが595GBに達するように、実運用ではサーバークラスのマルチGPUメモリが必須になる。安いとはいえインフラコストはゼロではない。

論点は「フロントティアの性能を手放せるか」だ。North Mini CodeのArtificial Analysis Intelligence Indexは27.6で、フロントティア層には届かない。

（このインデックスは、コーディング能力、推論速度、コスト効率を総合的に数値化したベンチマーク指標）冗長性のためのセカンドソースとして割り切るなら許容できるトレードオフかもしれない。しかし本番トラフィックを日常的に支える主軸として見るなら、性能差は無視できない。

自分がマイクロサービスの外部API依存を管理する立場だとしたら、今回の件で真っ先に見直すのは「単一プロバイダーにロックインされているエージェントパイプライン」だ。ホステッドモデルを主軸にしつつ、オープンウェイトの小型モデルをフェイルオーバー用に自前ホストする。その二段構えが、今後の標準になるのではないか。

DoorDashが「意図」をログにした理由

DoorDashのVinay ChellaとAkshat Goelが、Write-Ahead Intent Log（WAIL）という取り組みを発表した。Change Data Capture（CDC）の限界にぶつかり、自前で作り直したという話だ。

（CDC: データベースの変更履歴をリアルタイムで検出し、他のシステムへ伝播させる手法）

DoorDashの注文フローは、1回のタップが複数のマイクロサービスをまたいで流れる。注文がデータベースに書き込まれ、レストランに通知が飛び、配達員がディスパッチされ、アプリが更新される。この連鎖のどこかが欠けると、客は「処理中」のスピナーを見つめ続けることになる。

この連鎖を繋ぐために、多くのチームがデュアルライトに頼る。データベースに書き込み、ストリーミングシステムにもイベントを送る。シンプルに聞こえるが、片方だけ成功することもある。そうなるとシステム間で真実が分岐する。Chellaはこれを「フィッティッドシートを折るようなもの」と表現していた。何度やってもきれいにいかず、結局押し込んでクローゼットにしまう感覚。笑える比喩だが、実務では笑えない。

CDCはこの問題への標準的なアプローチだ。データベースの変更をリアルタイムにキャプチャし、下流に流す。ただし銀の弾丸ではない。コネクタが壊れるし、シンクが落ちるし、データベースごとに方言が違う。DoorDashの規模では、ピーク時の注文ラッシュのなかでこれらが同時に起きる。検索結果によると、Debeziumが高負荷下で限界に達したと明言している。数百サービスを跨ぐプラットフォームで、従来のCDCが持たなかったのだろう。

WAILの核心は「状態ではなく意図を記録する」という考え方だ。注文の状態そのものではなく、「何をしようとしていたか」という意図を先にログに書き込む。プロキシ層を使ってデータレプリケーションを分離する構成になっている。WAL（Write-Ahead Log）の発想をアプリケーションレイヤーの意図に持ち込んだと言える。

ここで気になるのは、プロキシ層の導入が運用にどう影響するかだ。既存のCDCパイプラインをWAILに移行する場合、アプリケーション側の書き込みパスを変える必要があるのか、それともプロキシが透過的に吸収するのか。後者であれば移行コストは低いが、プロキシが単一障害点になる懸念は残る。このあたりの詳細は今回の資料からは読み取れなかった。

それでも「意図を先に書く」という方向性は筋が良いと感じる。分散システムで整合性を保つには、事後的に状態を同期するより、事前に意図を確定させる方が制御しやすい。デュアルライトで苦しんでいるチームにとって、WAILは一つの回答になりうる。ただし、DoorDashほどのスケールでなければDebeziumなどの既存CDCで事足りる場面も多いはずだ。自前でプロキシとログ基盤を保守するコストと、得られる信頼性のバランスを考える必要がある。

まとめ

5つの話題に共通するのは、システムの境界線を引き直す動きだ。EMAは接続の制御と操作の認可を分け、Netflixはイメージサイエンスを外部APIに委ねた。DoorDashは状態の事後同期から意図の事前確定に切り替え、Postgresエコシステムはデータの移動そのものを減らそうとしている。何を自分で持ち、何を外部に任せるか。その線が見直されている。

AIモデルの供給途絶リスクも同じ文脈で語れる。ホステッドモデルが1午後で消える事態を見れば、単一プロバイダーへの依存がどれほど脆いか分かる。オープンウェイトをセカンドソースとして自前ホストする構成は、性能のトレードオフを受け入れてでも制御を手元に残す選択だ。

ただし、境界線を引いた先の責務まで見切れていなければ、分離は新たなリスクを生む。EMAでIdPに接続を任せれば安心、と考えるのは危険だ。広すぎる権限をエージェントに渡すことになりかねない。DoorDashのWAILも、プロキシ層が単一障害点になる懸念は残る。境界線の外側で何が起きるか。そこまで設計して初めて、責務の分離は機能する。

参照記事

記録日: 2026-06-19