ClaudeのGmailコネクタがURLを書き換える問題 — google.com/urlリンクの確認と回避策

ClaudeのGmailコネクタで下書きを作ったり送信したりすると、本文のURLがhttps://www.google.com/url?q=元のURL&source=gmail&ust=…&sa=Eという形のリダイレクトリンクに置き換わる、という報告が続いています。GitHubのclaude-codeリポジトリのissue #94247に、2026年9月から10月にかけて複数の環境の再現報告が集まりました。issue #94247はまだ閉じられていません。状態はissueのページで確認できます。

書き換えられたリンクがそのまま保存され、そのまま相手に届きます。取引先に送るメールのリンクが壊れて見えるので、リンク入りのメールをコネクタ経由で出している人は、送る前に確かめる手順を持っておくと安心です。

何が起きているのか

issueの報告者が最初に確かめたのは、create_draftで次の3行の本文を渡したときの結果です。

A1 https://www.example.com/page/
A2 example.com
A3 <https://www.example.com/>

保存された下書きをRAW形式で読むと、3行すべてがgoogle.com/urlのリダイレクトリンクになっていました。text/plainの部分も、text/htmlの部分も同じです。htmlBodyに<a href="https://www.example.com/page/">と書いても、hrefの値が書き換わります。

URLだけでなく、スキームのないドメイン名も対象です。example.comのような裸のドメインは、まずリンクにされ、そのうえでリダイレクトで包まれます。一方でメールアドレスは書き換えの対象にならず、通常どおりmailtoリンクになります。

書き換え後の形は、報告どおりなら次の通りです。

usgという署名のパラメーターが付かない点も、複数の報告者が指摘しています。署名がないリダイレクトは、クリックすると宛先に飛ぶ前にGoogleの「Redirect notice」ページを挟みます。受け取った側から見れば、不審なリンクに見える形です。

誰が、どの環境で再現しているのか

issueに書かれた再現報告を、環境ごとに並べます。

つまりWindowsにもmacOSにも出ており、Workspaceのメールボックスにも個人のgmail.comにも出ています。Claude CodeのCLI、デスクトップアプリ、Coworkと、使う面もまたがっています。いずれも、claude.aiのGmailコネクタを呼ぶ点が共通項です。

書き換えが最近始まった現象ではない、という報告もあります。10月20日の報告者は、8月18日から10月16日の間に外部の取引先へ送った80通を調べ、create_draftで下書きした4通すべてでリンクが書き換わっていたと書いています。そのうち1通は、受信者に長いURLがそのまま見える状態で届き、訂正メールを送る羽目になったそうです。

コネクタの書き込みで起きている、と言える根拠

「受信側の表示の問題ではないか」という疑問に対して、報告者は3つの切り分けを示しています。

1. 送信済みメッセージのRAW MIMEを読み戻すと、本文にすでにgoogle.com/urlのラッパーが入っている(10月25日の報告)
2. 同じ本文をGmailのWeb画面で作って送ると、hrefは元のURLのまま(10月5日の報告)
3. 同じ受信箱に、別経路(Resend)で送ったメールのリンクは無傷で届く(10月25日の報告)

もう一つ、9月18日の報告者はMake.comからGmail APIを直接呼んで下書きを作ったところ、同じメールボックスでもリンクはきれいなままだったと書いています。いずれも報告者本人の観察で、公式の確認ではありません。ただ、原因がコネクタ経由の書き込みにあるという見立てを支える材料としては、条件をそろえた対照実験が複数あります。

なお、コネクタの製品ページを見ると、Gmailコネクタの提供元は「Made by Google」で、接続先はhttps://gmailmcp.googleapis.com/mcp/v1と表示されています。この事実と書き換えの原因がどう結びつくのかは、issueの8件のコメントには書かれていません。修正の時期や、どちらの側で直す話なのかも、同じく記載がありません。

自分の下書きで確かめる手順

リンク入りのメールをコネクタで作るなら、送る前に保存された中身を見ます。

1. Claudeにget_draftでRAW形式の下書きを取得してもらう
2. 取得した本文にgoogle.com/url?q=が含まれていないか探す
3. 含まれていたら、その下書きは送らずにリンクを手で貼り直す

get_draftのオプション名は、報告者のissueにmessageFormat: RAWと書かれています。RAWで読むと、MIME全体が引用符つき印刷可能形式(quoted-printable)で見えるため、=が=3Dと表記されます。href=3D"https://www.google.com/url?q=3D…のような並びがあれば、書き換え済みです。

もう一つ、報告者が気づいた不具合があります。保存されたustの値の直後に、=17ではなく制御文字(0x17)が入っていた例が、issue本文と9月16日のコメントに出てきます。リンクの文字列がエンコードされずに挿入されている可能性を示すものですが、報告者の推測の域を出ません。

影響を受ける操作

issueに出てくる操作はcreate_draft、update_draft、send_messageの3つです。replyとforwardは、コネクタのツール一覧にはありますが、issueの報告には出てきません。この2つがどう動くかはissueに書かれていません。使う前に自分のメールで試すのが確実です。

update_draftには、リンクとは別の問題も報告されています。更新した下書きのthreadIdが新しい値に変わり、In-Reply-ToとReferencesのヘッダーが消えるため、送ると返信ではなく新しい会話になります。create_draftにreplyToMessageIdを渡した場合は、スレッドもヘッダーも保たれたという報告です。返信の下書きを直すなら、update_draftで上書きするより、create_draftで作り直すほうが安全です。

回避策

issueの報告者たちが取っている回避策は、大きく3つです。

• リンクを含む部分だけ、GmailのWeb画面で手貼りする
• コネクタを経由せず、自前のGmail APIクライアントや送信サービス(Resendなど)で送る
• コネクタの書き込みツールをhookで止める

最初の2つは、報告をそのまま紹介した内容です。3つめは、Claude Codeの機能で実現できるので、設定の形を示します。

PreToolUse hookでリンク入りの書き込みを止める

Claude CodeのPreToolUse hookは、ツールが実行される前に呼ばれ、実行を止められます。MCPのツールはmcp__<server>__<tool>という名前で、matcherに正規表現を書けます。claude.aiのコネクタをClaude Codeが取得した場合は、mcp__claude_ai_<server>__<tool>の形です。issueの報告者の一人も、同じ方法でコネクタの書き込みツールを止めたと書いています。

サーバー名の部分は環境で違う可能性があります。/mcpで実際のツール名を確かめてから、matcherに書いてください。次の例は、サーバー名がGmailである前提です。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "mcp__claude_ai_Gmail__(create_draft|update_draft|send_message)",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/gmail-link-guard.sh"
          }
        ]
      }
    ]
  }
}

スクリプトは、標準入力のJSONからbodyとhtmlBodyを取り出し、URLらしき文字列があればpermissionDecisionをdenyにして返します。

#!/bin/bash
input=$(cat)
text=$(echo "$input" | jq -r \
  '[.tool_input.body, .tool_input.htmlBody] | map(. // "") | join("\n")')
if echo "$text" | grep -Eq 'https?://|[A-Za-z0-9-]+\.[A-Za-z]{2,}'; then
  jq -n '{hookSpecificOutput: {
    hookEventName: "PreToolUse",
    permissionDecision: "deny",
    permissionDecisionReason: "リンクが書き換わる報告があります。Web画面で貼ってください"}}'
fi
exit 0

denyの理由はClaudeに返るので、「リンクの部分はGmailのWeb画面で貼ってください」とユーザーに案内してくれます。bodyとhtmlBodyというフィールド名は、issueの再現手順に出てくる引数名に合わせたもので、変わったときはスクリプトも直します。

この正規表現はやや広めです。「Node.js」のような文字列やe.g.に近い表記にも反応して、リンクのない本文を止める場合があります。止まりすぎるときは、https?://だけに絞ります。その代わり、裸のドメインは通ってしまいます。

hookの書き方やdeny以外の返し方は、PreToolUse hookの解説にまとめています。

permissionsのdenyで止める方法もある

リンクの有無にかかわらず書き込みツール自体を止めてよいなら、permissionsのdenyルールで足ります。ルール名はmcp__claude_ai_<server>__<tool>の形で、サーバー単位のmcp__<server>__*も書けます。ただし、読み取りのツールまで止まらないように、ツール名を指定して書くほうが安全です。

回避しても残る点

hookで止められるのは、Claude Codeから呼ぶ場合に限られます。issueには、Coworkのデスクトップアプリでの再現も出ていますが、Claude Codeのhookはそこには効きません。Coworkで書き込みを頼むときは、依頼文で「リンクは入れない」と指定するのが現実的です。

また、Gmailコネクタの案内ページの機能一覧にも、本文のURLが書き換わることを示す記載はありません。ヘルプには、送信・返信・転送は既定で実行のたびに承認を求めること、添付ファイルは中身ではなくメタデータだけ読めることが書かれています。承認を求められる前に見えるのはClaudeが渡そうとした本文のはずで、保存後の中身とは別物です。承認画面でURLを確認しても、書き換えの有無は分からない可能性があります。

Gmailコネクタの接続手順や、Coworkでのメール業務の線引きで、そもそもどこまで任せるかを決めておくと、リンク入りのメールだけ手動に回す運用が組みやすくなります。

よくある質問

署名の挿入にも影響しますか

9月29日のコメントに、署名を追加できず、同じリンクの問題も出るという報告が1件あります。詳しい再現手順は書かれていないため、署名の仕様は分かりません。

受信者側ではどう見えますか

報告によれば、htmlBodyでは見える文字は元のURLのままで、hrefだけがgoogle.com/urlになります。bodyだけで送ると、長いリダイレクトのURLがそのままリンクの文字として見えた例があります。さらに、Gmailの画面でクリックするとリダイレクトがもう一段挟まる、という報告も出ています。

修正されたかどうかはどこで分かりますか

issue #94247のページで、閉じられたかどうかを確認できます。直ったあとも、前述の確認手順で一度試すと確実です。