経費の確認や在庫の引き当てをGeminiに頼むと、結果は文章で返ってきます。「この2件だけ差し戻して」「並び順を変えて」と直すたびに、またチャットで頼み直すことになります。表やボタンのある画面で操作したい作業ほど、文章のやり取りでは手間が増えます。
Google Cloudの開発者向けブログに2026年10月19日（米国時間）、この問題への答えとして「MCP Apps」をGemini Enterpriseで動かす手順が載りました。MCP Appsは、AIが使う道具（ツール）に操作画面を組み合わせる、Model Context Protocol（MCP）の拡張です。画面はチャットの中に表示され、全画面やサイドパネルにも広げられます。
この記事では、ブログの構成と、MCP Appsの仕様（SEP-1865）の原文、編集部がSDKで小さなサーバーを動かした結果をもとに、社内ツールをつなぐ前に担当者が決めておくことを整理します。Gemini Enterprise上での表示は編集部では確認していません。
MCP Appsで何が変わるのか
ブログは、社内向けのAIアシスタントを3つの段階に分けています。文章だけを返すチャットボット、外部のAPIを呼べるが結果は文章で返す通常のMCPツール、そしてツールごとに操作画面を持つMCP Appsです。MCP Appsでは「画面の中の操作はモデルとのやり取りを挟まずに実行される」とされています。
仕様（SEP-1865、2026年1月26日に「Stable」）の仕組みは次のとおりです。
- 画面は
ui://で始まるURIのリソースとして、HTML（MIMEタイプtext/html;profile=mcp-app）で用意する - ツールの
_meta.ui.resourceUriにその画面を指定して、ツールと画面を結び付ける - ホスト（Gemini Enterpriseのようなチャット側）は、画面をサンドボックス化したiframeで表示しなければならない
- MCP Appsに対応しないホストでは、ツールは通常の文章の結果を返すツールとして動く
最後の点は、つないだ社内ツールが画面に対応しないAIからも使われうる、ということです。仕様は、画面を持つツールにも文章の結果を必ず返すよう求めています。
Gemini Enterpriseでの構成
ブログの構成は3層です。利用者のブラウザ（チャットと画面）、Gemini Enterprise（既定のアシスタントがツールを呼び、画面とのやり取りを中継し、OAuthを管理する）、そして自社のGoogle Cloudプロジェクトです。自社側では、MCPサーバーをCloud Runで動かし、/mcp という1つの窓口と、1ファイルのHTMLの画面を返します。
認証は2層で、片方では足りない
ブログが最も紙幅を割いているのが認証です。Gemini Enterpriseは呼び出しのたびに、自身のサービスエージェントのトークンと、利用者がOAuthでサインインしたトークンの両方を送ります。Gemini Enterpriseのドキュメントによると、前者は X-Serverless-Authorization ヘッダー、後者は Authorization ヘッダーに入ります。
| 層 | 確かめること | 失敗したとき |
|---|---|---|
| 1層目：Cloud RunのIAM | どのサービスが呼んでいるか（公開アクセスは無効） | HTTP 403 |
| 2層目：アプリの中のOAuth | どの利用者が呼んでいるか | HTTP 401（再サインインを促す） |
ブログには「Cloud RunのIAMは利用者を見分けられないため、両方の層が必要」とあります。1層目だけでは、Gemini Enterpriseを使える社員なら誰でも、そのツールの操作を実行できる状態になります。経費の承認のように人によって権限が違う操作は、2層目で得た利用者に基づいて、サーバーの側で判断する必要があります。
管理者が触る設定
ブログの手順のうち、管理者の判断が要るのは次の点です。Gemini Enterpriseのドキュメントで確かめた内容も補っています。
- 組織ポリシーの制約を解除する。 Gemini Enterpriseは、独自のMCPサーバーのデータストアを作れないよう、
discoveryengine.managed.disableCustomMcpServerConnectorという制約で既定で止めています。組織のポリシー管理者（roles/orgpolicy.policyAdmin）が、この制約を上書きして無効にします。VPC Service Controls（データの持ち出しを防ぐ境界）で保護したプロジェクトや、ポリシーの適用対象に入れたプロジェクトでは、接続先とOAuthのホストをallowedEgressFqdnsに、custom_mcpをallowedDataSourcesに加える必要もあります - 呼び出しの権限を1つのサービスに絞る。 Cloud Runの起動者のロール（
roles/run.invoker）を、Discovery Engineのサービスエージェントに付けます。ドキュメントによると、Gemini Enterpriseが1層目のトークンを付けるのは、.run.appで終わる既定のURLにつないだときだけです。独自ドメインのURLでは送られません - OAuthのクライアントを作る。 リダイレクト先は
https://vertexaisearch.cloud.google.com/oauth-redirect、スコープはopenid email profile、PKCEは有効が推奨です - アクションを選んで有効にする。 Gemini Enterpriseは取り込んだツールを「アクション」として既定で無効にします。モデルに見せるツールを選んで有効にします（一度に有効にできるのは100個まで）。ドキュメントによると、読み取り専用の注記（
readOnlyHint）がないツールは、呼び出しのたびに利用者の確認を求めます - データストアとしてアプリにつなぐ。 ブログは、「Add Agent」（外部のサブエージェント用）ではなく、データストアとして接続するよう注意しています
1の制約の上書きについて、ドキュメントは対象のプロジェクトを選んで行うよう注意しています。組織の単位で設定すると、組織内のすべてのプロジェクトで独自のMCPサーバーをつなげる状態になるためです。社内の承認の流れに乗せ、対象のプロジェクトに絞って解除することを、編集部としては勧めます。
なお、この設定手順を載せたドキュメントは、Standard・Plus・Pay-as-you-go・Frontlineの各エディション向けです。Businessエディションで同じ設定ができるかは確認できていません。
手元で確かめた、画面専用のツールの扱い
MCP Appsでは、ツールに visibility を付けて、モデルからは呼べず画面からだけ呼べるツール（["app"]）を作れます。画面のボタンで実行する「承認」のような操作に使う想定です。
編集部では、MCP Apps のSDK（@modelcontextprotocol/ext-apps 2.0.3、@modelcontextprotocol/sdk 1.32.1）で、検証用の小さなサーバーを作りました。経費の一覧を表示するツールと、画面専用の承認ツールの2つです。これに、MCP Appsに対応しない普通のクライアントをメモリ上でつないで試した結果が次の表です。
| 試したこと | 結果 |
|---|---|
ツールの一覧（tools/list） | 画面専用の承認ツールも、visibility: ["app"] 付きで一覧に出た |
画面のリソース（resources/read） | text/html;profile=mcp-app のHTMLが返った |
| 一覧のツールを呼ぶ | 文章の結果（「2026-10 の申請は3件」）が返った |
| 承認ツールを直接呼ぶ | 実行され「approved EXP-1」が返った |
仕様では、["app"] のツールをモデルの道具の一覧から外すのはホストの役割です。サーバーの側で呼び出しを拒む決まりはなく、編集部の検証でもSDKのサーバーは呼び出しを止めませんでした。つまり、MCPサーバーに直接つながる経路があれば、画面専用のつもりの操作も実行できます。重要な操作は visibility に頼らず、2層目の認証で得た利用者の権限をサーバーで確かめる作りにしておく必要があります。
つなぐ前に決めておくこと
ここからは編集部の整理です。
- どの操作を画面に出すか。 一覧・比較・確認のように、何度も直す作業ほど画面にする価値があります。ブログも、実行前に人が確かめる「人が判断を挟む」使い方を利点に挙げています
- 誰が何を実行できるか。 2層目の利用者ごとの権限を、既存の社内システムの権限と一致させます
- 画面が外部と通信するか。 仕様では、画面が通信できる先はリソースで宣言したドメインに限られ、宣言がなければ外部への接続（
connect-src）は許されません。使うAPIやCDNを洗い出しておきます - 常時起動の費用。 ブログのCloud Runの設定例は、最小インスタンス数1・CPUを常に割り当てる指定です。料金はブログに書かれていないため、Google Cloudの料金表で見積もります
MCPサーバーに渡す権限の考え方はAIにgcloudを任せる前に — リモートMCPの権限設計、Gemini Enterpriseへのアクセスを端末と場所で絞る設定はGemini Enterprise のアクセスを端末と場所で絞るCAA設定で扱っています。AIに専用のアカウントを持たせる動きはAIに専用のWorkspaceアカウント 管理者が先に決めることを参照してください。
確認した範囲
2026年10月22日に、Google Cloudのブログ「Developer’s guide to implementing MCP apps in Gemini」（2026年10月19日）と、MCP Appsの仕様（modelcontextprotocol/ext-apps リポジトリの
specification/2026-01-26/apps.mdx、SEP-1865）を直接開いて確認しました（資料調査）。あわせて、編集部の検証環境（Linux、Node.js v22.22.0）で、npmに公開された@modelcontextprotocol/ext-apps2.0.3 と@modelcontextprotocol/sdk1.32.1 を使い、検証用のMCPサーバーにメモリ上のクライアントをつないで、ツールの一覧・画面のリソース・呼び出しの結果を確かめました（実機検証）。Gemini Enterpriseでの画面の表示、Cloud Runへのデプロイ、OAuthと組織ポリシーの設定は試していません。同じ日に、Gemini Enterpriseのドキュメント（カスタムMCPサーバーのデータストアの設定、組織ポリシーの上書き、データストアの接続、エディションの比較）も開き、ブログの手順と照合しました。エディションごとにこの機能が使えるかを明記した記述と、料金は確認できていません。
Gemini EnterpriseやGoogle Workspaceに社内のツールをつなぐ設計・権限の整理は、IT・Google Workspace 無料相談からお問い合わせください。
参考資料
- Developer’s guide to implementing MCP apps in Gemini（Google Cloud Blog, 2026-10-19）
- Set up your custom MCP server data store（Gemini Enterprise ドキュメント, 2026-10-19 更新）
- Override the organization policy for Custom MCP data stores（Gemini Enterprise ドキュメント, 2026-10-14 更新）
- Compare editions of Gemini Enterprise（Gemini Enterprise ドキュメント, 2026-10-16 更新）
- SEP-1865: MCP Apps（modelcontextprotocol/ext-apps, specification/2026-01-26/apps.mdx）
- npm registry — @modelcontextprotocol/ext-apps
