お疲れ様です。SKYこと関谷です。
今回は、久々に専門の一つである Chrome 分野について、意外に意識されていない部分について記載してみたいと思います。
Google が無償で提供している Chrome Enterprise Core (Chrome Enterprise Premium ではありませんよ)ってご存知でしょうか？
ひとことで言うと 「全社の Chrome ブラウザをクラウドの管理コンソールから一元管理できるツール」 です。
Windows / Mac / Linux といった PC 上の Chrome ブラウザに対して、ポリシーの配信、拡張機能の制御、脆弱な古いバージョンの検出まで、無償でかなりのことができます。
ところが、いざ Chrome Enterprise Core を使い始めると、ほぼ全員が最初にぶつかる壁があります。
「管理されたブラウザ」と「管理されたユーザー（プロファイル）」って、何が違うの?
という問いです。
実はこの 2 つは、Chrome Enterprise Core を支える 2 大コンセプトであり、ここを理解しないまま設計を進めると、
- セキュリティに穴ができる
- 逆に従業員のプライバシーを侵害してしまう
- ポリシーの優先順位を読み違えてポリシーが効かない
といったトラブルに直結します。
本記事では、この 4 つの状態（管理されたブラウザ／管理されていないブラウザ／管理されたユーザー／管理されていないユーザー） を、初心者の方でも理解できるように、図解付きで整理していきたいと思います。
第 1 章：はじめに
1.1 Chrome Enterprise Core とは
まずは前提となる Chrome Enterprise Core の概要を、ごく簡単に整理しておきます。
Chrome Enterprise Core の特徴
- 無償で利用可能
- Windows / Mac / Linux の Chrome ブラウザを、クラウドからまとめて管理できる
- クラウドの Google 管理コンソールから、Chrome のポリシー・拡張機能・アプリを 一元管理
- 専用のエンタープライズブラウザを別途配るのではなく、社員がいつも使っている Chrome をそのまま管理対象にする
これだけだと「便利なブラウザ管理ツール」に聞こえますが、実装上の特徴的な設計が 1 つあります。
それが、
「ブラウザそのもの（=ソフトウェア）」と「ユーザーのアカウント（=アイデンティティ）」を、別々に管理できる
という設計思想です。
このため、Chrome Enterprise Core では、
-
管理されたブラウザ（Managed Browser）
ブラウザというソフトウェアを丸ごと組織の管理下に置く -
管理されたユーザー / 管理されたプロファイル（Managed Profile）
ユーザーがサインインしている「プロファイル」だけを管理下に置く
という 2 つの管理モードが用意されています。
本記事のテーマは、まさにこの 2 つのモード（と、それぞれが管理されていない状態）の違いを正しく理解する、というところにあります。
1.2 なぜ「ブラウザの管理」が重要なのか
そもそも、なぜ Google は Chrome のブラウザ管理にここまで投資しているのか。背景を一言だけ補足します。
最近の企業 IT 環境は、ここ数年で大きく変わってきました。
- 以前は PC にインストールするデスクトップアプリが中心
- 今は Google Workspace、Salesforce、Microsoft 365、Slack、ChatGPT など、ほぼすべてブラウザで動くクラウドサービス
つまり、業務データが流れる「最前線」がブラウザに移ってきている、ということです。
これに伴って、企業のセキュリティ境界も、
- 旧：ファイアウォール／VPN（社内ネットワークの境界）
- 新：ブラウザそのもの
という発想に変わってきています。Chrome Enterprise Core は、このブラウザ境界をクラウドから守るための基盤、と位置付けると分かりやすいです。
1.3 本記事の目標
本記事を読み終えるころには、以下が整理された状態になっていることを目指します。
- **「管理されたブラウザ」と「管理されたプロファイル」**の違いが分かる
- 4 つの組み合わせシナリオのどれを採用すべきか判断できる
- ポリシーの優先順位と「アフィリエーション」の罠を理解できる
- BYOD 時に 従業員のプライバシーがどこまで守られるか を説明できる
それでは始めましょう。
第 2 章：管理の対象は「ブラウザ」と「ユーザー」の 2 つ
第 1 章でお伝えしたとおり、Chrome Enterprise Core は 「ブラウザ」と「ユーザー」を別々に管理できる設計になっています。本章では、その 4 つの構成要素を 1 つずつ丁寧に定義していきます。
ポイントは、ブラウザとユーザーがそれぞれ独立に「管理する／しない」を選べるため、組み合わせで 4 通りの状態が発生する、というところです。
2.1 管理されていないブラウザ（Unmanaged Browser）
PC に Chrome をインストールしただけ、何も追加設定していない状態です。
- 企業の 登録トークン が入っていない
- IT 管理者からは、そもそもブラウザの存在自体が見えない
家で個人が使っている Chrome と同じ状態、と思ってください。
2.2 管理されていないユーザー（Unmanaged User）
ブラウザに、
- 個人の
@gmail.comでサインインしている - または何もサインインしていない（ゲスト・シークレットモード）
状態です。組織が発行した Google Workspace / Cloud Identity のアカウントではないので、「ユーザー（プロファイル）に向けた会社のポリシー」は届きません。
2.3 管理されたユーザー / 管理されたプロファイル（Managed Profile）
ここが今回の主役のひとつです。
ユーザーが、組織発行の Google Workspace / Cloud Identity アカウント（例: user@company.com）で Chrome にサインインしている状態です。
- サインインすると、そのアカウント専用の 「プロファイル」 が作られる
- 管理者は、このプロファイルの中だけ にポリシーを配信できる
- どの PC からサインインしても、同じ業務環境が追従してくる
ポイントは、管理範囲が「プロファイル単位」に限定される ということです。
2.4 管理されたブラウザ（Managed Browser）
もう一方の主役です。
組織が発行した 登録トークン（Enrollment Token） を、PC 上の Chrome に展開した状態です。
- ユーザーがサインインしているかどうかは関係ない
- ブラウザに入れたすべてのプロファイル、ゲストモード、シークレットモードまで、ポリシーの適用対象・レポートの対象になる
- 主に 会社支給 PC（コーポレートデバイス）で使う
つまり、管理スコープが「ブラウザまるごと」になる ということです。
2.5 図で整理
ここまでの話を、図で整理します。
管理されたプロファイル vs 管理されたブラウザ（制御スコープの違い）
- 左（管理されたプロファイル） ：管理・レポートの対象は「業務プロファイル」だけ。個人プロファイルやゲストはノータッチ。
- 右（管理されたブラウザ） ：個人プロファイルやシークレットモードを含む、ブラウザ全体がポリシー適用とレポートの対象になる。
2.6 違いが一目で分かる比較表
| 比較次元 | 管理されたプロファイル | 管理されたブラウザ |
|---|---|---|
| 主なユースケース | BYOD、私物 PC からの安全アクセス | 会社支給 PC、キオスク端末 |
| 管理適用のトリガー | 組織アカウントでサインイン | デバイスへ登録トークンを展開 |
| サインインの必要性 | 必須（サインイン中だけ有効） | 不要（常に有効） |
| 管理の及ぶ範囲 | 企業アカウントのプロファイルのみ | すべてのプロファイル＋ゲスト＋シークレット |
| 個人プロファイルへの扱い | 完全に分離・対象外 | ポリシー適用とレポートの対象 |
| IT 管理者のレポート範囲 | 業務プロファイル内の利用状況 | ブラウザ全体の利用状況・デバイス情報 |
| 主なメリット | プライバシー保護、リモートワーク促進 | デバイスレベルの厳格な統制 |
第 3 章：4 つの組み合わせシナリオ
「ブラウザの管理有無」と「ユーザーの管理有無」を掛け合わせると、現場で起きる状況は以下の 4 つに分類できます。
4 つのシナリオ早見表
縦軸が「ユーザーの管理状態」、横軸が「ブラウザの管理状態」です。
それぞれを順に見ていきましょう。
3.1 シナリオ 1：管理されたブラウザ × 管理されたユーザー（推奨構成）
会社支給 PC で、社員が企業アカウントでサインインして使うケースです。
- ハードウェア寄りの強い制限（拡張機能ブロック・ローカル保存禁止など）を ブラウザ全体に適用
- 同時に、プロファイル単位で 部門別の柔軟な設定（営業向けブックマーク自動配信など）を配信
セキュリティと運用柔軟性のバランスが取れた、もっとも推奨される構成です。
RestrictSigninToPattern や BrowserSignin、RestrictAccountsToPatterns を組み合わせれば、「会社の承認したドメイン以外ではそもそもサインインできない」という強力な統制も可能です。
3.2 シナリオ 2：管理されたブラウザ × 管理されていないユーザー
会社の共用端末・キオスク端末などのケースです。
ユーザーが個人アカウントでログインしようと、ゲストモードで使おうと、
- ブラウザ自体に管理ポリシーが効いている
- 拡張機能の追加禁止、閉じたら履歴・キャッシュを自動削除、なども可能
「誰が使っても安全」 な状態を作れます。小売店の接客端末、学校の図書室共用 PC などで非常に有効です。
3.3 シナリオ 3：管理されていないブラウザ × 管理されたユーザー（BYOD）
社員の私物 PC に、会社プロファイルだけを追加するケースです。
ハイブリッドワーク／リモートワーク時代の、最重要シナリオです。
- 1 台の PC の中で、個人プロファイルと業務プロファイルが完全分離
- 業務プロファイル内だけ、必要なポリシー（必須拡張機能の自動配信、URL 制御、ブックマーク配布など）を強制
- 個人プロファイルに切り替えた瞬間、会社の制御は一切及ばない
「会社が私物 PC を覗いてるんじゃないか」というプライバシー懸念を、設計レベルで解消できるのが最大の強みです。
3.4 シナリオ 4：管理されていないブラウザ × 管理されていないユーザー
完全に企業管理スコープの外です。
ここで一番怖いのは、社員が無防備な経路から会社の SaaS にアクセスしてしまうこと。いわゆる「シャドー IT 的な経路」です。
これに対しては、
- Chrome Enterprise Premium（有償版）の高度なデータ保護
- コンテキストアウェアアクセス（Google Workspace の機能）
を使って、「管理されていないブラウザ／ユーザーからのアクセスは条件付きで遮断する」のが標準的な対策となります。
第 4 章：登録トークンの仕組み
「管理されたブラウザ」を実現する技術の中心が、登録トークン（Enrollment Token） です。
4.1 登録トークンとは
管理コンソールから発行される、組織を識別するための一意の文字列です。
トークンを PC に展開する方法は、
-
Windows：レジストリ（
HKEY_LOCAL_MACHINE配下）に書き込み -
Mac：構成プロファイル（
.mobileconfig） - Linux：管理ファイル
- MDM：Workspace ONE、Intune、Jamf などから一括配布
のいずれかです。
4.2 トークン発行から登録完了までの流れ
裏側では、管理コンソールと Google のブラウザ管理サービスがやり取りをして登録が進みます。全体像は次のとおりです。
登録トークンの展開シーケンス
ポイントは、
- エンドユーザーは何も操作不要（サイレント登録）
- トークンを OU（組織部門）ごとに分けて発行することで、登録と同時に部門別ポリシーが自動適用
ということです。
4.3 ChromeEnrollmentToken の主なプロパティ
ChromeEnrollmentToken は、Directory API でトークンを操作する際のリソース表現です。主な属性は以下のとおりです。
| プロパティ | 役割 |
|---|---|
kind |
リソースの種別（常に admin#directory#chromeEnrollmentToken） |
tokenId |
トークンの識別子 |
tokenPermanentId |
永続 ID。revoke（無効化）API のキー |
customerId |
顧客（テナント）の一意 ID |
orgUnitPath |
紐づく OU パス。ポリシーの継承元 |
state |
active / expired / revoked
|
expiration |
expireTime（特定日時）または ttl（存続期間） |
creatorId / creationTime
|
発行者と発行日時（監査用） |
revokerId / revokeTime
|
無効化者と無効化日時（監査用） |
tokenType |
現状は chromeBrowser のみ |
creatorId や revokerId などの監査属性が揃っているので、「いつ、誰が、どの OU 用にトークンを発行・無効化したか」を後から追跡可能です。
第 5 章：ポリシーの優先順位と「アフィリエーション」の理解
複数の管理経路（GPO、管理コンソール、AD など）が併存している場合、どのポリシーが勝つか を決めるのが「優先順位」です。
ここは Chrome Enterprise Core で もっとも誤解されやすいポイント なので、丁寧に見ていきます。
5.1 デフォルトの優先順位
デフォルトでは、上から順に強い、というシンプルなルールです。
ポリシー優先順位の階層
| 優先順位 | ポリシー種類 | 起点 | スコープ |
|---|---|---|---|
| 1（最強） | プラットフォーム | GPO / MDM | マシン全体 |
| 2 | マシンのクラウド | 管理コンソール | マシン全体 |
| 3 | OS ユーザー | GPO / MDM | OS アカウント |
| 4（最弱） | クラウド・ユーザー | 管理コンソール | Chrome プロファイル |
設計思想は単純で、
「ハードウェア所有者の意思」が「アカウントの意思」より常に勝つ
というエンタープライズ IT の鉄則を、そのまま体現したものです。
5.2 クロステナント（異なる管理コンソール管理）時の場合
ここが地味に重要です。
たとえばこういうシチュエーション。
- A 社支給 PC（A 社のマシンポリシーが効いている）
- 業務提携先 B 社のアカウントで、Chrome にサインインしてプロファイル作成
- B 社のユーザーポリシー（拡張機能を強制インストールせよ、など）が降りてくる
このとき、A 社マシンポリシーと B 社ユーザーポリシーが衝突します。Chrome の挙動は明確です。
- A 社（マシン管理者）が常に勝つ
- 異なる管理コンソール（テナント）から発行されたポリシー同士は、絶対にマージできない
これは、B 社が緩いポリシーや悪意ある拡張機能を「合法的に」A 社デバイスに送り込んで、A 社のデータを盗む ような経路を絶つための、システム設計レベルのフェイルセーフです。
5.3 優先順位の変更（オーバーライド）
同一組織内であれば、デフォルトの優先順位を変更できます。
-
CloudUserPolicyOverridesCloudMachinePolicy：ユーザークラウドポリシーが、マシンクラウドポリシーを上書き - 管理コンソールの「ポリシーの優先順位」設定で、4 階層の順序を入れ替え可能
たとえば「営業部門のユーザーがサインインしたときだけ、特定の制限を緩める」というアイデンティティ主導の運用が組めます。
5.4 【大切】アフィリエーション（Affiliation）
ここが本記事で 絶対に押さえてほしいポイント です。
ユーザークラウドポリシーがマシンクラウドポリシーを上書きできるのは、
Chrome プロファイルが、マシン管理テナントと「アフィリエート（affiliated）」している場合に限られます。
公式ドキュメントの原文（Google）はこう書かれています。
User cloud policies only take precedence if the associated Chrome profile is affiliated. If not, they follow the default order of precedence.
「アフィリエート」とは、マシンを管理しているテナントと、ユーザープロファイルを管理しているテナントが同一（または連携設定済） であることを指します。
アフィリエーション判定フロー
つまり、他社テナントのプロファイルがオーバーライドポリシーを使って自社マシンポリシーを書き換える、という攻撃経路はここで二重に塞がれている ということです。
オーバーライドを設定するときは、必ず「対象プロファイルがアフィリエート済みか」をチェックしましょう。
5.5 ポリシーのマージ
「片方が勝つ」ではなく、両方の設定をマージすることもできます。
ワイルドカード * を指定すれば、サポート対象のすべてをマージ可能です。
たとえば、
- GPO で「全社共通ブックマーク」を配信
- 管理コンソールで「部門別ブックマーク」を配信
これらを 両方とも ユーザーの画面に出す、といった運用ができます。
第 6 章：プライバシーの境界
組織ユーザーから最もよく聞かれる質問が次のようなものです。
「私の閲覧履歴とか、会社に見られてるんですか?」
回答は、「どの管理モデルか」によって正反対になります。
6.1 管理されたブラウザ：ブラウザ全体が管理スコープ
会社支給 PC（登録トークン展開済）の場合、
- 企業プロファイル
- 個人プロファイル
- ゲストモード／シークレットモード
これらすべてが、ポリシー適用とレポートの対象になります。
ここで誤解されやすいのが、「管理者が個人のパスワード本文や、見ているページの中身を自由に閲覧できる 」と思われてしまうことです。これは違います。管理コンソール上で把握できるのは、
- 訪問したサイトの URL（ポリシー違反時のイベントなど）
- インストールされている拡張機能の一覧
- Chrome のバージョンや適用中のポリシー
- （Chrome Enterprise Premium を追加適用して）DLP ルールに引っかかったコピー＆ペーストやアップロードの記録
といった 管理コンソールが定義する範囲のテレメトリです。とはいえ、シークレットモードや個人プロファイルでもポリシーは効いてしまうため、「会社支給 PC を私用で使う」のは原則 NG であることに変わりはありません。IT 部門は社員に、「個人利用は別の私物 PC で行う」というルールを明確に伝える必要があります。
6.2 BYOD + 管理されたプロファイル：プライバシーは厳格に守られる
私物 PC + 会社プロファイルの場合、
- 管理者が見られるのは 業務プロファイルの中だけ
- 個人プロファイルの履歴・ブックマーク・拡張機能は 完全に不可視
- 個人プロファイルにポリシーは 一切適用されない
つまり、「私物 PC で業務をする」場合は、業務プロファイルと個人プロファイルを分けて運用していれば、プライバシーは守られる、というのが設計上の保証になります。
6.3 レポート機能を有効化する手順
管理者がプロファイルのテレメトリを取得するためには、明示的なオプトインが必要です。
- Google 管理コンソールにログイン
- メニューから ［デバイス］ → ［Chrome］ → ［設定］
- 対象の組織部門を選択
- ［ブラウザレポート］ → ［管理対象プロファイル レポート］
- 「管理対象ユーザーの管理対象プロファイル レポートを有効にする」をオン
これで、
- インストール済み拡張機能の一覧
- Chrome のバージョン
- 適用中ポリシーのリスト
などが、クラウド上で一元的に把握できるようになります。「古いバージョンの Chrome を使い続けている社員」を一発で特定して、強制アップデートする、といった運用が可能です。
第 7 章：脅威への対策（拡張機能と生成 AI）
7.1 拡張機能の管理・統制
拡張機能の多くは「アクセスしたすべてのウェブサイトのデータを読み取り、変更する」 という強い権限を要求します。
悪意ある拡張機能が入ったら、SaaS の認証トークンや業務データが簡単に盗まれます。
Chrome Enterprise Core では、
- 拡張機能レポート：組織内で何が使われているか網羅
-
ExtensionInstallAllowlist/ExtensionInstallBlocklist：許可リスト方式 -
ExtensionSettings：きめ細かい挙動制御
を使って、許可リスト方式での運用が可能です。
7.2 生成 AI へのデータ流出防止
生成 AI などへ社員がソースコードや顧客情報をうっかりコピペする、という事故は、もはや日常茶飯事と考えられます。
選択肢としては、
- 専用エンタープライズブラウザ（Island、Talon、Seraphic、LayerX 等）の導入
- Chrome をそのまま使い、軽量なコントロールレイヤーを足す
の 2 つがありますが、ユーザー体験の変化（フリクション）を考えると、後者が現実解になることが多いです。
ここで、Core と Premium で 機能の境界線 を意識するのが大事です。
Chrome Enterprise Core（無償）でできること
- 生成 AI を含む URL へのアクセス制御（ブロック／許可リスト）
- 拡張機能の許可リスト方式での管理
- どのサイトにアクセスしているかの 可視化（レポート）
Chrome Enterprise Premium（有償）で追加できること
- 特定ドメインへの コピー＆ペースト・アップロード・印刷・ダウンロードの制御（DLP）
- コンテンツ検査（クレジットカード番号、機密ラベル等の検出）
- ファイルのマルウェアスキャンや URL のリアルタイム評価
- セキュリティイベントレポート（コンソールや SIEM への連携）
つまり、「アクセス制御や可視化までは Core で、コンテンツ検査を伴う DLP は Premium で」 という分担になっています。
第 8 章：アカウントのセットアップ
最後に、Chrome Enterprise Core を「これから始める」方向けの注意点です。
8.1 アカウントタイプの選び方
Chrome Enterprise Core のサインアップ時に、2 つのアカウントタイプから選びます。
| 比較項目 | メール検証済み | ドメイン検証済み |
|---|---|---|
| 初期費用 | 無料 | 無料 |
| 無料枠 | 最大 10 ユーザー | 最大 10 ユーザー |
| 追加ライセンスでの拡張 | 原則不可（拡張には DNS 検証への移行が必要） | 可能 |
| 管理者ロール | 特権管理者のみ | 特権管理者＋カスタムロール |
| グループベース管理 | 不可 | 可能 |
| プロファイルポリシー適用 | 限定的 | Win / Mac / Linux 全域に適用可 |
| サービス拡張 | 不可 | Workspace 等の追加契約可 |
8.2 大規模展開のベストプラクティス
- 登録トークンは、MDM や GPO で一括配布（手動投入は NG）
-
AllowedDomainsForAppsポリシーで、コンシューマー向け Google アカウントへのアクセスをブロック
まとめ
長くなりましたので、最後に重要ポイントをまとめます。
この記事の要点
- Chrome Enterprise Core は、「ブラウザの管理」と「ユーザーの管理」が完全に分離しているのが最大の特徴
- 「管理されたブラウザ」=ブラウザ全体を統制、 「管理されたプロファイル」=プロファイル単位で統制
- 推奨構成は シナリオ 1（管理ブラウザ × 管理ユーザー） 、BYOD では シナリオ 3（プロファイル分離） が威力を発揮
- ポリシー優先順位は 「マシン > ユーザー」が原則、ただし変更時は 「アフィリエーション」が必須前提
- 最初のセットアップは、ドメイン検証済みアカウントから始める
もはやブラウザは「単なるアプリ」ではなく、「業務基盤そのもの」 です。
Chrome Enterprise Core を正しく設計すれば、無償の範囲でも、かなり高いセキュリティ水準を確保できます。本記事が、皆さんの導入検討の参考になれば幸いです。
ありがとうございました!
参考リンク
- What's the difference between a managed profile and a managed browser? - Google Help
- Understand Chrome policy management - Google Help
- Use the Chrome Browser Enrollment Token API - Google Help
- Chrome Enterprise Core account types - Google Help
- Chrome Enterprise Policy List & Management
- Browser Management - Chrome Enterprise Core
- Manage user profiles on Chrome browser - Google Help
- Turn on managed profile reporting - Google Help
- Zero-touch enrollment - Google Help
- Policy precedence for Chrome admins - Google Cloud Blog
- Browser management made easier with Chrome Enterprise Core - Google Cloud Blog
Discussion