AI エージェントに Gmail を触らせるために、Google と 6 ヶ月戦った話

Restricted Scope 申請、デモ動画ループ、gmail.modify の正当化、そして CASA Tier 2 の入り口まで。

うちは KumaKumaAI というエンタープライズ向け AI プラットフォームを作っていて、その中核機能のひとつに「Email AI」というものがあります。受信メールを AI エージェントが自動分析して、ナレッジベースやカレンダーを参照しながら返信ドラフトまで作る、という機能です。

これを Gmail で動かすためには、当然ながら Google の OAuth verification を通す必要があります。しかも https://mail.google.com/ のような広いスコープを使うなら Restricted Scope 扱いになって、年 1 回更新の CASA Tier 2 セキュリティ評価 までセットで通さないといけない。

で、実際にやってみたんですが、これがまあ長い。

最初の差し戻しメールが届いた 2025 年 9 月から、CASA Tier 2 の Letter of Validation (LOV) を提出して結果待ちになっている 2026 年 4 月末まで、まる 6 ヶ月以上の戦い になりました。途中で「これは記録しておかないと、次にやる人が同じ罠を踏む」と思った場面が何度もあったので、まだ完走していないですが、現時点までの実録として書き残しておきます。

完走編（CASA 結果が返ってきた時点）はまた別記事にする予定です。

3 行サマリ

• 動く: Restricted Scope (gmail.modify, drive.readonly) の申請は通る。AI エージェントの正当化ロジックは Google も最終的には認めてくれる
• 戦いが長い: デモ動画ループ、スコープ正当化の応酬、CASA Tier 2 開始指示まで。淡々とやれば数週間で終わるが、間に「やる気が萎えて放置する期間」が挟まりやすい
• AI エージェント特有の正当化が必要: 「なぜ drive.file + Picker API では駄目なのか」「なぜ gmail.readonly で足りないのか」を、Google の審査チームに納得させる作文力が問われる

そもそも何で揉めるのか

Google の OAuth verification は、要求するスコープの「重さ」によって審査の濃さが 3 段階に分かれています。

• Non-Sensitive Scopes: profile, email など。verification 不要
• Sensitive Scopes: gmail.readonly など。Google の verification 必要、デモ動画とプライバシーポリシー必須
• Restricted Scopes: gmail.modify, drive.readonly など。Sensitive の全要件 + サードパーティ製の CASA セキュリティ評価が毎年必須

AI エージェントを Gmail に介入させるアプリケーションは、ほぼ確実に Restricted Scopes に到達します。なぜなら:

• 受信メールの一覧を取りたい → gmail.readonly（Sensitive）で済む
• でもラベルを操作したり、archive したり、ドラフトを作ったりしたい → gmail.modify（Restricted）必須
• Drive 全体を横断検索したい → drive.readonly（Restricted）必須

ここがゴールに見えるのですが、Google の審査チームは「もっと狭いスコープで足りるはずだ」と何度でも押し返してきます。これが今回の戦いのほぼすべてでした。

タイムライン

長くなるので、まず俯瞰図を貼ります。

正直に書いておくと、5 ヶ月の沈黙期は 私が単に放置していた期間 です。差し戻しのたびに動画を撮り直してプライバシーポリシーを書き直して英語で反論文を作って、というのが思った以上にメンタルに来て、他の優先度の高い開発タスクを言い訳にずっと先延ばしにしていました。これからやる人にひとつアドバイスがあるとすれば、verification は始めたら勢いで一気に通すのが結局一番楽 です。間が空くと、前回どこまでやったかを思い出すコストでさらに腰が重くなります。

それぞれの幕で「ここで詰まったか」というポイントがあるので、順に書きます。

第 1 幕: デモ動画ループ（2025 年 9 月）

最初の差し戻しメールは 2025 年 9 月 23 日に届きました。

We are unable to log in and test your application.

訳すと「お前のアプリにログインできないんだが」です。Google の審査チームが KumaKumaAI を実際に触ってみようとして、入れなかったらしい。

ここで 1 つ目の罠です。

罠 1: オンプレ製品なのにログインさせろと言われる

KumaKumaAI は 顧客のプライベートネットワーク内にデプロイするオンプレ製品 として設計しています。インターネットに公開された URL が無いので、Google の審査チームに「どうぞ、ここからログインしてください」と渡すこと自体ができません。

そこで初回提出時に YouTube で OAuth consent 画面のデモ動画を撮って一緒に出していたのですが、それでは不十分だ、と差し戻された形です。

慌てて返信を書きました。

Our application is an on-premise solution that operates within our customers' private networks and is not accessible from the public internet. Therefore, we cannot provide direct login access or test credentials for your team to access the live application.

「私たちのアプリはオンプレなので公開 URL はありません。代わりに動画を提出していたはずです、それを見てもらえませんか」という主旨。

これはオンプレ SaaS あるあるだと思うので最初に書いておきますが、Google 側は「動画があるならそれで OK」と即答してくれるわけではない です。動画の中身が彼らの審査基準を厳密に満たしていないと、何度でも撮り直しを要求されます。今回はまさにそれが起きました。

罠 2: 「# services リンクをクリックして全スコープを見せろ」

撮り直しを覚悟して再度 Google からのフィードバックを読むと、こう書かれていました（2025 年 9 月 26 日）。

The demo video you submitted does not show the OAuth Consent screen workflow. Your demo video must show the OAuth consent screen workflow including all the requested scopes.

Click '# services' to reveal the scopes your application is requesting from your users.

Note: '# services' here means the no. of scopes hidden behind the 'services' hyperlink.

Kindly set the language on English for the new demo video.

要点は 3 つです。

1. OAuth consent 画面の workflow を最初から最後まで映せ
2. # services というリンクをクリックして、隠れているスコープを全部見せろ（# の部分はスコープ数で、たとえば「3 services」と表示される）
3. 動画の言語を英語に設定しろ

特に 2 番目の罠が地味に効きます。Google の OAuth consent 画面は、デフォルトでは「3 services」のような形でスコープがリンクの裏に隠れていて、ユーザーがそのリンクをクリックすると展開される UI になっています。最初の動画では consent 画面を映してはいたものの、このリンクをクリックして全スコープを展開する瞬間が無かった、というのが差し戻しの理由でした。

3 番目の「英語で撮り直せ」も、日本人としては地味にダメージがあります。Google の Workspace の言語設定はアカウントごとに English にしないといけないので、テスト用の Google アカウントを別途作って言語を English にして、シークレットウィンドウで操作する、という手順を踏むことになります。

罠 3: 「機能を十分に示していない」という曖昧な差し戻し

3 度目の正直、と思って提出したら、また差し戻されました（2025 年 9 月 29 日）。

The video you submitted does not sufficiently demonstrate the functionality of your application.

「アプリの機能を十分に示せていない」。

正直、ここでイラッとしました。何が「十分」なのか具体的な基準が示されないからです。 前回の差し戻しでは「OAuth consent 画面を映せ」「# services を展開しろ」「英語にしろ」と非常に具体的だったのに、今回は何が不足しているのか分からない。

しょうがないので、

• ログイン → OAuth 同意 → 認可成功
• ナレッジベースに対するチャット
• Gmail を実際に検索して件名を読み上げる
• Drive ファイルを検索して中身に基づいて回答する

までを 1 本の動画で連続的に見せる長尺デモを撮り直しました。これが 2025 年 9 月 29 日の提出。

そしてここで 「面倒すぎる」が爆発して 5 ヶ月放置するモードに突入 します。

第 2 幕: スコープ最小化バトル（2026 年 3 月〜4 月）

5 ヶ月放置した後、2026 年 3 月に重い腰を上げて再開しました。

ここからが本番です。Google の審査チームと 「スコープが広すぎる、もっと狭くしろ」「いや、AI エージェントの仕様上これが最小です」 という応酬を繰り広げることになります。

時系列で書くと長くなるので、まず争点を整理します。

争点の整理

KumaKumaAI が当初リクエストしていた Restricted Scope は次の 2 つでした。

これに対して Google の審査チームは、それぞれもっと狭いスコープが使えるはずだと主張 してきました。

ここから応酬が始まります。

Google「drive.file + Picker を使え」 ← 2026/03/25

最初のスコープ縮小要求が来ました。

Drive 側の主張は明快で、「drive.file という非 Restricted のスコープを使えば、ユーザーが Picker UI で明示的に選んだファイルだけにアクセスできる。これが最小スコープ原則に沿う」 というもの。さらに「UI preferences alone は valid policy exception ではない」と釘を刺してきます。「UI 上の好みで広いスコープを要求するのは認めない」と。

これは正論です。Drive の中身全部見せろというのは確かに広すぎる。ただし AI エージェントの場合、ユーザーが事前にファイルを選ぶことが原理的にできない という問題があります。

返信（2026/03/28）の論点はこうでした。

1. AI エージェントは「どのファイルが関連するか」を事前に知らない。ユーザーが「先月の売上レポートを要約して」と言ったとき、Picker でファイル選択を求めるのは AI エージェントの目的と矛盾する
2. プログラマティックな全文検索が core functionality。Drive API の files.list で fullText contains 'sales report' のようなクエリを動的に組み立てるのが本質で、これが Picker では再現不可能
3. これは UI preferences ではなく architectural constraint。チャット UI で「ファイル選んでください」と返す AI エージェントは、もはや AI エージェントではない

Gmail 側についても同様の理由で「gmail.readonly だけでは足りない、送信もドラフト作成もできないと製品が成立しない」と返しました。

Google「じゃあ gmail.readonly + gmail.compose ならどうだ」 ← 2026/04/04

Google が一歩譲歩してきました。「mail.google.com は広すぎるが、gmail.readonly と gmail.compose の組み合わせなら、読み取りと送信の両方できるぞ」と。

Drive についても、こちらの主張をある程度受け入れた様子で、drive.readonly の使用を認める方向に動きました。

ここで AI エージェントの設計に詳しい人なら気づくと思いますが、gmail.readonly + gmail.compose でも実は足りません。これだけでは:

• 受信メールに 既読マーク をつけられない
• メールを アーカイブ できない
• メールに ラベル をつけたり外したりできない

KumaKumaAI の Email AI 機能は、AI エージェントがメールを処理した後で「この件は対応済み」「この件は要フォロー」のようなラベル管理や、不要メールのアーカイブまで自動化するのが価値の中心です。読み取りと送信だけ許可されても、製品としては不完全になる。

返信（2026/04/05）で、ここを丁寧に書きました。

Mark as read/unread: After the AI agent processes and summarizes emails for users, it marks them as read to reflect the user's workflow state.

Archive and trash: Users instruct the AI agent to clean up their inbox by archiving or trashing emails through the conversational interface.

Label management: The AI agent categorizes and organizes emails by adding or removing labels based on user instructions.

要するに 「gmail.modify こそが最小スコープ」 という主張です。gmail.modify は、メールの完全削除や mail settings へのアクセスを含まないので、Google が懸念する「もっと広い権限」よりは確実に狭い。AI エージェントが行うラベル管理・アーカイブ操作にちょうど一致するレベルです。

Google「いや、テストしたら gmail.readonly で動いてたぞ」スクショ反論 ← 2026/04/05

ここが今回のバトルで一番ヒヤッとした瞬間です。

Google から、こんな返信が来ました。

Based on the information we gathered by testing your app, we believe the following scope(s) may be a better fit for your use case:

.../auth/gmail.readonly (see attached files)

「テストしてみたら gmail.readonly で動いてるように見えた、スクショも添付した」 と言うのです。添付ファイルが 3 枚。

ここで何が起きたかを整理しないといけません。

Google の審査チームがこちら側のテストアカウントでログインして KumaKumaAI を動かしたとき、たまたま試した操作（メールを検索する・読む）が gmail.readonly の範囲で完結していた。だから「これで足りるじゃん」と判断された。

でも実際には、彼らが試さなかった操作（ラベル付与、アーカイブ、ドラフト作成、既読マーク）の方が gmail.modify を必要とする本質的な機能だったわけです。テスト範囲の偏りで「こちらが使っているスコープを過剰申請している」と誤解された。

こちらもスクショ反論 ← 2026/04/06

向こうがスクショで反論してきたので、こちらもスクショで押し返しました。

返信の核は 「もう一度テストしてくれ、こういうプロンプトを AI エージェントに送れば gmail.modify が必要な操作が再現できる」 という具体的な再現手順の提示です。

Send the following prompt to the AI agent:

"Search for emails sent to [your email address]. Then archive the most recent email from the search results. Finally, create a new draft email to [your email address] with the subject 'Test Draft' and body 'This is a test draft created by the AI agent.'"

このプロンプトを送ると、AI エージェントは:

1. メール検索（gmail.readonly でも可）
2. 最新メールをアーカイブ（gmail.modify が必須）
3. 新しいドラフトを作成（gmail.compose または gmail.modify）

を順に実行します。gmail.readonly だけでは 2 番目で確実に失敗する。これをこちらの環境で実行したスクショと一緒に提出しました。

沈黙、そして勝利 ← 2026/04/08

スクショ反論を送った 2 日後、返信が来ました。今度はスコープを否定するメールではなく、こういう内容でした。

You are required to complete a CASA Tier 2 security assessment for your application by the following date: Jul 6, 2026.

「CASA Tier 2 を 7 月 6 日までに完了してください」

これは事実上の勝利宣言です。CASA Tier 2 は Restricted Scope を承認する前提として要求される評価なので、Google が gmail.modify と drive.readonly のスコープを認めた、ただし CASA を通すまでは正式承認しない、というステップに進んだことを意味します。

スコープバトル本戦、終了。

第 3 幕: CASA Tier 2 開始（2026 年 4 月〜現在）

スコープが認められて喜んだのも束の間、CASA Tier 2 という新しい関門が現れます。これがまた、独立した小さな冒険です。

CASA Tier 2 とは

CASA は Cloud Application Security Assessment の略で、Restricted Scope を使うアプリには Google が必須化しているサードパーティセキュリティ評価です。Tier 1 〜 Tier 3 の 3 段階あって、ざっくり次の感じ。

KumaKumaAI のようなアプリは Tier 2 が要求 されます。年 1 回の更新が必要なので、これは「一度通せば終わり」ではなく 「毎年やる作業」 であることに注意が必要です。

TAC Security を選んだ理由

CASA を実施できる Authorized Lab は複数ありますが、Google が公式ドキュメントで preferred partner として案内しているのが TAC Security です。インドの会社で、ESOF AppSec ADA という SaaS 上で CASA のプロセスが進みます。

選んだ理由は単純で、Google が公式に「ここがディスカウントレートで提供している」と書いているから です。他の Authorized Lab を比較する時間と心理的余裕が無かったので、最短ルートを取りました。

オンボーディング、スキャン、SAQ

TAC Security のオンボーディングは ESOF AppSec ADA Portal というポータルから始まります。流れはざっくりこんな感じ。

1. アカウント作成と支払い: ポータルにサインアップ、支払い処理
2. アプリケーション情報の登録: Web アプリの URL、OAuth クライアント ID、リクエストするスコープ一覧などを登録
3. スキャンの作成と実行: 自動化された Web アプリスキャンが実行される。脆弱性スキャナで OWASP Top 10 系の脆弱性を洗う
4. SAQ（Self-Assessment Questionnaire）の記入: 認証、ロギング、データ保護、暗号化、インシデント対応など 30 項目程度のチェックリストに、それぞれエビデンス（スクショやポリシードキュメント）付きで回答
5. LOV（Letter of Validation）の提出: 全部揃ったら TAC のレビューチームに提出して結果待ち

現在地: SAQ エビデンス追加対応中

2026 年 4 月 30 日時点で、

• スキャンレビュー: OK
• SAQ: point 4, 15, 20 の追加エビデンスを TAC から要求されて対応中

の状態です。SAQ で追加エビデンスを求められた項目は、ロギング、暗号化、データ保護に関するもの が中心でした。具体的にどう答えたかは長くなるので別記事にしますが、AWS 上で動かしている前提で言うと、CloudTrail のログ保管設定、KMS による保管時暗号化、TLS 構成、IAM ポリシーの最小権限化、あたりのスクショと設定ドキュメントを揃えることになります。

CASA の最終結果が返ってきたら、続編記事を書きます。現時点では、Google の verification 自体は LOV と CASA レポートが揃って初めて approved になる ので、KumaKumaAI の Gmail 連携機能は production 環境ではまだ unverified app screen が出る状態 です（test users としてホワイトリストに入れた人だけ使える）。

これから申請する人向け 5 つの教訓

ここまでの全体を通じて、これからやる人にひとつだけアドバイスするなら、を 5 つに圧縮しました。

1. デモ動画は専用テストアカウントで撮る

普段使いの Google アカウントで撮らない。言語を English に設定したテスト用アカウントを最初から作って、シークレットウィンドウで操作する。OAuth consent 画面の # services リンクは必ずクリックして、スコープを 1 つずつ展開する瞬間を映す。

2. AI エージェントには gmail.modify と drive.readonly が最小

gmail.readonly + gmail.compose で足りるかも、と思っても、ラベル管理・アーカイブ・既読制御をやろうとすると確実に詰まります。最初から gmail.modify で申請して、正当化文書を準備しておく方が結局速い。Drive も同じで、drive.file + Picker は AI エージェントの core functionality と原理的に矛盾するので、最初から drive.readonly で行く。

3. 「UI preferences ではなく architectural constraint だ」と書く

Google の審査チームが好んで使うフレーズが「UI preferences alone are not valid policy exceptions」です。これに対しては「これは UI の好みではなく、我々のアーキテクチャ上 Picker UI を表示する箇所が原理的に存在しない」と明確に切り返す。「ユーザーが事前にファイルを選ぶことが原理的にできない」「AI エージェントの目的と矛盾する」のような書き方が効きます。

4. 審査側のテスト範囲は限定的、こちらから再現手順を提示する

Google の審査チームがこちらのアプリをテストしてくれるのはありがたいですが、彼らが試した操作が、こちらが意図した「広いスコープを必要とする操作」と一致するとは限らない。スコープ正当化の返信には、必ず 「このプロンプトをこの順序で実行してください」と再現手順を書いて、こちら側で実行したスクショも添付する。これが最短ルートです。

5. 始めたら一気に通す

これが一番大事です。verification は「始める → 差し戻し対応 → また差し戻し対応 →」のループが続くので、間が空くとメンタルが折れます。一度心が折れると 5 ヶ月くらい簡単に飛びます（実体験）。着手する前にカレンダーで 2 〜 3 週間ブロックして、その期間に集中して通す方が結果的に楽 です。

まとめ

• AI エージェントが Gmail / Drive を触るには Restricted Scope と CASA Tier 2 の両方が必要
• スコープ正当化は 「architectural constraint」「再現手順 + スクショ」 がキーワード
• CASA Tier 2 は TAC Security が公式 preferred partner、ESOF AppSec ADA Portal で進める
• 全体で 6 ヶ月以上かかったが、純粋な作業時間は数週間レベル。間が空いて心が折れる方が時間を食う
• 完走編は CASA 結果が返ってきたら別記事で書く

オンプレ AI エージェントを Google API と繋ぎたい人の参考になれば。

AI agents don't fit Google's minimum scope philosophy — they fit a different philosophy.