Google WorkspaceのCAAとは？認証と認可の違いから学ぶ、安全な設定の始め方

「会社のGoogleアカウントにはログインできるのに、ドライブが開けない」。そんなとき、パスワードを変えれば直るとは限りません。

本人かどうかの確認を通っても、「今の接続環境で、そのアプリを使ってよいか」という別の確認があるからです。

今回はGoogle Workspaceの「コンテキストアウェア アクセス（Context-Aware Access、以下CAA）」を、テーマパークの入口に置き換えて見ていきます。仕事でAIを使う前にも、会社のデータへどこからアクセスしてよいかを知っておくと、相談しやすくなります。

この記事でわかること

• 「認証」と「認可」の違い
• CAAと、端末情報を確認する拡張機能の役割
• 管理者が少人数から設定を試す順番

先にここだけ： 設定の実行は、組織から権限を与えられた管理者が行います。一般利用者は仕組みを知るところまでで大丈夫です。管理者も、いきなり全社員をブロックする設定には進まず、影響確認と元に戻す手順を先に用意しましょう。

CAAは「誰か」に加えて「どんな状況か」を確認する仕組み

先に結論から言うと、CAAは、アプリを使う人の接続状況に応じてアクセスを制御する機能です。

たとえば「会社が認めたネットワークからだけ使う」「暗号化された端末からだけ使う」といった条件を考えられます。ユーザー情報、IPアドレス、地域、端末のセキュリティ状態などが判断材料になります。Google公式：CAAの概要

テーマパークでたとえるなら、入園券を持っているかだけでなく、アトラクションの利用条件も確かめるイメージです。

SAIちゃん「入口を通れたら全部使える、というわけではないんだね。確認する場所が違うとわかると、少し整理できそう！」

CAAは、資料そのものの正しさや、生成AIへ渡してよい内容まで判断するものではありません。アクセスできることと、社外のAIへ資料を渡してよいことは、分けて考えましょう。

認証は「あなたは誰？」、認可は「何を使っていい？」

この2つを覚えると、設定画面を見たときに目的を見失いにくくなります。

ID・パスワードや2段階認証は、本人確認の側です。CAAは、アクセスを許可するかという側の条件を細かくします。本人確認を置き換える機能ではありません。

なお、これは理解のための簡略化です。CAAは「ログイン直後の1回だけの確認」とも限りません。Workspaceのコアサービスでは、利用中もポリシーが継続的に評価されます。アプリの種類によって評価のタイミングは異なります。Google公式：対応アプリと評価

最初につまずきやすい3つのポイント

1．Google Workspaceなら、どの契約でも使えるわけではない

動画ではEnterprise Plusを使っています。まずは、あなたの組織の契約と、対象ユーザーのライセンスがCAAに対応しているか確認しましょう。Enterprise Standard／Plusなどが対応していますが、全エディション共通の機能ではありません。

対応ライセンスを持たない利用者には、同じ組織部門に設定してもCAAの制限が適用されません。「全員に設定したつもり」を避けるため、利用者ごとの確認が必要です。Google公式：対応エディション

2．IP制限と端末の状態確認は、準備が違う

「エンドポイントの確認（Endpoint Verification）」は、端末のOSや暗号化などの情報を管理者が確認するための仕組みです。パソコンで端末条件を使う場合は、対応するChrome環境と拡張機能などを準備します。

一方、IPアドレスや地域だけを条件にするポリシーでは、原則としてエージェントは不要です。CAAを使うならどんな場合も拡張機能が必須、とは覚えなくて大丈夫です。Google公式：プラットフォーム要件

導入時は、利用者にも収集される情報を説明しましょう。公式案内には、端末ID、OS、管理対象のメールアドレス、同期時刻、暗号化やパスワードに関する情報などが挙げられています。環境によって補助アプリが必要になる場合もあります。Google公式：エンドポイントの確認の設定

3．会社のIPを許可しても「会社支給のPCだけ」とは限らない

IPアドレスは、この例ではインターネットへ出るときの「出口の住所」のようなものです。同じ出口を使う別の端末も、IP条件を満たす場合があります。

「会社の回線」と「会社支給の端末」は別の条件です。僕なら、まず何を守りたいのかを一文にしてから、必要な条件を選びます。

管理者向け：会社の回線からだけドライブを使う設定の進め方

ここからは、組織の許可を得た管理者向けの流れです。画面名や項目は変わるため、実行時はリンク先の公式手順と実際の画面を照らし合わせてください。

手順1：試す範囲と、戻す方法を決める

最初は、検証用の少人数の組織部門かグループに絞ります。対象アプリ、対象ユーザー、現在の設定、変更担当者、連絡先をメモしましょう。

管理者が復旧作業をできる経路と、ポリシーの割り当てを元に戻す手順も先に確認します。初回の試験で管理コンソールまで一緒に制限するのは避け、変更対象を小さくします。

手順2：本物の接続元IPを確認する

会社のネットワーク担当者に、Google側から見える送信元のグローバルIPアドレスと、許可すべき範囲を確認します。VPNやプロキシを通す場合、IPv4とIPv6で経路が異なる場合も含めて確認しましょう。

動画や画面例のIPを、そのまま設定に使わないでください。ここでは実際に投入するIP例を載せず、組織で確認した値を使う前提にします。

会社の公開IPは、会社の回線につないで確認する

まず知りたいのは、PCの設定画面に出る内部のIPではなく、インターネット側から見える「出口のIP」です。僕なら、次の順で調べます。

1. 会社の有線LANか、業務用Wi-Fiにつなぎます。 自宅回線、スマホのモバイル通信、テザリング、来客用Wi-Fiでは、別の出口になる場合があります。
2. 会社が利用を認めた公開IP確認ページを、そのPCのブラウザで開きます。 一例はcmanのアクセス情報・グローバルIP確認です。表示されたグローバルIPと、確認した日時・拠点・接続方法を社内用メモに残します。
3. その値を、ネットワーク担当者や回線の管理会社へ確認します。 「このIPは会社専用ですか。固定ですか。IPv6や別の出口もありますか」と聞きましょう。管理者なら、ルーター／ファイアウォールの管理画面のWAN・インターネット接続情報、回線契約の固定IP通知書も照合します。画面名は機器によって異なります。
4. CAAのモニターログでも、実際のGoogleへの接続が意図した条件に合うか確かめます。 Webページで確認できた1つの値だけで、全拠点・全端末の許可範囲が確定したとは扱いません。

ここで外部のIP確認サイトを開いても、確認できるのは「そのサイトへ接続したときの出口」です。VPN、プロキシ、接続先ごとの通信経路、IPv4／IPv6によって、Googleへの出口と違うことがあります。会社のルールに従い、VPNを勝手に解除して調べることは避けましょう。

WindowsのipconfigやWi-Fiの詳細に出る192.168.x.x、10.x.x.xなどは、この公開IP制限へそのまま使う値ではありません。 また、検索結果やこの記事を作るAI側に表示されたIPをコピーしても、あなたの会社のIPにはなりません。

固定IPなら値が安定しやすく、動的IPは変わる場合があります。共有の出口や変動する回線しかない場合は、広いIP範囲を雑に許可せず、固定IPや会社VPNの設計を担当者に相談します。スマホも、会社Wi-Fiからモバイル通信へ切り替えると、通常は別の回線になります。

手順3：CAAの画面でアクセスレベルを作る

管理コンソールの「セキュリティ」→「アクセスとデータ管理」→「コンテキストアウェア アクセス」を開きます。必要な管理権限があるかも確認してください。

アクセスレベルは「利用を許す条件のまとまり」です。公開IPによる制限なら、基本モードで「IPサブネット（公開）」を選び、確認済みのIPv4／IPv6アドレス、またはCIDR形式の範囲を指定します。CIDRは、アドレスの範囲を表す書き方です。許可する範囲に一致したときに条件を満たす向きになっているかも確かめます。

自宅のWi-Fiなどで見かける一般的なプライベートIPを、公開IP欄へ入れる用途ではありません。範囲の指定に迷ったらネットワーク担当者に確認しましょう。Google公式：アクセスレベルの作成

手順4：ドライブに割り当て、まずモニターする

試験対象の組織部門またはグループと、対象アプリを確認して、作成したアクセスレベルを割り当てます。

最初はモニターモードで、条件を強制したら誰が影響を受けるかを確認します。このモードは、実際にアクセスを遮断せずに影響を調べるものです。Googleは新しいアクセスレベルについて、少なくとも1週間のモニタリングを勧めています。Google公式：導入の進め方

「監視」と「有効」を両方選べば安全、という意味ではありません。有効にすると実際の制御につながります。検証段階では、適用状態を確認してから保存しましょう。

手順5：影響を確認してから、有効化する

ログと利用者の状況を見て、次のような場面を確認します。

• 会社の許可された回線からアクセスできるか
• 在宅勤務や外出先で、想定した人が制限対象になるか
• パソコン版ドライブ、スマートフォン、連携ツールの業務に影響しないか
• 困った利用者が、別の連絡経路で担当者へ相談できるか

問題がなければ、少人数のまま有効化して再確認し、段階的に広げます。会社回線だけに制限したい場合は、条件を満たさないときのアクションが「ブロック」になっているか確認します。「警告」は利用を続けられる動作なので、目的に合う選択か見直しましょう。制限時の案内には、担当窓口と利用者が次にすることを短く書きましょう。

アプリの利用制限と、API経由のアクセス設定は分けて確認します。APIはサービス同士をつなぐ仕組みです。連携アプリまでまとめて止めると、バックアップなどの業務へ影響する場合があります。対象アプリや除外設定を確認し、「APIも一括で遮断」に進まないようにしましょう。Google公式：アプリへの割り当て

営業は社外でも使い、権限の多い人だけ回線と端末を絞るには？

「営業や現場担当はスマホ・PCで動けるようにしたい。一方で、重要な資料を扱う人は、会社回線と決めた端末だけにしたい」。そんな分け方もできます。

CAAでは、対象アプリについて、組織部門や設定グループごとにアクセス条件を割り当てられます。ただし、役職名を見て自動で振り分ける仕組みではありません。管理者が対象者をグループに登録し、異動や権限変更に合わせて見直します。Google公式：設定グループでの適用

まずは「役職」より「扱うデータと権限」で分ける

課長でも重要なデータに広くアクセスできる人はいます。反対に、役職者でも社外での業務が多い場合があります。僕なら、肩書きだけでなく、何にアクセスできる人なのかと、どこで働く必要があるのかを一緒に整理します。

これは設計例です。会社回線だけという条件にすると、その人の正当な外出先利用も止まります。VPNを使う場合も、Google側から見える出口IPが本当に許可範囲になるか、ネットワーク担当者と確認しましょう。

営業に「CAAの追加制限を設けない」設計も考えられますが、上位の組織部門や別グループから制限を受けていないかの確認が必要です。また、CAAの制限がないことは、認証・共有権限・端末管理などの会社ルールもなくなるという意味ではありません。

組織部門を作り直さず、横断するグループで分ける

組織部門は部署ごと、設定グループは部署をまたぐ対象者のまとまり、と考えると整理しやすくなります。たとえば「重要データ取扱者」という設定グループに、役員・経理責任者・管理権限の多い担当者を集める形です。

グループ設定は組織部門の設定より優先します。複数の設定グループに所属している場合は、アプリごとに設定された優先順位が効きます。各グループの制限が全部足されるわけではありません。営業も兼務する役職者などは、どのグループがそのアプリの条件を決めているか確認しましょう。Google公式：グループの優先順位

「会社IP」と「承認済み端末」はANDで組み合わせる

重要データ取扱者には、たとえば次のような1つのアクセスレベルを作る設計にします。

1. 接続元が、組織で確認した会社の公開IP範囲に一致する。
2. 使う端末が、管理者によって承認されている。
3. 1と2の両方が必要（AND）になるよう組み合わせる。

「会社IP」「承認済み端末」という2つのアクセスレベルをアプリに別々に割り当てるだけでは、基本的にORになります。会社回線なら未承認端末でも、または承認端末なら社外回線でも条件を満たす設計になり得るため、ここは特に確認したいところです。Google公式：アクセスレベルの作成・アプリへの割り当て

「承認済み」は「会社所有」と同じ意味ではありません。私物の端末でも管理者が承認すれば承認条件を満たし得ます。会社支給だけにしたい場合は、会社所有という条件や端末の登録情報も確認します。指定した端末だけを許す運用なら、承認対象の台帳と追加・撤去の手順まで決めておきましょう。

スマホはPCと同じ準備をそのまま使わない

PCの端末条件ではEndpoint Verificationなどを準備しますが、スマホはGoogleエンドポイント管理側の要件を確認します。対応OS、使うアプリ、端末情報が同期されるまでの時間も異なります。

特に、Android 12以降の仕事用プロファイルがある端末では、会社所有として登録していてもユーザー所有として報告されるケースがあります。「会社所有だけ」を条件にする場合は、実際に判定される属性を確認してください。スマホのブラウザとアプリを同じ扱いとも決めつけず、営業が実際に使う経路で試します。Google公式：端末・プラットフォームの要件

PCを「この端末はOK」にするまでの操作

「少人数で試す」は対象者の範囲の話、「承認済み端末」はPCなどの機器の状態の話です。PCを承認対象として管理画面へ載せ、その承認状態をCAAの条件に使う、という順番になります。

以下は、Endpoint VerificationでPCを確認する場合の例です。すでに端末管理を導入している会社では、現在の管理方式に合わせて担当者が判断します。

1. 管理者：対象PCの情報収集を準備。 管理コンソールの「デバイス」→「モバイルとエンドポイント」→「設定」→「一般」→「データアクセス」→「デバイス シグナル」で、対象の組織部門の「Endpoint Verification を使用してデバイス シグナルを収集する」を確認します。Google公式：エンドポイントの確認の設定
2. 管理者：手動承認を必須にする設定を確認。 「デバイス」→「モバイルとエンドポイント」→「設定」→「ユニバーサル」→「セキュリティ」→「デバイスの承認」で、対象の組織部門に管理者承認を求める設定を検討します。適用すると既存業務へ影響する場合があるため、まず検証用の範囲で確認します。
3. 利用者：会社指定のChrome環境で登録・同期。 Endpoint Verification拡張機能を会社の手順で導入し、仕事用アカウントでサインインします。必要と案内された場合は補助アプリを設定し、拡張機能の「今すぐ同期」を実行します。Google公式：利用者向け設定
4. 管理者：端末を照合して承認。 「デバイス」→「モバイルとエンドポイント」→「デバイスの承認」を開き、申請されたPCの利用者、機種、シリアル番号などを社内台帳と照合します。許可する端末を選び、「その他」→「デバイスを承認」で承認します。PCが見当たらない場合は、アカウント・情報収集設定・同期状態を確認します。
5. 管理者：CAAへつなげる。 アクセスレベルのデバイスポリシーで「管理者の承認が必要」を条件にします。社内限定なら公開IP条件とANDで組み合わせ、必要な人とアプリへ割り当てます。まずモニターし、同期後の状態を確認してから小さく有効化します。

「拡張機能を入れた」「端末一覧に出た」だけでは、手動で選んだPCだけを許す設計にはなりません。 承認必須を設定しない場合は、端末が既定で承認されることがあります。会社所有として登録された端末など、一部は自動承認される場合もあります。既存端末と自動承認ルールも含め、誰が何を承認済みにしているかを確認しましょう。Google公式：承認必須の条件と例外

また、Endpoint Verificationの承認・ブロックは、CAAで使える状態タグです。端末一覧で「ブロック」にしただけで、すべてのGoogleデータへのアクセスが止まるわけではありません。CAA側で、その状態をアクセス条件に使う設定まで必要です。Google公式：デバイス承認の動作

スマホを「この端末はOK」にするまでの操作

スマホにもPC用のChrome拡張機能を入れればよい、という流れではありません。個別の管理者承認を必須にする運用では、Android・iPhoneともに詳細なモバイル管理が必要です。基本管理で端末情報が見えることと、個別承認を使えることは分けて考えましょう。Google公式：管理者承認の要件

1. 管理者：契約と管理方式を確認。 「デバイス」→「モバイルとエンドポイント」→「設定」→「ユニバーサル」→「全般」→「モバイル管理」で、検証対象の組織部門の管理方式を確認します。詳細管理へ進める場合は、対応ライセンス・OS、既存の管理サービスとの関係、利用者への説明を先に確認します。
2. 管理者：承認必須と必要な端末ルールを準備。 ユニバーサル設定の「セキュリティ」→「デバイスの承認」で管理者承認を求める設定を行い、画面ロックなどの要件も定めます。会社全体へまとめて変更せず、試験範囲から始めます。
3. Android利用者：仕事用アカウントを追加し、画面の案内で登録。 必要に応じてAndroid Device Policyや仕事用プロファイルの設定へ進みます。アプリ名だけを頼りに先に手動インストールせず、会社の登録案内に従います。
4. iPhone利用者：会社の登録案内に従い、アプリや管理プロファイルを設定。 管理者側ではAppleプッシュ通知証明書などの準備が必要です。構成プロファイルやGoogle Device Policyの案内は管理方式によって変わります。端末を消去したり、既存の管理プロファイルを勝手に外したりする手順ではありません。Google公式：詳細なモバイル管理の設定
5. 管理者：申請された実機を照合して承認。 「デバイスの承認」で、利用者と端末IDなどを台帳に照らし、対象スマホを承認します。承認済みという状態に加え、暗号化やOSなど必要な属性が同期されているか確認します。
6. 管理者と利用者：実際に使うアプリで試験。 まずCAAをモニターし、その後小さな範囲で有効化します。承認済みのスマホで必要なアプリが使えるか、未承認端末では意図した制限になるかを確認します。スマホアプリへのCAA適用範囲や、デスクトップ・モバイルアプリにも条件を適用するポリシー設定を見落とさないようにします。

スマホを承認しても、CAAが「会社IP AND 承認済み端末」なら、会社の外のモバイル通信ではIP条件を満たさず止まります。営業は社外でも使いたい、という場合は営業向け条件に会社IP制限を付けない設計などを検討します。端末の承認だけで、IP条件が免除されるわけではありません。

SAIちゃん「PCもスマホも、まず登録して、管理者が確かめて、その状態をCAAの条件に使うんだね。『承認したら、どこからでも使える』とは限らないところも覚えておこう！」

僕なら、営業と重要データ取扱者の2人で試します

最初は2つの働き方を代表する検証用アカウントを用意します。重要データ取扱者には「会社IP AND 承認済み端末」、営業には予定した緩い条件を割り当て、まずモニターで影響を見ます。

そのうえで、小さな試験範囲でブロックを有効にし、「会社回線＋承認済みPCでは使える」「会社回線＋未承認PCでは止まる」「社外回線＋承認済みPCでも止まる」を確かめます。営業は社外のPCとスマホで必要な業務ができるかを確認。両グループを兼務する人も試験に加えると、優先順位の見落としに気づきやすくなります。

なお、CAAは対象アプリへのアクセス条件を決める仕組みです。「営業はこのフォルダだけ」「役員は別の機密ファイルも読める」といった資料ごとの権限は、ドライブの共有設定などで別に管理します。

設定前に避けたいこと

• 見本のIPで本番設定すること。 許可すべき利用者を止めてしまう原因になります。
• ログを見ずに全社員へ広げること。 まずは小さな試験範囲で確認します。
• 複数のアクセスレベルを選ぶだけで「全部必要」になると思うこと。 アプリに複数割り当てた場合は基本的にOR、つまりどれかを満たせば許可されます。両方必要ならANDになるよう条件を設計します。Google公式：割り当て時の条件
• CAAでデータへの全経路を制限できると思うこと。 サービスアカウントからのGoogle APIアクセスは、このポリシーの制限対象ではありません。機械用のアカウントや別経路は、別途管理が必要です。Google公式：適用範囲

かずまの実践メモ：僕なら、設定前にこの3行を書きます

僕なら、まず次の3行を埋めます。これは実機検証の体験談ではなく、今回の仕組みを導入するなら、という進め方の提案です。

1. 守りたいもの： 会社のドライブにある業務資料。
2. 許可したい条件： 組織で確認した会社回線から、検証ユーザーが利用する。
3. 困ったときの戻し方： 変更前の記録を見ながら、試験ポリシーの割り当てを元に戻す。

この3行を説明できると、「どこをクリックするか」より先に、設定の目的を共有できます。

AIに相談するなら、実在のIP、アカウント、社内資料は渡さず、架空の条件に置き換えて声で伝えるところから始めましょう。音声を使えない場所では文字でも大丈夫です。

「架空の会社で、Google Workspaceのドライブを会社回線からだけ使う試験を考えています。認証と認可の違いをやさしく説明して、モニターモードで確認したい項目を整理してください。実際の設定値は提案せず、公式情報で確認する点を挙げてください」

返ってきた答えは、管理者が公式手順と照合するためのたたき台です。個人情報、会社の秘密、未公開資料はAIへ入れず、設定の最終判断は担当者が行います。

今日の一歩：設定する前に「自分の役割」を確認する

一般利用者なら、会社の管理者へ「この端末と回線から使ってよいですか」と確認してみましょう。ブロックを回避するために個人アカウントへ業務資料を移すのは避けます。

管理者なら、今日は契約の対応状況、検証対象、復旧経路を確認するところまで。準備ができたら、モニターモードで小さく試します。

パークの入口を全部覚えるより、「ここでは何を確かめているのか」がわかると、次の画面でも考えやすくなります。まずは認証と認可を、あなたの言葉で一度説明してみてください。

---

確認日：2026年10月18日。 管理コンソールでの実設定は行っていません。提供条件や画面は変わるため、導入時は本文のGoogle公式リンクで確認してください。