📅 2026年1月15日 ⏱️ 16分で読めます

Google Workspace連携サービスに必須のOAuth審査とは？CASA審査・費用・スコープ設計を解説

執筆小林編集ファネルAi編集部監修ファネルAi監修チーム最終更新2026年5月8日

Google Workspace連携のOAuth審査でスコープ設計とセキュリティ審査を分けて検討するイメージ図

Google Workspace と連携するサービスを提供するなら、OAuth審査は「リリース直前の申請作業」ではなく、プロダクト設計の初期論点です。 Gmail、Google Drive、Google Calendar などのユーザーデータを扱う場合、要求するOAuthスコープによって、ブランド確認だけで済むのか、sensitive scopes の確認が必要なのか、restricted scopes としてCASAを含むセキュリティ審査まで進むのかが変わります。

結論として、Google Workspace連携サービスでは、最初に「どのGoogleデータを、どの機能に、どの範囲で使うか」を絞り込む必要があります。特にGmail本文やDrive全体アクセスのようなrestricted scopesを使う設計は、OAuth verificationに加えて第三者セキュリティ審査と年次再審査が必要になる場合があり、費用・期間・運用負荷を初期計画に入れておくべきです。

Google Workspace連携は、SaaSやAIエージェント、CRM、営業支援ツールにとって強力な差別化要素です。Gmailのやり取りをCRMに取り込む、Drive上の提案書を案件にひも付ける、Calendarの予定から活動ログを作る、Google Sheetsのデータを業務システムに同期する。こうした機能は現場にとって便利ですが、Googleアカウントのユーザーデータに触れる以上、OAuth同意画面と審査の設計を避けて通れません。

この記事では、Google Workspace連携サービスを提供する事業者向けに、OAuth審査の全体像、sensitive scopesとrestricted scopesの違い、CASA審査で費用が膨らむ条件、初期設計で避けるべき落とし穴を整理します。Google WorkspaceをCRMや営業管理に使う前提は、Google Workspace CRMとは？でも整理しています。

Google Workspace連携のOAuthスコープ分類とCASA審査の判断フローを整理した図 — OAuth審査は、取得するGoogleユーザーデータの種類、サーバーでの保存・中継、restricted scopesの有無で負荷が変わります。

本記事のポイント

Google Workspace連携のOAuth審査は、使うスコープが非機密・sensitive・restrictedのどれに当たるかで負荷が大きく変わる。
Gmail本文やDrive全体アクセスなどのrestricted scopesは、OAuth verificationに加えてCASAを含む年次セキュリティ審査が必要になる場合がある。
初期設計では機能より先に最小スコープ、保存しない構成、用途別OAuthクライアント分離を決めると、審査費用と運用負債を抑えやすい。

この記事で扱うテーマ

GoogleのOAuth審査とは何か

OAuth審査は、Google APIを使うアプリが、ユーザーに対して正しく同意を取り、申請したスコープに見合う機能だけでGoogleユーザーデータを扱っているかを確認するプロセスです。Googleの公式ドキュメントでは、OAuth同意画面のブランド情報、ホームページ、プライバシーポリシー、スコープの必要性、デモ動画などが確認対象になります。

ここで重要なのは、OAuth審査は単なるフォーム入力ではないという点です。審査では「そのスコープが本当に必要か」「もっと狭いスコープで実現できないか」「ユーザーに見える機能と申請内容が一致しているか」が見られます。たとえば、Gmailの送信だけで足りる機能なのに、Gmail全体を読み取れるスコープを要求すると、最小権限の説明が通りにくくなります。

Google Workspace連携でよく関係するのは、Gmail、Drive、Calendar、Sheets、Chat、Admin系のAPIです。営業支援やCRMでは、Gmailのスレッド、Calendarの商談予定、Driveの提案資料、Sheetsの顧客リストが自然に候補になります。ただし、便利な機能ほど広い権限を要求しがちで、ここに審査負荷とセキュリティ評価の差が出ます。

確認される論点	実務で準備するもの	詰まりやすい点
アプリの実体	公開ホームページ、アプリ名、ロゴ、サポート連絡先	同意画面の名称と実際のサービス名がずれる
データの扱い	プライバシーポリシー、利用規約、データ削除手順	Googleユーザーデータの保存・共有・削除が曖昧
スコープの必要性	機能説明、画面デモ、狭いスコープで足りない理由	将来使うかもしれない権限まで申請する
実装の確認	OAuthフローのデモ動画、テストアカウント	申請スコープを使う画面がまだ完成していない

Google公式の Restricted scope verification でも、スコープの必要性を確認し、最小限のアクセスにすることが重要だと説明されています。つまり、審査を軽くする最初の設計は、申請書の書き方ではなく、機能と権限の切り方です。

sensitive scopesとrestricted scopesの違い

GoogleのOAuthスコープは、リスクに応じて分類されます。すべてのスコープが同じ重さではありません。基本プロフィールやメールアドレスだけを扱う場合と、Gmail本文やDriveファイル全体を扱う場合では、確認される内容が大きく変わります。

分類	代表的な用途	審査負荷の考え方
非機密に近い基本情報	ログイン、メールアドレス、プロフィール確認	比較的軽いが、同意画面やドメイン情報は正確にそろえる
sensitive scopes	Calendarや一部のDrive/Workspaceデータの利用	OAuth verificationで、機能とスコープの整合性を説明する
restricted scopes	Gmail本文、広いDriveアクセスなど高リスクなGoogleユーザーデータ	OAuth verificationに加え、CASAを含む第三者セキュリティ審査が必要になる場合がある

restricted scopesが重いのは、アプリがユーザーの重要な業務データに広く触れる可能性があるためです。Gmail本文、添付ファイル、Drive内のファイル、広範な読み書き権限は、漏えいや不適切利用が起きたときの影響が大きくなります。そのため、Googleは対象アプリに対して、データの保存、転送、削除、アクセス制御、脆弱性対策まで含む確認を求めます。

実務では、「Google Workspace連携」とひとくくりにせず、どのデータを読むのか、どこまで書き込むのか、サーバーを経由するのか、保存するのかを機能ごとに分解します。たとえば、Google Calendarの空き時間確認、Drive Pickerでユーザーが選んだファイルだけを扱う設計、アプリが作成したファイルだけを扱う設計は、Drive全体を読む設計より審査上の説明がしやすくなります。

Gmail起点のCRMを検討する場合も同じです。Gmailで使えるCRM比較のような製品選定では機能差に目が向きますが、自社で連携サービスを作るなら、スコープ分類とデータ保存方針を先に決める必要があります。

CASA審査で費用と期間が重くなる理由

CASAは Cloud Application Security Assessment の略で、Googleユーザーデータを扱うアプリのセキュリティ評価に使われるフレームワークです。Google公式の Security Assessment では、restricted scopesへアクセスするアプリは年次のセキュリティ審査が必要になると説明されています。また、Google公式の Annual Recertification では、restricted scopesへアクセスするアプリは12か月ごとに再審査が必要になるとされています。

審査完了は、Googleデータを扱う体制の信頼材料になる

GoogleのOAuth verificationやCASA審査を完了していることは、そのアプリがGoogleユーザーデータを扱う前提で、スコープの必要性、データの保存・共有・削除方針、セキュリティ対策について確認を受けたことを意味します。もちろん、審査完了だけで将来の事故が絶対に起きないと保証されるわけではありません。それでも、GmailやDriveのような業務データに触れるプロダクトを選ぶときには、第三者によるセキュリティ評価を通過しているかどうかは重要な信頼材料になります。

導入企業の管理者にとっても、この点は見逃せません。Google Workspaceと連携するアプリは、ユーザーのメール、ファイル、予定、顧客情報の周辺に位置します。CASAやGoogleの審査を通過しているプロダクトは、少なくとも審査対象となった範囲について、外部に説明できるデータ取り扱い方針とセキュリティ確認の履歴を持っていると判断しやすくなります。

費用面で誤解しやすいのは、Googleに審査費用を払うわけではない点です。Google公式FAQでは、セキュリティ評価はCASA認定の独立 assessor が行い、費用は開発者とassessorの間で決まると案内されています。つまり、費用はアプリの規模、構成、審査Tier、再テストの有無、急ぎ対応、対象プロジェクト数によって変わります。

金額感としては、個別のassessor価格を固定して見るのではなく、上限感で考えるのが現実的です。Tier2は最大で数千USD、つまり日本円で数十万円規模になる可能性があります。Tier3は数万USD、つまり日本円で数百万円規模になる可能性があります。さらに、これは一度きりではなく、restricted scopesを継続する限り年次再審査の運用も見込む必要があります。

期間についても、短く見積もりすぎない方が安全です。Googleの公式情報では、verificationに必要な時間をローンチ計画に織り込むよう案内されています。実務では、スコープの追加、デモ動画の差し戻し、プライバシーポリシーの修正、テストアカウント確認、CASA assessorとのやり取り、再テストが重なると、数週間では収まらず、数か月単位に長期化することがあります。公開されている開発者の体験談でも、半年以上のやり取りになった例が複数報告されています。標準所要期間として半年かかるという意味ではありませんが、restricted scopesを含むプロダクトでは、審査待ちを事業計画の外に置かない方が現実的です。

費用が重くなる条件	なぜ重くなるか	初期設計での対策
restricted scopesを要求する	第三者セキュリティ審査の対象になりやすい	狭いスコープ、ユーザー選択型、読み取り専用で代替できないか確認する
Googleデータを自社サーバーに保存する	保存、暗号化、削除、アクセス制御まで評価対象になる	保存しない、短期保持、メタデータだけ保持などに分ける
複数機能を1つのOAuthクライアントに混ぜる	軽い機能まで重い審査の影響を受ける	用途別にOAuthクライアントやプロジェクトを分ける
申請時点で画面や削除導線が未完成	デモやポリシー説明が通りにくい	審査対象機能だけを先に完成させ、動画で確認できる状態にする

とくに初期のSaaSや新規AI機能では、「将来のためにGmailとDriveを広く読めるようにしておく」という設計が後で効きます。リリース前は便利に見えても、OAuth審査、CASA審査、年次再審査、セキュリティポリシー、削除依頼対応が継続的な運用負債になります。

審査を重くしないためのスコープ設計

OAuth審査を軽くするには、申請文を工夫する前に、機能を最小権限で作り直せないかを見ます。審査で求められるのは「その権限が必要であること」の説明です。広い権限を取ってから社内運用で制限するより、そもそも狭い権限で実装する方が説明しやすく、セキュリティ事故の面でも強くなります。

1. 機能ごとに必要データを分解する

「Gmail連携」ではなく、「送信履歴をCRMに残す」「商談予定を作る」「添付ファイルを案件にひも付ける」のように機能単位で分けます。機能単位で見ると、すべてのメール本文を読む必要がない、Drive全体を読む必要がない、Calendarの全予定ではなく対象カレンダーだけで足りる、といった削減余地が見えます。

2. 読み取り専用・ユーザー選択型を優先する

書き込み権限や全体アクセスは、説明責任が重くなります。Driveならユーザーが明示的に選んだファイルだけを扱う、Sheetsなら対象スプレッドシートだけを連携する、Gmailならメール送信やラベル付与など必要機能だけに絞る、といった選択肢を先に検討します。

3. Googleデータを保存しない設計を検討する

restricted scope dataを自社サーバーで保存・中継する場合、セキュリティ評価の対象が広がります。本文や添付を保存せず、Google側への参照URLやメタデータだけを保持する、短期キャッシュに限定する、ユーザー操作時だけ取得するなど、保存範囲を狭める設計が有効です。

4. OAuthクライアントを用途別に分ける

基本ログイン、Calendar連携、Gmail連携、Drive連携をすべて1つに混ぜると、軽い機能まで重い審査の影響を受けます。ユーザー導線やプロダクト構成に応じてOAuthクライアントを分けると、基本ログインだけ使うユーザーに不要な同意を求めずに済みます。

5. 審査前提のドキュメントを先に作る

OAuth審査では、プライバシーポリシー、利用規約、データ削除手順、デモ動画、テストアカウントが必要になります。restricted scopesを使うなら、データフロー図、保存期間、アクセス権限、ログ、削除依頼対応、脆弱性対応も整理しておくべきです。これは審査対策だけでなく、顧客企業へのセキュリティ説明にもそのまま使えます。

Google Workspace連携サービスの実装前チェックリスト

Google Workspace連携を提供する前に、次のチェックを通すと、後からスコープを削る手戻りを減らせます。

チェック項目	確認する問い	危険なサイン
機能	ユーザーが見える画面で、そのGoogleデータを本当に使うか	将来機能のために先取りしている
スコープ	より狭いスコープやreadonlyで代替できないか	実装が楽だから広いスコープを選んでいる
保存	本文・添付・ファイル本体を保存する必要があるか	削除依頼時の消し込み範囲を説明できない
同意画面	ユーザーに見える説明と実際の利用が一致するか	同意文ではCRM連携、実態は別用途にも使う
審査計画	公開前に数週間以上の審査期間を見込んでいるか	ローンチ直前にOAuth設定を始める

営業・マーケティング系の連携では、Google Workspaceの便利さとCRMの正本設計がぶつかりやすくなります。スプレッドシートやDriveを業務基盤にする場合は、無料のGoogle Sheets CRMの限界や Google Workspace AIガバナンスチェックリストとあわせて、権限と監査の設計も確認してください。

よくある質問（FAQ）

Google Workspaceと連携するだけで必ずOAuth審査が必要ですか？

GoogleアカウントのユーザーデータにOAuthでアクセスするアプリは、同意画面とスコープの設定が必要です。外部ユーザーに公開し、sensitive scopesやrestricted scopesを使う場合は、GoogleのOAuth verificationが必要になることがあります。社内だけの検証や少数の既知ユーザー利用では進め方が変わる場合がありますが、商用提供を前提にするなら審査前提で設計するのが安全です。

CASA審査はsensitive scopesでも必要ですか？

一般にCASAを含むセキュリティ審査が問題になりやすいのはrestricted scopesです。sensitive scopesでもOAuth verificationは必要になり得ますが、restricted scopesのような第三者セキュリティ審査とは負荷が異なります。最終判断はGoogle Cloud Console上のスコープ分類とGoogleの審査案内に従います。

CASA審査で数百万円かかる可能性はありますか？

あります。費用はGoogleではなく独立assessorとの見積もりで決まります。上限感としては、Tier2で最大数千USD、つまり数十万円規模、Tier3で数万USD、つまり数百万円規模になる可能性があります。アプリの構成、対象スコープ、サーバー保存の有無、再テスト、急ぎ対応で変わるため、restricted scopesを使う設計では早めに見積もりを取るべきです。

Gmail APIを使うCRMは必ずrestricted scopesになりますか？

必ずではありません。どのGmailスコープを使うか、本文を読むのか、送信だけなのか、メタデータだけで足りるのかで変わります。ただし、Gmail本文や添付に広く触れる設計はrestricted scopesの検討対象になりやすいため、CRM機能を「読む」「送る」「記録する」「検索する」に分解して最小権限を確認します。

審査を避けるためにユーザーにAPIキーを入れてもらう設計は有効ですか？

ユーザーデータへのアクセスをGoogleの正規OAuthフローの外に逃がす設計は、セキュリティと利用規約の観点で危険です。Google APIは公式ドキュメントに沿った認可手段で扱うべきです。審査を避けるためではなく、必要データを減らす、保存しない、ユーザー選択型にする方向で設計を見直してください。

参考にした公式情報

Google Workspace連携の設計を見直したい方へ

Google Workspace、Gmail、Drive、CalendarとCRMやAI機能をつなぐ場合は、便利な機能を先に積むほどOAuth審査とセキュリティ説明が重くなります。ファネルAiでは、営業・マーケティング業務に必要なデータ範囲を整理し、最小スコープ、保存範囲、運用導線を含めた連携設計を一緒に確認できます。

Google Workspace連携について相談する

メディア一覧へ戻る