統合ソリューションの前提条件

最終公開日 : Oct 24, 2026
Citrix Workspace™アプリケーションとChrome Enterprise Premium間の最適な統合を確保するには、以下の前提条件を実装する必要があります。これらの前提条件を正常に完了すると、Citrix WorkspaceアプリまたはWebベースのユーザーインターフェイスからアプリケーションを起動する際に、より効率的でシームレスなエクスペリエンスが得られます。
前提条件は、以下のカテゴリに大別されます。

ライセンス、アプリのバージョン、および拡張機能

  • Chrome Enterprise Premiumライセンス: Citrix Cloud Platform License (CPL) プログラムを通じて利用可能な、アクティブなChrome Enterprise Premiumライセンスがあることを確認してください。
  • Citrix Workspaceアプリ (CWA) のバージョン:
    • Windows: 2025.07以降
    • macOS: 2025.08以降
    • ChromeOS: 25.7.0.25 以降
    注記:
    Citrix Workspace アプリは、このソリューションのオプション要件です。
  • Citrix Endpoint Analysis (EPA) クライアントバージョン:
    • Windows: 25.9.1.9 以降
    • macOS: 25.10.3 以降
    注記:
    定期的なデバイスポスチャスキャンをサポートするために、Windows EPAクライアントを管理者モードでインストールすることをお勧めします。さらに、デバイスポスチャの設定ページで定期的なデバイスポスチャスキャンを有効にする必要があります。詳細については、「デバイスの定期スキャン」を参照してください。
  • Chromeブラウザのバージョン: エンドポイントは、最新のGoogle Chromeバージョンを使用する必要があります。
  • オペレーティングシステム: Windows、macOS、ChromeOS。

Google 管理コンソール

  • Google顧客ID: Google 管理コンソールからGoogle顧客IDを取得します。このIDは、Googleサービスと統合を構成するために必要です。顧客IDは、Google 管理コンソールのアカウント > アカウント設定から取得できます。
  • Google 管理コンソールでカスタムロールを作成する: Chrome Enterprise Premium (CEP) に顧客をオンボーディングし、Google Chrome統合を有効にするには、管理者はGoogle 管理コンソールでカスタムロールを作成し、適切な権限を割り当てる必要があります。詳細については、「管理者ロールと権限」を参照してください。
  • DevTools拡張機能を制限する: 機密データの漏洩を防ぐため、強制インストールされた拡張機能のChrome DevToolsは無効にする必要があります。これは、Google 管理コンソールのデフォルトオプションです。

セキュア プライベート アクセス サービス

  • IPv6エンドポイントの制限事項: Google Cloudエンドポイントと統合されたCitrix Secure Private Accessサービスは、IPv6アドレスを持つエンドユーザーデバイスからトラフィックを受信する場合があります。現在、Secure Private Accessの地理的位置およびネットワーク位置アクセスポリシーはIPv6をサポートしていません。
    その結果、地理的位置またはネットワーク位置の条件を持つアクセスポリシーは、IPv6アドレスを持つエンドユーザーデバイスでは失敗する可能性があります。これらの条件を利用しない他のアクセスポリシーは、IPv4およびIPv6対応のエンドユーザーデバイスの両方で機能します。
  • CEPのアクセス制限はGoogle管理コンソールで設定されるようになりました: 以前Secure Private Accessコンソールで構成されていたアクセス制限は、Citrix Enterprise Browserにのみ適用されます。Google Chromeがエンタープライズブラウザである場合、アクセス制限はGoogle管理コンソールでポリシーおよびルールとして構成する必要があります。
    • ポリシーは、Google管理コンソール > デバイス > Chrome > 設定で構成されます。これらの設定により、JavaScriptのブロックやプリンターの許可リストなど、ブラウザの設定を管理できます。
    • ルールは、Google管理コンソール > ルールで構成されます。これらのルールは、透かしの追加、社会保障番号を含むファイルのダウンロードのブロック、URLフィルタリングなど、DLPに関連する高度な設定です。
    Google Workspace管理コンソールでポリシーとルールを作成する方法の詳細については、以下のトピックを参照してください。
    • Chrome EnterpriseコネクタポリシーをChrome Enterprise用に設定する
    • データ保護ルール

グーグル クローム

管理対象Chromeプロファイル: すべてのエンドユーザーは、管理対象プロファイルを使用してChromeにアクセスする必要があります。管理対象プロファイルにより、Chromeのポリシー、拡張機能、およびセキュリティ設定がユーザーデバイスに適用されます。

ユーザーの管理

シームレスな統合のためには、Citrix Secure Private AccessとGoogle Identity (Directory) で構成されたユーザー間に相関関係が必要です。これにより、承認されたユーザーのみが割り当てられたアプリケーションにアクセスできるようになります。統合でサポートされているユーザーディレクトリは次のとおりです。
  • アクティブ ディレクトリ
  • マイクロソフト エントラ ID (旧称: アジュール アクティブ ディレクトリ)

必須 - ユーザーのメールアドレスフィールドに入力する

Google Identityにはメールアドレスフィールドの入力が必要です。この目的のために、Secure Private Accessで使用されるディレクトリ内のユーザーオブジェクトは、次のいずれかを持っている必要があります。
  • Google管理コンソールで設定および検証されているドメイン部分を持つメールアドレス。たとえば、メールアドレス alice@example.com を持つ Alice は、Google Identityで alice@example.com としてマッピングされます。
  • Google管理コンソールで設定されていないドメイン部分を持つメールアドレス。たとえば、Bob はメールアドレス bob@example.internal.net を持っていますが、これはGoogleで設定されていません。この場合、example.com が検証済みドメインであるため、彼はGoogle Identityで bob@example.com としてマッピングされます。
  • ドメインマッピングの目的でメールアドレスがない場合に使用できる別のディレクトリフィールド。一般的なアプローチは、ドメイン置換の有無にかかわらず、ユーザープリンシパル名 (UPN) を活用することです。たとえば、Charlie はUPN charlie@ADdomain.com を持ち、Google Identityで charlie@example.com としてマッピングされます。
Secure Private AccessディレクトリとGoogleディレクトリのメールアドレスが一致しないユーザーには、重大な制限があります。詳細については、ドメインマッピングの考慮事項 セクションを参照してください。

必須 - ユーザーグループのメールアドレスフィールドに入力する

ユーザーと同様に、Secure Private Accessで使用されるディレクトリ内のグループオブジェクトは、次のいずれかを持っている必要があります。
  • Google管理コンソールで設定および検証されているドメイン部分を持つメールアドレス。
  • Google管理コンソールで設定されていないドメイン部分を持つメールアドレス。
  • ドメインマッピングの目的でメールアドレスがない場合に使用できる別のディレクトリフィールド。一般的なアプローチは、共通名 (CN) を活用し、Google Directoryに適切なドメインを追加することです。たとえば、CN group1 を持つグループは、Google Identityで group1@example.com としてマッピングされます。

メールアドレスの欠落または不整合に関するドメインマッピングの考慮事項

ユーザー:
ユーザーのメールアドレスがSecure Private Accessディレクトリにない場合、またはSecure Private AccessディレクトリとGoogle Identityの間で一貫性がない場合、以下の考慮事項が適用されます。
  • メールアドレスを持たないユーザーは、Secure Private Accessコンソール内でSecure Private Accessポリシーを設定する際に選択できません。
  • Secure Private AccessディレクトリとGoogleディレクトリの間でメールアドレスが一致しないユーザーのSecure Private Accessポリシーは機能しません。
  • これらのユーザーに対して、クラウドストアからWebまたはSaaSアプリを起動すること(Citrix WorkspaceアプリまたはWebブラウザを使用)はサポートされていません。
グループ:
グループのメールアドレスがSecure Private Accessディレクトリにない場合、またはSecure Private AccessディレクトリとGoogle Identityの間で一貫性がない場合は、Secure Private Accessのグループレベルポリシーが正しく機能するように、適切なドメインマッピング構成が必要です。

Citrix Secure Private Accessで構成されたユーザーディレクトリをGoogle Cloudユーザーディレクトリと関連付ける

Citrix Secure Private Accessで構成されたユーザーディレクトリをGoogle Cloudディレクトリと関連付ける必要があります。具体的には、以下のユーザーディレクトリがサポートされています。
  • アクティブディレクトリ
  • マイクロソフト エントラ ID(旧称:アジュール アクティブ ディレクトリ)
  • オクタ
アプリケーションアクセスが適切に適用されるように、ユーザーディレクトリの関連付けは定期的に行う必要があることに注意してください。関連付けに必要な属性は最小限のセットのみです。

アクティブディレクトリ

Active Directoryの場合、名前、メールアドレス、オブジェクトグローバル一意識別子 (objectGUID)、およびセキュリティ識別子 (SID) を関連付ける必要があります。パスワードおよびその他のすべての属性は、Google Cloud Directoryと関連付ける必要はありません。
カスタムスキーマcitrix-schemaの下にカスタムADフィールドを含めるようにADをGoogle Cloudと関連付ける方法の詳細については、「Citrix CloudへのIDプロバイダーとしてのGoogle Cloud Identityの接続」および「Active Directoryユーザーアカウントのプロビジョニング」を参照してください。

マイクロソフト Entra ID

GoogleとMicrosoftの両方のクラウドプラットフォームでユーザーとグループを管理するために、Microsoft Entra IDをGoogle Cloudユーザーディレクトリと同期する必要があります。詳細については、「Microsoft Entra ID (旧Azure AD) ユーザープロビジョニングとシングルサインオン」を参照してください。
同期を構成する際には、以下の要件を考慮する必要があります。
  • メールアドレス: すべてのユーザーとグループに対して、メールアドレスフィールドが入力されている必要があります。詳細については、「ユーザーの管理」を参照してください。
  • objectId属性マッピング: Entra IDユーザーのobjectId属性は、Google Directoryにマッピングする必要があります。
    このマッピングは、G-Suiteコネクタの設定で行います。
    1. 左側のメニューから、 > をクリックします。
    2. 新しいメニューで、 > をクリックします。
    3. をクリックします。
    4. objectIdの適切な行を見つけます。
      • をクリックし、 で externalIds..value を選択します。
      • 結果として得られる構成が次のスクリーンショットと一致することを確認します。
      属性マッピング
  • シングルサインオン: シングルサインオン (SSO) の構成はオプションです。Googleディレクトリで個別のパスワードを設定するか、Entra IDでSSOを設定するか、またはCitrix IdentityによるOpen ID ConnectでSSOを設定できます。

オクタ

OktaからGoogle Cloudユーザーディレクトリ (Cloud Identity / Google Workspace) にユーザーとグループをプロビジョニングすることで、OktaをIDソースとして使用できます。プロビジョニングされると、Secure Private Accessとの関連付けは、他のサポートされているディレクトリと同じモデルに従います。最小限の属性セットのみが必要であり、すべてのユーザーとグループに対してメールアドレスフィールドが入力されている必要があります。
OktaからGoogleへのプロビジョニングの詳細については、「Oktaユーザープロビジョニングとシングルサインオン」を参照してください。同じガイドに従ってOktaに対するSSOを設定するか、「Citrix WorkspaceによるOpen ID Connect」を参照してください。

グーグル クラウド アイデンティティ(グーグル ディレクトリ)

Google Cloud IdentityがすでにIDプロバイダーである場合、ユーザーとグループはGoogle Cloudディレクトリにネイティブに存在します。Googleと照合する別の外部ディレクトリがないため、ディレクトリの関連付けや同期は必要ありません。Googleは、Citrix WorkspaceとChrome管理プロファイルの両方にとってIDのソースです。
注:
Chrome Enterprise Premiumのデバイスポスチャサービス統合は、Google CloudディレクトリがCitrix Workspaceに対して依拠当事者として機能するOpenID Connect (OIDC) フローに依存しています。Google Cloud Identity自体が基盤となるIdPである場合、このフローはサポートされません。したがって、この構成ではデバイスポスチャサービス統合は利用できません。

TLS検査のバイパス

TLS検査(またはSSL検査)を使用するネットワークでChrome Enterprise Premiumエンドポイントが正しく機能するようにするには、以下のホスト名を検査から除外する必要があります。
  • ingress.cloudproxy.app
  • securegateway.goog
  • *.securegateway.goog
多くのTLS検査ソリューション(SSEベンダーやプロキシサーバーなど)は、Chrome Enterprise Premiumが使用するHTTP CONNECTメソッドを完全にサポートしていないため、トラフィックが突然切断される可能性があるため、この除外は不可欠です。
さらに、潜在的なエンドユーザーのパフォーマンス問題や接続遅延を避けるために、以下のホスト名をTLS検査から除外することをお勧めします。
  • safebrowsingrealtime.googleapis.com
  • secureconnect-pa.clients6.google.com
  • secureconnect-pa.mtls.clients6.google.com
  • secureconnect-pa.googleapis.com
  • chromereporting-pa.googleapis.com