Gmail MCPの選び方｜公式とサードパーティを実装視点で比較
Gmail MCPはGoogle公式とサードパーティ製、どちらを選ぶべきか
Claude Code でGmail連携を実装しようとすると、最初にぶつかるのが「Gmail MCPは公式とサードパーティ、どちらを使うべきか」という問いです。2026年4月にGoogleが公式リモートMCPサーバーをリリースしたことで、選択肢が一気に二つに増えました。
私は中小企業向けにAI業務自動化を受託している立場で、最近、クライアント向けに「未読メールを4象限で分類して、それぞれに返信ドラフトを自動作成する」ワークフローをClaude Codeで構築しました。その案件で実際に両方を比較検討し、最終的にどちらを採用するかを判断したので、その実装視点での選定基準を整理します。
結論を先に書くと、「リモートが正解」「ローカルが正解」という二元論ではありません。運用環境（Claude Code CLI / Desktop / Web）と必要機能（添付ファイルの有無）の組み合わせで使い分けるのが現実解です。本記事では、両者の仕組み・機能・選定基準を、実際に検証した内容ベースで解説します。
そもそもGmail MCPとは何か
MCP（Model Context Protocol）は、AIアシスタントと外部サービスを接続するためのオープンプロトコルです。Anthropicが提唱し、現在はGoogleなど主要プラットフォームも公式対応を進めています。
Gmail MCPは、その仕組みをGmail操作に適用したサーバー実装で、Claude Codeから自然言語で「未読メールを取得」「返信ドラフトを作成」といった操作ができるようになります。
MCPの基本的な仕組みについては、こちらの記事で詳しく解説しています。
Gmail MCPに関しては、2026年5月時点で大きく二つの選択肢があります。
- Google公式のリモートMCPサーバー（gmailmcp.googleapis.com）
- サードパーティ製のローカルMCPサーバー（@gongrzhe/server-gmail-autoauth-mcp が代表的）
この二つは、エンドポイントが違うだけでなく、アーキテクチャ・ツール構成・対応機能・想定される運用環境がそれぞれ異なります。そのため「どちらが優れているか」ではなく、「自分の運用環境にどちらが合うか」を見極める必要があります。
Google公式リモートMCPの仕組みと特徴
サーバー仕様
Google公式のGmail MCPサーバーは、2026年4月にdeveloper previewとしてリリースされました。Google Cloud公式ブログによれば、Gmailを含むGoogleの主要サービスに対してMCPサポートを正式に開始したものです。
- サーバーURL:
https://gmailmcp.googleapis.com/mcp/v1 - 認証: OAuth2.0
- コールバックURI:
https://claude.ai/api/mcp/auth_callback固定 - 接続方法: Claude.ai / Claude Desktop の Settings → Connectors
OAuthのコールバックURIが claude.ai 固定になっている点が大きな特徴で、これはClaude.ai または Claude Desktop からの利用を想定した設計であることを示しています。
提供されるツール
公式の提供ツールは10個です。Google公式リファレンスに記載されている内容を整理すると、以下のとおりです。
- 取得系: list_drafts / get_thread / search_threads / list_labels
- 作成系: create_draft / create_label
- ラベル操作: label_thread / unlabel_thread / label_message / unlabel_message
注目すべきは、send_email（直接送信）系のツールが含まれていない点です。AIが勝手にメールを送信するリスクを避けるため、ドラフト作成までに留め、送信は人間の最終確認を経てGmail UI上で行う設計になっています。
アーキテクチャ
公式版はリモート型のアーキテクチャで、データの流れは以下のようになります。
- Claude.ai / Desktop が gmailmcp.googleapis.com にHTTPS接続
- OAuthトークンは claude.ai 側で管理
- サーバーがGmailバックエンドにアクセスしてレスポンスを返す
クライアント側でNodeプロセスやcredentials.jsonを管理する必要がないため、端末を変えても同じアカウントで継続利用できるのが大きなメリットです。
注意点
2026年5月時点で、私が公式ドキュメントを読んだ範囲では、Claude Code CLI からの接続手順が明記されていません。Claude.ai / Claude Desktop のConnector設定からの接続が公式の前提です。Claude Code CLI で公式リモートMCPに接続する手順は、コミュニティでも実例がまだ少ない段階です。
また、添付ファイル付きドラフトの作成について、公式の仕様書に詳細が明記されていません。Gmail APIのraw形式（RFC 822）で渡せば対応できる可能性がありますが、現時点では確実とは言えず要検証の領域です。
サードパーティ製ローカルMCP（@gongrzhe）の仕組みと特徴
サーバー仕様
サードパーティ製の代表格が @gongrzhe/server-gmail-autoauth-mcp です。npmで配布されており、npxで起動するローカルNodeプロセスとして動作します。
- 起動方法:
npx @gongrzhe/server-gmail-autoauth-mcp - 通信方式: stdio（標準入出力）
- 認証: OAuth2.0、credentials.jsonをローカル保管
- credentials保管先:
~/.gmail-mcp/credentials.json - コールバック: localhost
OAuthのコールバックがlocalhostで完結するため、Google Cloud Consoleで自分のOAuthクライアントを作成して認証する方式です。Claude.ai経由ではなく、ブラウザでlocalhostにリダイレクトされて認証が完結します。
提供されるツール
gongrzhe版の提供ツールはGitHubのREADMEで確認できます。公式と比較すると、より幅広い操作に対応しています。
- 送信・作成系: send_email / draft_email
- 読み取り系: read_email / search_emails
- ラベル系: list_email_labels / modify_email
- 削除系: delete_email
注目すべきは send_email（直接送信）と、添付ファイル付きドラフト作成に明示的に対応している点です。プレーンテキスト・HTML・マルチパート形式に対応し、ファイル添付も問題なく動作します。
アーキテクチャ
ローカル型のアーキテクチャで、データの流れは以下のとおりです。
- Claude Code が stdio でローカルNodeプロセスと通信
- Nodeプロセスが Gmail API にHTTPS接続
- OAuthトークンは
~/.gmail-mcp/に保管
credentials が自分のPC上にしか存在しないため、Claude Code CLIからの接続実績が多く、設定方法もコミュニティで確立しています。
機能対応の違い—実装担当者の選定ポイント
私が実際に旅館業のクライアント案件で必要だった機能は以下の6点でした。それぞれについて、両者の対応状況を整理します。
1. 未読メールの検索
両者とも対応しています。公式は search_threads でスレッド単位、gongrzhe版は search_emails でメッセージ単位で取得できます。
「未読 + 過去30日」のような条件指定は、Gmailの検索演算子（is:unread newer_than:30d）をそのまま渡せるため、両者で問題ありませんでした。
2. メール本文の取得
両者とも対応。公式は get_thread でスレッド全体を、gongrzhe版は read_email で個別メッセージを取得します。スレッド単位で扱いたい場合は公式の方が素直、メッセージ単位で扱いたい場合は gongrzhe版の方がコードがシンプルになります。
3. messageId・threadIdの取得
両者とも対応。Gmail UIへの直リンク（https://mail.google.com/mail/u/0/#all/<threadId>）を生成して、ドラフト確認用のリンクをClaude Codeから提示する用途で使います。
4. 返信ドラフトの作成
両者とも対応。In-Reply-To および References ヘッダーを正しく設定すれば、Gmailのスレッドに紐付いたドラフトとして作成できます。
5. 添付ファイル付きドラフト
ここが最大の分岐ポイントです。
- 公式: 仕様書に詳細記載がなく、添付対応の確実性は不明（要検証）
- gongrzhe版: README に明示的に記載があり、確実に動作する
旅館業のクライアントでは、見積書PDFや請求書を添付した返信を自動生成する要件があったため、この時点でgongrzhe版に決定しました。
6. ラベル操作
両者とも対応。公式は label_thread / label_message がスレッド単位とメッセージ単位で分かれているため、操作対象を明示的に選べる点で柔軟です。gongrzhe版は modify_email に統合されています。
選定基準—実装視点での判断フロー
以上の比較を踏まえて、実装担当者がGmail MCPを選ぶときの判断フローを整理します。
運用環境による分岐
- Claude Code CLI 主体で運用: gongrzhe版が現実解。公式はCLIからの接続手順がまだ確立していない
- Claude.ai / Desktop 主体で運用: 公式のConnector設定が最もシンプル。サーバー運用が不要で、Googleがメンテしてくれる安心感がある
- 両方使い分けたい: それぞれの環境で別々にセットアップする運用も可能（OAuthのアプリ自体は別物として動く）
必要機能による分岐
- 添付ファイル付きメール送信が必須: gongrzhe版（公式は要検証で本番採用は時期尚早）
- ドラフト作成までで十分: 公式でもgongrzhe版でも対応可
- 直接送信（人間チェックなしの自動送信）が必要: gongrzhe版のみ。ただし設計としては推奨しない（誤送信リスク）
運用負荷による分岐
- 長期メンテ性・端末非依存を重視: 公式（claude.aiが裏側を吸収）
- すぐに動かしたい・ローカル完結を重視: gongrzhe版（npx一行で動く）
- セキュリティをローカル境界で完結させたい: gongrzhe版（credentials が自分のPCを離れない）
実案件での採用判断—旅館業クライアントのケース
具体的にどう判断したかを、案件ベースで共有します。クライアント特定を避けるため詳細はぼかしますが、旅館業の中小企業向けに以下のワークフローを構築する案件でした。
- 未読メールを定期的に取得
- 4象限（重要×緊急の2軸）で自動分類
- 各象限に応じた返信ドラフトを自動作成
- 必要に応じて見積書PDFや既存資料を添付
私が下した判断はgongrzhe版の採用です。決め手は3つでした。
- 運用環境: Claude Code CLI を主体に構築する案件で、公式のCLI接続手順がまだ確立していない
- 添付要件: 見積書・請求書PDFを返信に添付する要件があり、gongrzhe版が確実
- 実装スピード: コミュニティで実例が多く、設定でつまずく可能性が低い
ただし、これは「公式が劣っている」ということではありません。同じ要件でもクライアントがClaude Desktopベースで運用するなら、公式を試す価値が十分にあると判断しています。実際、納品後の運用フェーズで「Claude Desktop に切り替えたい」となれば、公式に乗り換える設計余地は残しています。
セキュリティ観点での比較
Gmailは社内外の機密情報が大量に流れるサービスなので、MCP連携時のセキュリティは慎重に考える必要があります。
OAuthスコープの最小化
両者とも、Gmail APIのスコープ（gmail.readonly / gmail.modify / gmail.compose / gmail.send）を必要に応じて選べます。送信が不要なら gmail.compose まで（ドラフト作成権限のみ）に絞るのが基本です。
Gmail API の各スコープが何を許可しているかは、Google公式ドキュメントに整理されています。私のクライアント案件でも、最初は gmail.compose + gmail.modify までに絞り、送信権限は付与していません。
credentials の管理
- 公式: トークンは claude.ai 側で管理。ユーザーが直接ファイルに触れることはない
- gongrzhe版:
~/.gmail-mcp/credentials.jsonがローカル保管。このファイルへのアクセス制御がそのままセキュリティ境界になる
gongrzhe版を使う場合は、credentials.jsonをGitに含めない、PCの全体暗号化（FileVault / BitLocker）を有効にする、共用PCでは使わない、といった基本対策が必須です。
Claude CodeとMCPのAPIキー管理全般については、こちらの記事も参考になります。
ログ・監査の差
公式版はGoogle Cloud側で操作ログが記録される（Google Workspaceの監査ログから追える）一方、gongrzhe版はローカルプロセスの中で完結するため、AI側がどんな操作をしたかは Claude Code のセッションログに依存します。法人運用で監査要件があるなら、この点は要検討です。
2026年以降の見通し—両者は当面共存する
「公式が出たならローカル版は不要では？」という疑問を持つ方もいると思いますが、私の見立ては逆です。両者は当面共存すると考えています。理由は3つあります。
1. 公式はClaude.ai / Desktop 中心の設計
OAuthコールバックURIが claude.ai 固定である点を見ても、公式は明確にClaude.ai経由の利用を主軸に据えています。Claude Code CLI 主体のエンジニア・パワーユーザー層は、当面ローカル版に依存し続ける可能性が高いです。
2. 機能差（添付・送信など）が当面残る
公式は安全性を重視してドラフト作成までに絞っており、添付や直接送信のサポートは慎重に進む見通しです。業務自動化の現場では送信・添付の要件が頻出するため、ローカル版の存在意義は当面消えません。
3. ローカル運用への根強いニーズ
セキュリティポリシー上「クラウド経由のメール操作は許可されない」企業は少なくありません。credentials が自分の管理境界を出ない設計を求める層には、ローカル版が今後も選ばれ続けます。
まとめ—二元論ではなく組み合わせで考える
Gmail MCPの選定は、「公式が正解」「ローカルが正解」という二元論で語れるものではありません。本記事の内容を整理します。
- Google公式リモートMCP: Claude.ai / Desktop 主体・端末非依存・長期メンテ性重視のケースに強い。送信系ツール非搭載で安全寄りの設計
- サードパーティ製ローカルMCP（@gongrzhe）: Claude Code CLI 主体・添付付き送信が必要・ローカル完結を重視するケースに強い。ツール幅が広く実例も豊富
- 選定基準は「運用環境 × 必要機能 × 運用負荷」の3軸。最初に運用環境（CLI / Desktop / Web）を決め、次に機能要件（添付・送信の要否）を確認し、最後に運用負荷を見比べる
- 2026年以降も両者は共存。公式の安全寄り設計と、ローカル版の機能の広さは、それぞれの強みとして残り続ける
私がクライアントの案件で gongrzhe版を採用したのは、Claude Code CLI 主体・添付要件あり・実装スピード重視の3点が揃ったためです。同じ要件でも、Claude Desktop ベースで運用するクライアントなら公式を試す価値が十分にあります。
結局のところ、Gmail MCPの選定は「自分（または自社）がどの環境でAIを動かすのか」「どこまでの操作をAIに任せるのか」を先に決めることから始まります。本記事の判断フローが、その選定の参考になれば幸いです。
Claude Codeで業務自動化を実装する全体像については、以下の記事で解説しています。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。