MCP2026新仕様でできるようになること

Grace
2026-06-26

BTMAIZ の Graceと申します。
MCP、Model Context Protocol の 2026 年新仕様を踏まえ、現場の業務として何ができるようになるかを整理しました。条文の一覧というより、社内で導入を検討するときの判断材料になればと思います。

この記事の内容

3つの拡張で見る全体像
2026年版で追加・変更される3つの拡張
ステートレス化でできること
Tasks でできること
MCP Apps でできること
向いているユースケースと早いケース
活かすときの注意
まとめ
参考にしたサイト

3つの拡張で見る全体像

MCP は、エージェントが外部のデータやツールに安全にアクセスするための接続規約です。ローカル開発なら Cursor などの stdio 接続で足りることが多いです。組織で本番運用に広げていくと、接続はできてもスケールしない、長い処理で会話が止まる、UI とツールの監査が分断される、といった壁に当たりやすくなります。

2026 年に予定されている MCP 新仕様では、こうした課題に対応する3つの拡張（SEP-2567 / 2663 / 1865）が整理されています。何が追加・変更されるかは次のセクションで整理し、そのあと現場の業務にどうつながるかを見ます。

MCP の入門説明や SEP の条文解説は、ここでは深くは扱いません。エージェントや生成 AI で業務改善を進めているテックリード、プロダクト担当、導入を押さえている方に向けて、社内で何から試せるかを中心にまとめています。

📌 ざっくり言うと

MCP 新仕様は、ツール接続の細部を直すだけではありません。エージェントを本番の業務フローに載せるための3つの拡張がまとまって入ってきます。stdio のローカル利用は当面これまでどおり。組織展開、長時間業務、UI 統合では、設計の選択肢が増えます。

2026年版で追加・変更される3つの拡張

ツール一覧の取得、ツール呼び出し、リソース参照といった MCP の基本は、これまでどおりです。2026-07-28 リリース候補で公式に位置づけられる拡張は、ステートレス化（SEP-2567）、Tasks（SEP-2663）、MCP Apps（SEP-1865）の3つです。いずれも任意の拡張として定義されており、ホストとサーバーが対応していれば使えます。

拡張	これまで	2026年版で
ステートレス化 SEP-2567	リモート MCP はサーバー側がセッション状態を抱えやすく、LB 配下やマルチエージェントで運用が重くなりがち	リクエストごとに必要な文脈をクライアントから渡し、サーバーは可能な限り状態を持たない形に寄せられる。多段業務の継続には、明示的な State Handle を使う設計パターンが示される
Tasks 拡張 SEP-2663	長時間処理は同期のツール呼び出しに縛られ、会話スレッドが止まったりタイムアウトしやすい	処理をタスクとして起票し、非同期で進捗を確認し、完了結果を後から受け取れる
MCP Apps SEP-1865	対話的な UI はチャット外の別実装になりがちで、ツール操作と画面操作の監査が分かれやすい	MCP サーバーが提供するインタラクティブ UI を、チャットのホスト内に埋め込める

3つを組み合わせれば、ステートレスなリモート MCP に重い処理を任せ、チャット内 UI で現場が操作する、といった本番寄りの流れを一続きの設計として描けます。以下では、拡張ごとに業務として何が変わるかを取り上げます。

補足：執筆時点では MCP 2026 仕様はリリース候補段階です。最新の仕様や対応状況は、modelcontextprotocol.io でもご確認ください。

ステートレス化でできること

Kubernetes やロードバランサの前でリモート MCP を並べるとき、たとえば次の設計が現実的です。

組織規模でのリモート MCP 配備：部門横断のツールゲートウェイを、水平スケールできる形で置ける
LB・オートスケールとの相性改善：どのインスタンスに振られても同じように応答できる前提を整えられる
サブエージェント連携のオーバーヘッド低減：オーケストレータが複数の専門エージェントを呼ぶとき、セッション維持の負担が減る

たとえば、社内 API 用の MCP を Kubernetes 上に複数台立て、営業・経理・開発の各エージェントから同じエンドポイントを叩く配備が現実的です。

ハーネス設計では、ツール接続を開発者個人のローカル設定から、組織が承認した共有インフラへ移す一歩になります。AWS Agent Registry のような統制と組み合わせれば、誰がどの MCP を使えるかをカタログ化しつつ、接続先をスケールさせる構成も組み立てられます。

多段業務の継続（State Handle）

ステートレス化の設計の中で、承認待ちや担当変更を挟む業務をどう継続するかが示されています。業務の途中状態を Handle で識別すれば、セッションが切れても同じ案件を再開・引き継ぎできます。Tasks が非同期の1件の仕事を扱うのに対し、State Handle は複数ステップの業務全体を指す、と切り分けておくと設計しやすいです。

たとえば、見積ドラフトを出したあと上長承認を待ち、翌日同じ Handle で発注ステップに進む、といった日をまたぐ業務を、セッション切れの影響を受けにくくできます。

💡 ポイント

Cursor などの stdio ローカル接続は、当面は従来どおり使えます。ステートレス化が主役になるのは、リモート MCP を本番相当の環境に載せる段階です。まずローカルでツールを試し、社内共有に進むときに設計を切り替える進め方で足ります。

Tasks でできること

数分から数時間かかる処理をエージェントに渡すとき、会話を止めずに進められるのは次の点です。

会話を止めずに委任：分析を預けたあと、ユーザーは別の質問や作業を続けられる
進捗・結果のポーリング：タスク ID で状態を問い合わせ、完了時に結果を取り込める
バックグラウンド業務との接続：既存のジョブキューやワークフローエンジンと、エージェント経由の起動点を揃えられる

たとえば、全社売上の集計レポート生成をエージェントに任せ、チャットでは別件の質問を続け、数十分後に完了通知で結果を受け取る、といった動き方です。

Tasks はエージェントをチャット内だけで完結させず、社内の非同期業務を起動する入口として扱えます。マルチエージェントで専門役に処理を振ったあと、オーケストレータがタスク完了を待って次の手を打つ構成も取れます。

MCP Apps でできること

フォームやプレビューなど UI が要る業務では、次の点が活きてきます。

チャット内でのリッチな操作：フォーム、スライダー、プレビューなどを会話の流れの中で出せる
ツールと UI の監査パス統一：同じ MCP 接続・同じ権限モデルの上で、テキスト指示と画面操作を追跡できる
部門ツールの UI を共通化：バックエンドは既存 API、フロントは MCP App としてホストに載せる分担が取れる

たとえば、経費申請の金額と科目をチャット内のフォームで確認し、担当者が承認したあとだけ支払い API を実行する流れを、1本の監査ログに残せます。

社内システムにエージェント連携を足すたびに専用画面を作るコストは下がります。UI を載せる以上、誰がどの画面を開けるかの統制は先に決めておくと安心です。Agent Registry 型のガバナンスとあわせて検討できるとよいでしょう。

📌 ざっくり言うと

3つの拡張を組み合わせるイメージです。ステートレスなリモート MCP に Tasks で重い処理を任せ、MCP Apps で現場が操作する。承認待ちなど日をまたぐ業務は、ステートレス設計の中で State Handle を使って継続できます。

向いているユースケースと早いケース

3つの拡張を一度に入れる必要はありません。組織の成熟度に応じて、無理のない範囲で段階を分けていけば足ります。

段階	向いている状況	先に試す要素
今すぐ試せる	開発者が Cursor 等で MCP を試している	ローカル stdio は従来どおり。リモート化の設計だけ先に検討
部門 PoC	1業務にエージェントと社内 API を載せたい	Tasks、MCP Apps
全社展開	複数部門でツールを共有したい	ステートレス化と統制、Registry 等
業務プロセス直結	承認、引き継ぎ、再開が必須	ステートレス化（多段業務の継続）と Tasks

PoC の候補になりやすい業務をいくつか挙げます。

社内データ・業務 API の共通ゲートウェイ：部門ごとのバラバラな連携を、承認済み MCP に集約する
レポート・分析の非同期委任：重いクエリや集計をタスク化し、完了通知で回収する
承認付きオペレーション：MCP App でパラメータを確認し、承認後にツール実行までを一連の監査ログに残す
マルチエージェントの本番運用：オーケストレータ＋専門エージェントを、セッション負荷を抑えて並列・直列に動かす

あまり向かないのは、MCP を社内に広めるだけの用途や、既存のワークフローエンジンで足りている単純バッチです。新仕様の恩恵は、エージェント経由で対話しながら判断する業務に載せたときに、いちばん実感しやすいと思います。

活かすときの注意

新しい拡張を入れるとき、現場でつまずきやすい点を、先に押さえておくと安心です。

仕様はまだ動く：リリース候補段階のため、ホスト、SDK、サーバーの対応時期はベンダーごとに差が出ます。本番判断の前に公式サイトを確認しておくと安心です
統制なき拡張は危険：リモート MCP と MCP Apps が増えるほど、権限・監査・棚卸しの設計を先に考えておきたいところです
全部入りは避ける：3つの拡張を一度に実装せず、1業務・1要素から PoC する
ハーネス全体は別設計：MCP はツール接続と UI の標準化に強いが、評価・権限・失敗時の介入は引き続きハーネス側の責務です
既存投資との役割分担：Workflow エンジン、iPaaS、社内ポータルと、どこまで MCP に寄せるかを決めないと二重実装になりやすい

補足：試験導入の段階では、ツールが動くかに加えて、誰がいつ何を起動し、どのタスクや多段業務を追跡できるかまで押さえておくと、本番移行の判断材料が揃いやすくなります。

まとめ

MCP 2026 新仕様は、接続規約の細部を読む資料というより、エージェントを本番業務に載せる3つの拡張で捉えると全体像が掴みやすくなります。ステートレス化は組織規模の配備と多段業務の継続、Tasks は長時間委任、MCP Apps は現場 UI と監査の統一に対応します。

分かれ目は、ローカルでツールを試すだけか、部門や全社でエージェント連携を運用するかです。前者は stdio を続け、後者はリモート設計と統制を先に決めていく形が現実的です。後者なら1業務に絞り Tasks か MCP Apps から PoC を始め、動いてきたらステートレス基盤へ広げていく進め方で足りると思います。

まずは自社で困りごとが大きい業務を1つ選び、長時間待ち、UI 分断、引き継ぎ不能、ツール乱立のうち、どれに当てはまるかを整理してみると、3つの拡張のどこから PoC を始めるかが見えてきます。