Gemini Enterpriseで社内データを横断検索させる時に、2026年7月の更新で最優先になったのは「どのコネクタを許すか」と「どの宛先ドメインまで通信を許すか」を分けて管理できるようになった点です。2026年7月7日に Google は allowed data sources と allowed egress FQDNs をGAにし、7月6日には Japanリージョン（asia-northeast1）もGA with allowlistになりました。
まず押さえる結論
今回の変更は、Gemini Enterpriseのコネクタ運用を「接続先の種類」と「通信先のFQDN」に分けて管理しやすくしたものです。Google DriveやGmailのような well-known source は allowed data sources 側で許可すると既知のFQDNが自動で許可されます。一方で、JiraやCustom MCPのような接続先は、必要に応じて egress FQDN を明示しないと作成段階で止まります。
そのため、導入担当者は「どのSaaSを使わせるか」だけでなく、「そのSaaSに到達する通信先をどう制限するか」まで一緒に決める必要があります。ここを曖昧にすると、PoCではつながるのに本番のVPC Service Controls配下では作れない、という事故が起きやすくなります。
7月7日にGAになった2つの制御
Google CloudのGemini Enterprise release notesによると、2026年7月7日にGAになったのは 1) Restrict allowed data sources と 2) Restrict allowed egress FQDNs です。前者は Jira、Box、Confluence のような外部データソースの種類を、後者はデータストアが接続できる宛先FQDNを制御します。
Googleの managed policy constraints overview では、この2つは別物ですが相互に影響すると整理されています。特に Google Drive や Gmail のような許可済みGoogleソースは well-known FQDN が自動許可される一方、サードパーティや custom_mcp は FQDN を別途足す場面があります。
allowed data sourcesで先に決めること
最初に決めるべきなのは、従業員にどのコネクタを開放するかです。例えば社内ファイルの横断検索だけが目的なら Google Drive、Gmail、Google Chat までに絞る設計でも十分です。逆にJiraやConfluenceまで開けると、回答精度は上がりやすい一方で、公開範囲や管理コストも増えます。
VPCSCが有効なプロジェクト、または enforcedProjects に入ったプロジェクトでは、allowedDataSources に対象ソースが入っていないとプロビジョニングがブロックされます。つまり、まずは業務上必要なソースを絞り、その後に申請ベースで追加していく運用の方が安全です。
egress FQDNで詰まりやすいポイント
allowedEgressFqdns は、データストア作成時にどのFQDNへ通信できるかを制御します。Googleのドキュメントでは、instance URL、authorization URL、token URL から必要なドメインを抜き出して許可する想定です。例えば authorization URL が https://api.cymbal.com/oauth/authorize の場合、allowlist に必要なのは api.cymbal.com です。
設定作業自体は Organization Policies で discoveryengine.managed.allowedEgressFqdns を編集し、必要に応じて enforcedProjects を指定します。検証時は data store 作成を試し、Operation denied by org policy が消えているかで確認できます。
Japanリージョン対応で確認したいこと
2026年7月6日の release notes では、Gemini Enterprise app が Japan（asia-northeast1）と UK（europe-west2）で GA with allowlist になりました。Googleは、このリージョンで at-rest data residency と machine learning processing in region を使えると案内しています。
ただし、この地域対応は allowlist 前提で、Google account team への連絡が必要です。導入前に、対象エディション、接続予定コネクタ、社内のデータ所在ポリシー、PoC環境と本番環境のリージョン差分を一覧化しておくと判断が速くなります。
導入時の実務チェックリスト
実務では、次の順で詰めると失敗しにくくなります。1つ目は対象業務ごとに必要なデータソースを洗い出すこと。2つ目は Google系だけで足りる部署と、外部SaaSが必要な部署を分けること。3つ目は VPCSC と enforcedProjects の対象を確認し、どこで制約が効くかを明文化すること。4つ目は third-party source ごとに必要FQDNを整理すること。5つ目は data store 作成時のエラー確認手順まで含めて運用手順書に落とすことです。
特に、Google Driveは許可したのに custom_mcp や self-hosted connector は別対応だと理解していないと、本番移行でつまずきます。Googleの例でも、Custom MCP をVPCSC配下で使うには custom_mcp の許可に加えて api.cymbal.com のようなFQDNも足す必要があると説明されています。
社内展開前に見直したい運用ルール
おすすめは、コネクタ追加を自由化する前に「申請時に必要な情報」を固定することです。最低でも、利用目的、接続先サービス名、必要なFQDN、扱うデータの機密度、リージョン要件、テスト担当者を申請項目に入れておくと、セキュリティと情シスの往復が減ります。コネクタは増やすほど便利になりますが、Gemini Enterpriseの強みは“全部つなぐこと”ではなく“必要な接続だけを安全に許可できること”です。
まとめ
Gemini Enterpriseの2026年7月更新は、コネクタ運用を本格導入フェーズへ進めるための管理機能強化と見てよさそうです。これから導入するなら、まず接続先を絞り、次に必要なFQDNを定義し、最後にVPCSCとリージョン要件を合わせて確認する順番がおすすめです。
Gemini Enterpriseや社内コネクタ運用の設計を相談したい場合は、 お問い合わせください 。要件整理から接続範囲、権限制御、PoC設計まで伴走できます。
