Endpoint Verification 段階的導入の3フェーズ展開設計

Endpoint Verification（エンドポイント検証、以下 EV）は、デバイスのセキュリティ状態を Google Workspace に報告する Chrome 拡張機能です。この記事では、EV を段階的に展開するための3フェーズ設計と、各フェーズで確認すべき実務チェックリストを整理します。

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

• Google Workspace で EV の導入を検討しているが、ユーザー影響を懸念して踏み切れていない情シス担当者
• EV と CAA（Context-Aware Access）を連携させたデバイスベースのアクセス制御を設計したい方
• 100名規模の組織で、管理外デバイスからのアクセスリスクを段階的に低減したい方
• 「いつ Block に移行するか」の判断基準を言語化できておらず、前進できずにいる方

Block一斉展開で起きること

EV は単体ではアクセスを制限しません。EV が収集したデバイス情報を CAA のアクセスレベル条件として設定し、そのポリシーをアプリに割り当てた時点で初めてアクセス制御が機能します。

問題が起きやすいのは「EV をインストールしていないデバイスが残っている状態で、EV 必須の CAA ポリシーを全員に一斉適用した」パターンです。EV 未インストールのデバイスからは、Workspace アプリへのアクセスが即座に失われます。具体的には次のようなケースが巻き込まれやすい。

• Chrome 以外のブラウザ（Firefox・Safari・Edge）をメインで使っているユーザー
• iOS・Android のスマートフォンやタブレットからアクセスしているユーザー（モバイルアプリ経由はEVの対象外）
• 拡張機能のインストールが完了しているつもりだったが、古いバージョンのままになっていたケース
• 社外から個人PCで業務をしている在宅勤務者（管理外デバイス）
• 社外パートナーや業務委託スタッフに共有しているアカウント

こうした事態を防ぐのが、フェーズを分けた展開設計です。「最初から全員に適用する」のではなく、影響範囲を把握してから段階的にポリシーを有効化することで、ヘルプデスクへの問い合わせ急増とユーザーの業務停止を回避できます。

3フェーズ展開フローの全体像

EV と CAA を使ったデバイス管理の展開を、次の3フェーズに分けて設計します。

以下のフェーズ設計が基本の枠組みです。組織の規模・デバイス構成・ユーザーの IT リテラシーに応じて、各フェーズの期間を前後させてください。

フェーズ	目的	CAA ポリシーの状態	期間目安
フェーズ1（Warn期）	EV 展開とデバイス状況の可視化	作成しない or 未割り当て	2〜4週間
フェーズ2（Monitor期）	ポリシー適用シミュレーション	モニターモードで割り当て	1〜2週間
フェーズ3（Block期）	本番適用・アクセス制限の実施	アクティブモードで割り当て	継続運用

フェーズ2で使う「モニターモード」は CAA の公式機能で、実際にアクセスを制限せずに「このポリシーを適用したら誰がブロックされるか」を監査ログに記録できます。このモードを活用することが、段階的展開の核心です。モニターモードを省略してフェーズ1からフェーズ3に直接移行する判断は、原則として避けてください。

EV が収集するデバイス情報の把握

フェーズ1に入る前に、EV が何を収集するかを把握しておくことが重要です。CAA のアクセスレベル条件に使える情報は、EV が報告するデータに限られるからです。

EV が管理コンソールに報告する主な情報は以下の通りです（Google Workspace 管理者向けヘルプより）。

• OS の種類とバージョン（Windows / macOS / Linux / ChromeOS）
• ディスク暗号化の有効・無効
• スクリーンロック（パスワード要求）の設定状態
• ファイアウォールの有効・無効
• Chrome ブラウザのバージョン
• デバイスが管理対象かどうか（管理ステータス）

これらのうち、組織として「最低限このレベルを満たしているデバイスのみ許可する」と設定したい条件を事前に決めておきます。例えば「ディスク暗号化が有効、かつ OS が Windows 10 以降 / macOS 12 以降」のような条件を設計段階で決定しておくと、フェーズ1でのデータ収集と実態確認が目的を持って進みます。

なお、iOS・Android のモバイルデバイスは EV の対象外です。スマートフォンからのアクセスを制御したい場合は、MDM（モバイルデバイス管理）や CAA の IP アドレス条件など、別の手段を組み合わせる必要があります。

フェーズ1チェックリスト：EV 展開とデバイス可視化

フェーズ1の目標は「どのデバイスが EV を使えるか、どのデバイスには使えないか」を把握することです。CAA ポリシーの適用はまだ行いません。

以下の項目を順に確認してください。

• [ ] 展開対象の OU（組織部門）の範囲と順序を決定した
• [ ] Chrome 拡張機能の配布方法を確定した（Chrome Enterprise 管理 / マニュアルインストール / BYOD のセルフインストール）
• [ ] EV に対応しないデバイスや環境を事前にリストアップした（iOS / Android / 古い OS / Chrome 以外のブラウザ利用者など）
• [ ] 管理コンソールのデバイス画面で、EV データが収集されていることを確認した
• [ ] 収集された情報の項目（OS バージョン、ディスク暗号化、ファイアウォールなど）が、設計予定のポリシー条件と一致するか確認した
• [ ] CAA のアクセスレベル条件に使う予定のデバイス属性について、対象デバイスの充足率（例：「ディスク暗号化が有効なデバイスは何割か」）を把握した
• [ ] ヘルプデスクに「EV 展開中である」旨を共有し、問い合わせへの対応準備をした

フェーズ1はユーザーへの直接影響が出ないため、展開そのものは比較的スムーズに進みます。ただし、EV が報告しないデバイスの存在が後続フェーズに大きく影響します。「インストールしたつもり」を鵜呑みにせず、管理コンソールのデバイス一覧から実際の登録状況を確認してください。

EV のインストール率が 70〜80% に届かない場合は、フェーズ2への移行を焦らないことが大切です。原因を特定（古い OS のユーザーが多い、Linux ユーザーが対応できていないなど）し、代替策を準備してからフェーズ2に進みます。

フェーズ2チェックリスト：CAA モニターモードでの影響確認

フェーズ2の目標は「このポリシーを適用したら誰がブロックされるか」をゼロリスクで把握することです。CAA のモニターモードを使うと、実際にアクセスを制限せずにブロック対象ユーザーを監査ログに記録できます。

以下の項目を確認しながら進めてください。

• [ ] 設定しようとしている CAA アクセスレベルの条件を確定した（OS バージョン、ディスク暗号化状態など）
• [ ] 対象アプリに CAA ポリシーをモニターモードで割り当てた（アクセスは制限されない）
• [ ] 1〜2週間の観測期間を設け、監査ログでブロック対象となるアクセスを確認した
• [ ] ブロック対象の中に「例外にすべきケース」が含まれていないかレビューした
• [ ] 例外 OU への割り当て除外を設計・実施した（例外パターンは後述）
• [ ] モニター期間中のブロック予定件数が十分に低い水準に収まっていることを確認した
• [ ] ユーザーへの周知コミュニケーションを実施した（周知テンプレートは後述）

監査ログでは、モニターモード中にブロック対象となったアクセスの「ユーザー・デバイス・日時・アクセス先アプリ」を確認できます。単純に件数を見るだけでなく、「同じユーザーが毎日ブロック予定になっている」「特定部門のデバイスが集中してひっかかっている」といったパターンを分析し、例外 OU の設計や展開前のフォローに活かします。

フェーズ3チェックリスト：Block適用と本番運用開始

フェーズ3は「モニターモードをアクティブに切り替える」フェーズです。一度 Block を有効にすると、対象外デバイスからのアクセスは即座に制限されます。

以下の項目がすべて完了していることを確認してから切り替えてください。

• [ ] フェーズ2のモニター期間で想定外のブロック対象が解消されていることを確認した
• [ ] 例外 OU の設定が完了しており、意図せず巻き込まれるユーザーがいないことを確認した
• [ ] ヘルプデスクに「○月○日から Block が有効になる」ことを事前共有した
• [ ] 適用前日にユーザー向けの最終周知を行った
• [ ] CAA ポリシーをモニターモードからアクティブモードに切り替えた
• [ ] 切り替え後24〜48時間は監査ログと問い合わせ件数を重点モニタリングした
• [ ] 想定外のブロックが発生した場合の緊急ロールバック手順を確認しておいた

切り替え直後の24〜48時間は、どれだけ準備しても予期しない問い合わせが来ることがあります。ヘルプデスクが Block 原因のトラブルシューティングを自己解決できる手順書（「EV が入っていない場合の対処」「Block されたとき情シスへの連絡方法」など）を事前に渡しておくと、対応コストを大幅に下げられます。

例外OU設計のパターン

全員に同一ポリシーを適用することが現実的でないケースは必ず存在します。よくある例外パターンを4つ整理します。

パターン1：管理者・IT担当者 OU

情シス担当者自身が EV 適用対象外になってしまうと、トラブル対応中に自分がロックアウトされるリスクがあります。IT 担当者は専用 OU に分け、Block ポリシーの対象から除外しておくことが基本です。ただし、この OU を「なんでも除外する避難場所」にしないよう、対象者リストは定期的に棚卸しします。

パターン2：EV 非対応デバイス利用者 OU

iPad や Android のみを使うスタッフ、古い OS を利用せざるを得ない特定業務ユーザーなどは、EV のデータが報告されないケースがあります。これらのユーザーをグループ化し、IP アドレス制限など EV 以外の条件で代替のセキュリティ制御を設計します。「除外するから何もしない」ではなく、別のアクセスレベルで対処することが重要です。

パターン3：外部委託・パートナー OU

社員と異なるデバイス管理ポリシーが適用される外部スタッフは、別 OU で管理し、個別のアクセスレベルを設計します。Google グループで管理し、CAA 割り当てを OU ではなくグループ単位で行う方法も有効です。

パターン4：段階ロールアウト用の先行 OU

全社一斉に Block を適用するのではなく、IT 部門→特定部門→全社という段階で展開する場合は、段階ごとに対象 OU を区切ります。先行 OU での Block 期間の問い合わせ傾向を見て、残りの OU への展開スケジュールと例外設計を調整できます。規模が大きい組織ほど、この段階的な OU 展開が現実的です。

Block移行の判断基準

モニターモードから Block へ移行するタイミングは、次の4条件を目安に判断します。あくまで参考基準であり、組織の実態に合わせた調整が必要です。

• 対象 OU に含まれるデバイスの EV レポート率が 95% 以上になっていること
• モニターモードで観測された「ブロック予定アクセス」の件数が、全アクセスの 3% 未満に収まっていること
• ブロック予定となっているアクセスのうち、意図的に例外にすべきケースが解消済みであること
• ヘルプデスクへの EV 関連問い合わせが安定しており、ユーザー側の準備が整っていること

これら4条件がすべて揃ったときが Block 移行の目安です。1つでも満たされない場合はフェーズ2を延長し、原因を特定してから移行します。「早く終わらせたい」という焦りが、後のヘルプデスクパンクにつながります。

EV レポート率の実数は、管理コンソールのデバイス管理画面で確認できます。対象 OU のデバイス総数と EV データが届いているデバイス数を比較して計算します。この数字が90%を超えない場合は、未登録デバイスの所有者をリストアップして個別フォローする工程が必要です。

ユーザー向け周知文テンプレート

Block 適用前の周知は2段階が基本です。以下はそのまま転用できる文例ですが、組織の文化や言葉遣いに合わせて調整してください。

Block 適用の2週間前（初回周知）

件名：【情報セキュリティ】Workspace アクセスの新しい要件について

○○日より、会社の Google Workspace アプリ（Gmail、ドライブ等）にアクセスするには、お使いのパソコンに「Endpoint Verification」Chrome 拡張機能のインストールが必要になります。まだインストールが完了していない方は、添付の手順書を参照してください。ご不明な点は情シスまでご連絡ください。

Block 適用の前日（最終周知）

件名：【明日適用】Workspace アクセス要件の変更について

明日○○日より、Endpoint Verification 拡張機能が未インストールのデバイスからは Google Workspace にアクセスできなくなります。本日中に準備が完了しているかご確認ください。問題がある場合は本日中に情シスへご連絡ください。

周知文には「問い合わせ先と連絡方法」を必ず明記します。「情シスまで」だけでは不十分で、Slack チャンネル名・メールアドレス・電話番号など、ユーザーがすぐ動けるチャネルを具体的に書いてください。また、スマートフォンからのアクセスが多い組織では「スマートフォンからのアクセスは別の方法で対応予定」といった注記を加えると、混乱を防げます。

Block適用後の継続運用

Block を有効にした後は「設定して終わり」ではありません。以下の継続運用が必要です。

新入社員・デバイス交換時の対応

新しいデバイスに EV が未インストールの状態で入社・交換されると、そのユーザーは即座にアクセスできなくなります。オンボーディング手順書に「EV のインストール」を必須ステップとして組み込み、IT セットアップ時に完了させる流れを作っておきます。

例外 OU の定期棚卸し

例外 OU は「一時的な措置」として設計した場合でも、放置すると恒久化します。四半期ごとに例外 OU のメンバーリストを見直し、Block 対象に移行できるユーザーがいないか確認してください。特にパターン2（EV 非対応デバイス利用者）は、OS アップグレードや端末更新によって状況が変わることがあります。

CAA ポリシーの条件バージョン管理

OS の最低バージョン要件などは、時間の経過とともに見直しが必要です。例えば「Windows 10 以降」という条件を設定した場合、Windows 10 のサポート終了以降は「Windows 11 以降」への更新が求められます。CAA のアクセスレベル条件を更新する前には、必ずモニターモードで影響確認を行う習慣をつけます。

まとめ：フェーズを守ることが「失敗しない展開」の本質

EV の段階的展開で最も重要なのは、モニターモードを省略しないことです。フェーズ2をスキップして Block に移行した組織では、大半のユーザーは問題なかったが、残り数%の対応でヘルプデスクがパンクするというパターンを繰り返しています。

EV はデバイスの状態を可視化する仕組みとして優れていますが、その価値が最大化されるのは CAA と組み合わせてアクセス制御に活用したときです。段階的な展開設計と例外 OU の丁寧な設計が、組織全体のスムーズな移行を支えます。

EV だけで解決できない課題（モバイルデバイス管理・社外パートナーのアクセス制御など）は、MDM や IP アドレス条件などと組み合わせて対処します。EV・CAA・MDM それぞれの役割と適用範囲の整理については Google Workspace MDM・EV・CAAの使い分け も参照してください。CAA モニターモードの詳しい活用方法は Context-Aware Access モニターモードでゼロショック導入を実現する をあわせてご確認いただくと、フェーズ2の設計がより具体的に進みます。

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

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