この記事の要点: Anthropicは2026年7月28日、AIエージェントと外部システムをつなぐ標準規格「MCP(Model Context Protocol)」の新仕様「2026-07-28」を公開しました。プロトコルの土台が「ステートフル(状態保持)」から「ステートレス(状態を持たない)」に切り替わり、あわせて認可(OAuth/OIDC)まわりのセキュリティが強化されています。
- 要点1: MCPの通信方式が根本的に変わり、社内で使っているMCPサーバーの一部は12か月の移行期間内に対応が必要になる可能性があります
- 要点2: セキュリティ強化はプラスですが、旧仕様のクライアント認証情報をそのまま使っていると資格情報の再利用リスクが残ります
- 要点3: 「Enterprise Managed Auth」により、社員が個別にAIエージェント連携を繋いでしまう”シャドー連携”を情報システム部門が一元管理しやすくなります
対象読者: Claude・ChatGPT・社内システムをMCP経由で連携している、またはこれから連携を検討している企業のAI導入担当者・情報システム責任者
読了後にできること: 自社が使っているMCPサーバー・コネクタが今回の変更の影響を受けるか、3つのチェックポイントで判断できるようになります
「うちの会社、MCPサーバーなんて使ってないから関係ない」——そう思う方も多いと思います。ですが、Claude DesktopやChatGPTの「コネクタ」機能を使って、Slackや社内Wiki、Google Driveの中身をAIに読ませている企業は、実はもうMCPを使っています。名前を意識していないだけです。
2026年7月28日、そのMCPの土台部分に、これまでで最大級と言われる仕様変更が入りました。プロトコルの通信方式そのものが変わり、あわせて認証・認可の仕組みも強化されています。開発者向けの技術ニュースとして流れると「サーバーの実装方式が変わった」くらいの扱いで終わってしまいがちですが、企業でAI活用を進めている立場から見ると、これは無視できない話です。
100社以上のAI研修・導入支援を行ってきた経験から言うと、こうした基盤レベルの仕様変更のタイミングこそ、社内でどのAIエージェント連携がどこまで会社の管理下にあるかを棚卸しする良い機会です。この記事では、何が変わったのかを非エンジニアにも分かる言葉で整理したうえで、企業のAI導入担当者が今週中に確認しておくべき3つのポイントをまとめます。
何が起きたのか — MCP「2026-07-28」仕様の全体像
MCP(Model Context Protocol)は、AnthropicがClaudeのために作り、その後OpenAIやGoogleを含む業界全体が採用した「AIエージェントと外部システムをつなぐ共通規格」です。社内の会計システム、Slack、GitHub、Google Driveなどを、各社バラバラの方法でなく共通の作法でAIエージェントに接続できるようにする、いわば”AI版のUSB規格”のような存在です。
2026年7月28日にリリースされた「2026-07-28」仕様は、このMCPの5回目の正式改訂にあたります。前回の大きな改訂が2025年11月だったことを踏まえると、8か月ぶりの大型アップデートです。Anthropicの公式ブログでは「プロトコル史上もっとも重要なリリースの一つ」と位置づけられています。
| 時期 | できごと |
|---|---|
| 2025年11月 | 前回の大型仕様改訂 |
| 2026年7月28日 | MCP「2026-07-28」仕様を正式公開。ステートレス化・認可強化・3拡張機能の追加 |
| 公開時点 | MCPの月間SDKダウンロード数が400万を突破(年初比4倍)、Claudeのコネクタディレクトリ掲載サーバー数は950以上 |
| 今後12か月 | 旧仕様の一部機能(Roots・Sampling・Logging・HTTP+SSEトランスポート・動的クライアント登録)の移行猶予期間 |
MCPがAIエージェント連携の”事実上の標準”になりつつあることは、この半年で企業のAI導入現場を見ていても実感します。社内システムとAIを繋ぐ話になると、必ずと言っていいほどMCPサーバーの選定・実装の話が出てくるようになりました。
AIエージェントの基本と社内システム連携の全体像を先に押さえておきたい方は、AIエージェント導入完全ガイドもあわせてご覧ください。
MCP登場からの経緯 — なぜ1年半で「業界標準」になったのか
今回の改訂の重みを理解するには、MCPがここまで来た経緯を押さえておくと分かりやすくなります。MCPは2024年11月25日、Anthropicが仕様(バージョン2024-11-05)を公開したのが始まりです。「AIアシスタントが情報のサイロに閉じ込められていて、新しいデータソースを繋ぐたびに個別の連携を作らなければならない」という課題意識から生まれました。
その後の広がり方は、技術標準としては異例のスピードでした。2025年3月にはOpenAIがAgents SDKでMCP対応を発表し、2025年後半にはGoogleもGeminiのエージェント基盤にMCPを採用しています。競合関係にあるはずのAnthropic・OpenAI・Googleが同じ規格を使うようになったことで、企業側は「特定ベンダーに縛られずにAIエージェント連携を作れる」という安心感を持てるようになりました。さらに、AnthropicとOpenAI、Blockがそれぞれのオープン標準プロジェクトを、新設された「Agentic AI Foundation」に寄贈し、ガバナンスも一社に依存しない体制に移行しています。
この「複数の巨大ベンダーが同じ規格に乗っている」という状況こそが、今回の2026-07-28仕様のような基盤変更が、一部の開発者だけの話では済まない理由です。Claude・ChatGPT・Geminiのどれを使っていても、裏側の連携方式が同じ規格でつながっている以上、影響範囲は特定ベンダーのユーザーだけにとどまりません。
「ステートレス化」とは何か — 非エンジニア向けに解説
今回の変更の中核は、プロトコルが「ステートフル(状態保持型)」から「ステートレス(状態を持たない型)」に切り替わったことです。専門用語が続くので、日常の例に置き換えて説明します。
これまでのMCPは、AIエージェントとMCPサーバーが最初に「ハンドシェイク(挨拶)」をして接続を確立し、そのやり取りの”文脈”をサーバー側が覚え続ける仕組みでした。窓口が1人しかいない相談窓口で、担当者があなたの話の続きを覚えていてくれるイメージです。ただしこの仕組みは、アクセスが増えたときに「同じ担当者でないと話が通じない」制約になり、サーバーを増やして負荷分散することが難しくなります。
新仕様では、リクエストの1つひとつが自己完結した情報(プロトコルバージョンやクライアント識別情報など)を持つようになり、初期接続時の「ハンドシェイク」と「セッションID」の概念自体がなくなりました。毎回の問い合わせに必要な情報がすべて添えられているので、どの担当者(サーバーインスタンス)が対応しても同じように処理できます。結果として、ラウンドロビン方式のロードバランサーの背後に複数のサーバーを並べて、負荷に応じて自動的に増減させる「サーバーレス」構成が組みやすくなりました。
企業側のメリットは主に2つです。1つは、社内でMCPサーバーを自前運用している場合、インフラの構築・保守コストが下がりやすくなること。もう1つは、外部ベンダーが提供するMCPサーバーの信頼性・スケーラビリティが底上げされ、大量アクセスが発生する繁忙期でも安定しやすくなることです。逆に言えば、これまで独自のセッション管理を前提に社内でMCPサーバーを実装していた企業は、その部分の作り直しが必要になります。
| 項目 | 旧仕様(〜2026-07-28以前) | 新仕様(2026-07-28〜) |
|---|---|---|
| 通信モデル | 双方向ステートフル(状態を保持) | 要求/応答のステートレス(状態を持たない) |
| 接続開始 | initialize/initializedハンドシェイクが必要 | ハンドシェイク廃止。各リクエストが自己完結 |
| セッション管理 | Mcp-Session-Idで同一サーバーに紐づけ | セッションID廃止。どのサーバーインスタンスでも処理可能 |
| スケール方式 | 特定サーバーへの固定接続が前提 | ロードバランサー配下でサーバーレス展開が可能 |
| キャッシュ | 明確な仕組みなし | ttlMs・cacheScopeでツールカタログのキャッシュが標準化 |
セキュリティ強化の3点 — 何がどう厳しくなったのか
ステートレス化と同時に、認可(誰にどこまでアクセスを許可するか)まわりのセキュリティも強化されました。企業のAI導入担当者としては、こちらの方が実務への影響が大きい変更です。
| 強化ポイント | 内容 | 企業への意味 |
|---|---|---|
| RFC 9207準拠 | 認可サーバーがレスポンスに発行元(issuer)情報を含め、クライアント側が事前に検証する | 「認可サーバーの成りすまし」による情報漏えいリスクを防止 |
| クライアント認証情報の発行者バインディング | 認証情報を発行した相手としか使えないよう紐づける | 盗まれた認証情報を別のサービスで使い回す攻撃を防止 |
| 動的クライアント登録(DCR)の廃止 | クライアントID メタデータ文書(CIMD)方式へ移行 | 不特定多数のクライアントが自動登録できてしまう抜け道をふさぐ |
これらはいずれも「AIエージェントに社内システムへのアクセス権を渡すときの、なりすまし・使い回しのリスクを減らす」方向の変更です。OAuth 2.0とOIDC(OpenID Connect)の標準への準拠が明記されたことで、Microsoft EntraやOktaといった企業向けID管理システムとの統合もしやすくなりました。すでにこうしたID管理基盤を使っている企業にとっては、AIエージェント連携を”野良のID・野良の権限”のまま放置せず、既存の社員ID管理の枠組みに乗せやすくなったという意味で歓迎できる変更です。
権限の設計そのものについては、AIエージェントの権限設計|最小権限3段階と停止手順の実務で具体的な設計手順をまとめています。
新設された3つの拡張機能 — Apps・Tasks・Enterprise Managed Auth
今回の仕様改訂では、これまで実験的な位置づけだった機能が正式な「拡張機能」として独立し、あわせて3つの機能が公式拡張として追加されました。
MCP Apps — 会話の中にUIをそのまま表示
これまでMCPサーバーはテキストの応答しか返せませんでしたが、MCP Appsを使うと、AIとの会話の中にサーバー側が用意した簡易UI(フォームやボタンなど)を直接埋め込めるようになります。たとえば経費精算のMCPサーバーであれば、チャット内に金額入力フォームがそのまま表示され、AIとの対話とシステム操作がシームレスにつながるイメージです。
Tasks — 時間のかかる処理を非同期で扱う
大量データの集計や外部システムへの一括反映など、数分〜数十分かかる処理を、AIエージェントが「投げっぱなし」にできる仕組みです。従来の実験的な仕組みから、ポーリング方式の`tasks/get`と更新用の`tasks/update`という正式な仕組みに整理されました。長時間ジョブを扱う業務システム連携では、この仕組みの有無が実装のしやすさを大きく左右します。
Enterprise Managed Auth(EMA) — 組織単位でのアクセス管理
企業の情報システム部門にとって、実務上もっとも重要なのがこのEMAです。IdP(IDプロバイダー)ベースで、組織全体のコネクタ認証を一元的にプロビジョニング(発行・管理)できるようになります。これまでは、社員が個人のAPIキーで勝手に外部のAIエージェントサービスとMCP連携を繋いでしまう、いわゆる”シャドー連携”が発生しやすい構造でした。EMAにより、情報システム部門が「誰が・どのMCPサーバーに・どこまでのアクセス権を持つか」を組織のID管理システム側から統制しやすくなります。
社内で使われているAIエージェント連携を可視化・統制する具体的な手順は、シャドーAIエージェントの棚卸し手順|発見・分類・廃止の実務で詳しく解説しています。
エンタープライズ各社の反応 — 「インフラの成熟化」という評価
今回の仕様改訂について、Microsoft・Google Cloud・AWSといった主要クラウドベンダーからは、揃って「エンタープライズグレードインフラの成熟化」という評価が出ています。ステートレス化によってセッション管理が不要になったことで、運用の複雑さが下がり、標準的なクラウドインフラの上にそのまま展開しやすくなった点が評価されている形です。
ここが重要なポイントですが、この評価は「開発者にとって作りやすくなった」という話にとどまりません。企業がMCPサーバーをベンダーに発注・調達する側の立場で見ると、標準的なクラウドインフラ上に構築しやすくなったということは、特定ベンダーへのロックインリスクが下がり、乗り換えや複数ベンダー併用のハードルも下がるということです。AIエージェント連携をこれから本格導入する企業にとっては、むしろ追い風の変化と捉えてよいでしょう。
廃止される機能と移行期間 — いつまでに何を確認すべきか
基盤が変わる以上、これまでの仕組みの一部は廃止(非推奨化)されます。ただし、いきなり使えなくなるわけではなく、最低12か月の移行期間が設定されています。
| 廃止される機能 | 影響を受けやすいケース |
|---|---|
| Roots | クライアント側でファイルシステムの参照範囲を指定する仕組みを使っている実装 |
| Sampling | MCPサーバー側からAIモデルの推論を呼び出す設計にしている実装 |
| Logging | MCP標準のログ仕組みに依存した監視・監査体制 |
| HTTP+SSEトランスポート | 旧方式の常時接続(Server-Sent Events)でMCPサーバーを構築している実装 |
| 動的クライアント登録(DCR) | クライアントの自動登録機能を使ってきた実装 |
「最低12か月」の猶予があるとはいえ、この期間は油断せず今のうちに確認しておくべきです。理由は単純で、社内で使っているMCPサーバーやコネクタが、自社で構築したものなのか、外部ベンダー提供のものなのかによって、対応の主体とスケジュールがまったく違うからです。外部ベンダー提供であれば「ベンダー側がいつまでに新仕様へ追従するか」を確認する話になりますし、自社構築であれば「開発チームのロードマップに移行作業を組み込む」話になります。
MCPサーバーの基本構成や実装パターンをおさらいしたい方は、MCP入門|AIと社内システム接続の実装7ステップを、Claude Codeと組み合わせたMCP連携の実装手順はClaude Code × MCP 連携完全ガイドを参照してください。
日本企業への影響 — 「知らなかった」で済まない理由
日本企業の多くは、MCPを「Claude DesktopやChatGPTのコネクタ機能」として意識せずに使っています。営業部門がSlack連携のAIアシスタントを、経理部門がGoogle Drive連携のAI検索を、それぞれ別々のタイミングで導入しているケースは珍しくありません。この状態で基盤仕様の変更が入ると、どの部門のどの連携が影響を受けるのか、情報システム部門が把握しきれていないという事態が起こり得ます。
特に日本企業の場合、以下の2点が実務上の壁になりやすいというのが、複数の企業のAI導入を支援してきた実感です。
- 部門ごとにバラバラに導入されたAI連携の全体像を、情報システム部門が持っていない——今回のような基盤変更のたびに、影響範囲の洗い出しから始めなければならない
- ベンダー提供のMCPサーバーへの追従状況を、契約時点で確認していない——「新仕様への対応はいつ頃予定していますか」を事前に確認する習慣がまだ根付いていない
これらは、今回のMCP仕様改訂に限った話ではなく、AIエージェント活用が広がるほど繰り返し発生する課題です。ガバナンス体制そのものを見直したい場合は、AIエージェント運用ガバナンス完全ガイド|中小企業向け35項目チェックリストが実務のたたき台になります。日本語対応のMCPサーバーを検討している場合は、日本特化MCPサーバー8選|法令・税務・労務・助成金もあわせてご確認ください。
AI導入担当者が今週やるべき3つの確認
基盤レベルの仕様変更は、日々の業務に追われているとつい後回しになりがちですが、影響範囲の確認自体は数時間で終わる作業です。今週中に、以下の3点だけでも確認しておくことをおすすめします。
確認1:社内で使っているMCP連携の棚卸し
Claude・ChatGPT・その他AIツールの「コネクタ」「MCPサーバー」設定を、部門ごとにリストアップします。IT部門が把握していない”部門主導導入”の連携がないか、この機会に洗い出してください。
確認2:各連携が自社構築かベンダー提供かの切り分け
自社構築であれば、開発チームに今回の仕様変更(特にHTTP+SSEトランスポート廃止と動的クライアント登録廃止)への対応要否を確認します。ベンダー提供であれば、契約先に新仕様への追従スケジュールを問い合わせます。
確認3:Enterprise Managed Authへの移行検討
すでにMicrosoft EntraやOktaなどのID管理基盤を導入している企業は、MCP連携をその配下に統合できないか検討する価値があります。個人のAPIキーに依存した”シャドー連携”を減らすことは、監査対応の観点でも有効です。
よくある質問
Q. 今すぐ何かを変更しないと、既存のAI連携が止まってしまいますか?
A. いいえ、即座に止まることはありません。廃止対象の機能には最低12か月の移行期間が設定されています。ただし、期間内に対応が完了しなければ、期限到達後にHTTP+SSEなど旧方式の接続が使えなくなる可能性があるため、早めの棚卸しをおすすめします。
Q. 自社でMCPサーバーを構築していなくても関係ありますか?
A. Claude DesktopやChatGPTの「コネクタ」機能を使ってSlackやGoogle Drive、社内Wikiなどを連携している場合、意識していなくてもMCPを利用しています。自社構築でなくとも、利用しているサービスが新仕様にどう対応するかは確認しておくべきです。
Q. Enterprise Managed Authは中小企業でも導入すべきですか?
A. すでにMicrosoft EntraやOktaなどのID管理基盤を導入している企業であれば検討価値があります。一方、そうした基盤がまだ整っていない企業は、EMA単体の導入を急ぐより先に、社内のAI連携の棚卸しとアクセス権の可視化から始めるほうが現実的です。
Q. OpenAIやGoogleのAIエージェントもこの新仕様の影響を受けますか?
A. はい。MCPはAnthropicが2024年11月に公開した規格ですが、OpenAIが2025年3月にAgents SDKで対応し、Googleも同年後半にGeminiのエージェント基盤で採用しています。特定ベンダーの利用者に限らず、MCP経由でAIエージェントを連携させている企業全般が対象になります。
Q. 情報システム部門が今回の変更をどう社内に説明すればよいですか?
A. 「AIエージェント連携の裏側の通信方式が変わり、セキュリティが強化された」という技術的な事実に加えて、「これを機に社内のAI連携を棚卸しし、野良のAPIキー運用を減らす」という実務上の狙いをセットで伝えると、現場の協力を得やすくなります。単なる技術ニュースの共有ではなく、社内のシャドー連携対策のきっかけとして位置づけるのが実務的です。
まとめ
MCP「2026-07-28」仕様の要点は、プロトコルの土台がステートフルからステートレスに変わったこと、そして認可まわりのセキュリティが強化されたことの2つです。開発者向けの技術的な変更に見えますが、Claude DesktopやChatGPTの「コネクタ」機能を通じてすでにMCPを使っている企業にとっては、無関係ではいられない変更です。
まずは自社のAI連携がどこにどれだけ存在するかの棚卸しから始めてください。基盤の仕様が変わるタイミングは、普段見過ごされがちなシャドー連携を洗い出す良い機会でもあります。
参考・出典
- MCP 2026-07-28 spec: stateless core, coming to Claude — Anthropic公式ブログ(参照日: 2026-07-30)
- The 2026-07-28 Specification — Model Context Protocol公式ブログ(参照日: 2026-07-30)
- Anthropic updates MCP with stateless core, stronger security and task support — News9live(参照日: 2026-07-30)
- A Year of MCP: From Internal Experiment to Industry Standard — Pento(参照日: 2026-07-30)
今日から始める3つのアクション
- 今日やること: 自社でClaude・ChatGPTの「コネクタ」機能を使っている部門がどこかを、社内Slackで一声かけて確認する
- 今週中: 洗い出した連携が自社構築かベンダー提供かを切り分け、ベンダー提供分は追従スケジュールを問い合わせる
- 今月中: Enterprise Managed Authへの統合可否をID管理基盤の担当部門と検討する
次回予告: 次回は、AIエージェント連携で発生しがちな「シャドー連携」を具体的にどう洗い出し、廃止・統制していくかの実務フローをさらに深掘りします。
著者: 佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』(SBクリエイティブ)。
SoftBank IT連載7回執筆(NewsPicks最大1,125ピックス)。
ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。
AIエージェント実装、設計から運用まで伴走します
PoCで終わらせない。マルチエージェント設計・MCP統合・運用体制まで、貴社の業務プロセスに合わせて構築します。
- マルチエージェント実装の実戦経験
- 初回30分無料・即日返信
お問い合わせフォームから24時間以内にUravation担当者がご返信します。





