バイブコーディング URL設計｜AIに伝わる「いいURL」の作り方ガイド
冒頭
従業員15人の社労士事務所で、バイブコーディングを使って顧問先管理ツールを作った方がいる。完成したアプリを事務所のスタッフに使ってもらったところ、こんな声が上がった。「今どのページを見ているのか分からない」「戻るボタンを押すと変なページに飛ぶ」「ブックマークしたのに、開くと毎回トップに戻る」。
アドレスバーを確認すると、すべてのページのURLが https://myapp.com/#/ のようになっていた。どのページを開いても同じURLだ。これでは、特定の画面を直接開いたり、同僚に「このページを見て」とURLを共有したりできない。
8人のデザイン事務所でも似た問題が起きた。案件管理ツールのURLが /page1、/page2、/page3 という名前になっていて、どれがどの画面か分からない。
URLの付け方（URL設計と呼ぶ）次第で、アプリの使いやすさは大きく変わる。そして、バイブコーディングではAIに「こういうURL構造にして」と伝えるだけで、整理されたURLを作ってもらえる。
この記事では、いいURLの5つのルールと、AIへの具体的な伝え方を解説する。記事の最後に、URL設計テンプレート（業種別のURL構造のひな型）をPDFで無料ダウンロードできる。
いいURLとは何か
いいURLとは、アドレスバーを見ただけで「このページに何があるか」が想像できるURLのことだ。
例を挙げる。
悪いURLの例:
- /page1 → 何のページか分からない
- /data?id=3&view=detail → 記号と数字だらけで意味不明
- /a/b/c/d/e → 階層が深すぎる
いいURLの例:
- /clients → 顧客の一覧だと分かる
- /clients/123 → 顧客ID 123の詳細だと分かる
- /clients/new → 新しい顧客の登録画面だと分かる
いいURLになっていると、3つのメリットがある。
1つ目は、アプリを使う人が迷わない。アドレスバーを見れば今どこにいるか分かるので、「あれ、今どのページだっけ？」がなくなる。
2つ目は、URLを共有できる。「/clients/123/reports を見てください」と同僚にURLを送れば、その画面が直接開く。いいURLになっていないと、「トップページを開いて、左のメニューから顧客一覧を選んで、123番をクリックして、レポートタブを押して……」と手順を説明することになる。
3つ目は、バイブコーディングでの修正がしやすい。「/clients/new のフォームに住所欄を追加して」のように、AIに修正箇所を的確に伝えられる。
いいURLの5つのルール
エンジニアの世界では、URLの設計パターンについて多くの議論がある。REST（レスト）やRESTful（レストフル）という設計思想が有名だが、ここでは非エンジニアの方が覚えるべき本質だけを5つのルールにまとめた。
ルール1: 名前は「そのページに何があるか」を表す英単語にする
/page1 や /screen-a ではなく、ページの内容を表す英単語を使う。
- 顧客一覧 → /clients
- 請求書一覧 → /invoices
- 設定 → /settings
- ダッシュボード → /dashboard
AIへの伝え方: 「各画面のURLは、内容を表す英単語にして。/page1 のような連番は使わないで」
英単語が思いつかなくても大丈夫だ。AIに「顧問先管理のページを作って」と伝えれば、AIが /clients のような適切な英単語を選んでくれる。
ルール2: 階層は「大きなカテゴリ → 個別 → 詳細」の順にする
URLの階層は、左から右へ「大きなカテゴリから個別の項目へ」と並べる。
- /clients → 顧客という大きなカテゴリ
- /clients/123 → その中の個別の顧客
- /clients/123/invoices → その顧客の請求書
この構造は、フォルダの中にフォルダがあるのと同じだ。パソコンでファイルを整理するとき、「顧客」フォルダの中に「田中商事」フォルダがあり、その中に「請求書」フォルダがある。URLも同じ発想で階層を作る。
AIへの伝え方: 「URLの階層は、大カテゴリ → 個別ID → サブ情報の順で統一して」
ルール3: 一覧・詳細・新規作成・編集のパターンを統一する
アプリのほとんどの画面は、次の4つのパターンに分類できる。
- 一覧: /clients（顧客の一覧を見る）
- 詳細: /clients/123（特定の顧客の情報を見る）
- 新規作成: /clients/new（新しい顧客を登録する）
- 編集: /clients/123/edit（既存の顧客情報を修正する）
このパターンをすべての機能に統一すると、アプリ全体の一貫性が保たれる。
- 請求書の一覧 → /invoices
- 請求書の詳細 → /invoices/456
- 新しい請求書 → /invoices/new
- 請求書の編集 → /invoices/456/edit
顧客でも請求書でも案件でも、同じパターンだ。使う人は「/○○ が一覧、/○○/new が新規作成」と覚えれば、すべての画面に応用できる。
AIへの伝え方: 「すべてのデータ管理画面は、/○○（一覧）、/○○/new（新規作成）、/○○/ID（詳細）、/○○/ID/edit（編集）のパターンで統一して」
ルール4: 階層は3つまでにする
URLの階層が深すぎると、URLが長くなり読みにくくなる。
悪い例: /clients/123/projects/456/tasks/789/comments/012
このURLは4階層もある。アドレスバーに収まりきらないし、共有するときにも不便だ。
いい例: /projects/456/tasks/789
階層は最大3つまでに抑えるのが目安だ。3つ以上必要になったら、それは設計を見直すサインだ。
AIへの伝え方: 「URLの階層は最大3段階までにして。それ以上深くなる場合は、構造を見直して」
ルール5: URLに動詞を入れない
URLには「何があるか」を書く。「何をするか」は書かない。
悪い例:
- /get-clients → 「取得する」は動詞
- /create-invoice → 「作成する」は動詞
- /delete-project/123 → 「削除する」は動詞
いい例:
- /clients → 顧客データがある場所
- /invoices/new → 新しい請求書の画面
- /projects/123 → 案件123の画面
URLは「場所」を表すものであり、「行動」を表すものではない。図書館の棚に「本を借りる」と書くのではなく「小説」と書くのと同じだ。
AIへの伝え方: 「URLには動詞（get、create、delete等）を使わないで。名詞だけで構成して」
実際にAIに伝えてみよう — 会話のサンプル
少しだけ、AIとのやり取りの例が出てくる。そのままコピーして使えるので、意味は分からなくてもOKだ。
バイブコーディングでアプリを作り始めるとき、最初にURL構造をAIに伝えておくと、あとから整理し直す手間がなくなる。
伝え方の例（そのままコピーして使える）:
「これから顧問先管理ツールを作ります。以下のルールでURL構造を設計して。
- 各画面のURLは内容を表す英単語にする（/page1のような連番は使わない）
- 階層は大カテゴリ → 個別ID → サブ情報の順
- 一覧は /○○、詳細は /○○/ID、新規は /○○/new、編集は /○○/ID/edit で統一
- 階層は最大3段階まで
- URLに動詞は使わない
必要な画面:
- ダッシュボード（トップページ）
- 顧問先の一覧・詳細・登録・編集
- 請求書の一覧・詳細・作成・編集
- 月次レポートの一覧・詳細
- 設定」
AIはこの指示を受けて、次のようなURL構造を提案してくれる。
- / → ダッシュボード
- /clients → 顧問先一覧
- /clients/new → 顧問先登録
- /clients/123 → 顧問先詳細
- /clients/123/edit → 顧問先編集
- /invoices → 請求書一覧
- /invoices/new → 請求書作成
- /invoices/456 → 請求書詳細
- /invoices/456/edit → 請求書編集
- /reports → 月次レポート一覧
- /reports/2026-03 → 2026年3月のレポート
- /settings → 設定
このURL構造を最初に決めておけば、あとから画面を追加するときも同じパターンに沿って整理できる。「/clients/123/invoices に、その顧問先の請求書一覧を追加して」のように、既存の構造に自然に組み込める。
業種別のURL構造テンプレート
あなたの業種に合わせたURL構造のひな型をいくつか紹介する。これをAIに渡して「この構造でアプリを作って」と伝えれば、整理されたアプリが出来上がる。
会計事務所・税理士事務所
- / → ダッシュボード（今月の対応一覧）
- /clients → 顧問先一覧
- /clients/new → 顧問先登録
- /clients/123 → 顧問先詳細
- /clients/123/visits → 訪問記録
- /clients/123/documents → 書類管理
- /schedule → 月間スケジュール
- /settings → 事務所設定
不動産会社
- / → ダッシュボード（本日の内見予定）
- /properties → 物件一覧
- /properties/new → 物件登録
- /properties/123 → 物件詳細
- /customers → 顧客一覧
- /customers/456 → 顧客詳細
- /viewings → 内見スケジュール
- /contracts → 契約管理
フリーランス（デザイナー・ライター等）
- / → ダッシュボード（今月の案件状況）
- /projects → 案件一覧
- /projects/new → 新規案件
- /projects/123 → 案件詳細
- /projects/123/tasks → タスク管理
- /invoices → 請求書一覧
- /invoices/new → 請求書作成
- /portfolio → ポートフォリオ
よくある不安と答え
途中でURL構造を変えられるのか
変えられる。AIに「/page1 を /clients に変更して、既存のリンクも全部修正して」と伝えれば、対応してくれる。ただし、すでに公開しているアプリの場合、ブックマークや共有されたURLが無効になるので注意が必要だ。公開前にURL構造を決めておくのが一番手間が少ない。
英語が苦手でも大丈夫か
AIが英単語を選んでくれるので、大丈夫だ。あなたが日本語で「顧問先管理のページ」と伝えれば、AIが /clients という英単語を選ぶ。英語で指定する必要はない。
ルールを全部覚えなくても使えるか
使える。5つのルールを全部覚えなくても、先ほどの「伝え方の例」をそのままAIにコピーして渡せば、AIが5つのルールに沿ったURL構造を作ってくれる。テンプレートをコピーして使うだけで十分だ。
まとめ
いいURLとは、見ただけで何のページか想像できるURLのことだ。5つのルール（意味のある英単語、階層の順序、一覧/詳細/新規/編集の統一、3階層まで、動詞を使わない）を最初にAIに伝えておくだけで、使いやすいアプリが出来上がる。この記事の「伝え方の例」をコピーしてAIに渡すところから始めてみてほしい。
🎁 特典
この記事で紹介した5つのルールと、業種別のURL構造テンプレート（会計事務所・不動産・士業・フリーランスの4業種分）をPDFにまとめた。バイブコーディングでアプリを作り始める前にAIに渡せば、整理されたURL構造を最初から手に入れられる。
→ URL設計テンプレートPDF を無料ダウンロード /resources
📚 参考リファレンス
- Claude Worksバイブコーディング URL 読み方— URLの基本構造を理解する
- Claude Worksバイブコーディングとは— バイブコーディングの基礎解説
- Claude Worksバイブコーディング コツ— 指示の出し方9選
- Claude WorksClaude Code 使い方— Claude Codeの基本操作