「業務端末から個人のGmailにログインしてファイルを持ち出せてしまう」— Google Workspaceを導入した組織が最初に指摘されるリスクがこれです。これを塞ぐのがドメイン制限（テナント制限）で、実装方式は大きく3つあります。
プロキシでHTTPヘッダーを付与する方式は網羅性が最も高い代わりにネットワーク投資が必要、Chromeのポリシーで制限する方式はコストが低く柔軟だがChromeブラウザ以外は別途塞ぐ必要がある、ChromeOSのデバイス設定は端末をChromebookに寄せられる組織なら最も素直です。
どの方式を選ぶにせよ、gserviceaccounts.com を許可リストに含め忘れると業務が止まります。この一点だけでも押さえて帰ってください。
ドメイン制限とは何を止める仕組みか
Google Workspaceのユーザーは、同じブラウザから複数のGoogleアカウントにサインインできます。会社のアカウント（例：user@abc.com）でログインしたまま、個人のGmailアカウントや、取引先から発行された別テナントのアカウントを追加できてしまう、ということです。
この状態で起きうるのが次の3つです。
- 会社のGoogleドライブから個人のGoogleドライブへファイルをコピーする
- 会社のメールを個人Gmailに転送・保存する
- 他社テナントのアカウントで、会社端末上に業務外のデータを持ち込む
ドメイン制限は、「この端末／このネットワークからは、許可したドメインのGoogleアカウントにしかサインインできない」という制御をかける仕組みです。自治体や金融機関の調達では「Only my tenancy」という言い方で要件化されることもあります。
許可されていないアカウントでサインインを試みると、ユーザーには「このアカウントはこのネットワーク内でサインインできません」という趣旨のエラーが表示され、管理者に問い合わせるよう案内されます。
3つの実装方式の全体像
| 観点 | 方式1：プロキシ | 方式2：Chromeポリシー | 方式3：ChromeOSデバイス設定 |
|---|---|---|---|
| 制御の網羅性 | 高い（ブラウザを問わない） | Chromeブラウザのみ | ChromeOS端末上で確実 |
| ユーザー体験 | プロキシ経由による遅延・不安定化のリスク | ダイレクト アクセスのため劣化しない | 劣化しない |
| ネットワーク投資 | プロキシ／VPNの構築・維持が必要 | 不要 | 不要 |
| リモートワークとの相性 | 制約が出やすい | 良い | 良い |
| BYODへの適用 | プロキシ設定の強制が難しい | 管理対象ブラウザの登録が前提 | 該当しない |
| 主な追加作業 | SSLインターセプトと内部CA配布 | Chrome以外のブラウザを別途ブロック | 端末をChromeOSに寄せる判断 |
3方式は排他ではありません。実務では「Chromeポリシー＋Chrome以外のブラウザの遮断」を主軸に、ChromeOS端末には方式3を重ねる構成が最もコスト効率が良く、プロキシ方式は既にSSLインターセプト可能なプロキシが導入済みの組織で選ばれます。
業務端末からの個人アカウント利用や他社テナントへのログインの統制は、設計と運用の両方が必要です。情シス365でご支援しています。
情シス365を見る →Google Workspace導入コンサルティング方式1：プロキシでX-GoogApps-Allowed-Domainsを付与する
Google公式ヘルプ「Block access to consumer accounts」が説明している、最も網羅性の高い方式です。
仕組み
Googleサービス宛のHTTPリクエストに、許可ドメインを列挙したヘッダーを付与します。書式はカンマ区切りです。
` X-GoogApps-Allowed-Domains: mydomain1.com, mydomain2.com `
このヘッダーが付いたリクエストでは、列挙されていないドメインのGoogleアカウントでのサインインが拒否されます。ブラウザの種類に依存しないため、ChromeでもEdgeでもSafariでも同じ制御が効きます。これが最大の利点です。
実装上の前提
公式ヘルプは次の2点を明記しています。
*.google.com宛のすべての通信をプロキシ経由にすること- Googleサービス宛の通信のほとんどは暗号化されているため、プロキシがSSLインターセプトをサポートしている必要があること
SSLインターセプトを行うには、社内のRoot CA証明書を全端末に配布する必要があります。既にSSLインターセプト前提のプロキシを運用している組織なら追加コストは小さいですが、そうでない場合は「ドメイン制限のためにプロキシ基盤を作る」ことになり、投資判断が必要になります。加えてセンター拠点にトラフィックが集中する構成になるため、全業務がクラウド上で完結する環境では帯域設計の見直しが伴います。リモートワークでは端末をVPNでセンターに引き戻すか、クラウド プロキシを併用するかの判断も必要です。
この方式が向くのは、既にSSLインターセプト可能なプロキシを運用している組織、Chrome以外のブラウザの利用を業務上止められない組織、ネットワーク境界での一元制御を監査要件として求められている組織です。
方式2：Chromeのポリシーで制限する
ネットワークに手を入れずに実装できる方式です。Google管理コンソールからChromeブラウザにポリシーを配布します。
設定するポリシー
① ログインの制限（Restrict sign-in to pattern）
Chromeのプライマリ アカウントとして設定できるGoogleアカウントを、正規表現で制限します。公式ドキュメントの例は次のとおりです。
` .*@example\.com `
ドットをエスケープする点（\.）に注意してください。パターンに一致しないアカウントをプライマリ アカウントとして設定しようとすると、エラーが表示されます。
重要な制約として、このポリシーは公式に 「Chrome browser for Windows, Mac, and Linuxで利用可能」 と記載されています。ChromeOS・Android・iOSはこのポリシーの対象外です。モバイルの扱いは後述します。
② シークレット モードの無効化（Incognito mode）
シークレット モードは、管理コンソールの「デバイス > Chrome > ユーザーとブラウザの設定」から「シークレット モードを無効にする」を選択して塞ぎます。このポリシーはAndroid・ChromeOS・iOS・Windows／Mac／Linuxのすべてに対応しています。
注意点が2つあります。ひとつは、すでに開いているシークレット ウィンドウは閉じられないこと。もうひとつは、「シークレット モードを強制」はAndroidでは利用できないことです。
なお、K-12教育機関ドメインではシークレット モードがデフォルトで無効、それ以外のドメインではデフォルトで有効です。
ポリシーを確実に届けるために
Chromeのユーザー単位ポリシーは、ユーザーがChromeにサインインして同期することで適用されます。管理者側で「Chromeへのサインインを強制する」設定を併用することで、管理コンソールのポリシーが確実に端末へ届く状態を作れます。
会社支給端末ではGPOやデバイス管理でポリシーを配布し、BYODや非ドメイン参加端末ではChrome Enterprise Core（無償）でブラウザを登録して管理対象ブラウザとして扱う、という切り分けになります。
方式3：ChromeOSのデバイス設定で制限する
Chromebookを業務端末として採用している場合、ChromeOSのデバイス設定でログインできるアカウントを制限できます。管理コンソールの「デバイス > Chrome > 設定 > ユーザー エクスペリエンス > セカンダリ アカウントへのログイン」で、許可するドメインを指定します。
この設定では、後述する consumer_accounts や gserviceaccounts.com といった特殊な値をプロキシ ヘッダーと同じ形式で指定できます。端末そのものがGoogleの管理下にあるため、ブラウザの入れ替えや設定の回避という抜け道が構造的に存在しないのが強みです。
「無害化端末」「データレス端末」としてChromeOSを採用する設計では、ドメイン制限もこの層で完結させるのが最もシンプルです。
忘れやすい設定値：gserviceaccounts.comとシークレットモード
特殊な許可値
許可リストには、ドメイン名以外に次の値を指定できます。この存在を知らずに自社ドメインだけを列挙すると、業務が止まります。
| 値 | 意味 |
|---|---|
gserviceaccounts.com | 認証済みサービス アカウント。含めることが重要と公式に明記されています |
consumer_accounts | 個人のGmailなど消費者向けアカウントを許可する場合に追加 |
visitor_accounts | Googleアカウントを持たない相手との共同編集を許可する場合に追加 |
in_domain_visitor_accounts | 同上（自社ドメイン内のビジター アカウント向け） |
とくに gserviceaccounts.com の指定漏れは、Apps Script、AppSheet、外部SaaSとのAPI連携、監査ログのBigQueryエクスポートといった、サービス アカウントを使う仕組みを一斉に壊します。しかも「ドメイン制限を入れた翌日から一部の自動処理だけが動かない」という形で表面化するため、原因究明に時間がかかりがちです。設計時点でチェックリストに入れてください。
シークレット モードの扱い
当社の実装経験では、シークレット モードを開いたままにしておくとドメイン制限の運用に穴が残るため、あわせて無効化することを標準としています。ただし「ドメイン制限がシークレット モードで回避される」という因果関係を明記したGoogle公式の記述は確認できていません。公式の根拠がある制御（ログイン制限）と、運用上の推奨（シークレット モードの無効化）は分けて説明するのが、監査対応上は安全です。
Chrome以外のブラウザとモバイルをどう塞ぐか
Windows：Edge / Internet Explorer
ChromeのポリシーはChromeにしか効きません。したがって方式2を採る場合、Chrome以外のブラウザからのアクセスを別途遮断する必要があります。
Windowsデバイス管理を有効にした端末であれば、Google管理コンソールのカスタム設定からポリシーを配布できます。手順は「デバイス > モバイルとエンドポイント > 設定 > Windows > カスタム設定」で、入力項目は次の4つです。
| 項目 | 内容 |
|---|---|
| Name | 設定を識別するための一意の名前 |
| OMA-URI | 設定パス（オートコンプリートで検索可能） |
| Data type | OMA-URIに応じて自動設定 |
| Value | 設定したい値 |
ここでWindows Defender Firewallのルール（./Vendor/MSFT/Firewall/MdmStore/FirewallRules/...）を配布し、msedge.exe や iexplore.exe のアウトバウンド通信をブロックする、という応用が可能です。
ただし正確に言うと、このファイアウォール ルールの記述はMicrosoftのFirewall CSPの仕様であり、Google公式ヘルプの「よく使うカスタム設定」に掲載されている例ではありません。Google側も「Microsoftがこれらの設定の挙動を変更する可能性がある」と注記しています。「Googleが推奨する設定例」としてではなく、「MicrosoftのCSP仕様をGoogleのカスタム設定機能経由で適用する応用」として扱ってください。
モバイル（iOS / Android）
前述のとおり、Chromeの「ログインの制限」ポリシーは公式にWindows／Mac／Linux対象です。モバイルでは次のように整理します。
- iOS：Safariを含むブラウザ側での制御は期待できません。Googleエンドポイント管理（高度なモバイル管理）でマネージド アプリを構成し、管理対象アプリ以外へのコピーや端末へのローカル保存を禁止する方向で塞ぐのが現実的です。Apple Push証明書の作成とGoogle Device Policyアプリの配布が前提になります。
- Android：仕事用プロファイルでアプリとデータを分離し、個人プロファイルへのコピー・共有を禁止する設定を組み合わせます。なおAndroid版Chromeへの管理構成によるドメイン制限は、公式ポリシー名の特定に至っていないため、要件化する場合は事前検証を推奨します。
つまりモバイルは「ブラウザでログインを止める」のではなく、「業務データが個人領域に出ないようにする」という別のアプローチで要件を満たすことになります。要件定義の段階でこの違いを説明しておかないと、後工程で「iPhoneで個人Gmailにログインできてしまう」という指摘を受けます。
できないこと・向かないこと
- すでにログイン済みのセッションがどう扱われるかについて、公式の明記は確認できていません。展開時は既存セッションのサインアウトを含む切替手順を設計してください。
- Chromeポリシー方式はChrome以外を制御できません。 「ブラウザは自由に使わせたい」要件とは両立しません。
- プロキシ方式はリモートワークと相性が悪い傾向があります。全通信をセンターに引き戻す構成は、クラウド前提の働き方の利点を打ち消します。
- ドメイン制限は情報持ち出しの全体対策ではありません。 USB、印刷、スクリーンショット、私物端末での撮影といった経路は別途、DLPやデバイス管理で塞ぐ必要があります。
どの方式を選ぶか
判断は次の3問で概ね決まります。① Chrome以外のブラウザを業務で使う必要があるか。 必要なら方式1、または方式2 ＋ ファイアウォールでの遮断。② SSLインターセプト可能なプロキシを既に持っているか。 持っているなら方式1の追加コストは小さく、持っていないならドメイン制限のためだけの投資になるため方式2を優先。③ 端末をChromeOSに寄せられるか。 寄せられるなら方式3が最もシンプルで、抜け道も構造的に少なくなります。
なおBYODが含まれる場合は、方式にかかわらずエンドポイント管理と組み合わせないと完成しません。ブラウザだけを見ていても、私物端末の別ブラウザや別プロファイルという穴が残るためです。
よくある質問
ドメイン制限を入れると、社外の人とファイルを共同編集できなくなりますか。
許可リストに `visitor_accounts` や `in_domain_visitor_accounts` を追加することで、Googleアカウントを持たない相手との共同編集を許可できます。
複数のドメインを持っている場合はどう書きますか。
`X-GoogApps-Allowed-Domains: mydomain1.com, mydomain2.com` のようにカンマ区切りで列挙します。セカンダリ ドメインも忘れずに含めてください。
Apps Scriptや外部SaaS連携が動かなくなりました。
許可リストに `gserviceaccounts.com` が含まれているか確認してください。サービス アカウントによる認証が必要な仕組みは、この値がないと動作しません。
個人のGmailを許可したい部署だけ例外にできますか。
Chromeのポリシーは組織部門単位で設定できるため、組織部門を分けて例外を作ることが可能です。プロキシ方式の場合は、ネットワーク側でセグメントを分ける設計になります。
iPhoneからは制御できないのですか。
ブラウザ側でのログイン制限は期待できません。Googleエンドポイント管理の高度なモバイル管理でマネージド アプリを構成し、業務データの持ち出しを止める方向で設計します。
Chrome Enterprise Premiumがあれば不要ですか。
目的が異なります。ドメイン制限は「どのアカウントでサインインできるか」の制御、Chrome Enterprise Premiumは「ブラウザを通る操作をどう統制するか」の製品です。併用が自然です。
まとめ
- ドメイン制限（テナント制限）は、プロキシでのヘッダー付与／Chromeポリシー／ChromeOSのデバイス設定の3方式で実装できます。
- 網羅性を最優先するならプロキシ方式ですが、SSLインターセプトと帯域設計の負担が伴います。コスト効率では Chromeポリシー＋Chrome以外のブラウザ遮断が現実解です。
- Chromeの「ログインの制限」ポリシーは公式に Windows／Mac／Linux対象です。モバイルはエンドポイント管理側で「データを個人領域に出さない」アプローチに切り替えます。
gserviceaccounts.comの指定漏れは、API連携やApps Scriptを静かに壊します。設計時のチェックリストに必ず入れてください。
自治体・金融機関の調達で求められる「Only my tenancy」要件の設計と実装、既存プロキシ環境での適用可否の判断については、当社でも支援を行っています。