M365 条件付きアクセス→Google Workspace CAA移行：設計マッピング

Microsoft 365 (M365) から Google Workspace (GWS) への移行プロジェクトでは、データ移行と並んでセキュリティポリシーの移植が大きな設計課題になります。この記事では、Entra ID の条件付きアクセス (Conditional Access、以下 CA) と GWS の CAA (Context-Aware Access) のシグナル対応関係をマッピング表で整理し、「何が移せて、何が移せないか」を軸に移行設計の判断軸を示します。

この記事を読んだほうが良い人

• M365 から GWS への移行プロジェクトの中盤以降を担当している情シス担当者
• M365 で Conditional Access を設計・運用した経験があり、GWS CAA との対応関係に悩んでいる人
• GWS 移行後のアクセス制御設計でセキュリティポリシーの継続性を確保したい人
• M365 と GWS のゼロトラスト設計の違いを体系的に把握したい人

M365 CA と GWS CAA：設計思想のギャップを先に把握する

両者の違いを理解しないまま 1:1 対応を試みると、後で設計が行き詰まります。前提として、アーキテクチャの差異を整理します。

M365 の条件付きアクセスは、Microsoft Entra ID（旧 Azure AD）に統合されたポリシーエンジンです。ユーザーがリソースにアクセスしようとする際、ID・デバイス・ネットワーク・リスクスコアなどのシグナルを評価し、「許可」「拒否」「MFA 強制」「セッション制御」といった Grant control / Session control を与えます。

GWS の CAA (Context-Aware Access) は「アクセスレベル」を定義し、Gmail や Drive といった GWS アプリへの接続条件として割り当てる仕組みです。コアアプリ（Gmail / Drive / Meet 等）ではポリシー評価が継続的（リアルタイム）に行われ、SAML アプリではサインイン時のみ評価されます。

重要な構造上の差として、M365 CA は「MFA を強制する」「セッション継続時間を制御する」といった操作まで担いますが、GWS CAA は「この条件を満たさないとアプリに繋がせない」という接続条件の定義のみです。MFA の強制は GWS では 2-Step Verification (2SV) として別系統の管理コンソール設定で管理します。CA が持っていた「認証後の挙動まで制御する」機能の一部は、GWS では CAA 以外の場所に分散します。

必要ライセンスも異なります。M365 CA の基本機能は Entra ID P1 で利用可能ですが、リスクベース条件（サインインリスク・ユーザーリスク）は P2 が必要です。GWS CAA は Cloud Identity Premium または Workspace Enterprise Standard 以上のエディションで利用できます（Enterprise Essentials Plus / Education Standard / Education Plus / Frontline も対象に含まれます）。

シグナル別マッピング表：M365 CA → GWS CAA

移行設計の第一歩は、現行の CA ポリシーで使っているシグナルの棚卸しです。対応度の列では ○（同等）・△（近い設計は可能だが完全に同等ではない）・×（対応なし）の 3 段階で表します。

M365 CA の条件	GWS CAA での対応	対応度
場所：IP アドレス / CIDR（名前付き場所）	IP サブネット（Public）	△ CIDR 指定は可能。名前付き場所の名前管理 UI はない
場所：国・地域	Location（国・地域）	○ 国単位の制限は同等に設定可能
デバイスプラットフォーム	Device OS + バージョン指定	○ OS 種別・最低バージョン指定は同等
デバイスコンプライアンス（Intune 準拠済み）	デバイスポリシー（Endpoint Verification 経由）	△ 全項目対応ではない（後述）
Hybrid Entra ID 参加済みデバイス	会社所有デバイス（Company-owned）	△ 判断根拠が異なる
サインインリスク（Entra ID Protection）	対応なし	×
ユーザーリスク（Entra ID Protection）	対応なし	×
インサイダーリスク（Microsoft Purview）	対応なし	×
レガシー認証ブロック	対応なし（別手段で対処）	× CAA 経路では制御できない
MFA 強制（Grant control）	対応なし（2SV は別系統）	×
フィルター for デバイス（詳細条件）	Advanced mode（CEL 式）	△ 同等機能だが記述方式が大きく異なる
ユーザー属性による絞り込み	Advanced mode（CEL / user.attributes）	△ Admin SDK でのカスタム属性定義が前提
セッション制御（サインイン頻度等）	対応なし	×
アプリ保護ポリシー（MAM）	対応なし	×

デバイス条件の詳細：Intune 準拠 vs Endpoint Verification

M365 CA のデバイスコンプライアンス条件は Intune の準拠ステータスを参照します。Intune では「パスワード複雑性」「BitLocker の強制」「特定ソフトウェアのインストール状態」など、組織が定義した詳細な要件を満たしているかを評価します。

GWS CAA のデバイスポリシー条件は、Endpoint Verification（EV）というエージェントが収集するデバイス情報を参照します。EV が確認できる主な項目は、暗号化の有無・画面ロックの設定・OS バージョン・管理者による承認ステータスなどです。Intune のコンプライアンスポリシーを 1:1 で移植することはできません。

「Hybrid Entra ID 参加済み」という条件についても同様です。Entra ID 参加（ドメイン参加）を根拠にするのではなく、GWS の管理コンソールでデバイスが「会社所有」として登録されているかを根拠にするため、デバイスの管理登録の仕組みを移行と並行して整備しておくことが求められます。

移行設計の観点として、「Intune 準拠済みのみを許可する」というポリシーを GWS CAA に移行する場合は、まず「何を準拠の根拠にするか」を問い直すことから始めます。EV で確認できる範囲（暗号化・OS バージョン・画面ロック）を組み合わせて代替アクセスレベルを設計する、というアプローチになります。

GWS CAA に存在しない機能と代替設計

対応度 × の条件については、CAA 外の手段で補完する設計が必要です。

サインインリスク / ユーザーリスク（Entra ID Protection 相当）

GWS CAA にはリスクスコアの概念がありません。GWS のアラートセンターや Security Investigation Tool で不審なサインインを検知し、管理者が手動でアカウントをサスペンドする運用フローが現実的な代替です。リアルタイムの自動ブロックが必要な場合は、Google Cloud Chronicle や外部 SIEM との連携を検討することになります。Entra ID P2 の動的リスク評価に近い自動化を GWS 単体で実現することは現時点では難しく、この部分はセキュリティ設計上の制約として事前に把握しておくべきです。

MFA 強制（CA の Grant control 相当）

「このアプリにアクセスするときだけ MFA を要求する」という粒度の制御は GWS CAA では実現できません。GWS では管理コンソールのセキュリティ設定から OU 単位で 2SV を強制する設計に切り替えます。全体 2SV 強制と CAA によるアクセス条件の組み合わせが、M365 の「CA + MFA Grant control」に機能的に近い効果を出せます。アプリ単位での MFA 要求ができなくなる点は、移行前に業務部門と合意しておくべき制約です。

セッション制御（サインイン頻度・永続ブラウザセッション）

GWS CAA にはセッション制御機能がなく、Google アカウントのセッション管理は基本的に Google 側のポリシーで制御されます。M365 での「1 時間ごとに再認証を要求する」運用は GWS では再現できません。この制約を許容できない場合は、CAA でのアクセス条件そのものを厳格化（デバイス管理必須・IP 制限など）し、アクセス可能な状況を限定することで代替します。

レガシー認証ブロック

GWS は元々 OAuth 2.0 ベースの認証設計であり、M365 で問題になる SMTP / IMAP / POP などの Basic 認証クライアント問題はほぼ発生しません。移行後にこのポリシーの相当設計を別途構築する必要がないケースがほとんどです。

移行の判断フロー

M365 の各 CA ポリシーを GWS に移行する際は、以下の順序で判断します。

1. ポリシーが守る対象アプリを確認する

Exchange Online / SharePoint を守るポリシーは、GWS 移行後は Gmail / Drive のアクセス条件に読み替えます。ポリシーの目的（「社外から社内データへのアクセスを制限する」「非管理デバイスをブロックする」等）を先に言語化し、対象アプリとのマッピングを先に済ませます。

2. 使用しているシグナルを棚卸しする

上のマッピング表で各ポリシーの条件を確認します。○または △ のシグナルのみで構成されているポリシーは CAA で再設計が可能です。× を含むポリシーは代替設計が必要です。

3. Basic mode か Advanced mode かを選択する

IP・国・OS・デバイスポリシー条件の組み合わせのみなら Basic mode で十分です。時間帯条件やユーザー属性（部署ごとに異なる条件など）が必要な場合は Advanced mode（CEL 式による記述）を選びます。ただし Advanced mode はポリシーの記述ミスで予期せぬユーザーをブロックするリスクがあるため、導入前の検証が欠かせません。

4. Monitor mode で事前検証する

GWS CAA には「Monitor mode」があり、アクセスレベルをポリシーに反映しながら実際にはブロックせず、影響を受けるユーザーを事前確認できます。本番適用前に必ず Monitor mode で検証を行い、意図しないブロックが発生しないかを確認してから Active mode（実際のブロック）に切り替えます。

まとめ：移行設計は「ポリシー目的の再言語化」から始める

GWS CAA は M365 CA のすべての機能を引き受けることができません。リスクスコアベースの動的制御・MFA の細粒度制御・セッション制御は GWS CAA にはなく、代替手段も限定的です。

移行設計の出発点は、現行のすべての CA ポリシーを「何を守るために、どのシグナルを使っているか」という形式で文書化することです。その上でマッピング表と照合し、「GWS CAA で代替できるもの」「CAA 以外の GWS 設定で補完するもの」「一時的に制御精度が下がることを許容するもの」を仕分けてから設計に入ることが、移行プロジェクトの最短経路です。セキュリティポリシーの継続性を移行計画書に明示し、業務部門・経営層との合意を先に取っておくことで、移行後のトラブルを減らせます。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。