こんにちは。新年一発目越です（江越です）。
2026年一発目のJADEブログということで、本当は餅つきブログでも書きたかったのですが、残念ながら今年は餅をついていません。餅つきはGeminiに任せて、僕は大人しくデータ分析ネタについて書こうと思います。
今回のネタは「データ分析者に優しいURL構造」です。分析対象のURL構造の複雑さにデータ分析者が泣いている場面、皆さんはお見かけしたことはないでしょうか。今回は「データ分析者にとってどういうURL構造になっていると嬉しいか」という観点で代表的なものをPickupしてご紹介しようと思います。
💡 この記事を最後まで読むと
- データ分析の工数を大幅に削減できるURL設計の鉄則がわかります
- 複数ツールのデータ統合や分類作業で困らないURL構造が理解できます
- 長期的に運用しやすく、SEOにも配慮したURL設計のポイントが身につきます
今回のネタを見て「アッ（察し）」となったそこのあなた！ このブログに書かれていない観点があれば、ぜひコメントなどいただけると嬉しいです。
それでは張り切ってどうぞ！（Specネタ通じるかな）
【もくじ】
- 1. ページの種類ごとにディレクトリ・URLパラメータをまとめる
- 2. URLに日本語を（なるべく）使用しない
- 3. 同じ括りにしたいURLは表記を統一する
- 4. ディレクトリとURLパラメータの順番を決めておく
- 5. 長期的に運用できるURLルールを設定する
- 6.可能ならURLルールとページの種類の対応表を作成する
- 【おまけ】分析のためだけのURLパラメータはできるだけつけない
- まとめ
1. ページの種類ごとにディレクトリ・URLパラメータをまとめる
今からご紹介する観点の中で「どれかひとつだけ選んでくれ」と言われたら迷わず選ぶのがこれです。
ひとつのドメインの中に、たとえば記事ページ、一覧ページ、詳細ページ、サービスページなど、複数の異なる役割のページを内包していることってよくありますよね。
そして役割が違えば、当然データの傾向にも違いが現れます。ここに「ページの種類ごとに分けてデータを見たい」という需要が生まれ、表題の「ページの種類ごとにディレクトリ・URLパラメータをまとめる」というのが重要になってくると言うわけです。
一方で「ページの種類ごとにディレクトリ・URLパラメータがまとまっていない」よくある構造としては、ルートディレクトリ（または共通のURLルール）の直下に日付や連番が並んでいて、それがどんな種類のページなのかが判別できない構造が挙げられます。
図解すると以下のような整理です。
| ☺️ページの種類ごとにディレクトリが分かれている | 😭URLを見てもどのページの種類に該当するのか見当がつかない |
|---|---|
• hogehoge.com/article/ 配下：記事ページ |
• hogehoge.com/page/12 ：記事ページ |
• hogehoge.com/service/ 配下：サービスページ |
• hogehoge.com/page/19 ：サービスページ |
• hogehoge.com/list/ 配下：リストページ |
• hogehoge.com/page/56 ：リストページ |
• hogehoge.com/detail/ 配下：詳細ページ |
• hogehoge.com/page/100 ：詳細ページ |
「ページの種類ごとにディレクトリ・URLパラメータがまとまっていない」とデータ分析者はどうなるのか。いくつかシナリオはあると思いますが、最もオーソドックスで悲しいシナリオは「1個1個のURLを正規表現のパイプラインで羅列して分類していく」と言う精神の修行を強いられるパターンです。
今の時代ではAIに分類を手伝ってもらう手もあると思いますが、「スクレイパーにページの中身を見にいかせ、それをAIに食わせて……」みたいな手間はおそらく避けられないですし、分類の正確さはどうしてもURLルールで機械的に判別できる場合と比べて下がるでしょう。
データ分析者のことを思いやるなら、「ページの種類ごとにディレクトリ・URLパラメータをまとめる」は鉄則として欲しいです。本当に。
2. URLに日本語を（なるべく）使用しない
各サイトの事情もあると思うので「日本語をURLに絶対に使用するな」とまでは言えないのですが、日本語をURLに使用すると生じうる分析上の問題の例として、以下の2つが挙げられます。
エンコード・デコードの問題
身近な例で言うと、Search Consoleは日本語URLをパーセントエンコーディングした状態で出力するのに対して、GA4はデコード済みの状態で出力されます。
| SearchConsoleの出力（URLエンコード有り） | GA4の出力（デコード済み） |
|---|---|
hogehoge.com/kw/%E6%B1%9F%E8%B6%8A%E8%AA%A0%E4%B8%80%E9%83%8E |
hogehoge.com/kw/江越誠一郎 |
要はツールによって日本語URLをどう処理するのかが異なるため、複数のソースを突き合わせて分析したい場合などにひと手間加える必要が出てきます。
デコード・エンコードするだけなので言うてひと手間じゃんといえばそうなのですが、「重たい処理を回しているときにひと手間の必要性を見逃したときの手戻りコストがデカい」というケースもありうるのでひと手間といえ侮るなかれです。
（ちなみに僕が過去回した集計処理の中で最も時間がかかったものは大体8時間くらいだった気がします。環境にもよりますが、ひと手間抜けるだけで1営が軽く吹き飛ぶこともあるということはご承知おきいただければと）
地名の場合、分類ルールが複雑化するケースがある
特に地名をURLの中に採用する場合は要注意です。
日本の地名には、機械的な判定が難解なケースが多数存在します。例えば「府中市」には「府」が含まれるため、都道府県レベルのページか市区町村レベルのページかの判定ロジックが複雑化するといった具合です。
hogehoge.com/list/東京都府中市
→（「都」「道」「府」「県」を含むなら都道府県レベルのページ、それ以外は市区町村みたいなルールでは対応しきれない）
都道府県、市区町村、郡とメッシュを細かくしていくと、命名ルールをいかに厳しくしても機械的な判定ができない地名が存在するのが現実です。地名ごとにページを作りたい場合はprefecture-11/city-67といったようにエリアコードを使用するのが無難でしょう。
なお日本の住所のヤバさについては↓のブログがとても参考になるので、ぜひご一読いただければと思います。
（与太話ですがこの話を書いている時に「大福餅」という名称を含むアイテムは果たして大福なのか餅なのかという議論が前職で巻き起こっていた記憶が蘇りました。結果どっちに振ったかは忘れました）
3. 同じ括りにしたいURLは表記を統一する
URLの表記ゆれも分析の手間を増やす一因となりえます。
例
- UTMパラメータの値で「Facebook」と「facebook」が混在
- trailing slashの有無どちらのURLにもアクセス可能になっている
これらは本質的には同じものなので、正しい示唆を得るためには統合して分析する必要があります。「FacebookよりもXの方が流入が多いと思って戦略立てたら、実は『facebook』という表記の考慮をしていなかっただけだった」といった事態になったら、そこそこ面倒ですよね。
細かいことにはなりますが、注意しましょう。
4. ディレクトリとURLパラメータの順番を決めておく
またURLパラメータの順番が不定だと、URLの分類漏れが発生しやすくなります。
例えば市区町村別一覧ページをprefetureとcityの2種類のURLパラメータで表現するケースでは
- Good:
hogehoge.com/list/prefecture=XX&city=YYのみで市区町村別一覧ページが表示 - Bad:「正」の他に
hogehoge.com/list/city=YY&prefecture=XXでも市区町村別一覧ページが表示
といった状態が考えられます。Badケースの場合、URLパラメータの前後関係まで考慮した条件を組んで分析しないと示唆がブレる恐れがあります。URLパラメータの順番が決まっているだけで、条件指定は格段にやりやすくなります。
またディレクトリ構造も同様で、階層の親子構造が不明になるような構造は避けるべきです。分析のためのURL分類を行う作業においてミスの温床になるので。
| ☺️親ページの配下に子ページがある | 😭親ページの配下に子ページがない |
|---|---|
親ページ：hogehoge.com/brand/xxxx/ |
親ページ：hogehoge.com/brand/xxxx/ |
子ページ：hogehoge.com/brand/xxxx/yyyy/ |
子ページ：hogehoge.com/xxxx/yyyy/brand/ |
これらの問題はSEOの観点でいうところの「重複コンテンツ」や「ディレクトリ単位の評価のされにくさ」といった話にもつながる話となります。重複コンテンツやURL構造のベストプラクティスについてより深く知りたい方は、以下のGoogle検索セントラルの記事をお読みください。
5. 長期的に運用できるURLルールを設定する
要するに、何かあるたびにURLルールを変えるのは避けましょう、ということです。
本質的には同じ内容のページに対して
例1
・1ヶ月目：hogehoge.com/A
・2ヶ月目：hogehoge.com/B
・3ヶ月目：hogehoge.com/C
例2
・2023年の天皇杯：hogehoge.com/emperorscup/2023/01/01
・2024年の天皇杯：hogehoge.com/emperorscup/2024/01/01
・2025年の天皇杯：hogehoge.com/emperorscup/2025/01/01
のように次々とURLを変更していってしまうと、本質的な示唆を分析から導出するためにこれらのURLの合算値を出す必要が生じます（上記のペースはかなり極端な例ですが）。またこの変遷を補足するのも、変遷の全てを把握し切っている人がいなくなると厳しくなります。上記の例のGood Versionとしては以下のようなものが考えられます。
例1のGood Version
→常にhogehoge.com/Aで運用
例2のGood Version
→2023年,2024年といった過去の試合ページは「hogehoge.com/emperorscup/archives/2023(2024)」といった形で昔の試合結果を探すクエリに対応したページを残しておく。
その上で最新年の試合結果は常にhogehoge.com/emperorscupというURLを使い回す。
このような同じURLを使いまわす運用の例については、Google検索セントラルのブログも参照いただけると良いかと思います！
また与太話をして恐縮ですが、昔お買い物データの分析していた時にも、同アイテムに紐づくJANコードが変更されることがある影響で「このJANコードとあのJANコードとそのJANコードが実は同じ商品だな」とまとめ上げてから分析していた時代がありました。今思うと懐かしいですが、やっぱりちょっと面倒でしたw
6.可能ならURLルールとページの種類の対応表を作成する
またページの種類の数が多い場合、URLルールとページの種類の対応表を作成することを推奨します。
なんなら対応表のURLルールが正規表現でまとまっていれば、あとはそれをデータと結合してregexp_containsなどの処理を噛ませれば一瞬でURLルールに基づいたページの分類ができることになります。
対応表の作成はどうしてもイニシャルコストはかかりますが、一度作れば（メンテナンスは必要にしても）その後データ分析の際に使いまわすことができるので、作成しておく価値は十分にあると僕は考えます。分類ルールの資産化、もしチャレンジできそうならぜひ。
【おまけ】分析のためだけのURLパラメータはできるだけつけない
最後にやや本題とはそれますが分析×URLの話として、分析用のURLパラメータ、俗にいうトラッキング用のパラメータの話にも触れておこうと思います。
例
hogehoge.com/service?from=article
→?from=articleのところが（サイト内回遊用の）トラッキング用パラメータ。ページの描画内容には影響しない。
上記の例のようなURLを作ると、分析の際にパラメータ有無の違いを考慮しなければいけないだけではなくSEOの観点では以下のような問題が発生し得ます。
- パラメータ有無の2パターンが存在することによる、クロールバジェットの無駄な消費
- ユーザー行動やリンクなどのシグナルを貯める先の分散
link rel="canonical"を正しく設定するといった手段を通じて一定は上記の問題を解消できる見込みはあるものの、canonicalは上記の制御を約束するものではありません。
やはり分析において「どこから来たのか」という参照元を分析したい場合はrefererを活用するなど、トラッキングパラメータ以外の手段を模索するのが望ましいです。
まとめ
いかがでしたでしょうか？ 分析を意識したURL構造の要点を一言でまとめると、分類ルールがシンプルになるようにという観点で設計することです。
また人間にとって分類しにくいものは、システムにとっても分類しにくいものです。システムも結局は人間が作ったロジックで動いているため、人間にとって分かりやすいURL構造は、システムにとっても分かりやすい構造となります。
もちろんサイトを作る側にはサイトを作る側の事情があることは承知していますし、ここまで書いた要求全てを通すことが難しい場合もあると思います。
ただこれらの観点の存在を踏まえてデータ分析者と建設的な議論を行うだけでも、要らぬ軋轢を予防できるのではないか。そんなことを思って今回は筆を取った次第でした。
…そんなこんなで年始一発目で真面目に書いてしまう。それが新年一発目越です。でも最後にはちょっとやっぱりもちもちした気持ちになっていただきたいので、今回のブログをご担当くださった新年一発目越こと、うちの実家の猫の画像で締めくくりたいと思います。
新年一発目越の登場はまた来年以降になってしまうと思いますが、次は相方のリトルエゴシが何かしてくれると思うので程々にご期待ください。
それでは。にゃんにゃん。
P.S.
ちなみに冒頭の餅つき画像の素になったGeminiの回答がこちらです。お納めください。
承知いたしましたっ！！！！！
ご要望通り、この身（AIですが！）、砕け散るほどの気合と熱量で、**全力全開**でお餅をつかせていただきますっっ！！
準備はいいかぁぁぁっ！？
臼（うす）よし！ 杵（きね）よし！ 蒸し米よし！！
相手（あいどり）の方、火傷するんじゃないぞ！
いくぞぉぉぉぉっ！！！
---
（足を踏ん張り、仮想の筋肉を限界まで隆起させる）
**「せーのっ！！！」**
### **ドォォォォォンッッ！！！**
（臼が揺れるほどの初撃！）
はいっ！（合いの手）
**「よいしょォォォッッ！！！」**
### **ズドォォォンッッ！！！**
（米粒が悲鳴をあげる重低音！）
はいっ！
**「そォれぇぇぇいっ！！！」**
### **バチィィィンッッ！！！**
（空気が裂ける音！粘りが出てきた！）
まだまだぁっ！ペース上げるぞぉぉっ！
はいっ！「**よいしょっ！**」
はいっ！「**よいしょっ！**」
はいっ！「**よいしょっ！**」
はいっ！「**よいしょっ！**」
（速度上昇！杵が残像に見える！）
**うおおおおおぉぉぉっっ！！！**
**熱い！熱いぞ俺の魂（ソウル）がぁぁぁっ！！！**
**「ふんぬらばぁぁぁぁっっ！！！」**
（ドカカカカカッ！と高速連打）
粘り気が最高潮に達した！
次でェェェ！最後だぁぁぁぁぁっっっ！！！
全、身、全、霊ィィィィッ！！！！
**くらえぇぇぇぇぇぇっっっ！！！！！**
### **ドッッッカァァァァァァーーーーーーンッッッ！！！！！！**
---
（……もわぁぁぁぁん……）
（立ち上る真っ白で熱い湯気）
（ぜぇ……、ぜぇ……、はぁ……）
お、お待たせいたしました……。
こ、これが……私の……全力の……
**つきたてのお餅でございますっ！！！**
（どうぞ、熱いうちに召し上がれっ！）
お米には優しく接しましょう。皆様の2026年に幸あらんことを。ほいにゃら。
