GCPWとは - WindowsログオンをGoogle認証で扱う方法

Windows 端末のログオンを Google 寄りにまとめたい相談では、かなりの頻度でこういう話が一気に混ざります。

• GCPW は「Google のログイン画面を出すだけ」なのか
• 既存のローカル プロファイルや AD プロファイルはどうなるのか
• Windows の管理者権限、BitLocker、更新管理まで面倒を見られるのか
• 最初のログオン、オフライン、2 段階認証、パスワード変更はどう動くのか
• Active Directory と共存できるのか、あるいは置き換えるのか

ここを雑にまとめてしまうと、導入前の期待値がずれて、移行や初期設定で事故りやすくなります。

GCPW は、単なる「Google サインイン画面」でも、Windows ドメインそのものの完全代替でもありません。 実務では、Windows への Google サインイン、既存プロファイルとの対応付け、Google 側のパスワード / セッション運用、Windows device management の併用を分けて考えると、見通しがよくなります。

この記事では、Google Credential Provider for Windows（GCPW）を Windows 10 / 11 環境で使うときに何が起きるのか、向いている構成、導入手順、ハマりどころを、Mermaid 図を多めに入れながら実務向けに整理します。内容は 2026 年 3 月時点 で確認できる Google Workspace の公式ドキュメントを主な前提にしています。

図は概念図です。Mermaid 対応の Markdown 環境では図として表示されます。

1. まず結論

先に、結論だけ並べておきます。

• GCPW は、管理対象の Google アカウントで Windows 10 / 11 へサインインさせるための仕組みです。
• GCPW 単体の主役は Windows サインイン と Chrome Browser の SSO 体験 です。
• Windows の更新、BitLocker、ローカル管理者権限、カスタム設定、ワイプまで見たいなら、Windows device management 併用を前提にしたほうが実務的です。
• 既存のローカル / AD プロファイルがある環境では、「既存プロファイルを関連付けるか、新規プロファイルを作るか」 を先に決めないと移行で詰まりやすいです。
• 初回サインインはオンライン前提です。さらに AD 参加端末で既存の AD-backed プロファイルがない場合は、最初のサインイン時に AD へ接続できることも重要です。
• オフラインサインインは可能ですが、何日まで許すか を決めておかないと運用がぶれます。
• 2 段階認証は使えますが、USB セキュリティキーは GCPW で未対応です。
• パスワード運用を先に決めないと、Google 側と Windows 側の不一致でログオン事故が起きます。特に AD / Entra ID 側だけで先にリセットする運用は危険です。
• GCPW は Google だけを ID プロバイダとして扱うので、ここを前提に構成を考えたほうがズレません。

要するに、GCPW は 「Google で Windows に入る仕組み」であり、Windows 端末運用全体まで握りたいなら Windows device management とセットで設計するのが筋です。

この記事で使う用語

Google 側と Windows 側の言葉が混ざるので、先に整理しておきます。

まずは位置づけを一枚で見る

flowchart TD
    A["Windows 端末で Google アカウントを使いたい"] --> B{"何を実現したいか"}
    B --> C["Windows への Google サインイン"]
    B --> D["Windows 設定の一元管理"]
    B --> E["既存プロファイル移行"]

    C --> F["GCPW"]
    D --> G["Windows device management"]
    E --> H["既存ローカル / AD プロファイルの関連付け設計"]

    F --> I["Windows ログオン"]
    F --> J["Chrome Browser SSO"]
    F --> K["Google パスワード同期"]

    G --> L["BitLocker"]
    G --> M["Windows Update"]
    G --> N["ローカル管理者権限"]
    G --> O["カスタム設定 / ワイプ / 監査"]

    H --> P["新規プロファイル作成か"]
    H --> Q["既存プロファイル再利用か"]

この図は 「やりたいこと」から「使う道具」を引くための図です。左から右へ、実現したいことを選ぶと、担当する仕組み（GCPW / Windows device management / プロファイル設計）が決まります。ここで確認したいのは1点だけで、BitLocker や Windows Update のような端末レベルの管理は GCPW の列に出てこないということです。

この記事の知識マップ

この記事は、GCPW(Google Credential Provider for Windows)を管理対象のGoogleアカウントでWindows 10/11にサインインさせるための資格情報プロバイダーとして整理し、BitLockerや更新管理などの端末レベル制御はWindows device managementの併用が前提であることを示す。既存のローカル/AD-backedプロファイルはDirectory側のcustom attributeで関連付けるか新規プロファイルを作るかを事前に設計する必要があり、併用時は最初にサインインしたユーザーだけがenrollされる制約がある。GoogleとWindowsのパスワードは同期が前提のため、AD/Entra ID側だけで先にリセットする運用は事故のもとになる。USBセキュリティキーは未対応で、許可ドメインの設定なしには誰もサインインできない。

flowchart LR
    accTitle: GCPWの知識マップ
    accDescr: GCPWによるWindowsサインインがChrome Browserと許可ドメインを前提とすること、Windows device managementの端末レベル管理がGCPWでの最初のenrollを前提にすること、既存プロファイルの関連付けとパスワード同期の運用上の注意点の関係を示す図
    gcpw["GCPW"]
    windows_device_management["Windows device management"]
    chrome_browser["Chrome Browser"]
    fido2_security_key["セキュリティキー"]
    permitted_domains["許可ドメイン(permitted domains)"]
    admin_console_gcpw_settings["Admin consoleでのGCPW設定"]
    installer_token_embedding["installerへのトークン自動埋め込み"]
    gcpw_enrollment["Windows device managementへのenroll"]
    staging["staging(キッティング)"]
    first_user_enrollment_constraint["最初の1ユーザーenroll制約"]
    existing_profile_association["既存プロファイルの関連付け"]
    custom_attribute_profile_mapping["Directory側custom attributeによるプロファイル対応付け"]
    initial_signin_ad_connectivity_requirement["初回サインイン時のAD接続性要件"]
    ad_backed_profile["AD-backedプロファイル"]
    active_directory["Active Directory(AD DS)"]
    ad_side_only_password_reset_antipattern["AD/Entra ID側だけでの先行パスワードリセット"]
    password_sync_requirement["Google/Windowsパスワード同期の前提"]
    offline_signin_validity_period["オフラインサインイン許容日数"]
    google_2sv["2SV(2段階認証)"]
    google_password_complexity_policy["Google側パスワード複雑度設定"]
    bitlocker["BitLocker"]
    windows_update["Windows Update"]
    admin_rights["管理者権限"]
    gcpw -->|"前提とする"| chrome_browser
    gcpw -.->|"両立しない"| fido2_security_key
    gcpw -->|"前提とする"| permitted_domains
    permitted_domains -->|"で構成できる"| admin_console_gcpw_settings
    admin_console_gcpw_settings -->|"前提とする"| installer_token_embedding
    windows_device_management -->|"前提とする"| gcpw
    windows_device_management -->|"前提とする"| gcpw_enrollment
    gcpw_enrollment -->|"前提とする"| gcpw
    staging -.->|"原因になり得る"| first_user_enrollment_constraint
    existing_profile_association -->|"利用する"| custom_attribute_profile_mapping
    existing_profile_association -.->|"前提とする"| initial_signin_ad_connectivity_requirement
    ad_backed_profile -->|"前提とする"| active_directory
    ad_side_only_password_reset_antipattern -->|"両立しない"| password_sync_requirement
    offline_signin_validity_period -->|"で構成できる"| admin_console_gcpw_settings
    gcpw -.->|"利用する"| google_2sv
    google_password_complexity_policy -.->|"両立しない"| active_directory
    windows_device_management -->|"利用する"| bitlocker
    windows_device_management -->|"利用する"| windows_update
    gcpw -.->|"前提とする"| admin_rights
    chrome_browser -.->|"前提とする"| admin_rights
    gcpw -->|"で構成できる"| admin_console_gcpw_settings
    gcpw -->|"利用する"| existing_profile_association
    existing_profile_association -->|"利用する"| ad_backed_profile
    gcpw -->|"前提とする"| password_sync_requirement
    staging -->|"より先に行うべき"| gcpw_enrollment

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全25件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. GCPW を 4 層に分けると理解しやすい

GCPW の話がややこしくなるのは、「サインイン」と「プロファイル移行」と「端末管理」が同じ箱の話として扱われやすいからです。 実務では、この 4 層に分けてしまうのが早いです。

この見方をすると、「GCPW を入れたのに BitLocker が効かない」「Google で入れたのに既存ユーザーデータが見えない」といったズレの原因が見えやすくなります。

レイヤー構造

flowchart LR
    subgraph Id["ID / セッション"]
        A["Google アカウント"]
        B["2 段階認証"]
    end

    subgraph SignIn["サインイン層"]
        C["GCPW"]
    end

    subgraph Profile["Windows プロファイル層"]
        D["既存ローカル プロファイル"]
        E["既存 AD-backed プロファイル"]
        F["新規 Windows プロファイル"]
    end

    subgraph Mgmt["管理層"]
        G["Windows device management"]
        H["BitLocker / 更新 / ローカル管理者権限"]
        I["カスタム設定 / ワイプ / 監査"]
    end

    subgraph Config["設定層"]
        J["Admin console"]
        K["レジストリ設定"]
    end

    A --> C
    B --> C
    C --> D
    C --> E
    C --> F
    J --> C
    K --> C
    G --> H
    G --> I
    C --> G

1章の図が「目的から道具を引く」ものだったのに対し、この図は 同じ要素を「どの層の話か」と「何が何に依存するか」で並べ直したものです。読み取ってほしいのは、矢印がすべて GCPW（サインイン層）を通っていること、そして GCPW からプロファイル層へ伸びる矢印が3本に分岐していること。この分岐が4章で扱う「既存プロファイルを関連付けるか、新規で作るか」の設計そのものです。

3. Windows 環境でどう動くのか

3.1 対応要件を先に押さえる

Windows 環境では、まず要件で引っかからないことが大事です。

対応エディションの違い（導入判断の最初の関門）

「GCPW 単体」と「Windows device management 併用」では、必要なエディションが違います。Google の公式ドキュメント（Overview: Enhanced desktop security for Windows）が挙げている対応エディションは次のとおりです。

読み方はこうです。GCPW でのサインインだけなら、ほぼすべてのエディションで使えます。 一方、BitLocker や Windows Update、ローカル管理者権限まで管理したい場合は、Business Plus、Enterprise Standard 以上、Cloud Identity Premium などの対応エディションが必要です。特に Business Starter / Business Standard と Cloud Identity Free は、GCPW は使えても Windows device management は使えません。「GCPW を入れたのに BitLocker が管理できない」という相談は、ここが原因のことがあります。

エディションの構成は変わることがあるため、契約前には必ず公式ドキュメントの最新の対応表を確認してください。

ここで見落としやすいのが Chrome と ARM 非対応 です。 Windows 端末の話なので OS ばかり見がちですが、GCPW は Google サインイン画面の起動で Chrome 側にも依存するので、Chrome の有無や配置不整合でもログオンが失敗します。

3.2 初回サインインから、普段のログオンまで

GCPW 導入後の流れを単純化すると、こうなります。

1. 端末に GCPW をインストールする
2. ユーザーが Google アカウントで初回サインインする
3. GCPW が 既存プロファイルを関連付けるか、新しい Windows プロファイルを作る
4. その後は、通常の Windows ログオン画面から入る
5. ただし、Google パスワード変更やセッション期限切れなどのセキュリティイベント時は、再度 Google サインイン画面が要求される

ここで大事なのは、「毎回必ず Google ダイアログから入る」わけではない という点です。 初回ログオンや特定のセキュリティイベント時は Google 側の認証が前面に出ますが、普段は Windows ログオン画面でのサインインが主になります。

初回サインインの流れ

sequenceDiagram
    participant U as ユーザー
    participant W as Windows サインイン画面
    participant G as Google サインイン
    participant P as GCPW
    participant R as 既存 / 新規プロファイル
    participant C as Chrome Browser

    U->>W: Add Work Account または既存アカウントを選ぶ
    W->>G: Google 認証画面を起動
    G->>U: メールアドレス / パスワード / 2SV
    U->>G: 資格情報を入力
    G->>P: 認証成功

    alt 既存プロファイルを関連付ける
        P->>R: 既存ローカル / AD プロファイルを見つけて関連付け
    else 新規作成
        P->>R: 新しい Windows プロファイルを作成
    end

    P->>C: Google サインイン状態を引き継ぐ
    P->>W: Windows セッションを開始

この図で見てほしいのは、分岐が1か所しかないことです。既存プロファイルを関連付けるか、新規プロファイルを作るか。ここは初回サインインの一瞬で決まり、あとから「やっぱり既存プロファイルに」と戻すのは手戻りになります。だからこそ、4章の関連付け設計を installer の配布より先に済ませます。

3.3 パスワード同期、オフライン、2 段階認証

GCPW を Windows 環境で安定運用したいなら、実は一番先に見るべきなのは パスワード運用 です。

Google の公式ガイドでも、GCPW を使う端末では Google のパスワードと Windows のパスワードが同期していること が前提になっています。しかも、ユーザーは通常 Google 側のパスワード を主に管理する前提です。 そのため、Ctrl + Alt + Delete からの Windows パスワード変更に頼る設計とは相性がよくありません。

パスワード同期の考え方

flowchart LR
    A["Google パスワード変更"] --> B{"端末はオンラインか"}
    B -- はい --> C["GCPW が Windows 側パスワードを同期"]
    C --> D["次回ログオン成功"]

    B -- いいえ --> E["同期は保留"]
    E --> F["次のオンライン時に再同期"]

    G["AD / Entra ID 側だけでパスワード変更"] --> H["Google と Windows の不一致"]
    H --> I["Password incorrect / 同期エラー"]

この図は上下2本の流れに分かれています。上の流れ（Google 側で変更）は、オンラインなら同期され、オフラインでも次回オンライン時に追いつきます。下の流れ（AD / Entra ID 側だけで変更）は、どれだけ待っても同期されません。 パスワードリセットの手順書を作るときは、この下の流れを禁止手順として明記しておくのが実務的です。

実務でよくあるのは、ここです。

• Google 側でパスワード変更したつもりだが、端末がオフラインで Windows 側とまだ同期していない
• 逆に AD / Entra ID 側だけで先にリセットして、Google 側と不一致になった
• Google 側のパスワード複雑度が Windows / AD より弱く、Windows 側の要件を満たせない文字列に変えてしまった

このため、導入前に少なくともここまでは決めておかないといけません。

• パスワードの主導権を Google に置くのか
• それとも AD / Entra ID / 他ツールから Google へ同期するのか
• パスワード複雑度を Windows 側以上 に合わせるのか

3つめの複雑度は、Google 管理コンソールの 「セキュリティ」→「認証」→「パスワードの管理」 で組織部門ごとに設定します。ただし、ここで指定できるのは「安全なパスワードを適用する」というチェックと、最小・最大文字数（8〜100 文字）、再利用の可否、有効期限までです。Active Directory のパスワード ポリシーのように「大文字・小文字・数字・記号のうち何種類を含むこと」といった文字種の指定はできません。Google 側は文字種の内訳ではなくパスワード全体の強度を評価する方式だからです。

そのため実務では、AD 側の最小文字数と同じかそれ以上を Google 側に設定し、「安全なパスワードを適用する」を有効にする、という揃え方になります。AD 側の文字種要件が厳しい場合、Google 側で通ったパスワードが Windows 側で弾かれる可能性が残るため、その組み合わせは pilot で必ず確認してください。

オフラインと 2 段階認証

GCPW はオフラインサインイン自体は可能です。 ただし、最後のオンラインサインインから何日まで許すか を設定できます。ここを決めないまま入れると、厳しすぎて現場が困るか、緩すぎて端末紛失時のリスクが上がるかのどちらかに寄りやすいです。

また、2 段階認証は使えますが、このあたりは先に現場へ伝えておいたほうが安全です。

• USB セキュリティキーは GCPW で未対応
• 代わりに、Google prompt、Google Authenticator、backup code などの方式を前提にする
• セキュリティキーしか許可していない構成だと、ユーザーが Windows に入れなくなる可能性がある

4. 既存のローカル / AD プロファイルをどう扱うか

GCPW 移行で一番事故りやすいのがここです。

端末にすでに業務用 Windows プロファイルがあるとき、GCPW 側でそれを 関連付けて再利用する のか、新しい Windows プロファイルを作る のかで、ユーザー体験も移行難易度も大きく変わります。

代表的な 3 パターン

Google の案内でも、既存プロファイルへ関連付ける場合は Directory 側の custom attribute で Windows アカウント名や AD アカウントを対応付けたり、端末側の SID ベースのレジストリ設定 を使ったりします。 つまり、「入れたあと、ユーザーがその場で何となく選ぶ」運用ではなく、事前設計が必要な移行作業 です。

さらに重要なのは、関連付けしない場合の挙動です。

• 既存ローカル プロファイル利用者は、旧プロファイル側へ入る余地が残ることがある
• 既存 AD ユーザーは、Google サインイン用の新規プロファイルが作られると、期待した業務プロファイルへ素直に入れないことがある

既存プロファイルをどう扱うかの判断図

flowchart TD
    A["端末に既存の業務用 Windows プロファイルがある"] --> B{"そのままデータ / 設定を使いたいか"}
    B -- はい --> C["既存プロファイルの関連付けを設計する"]
    B -- いいえ --> D["GCPW に新規 Windows プロファイルを作らせる"]

    C --> E{"既存プロファイルの種類"}
    E -- ローカル --> F["Local Windows accounts などで対応付け"]
    E -- AD-backed --> G["AD accounts などで対応付け"]

    G --> H["初回サインイン時に AD 接続性を確認"]
    F --> I["Windows ユーザー名 / 端末単位制限を整理"]
    D --> J["既存データ移行を別計画で進める"]

この図は、端末群ごとに1回だけ通せば済む判断です。最初の分岐（既存データをそのまま使いたいか）を端末群単位で決めておけば、あとは対応付けの定義を作るか、データ移行の計画を作るかのどちらかに収束します。 現場で1台ずつ判断させると、同じ端末群の中で新規プロファイルと関連付けが混在し、問い合わせ対応が読めなくなります。

5. GCPW 単体と、GCPW + Windows device management の違い

GCPW の話をするとき、実務ではここを分けるのがとても大事です。

比較表

Google の公式でも、会社支給端末では GCPW と Windows device management を一緒に使う構成 が推奨です。 逆に、別の管理基盤がすでにあり、Google ログオン体験だけ欲しいなら GCPW 単体という考え方になります。

併用時に地味に重要な制約

Windows device management を併用するときは、1 台の端末で enroll できるユーザーは 1 人だけ という点を先に理解しておいたほうが安全です。

Google の公式でも、これは Windows 10 / 11 側の制約として案内されています。 複数ユーザーが GCPW でその端末へ入れる構成にしても、Windows device management へ enroll されるのは最初の 1 ユーザー です。しかも、BitLocker や更新、ローカル管理者権限のような 端末レベルの設定 は、その端末を使う他ユーザーにも影響します。

最初の 1 ユーザー問題

flowchart TD
    A["端末をセットアップ"] --> B["最初に GCPW でサインインしたユーザー"]
    B --> C["Windows device management へ enroll"]
    C --> D["端末レベル設定が適用"]
    D --> E["BitLocker / 更新 / ローカル管理者権限 / カスタム設定"]

    F["後から GCPW で入る別ユーザー"] --> G["Windows サインイン自体は可能"]
    G --> H["ただし enroll ユーザーは増えない"]
    H --> I["端末レベル設定は最初の enroll を前提に動く"]

これが何に効くかというと、キッティング担当が最初に GCPW で入ってしまう問題です。 本来その端末を使う社員ではなく、セットアップ担当のアカウントが enroll されると、あとで意図した設定が乗らない、という事故が起きます。

6. 導入前に決めるべきこと

GCPW 導入で後から効いてくるのは、インストーラ実行そのものより 事前設計 です。 公式ガイドを実務向けに言い換えると、少なくともこの 6 つは先に決めておきたいところです。

flowchart LR
    A["導入前に決める"] --> B["パスワード主導権"]
    B --> C["複雑度要件"]
    C --> D["許可ドメイン"]
    D --> E["既存プロファイル対応"]
    E --> F["サポート用管理者権限"]
    F --> G["自動 enrollment の staging 方針"]
    G --> H["オフライン許容日数"]

この図は順番が意味を持ちます。左から右へ、決めないと次が決められない順に並べてあります。 たとえば複雑度は、パスワードの主導権を Google に置くのか AD 側に置くのかが決まらないと決められません。逆に言えば、この並びのどこかを飛ばしたまま installer を配ると、その先の判断が全部保留のまま端末が増えていきます。

ダメな進め方と、実務的な進め方

特に見落としやすい 3 点

1. 許可ドメインは必須

GCPW では、どのドメインのアカウントをログオン許可するか を決めないとユーザーは入れません。 Admin console でも、レジストリの domains_allowed_to_login でも設定できますが、どちらにせよここは必須です。

2. Admin console とレジストリは役割を分ける

古い解説ではレジストリ設定中心の記事が多いですが、現在は Admin console 管理が基本 です。 ただし、端末ごとに違う許可ドメインを持たせたい など、粒度を細かくしたい場合はレジストリのほうが向く場面もあります。

3. Admin console の設定は即時反映ではない

GCPW の設定は、端末へ だいたい 1 時間単位 で同期されます。 「設定は入れたのに、すぐ反映されない」というのはよくあるので、pilot 時はこのタイムラグ込みで見たほうが安全です。

7. 実務向けの導入手順

ここでは、Windows 環境で GCPW を実務的に入れるときの流れを、できるだけ短くまとめます。

導入フロー

flowchart TD
    A["1. 契約プラン / OS / Chrome 要件を確認"] --> B["2. パスワード戦略と複雑度を決める"]
    B --> C["3. 許可ドメインと各種設定を決める"]
    C --> D["4. 既存プロファイル関連付け要否を決める"]
    D --> E["5. Windows device management を使うなら有効化"]
    E --> F["6. Admin console から installer を取得"]
    F --> G["7. 端末へ配布 / 管理者権限でインストール"]
    G --> H["8. ユーザーが初回オンライン サインイン"]
    H --> I["9. 端末詳細 / enrollment / ログを確認"]

7.1 まず、構成を決める

最初に決めるのはここです。

• GCPW 単体で使うのか
• GCPW + Windows device management で使うのか
• 既存プロファイルを 関連付ける のか
• それとも 新規プロファイル で切り替えるのか

この判断が先です。 ここを決めずに installer だけ配ると、あとで「思っていた端末管理ができない」「既存ユーザーデータが引き継がれない」となります。

7.2 許可ドメインとオプションを決める

設定方法は 2 つです。

• Admin console 同じ設定を組織全体へ配りたいときに向いています。いまの基本はこちらです。
• 端末レジストリ 端末ごとに細かく分けたいときに向いています。

レジストリを使うなら、最低でも domains_allowed_to_login は必要です。 GCPW を Windows device management と併用するなら、enable_dm_enrollment や validity_period_in_days、共有端末っぽい運用なら enable_multi_user_login も判断ポイントになります。

7.3 installer を取得して配布する

Admin console から 32bit / 64bit の GCPW installer を取得し、端末へ配布します。取得先の画面は次のパスです。

Google 管理コンソール
  → メニュー
  → デバイス（Devices）
  → モバイルとエンドポイント（Mobile & endpoints）
  → 設定（Settings）
  → Windows
  → 「Google Credential Provider for Windows setup」
  → 「Download GCPW」

この操作には 特権管理者（super administrator） としてのログインが必要です。ここから 64bit 版または 32bit 版をダウンロードして配布します。

現行の管理モデルで重要なのは、Admin console からダウンロードした installer には、その組織のトークンが自動で埋め込まれるという点です。トークンの有無は、後から効いてきます。

なお、Chrome Enterprise Core 用の登録トークンをすでに端末へ配っている場合は、そのトークンで GCPW の設定も Admin console から管理できます。「Admin console で許可ドメインを設定したのに、端末に反映されない」ときは、まずトークンなしの installer を配っていないかを疑ってください。 設定の反映自体にも最大1時間程度かかるため、その時間を待ってから判断します。

7.4 インストールする

手動インストールなら、たとえば次のようにできます。

# 64bit 版
gcpwstandaloneenterprise64.exe /silent /install

# 32bit 版
gcpwstandaloneenterprise.exe /silent /install

7.5 レジストリで個別設定したい場合の例

Admin console で設定していない値を、端末ごとに入れたいときの例です。

注意: Admin console とレジストリの両方で同じ設定を持つ場合、Admin console 側が優先されます。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"domains_allowed_to_login"="example.com"
"enable_dm_enrollment"=dword:00000001
"validity_period_in_days"=dword:00000007
"enable_multi_user_login"=dword:00000000

7.6 既存プロファイルを再利用するなら、関連付け定義を先に作る

既存ローカル / AD プロファイルを再利用したいなら、ユーザーの Google アカウントと Windows アカウントの対応付けを Directory 側の custom attribute で先に用意します。 ここを後回しにして先にログオンさせると、新規プロファイルが作られてから巻き戻すことになりやすいです。この記事でいちばん事故りやすい箇所なので、具体的に書いておきます。

手順1: カスタム属性を作る

Admin console の「ディレクトリ」→「ユーザー」→ 上部の「その他」→「カスタム属性を管理」から追加します。値は 大文字・小文字まで含めて次のとおりに入力します（間違えると後から名前を直せず、作り直しになります）。

Directory API で作る場合は、スキーマ名 Enhanced_desktop_security、フィールド名 AD_accounts / Local_Windows_accounts で登録します。既存の AD から値を流し込むなら、Google Cloud Directory Sync を使う方法もあります。

手順2: ユーザーごとに値を入れる

ユーザーの詳細画面の「ユーザー情報」に「Enhanced desktop security」欄が出るので、そこへ Windows 側のアカウント名を入れます。書式が決まっています。

押さえておきたい制約は3つです。

• AD アカウントは1ユーザーにつき1つだけです。複数入れても、GCPW は最初の1件しか使いません。
• AD とローカルの両方を設定した場合、GCPW は AD アカウントを先に探します。
• 属性が未設定、または一致する Windows プロファイルが見つからない場合は、新しい Windows プロファイルが作られます。 「関連付けたはずなのに既存データが見えない」の大半はここです。

AD 参加端末で、その端末にまだ AD-backed プロファイルが無いユーザー（サインイン画面で「その他のユーザー」から入る人）は、初回サインイン時に端末が AD へ接続できる必要があります。リモートワーク中の端末で初回サインインさせると、ここで失敗します。

正確な画面手順と最新の仕様は、公式の Associate Google accounts with existing Windows profiles を参照してください。

7.7 初回オンライン サインイン後に、確認する

初回サインイン後は、ここを確認します。

• 期待した Windows プロファイルに入れているか
• Windows device management 併用なら、意図したユーザーで enroll されているか
• 端末詳細が Admin console に出ているか
• ポリシー同期が終わっているか

8. よくあるハマりどころと、Windows での切り分け

GCPW のトラブルは、だいたいこの表のどれかに落ちます。

「Chrome / AV 干渉」の中身を分解する

この表でいちばん曖昧なのが「AV 干渉」です。実際に問題になるのは、次のどれかです。上から順に確認すると切り分けが速くなります。

このうち ログオン前の通信 は見落とされやすいところです。ユーザーがサインインした後は通る通信でも、ログオン画面の時点では別の経路や別の資格情報で動くため、そこで止まっていないかを確認します。

トラブルシュートの流れ

flowchart TD
    A["GCPW で問題発生"] --> B{"何が起きているか"}
    B -- サインイン拒否 --> C["許可ドメイン確認"]
    B -- Google 画面が出ない --> D["Chrome の有無 / パス / AV 確認"]
    B -- Password incorrect --> E["Google / Windows の同期状態確認"]
    B -- 既存データが見えない --> F["プロファイル関連付け確認"]
    B -- device management に入らない --> G["最初の enroll ユーザー確認"]
    C --> H["Admin console / レジストリを確認"]
    D --> I["Chrome を再導入"]
    E --> J["パスワード運用を整理し直す"]
    F --> K["custom attribute / SID マッピング再確認"]
    G --> L["staging 手順を見直す"]

この図は、症状から最初に見る場所を1つに決めるためのものです。GCPW のトラブルは「認証」「Chrome」「パスワード同期」「プロファイル関連付け」「enrollment」のどれかに落ちるので、まずどの列の話かを確定させてから、詳細ログへ進みます。 症状が複数あるように見えるときは、最初にサインインできたユーザーが誰だったかを確認すると、enrollment の列に集約されることが多いです。

Windows でログを取る場所

GCPW を Windows 上で追うときは、まず Event Viewer です。

• Windows Logs > Application
• Event source は GCPW

これで大半の基本情報は見られます。 さらに詳しく見るなら、レジストリで verbose logging を有効にできます。

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Google\GCPW]
"enable_verbose_logging"=dword:00000001
"log_file_path"="C:\\GCPW.log"
"log_file_append"=dword:00000001

Windows device management まで見たいときは、必要に応じてこちらも見ます。

• Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin

反映を早く確認したいとき

許可ドメインやポリシーを直したあと、すぐ反映確認したいなら、Google の案内では Task Scheduler から GoogleUpdateTaskMachineUA を実行して同期を促す方法が案内されています。 pilot 中は、この手順を手元に置いておくと切り分けが速くなります。

9. どんな組織に向くか、向かないか

向いている場面

向かない場面

10. まとめ

GCPW を Windows 環境でうまく使うコツは、機能を一枚岩で見ないことです。

• GCPW は Google で Windows に入る仕組み
• 既存プロファイル関連付け は移行の仕組み
• Windows device management は端末運用の仕組み

この 3 つを分けて考えると、導入判断がぐっとしやすくなります。

実務で特に重要なのは、この 5 点です。

1. パスワード運用を先に決める
2. 許可ドメインを先に決める
3. 既存プロファイルを再利用するか決める
4. Windows device management を使うなら最初の enroll ユーザーを誤らない
5. Event Viewer を前提にトラブルシュート手順を持っておく

GCPW は Windows ログオンを Google 側へ寄せるための実務的な道具 です。 ただし、本当に効くのは installer を実行した瞬間ではなく、その前の設計です。 ここを先に固めておくと、Google ログオン、既存データの継続利用、Windows 端末管理の線がきれいにつながります。

関連記事

• Windows の管理者特権が必要になるのはいつなのか - UAC、保護領域、設計上の見分け方
• Windows Sandboxでアプリ検証を速くする方法
• ClickOnce とは何か - 仕組み、更新、向いている場面・向いていない場面を実務目線で整理

関連トピック

• Windows技術トピック

このテーマがつながるサービス

• Windowsアプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考資料

1. Google Workspace Help - Overview: Enhanced desktop security for Windows
2. Google Workspace Help - Prepare to install GCPW
3. Google Workspace Help - Install Google Credential Provider for Windows
4. Google Workspace Help - Set up GCPW and Windows device management together
5. Google Workspace Help - Associate Google accounts with existing Windows profiles
6. Google Workspace Help - Set account privileges on Windows 10 or 11 devices
7. Google Workspace Help - FAQ for GCPW
8. Google Workspace Help - Troubleshoot GCPW
9. Google Workspace Learning Center - Sign in to Windows after GCPW installation
10. Google Workspace Help - Set token to manage GCPW from the Admin console
11. Google Workspace Help - What’s new in GCPW
12. Google Workspace 管理者ヘルプ - ユーザーのパスワード要件を適用、モニタリングする

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

GCPWとは何ですか？

GCPW（Google Credential Provider for Windows）は、管理対象の Google アカウントで Windows 10 / 11 へサインインさせるための仕組みです。単体での主役は Windows サインインと Chrome Browser の SSO 体験で、単なる「Google サインイン画面」でも、Windows ドメインの完全代替でもありません。対応 OS は Windows 10 / 11 の Pro、Pro for Workstations、Enterprise、Education で、ARM ベース端末は非対応、Chrome Browser 81 以降が管理者権限でインストールされていることが前提です。

GCPWだけでBitLockerやWindows Updateの管理はできますか？

GCPW 単体では基本的にできません。GCPW 単体でできるのは Google での Windows サインイン、Chrome SSO、既存プロファイルの関連付けまでで、BitLocker、Windows Update 制御、ローカル管理者権限の制御、カスタム設定配布、ワイプなどは Windows device management の併用が前提です。併用時は1台の端末で enroll できるユーザーは最初の1人だけという制約があるため、キッティング担当が最初にサインインして enroll されてしまう事故に注意が必要です。

GCPWはオフラインでもWindowsにログオンできますか？

オフラインサインイン自体は可能です。ただし初回サインインはインターネット接続が必須で、AD 参加端末で既存の AD-backed プロファイルがない場合は、最初のサインイン時に AD へ接続できることも必要です。オフラインを許す日数は validity_period_in_days などで設定でき、最後のオンラインサインインから何日まで許すかを決めておかないと、厳しすぎて現場が困るか、緩すぎて端末紛失時のリスクが上がるかのどちらかに寄りやすくなります。

GCPWで2段階認証やセキュリティキーは使えますか？

2段階認証は使えますが、USB セキュリティキーは GCPW では未対応です。代わりに Google prompt、Google Authenticator、backup code などの方式を前提にします。セキュリティキーしか許可していない構成だと、ユーザーが Windows に入れなくなる可能性があるため、導入前に現場へ伝えておくのが安全です。またパスワードは Google 側と Windows 側の同期が前提のため、AD / Entra ID 側だけで先にリセットする運用は不一致によるログオン事故につながります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。