>
>
公開日
2026年7月28日、AIエージェントと外部ツールをつなぐ標準規格「MCP（Model Context Protocol）」の新仕様「2026-07-28」が公開されました。最大の変更は、通信方式が「ステートフル」から「ステートレス」へ移行したことです。開発者向けの技術トピックに見えますが、社内でAIエージェントの利用が広がるいま、MCPサーバーの運用形態やセキュリティ設計が変わる本件は情シスにとっても無関係ではありません。
この記事では、ステートレス化で何が変わり、情シスがどの観点で情報を取り入れ、どう対応判断すればよいのかを実務目線で整理します。
3つのポイントでわかるMCP 2026-07-28の変更点
今回の更新は「セッションの廃止」が核心で、MCPサーバーを一般的なWebサービスと同じように運用・拡張できるようになったのが最大のポイントです。 MCP登場以来もっとも大きな改定と位置づけられています。
ステートレス化：接続ごとに状態を保持する仕組み（initialize と Mcp-Session-Id）を廃止。どのサーバーがリクエストを受けても処理できるようになった
拡張フレームワークの正式化：UI描画の「MCP Apps」と長時間処理の「Tasks」がコア仕様から切り離され、正式な拡張機能へ昇格
認証の強化：OAuth 2.0 / OpenID Connect（OIDC）準拠が進み、Entra IDやOktaといった企業のID基盤と接続しやすくなった
いずれもすぐに既存環境が壊れるわけではなく、非推奨となる機能には最低12カ月の移行猶予が設けられています。まずは「自社にMCPサーバーがあるか」「それを誰が運用しているか」を把握することが情シスの出発点になります。
そもそもMCPとは何か：情シスが押さえる基礎
MCPは、AIエージェントやAIアプリを社内外のツール・データに接続するためのオープンな共通規格です。 Anthropicが2024年11月に公開し、現在はLinux Foundation傘下のAgentic AI Foundationで開発が続けられています。
AIサービスごとに個別の接続方式を作るのではなく、MCPに対応しておけばさまざまなAIから同じツールを呼び出せる——これがMCPの狙いです。月間SDKダウンロードは4億回を超え（年内で約4倍）、Claudeのコネクターディレクトリには950件を超えるMCPサーバーが登録されているとされ、AIエージェントとツールをつなぐ事実上の業界標準になっています。
情シスの視点では、MCPは「AIエージェントが社内のSaaSやデータへアクセスするための入口」に相当します。どのAIがどのMCPサーバー経由でどのシステムに触れているのかを把握できていなければ、シャドーAI・シャドーITの温床になりかねません。MCPそのものの企業導入・統制の全体像は、MCP 企業導入の完全ガイド｜セキュリティ統制とAI Agentガバナンスで体系的に解説しています。あわせて、代表的なAIアシスタントの基礎はClaudeとは？も参考にしてください。
最大の変更点「ステートレス化」の中身
ステートレス化とは、接続のたびに状態を維持する「セッション」の仕組みを廃止し、1つ1つのリクエストが単独で完結するように変えたことを指します。 従来はまず initialize / initialized のやりとりでハンドシェイクを行い、その後は Mcp-Session-Id というヘッダーで同じ接続状態を維持していました。
新仕様ではこの初期化とセッションIDが不要になり、各リクエストがプロトコルのバージョンやクライアント情報、利用可能な機能を個別に伝えるようになりました。サーバーが提供する機能を事前に確認したい場合は、新設された server/discover を任意で使えます。
わかりやすく言えば、旧MCPは「担当者制の窓口」でした。最初に名乗って担当者が決まり、以降はその人としか話が通じない。担当者が不在なら処理が止まります。新MCPは「番号札のいらない窓口」で、どの窓口に行っても同じ処理ができ、必要な情報は毎回リクエスト自身が持参する形です。
なお、ステートレス化によって買い物かごの中身のような「アプリが持つ状態」が保存できなくなるわけではありません。状態を維持する必要がある場合は、サーバーが状態を示す識別子（ハンドル）を発行し、AIエージェントが次のツール呼び出しで明示的に渡します。これまで通信の内部に隠れていた状態が、ツールの引数として「見える場所」に移った、という理解が正確です。
ステートレス化で情シスに何が起きるか
運用面のメリットは、MCPサーバーを一般的なHTTPサービスと同じ感覚でスケールさせられるようになったことです。 これは自社でMCPサーバーを運用する情シスにとって直接的な恩恵です。
従来はセッションを維持するため、同じユーザーの通信を同じサーバーへ送り続ける「スティッキーセッション」や、複数サーバー間で状態を共有するデータベースが必要でした。サーバーの増減や障害時の切り替えが難しく、大規模運用の妨げになっていました。
ステートレス化により、リクエストはどのサーバーが受けても処理できます。一般的なロードバランサーで空いているサーバーへ振り分けられ、Kubernetes・サーバーレス・エッジといった環境へ展開しやすくなりました。実際にGitHubは新仕様に先駆けて対応し、セッション情報を保存していたRedisへの読み書きを削除したことで、サーバー構成が簡素になったと説明しています。
情シスがこの点を情報として取り入れるべき観点は次の3つです。第一に、社内MCPサーバーの可用性とスケール設計を見直す好機であること。第二に、状態がツール引数として明示化されることでどの処理でどのデータが使われているか監査しやすくなること。第三に、運用がシンプルになる分、外部公開の敷居も下がるため、意図しない公開を防ぐ棚卸しが一層重要になることです。
セキュリティはどう変わるか
ステートレス化はセキュリティ面でもプラスに働くとされ、あわせてOAuth 2.0 / OIDC準拠の認証強化が行われました。 ただし恩恵を受けるには、クライアント・サーバー双方が新仕様に正しく対応している必要があります。
TechTargetの取材では、あるFortune 100企業のDevOpsエンジニアが、セッションIDの維持は「サーバーにとって大きな負担」であり、攻撃者がセッションを乗っ取ってバックエンドへ侵入する経路にもなり得たと指摘しています。新仕様ではメタ情報のみをやり取りするため、この攻撃面が縮小すると評価されています。
認証面では、主に以下が強化されました。
発行者（issuer）検証の必須化：ある認証サーバー向けに発行されたトークンが、別の認証サーバーで誤って使われる「mix-up攻撃」を防ぎやすくする
Resource Indicators（RFC 8707）対応：トークンの対象サーバーを明示し、トークンの流用を防止する
Dynamic Client Registrationの非推奨化：クライアント情報を文書として公開する「Client ID Metadata Documents（CIMD）」への移行が進む
これらにより、MCPサーバーがEntra IDやOktaなど企業のID基盤と余計な回避策なしで接続しやすくなりました。情シスの実務としては、AIエージェントのアクセスを既存のIdPやSSOの統制下に置けるかを確認するのが要点です。認証・ID管理の考え方はClaudeエンタープライズの認証・認可管理、シークレット管理は1Password for Claude 活用ガイドが参考になります。
一方で、Omdiaのアナリストは、MCPが現状は人間のユーザー認証を前提としており、将来的にはエージェント固有のアイデンティティをサポートし、エージェントに必要最小限の権限のみを付与する仕組みが課題として残ると指摘しています。「AIエージェントに人間のIDを流用させ続けない」という論点は、情シスが中長期で押さえておくべきテーマです。
そのほかの主要な変更点
セッション廃止に伴い、ユーザー確認・通信効率・機能拡張のそれぞれで新しい仕組みが導入されました。 実装の詳細はエンジニア領域ですが、情シスは「何が新しくなったか」を俯瞰しておくと、社内からの問い合わせや導入判断に対応しやすくなります。
MRTR（Multi Round-Trip Requests）：処理の途中で追加確認が必要なとき、サーバーは「input_required」と質問を返し、クライアントは回答を付けてリクエストを再送します。データ削除前の確認などを、接続を維持せずに処理できます
HTTPヘッダーとキャッシュの刷新：呼び出す機能を示す
Mcp-Method、ツール名を示すMcp-Nameの付与が必須になり、ゲートウェイやWAFがJSON本文を解析せずヘッダーだけで振り分け・制御できます。ツール一覧には有効期間ttlMsとキャッシュ範囲cacheScopeが加わり、通信量を削減できます拡張フレームワークの正式化：新機能をコア仕様から切り離して追加できる仕組みが整いました。チャット内にフォームや表を表示する「MCP Apps」と、長時間処理を扱う「Tasks」が正式な拡張へ昇格しています
3機能の非推奨化：Roots・Sampling・Logging と、旧来のHTTP+SSEを組み合わせた通信方式が非推奨になりました。ただし削除まで最低12カ月の猶予が保証されます
WAFやゲートウェイでの制御が効きやすくなった点は、ネットワーク統制を担う情シスにとって実務的な追い風です。
情シスが取るべき対応：影響範囲別チェックリスト
やるべきことは「自社にMCPサーバーがあるか」「その運用主体は誰か」で大きく変わります。 大多数のケースではAIツール側のアップデートで自然に移行が進みますが、カスタムサーバーを持つ場合は計画的な対応が必要です。主要SDK（TypeScript / Python / Go / C#）は後方互換を維持しているため、あわてて全面移行する必要はありません。
パターン1：AIツールの「利用者」として使っている場合（多数派） Claude Code・Cursor・各種AIアシスタントを通じてMCPサーバーに接続しているだけなら、ツール側のアップデートで対応される見込みです。情シスの実務は、社内で使われるツールのバージョンを最新に保つ運用ルールを整えることです。古いバージョンのまま放置すると、新仕様のサーバーと通信できなくなる可能性があります。
パターン2：MCPサーバーを「自作・運用」している場合 社内ツールやSaaS連携のためにMCPサーバーを構築している場合は、移行作業が発生します。具体的には、initialize ハンドシェイクや Mcp-Session-Id を使ったルーティングへの依存、Roots・Sampling・Logging の利用有無をコード内で確認し、影響範囲を特定します。OAuth関連のエンドポイント実装とステートレス対応が主な作業になります。
パターン3：外部ベンダーのMCPサーバーを「導入」している場合 利用中のSaaSやコネクターがMCPサーバーを提供している場合は、提供元の対応方針とスケジュールを確認します。新仕様対応のクライアントと旧仕様のサーバー（またはその逆）の組み合わせでは互換性の問題が出る可能性があるため、バージョンの整合を管理台帳で追える状態にしておくと安全です。
いずれのパターンでも、まず「今日やること」は棚卸しです。以下は、自社がどのパターンに当てはまる場合でも共通して確認したいチェックリストです。上から順に埋めていくことで、影響範囲の特定と初動を漏れなく進められます。
社内で稼働しているMCPサーバー・AIエージェント連携をすべて洗い出したか
それぞれの運用主体（自社で自作／外部ベンダー提供／利用者がツール経由で接続のみ）を特定したか
各連携の接続先システムと認証方式（IdP / SSO連携の有無、トークンの管理方法）を一覧化したか
自作サーバーがある場合、
initializeハンドシェイクやMcp-Session-Idを使ったルーティングに依存していないか確認したか非推奨となった Roots・Sampling・Logging を利用していないか、コード内を検索して確認したか
社内で使うAIツール（Claude Code・Cursor 等）のバージョンを最新に保つ運用ルールがあるか
外部ベンダー提供のMCPサーバーについて、提供元の新仕様対応スケジュールを確認したか
上記を管理台帳（一覧）として記録し、定期的に棚卸しできる状態にしたか
これらを一覧化しておけば、12カ月の猶予期間のなかで計画的に移行判断を進められます。AIエージェント全般の統制・比較は主要AIエージェント比較、コーディングエージェントのガバナンスはClaude Code エンタープライズ・ガバナンスガイドが判断材料になります。GPT系エージェントを併用している場合はGPT-5.6 エンタープライズ導入ガイドもあわせてご確認ください。
情シスがこの変化をどう活かすか
ステートレス化は「AIエージェントの利用が本番運用フェーズに入った」というシグナルであり、情シスは可視化と統制の仕組みを先回りで整える好機ととらえるべきです。 運用が容易になるほどMCPサーバーは社内に増え、把握しきれない接続が生まれやすくなるためです。
活用の観点は3段階で整理できます。
可視化
どのAI・どのエージェントが、どのMCPサーバー経由で、どのSaaSやデータへアクセスしているかを棚卸しする。
統制
認証をIdP / SSOの下に集約し、エージェントに与える権限を最小化する。
ライフサイクル管理
使われなくなったMCP連携やアカウントを定期的に棚卸し・削除する。
この一連の流れは、AIエージェントが自律的に動いた際のリスクを最小化するうえでも重要で、想定外の挙動が事故につながった事例からの学びはOpenAIエージェント暴走インシデントの教訓にまとめています。
SaaS・アカウント・デバイスの利用実態を横断的に可視化する土台があれば、AIエージェントによる新たな接続経路も同じ枠組みで管理できます。マネーフォワード Adminaは、社内のSaaS利用状況やアカウントを一元的に把握し、棚卸しと統制を継続する情シスの実務を支援します。MCP自体もAdminaのデバイス・ID・サービス・アカウント管理へ接続できるため、AI連携の可視化にも活用できます。
よくある質問（FAQ）
Q. 情シスとして、いますぐ何か対応が必要ですか？
A. 多くの場合、緊急の対応は不要です。主要SDK（TypeScript / Python / Go / C#）は後方互換を維持しており、非推奨機能にも最低12カ月の猶予があります。ただし「社内にMCPサーバーやAIエージェント連携がどれだけあるか」の棚卸しだけは早めに着手することをおすすめします。
Q. 社内でClaudeやCursorなどのAIツールを使っているだけなら影響はありますか？
A. ツール側のアップデートで自然に移行される見込みで、利用者側の作業は基本的に発生しません。情シスの実務としては、社内で使うツールのバージョンを最新に保つ運用ルールを整えておくと安全です。古いバージョンのまま放置すると、新仕様のサーバーと通信できなくなる可能性があります。
Q. ステートレス化でセキュリティは強くなりますか、弱くなりますか？
A. 総じて強化される方向とされています。セッションIDの維持がなくなることで乗っ取りの攻撃面が縮小し、あわせてOAuth 2.0 / OIDC準拠の認証強化（issuer検証の必須化など）が行われました。ただし恩恵を受けるにはクライアント・サーバー双方が新仕様に正しく対応している必要があります。認証・認可の統制はClaudeエンタープライズの認証・認可管理もご確認ください。
Q. 非推奨になった機能を使っている場合、いつまでに移行すればよいですか？
A. 非推奨となったのはRoots・Sampling・Logging および旧来のHTTP+SSE通信方式で、削除まで最低12カ月の移行猶予が保証されています。すぐに停止するわけではありませんが、猶予期間の終盤に問題が顕在化しないよう、影響範囲の確認だけは前倒しで進めておくのが安全です。
Q. MCP AppsやTasksとは何で、情シスは何を気にすべきですか？
A. MCP Appsはチャット内にフォームや表などの操作可能なUIを表示する拡張、Tasksは長時間処理を非同期で扱う拡張です。いずれもツール呼び出しと同じ監査経路を通るため統制はしやすい設計ですが、UI経由でどのデータが扱われるかを把握しておくことが重要です。AIエージェント全般の統制観点は主要AIエージェント比較を参考にしてください。
まとめ
MCP 2026-07-28で導入されたステートレス化は、セッション管理という根幹を作り変える大きな改定です。背景には、MCPがローカルツールとの連携からクラウド規模の本番インフラへと使われ方を広げたという現実があります。ステートレス化・拡張フレームワーク・認証強化により、MCPは「ツール呼び出しの薄い橋渡し」から「AIエージェントのためのプラットフォーム基盤」へと進化しつつあります。
情シスにとっての実務ポイントは3つです。第一に、SDK利用者は後方互換により当面あわてる必要はないこと。第二に、非推奨機能には最低12カ月の猶予があるため、影響範囲の確認を落ち着いて進められること。第三に、運用が容易になる分、MCP連携の可視化・認証集約・ライフサイクル管理をいまのうちに整えておくことが、シャドーAIの抑制とセキュリティ確保に直結することです。
まずは自社にMCPサーバーやAIエージェント連携がどれだけあるかを棚卸しし、統制の枠組みに乗せるところから始めてみてください。MCPの企業導入と統制の全体像はMCP 企業導入の完全ガイドを、AI活用を安全に進める実務の基点はマネーフォワード Adminaをご覧ください。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
