Netskope の Google CASB API が BYOP へ移行。Google / GCP 側で先に準備が必要なことは？

こんにちは、セキュリティチームのHitomiです。

Netskope から「Google Workspace との連携方式が変わります」というアナウンスを受け取った方がいらっしゃるかと思います。

ざっくり言うと、Google CASB API が使う GCP プロジェクトが、これまでの Netskope 共有プロジェクトから、お客様ごとの自前プロジェクトに変わる、という話です。

期限は 2026年9月30日。

アナウンス文の「対応手順」は Netskope テナントの操作から書き始められているのですが、実際に手を動かすと分かることがあります。作業量の大半は Netskope ではなく、Google Cloud と Google 管理コンソールです。

この記事では、Google 側の準備を中心に整理します。

0. はじめにまとめ

① 期限は 2026年9月30日。
Netskope 公式ドキュメントは "well before September 30, 2026" と書いています。過ぎると共有サービスアカウント経由の次世代 API データ保護がレート制限で劣化する可能性があります。

② Google 側の事前準備があります。
GCP プロジェクト作成 → 必要な API 有効化 → サービスアカウント作成 → JSON キー発行 →（Gmail のみ Pub/Sub 管理者ロール付与）→ Google 管理コンソールでドメイン全体の委任。Netskope 側は最後に値を貼るだけです。

③ GCP と Google Workspace の管理権限が必要です。
GCP 側は、プロジェクト作成と API・サービスアカウントの設定ができる権限（新規作成ならプロジェクト作成者）、Google Workspace 側は、ドメイン全体の委任を設定できる特権管理者（super admin）が必要です。詳しくは 3-1 で説明します。

［出典: Bring Your Own Project (BYOP) for Google Apps / Access control for projects with IAM（Google Cloud） / Create access credentials（Google Workspace）］

1. なぜ今この変更なのか

Google は Workspace API に標準の利用枠（standard usage quota）と課金の枠組みを導入しました。公式の記述は次のとおりです。

• 対象は Gmail API / Google Calendar API / Google Drive API
• 2026年5月1日 から、新規作成プロジェクトに新しい利用枠が適用
• 既存プロジェクトには少なくとも 60日前 の通知
• 標準の日次しきい値を超えた分は Google Cloud の請求対象になる予定。課金の詳細は「2026年後半」に、少なくとも90日前の告知を伴って共有される

［出典: Google Workspace standardized model for agent tools and APIs / Agent tools and security updates for Google Workspace developers（Workspace Updates, 2026年5月）］

つまり API 呼び出しのコストを、プロジェクトの持ち主が負担する構図になります。Netskope が全顧客分を1つの共有プロジェクトに束ねていると、共有枠のレート制限を全員で奪い合うことになる・・・というのが、BYOP に踏み切った理由です。

無償枠のしきい値（2026年8月時点の公式値）

日次しきい値は 引き上げ申請ができない 点が共通しています。また、2025年11月〜2026年4月に対象 API を利用していた既存プロジェクトは、従来の利用枠が少なくとも60日間維持されます。

［出典: Gmail API Usage limits / Drive API Usage limits / Calendar API Usage limits］

2. 自社が対象なのかを確認するには？

［出典: Bring Your Own Project (BYOP) for Google Apps］

判定に迷ったら、Netskope テナントで実際にインスタンスの設定値を見るのが確実です。ただし、確認する場所は構成パターンごとに違うので、手順を2つに分けます。

手順A：Classic を利用しているかの確認

1. Netskope テナントで Settings > Configure App Access > Classic を開く
2. Google アプリ（Google Drive / Gmail など）のインスタンスが存在するか確認する。存在すれば Classic 利用中＝移行対象です（手順Bの次世代側にもインスタンスがある場合は「両方を利用中」のパターンになります）

手順B：次世代インスタンスが BYOP 済みかの確認

1. Netskope テナントで Settings > Configure App Access > Next Gen > CASB API を開く
2. Google Drive / Google Calendar / Gmail の対象インスタンスを選択し、Edit で設定画面を開く
3. サービスアカウントのメールアドレス欄の値を確認する

   

チェックするのは、メールアドレスの @ より後ろです。GCP のサービスアカウントは必ず以下の形式で、所属する GCP プロジェクトの ID がそのまま埋め込まれています。ここを見れば、誰のプロジェクトのサービスアカウントかが一目で分かります。

<サービスアカウント名>@<GCPプロジェクトID>.iam.gserviceaccount.com

• 自社で作成した GCP プロジェクトの ID になっている（例: ng-casb-api-gmail@your-company-casb.iam.gserviceaccount.com）→ BYOP 済み。追加の対応は不要です
• 自社に心当たりのないプロジェクト ID になっている（インスタンス作成時にプリセットされていた値のまま）→ 共有プロジェクトのまま。移行対象です

補助的な切り分けとして、インスタンスの作成日も使えます。上の表のとおり、2026年8月10日以降に作成した次世代インスタンスは作成時点で BYOP なので確認不要、それより前に作成したものは要確認です。

補足：「自社のプロジェクト ID かどうか」を確認する方法

「この ID、自社のプロジェクトだっけ？」と迷ったら、GCP 側で自社が保有するプロジェクトの一覧と突き合わせます。

1. プロジェクトセレクタで検索する：console.cloud.google.com にログインし、上部のプロジェクトセレクタを開いてすべてタブを選択すると、自分が閲覧できる組織配下のプロジェクトを検索できます。検索ボックスに、サービスアカウントのメールアドレスの @ より後ろのプロジェクト ID をそのまま入力してください
2. リソースの管理で一覧表示する：コンソール上部の検索バーで「リソースの管理（Manage Resources）」と検索するか、console.cloud.google.com/cloud-resource-manager に直接アクセスして確認します。照合するのは「名前」列ではなく ID 列です。プロジェクト名と ID は別物で、名前は後から変更できますが、ID は作成後に変更できないため確実な照合キーになります

CLI 派の方は gcloud でも確認できます。

# 該当 ID のプロジェクトが自分の見える範囲に存在するか確認
gcloud projects list --filter="projectId:<確認したいプロジェクトID>"

# または直接照会（存在しない、または閲覧権限がない場合はエラー）
gcloud projects describe <確認したいプロジェクトID>

［出典: プロジェクトの作成と管理（Google Cloud）］

3. Netskope の画面を開く前に、Google 側で終わらせること

ここからが本題です。順番を守らないと後戻りが発生するので、この並びで進めてください。

3-1. 作業に必要な権限は？

必要な権限は2種類あります。

• GCP 側: プロジェクトを作成し、API を有効化し、サービスアカウントと JSON キーを作れる権限。IAM ロールで言うと、新規プロジェクトを作るなら組織レベルのプロジェクト作成者（roles/resourcemanager.projectCreator）で足ります。
  
  作成した本人は自動でそのプロジェクトのオーナー（roles/owner）になるので、API 有効化からキー発行までそのまま完結します。既存プロジェクトを利用する場合はオーナー相当の権限があれば一通りの作業を行えます。
  • 最小権限で分けるなら、Service Usage 管理者（roles/serviceusage.serviceUsageAdmin・API 有効化）＋サービスアカウント管理者（roles/iam.serviceAccountAdmin・サービスアカウント作成）＋サービスアカウントキー管理者（roles/iam.serviceAccountKeyAdmin・JSON キー発行）が必要です。
  • さらに Gmail でサービスアカウントに Pub/Sub 管理者を付与する場合は、プロジェクト IAM 管理者（roles/resourcemanager.projectIamAdmin）など、プロジェクトの IAM ポリシーを変更できる権限が必要です
• Google Workspace 側: 特権管理者（super admin）。ドメイン全体の委任の設定と、Netskope 側での認証に使う API 管理者アカウントの用意に必要です

Netskope のドキュメントは Drive / Calendar / Gmail いずれの手順でも「super admin」の権限を前提にしています。

［出典: Configure Google Drive for the Next Generation API Data Protection］

3-2. GCP プロジェクトを用意する

専用の GCP プロジェクトを新規作成するか、要件を満たす既存プロジェクトを用意します。既存プロジェクトを利用する場合は、必要な API の有効化、サービスアカウントと JSON キーの作成、必要に応じた IAM ロールの付与が可能かを事前に確認してください。

1つのプロジェクトで複数の Google アプリインスタンスを賄うことも可能で、その場合はアプリごとに必要な API をすべて有効化しておく必要があります。

3-3. 有効化する API はアプリごとに違う

「Google だから同じでしょう」で進めると、後から認証エラーになります。

Calendar で Drive API が要る点と、Gmail で Cloud Pub/Sub API が要る点は、初見だと引っかかりやすいポイントです。

Gmail は Pub/Sub でイベントを受ける構成のため、API の有効化だけでなく後述のロール付与も必要です。

有効化の手順（コンソール）

1. console.cloud.google.com にログインし、上部のプロジェクトセレクタで作成したプロジェクトを選択していることを確認します（別プロジェクトで有効化してしまうのがありがちな失敗です）
2. API とサービス > API ライブラリを開き、上部の検索バーに API 名（例: Admin SDK API）を入力して該当 API のページを開き、有効にするをクリックします

   

3. 上の有効化が必要な APIの表を見ながら、対象アプリに必要な API の数だけ繰り返します

CLI 派の方は gcloud でまとめて有効化もできます。

# 例: Gmail 用プロジェクトの場合
gcloud services enable admin.googleapis.com gmail.googleapis.com pubsub.googleapis.com --project <PROJECT_ID>

（サービス名の対応: Drive は drive.googleapis.com、ラベルバッジ利用時は drivelabels.googleapis.com、Calendar は calendar-json.googleapis.com）

有効化漏れの症状

有効化を1つでも忘れると、Netskope 側の Grant Access や初回スキャンの段階で 403 accessNotConfigured（"API has not been used in project ... before or it is disabled" というメッセージ）が返ります。

エラー文中にプロジェクト番号と API 名が入っているので、「どのプロジェクトのどの API が無効か」はエラーを読めば特定できます。逆に言うと、このエラーが出たら真っ先に疑うのはスコープではなく API の有効化漏れです。

［出典: Configure Google Drive / Configure Google Calendar / Configure Gmail］

3-4. サービスアカウントと JSON キー

① サービスアカウントの作成

1. 同じ GCP プロジェクトで IAMと管理 > サービスアカウント > + サービスアカウントの作成 を開く

   

2. 名前と説明を入力する。
   Gmail の推奨名は ng-casb-api-gmail、説明は Service account for CASB Gmail。
   Drive / Calendar 用も ng-casb-api-gdrive のように同じ規則で揃えておくと、後から見た人が用途を判別しやすいです
3. 「このサービスアカウントにプロジェクトへのアクセスを許可する」のロール付与はスキップして構いません。Workspace データへのアクセス権はプロジェクトのロールではなく、後述のドメイン全体の委任で与えるためです
   • Gmail の場合のみ、後述の③で Pub/Sub 管理者ロールを付与します。
4. 完了 をクリックして作成を完了する

② メールと一意のIDを控える

作成したサービスアカウントを開き、詳細 タブで次の2つをコピーします。

• メール — Netskope のインスタンス設定画面に貼る値
• 一意のID — 21桁の数値。ドメイン全体の委任で入力するクライアント ID です

「クライアント ID」という語感から OAuth クライアント ID を新規作成したくなりますが、作るのはサービスアカウントだけです。OAuth 同意画面や OAuth クライアントの作成は不要です。

③ Pub/Sub 管理者ロールの付与（Gmail のみ）

1. サービスアカウントの 権限 タブで アクセスを管理 をクリック
2. ロールを追加 で Pub/Sub 管理者（Pub/Sub Admin）を検索して選択し、保存

Gmail はメールイベントを Pub/Sub 経由で受け取る構成で、Netskope がこのサービスアカウントの権限でトピックとサブスクリプションを作成するため、管理者ロールが必要になります。Drive / Calendar では不要です。

④ JSON キーの発行

1. 鍵 タブで キーを追加 > 新しい鍵を作成 を選び、キーのタイプは JSON でダウンロード
2. JSON 内の private_key の値を控える。Netskope に貼るのは -----BEGIN PRIVATE KEY----- から -----END PRIVATE KEY-----\n までの値の全体です。途中に入っている \n（改行のエスケープ）を整形したり削ったりすると認証に失敗するので、そのままコピーしてください

   

3. 秘密鍵をダウンロードできるのはこの1回だけです。紛失した場合は再ダウンロードではなく、新しいキーを作成して差し替えます

［出典: Configure Gmail for Next Generation API Data Protection］

鍵の作成時にエラーが出たら？

JSON キーのダウンロードで「サービスアカウントキーの作成が無効になっています」とエラーが出たら、組織ポリシー管理者と調整し、対象プロジェクトで例外を許可できるか確認します。JSON キーの新規作成に直接関係する制約は次の2つです。

• iam.disableServiceAccountKeyCreation — 外部サービスアカウントキーの新規作成を禁止する従来の制約
• iam.managed.disableServiceAccountKeyCreation — 同等のマネージド制約

iam.disableServiceAccountKeyUpload / iam.managed.disableServiceAccountKeyUpload は公開鍵のアップロードを制限する別の制約で、JSON キーの新規発行エラーとは切り分けて確認します。

Netskope の Gmail 手順書自体が、このケースについて Google のトラブルシューティング記事を参照するよう案内しています。キー発行を組織ポリシーで塞いでいる環境は珍しくないので、キー発行の可否を着手前に確認しておくと安全です。

制約が有効だった場合でも、組織全体でポリシーを緩める必要はありません。対象プロジェクト単位で例外（オーバーライド）を設定し、キー作成後に元へ戻すのが定石です。

作業手順も記載しておきます。

前提：「組織ポリシー管理者」ロールが必要です

• 例外設定には 組織ポリシー管理者（Organization Policy Administrator / roles/orgpolicy.policyAdmin）ロールが必要です
• このロールは組織レベルにのみ存在します。プロジェクトを選択した IAM 画面のロール一覧には表示されないので、画面上部のリソースセレクタで組織（ビルのアイコン＋ドメイン名）を選択してから付与してください。Google Workspace の特権管理者でも自動では付与されていない点に注意です
• 組織の IAM を編集できない場合は、先に自分へ「組織の管理者（Organization Administrator）」を付与してからやり直します（GWS 特権管理者はこれを自分に付与できます）
• ロール付与後は、リソースセレクタを対象プロジェクトに戻してから次の手順に進みます

例外設定の手順（プロジェクト単位のオーバーライド）

1. [IAMと管理] ＞ [組織のポリシー] を開き、上部のリソースセレクタで対象プロジェクトを選択します
2. フィルタに iam.disableServiceAccountKeyCreation と入力し、「Disable service account key creation」ポリシーを開きます。
3. [ポリシーを管理] をクリックし、適用先で [オーバーライドして親のポリシーをカスタマイズ] を選択します
4. ルールを追加し、適用を [オフ]（強制しない）に設定して保存します
5. サービスアカウントの [鍵] タブに戻り、JSON キーを作成します（ポリシーの反映まで数分かかることがあります）

キー作成後は必ず元に戻す

• この制約はキー漏洩リスク低減のための Google 推奨ガードレールです。キー作成後は同じ画面で、対象プロジェクトのポリシーソースを元の状態に戻して再度強制してください
• 作成済みのキーは制約を再適用しても無効化されないため、Netskope との連携はそのまま動き続けます
• 作業用に付与した「組織ポリシー管理者」「組織の管理者」のロールも、作業完了後に削除しておきましょう

［出典: Organization policy constraints for service accounts (Google Cloud) / Troubleshoot organization policies (Google Cloud)］

3-5. ドメイン全体の委任（Google 管理コンソール）

特権管理者で admin.google.com にログインして作業します。

1. セキュリティ > アクセスとデータ管理 > API の制御 を開く
2. ドメイン全体の委任 の ドメイン全体の委任を管理 をクリック
3. 新しく追加 をクリック
4. クライアント ID に、3-4 で控えたサービスアカウントの一意のID（21桁の数値）を入力する。サービスアカウントのメールアドレスではない点に注意してください
5. OAuth スコープに、後述のスコープを1行に1つずつ入力する。コピペ時の前後スペースや重複行、1行漏れが定番の事故ポイントです
6. 承認 をクリック

スコープはアプリごとに異なります。

Google Drive

https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/admin.reports.audit.readonly
https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/admin.directory.domain.readonly
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/drive

ラベルバッジ機能を使う場合は、加えて次のスコープが必要です。

https://www.googleapis.com/auth/drive.labels
https://www.googleapis.com/auth/drive.admin.labels
https://www.googleapis.com/auth/drive.admin.labels.readonly
https://www.googleapis.com/auth/drive.metadata

Google Calendar

https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
https://www.googleapis.com/auth/admin.reports.audit.readonly
https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/admin.directory.domain.readonly
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/calendar
https://www.googleapis.com/auth/drive.readonly

Gmail

https://www.googleapis.com/auth/admin.directory.user.readonly
https://www.googleapis.com/auth/admin.directory.domain.readonly
https://www.googleapis.com/auth/gmail.readonly
https://www.googleapis.com/auth/admin.directory.group.member.readonly
https://www.googleapis.com/auth/admin.directory.group.readonly
https://www.googleapis.com/auth/admin.reports.audit.readonly

登録後の確認と反映時間

• API クライアントの一覧に自分のサービスアカウント（一意のID）が出ているかを目視で確認します。さらに該当行の 詳細を表示 を開き、スコープが全件並んでいるかまで見てください。1行でも漏れていれば 編集 から追記して再承認できます
• Google 公式ヘルプは、変更の反映に最大24時間かかる場合があるとしています。登録直後に Netskope 側の Grant Access が失敗したら、設定ミスを疑う前に時間を置いて再試行する価値があります
• クライアント ID は後から編集できません。数値を打ち間違えた場合は、そのエントリを削除して登録し直します
• スコープの1行漏れは Netskope 側の Grant Access で初めてエラーとして表れます。ここで潰しておくほうが早いです

［出典: Control API access with domain-wide delegation（Google Workspace 管理者ヘルプ）］

［出典: Configure Google Drive / Configure Google Calendar / Configure Gmail］

3-6. Google Workspace 側の前提条件

GCP の作業とは別に、Workspace 側で満たしておく条件があります。

• エディション: Business Standard / Business Plus / Enterprise（Drive・Calendar の手順書に記載。Gmail の手順書は Business Standard / Business Plus と記載）
• Drive: アプリ > Google Workspace > ドライブとドキュメント > 機能 で ドライブ SDK が有効であること
• Calendar: 対象の組織部門で Google カレンダーが有効であること
• ゲスト／外部ユーザーがいる場合: 内部ドメインの設定が済んでいること
• API 管理者アカウント: Netskope 側に入力するアカウント。特権管理者、またはカスタムロールのユーザー。
  • カスタムロールを使う場合、「ドライブとドキュメントの設定」「レポート」「ドメイン管理」「グループ（読み取り）」「ユーザー（読み取り）」の各権限（英語 UI: Drive and Docs Settings / Reports / Domain Management / Groups Read / Users Read）が必要で、Netskope は 記載された権限を削らないことを推奨しています
• サービスアカウントに紐づけるユーザーは、有効な Workspace ライセンスを持っていること

［出典: Configure Google Drive for the Next Generation API Data Protection］

4. Netskope 側の作業

Google 側が終わっていれば、Netskope 側は値を入れるだけです。

既に次世代 CASB API を使っている場合（再付与）
Settings > Configure App Access > Next Gen > CASB API で対象インスタンスを Edit、プリセットされている Netskope のサービスアカウント情報を自社の値に置き換えて保存・再認証します。ポリシー・ルール・設定はそのまま維持されます。

Classic から移行する場合
次世代インスタンスを新規作成し、フォレンジックを使っているなら次世代のフォレンジックインスタンスを作ってから Classic のフォレンジックプロファイルを削除。Classic ポリシーを無効化 → 次世代でポリシーを作り直し → 検証後に Classic ポリシー削除 → Settings > Configure App Access > Classic で CASB API を無効化、という順序です。

［出典: Migrate Google Drive from Classic to Next Generation API Data Protection］

5. Classic からの移行で「なくなるもの」

再付与だけで済む方は読み飛ばして構いませんが、Classic から移行する方には影響があります。Netskope が「機能パリティあり」としているのは Google Workspace のデータ保護機能が中心で、Classic の周辺機能まで完全に同一という意味ではありません。

• CASB Inline の Quarantine ベースのポリシーは次世代では非対応
• Connected app の監視・失効の機能は次世代にはなく、Netskope は代替として SSPM を案内
• DLP インシデントと Skope IT アラートのフィールド形式が Classic と次世代で異なります。SIEM 連携やレポートを組んでいる場合は下流の改修が必要

最後の1点が地味に効きます。Microsoft Sentinel などに Netskope のアラートを取り込んでいる環境では、移行と同時にパーサーや分析ルールが空振りする可能性があります。移行計画に SIEM 側の検証を1項目として立てておくのが安全です。

Classic インスタンスの削除は、インシデントの保持期間（Netskope は6か月を例示）が過ぎてからです。

［出典: Migrate Google Drive from Classic to Next Generation API Data Protection］

FAQ

Q. 移行するとポリシーは作り直しですか。
A. 既存の次世代インスタンスへの再付与だけなら作り直し不要です。Netskope は「only updates the underlying service account credentials. All your existing policies, rules, and configurations are preserved.」としています。Classic からの移行の場合は、次世代側でポリシーを作り直します。

Q. 期限に間に合わないとどうなりますか。
A. 共有サービスアカウントのままだと、Google のレート制限により次世代 API データ保護の性能が劣化する可能性がある、と記載されています。即時停止とは書かれていませんが、スキャン遅延や中断は業務影響として想定しておくべきです。

Q. GCP の費用は本当に発生しますか。
A. 無償枠のしきい値（第1章の表）を超えた分が、お客様の GCP プロジェクトに課金されます。Netskope は多くの組織が無償枠内に収まる見込みとしています。ただし請求先が変わること自体は事前に社内共有が必要です。

Q. 1つの GCP プロジェクトで Drive・Calendar・Gmail をまとめられますか。
A. できます。ただし、そのプロジェクトでアプリごとに必要な API をすべて有効化する必要があります。

Q. 2026年8月10日以降に作った次世代インスタンスは何もしなくていいですか。
A. はい。作成時点で BYOP のため、移行作業は不要と記載されています。

参考リンク（一次情報）

• Bring Your Own Project (BYOP) for Google Apps（Netskope）
• Configure Google Drive for the Next Generation API Data Protection（Netskope）
• Configure Google Calendar for the Next Generation API Data Protection（Netskope）
• Configure Gmail for Next Generation API Data Protection（Netskope）
• Migrate Google Drive from Classic to Next Generation API Data Protection（Netskope）
• Google Workspace standardized model for agent tools and APIs（Google）
• Agent tools and security updates for Google Workspace developers（Google Workspace Updates, 2026年5月）
• Gmail API Usage limits（Google）
• Google Drive API Usage limits（Google）
• Google Calendar API Usage limits（Google）
• Control API access with domain-wide delegation（Google Workspace 管理者ヘルプ）
• Organization policy constraints for service accounts（Google Cloud）
• Troubleshoot organization policies（Google Cloud）