Gmail MCP とは、Gmail の受信箱を、AI が MCP の道具として読む・探す・下書きする・送るための口です。

  • 受信箱を AI の席に繋ぐ時の操作の分け方（読む・検索・下書き・送る・添付）と、それぞれに要る Google の許可
  • Gmail を読む許可が、Google の審査の要る「制限付きのスコープ」に入る所
  • 当社が差出人・添付の渡し方で詰まった所と、受信箱の権限を席にまとめて渡さないと決めた理由

受信箱を AI の席に繋ぐ形: 操作を 5 つに分けて考える

MCP は、AI のアプリを外の系に繋ぐための開かれた標準です。公式の頁は、Claude や ChatGPT のような AI のアプリが、データの在り処や道具に繋がれるようになる、と説明しています（What is the Model Context Protocol・2026-10-26 に見た）。Gmail MCP は、この形で Gmail を道具として AI に見せる MCP サーバーを指します。AI に仕事ごと任せる考え方の全体は AIエージェント の頁にまとめています。

Gmail の口を繋ぐ前に決めるのは、どの製品を使うかより、どの操作を席に渡すかです。操作ごとに、Google に頼む許可（OAuth のスコープ）の重さが違うからです。

操作許可の候補（スコープ）Google の分け気をつける所
読むgmail.readonly（メールと設定を見る）／gmail.metadata（ラベルやヘッダーだけ・本文は見ない）制限付き本文まで要るかを先に決める。要らなければ metadata に絞れる
検索gmail.readonly制限付き探した結果を会話に載せると、他人のメールの中身も AI に渡る
下書きgmail.compose（下書きを扱い、送る）制限付き説明文に「送る」も含まれる。下書きだけのつもりでも送れる許可になる
送るgmail.send（本人に代わって送る）機微（sensitive）読む許可は無いが、取り消せない。差出人の扱いを口の側で決める
添付gmail.readonly（取り出す側）制限付き中身を会話に載せるか、サーバーの側で渡すかを決める

出典: https://developers.google.com/workspace/gmail/api/auth/scopes（2026-10-26 に見た・スコープの名前・説明文・Non-sensitive／Sensitive／Restricted の分け）。「操作」と「許可の候補」の結びは、各スコープの説明文から読んだもので、頁が操作ごとに決めている物ではありません。

受信箱の全部を扱う https://mail.google.com/ は、読む・書く・送る・完全に消すまでを含む許可です。Google は、すぐに完全に消す必要がある時だけこれを頼むように、と書いています（Choose Gmail API scopes・2026-10-26 に見た）。

Google の許可の種類: Gmail を読む許可は「制限付き」

Google は Gmail のスコープを「Non-sensitive（機微でない）」「Sensitive（機微）」「Restricted（制限付き）」に分けています。メールを読む gmail.readonly、ヘッダーだけを見る gmail.metadata、下書きを扱う gmail.compose、読み書きする gmail.modify は、どれも制限付きです。一方、送るだけの gmail.send は機微の側に入ります（Choose Gmail API scopes・2026-10-26 に見た）。

制限付きのスコープを使う公開のアプリは、Google の検証（OAuth App Verification）を受ける必要があります。さらに、制限付きのスコープで取ったデータをサーバーに置く・送る場合は、セキュリティの審査を通す必要がある、と同じ頁に書かれています（Choose Gmail API scopes・2026-10-26 に見た）。Gmail の口をサーバーで動かす MCP は、この条件に当たるかを先に確かめます。

Google の勧めは「できるだけ狭いスコープを選ぶ」ことです（同じ頁・2026-10-26 に見た）。席に送らせるだけなら送る許可だけ、件名と差出人で仕分けるだけなら metadata だけ、と仕事から逆算して許可を絞ります。

MCP の側にも決まりがあります。仕様は、道具の呼び出しを人が断れるようにしておくべきで、アプリは操作の前に確認を出すべきだ、としています（MCP Specification: Tools・2026-10-26 に見た）。送る道具は、この確認を外さない前提で繋ぎます。

当社で詰まった所 1: 送る道具で差出人を変えられなかった

当社は、会員への完了の連絡を、窓口のアドレスを差出人にして送ろうとしました。ところが、使っていた Gmail の口の「送る」道具に差出人の引数が無く、From 行を変えられませんでした（社の実測 2026-09-30）。

調べると、要る物は 2 つで、両方が揃わないと窓口のアドレスからは送れませんでした（社の実測 2026-09-30）。

  • 道具に差出人の引数を足し、From 行に載せる事
  • 送る側の Gmail に「別のアドレスから送信」でそのアドレスを登録し、確認を済ませる事

後者は Gmail の送信の別名（send-as）の仕組みです。Google の頁は、確認が要る別名は「pending」の状態で作られ、そのアドレスの持ち主が確認を済ませるまで使えない、と書いています（Managing aliases・2026-10-26 に見た）。当社は、登録されていない差出人を渡された時に、黙って元のアドレスで送るのではなく、分かる形で拒む作りにするよう開発に頼みました（社の実測 2026-09-30）。

当社で詰まった所 2: 添付を会話に載せずに渡したい

領収書などのメールの添付を、経理の証憑の受け口へ渡したい場面があります。添付を一度 AI の会話に取り込むと、中身がそのまま会話を通ります。そこで当社は、会話に載せずにサーバーの側で渡す口の作り方を 3 案で比べました（社の実測 2026-10-22）。

案渡し方鍵の扱い
A受け口が出す一時的な券の住所へ、サーバーが添付を送る汎用の口鍵が相手へ渡らない
BGmail の口が、経理の道具を直に呼ぶ—
C経理の道具が、Gmail へ添付を引きに来る—

出典: 社の実測 2026-10-22（添付をサーバーの側で渡す口の 3 案の比較）。

A は、受け口が出した一時的な住所へ送るだけなので、鍵が相手へ渡りません（社の実測 2026-10-22）。どの案も、添付の中身を会話に載せない事を前提に比べています。経理の側で証憑をどう扱うかは AI 経理 の頁に書いています。

受信箱の権限を、担当の席にまとめて渡さない

当社は、社の共通の接続に Gmail を載せないと決めました。受信箱の権限を担当の席にまとめて渡す事もしません（社の決め 2026-10-20）。

わけは、受信箱は使う本人ごとに環境が違うからです。誰の受信箱か、どのアドレスから送るか、どの許可まで渡してよいかが人ごとに変わります。そこで、本人ごとに要る口を組む形にしました（社の決め 2026-10-20）。読む許可が制限付きに入る事を考えても、共通の接続に載せて誰の席からでも受信箱が読める形は避けたい所です。

Gmail の返信を AI に任せる流れ（委任・同じスレッドへの返事・送ってよい返事の線）は AI にメール返信を任せる の頁で扱っています。Drive を同じ考え方で繋ぐ時は Google Drive MCP、他の MCP サーバーを用途で探す時は MCP サーバーの一覧、Claude に MCP を繋ぐ全体は Claude の MCP の頁にまとめています。

よくある質問

Claude で Gmail を使えますか？

使えます。MCP は Claude などの AI のアプリを外の系に繋ぐ標準で、Gmail を道具として見せる MCP サーバーを繋げば、Claude から受信箱を読む・探す・下書きする・送る事ができます（MCP の公式の頁・2026-10-26 に見た）。その際、Gmail の側では操作に応じた OAuth のスコープの許可が要ります。

Gmail MCP で送信まで AI に任せてよいですか？

送る前に人が確かめる形を残すのが前提です。MCP の仕様は、道具の呼び出しを人が断れるようにし、操作の前に確認を出すべきだとしています（MCP の仕様・2026-10-26 に見た）。当社では、差出人を変えられない口で送ろうとして詰まった事があり（社の実測 2026-09-30）、未登録の差出人は拒む作りを求めています。

Gmail MCP は安全ですか？

渡す許可と、繋ぐ範囲しだいです。Gmail を読む許可は Google が「制限付き」に分けており、公開のアプリには検証が、データをサーバーに置く・送る場合はセキュリティの審査が要ります（Gmail API のスコープの頁・2026-10-26 に見た）。当社は受信箱を社の共通の接続に載せず、本人ごとに口を組んでいます（社の決め 2026-10-20）。

Gmail MCP で、別のアドレスを差出人にして送れますか？

口と Gmail の両方が対応していれば送れます。送る道具に差出人の引数が在る事と、送る側の Gmail に「別のアドレスから送信」でそのアドレスを登録して確認を済ませる事の両方が要りました（社の実測 2026-09-30）。確認が済むまで、その別名は使えません（Google の頁・2026-10-26 に見た）。

出典

  1. Google for Developers「Choose Gmail API scopes」 https://developers.google.com/workspace/gmail/api/auth/scopes（2026-10-26 に見た・スコープの名前と説明文・Non-sensitive／Sensitive／Restricted の分け・制限付きのスコープの検証とセキュリティの審査・狭いスコープを選ぶ勧め）
  2. Google for Developers「Managing aliases and signatures」 https://developers.google.com/workspace/gmail/api/guides/alias_and_signature_settings（2026-10-26 に見た・送信の別名と、確認が済むまで使えない事）
  3. Model Context Protocol「What is the Model Context Protocol (MCP)?」 https://modelcontextprotocol.io/docs/getting-started/intro（2026-10-26 に見た・MCP の定義）
  4. Model Context Protocol「Specification: Tools」 https://modelcontextprotocol.io/specification/2025-06-18/server/tools（2026-10-26 に見た・道具の呼び出しを人が断れるようにする事と、操作の前の確認）
  5. 社の実測 2026-09-30（送る道具の差出人の件）
  6. 社の実測 2026-10-22（添付をサーバーの側で渡す口の 3 案の比較）
  7. 社の決め 2026-10-20（社の共通の接続に Gmail を載せない決め）