長いURLは、そのままだとレビューしにくい

キャンペーンURLやAPIのGETリクエストでは、?utm_source=...&utm_medium=...&id=... のように多くのパラメータが並びます。短いURLなら目視できますが、値が増えるほど、キーの重複、スペルミス、不要なトラッキング値を見落としやすくなります。

URLパラメータをJSONで確認する方法：UTMとAPIクエリの見落としを減らす

DevToolKitsの URLパラメータJSON変換ツール を使うと、URLやクエリ文字列を貼り付けるだけで、キーと値をJSON形式で確認できます。

UTMチェックで見るポイント

広告やSNS投稿用のURLでは、utm_source、utm_medium、utm_campaign の値が計測結果にそのまま影響します。大文字小文字や表記ゆれがあると、アクセス解析側で別キャンペーンとして集計されることがあります。

公開前には、JSON化したパラメータを見ながら、想定した命名ルールに揃っているか確認すると安全です。

APIデバッグにも使える

APIのGETリクエストでは、検索条件、ページ番号、ソート条件などがクエリパラメータに入ります。JSONとして整理すると、仕様書やIssueに貼りやすく、チームで同じ条件を再現しやすくなります。

たとえば次のようなURLをレビューするときです。

https://example.com/search?q=jwt&page=2&sort=updated&tag=security&tag=api

JSON化すると、page が文字列として渡っているのか、tag が複数指定されているのか、空の値が混ざっていないかを確認しやすくなります。API側で tag=security,api を期待しているのに、フロント側が tag=security&tag=api で送っている、というズレも早めに見つけられます。

値がURLエンコードされている場合は、URLエンコード・デコードツール で文字列の意味も確認できます。

Issueに残すときの書き方

不具合報告では、URL全文だけを貼るよりも、分解したJSONと期待値を一緒に残すと再現が速くなります。

{
  "q": "jwt",
  "page": "2",
  "sort": "updated",
  "tag": ["security", "api"]
}

この形なら「検索語」「ページング」「並び順」「絞り込み条件」を別々に確認できます。長いURLを読む負担が減り、レビューする人も差分だけに集中できます。

エンコードと配列表現の落とし穴

URLパラメータをレビューするとき、見落としやすいのがエンコードと配列の表現です。

  • + と %20 の違い: クエリ文字列では空白が + でエンコードされることがあり（application/x-www-form-urlencoded の仕様）、パス部分では %20 が使われます。どちらも空白ですが、デコードの仕方を間違えると + がそのまま残ります。
  • 配列の表現はサービスごとに違う: 同じ「複数の値」でも tag=a&tag=b（繰り返し）、tag=a,b（カンマ区切り）、tag[]=a&tag[]=b（ブラケット）と流派があります。フロントとAPIで前提が食い違うと、片方しか受け取れません。
  • エンコード漏れ: 値に & や = が含まれるのにエンコードされていないと、そこで別パラメータとして切れてしまいます。

JSON化して配列やキーの形を確認し、エンコードされた値はURLエンコード・デコードツールで元の意味を見ると、こうしたズレを早期に発見できます。

まとめ

URLパラメータは、少しの入力ミスで計測やAPIの挙動が変わります。長いURLをそのまま眺めるより、JSONとして分解して確認するだけで、レビューの精度が上がります。

よくある質問

同じキーが複数あるURLはどう扱われますか？

tag=security&tag=api のように同名キーが複数ある場合、JSON化すると配列として確認できます。API側が tag=security,api（カンマ区切り）を期待しているのに複数指定で送っている、といったズレを見つけやすくなります。仕様に合わせてどちらの形式かを確認してください。

UTMパラメータで気をつける点は？

utm_source・utm_medium・utm_campaign は値がそのまま計測結果になります。大文字小文字や表記ゆれ（Twitter と twitter など）があると別キャンペーンとして集計されます。公開前にJSON化して、命名ルールに揃っているか確認すると安全です。

値が %20 のようにエンコードされていて読めません

URLパラメータの値は予約文字を含むとパーセントエンコードされます。%20 はスペース、%2F はスラッシュです。URLエンコード・デコードツールでデコードすると、元の文字列の意味を確認できます。

空白が + になっているのはなぜですか？

クエリ文字列では、application/x-www-form-urlencoded の仕様により空白が + でエンコードされることがあります。一方でパス部分やRFC 3986準拠のエンコードでは %20 が使われます。どちらも空白を表しますが、デコード時にこの違いを考慮しないと + がそのまま残ってしまうため、値を扱うシステムに合わせて確認してください。