Gmail MCPでドメインがgoogle.com/urlに化ける原因と確認手順｜送る前に下書きを確かめる【2026年】

Gmail MCPで下書きを作るとき、僕に必要だったのは、本文にドメインもURLも書かず、作った後に google.com/url を探す確認でした。2026年9月10日の実測で本文の裸のドメインが転送用の文字列に置き換わると分かり、前日に取引先へ送ったメールも同じ形で化けたまま送信済みでした。

この記事では、化けた文字列の形、原因の見立て、送る前の確認手順、いまの運用を順に書きます。「AIに作らせた下書き、そのまま送って大丈夫？」と迷っている方は、手順の章から読んでください。

Gmail MCPの下書きで、ドメインが google.com/url?q= の文字列に化ける

起きるのは、本文に書いたドメインが、Googleの転送用URLに置き換わって下書きに保存される症状です。僕の環境では、ドメインだけでなく https:// 付きのURLでも同じことが起きました。

たとえば本文に example.com と書くと、保存された下書きでは次の形になっていました。ust= の後ろの値は毎回違う長い文字列なので、ここでは ... にしています。

https://www.google.com/url?q=http://example.com&source=gmail&ust=...&sa=E

ここでいう裸のドメインとは、https:// を付けずに example.com のようにドメイン名だけを書いたものです。会社名の代わりにサイトの名前を書いたつもりでも、Gmail側ではリンクとして扱われることがあります。

僕が試した書き方と、結果を表にしました。どれも僕の会社の記録にある実測で、言い換えた本文だけが置換0件でした。

表を見る限り、書き方の工夫で避けるのは難しいと僕は判断しました。形式を変えても化けたので、本文からドメインとURLを消す運用にしています。

原因は、Gmailのリンク保護の形が下書きに残ったと見ています

なぜ書き換わるのか、Claude側の公式の説明は見つけられませんでした。手がかりは、Gmailのヘルプにある「クリック時のリンク保護」の説明です。

この保護が効くと、リンクが https://www.google.com/url?q=ORIGINAL_URL の形に見えることがあると書かれています。化けた文字列は、この形とよく似ています。

ここからは僕の見立てです。MCP経由で作った下書きに、本来は転送のための形がそのまま保存されたのだろうと読んでいます。仕組みを確かめたわけではないので、断定はしません。

送る前に化けていないかを確かめる手順（get_draft で google.com/url を探す）

確実なのは、下書きを作った後に中身を読み直し、google.com/url の文字列が無いかを探すことです。僕の会社では、この確認を通った下書きだけを人に渡しています。

手順は次の4つです。ツール名は、僕の環境のGmail MCPで見えていたものです。Claudeの公式ヘルプにはツール名の記載が無いので、環境によって名前が違う可能性があります。

1. 本文からドメインとURLを抜いてから、create_draft で下書きを作る
2. 作った下書きを get_draft で読み直す。中身は大きいのでファイルに保存し、自分の本文の部分だけを取り出す
3. 取り出した本文で google.com/url を検索する。1件でもあれば失敗として扱う
4. 化けていたら、言い換えた本文で作り直す。古い下書きは trash_message でゴミ箱へ移す

手順2で本文だけを取り出すのは、返信の下書きだと引用した過去のやり取りまで入ることがあるからです。相手のメールにある文字列まで拾うと、自分の本文が直ったかを見分けにくくなります。

Gmailのウェブ版なら、ヘルプにある「その他」の中の原文の表示（Show original）でも中身を見られます。それでも僕の会社では、見落としの起きにくい文字列の検索を正としています。

裏方で起きた例：9月9日の送信済みメールと、10月8日のURLの書き換え

僕の会社で最初に気づいたのは2026年9月10日です。Claude Codeの作業の中でGmailの下書きを作っていて、本文の裸のドメインが置き換わっているのを見つけました。

確かめると、create_draft で新しく作った下書きでも、返信先を指定した返信の下書きでも同じでした。前日の9月9日に取引先へ送ったメールも、同じ化け方のまま送信済みでした。

僕はClaude Codeを、Claudeのコネクタ経由でGmailにつないで使っています。下書きまではAIが作り、送信は人がGmailから押す分担です。

化けた文字列が送信済みのメールに残っていたので、送る前には気づけていなかったことになります。この経験から、作った後に文字列を検索する手順を足しました。

5日後の2026年9月15日には、別の取引先への返信の下書きで対策を試しました。サイトのドメインを書かずに「〇〇サイト」と言い換え、作った後に確かめると、google.com/url?q= への置換は0件でした。

2026年10月8日には、範囲が広いと分かりました。提出用のメールで、https:// 付きの完全なURLも書き換わったのです。テキスト形式でも、HTML形式の <a href> でも結果は同じでした。

このときは、URLを本文に入れず「添付資料の21ページにURLとQRコード」と書いて送る形にしました。添付のファイルも大きく、MCPでは受け渡せなかったので、添付と送信は人が手で行っています。

再発防止：本文にドメインとURLを書かず、添付は人が付ける

いまの社内ルールは3つです。ドメインは言い換える、URLは本文に書かない、大きな添付は人が付ける。どれも上の実測から決めました。

どうしてもURLを本文に入れたいときは、下書きを開いた人がGmailの画面で貼ります。AIに書かせず、最後の1か所だけ人が触る形にしています。

このルールは、Claude Codeが毎回読む社内のメモに書いてあります。作業のたびにAIが読み直すので、次の下書きからは言い換えた本文で作る前提です。メモの置き方は Claude Codeの使い方 に書きました。

Claude CodeでGmailを業務に使うときの注意（送信・添付・権限）

業務で使うなら、AIに任せるのは下書きまでにして、送信は人が押す形が安全だと僕は考えています。化けた文字列は、送った後では取り消せないからです。

Claudeの公式ヘルプでは、Gmailのコネクタは検索・読み取り・下書きのほか、送信・返信・転送もできるとされています。初期設定では、それぞれの前にClaudeが承認を求めます。

僕の会社の記録にある9月15日と10月8日の例では、どちらも下書きまでをAIが作り、送信は人がGmailから行っています。

添付については、公式ヘルプに中身は読めずメタデータだけと書かれています。TeamとEnterpriseのプランでは、組織の管理者がコネクタを有効にしないと各メンバーは使えません。

チームで使うなら、「下書きの後に google.com/url を探す」までを手順に入れておくと迷いません。AIに任せる範囲をどこで区切るかの考え方は AIエージェントの作り方と無人運用の設計 にまとめています。

MCPそのものの仕組みや、僕の会社がつないでいるほかの接続先は MCPとは？仕組みと実際につないだ接続先 で紹介しています。Claude Codeで出たほかの症状は Claude Codeの困りごと一覧 から探せます。

同じGoogleのコネクタでは、カレンダーの予定登録も任せています。決まった曜日の前日のような繰り返しの入れ方は Google カレンダーの繰り返し設定をClaudeに任せる方法 に書きました。

まとめ

• Gmail MCPで作った下書きは、本文のドメインやURLが google.com/url?q= の文字列に化けることがある
• 2026年9月10日の実測では裸のドメインが、10月8日の実測では https:// 付きのURLも、テキスト形式とHTML形式の両方で書き換わった
• 書き換わる理由の公式の説明は見つけられなかった。Gmailのリンク保護の形が残ったというのは僕の見立て
• 本文ではドメインを言い換え、URLは添付資料に載せる。大きな添付は人が付ける
• 僕なら、まず「下書きの後に google.com/url を検索する」1行を手順に足すところから始めます