アドレスバーの完全なURLは、そのまま共有してよい住所ではない
マーケターがランディングを Slack に投げる。サポートが問い合わせの URL を Backlog や Zendesk に貼る。開発が再現手順をチャットに書く。三つの場面でいちばん安い操作は同じです。アドレスバーを全選択し、コピーし、貼る。バーが示すのは、いまの文書の完全な URL です。WHATWG の URL モデルでは、少なくともスキーム、ホスト、パス、クエリ（? の後ろ）、フラグメント（# の後ろ）を持ちます。フラグメントは既定で HTTP に入りません。それは前のノートです。クエリはリクエスト行に乗り、クリップボードにも乗ります。
クエリは、ページを開くために必要とは限りません。計測付きのメルマガ、有料クリック、カード側がクリック識別子を足した SNS 投稿から来たかもしれません。ページが要るのは /product/42 だけです。バーは /product/42?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale&fbclid=… になります。解析にとっては、帰属できる一回の訪問です。次にこの列を読む人にとっては、チケットに置くべきではない横顔です。どのキャンペーンから来たか、いま広告を踏んだか、メール配信側がこの受信者に番号を振ったか。
HTTPS が守るのは、伝送中の盗聴です。アドレスバー、ブラウザ履歴、チャット保存、スクリーンショット、アクセスログは消しません。OWASP の「クエリ文字列による情報露出」は率直です。暗号化チャネルでも、クエリは Referer、Web ログ、共有システム、ブラウザ履歴、キャッシュ、肩越しの視線に出ます。共有前に問うのは「このサイトは安全か」ではありません。「このクエスチョンの後ろに、このタブから出してはいけないラベルがあるか」です。
UTMはキャンペーンを書き、クリックIDはその一回を書く
二種類は同じ URL に並ぶことが多く、仕事も漏れ方も違います。第一は、自分（または配信基盤）が意図して書いたキャンペーンタグです。Google アナリティクス ヘルプはこれをキャンペーン パラメータと呼び、標準例を示します。https://www.example.com/?utm_source=summer-mailer&utm_medium=email&utm_campaign=summer-sale。公式は、パラメータを付けるなら utm_source、utm_medium、utm_campaign を揃えて使うよう求めます。拡張は utm_id、utm_term、utm_content、utm_source_platform です。値は大文字小文字を区別します。utm_source=google と utm_source=Google はレポートで二行に割れます。
この種のタグは、一人の利用者を符号にすることがほとんどありません。チャネルとキャンペーンを書きます。どのメルマガか、どの夏のセールか、メール内の上のリンクか下のリンクか。それでも社外チャットへ転送すれば、社内の配信構造は漏れます。受け手は、いま押しているキャンペーン名と、メールか有料クリックかを読めます。獲得経路を推測できます。競合や無関係な第三者にとって、「このページを開く」に必要な量を超えています。
第二は、広告やメール基盤が勝手に足すクリック識別子です。よくある名前は、Google 広告の gclid、Display & Video 360 の dclid、iOS 周辺の gbraid / wbraid、Meta の fbclid、Microsoft Advertising の msclkid、X の twclid、メール配信側の mc_eid です。目的は「この一回のクリック」を、基盤側の配信記録へ縫い戻すことです。人の言葉を渡すためではありません。値は受け手には読めず、基盤には読めます。fbclid や gclid が残った列を転送することは、接合できるクリック証憑を渡すことです。mc_eid 系は、「この配信が、この購読者行へ行った」に近いです。
第三層もあります。サイト自身のアトリビューションや共有パラメータです。EC やコンテンツサイトでは spm、scm、pvid、share_token、refer_share_id がよく出ます。Google の UTM 仕様ではありません。それでも「商品ページだけ」に見えるリンクへ、誰がどこから共有したかの跡を残します。utm_* だけを消す方針では、この層は残ります。国内の通販やアプリ内ブラウザでも、見た目は短い商品 URL なのに、共有経路や推薦者の痕跡がクエリに乗ることは珍しくありません。
| 種類 | よくあるキー | 転送したときの問題 |
|---|---|---|
| キャンペーンタグ | utm_source、utm_medium、utm_campaign |
ページを開くのに不要なチャネル名とキャンペーン名が漏れる |
| クリック / 受信者 ID | gclid、fbclid、mc_eid、msclkid |
一回のクリック、または一人の購読者行へ接合できる |
| サイト内アトリビューション | spm、pvid、share_token |
共有経路や紹介の跡を持ち出す |
| 業務パラメータ | id、q、sku、page |
残すのが普通。消すと 404 や別の結果になる |
貼ったあと、クエリはどこへ落ちるか
CWE-598（現行タイトルは Use of HTTP Request With Sensitive Query String）は欠陥をこう書きます。機微をクエリへ置いた。するとブラウザ履歴に出る、Referer 経由で他サイトへ渡る、Web ログへ書かれる、別の記録へ写る。条目は 2026 年 4 月の 4.20 版で改名され、GET だけがクエリを持てるわけではないと強調しています。POST、PUT、DELETE も持てます。緩和は具体的です。機微はリクエスト本文かヘッダへ置き、クエリへ置かない。
計測パラメータの多くは、パスワードやセッショントークンではありません。露出面は同じです。完全な URL をチャットへ貼ると、少なくとも次の写しが生まれます。チャット事業者のメッセージ保存、受け手の端末履歴、さらに転送すれば次のホップの保存。相手が開くと、着地側のアクセスログはパラメータ付きのリクエスト行を残します。そのページが第三者のスクリプトや画像を読むと、完全な URL が Referer に乗って広告や解析のホストへ行くこともあります。OWASP の「共有システム」は社内では日常です。チケット、ドキュメント、エラー監視、セッション再生。再現のためだけに用意したリンクが、それらの系で平文検索できます。
だから「サイトは HTTPS だ」は、共有の問いに答えません。HTTPS は、経路上の観察者が平文を読むのを難しくします。自分がその平文を次の系へ貼ることは止めません。CWE-598 が挙げる実害には、監視カメラがパスワードをクエリへ置いた例、通信製品がアクセストークンを GET へ置いた例があります。同じ種類の誤りで、より重いものです。UTM とクリック ID の害は普通は軽いです。仕組みは同じです。クエスチョンの後ろにあるものは、人がコピーし、系が記録します。
ログイン中の URL、パスワード再設定、一度きりのトークン付きリンクで実演しないでください。パラメータを照合するときは、すでに公開されている商品ページやドキュメントページを使い、クエリへ捨てられるテスト値を足してください。例は utm_campaign=canary-2026 です。
Refererは、クエスチョンの後ろを第三者へ運ぶ
コピー＆ペーストは能動の共有です。受動の共有もあります。受け手がページを開いたあと、ブラウザの既定方針が後続リクエストへ「どこから来たか」を伝えます。このヘッダの標準名は Referer です（r が一つ欠けます）。MDN の Referer とプライバシーは、よくある例を出します。パスワード再設定ページのフッタに SNS リンクがある。外へクリックすると、トークン付きの住所を SNS へ渡すことがあります。ページ内の第三者画像も、いまの完全な URL を画像ホストへ同じ経路で送れます。
ブラウザは Referrer-Policy で送る量を決めます。Chrome などの既定は strict-origin-when-cross-origin です。同一オリジンなら完全な URL（パスとクエリ）を送れます。ダウングレードしないクロスオリジンはオリジン（スキーム + ホスト + ポート）だけを送ります。HTTPS から HTTP へは送りません。web.dev の Referrer 指針は、この既定をプライバシーと可用性の妥協と書きます。別ホストへ完全なクエリを渡す一部は止めます。同一オリジンの解析リクエストは止めません。サイトが unsafe-url を置く、または方針を置かず、古いクライアントが完全な URL を送る場合も助けになりません。
「同僚へ送っただけ」でも、Referer は意味を持ちます。相手がクリックした瞬間、貼った utm_* とクリック ID がもう一ホップ進むことがあります。着地に第三者ピクセル、サポートウィジェット、CDN 上のフォントがあり、方針が完全な URL を許せば、それらのホストのログへパラメータが出ます。共有前にクエリから追跡項を剥がすことは、二ホップを同時に減らします。チャット記録の平文と、開いたあとに出るかもしれない Referer です。
フラグメントとの対比を一文足します。鍵を # の後ろへ置くと、HTTP の設計ではリクエスト行に入らず、通常の Referer 実装にも入りません。クエリにその層はありません。キャンペーンタグとクリック ID を ? の後ろへ置くのは、サーバーとスクリプトが読むためです。ログへ入る理由もそれです。「クエスチョンはリクエストに入り、ハッシュは既定では入らない」を照合する手順は、URLのハッシュ記号の後ろに鍵を置ける理由と、その保護が効かなくなるときにあります。
端末が一部を剥がしても、共有方針にはならない
Apple は、システム側の切断を文書化しています。Apple のプライバシー機能では、リンクトラッキングからの保護機能をこう書いています。メッセージアプリでリンクを共有するとき、一部のサイトが URL に足す余分な情報を削除するので、自分と共有相手がトラッキングされるのを防げる。Safari のプライベートブラウズは別に書かれます。ウェブを見ているときに URL へ追加されたトラッキングを削除する。Apple が公開しているのは能力であり、パラメータの名簿ではありません。
公式の完全な除去一覧はありません。コミュニティの対照（PrivacyTests.org など）がよく挙げるのは gclid、fbclid、mc_eid、twclid、dclid です。utm_source などのキャンペーンタグは残ることが多いです。範囲にも縁があります。通常の Safari、第三者ブラウザ、アプリ内 WebView は、メッセージでの共有やプライベートブラウズと同じ経路ではありません。相手が Android、デスクトップ Chrome、Slack や LINE から開いても、代わりに剥がしてはくれません。
したがって「iPhone が追跡パラメータを消す」と書ける範囲は狭いです。特定のシステム、特定のアプリでは、一部のクリック ID が開く前に消えることがある。チケットへ貼った列がすでに整理済みだ、とは書けません。共有はコピーした瞬間に起き、OS がまだ入っていない場所で起きます。制御できるのはクリップボードの文字です。受け手の端末がもう一度剥がすかどうかではありません。
剥がすものと、残すもの
実行できる規則は、先に「このキーがなくてもページは開くか」と問うことです。商品の id、検索の q、ページ番号の page、言語の lang、文書自身が要るクエリは、消すと資源が変わります。キャンペーンタグ、クリック ID、メール受信者番号、共有トークンは、普通は帰属だけを変え、ページそのものは変えません。
第二の問いは、このリンクの仕事です。同僚が不具合を再現するなら、安定した資源の住所が要ります。utm_campaign=summer-sale は要りません。顧客へ「この商品を開いてください」と送るなら sku が要ります。自分が直前に踏んだ gclid は要りません。UTM を残してよいのは、「このタグ付きキャンペーンから入ってもらい、今回の転送を数えたい」が仕事のときだけです。その場合でも、自分のクリック ID は付けないでください。
手で消すと漏れます。実配信の URL は、utm_* を五、六個、クリック ID を一つ、サイト内トークンを二、三個持つことがあります。右から左へ目で消すと、id を消し、fbclid を残すことがよくあります。安定するのはキー名です。utm_ 接頭辞はすべて外す。既知のクリック ID 表を外す。仕事が許せば、よくある解析キー（_ga、_gl、mc_eid、mkt_tok）とよくある EC アトリビューションも外す。パス、ホスト、業務クエリは残す。終わったら「消したキー名の一覧」を見ます。結果が「短くなった」だけでは足りません。
保守と標準は、匿名の等級ではなく、リスクの好みです。保守は UTM とクリック ID だけを触り、未知の独自キーは残します。まだ見ていない業務パラメータを消さないためです。標準は、よくある解析と EC アトリビューションも外します。社外や公開の場へ出すリンクに向きます。どちらも「匿名になった」とは言えません。パスにユーザー名が残ることがあります。クエリの email= は UTM 表にありません。規則ベースの整理が扱うのは既知の追跡キーであり、任意の機微欄ではありません。本文の電話番号、身分証明書番号、鍵は、別のマスキングが要ります。URL パラメータの除去に、その仕事まで期待しないでください。
同僚へ送る最短の文はこれです。再現はパスと業務パラメータ。計測は UTM で、自分のクリック ID は付けない。迷ったら先に utm_* と *clid を剥がし、残ったキーを目で読む。
その場で照合する：除去一覧のあと、Network を探す
「端末で整理し、アップロードしない」は、標語だけでは証明になりません。その場で見えるのは三つです。どのキーが消えたか、どのキーが残ったか、元の URL が業務データとして出たか。
先にカナリアを作ります。実顧客のいない公開ページを開き、末尾へ ?utm_source=canary-share&utm_medium=email&utm_campaign=canary-2026&fbclid=canaryclid&id=42 を足します。列全体を整理の入力へ貼ります。実行後、四つの追跡キーは見えず、id=42 は残るはずです。ツールが「除去した」一覧を出すなら、名前を一つずつ照合します。最終 URL が短くなっただけで止めないでください。
次に開発者ツールの Network を開き、Preserve log を入れ、フィルタへ canary-share またはカナリアのクエリ全体を貼ります。XHR / Fetch のリクエスト行、クエリ、本文に出てはいけません。分析送信の query と body にも出てはいけません。静的ファイル、スタイル、スクリプトは出てよい。それはページ自身のファイルです。失敗は、原文が業務欄として出ることです。タイトルやパスに「プライバシー」「クリーン」が出るのは想定内です。入力欄の全文は想定外です。
utm_*、fbclid、業務のidを持つカナリア URL を作る。実顧客や公開前のキャンペーン名は使わない。- 整理後に表を照合する。追跡キーは「削除」側、
idは結果 URL に残る。 - カナリア文字列で Network を探す。業務リクエストに当たれば、原文はこのタブを出ている。
支えられる結論は狭いです。この一回では、既知の追跡キーが規則どおり消え、業務キーが残り、観察できた HTTP の欄として原文はこのタブを出ていない。拡張が入力欄を読んでいないことは証明しません。規則表にない独自の追跡キーが処理されたことも証明しません。ブラウザや規則表を変えたら、カナリアをもう一度走らせてください。
開いてすぐ使える整理ページで、規則を手に馴染ませる
除去一覧をページ上に出す道具で練習するなら、MakePwd の UTM削除・マスキングから始められます。開いてすぐ使え、登録もアカウントもありません。URL の解析とパラメータ除去は、いまのタブで終わります。製品の説明どおり、原文はリクエストに出さず、analytics にも書きません。標準モードは utm_*、広告クリック ID、よくある解析パラメータ、および Taobao、Pinduoduo、Douyin などでよく見るアトリビューションを外します。保守モードは UTM とクリック ID だけを外します。パスと id、q のような業務パラメータは残します。一度に最大 100 件、1 件が 8 KB を超えると拒否します。http または https だけを受け付けます。
練習は上のカナリアで行い、配信中の本物のクリック ID は使わないでください。実行後に見る場所は二つです。結果側の除去一覧と、Network に原文があるか。一覧は「正しいキーを消したか」用です。Network は「アップロードしたか」用です。両方を通してから、同僚へ説明できます。消したキーはこれで、カナリアを探しても出域はなかった、と。
整理が扱うのはリンクの形だけです。チャットやチケット本文の電話番号、身分証明書番号、メール、API Key は、同じページの個人情報マスキングへ切り、パターンで伏せ字にし、なお人手で確認します。MakePwd は GDPR や個人情報保護法の認証を主張しません。整理したあとも残してはいけない内容なら、ワンタイムリンクで一度送り、鍵は URL の # フラグメントに残します。ファイル一式は、ファイル暗号化でこの端末で .lock / .enc にしてから、クラウドストレージやメールへ載せます。どの手順もログインを求めません。
よくある質問
UTMを消したあと、相手はページを開けますか？
開けます。業務パラメータとパスが残っていれば十分です。UTM とクリック ID は計測用であり、ルーティング用ではありません。utm_campaign や fbclid を消しても、ランディングはパスと id で開くはずです。消したあと 404 や別の結果になるなら、業務キーを誤って消しています。保守モードに戻し、キーを一つずつ照合してください。
HTTPS なら、これらのパラメータはすでに守られていますか？
共有の瞬間は守られていません。HTTPS は途中の盗聴を下げますが、アドレスバー、履歴、チャット、ログは消しません。OWASP は、暗号化チャネルでもクエリが Referer、Web ログ、共有システム、ブラウザ履歴に出ると書いています。完全な URL を貼ってよいかと、サイトに証明書があるかは別の問いです。
iPhone が追跡パラメータを消すなら、自分で剥がす必要はありますか？
あります。システムの機能は、メッセージでの共有や Safari のプライベートブラウズなど、文書化された経路に働き、完全なキー一覧は公開されていません。UTM は残ることが多いです。チケットや Android のチャットに貼るとき、その保護は代わりに走りません。共有方針が見るのはクリップボードであり、相手の端末がもう一度剥がすかどうかではありません。
クリーンなURLは、商品の id も消しますか？
キー名で判断するなら、消すべきではありません。id、q、sku は utm_ 接頭辞ではなく、よくあるクリック ID 表にもありません。確かめ方は、追跡キーと業務キーを同じカナリアに入れ、前者が消えて後者が残るかを見ることです。サイトが追跡を独自のキー名に書いていると、規則表は知りません。手で消すか、一覧を広げてください。
次に共有する前に、覚えておく三つのこと
第一に、アドレスバーの全選択は「送ってよい」ではありません。クエスチョンの後ろを、キャンペーンタグ、クリック ID、サイト内アトリビューション、業務パラメータに分けます。既定で残すのは最後だけです。第二に、HTTPS と端末の自動除去は、クリップボード確認の代わりになりません。クエリは履歴、チケット、ログに入り、Referer でもう一ホップ進むことがあります。第三に、照合は二箇所です。消したキー名の一覧と、カナリアで Network を探すこと。
次の問いが「平文が業務データとしてこのタブを出たか」なら、ブラウザ暗号化の確かめ方：平文が端末を出ていないことを証明するを読んでください。本稿が落とすのは、「完全な URL のどのクエリを、共有に乗せてよいか」を、結論へ書ける範囲にすることだけです。