Gemini SparkのConnected Appsとは？MCPで外部アプリを動かす仕組みと日本企業の導入判断

5 時間前
読了時間: 14分

結論：Gemini SparkのConnected Appsとcustom MCPは、「AIに質問する」段階から「AIが外部ツールを使って仕事を進める」段階への重要な変化です。ただし2026年8月16日時点のGoogle公式情報では、Gemini Sparkの現在の展開地域から日本は除外され、custom Connected Appsにも米国・個人Googleアカウント・英語などの条件があります。日本企業が今やるべきことは、無理に導入することではありません。提供開始後に安全に使えるよう、read / write / human approval / stopの4点を先に設計しておくことです。

この記事では、Connected Appsの機能紹介だけで終わらず、通常チャット・native Connected Apps・custom MCPの違い、MCP server URLが何を意味するのか、Google管理外のthird-party MCP serverをどう評価するのか、日本企業が今できる準備とまだやらない方がよいことまで整理します。

この記事の対象読者と分かること

対象は、生成AIを「文章を作るツール」から一歩進め、社内システムや外部アプリと接続して業務を動かしたい中小企業の経営者、DX担当、情報システム担当者です。MCPという言葉を最近よく見るが何が変わるのか分からない、Gemini Sparkが日本で使えるか知りたい、AIエージェントを導入したいが権限やセキュリティが不安、という方を想定しています。

読み終えると「いま契約すべきか」だけでなく、「将来使えるようになった時、どの業務なら安全に接続できるか」を判断できます。新機能を追いかける記事ではなく、提供地域が変わっても使える企業側の設計原則を残すことを目的にしています。

なぜ今、Connected AppsとMCPを理解しておく必要があるのか

これまでの生成AI活用は、基本的に「人がAIへ質問し、AIが文章や回答を返す」形でした。メール下書き、議事録要約、企画案、検索補助など、多くの業務はこの形で十分に効率化できます。しかしAIエージェント化が進むと、AIが回答するだけでなく、外部のアプリやデータを読み、必要な機能を呼び出し、条件によっては書き込みまで行います。

例えば、AIが顧客情報を読み、必要な内容を整理し、外部ツールで下書きを作り、人間が確認した後に登録する、といった流れです。この変化は便利ですが、モデルの性能だけを見て導入すると危険です。AIが何を読めるのか、何を書けるのか、どこで人間が承認するのか、異常時に誰が止めるのか。この4点を決めて初めて業務として安定します。

CURRENT：日本はGemini Sparkの現在の提供対象外

Google公式情報で確認できる範囲では、Gemini Sparkは米国から展開が始まり、その後対象地域を拡大しています。ただし現在の展開地域では日本は対象外です。したがって「GeminiにMCPが来たから、日本企業も今すぐSparkでcustom appを本番導入できる」と考えるのは正確ではありません。

custom Connected AppsはGemini Sparkへのアクセスが前提で、現行条件には18歳以上、米国、personal Google Account、Keep Activity有効、英語での利用などが含まれます。work / school Google Accountは現在custom apps非対応です。企業導入で特に重要なのは、Google Workspaceの組織アカウントで一般的に使える状態ではない点です。

提供条件は今後変わる可能性があります。そのため本記事の結論は「日本では永遠に使えない」ではなく、「現在は一般導入前なので、提供開始を前提に大規模実装するのではなく、権限設計を先に準備する」です。公開・導入時には必ず最新のGoogle公式情報を再確認する必要があります。

通常チャット・Connected Apps・custom MCPを比較

比較軸	通常チャット	Connected Apps	custom MCP
主な役割	質問・生成・要約	対応アプリとの連携	MCP server経由で外部機能接続
外部操作	原則なし	対応機能により可能	tool定義により可能
管理責任	比較的単純	アプリ条件確認が必要	MCP運営元・権限設計が重要
日本企業の現在地	広く利用可能	アプリごとに条件差	Spark日本対象外のため一般導入前

通常チャットは最も分かりやすく、AIが答えを作り、人間がその答えを使います。Connected Appsになると外部サービスへ接続するため、情報の取得元と操作範囲が広がります。custom MCPでは企業や第三者が用意したMCP serverを通じてAIから利用できる機能を増やせます。その自由度が高い分、責任も企業側へ移ります。

MCP server URLで接続するとはどういうことか

MCPはModel Context Protocolの略で、AIと外部ツールの間に共通の接続方法を作る考え方です。custom appではMCP server URLを登録し、そのserver側がAIから利用可能なtoolやデータを定義します。AIがすべての外部APIを直接理解するのではなく、MCP serverが「何を読めるか」「何を実行できるか」を仲介します。

企業側から見ると、サービスごとにAI専用接続をゼロから作るより、共通の形でtool接続を設計できる可能性があります。一方、MCP server URLを登録できることと安全であることは別です。URLは入口でしかなく、その先の運営者、データ処理、credential、write範囲、ログ、停止手順を確認しなければなりません。

third-party MCP serverはGoogle管理外

Googleはthird-party MCP serverを自社でcontrol / monitor / secureするものではないと明記しています。ここは企業導入で最も重要な注意点の一つです。「Geminiから接続できる」ことを「Googleが接続先を保証している」と読み替えてはいけません。接続先の信頼性評価は利用者側の責任です。

最低限、運営者は誰か、何のデータを読むか、どんなwrite toolがあるか、credentialをどこで保持するか、ログは残るか、契約終了時にデータがどう扱われるか、異常時に接続解除できるかを確認します。便利なMCP serverを見つけたら即接続する、という運用は法人では避けるべきです。

write actionsにはmanual confirmationが必要

Googleの現行情報では、write actionsにはmanual confirmationが必要です。これは重要な安全境界です。ただし企業側は「Googleが確認画面を出すから安全」と任せきりにしない方がよいでしょう。価格変更、顧客送信、削除、公開、本番設定など、失敗コストが大きい操作には自社のHuman Gateも必要です。

たとえばAIがCRMの顧客情報を読むことと、顧客へメールを送ることは同じ権限ではありません。Webページを読むことと公開ページを書き換えることも別です。Connected Appsを「つなぐ / つながない」の二択で考えず、tool単位でreadとwriteを分ける方が実務に合います。

企業導入では4つの境界を先に決める

1. Read — 何を読めるか

公開情報だけか、社内文書までか、顧客情報を含むか、部署をまたぐデータへアクセスできるかを決めます。「読むだけだから安全」とは限りません。不要な情報まで読ませると、回答への混入、権限越境、古い資料の誤利用などが起きます。タスク達成に必要な最小データだけを見せる方が安全です。

2. Write — 何を書き換えられるか

下書き保存までなのか、本番更新までなのか、社内DBへ追加できるのか、外部送信まで許可するのか。writeは業務単位で最小化します。特に削除、公開、価格、契約、顧客送信は「AIができるか」ではなく「AIに任せるべきか」で判断します。

3. Human approval — 人間はどこで確認するか

AI活用の目的は人間をゼロにすることではありません。確認価値の低い工程をAIへ渡し、重要判断へ人間を集中させることです。契約、価格、顧客送信、外部公開、production変更など失敗コストが大きい操作はHuman Gateへ戻します。

4. Stop — 何が起きたら止めるか

不明なMCP serverへ接続しようとした、想定外のwriteを要求した、必要な確認情報が不足、利用地域やアカウント条件が合わない、出力が成功条件を満たさない。このような場合はAIが何とか続けるのではなくHOLDして人間へ返す方が安全です。停止条件は失敗時に考えるのではなく、導入前に決めます。

HSビルの実務視点：AIに全部任せる構成にしない

HSビルでは、企画・調査・実装・確認を同じAIへ全部まとめず、担当を分け、外部状態へ影響する操作には人間確認や承認境界を置く考え方です。AIが動いたこと自体を完了とせず、成果物・検証・成功条件まで揃って初めて業務上の完了と判断します。

この経験からConnected AppsやMCPを見るときも、「どれだけ自動化できるか」だけでは評価しません。AIがどこまで読むか、どこまで判断するか、どこまで書くか、人間をどこに残すかを分けます。Web業務でも、ページ内容を読んで改善案を作るread-onlyと、公開ページを変更するwriteを同じ権限にしない方が安全です。なお、これはGeminiとWixが現在native連携しているという意味ではありません。Wixは「外部Web業務へAIを接続するとき、readとwriteをどう分けるか」という設計例として挙げています。Gemini→Wix native integrationを確認済みとする表現は避けます。

業務別ケース1：顧客情報・CRM

CRMとAIを接続する場合、最初から「顧客対応を全部自動化」するのではなく、まずread-onlyで顧客情報を取得し、社内向けの返信下書きまでに限定する方法があります。人間が内容を確認し、送信だけは別権限に残します。ここで安定したら、条件の明確な定型処理だけ次の自動化候補にします。

この順番なら、誤送信や顧客情報の取り違えが起きても外部影響を抑えられます。MCPを導入する価値は「最初から全部自動化できる」ことではなく、tool単位で仕事を分解して接続できることにあります。

業務別ケース2：社内資料・ナレッジ

社内ドキュメントをAIへ接続する用途は、writeよりreadの価値が先に出やすい領域です。最新版の規程、商品情報、FAQなどを読ませ、回答や要約を返すだけなら比較的境界を作りやすい一方、古い資料と新しい資料が混在していればAIは正本を判断できません。MCP導入前に「どの資料が正本か」を決める必要があります。

つまりAI接続の問題に見えて、実際には文書管理の問題が先にあるケースです。ツールをつなぐ前に情報の所在・更新者・有効期限を決めると、AIの回答品質も安定します。

業務別ケース3：Web・コンテンツ運用

Web運用では、AIが記事やページを読み、改善案を返す工程、下書きを作る工程、CMSへ保存する工程、公開する工程を分けます。最初の二つはread-only中心で試しやすく、CMS保存は限定write、公開はHuman Gateという分け方ができます。

AIが文章を作れるからといって、公開権限まで同時に与える必要はありません。むしろ制作と公開を分けることで、AIの速度を活かしながら誤公開を防げます。MCPの価値を「自動公開」だけで評価せず、工程をつなぐ共通接続として捉える方が実務的です。

業務別ケース4：開発・GitHub・社内システム

開発系では、リポジトリを読む、差分案を作る、テストする、commitする、mainへmergeする、deployする、という複数の権限があります。AIエージェントだからといって全工程を同じ権限で渡す必要はありません。検証環境のworktreeだけwrite可、main・productionはHuman Gate、という分離もできます。

この考え方はGemini Spark固有ではなく、外部toolを使うAIエージェント全般に共通します。MCPを学ぶ価値は特定モデルの操作方法より、AIとtoolの境界をどう設計するかを理解する点にあります。

接続前に確認する10項目

対象サービスは現在、自社の地域・言語・アカウント種別で利用可能か
接続するMCP serverの運営元を確認できるか
AIが読めるデータ範囲を一覧化できているか
writeできるtoolを限定しているか
write前のHuman Gateをどこへ置くか決めているか
credentialの保持場所と更新担当が決まっているか
操作ログや承認記録を後から確認できるか
異常時に接続を止める手順があるか
接続解除後のデータ取り扱いを確認したか
本当にAIへ接続する必要がある業務か

10番目は特に重要です。単純な文章要約であればMCP接続は不要です。AIにtoolを増やせば増やすほど良いわけではありません。外部接続は便利さと同時に攻撃面・誤操作面も増やすため、goalに不可欠なtoolだけを追加します。

日本企業が今できること

自社業務を「読む仕事」と「書く仕事」に分ける
AIに任せたい業務を1つだけ選ぶ
人間承認が必要な操作を整理する
外部公開・顧客送信・削除などのHard Gateを決める
現在使えるAIツールでread-onlyのPoCを行う
MCPを導入するとしたら何を接続するか棚卸しする

日本未提供だから何もできないわけではありません。むしろ今の段階では、特定製品へ依存しない業務設計を作る好機です。どのAIを使っても必要になるread / write / approval / stopを整理しておけば、Sparkが日本提供された時にも比較的短く検証へ入れます。

まだやらない方がよいこと

日本未提供のSparkを前提に本番業務を組む
custom MCPありきで既存業務を全面再設計する
third-party MCP serverへ社内情報を安易に接続する
Google Workspaceでcustom appsが使える前提で予算化する
日本提供時期を予想して大規模開発を先行する

将来使える可能性がある技術でも、利用条件が揃う前に本番基盤を作ると手戻りが増えます。今は「Spark専用実装」ではなく「AIに外部仕事を任せるための共通ルール」を作る方が再利用性があります。

導入準備を3段階に分ける

段階1：業務を1つ選び、read-onlyで考える

最初から複数アプリをつなげず、毎週繰り返す定型業務を1つだけ選びます。まずはAIが情報を読む、整理する、下書きを返すところまでを想定し、外部状態を変えない構成で価値が出るかを見ます。この段階で価値がなければwriteを追加する理由もありません。

段階2：限定writeとHuman Gateを設計する

read-onlyで価値が確認できたら、必要なwriteを1つだけ追加します。下書き保存、社内DBへの一時登録など、失敗しても復旧しやすい操作から始めます。公開・送信・削除・契約などはHuman Gateへ残します。

段階3：ログと停止条件を実測する

AIが何回成功したかだけではなく、どんな失敗が起きたか、何回人間へ戻ったか、誤ったtoolを選びそうになったかを記録します。失敗の種類が分かれば、権限を増やす前にjob設計や入力情報を改善できます。実運用へ進むのは、停止・復旧・人間引継ぎまで確認してからです。

日本で使えないなら今知る意味はない？

「日本でまだ使えないなら、提供開始後に調べれば十分ではないか」という反論は半分正しいです。今すぐSpark専用システムを作る必要はありません。未提供機能のために大規模開発費を使う合理性も低いです。新機能の操作方法だけを覚えるなら、提供後でも遅くありません。

ただしConnected AppsとMCPの本質である権限設計はGemini Sparkだけの話ではありません。AIが外部toolを使うときには、どのサービスでもread / write / human approval / stopが必要です。今学ぶ価値があるのはSparkのボタン操作ではなく、AIへ外部業務を任せる管理方法です。

この考え方を先に整えておけば、日本提供が始まったときにも「新機能だから全部試す」のではなく、自社に必要なtoolだけ選べます。逆に境界がない会社は、便利な接続先が増えるほど、誰が何を操作できるか分からなくなります。

将来的に向く会社 / まだ待つ会社

将来的に相性が良い会社

複数のSaaSを日常業務で使っている
定型的な情報取得・登録作業が多い
APIや権限管理を担当できる人がいる
人間承認を含む業務フローを設計できる
AI活用を単発プロンプトではなく業務プロセスとして考えている

現時点では待った方がよい会社

通常チャット活用を始めたばかり
何を自動化したいか決まっていない
顧客情報や社内データのアクセス管理が整理されていない
AIの出力確認責任者が決まっていない

Connected AppsはAI導入の入口というより、ある程度業務と権限が整理された会社が次へ進むための機能と考える方が安全です。まず通常のAI活用で業務を定義し、その後に外部tool接続へ進む方が、技術に業務を合わせる手戻りを防げます。

FAQ

Q1. Gemini Sparkは現在、日本で使えますか？

2026年8月16日時点で確認したGoogle公式の展開情報では、日本はGemini Sparkの現在の提供対象から除外されています。提供状況は変わり得るため、導入時に再確認してください。

Q2. custom Connected Appsは会社のGoogle Workspaceアカウントで使えますか？

現行のGoogle公式条件では、custom appsはpersonal Google Accountが対象で、work / school Google Accountは現在サポートされていません。

Q3. MCP server URLを登録すれば安全に使えますか？

URLを登録できることと安全性は別です。Googleはthird-party MCP serverをcontrol / monitor / secureしないとしています。運営元、データ範囲、権限、ログ、停止手順を企業側で確認する必要があります。

Q4. AIが勝手に外部アプリを書き換えることはありますか？

Googleの現行仕様ではwrite actionにmanual confirmationが必要です。ただし企業導入ではGoogle側の確認機能だけに依存せず、自社の承認ルールも設計する方が安全です。

Q5. 日本企業は今、MCP導入を始めるべきですか？

Spark専用の本番導入を急ぐ段階ではありません。ただし対象業務をread/writeに分け、human approvalとstop条件を決める準備は今からできます。MCPという接続方式自体の学習や、read-only PoCは将来の手戻り削減につながります。

Q6. WixとGemini Sparkは直接つながりますか？

この記事ではGemini SparkとWixのnative direct integrationを確認していません。Wixは外部Web業務へAIを接続する場合の権限設計を説明する例としてのみ扱っています。

まとめ：日本で今やるべきは「導入」より「安全に使える設計」

Gemini SparkのConnected Appsとcustom MCPは、AI活用を「質問と回答」から「外部toolを使う仕事」へ広げる重要な仕組みです。しかし日本企業にとっての現在地を間違えてはいけません。日本は現時点でSparkの現在の提供対象外、custom appsには米国・個人アカウント・英語などの条件があり、third-party MCP serverはGoogle管理外、writeにはmanual confirmationが必要です。

したがって今の最適解は「とにかくMCPを導入する」ことではありません。自社のどの仕事をAIへ渡し、どこを人間に残し、どんな条件なら止めるかを決めることです。この設計ができていれば、日本提供が始まったときも新機能に振り回されず、必要な部分だけを導入できます。

法人AI導入・業務設計のご相談

HSビルでは、AIツールを増やすこと自体ではなく、「どの業務をAIに任せ、どこを人間承認に残すか」という業務設計から整理しています。AIエージェント、外部tool連携、MCPを含む法人AI活用を検討されている場合は、AIソリューションページから「法人AI導入・業務設計」をお選びください。

筆者プロフィール

筆者：HSビル AIメディア編集部

HSビル AIメディア編集部は、HSビル・ワーキングスペースのAI活用、SEO/AIO、Wix導線改善、LINE予約・相談導線、コワーキング・貸し会議室・バーチャルオフィス運営の実務経験をもとに、中小企業・個人事業主向けにAI活用と業務整理の記事を作成しています。

記事では、単なるAIツール紹介ではなく、実際の業務に落とし込むための役割分担、コスト管理、人間確認の範囲、相談導線まで含めて整理します。

代表者プロフィール補足：三宅悠生

FULMiRA Japan 合同会社代表。HSビル・ワーキングスペースを運営し、AIを単なるツールではなく、複数のAIを役割分担して成果へつなげる協働者として活用する方針を発信しています。公式サイトの代表メッセージおよび会社案内でも、代表者名と運営会社情報が確認できます。

案内役：朝比奈エリカ先生（HSビル AI実務ナビゲーター）

AI実務講座系の記事では、初心者にも分かりやすく解説する案内役として朝比奈エリカ先生が登場する場合があります。エリカ先生は本文内の案内役であり、構造化データ上の著者ではありません。