Gmailの権限で「下書きだけ」は作れない。AIに送信させない設定と、Googleの審査区分を公式ドキュメントで確かめた

この記事は、AIにGmailを繋いでいいかどうかを審査する立場の方——情シスの方と、社内でOAuthアプリを作る開発者の方に向けて書いています。「送信はさせない。下書きまでにする」と決めた直後に、Googleの権限の区分がその判断を裏切る、という話です。

営業・マーケの現場責任者の方は「できないこと・やらないこと」から、経営者の方は「決裁に必要な3点」だけ読めば足ります。

確認日は2026年10月22日です。この記事の事実は、すべてGoogleとMCPの公式ドキュメントを直接見て書いています。当社の話は当社1社の話（n=1）です。

先に結論

• 下書きを作るAPI（users.drafts.create）が受け付ける権限は3つだけで、その3つはすべてGoogleの「制限付き（Restricted）」区分です。
• 送信するAPI（users.messages.send）は、その3つに加えて gmail.send でも通ります。gmail.send は一段軽い「機密（Sensitive）」区分です。
• つまり、「送信させず下書きまで」に絞ると、選べる権限は重い区分しか残りません。
• さらに gmail.compose の公式説明文は「Manage drafts and send emails.（下書きの管理とメール送信）」です。「AIには送信させない」は、権限の層では作れません。 アプリの作りと運用で止めるしかありません。

Gmailの権限の3つの区分

Googleは、アプリがユーザーのデータにどこまで触れるかを3段階に分けています。公式ページの定義文はこうです（訳は当社）。

出典：https://developers.google.com/workspace/gmail/api/auth/scopes

Gmailの主な権限を、この区分に当てはめると次のようになります。公式説明文はそのまま引用しています。

出典：https://developers.google.com/workspace/gmail/api/auth/scopes

なお https://mail.google.com/ は、同じページで「ゴミ箱を経由せずに完全削除する必要がある場合にのみ要求せよ」と書かれています。それ以外の用途では、もっと弱い権限で足ります。

Gmail固有のポリシーページには、制限付きに入る条件も書かれています。「メッセージの本文（添付を含む）、メタデータ、ヘッダを読む・作る・変える」「メールボックスのアクセス、転送、管理設定を制御する」のいずれかができる権限です。下書きの作成は「本文を作る」に当たります。

出典：https://developers.google.com/gmail/api/policy

下書きの作成に必要な権限

公式のAPIリファレンスには、メソッドごとに「このメソッドを呼ぶにはこの権限のどれかが必要」という一覧が載っています。

users.drafts.create（下書きを作る）の一覧は3つです。

1. https://mail.google.com/（制限付き）
2. https://www.googleapis.com/auth/gmail.modify（制限付き）
3. https://www.googleapis.com/auth/gmail.compose（制限付き）

gmail.send は入っていません。

出典：https://developers.google.com/gmail/api/reference/rest/v1/users.drafts/create

送信に必要な権限

users.messages.send（送信する）の一覧は4つです。

1. https://mail.google.com/（制限付き）
2. https://www.googleapis.com/auth/gmail.modify（制限付き）
3. https://www.googleapis.com/auth/gmail.compose（制限付き）
4. https://www.googleapis.com/auth/gmail.send（機密）

出典：https://developers.google.com/gmail/api/reference/rest/v1/users.messages/send

並べると、こうなります。

「送信だけ」なら機密で済み、「下書きだけ」は制限付きしか選べません。 これがこの記事の中心です。工程を分けて人の手を最後に残す設計は、審査の区分では軽くならず、むしろ重い側に入ります。

図：同じ「書く」でも、Googleの区分は逆になります。左が送信（機密）、右が下書きの管理（制限付き）です。

なお下書きと送信は、APIとしても別のメソッドです。users.drafts.create は DRAFT ラベルの付いた下書きを作るだけで、送るには users.drafts.send という別のメソッドを呼びます。送信の経路は users.messages.send と users.drafts.send の2つです。

出典：https://developers.google.com/workspace/gmail/api/guides/sending

「送信させない」が権限の層で作れない理由

ここがいちばん誤解されるところだと思います。

gmail.compose の公式説明文は「Manage drafts and send emails.」です。下書きの管理と、メールの送信です。そして送信APIの権限一覧にも gmail.compose が入っています。

つまり、下書きを作る権限を取ると、送信できる権限も一緒に付いてきます。「AIには下書きだけ」をOAuthの権限で表現する方法は、公式ドキュメントの範囲では存在しません。

送信を止めたいなら、止める場所は4つのどれかです。

1. アプリが送信APIを呼ばない（実装で担保する）
2. AIに渡す道具の一覧から送信を外す（MCPサーバーのツール定義で担保する）
3. 書き込みの前に人の承認を挟む（運用で担保する）
4. AIへの指示を下書きまでにとどめる（運用で担保する。いちばん弱い。止めているのは指示の書き方だけなので、権限でもツール定義でも裏づけられません）

権限の画面を見ただけでは、このどれが効いているかは分かりません。稟議で確かめるべきは「要求しているスコープ」ではなく、「送信を止めているのはどの層か」です。

審査の重さの差

区分が違うと、何がどれだけ違うのか。Googleが数字で書いているものだけを並べます。

出典（機密）：https://developers.google.com/identity/protocols/oauth2/production-readiness/sensitive-scope-verification

出典（制限付き）：https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification

制限付きの期間について、Googleは「数週間かかる可能性がある」という書き方しかしていません。 中央値も分布も公開されていないので、この記事では「何週間」と断定しません。

セキュリティ評価の条件も、公式の文言はこうです。「has the ability to access data from or through a third-party server must go through a security assessment」「If you store or transmit restricted scope data on servers, then you need to complete a security assessment.」評価するのは「an independent, third-party assessor that is approved by Google」で、枠組みの名前は CASA（cloud application security assessment framework） です。

ここで、実務でいちばん効くのは期間ではなく更新の周期です。評価書（LOA）の承認日から少なくとも12か月ごとに再評価が必要です。一度通せば終わりではなく、毎年の運用コストになります。

⚠️ 費用はこの記事に書けません。 今回確認した制限付きスコープの審査ページと API Services User Data Policy に、金額の記載がないためです。検索すると価格表らしきものが出てきますが、いずれもベンダーやまとめ記事で、算出の方法まで遡れませんでした。当社の編集方針では、出典も算出式もない数字は載せません。「今回見たページに費用は書かれていなかった」が、確認できた限界です。 同じ理由で、CASAの段階（Tier）の分け方と、セキュリティ評価が必要になるユーザー数の閾値も、今回見たページには数値がありませんでした。閾値について公式が書いているのは「Depending on the API and number of users or grants」という一文だけで、数値はありません。

出典：https://developers.google.com/terms/api-services-user-data-policy

審査を受けなくてよい5つの例外

制限付きスコープの審査には、公式に例外が5つあります。見出しはページの表記のままです。

出典：https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification

実務の分岐点は「Internal use only」です。 API Services User Data Policy にも、「If an app is only used by users within your own organization, then these additional requirements do not apply.」と書かれています。顧客企業が自社のWorkspace組織の中だけで使う内製アプリなら、セキュリティ評価は発生しません。条件は、プロジェクトがその組織の所有であることと、OAuth同意画面のユーザー種別が Internal であることです。

出典：https://developers.google.com/terms/api-services-user-data-policy

テスト公開のままで運用する場合の制約

「審査を出さずに、テスト公開のまま社内で使う」という選択肢もよく挙がります。公式に書かれている制約は2つです。

• テストユーザーは、同意画面に登録した100人まで
• テストユーザーの認可は、同意から7日で失効する。オフラインアクセス用のリフレッシュトークンも、その認可と一緒に失効する（name・email・profile といった基本的なスコープは例外）

出典：https://support.google.com/cloud/answer/15549945

常時つながっている前提の仕組みでは、7日ごとに全員が再認可することになります。ここは運用の設計で見落としやすい点です。

当社のGmailコネクタの場合

当社（株式会社Latens）の Latens OS では、GmailコネクタでAIに渡せる操作を5件だけにしています。検索・閲覧・送信・下書きの作成・ラベル一覧です。操作名の一覧と、この一覧にない操作ができないことは、Gmailコネクタのページに載せています。同じ表をここに並べても読む手間が増えるだけなので、再掲はしません。

要求している権限は3つです。

認証は OAuth 2.0 で、繋ぐのは利用者本人の許可です。実装は @googleworkspace/cli を使っています。

ここで正直に書いておきます。当社も gmail.send を要求していますし、gmail.compose には送信が含まれます。 つまり権限の層では、当社のアプリは送信できます。

当社の運用（2026年10月22日時点・n=1）は、問い合わせへの返信についてAIがGmailの下書きを作るところまでで、送信は人が押します。これを担保しているのは権限ではありません。当社のGmailコネクタは、AIに渡す操作に送信（gmail_send_email）を含んでいます。送信していないのは、AIへの指示を下書きまでにとどめているからで、運用上の決めごとです。書き込み操作の前に人の承認を挟む設定も使えますが、「権限では送信できない」という状態にはなっていません。この区別を曖昧にしたまま「AIには送信権限を渡していません」と言うのは、正確ではありません。

「下書きまでで実務の大半が回るのか」は、当社では回っています。問い合わせへの返信は下書きまでで足りていて、送信の手前で止めても業務は止まりません。ただしこれは当社1社の運用の話（n=1）で、割合は集計していません。「読み取りだけで済む作業が何割か」を数字で出すには、集計の期間・母数・「1件」の数え方を先に決めて測る必要があります。まだやっていないので、この記事に割合は書きません。

MCPの仕様が推奨している形

「人が最後に押す」は当社が勝手に決めた作法ではありません。MCPの仕様にも書かれています。

For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations.

仕様がアプリケーションに SHOULD として求めていることは3つです。どの道具がAIに渡っているかが分かるUI、道具が呼ばれたときの明確な表示、操作の確認プロンプト。クライアントに求めていることも、機微な操作で確認を取る・サーバーを呼ぶ前に道具への入力を利用者に見せる・監査のために道具の利用を記録する、です。

別の警告もあります。「clients MUST consider tool annotations to be untrusted unless they come from trusted servers.」道具の説明文は、信頼できるサーバーから来たものでなければ信用してはいけない、ということです。繋ぐ先の提供元を確かめる作業は省けません。

出典：https://modelcontextprotocol.io/specification/2026-07-28/server/tools

まだ確かめていないこと

ここは実機で試していません。試していないことを「できる」と書かないために、残しておきます。

• gmail.compose だけを許可して、送信を実際に不可能にできるかは試していません
• トークンが失効したときに何が起きるかは試していません
• 読み取りをラベル単位・差出人単位に絞れるかは試していません
• 当社がCASAの審査を実際に受けた経験はありません
• 非機密の gmail.addons.current.action.compose で Gmail の REST API の下書き作成が呼べるかは、公式ドキュメントに記載がなく、確かめていません。公式はアドオンのUI操作に応じた下書き作成（Apps Script のメソッド）の文脈しか書いていません
• 他社のAIメールツールが実際にどの権限を要求しているかは、同意画面の実物を見ていないので書きません
• 日本語の解説記事にこの逆説が書かれていないことは、2026年10月22日のWeb検索で調べた範囲の話で、網羅的な調査ではありません

できないこと・やらないこと

• OAuthの権限で「下書きだけ」は作れません。 下書きの権限には送信が含まれます
• 「送信させない」を権限の画面で証明することはできません。 実装・ツール定義・承認のどこかで止めている、という説明になります
• 当社は制限付きスコープの審査期間を「何週間」と言いません。 Googleが数値で書いていないためです
• CASAの費用と段階（Tier）の話はしません。 公式に記載がなく、方法論に遡れる出典がないためです
• 「〇〇ユーザー以上でセキュリティ評価が必要」とも言いません。 公式に閾値の数値がありません
• 審査が通りやすい・通りにくいという評価もしません。Googleは却下率を公開していません
• 読み取りの範囲を、スコープで絞ることはしていません。gmail.readonly の公式説明文は "View your email messages and settings." です。ラベルや差出人で絞る方法があるかは確かめていません

権限と監査（情シスの方へ）

稟議で確かめる順番として、当社が使っている観点です。

当社のGmailコネクタでは、書き込み操作を人が承認してから走らせる設定にできます。操作のログは残ります。

審査を出す人についても、先に決めておいたほうがよい点があります。申請はGoogle Cloudのプロジェクトのオーナーまたは編集者の権限を持つアカウントからしか出せません。社外のベンダーに作らせている場合、申請の操作は顧客側の担当者がやることになります。

つまずいたこと

当社の経験（n=1）です。

1. OAuthアプリは、それを持っている組織の資産

前身のプロダクトで使っていたGoogleのOAuthアプリは、別法人のWorkspace組織の中にありました。法人が変わると引き継げないので、作り直しになりました。審査の実績も一緒にゼロに戻ります。 社名変更や法人の分割を予定しているなら、OAuthアプリをどの組織に置くかは先に決めたほうがよい点です。

2. 1つのアプリに2本のリダイレクトURI

ログイン用とコネクタの認可用で、リダイレクトURIを2本登録しています。実装がクライアントIDを1組しか持たないためです。審査の対象になる画面が増えるので、設計の段階で分けるかどうかを決めておくところです。

決裁に必要な3点（経営者の方へ・この節はそのまま転送できます）

AIにメールを触らせる判断で、金額より先に決まるのはスケジュールと例外の該当です。

1. 「送信させない」は安全側の判断ですが、Googleの審査が軽くなるわけではありません。 下書きを作るには制限付きスコープが必要で、Google自身が「数週間かかる可能性がある」と書いています（出典：https://developers.google.com/identity/protocols/oauth2/production-readiness/restricted-scope-verification）。自社でアプリを作る前提なら、この期間を計画に入れてください。
2. 審査は一度で終わりません。 セキュリティ評価が必要な構成なら、評価書の承認日から少なくとも12か月ごとに再評価です（同出典）。単発の費用ではなく、毎年の運用コストとして見る必要があります。
3. 自社のGoogle Workspace組織の中だけで使うなら、公式の例外に当たります。 「If an app is only used by users within your own organization, then these additional requirements do not apply.」（出典：https://developers.google.com/terms/api-services-user-data-policy）。社内に閉じるか、外に出すかで、必要な工程が変わります。 ここが最初の分岐です。

選択肢は3つです。(a) 自社のWorkspace内に閉じて例外に当てる、(b) 審査を通す、(c) 既に繋がっている基盤を使う。(c) の場合、審査の工程は基盤の提供側が持つので、御社に残るのは本人がOAuthで許可する操作だけです。

料金は、人数ぶんの基本料金と、AIが実際に操作した回数ぶんの従量料金を足した形です。読み取りだけの操作は0円、コネクタをいくつ繋いでも0円、初期費用も0円です。金額の水準と、段階ごとの単価はLatens OSの製品ページに出しています。

これは何に繋がっているか

この記事で扱った権限の区分は、Latens OS のGmailコネクタで実際に要求しているものです。どのサービスに、どの操作まで、どんな権限で繋がるのかは、Latens Lab のコネクタ一覧に操作名と権限の範囲ごと載せています。「下書きまで。送信は人が押す」も、そこで選べる設定の話です。

御社の業務で同じことをやるとどうなるかは、15分のデモでお見せします。資料請求はこちらからどうぞ。

確認日：2026年10月22日。この記事の事実は、特記のない限りGoogleおよびMCPの公式ドキュメントの直接確認にもとづきます。当社の数値は当社1社の計測（n=1）です。引用・転載は出典を明記していただければ自由です。