URL設計と画面設計を連携させる効果的な方法とは？

2025 12/06

2025/12/06

はじめに

本書の目的

本ドキュメントは、画面設計とURL設計を一体で考える重要性と、その具体的な進め方を分かりやすく整理しています。画面構成とURL構造を整合させることで、利用者の操作が直感的になり、検索エンジンにも評価されやすくなります。

読者対象

WebサイトやWebアプリの企画者、デザイナー、フロントエンド／バックエンドの開発者、運用担当者向けです。設計を初めて行う方にも理解しやすいよう、専門用語は最小限にして具体例を交えます。

本書で得られること

画面設計とURL設計を合わせて考えるメリットが分かります。
人に分かるURLの作り方が理解できます。
階層や画面遷移をURLに反映する実践的な方法が身に付きます。

使い方

各章は独立して読めますが、順に読むと理解が深まります。実務で使えるチェックリストや考え方を中心に、すぐに試せる具体例を示します。

なぜ画面設計とURL設計をセットで考えるべきか

概要

WebサイトやWebアプリでは、画面（ページ）構成が情報構造です。URLはその情報構造を外に表現する手段になります。画面設計で決めた分類や階層をURLに反映すると、ユーザーも検索エンジンもサイトを理解しやすくなります。

ユーザー視点の利点

予測しやすさ：ユーザーはURLを見て内容を推測できます。例：/products/coffee/espresso はコーヒーのエスプレッソ商品と推測できます。
ブックマークや共有が便利：意味のあるURLは共有先でも中身が想像しやすく、クリック率が上がりやすいです。

開発・運用の利点

ルーティングと実装が明確になります。画面構成とURLが一致すると実装・テストが楽になります。
分析やキャッシュ、権限管理が扱いやすくなります。階層ごとに集計や制御をかけやすくなります。

具体例

ナビゲーションで「カテゴリ→記事→詳細」を決めたら、/category/{slug}/article/{id} のように反映します。深いリンク（ダイレクトに特定ページへ戻れる）も容易です。

実務上のポイント

画面設計の段階でURL設計を同時に検討する
人が読める短いパスを心がける
後から変えにくいので安易に変更しない

画面とURLを一緒に設計すると、ユーザー体験と開発効率の両方が向上します。

画面設計の基本プロセスとURL設計の関係

画面設計の基本プロセス

画面設計は一般に次の流れで進みます。
1. サイトマップ作成：必要なページを整理し、全体の構成を決めます。
2. TOPページ設計：ファーストビューやナビゲーション、見せたい情報の優先度を決めます。
3. 下層ページのワイヤーフレーム：各ページで何をどの順番で見せるかを設計します。

URL設計との関係

サイトマップ＝画面構成ツリーをそのまま論理的なディレクトリ階層に落とすと、URLが分かりやすくなります。各ページがどの階層に属するかを意識すると、後からURLが散らかりません。

具体例

例：TOP ＞サービス一覧＞サービス詳細
対応URL：/ (TOP)、/services/（一覧）、/services/plan-name/（詳細、または /services/123/）
スラッグ（plan-name）やID（123）は、読みやすさや運用に応じて選びます。

設計時の注意点

階層を深くしすぎない。深い階層は管理が難しくなります。
ページの役割でディレクトリを分けると探しやすくなります。
デザイナーと開発者で階層と命名ルールを早めに合意してください。

意味の分かるURLとは何か（人が読める・推測できるURL）

短い説明

ユーザーがURLを見ただけで、ページの内容や位置づけをある程度推測できることを「人が読めるURL」と呼びます。説明的な単語を含め、読みやすい区切りを使うと分かりやすくなります。

人が読めるURLの特徴

説明的な語を含む：カテゴリ名や商品名など、ページ内容を示す単語を入れます。
単語区切りにハイフンを使う：検索エンジンや人に読みやすいです（例：white-ceramic-mug）。
一部が文章として読める構造：/goods/ceramics/white-mug のように階層で意味を伝えます。
対象言語を使う：日本語サイトなら日本語スラッグや日本語読みのローマ字を検討します。

具体例（良い／悪い）

悪い：/product?id=12345
良い：/products/白い-陶器-マグカップまたは /products/white-ceramic-mug

実務上のポイント

長すぎないようにする（短く要点を伝える）。
説明が必要ならIDを併記：/products/12345-white-ceramic-mug
アンダースコアは避ける（ハイフン推奨）。
URLは安定させる（頻繁に変えない）。

意味の分かるURLはユーザビリティと信頼感を高め、クリック率にも好影響を与えます。

階層構造をURLにどう反映するか

概要

サイトの情報構造（カテゴリ→サブカテゴリ→個別ページ）をURLのスラッシュで表現します。ユーザーが「どのジャンルの、どの中の、どのページか」を即座に理解できます。検索エンジンの巡回効率も上がり、ユーザビリティ向上につながります。

基本ルール

カテゴリやサブカテゴリは順に並べる（例: /books/fiction/novel-title）。
スラッグは短く英数字とハイフンで統一し、小文字にします。
IDは必要時のみ。タイトル変動に強い設計にするなら /posts/12345-title のようにIDを含めます。

階層の深さ

一般的に3階層程度までが見やすいです。深くしすぎると可読性と管理性が下がります。サイト規模に応じて、カテゴリを整理して平坦化を検討してください。

実例と運用上の注意

商品一覧は /products/electronics/televisions
絞り込みは原則クエリ文字列で /search?q=sony&sort=price
多言語はルート直下に言語コードを置く（/ja/、/en/）と分かりやすいです。

ただし、フィルターやソートを無闇にパス化すると管理が複雑になります。リダイレクトの運用と一貫した命名規則を整え、変更時の影響を最小化してください。

画面遷移とURLパターンの一貫性（REST的な考え方も含めて）

前提

URLは「どのリソースを示すか」を表します。閲覧・作成・更新などの動作はHTTPメソッドやUI操作で示す考え方を基本とします。画面URLにも同じ原則を適用すると分かりやすくなります。

基本原則

リソースは名詞で表す（例: schools, students）。
親子関係はパス階層で表現する（例: /schools/sakura/grades/2/classes/3/students/25）。
動作はメソッドや画面要素で扱う。編集画面は/students/25/editか、APIならPUT /students/25。

画面パターン例

一覧: /schools/sakura/students
詳細: /schools/sakura/students/25
新規作成: /schools/sakura/students/new
編集: /schools/sakura/students/25/edit
クエリで階層を表すと親子関係が分かりづらくなります（例: /students?school=sakura&grade=2）。

画面遷移とナビゲーション

URLに一貫性があるとパンくずや戻る操作が自然に働きます。モーダルやフィルタは場合によってクエリやハッシュで扱いますが、共有・ブックマーク可能な状態は個別URLで表現してください。

実践上の注意

リソースごとにパターンを決めて守る。
IDやスラッグは安定的に使う。
クライアントルーティングではHistory APIを利用してブラウザ挙動を保つ。

この方針で画面とURLを設計すると、ユーザーにも開発者にも理解しやすい構造になります。

動詞ではなく名詞ベースでURLを設計する

概要

URLは可能な限り名詞（リソース名）で表現します。画面設計でも同じ方針を採ると、構造が分かりやすくなります。

良い例と悪い例

良い例:
– /students/25 （生徒リソース、IDで参照）
– /about-us/、/services/、/blog/（ページの役割を名詞で表現）

悪い例:
– /getStudentInfo や /showBlogPost（動詞が混じり冗長）

例外と扱い方

ログインや検索は機能名が分かりやすいため /login/、/search?q=キーワードのようにする場合があります。ただし一般ページは名詞で統一してください。

操作やイベントの表現

画面上の操作（購入・削除など）はURLで動詞を表すより、リソースとHTTPメソッドやサブリソースで表現します。例:
– 購入：POST /orders/123/payments
– 削除：DELETE /items/45
画面の遷移でダウンロードや確認が必要なら /files/123 のような名詞にクエリやヘッダで制御します。