Model Context Protocol（MCP）に2026年1月26日付けで最初の公式拡張が入り、ツールの実行結果（戻り値）を3つに分ける仕様が加わりました。要点は「AIに見せなくてよい情報を、AIに渡さない」ことです。表示専用のデータをAIのコンテキストから隠すことで、トークン消費と情報漏れの両方を同時に減らせます。これは技術者向けの話に見えて、中小企業が社員のセンシティブデータをAIに渡すときの設計判断にそのまま通じます。以下、素材と当社の実測を突き合わせて読み解きます。
なお、この記事の運営元である株式会社TOEは、AI検索対策・AI導入支援を事業にしている利害関係者です。そのうえで、素材に書かれていることと、当社が実際に測った数字だけを根拠に書きます。
何が変わったのか──戻り値を3つに分ける
素材（Zenn AI）によれば、MCP Apps以前は、ツールの実行結果は基本的に文章としてAIに渡し、AIがそれを解釈して人間向けに整形していました。この方式だと、たとえば顧客データ100件をテーブル表示したいだけでも、丸ごとテキスト化してAIのコンテキストに読ませる必要があり、トークン消費と応答速度の両方でロスが出ます。
新しい仕様では、戻り値を用途別に3つへ分けます。
| 戻り値 | 中身 | AIから見えるか |
|---|---|---|
| content | AIが読む要約テキスト（「ダッシュボードを出した」程度の短文でよい） | 見える |
| structuredContent | UIが描画に使う生データ | 見えない |
| _meta | どのUIリソースを読み込むかを指す描画指示 | 描画指示 |
表示専用のデータをAIのコンテキストから隠すことで、トークン消費を抑えつつ、うっかり長い個人情報をモデルに読ませてしまう事故も減らせる設計だと素材は説明しています。UI自体はサンドボックス化されたiframe内で描画され、postMessageでホストアプリとやり取りする、Web標準の組み合わせで実現しているとのことです。
UI表示以外に同時に入った2つ
素材によれば、今回の拡張はチャットの返答にボタンやフォーム、確認ダイアログを埋め込めるようにするUI表示だけでなく、次の2点も同時に入っています。
- Streaming / MRTR: 長時間処理の途中経過を通知として流せるようになり、かつ通信が切れても「リクエストID＋最後に受け取ったイベントID」で処理を再開できる（最初からやり直しにならない）。
- Elicitation: 危険な操作の前にAIが人間の承認を挟める仕組み。サーバー側は「入力が必要」という状態を返すだけで、実際の確認UIはクライアント側が担当する。
素材はこれらを「AIに権限を持たせたいが、暴走が怖くて読み取り専用にせざるを得なかった、という現場の悩みへの回答」と位置づけています。AIに権限を渡す前に人間の承認を挟むという発想は、当サイトでも繰り返し扱ってきた論点です。AIにキーや権限を渡す設計そのものを問い直す視点は、AIエージェントに渡したAPIキーは回収できない ― 中小企業は「渡さない」を最初に選べるのか？やAIエージェントに「キー名だけ」渡す設計は成立するのか ― trustlessが値を見せない一点に絞った理由で扱っています。
既存サーバーはどうなるのか──Graceful Degradation
素材によれば、新機能はすべてオプションとして設計されており、UI非対応のクライアント（ターミナル等）に対しては、実装側が「機能検知→対応していなければプレーンテキストにフォールバック」という段階的縮退（Graceful Degradation）を用意する作法になっています。既存のMCPサーバーを急いで全面改修する必要はない、という点を素材は「安心材料」と書いています。
また素材は、MCPが2025年12月にLinux Foundation傘下のAAIFへガバナンスが移管され、SDKの月間ダウンロードも2024年11月の約200万回から2026年3月時点で9,700万回まで伸びた、という数字を挙げています。個人の実験ツールから企業インフラへと要求水準が引き上げられる中での仕様変更、という文脈です。
中小企業にとって何が変わるのか
ここからが、報道の要約では終わらせない部分です。「AIに見せなくてよい情報を、なぜ処理させるのか」という問いは、MCPサーバーを実装するエンジニアだけの話ではありません。中小企業が社員名簿や顧客リストをAIに扱わせるときにも、同じ問いが立ちます。
当社は2026年8月1日、福岡県の金属加工業45社を実測しました（Gemini Flash-Lite＋Google検索グラウンディング、1社3回）。公式サイトを根拠に説明できたのは42社（93%）でした。ここでAIが正しく引用できていたのは、当社の別の実測（2026年7月18日、Perplexityに3クエリ）で確認したとおり、「0.03mm〜1.0mmの極薄板溶接に対応」「1点から製作」のような具体的な記述の箇所であって、「高品質」「短納期」といった抽象的なキャッチコピーの箇所ではありませんでした。
つまり、AIに読ませて意味があるのは具体的で構造化された情報であり、抽象的な飾り文句や、そもそもAIに渡す必要のない表示専用データは、コストと事故のリスクを増やすだけになりがちです。MCPの戻り値3分割は、この「渡す情報を絞る」という判断を仕様のレベルで後押しするものだと読めます。社員のセンシティブデータをAIに渡す前に分類し、AIが本当に必要な部分だけを渡す設計を意識することは、中小企業のAI導入でもそのまま応用できる考え方です。
なお当社の運用中のAI API課金は現時点で0円で、社内業務の自動化は27本、AI秘書のブリーフィングは毎朝8:00に動いています。当サイト自体も、収集済みニュース3000件・自社要約つきニュース1850件・本文取得済み1054件・記事283本を、人手を介さず毎日自動で生産しています（2026-09-04時点）。「AIに渡す情報を絞る」設計は、こうした日々の自動処理のコストにも効いてくる論点です。大きなモデルに全部を読ませるのではなく必要な分だけを扱うという発想は、小さいモデルが大型モデルに勝った──中小企業は「勘の良い部下」を安く育てられるのか？でも扱っています。
この記事で言えないこと
- 戻り値3分割で、実際にトークン消費がどれだけ下がるのか。素材にも数値はなく、当社も測っていません。
- 中小企業の一般的な業務システムでMCP Appsを導入したときの効果。当社は実装・計測していません。
- 応答速度がどれだけ改善するか。素材は「ロスが出る」「抑えられる」と書くのみで、具体的な数字はありません。
- Streaming / Elicitation / Graceful Degradation の各機能が、主要なAIクライアントでどこまで実装されているか。素材からは分かりません。
- MCPの月間ダウンロード9,700万回が、どのくらいが企業の本番運用かの内訳。素材からは分かりません。
- 元ネタの動画で解説されている技術的詳細（仕様書の図解や比喩）は、当社が独自に検証したものではありません。
まとめ
- MCPに2026年1月26日付けで公式拡張が入り、戻り値をcontent（AIが読む要約）・structuredContent（UI描画用の生データ、AIから見えない）・_meta（描画指示）の3つに分ける仕様が加わりました。
- 狙いは「AIに見せなくてよい情報を渡さない」こと。トークン消費と、個人情報をうっかりモデルに読ませる事故の両方を減らす設計です。
- UI表示に加え、長時間処理の再開（Streaming / MRTR）と、危険な操作前の人間承認（Elicitation）も同時に入りました。既存サーバーは段階的縮退（Graceful Degradation）で急な改修は不要です。
- 中小企業にとっての示唆は「AIに渡す情報を分類して絞る」こと。当社の実測でも、AIが正しく引用したのは具体的な記述であり、抽象的なキャッチコピーではありませんでした。
- ただし効果の具体的な数値は素材になく、当社も測っていません。仕組みの理解として押さえ、自社データをAIに渡す前の分類設計に活かすのが実務的です。
この記事はZenn AIの解説記事「MCPの『戻り値3分割』設計から学ぶ、AIエージェントのUI表示とコスト最適化」を素材に、当社が2026年7月18日にPerplexityへ投げた引用元調査、2026年8月1日の福岡県金属加工業45社の実測、および2026-09-04時点の自社サイトの自動集計データとあわせて書きました。
