「基幹システムの情報を、AI から直接引けるようにしたい」という相談は、この半年で明らかに増えました。同時に、判断がつかずに止まっている案件も増えています。理由はほぼ共通していて、仕様がまだ動いているように見えるからです。
作ったあとに規格が変わって作り直しになるのが怖い。かといって、様子見の期間が1年を超えると、その間の業務改善はまるごと諦めることになります。
2026年8月に公開された MCP の新しいロードマップは、この判断に直接使えます。これから変わる部分と、もう変える予定がない部分が分けて書かれているからです。
何が公開されたのか
Linux Foundation 傘下で MCP（Model Context Protocol）の仕様策定を行う Agentic AI Foundation（AAIF） が、今後の方向性を示すロードマップを公開しました。報道では5つの重点領域として整理されています。
| 領域 | 内容 |
|---|---|
| トランスポートの進化 | Streamable HTTP の次世代化。複数インスタンスでのステートレス動作、ロードバランサー配下での運用 |
| サーバーの発見 | Server Cards の標準化による MCP サーバーの自動発見 |
| エージェント間の連携 | 非同期のタスク処理（Tasks）の強化 |
| エンタープライズ対応 | 監査証跡、高度な認証・認可、ゲートウェイとプロキシの標準化 |
| ガバナンスの成熟 | オープンなワーキンググループによる仕様策定プロセスの確立 |
前提として、MCP は2025年12月に Linux Foundation へ移管されており、標準化のガバナンス自体は特定ベンダーの手を離れています。今回のロードマップは、その体制での最初の中期方針にあたります。
「これから変わる」のは接続の仕方、業務ロジックではない
発注判断の観点で読むと、5領域はきれいに2つに分かれます。
変わるのは、外側です。 トランスポート、サーバーの発見、ゲートウェイ、認証の受け渡し方。いずれも「どうつなぐか」の話です。
変わらないのは、内側です。 どの業務データを、どの粒度で、誰に対して公開するのか。これはロードマップのどの項目にも含まれていません。仕様が決めることではなく、各社が決めることだからです。
この切り分けが、着手判断の実質です。MCP 導入の作業量の大半は、実は内側にあります。 既存の API やデータベースから、エージェントに渡してよい単位を切り出し、権限の境界を引き、返す情報の粒度を決める作業。既存 API を MCP サーバーとして設計し直すときに時間がかかるのも、変換の実装ではなくこの設計です。
外側が動いている間に内側を進めておくのは、無駄になりません。
ステートレス化はすでに入っている
もう1つ、実務上大きい変化が先に到着しています。2026年7月末の仕様改訂で、HTTP トランスポートがステートレスな方向に整理されました。 エンタープライズ向けに認可を一括管理する Enterprise-Managed Authorization の拡張も、同時期に安定版になっています。
何が変わるかというと、運用側の前提です。 接続ごとに状態を保持する必要がなくなると、MCP サーバーは通常の Web アプリケーションと同じようにロードバランサーの背後に並べられます。冗長化も、スケールも、既存の運用手順の延長で扱えます。
「AI エージェント用の特別なサーバーを1台立てて、そこだけ別運用する」という構成を避けられるということです。社内システムに組み込むうえで、これはかなり大きい。 特別扱いが必要なコンポーネントは、たいてい数年後に保守されなくなります。
判断の線引き
以上を踏まえると、着手の可否はおおむね次のように分かれます。
先に進めてよいもの
- どの業務データを、どの単位でエージェントに公開するかの設計
- 権限境界の整理（誰の権限で実行されるのかを、業務側の役割に対応させる）
- 監査ログに何を残すかの決定
急がなくてよいもの
- サーバーの自動発見を前提にした構成（Server Cards の標準化はこれから）
- 複数エージェントの非同期連携を前提にした設計（Tasks の強化がこれから）
つまり、1つの業務システムを1つの MCP サーバーとして公開するところまでは、いま設計して構いません。 複数のエージェントが自律的に連携し合う構成は、もう少し待ってからでも遅くありません。
現実の相談でも、実際に効果が出ているのは前者です。「在庫状況を自然言語で引ける」「見積の履歴を横断して探せる」といった、1システム1用途のものが確実に回っています。
読み取りから始めると、あとの判断が楽になる
読み取り専用で始めることを勧める理由は、安全性だけではありません。実際に何が使われるかが、事前の想定と食い違うからです。
想定では「在庫の引き当て状況を見たい」だったのに、動かしてみると実際に多いのは「先月と同じ品番を探したい」だった、というずれは頻繁に起きます。この情報は、机上の設計では出てきません。
読み取り専用の期間に取っておくべきなのは、どの問い合わせが多かったかのログです。これがあると、更新系を足すときに「どの操作を、誰の権限で許すか」を実データで決められます。逆にログを残していないと、更新系の設計は再び想像で進めることになります。
監査ログに何を残すかを最初に決めるべきだと書いたのは、この理由もあります。監査のためだけでなく、次に何を作るかを決めるための材料になります。
次にやること
まず、エージェントから触らせたい業務システムを1つに絞ってください。 複数を同時に検討すると、必ず「全体の連携をどうするか」の議論になり、それはロードマップ上まだ固まっていない領域です。
そのうえで、そのシステムで「読み取りだけ許す操作」を書き出してください。 更新系を含めるかどうかは、読み取りが安定して動いてから決めれば十分です。この一覧ができていれば、仕様の細部がこの先変わっても、作り直しになるのは接続部分だけで済みます。
社内システムの AI エージェント接続、MCP サーバーの設計・実装、権限境界と監査ログの設計については、グリームハブの開発・AI・自動化のご相談で承っています。既存システムの構成によって取れる手段が変わるため、個別にご相談ください。お問い合わせからどうぞ。
