URL

クリーン

URLクリーナーとは？

友達にリンクを送ろうとしたら末尾に ?utm_source=newsletter&utm_campaign=spring_sale_2026&fbclid=IwAR0... がぶら下がっていた、というやつです。ここに貼ると、すっぴんのURLと、何が削除されたかをまとめたJSONが返ってきます。出力はJSONなので、ログ行やテストフィクスチャ、あるいは「何を消したか」の記録を残したい場所にそのままコピペできます。

このページが存在するのは、Google Analytics、Facebook、HubSpot、Mailchimpなど数十のプラットフォームが、共有も保存もしたくないものをURLにくっつけてくるからです。utm_* パラメータは Urchin Tracking Module 由来で、Googleが2005年に追加し、いまや至るところで使われています。fbclid はFacebookのクリック識別子、gclid はGoogleのもの。どちらも表示されるページの中身には影響せず、遷移先のサイトに「どこから来たか」を伝えるだけです。

すべてはブラウザ内で標準の URLSearchParams APIを使って動きます。これは WHATWG URL Standard が定めるパーサーと同じものです。アップロードもサーバー処理もログ保存もありません。クリーニング処理は決定的 — 削除リストはソースに書かれていて読めますし、同じ入力には常に同じ出力が返ります。

URLクリーナーの使い方

3ステップ。それぞれがこのページのボタンに対応しています。

URLを貼るかサンプルを読み込む

左パネルにURLを貼り付けます。サンプルを押すと、utm_*、fbclid、gclidが本物のクエリパラメータと混ざった現実的な例が読み込まれます。サンプルURL：

https://shop.example.com/orders/ORD-1001?customer=Ava+Chen&status=active&utm_source=newsletter&utm_medium=email&utm_campaign=spring_sale_2026&fbclid=IwAR0abc123def456&gclid=Cj0KCQjwxyz

new URL(...) が受け付けるものなら何でも動きます — + を含むクエリ、パーセントエンコード、重複キー、ハッシュフラグメント、すべて対応。パス、ハッシュ、トラッキング以外のクエリパラメータはそのまま保持されます。

クリーンなURLと削除内容を確認

右パネルにJSONが表示されます: cleaned はトラッキングを除いたURL、removed は取り除かれた各パラメータ（キーと値）のオブジェクト、removedCount はその総数です。クリーンするものがなかった場合は removed が空オブジェクトになり、note フィールドでその旨が表示されます。入力中にリアルタイムで更新されます。

コピーまたはダウンロード

コピーでJSONをクリップボードへ、ダウンロードで .json ファイルとして保存できます。圧縮はJSONを1行にまとめます。やり直したいときは入力パネルのクリアを使います。クリーンなURL文字列だけが必要なら、cleaned フィールドの値をコピーしてください。

実際にこれを使う場面

共有前にリンクをきれいにする

マーケティングメールから開いたタブのリンクを、Slackで友人に送りたい。URLには末尾に ?utm_source=newsletter&utm_campaign=spring_sale_2026 がついていて、相手にとっては不要だしリンク自体が見苦しい。貼って、cleaned の値をコピーして送る。先に構成要素を確認したい場合は URLパーサーと組み合わせるのが便利です。

データベースに正規化URLを保存

ブックマーク系サービスや価格トラッカーでページをインデックスしているとします。同じ商品ページを utm_campaign 違いで2回訪問しても、それは2ページではなく同じ1ページです。DBに書き込む前にトラッカーを削除しないと重複だらけになります。RFC 3986 はこの処理をURL正規化と呼んでいます。

プライバシー — 遷移先にリファラを渡さない

fbclid 付きのリンクをクリックすると、遷移先サイトに「Facebook経由で来た」と伝えるとともに、Facebookがあなたのアカウントと突き合わせ可能なクリックIDを渡してしまいます。Facebookの公式ドキュメントもfbclidを広告アトリビューション用のクリック識別子と説明しています。アクセス前（または保存前）に削除すれば、その追跡経路を断ち切れます。

カスタマーサポートのチケットをきれいにする

「このリンクを踏んだらページが壊れた」— で、そのリンクが600文字あって、utm + gclid + HubSpotがこれまでに出してきたあらゆる追跡パラメータ（__hssc、__hstc、_hsenc、hsa_*）が全部くっついている。貼って、クリーンなURLをコピーして、それをバグ報告に貼り直す。これで本当のパスが読めるようになります。

よくある質問

具体的に何が削除されますか？

utm_ で始まるものすべて（つまり utm_source、utm_medium、utm_campaign、utm_term、utm_content、加えてマーケターが追加したカスタムの utm_*）— さらに約50個の既知トラッキングパラメータの明示リスト: fbclid（Facebook）、gclid と dclid（Google Ads）、mc_eid と mc_cid（Mailchimp）、_ga と _gl（Google Analyticsクロスドメイン）、igshid（Instagram）、yclid（Yandex）、__hsfp/__hssc/__hstc/_hsenc と hsa_*（HubSpot）、mtm_* と pk_*/piwik_*（Matomo）、vero_id、wickedid、_branch_match_id、_openstat など。customer=Ava+Chen のようにページにとって意味のある実際のクエリパラメータは触らずに残します。

パスやハッシュは変更しますか？

いいえ。手を加えるのはクエリ文字列だけです。プロトコル、ホスト、ポート、パス、ハッシュフラグメントはそのまま通ります。たとえば https://shop.example.com/orders/ORD-1001?utm_source=x#summary は https://shop.example.com/orders/ORD-1001#summary になります — パスもハッシュも同じで、クエリだけが消えます。

自分の解析用に utm_source は残したいのですが？

現在のところ削除リストは固定で、ページに直接組み込まれています。カスタムのホワイトリスト／ブラックリストが必要な場合はソースをフォークしてください — パラメータのSetと utm_* の正規表現はコンポーネントの先頭にあります。将来的にオプションとして公開する可能性はありますが、ここに来る人の多くはデフォルトの「全部削除」を求めて来ています。

fbclidはなぜあんなに長いのですか？

Facebookが特定の広告と（多くの場合）特定のユーザーにクリックを紐付けるために使う、不透明で署名付きの識別子だからです。正確なフォーマットは公開されていませんが、Wikipediaのfbclid記事で詳細に解説されています。gclid はGoogle Ads版です。どちらも共有・保存するURLからは安全に削除できます — ページを読み込むのに必要ではありません。

トラッキングパラメータがないURLでも動きますか？

はい。出力JSONは removedCount: 0、空の removed オブジェクト、何も見つからなかった旨を示す note フィールドを返します。cleaned URLは入力とバイト単位で同一になります（ただし new URL().toString() が正規化する分は除く — オリジンに末尾スラッシュが付くなど）。

?utm_source=a&utm_source=b のように同じキーが繰り返されている場合は？

両方とも削除されます。URLSearchParams.delete(name) はその名前のエントリをすべて削除するので、重複は問題ありません。removed オブジェクトには値が1つだけ表示されます（パースされた最後の値）が、現実のURLにutm_sourceを2つ書く人はいません。

その他のURLツール

クリーニングは1つの操作にすぎません。自然に組み合わせやすいツールはこちら：