URLの読み方 — アドレスバーの文字列を分解してみる

バイブコーディング入門 — 第4回

前回までのおさらいと、今回のテーマ

第1回では、Webアプリは「手紙のやりとり」（リクエストとレスポンス）で動いていることを学んだ。第2回では、フロントエンド・バックエンド・データベースの3層構造を理解した。第3回では、Webの歴史を4つの時代に分けて、なぜ今のコードがこんなに複雑なのかを解説した。

今回のテーマは、毎日何百回と目にしているのに、ちゃんと読んだことがないもの。URLだ。

ブラウザのアドレスバーに表示されている、あの長い文字列。たとえば https://example.com/products?category=shoes&sort=price#reviews のような文字列が、何を意味しているのか。

CursorやClaude Codeでアプリを作ると、AIが自動的にURLの構造を設計してくれる。ページのファイルを app/products/page.tsx という場所に置くと、自動的に /products というURLでアクセスできるようになる。この仕組みを「ルーティング」と呼ぶ。

URLの読み方を知っていると、2つのメリットがある。

1つ目は、エラーの原因が分かりやすくなること。「404 Not Found」が出たとき、URLのどの部分が間違っているか見当がつく。

2つ目は、AIへの指示が正確になること。「/api/users にアクセスすると500エラーが出る」と言えると、AIは問題箇所をピンポイントで特定できる。

URLは「住所」だ

第1回で、リクエストは「手紙」だと説明した。手紙を送るには宛先が必要だ。URLは、その宛先にあたる。つまり「住所」だ。

住所には構造がある。「東京都渋谷区神南1-2-3 ABCビル 5階」のように、大きい単位から小さい単位へと絞り込んでいく。URLも同じだ。

次のURLを例に、1つずつ分解してみよう。

https://example.com/products?category=shoes&sort=price#reviews

このURLは5つのパーツに分かれる。

パーツ1: スキーム — 届け方の指定

https:// の部分がスキーム（scheme）だ。

住所に例えると「届け方の指定」にあたる。書留で送るのか、普通郵便で送るのか。

https:// は「暗号化して安全に届ける」という意味。現在のWebサイトのほぼすべてがこれを使っている
http:// は「暗号化せずに届ける」という意味。古いサイトや開発中のサイトで見かけることがある

https の末尾の s は「Secure（安全）」の頭文字だ。あなたがCursorやClaude Codeで作ったアプリを公開するときも、https が使われる。開発中（自分のパソコンだけで動かしているとき）は http://localhost:3000 のように http で始まることが多いが、これは自分のパソコンの中だけの通信なので問題ない。

localhost というのは「自分のパソコン自身」を指す特別な名前だ。3000という数字はポート番号と呼ばれ、パソコンの中のどの入口で通信を受け付けるかを示している。マンションの部屋番号のようなものだ。

パーツ2: ドメイン — 届け先の建物名

example.com の部分がドメインだ。

住所に例えると「建物名」にあたる。「ABCビル」のように、どの建物に届けるかを示す。

ドメインは右から左に読むと構造が分かりやすい。

.com → 分類（「商業地区」のようなもの。他にも .jp、.org などがある）
example → その分類の中の具体的な名前（ビル名）

実際のサービスで見てみると、こうなる。

google.com → .com地区にあるgoogleというビル
amazon.co.jp → .jp地区の.coエリアにあるamazonというビル
claude.ai → .ai地区にあるclaudeというビル

CursorやClaude Codeで開発中は、ドメインの代わりに localhost が使われる。本番環境（実際にお客さんが使うサイト）に公開すると、yourapp.vercel.app や独自ドメインに変わる。

パーツ3: パス — 建物の中の部屋番号

/products の部分がパスだ。

住所に例えると「建物の中の部屋番号」にあたる。ABCビルの何階の何号室に届けるか。

パスは /（スラッシュ）で区切られていて、左から右に階層が深くなる。

/ → 入り口（トップページ）
/products → productsという部屋（商品一覧ページ）
/products/shoes → productsの中のshoesという部屋（靴の一覧ページ）
/products/shoes/123 → shoesの中の123番（特定の靴の詳細ページ）

ここが、バイブコーディングで一番大事なポイントだ。

Next.js（CursorやClaude Codeがよく使うフレームワーク）では、ファイルの置き場所がそのままURLのパスになる。これを「ファイルベースルーティング」と呼ぶ。

app/page.tsx → / でアクセスできる
app/products/page.tsx → /products でアクセスできる
app/products/[id]/page.tsx → /products/123 や /products/456 でアクセスできる

[id] という角括弧は「ここには何でも入る」という意味だ。商品番号が123でも456でも、同じファイルが使われる。URLに含まれる数字や文字列によって、表示するデータが変わる。

404エラー（ページが見つかりません）が出たとき、真っ先に確認するのはこのパスだ。URLのパスに対応するファイルが存在しなければ、404になる。

たとえば /products にアクセスして404が出たら、app/products/page.tsx というファイルが存在するかを確認する。ファイル名のスペルミスや、フォルダの階層を間違えているケースが多い。

パーツ4: クエリパラメータ — 追加の指示メモ

?category=shoes&sort=price の部分がクエリパラメータだ。

住所に例えると「追加の指示メモ」にあたる。「できれば午前中に届けてください」「不在時は宅配ボックスに入れてください」のような、配達に関する追加情報だ。

構造は次の通り。

? → ここから指示メモが始まるという目印
category=shoes → カテゴリは靴（名前=値のペア）
& → 指示が複数あるときの区切り
sort=price → 並び順は価格順

ECサイトで商品を絞り込んだとき、URLが長くなるのを見たことがあるはずだ。あれがクエリパラメータだ。Amazonで検索すると、URLに ?k=キーワード&ref=... のような文字列がつく。検索条件やフィルターの情報がURLに埋め込まれている。

クエリパラメータはページの中身を変えるが、パスとは違ってファイルの場所には影響しない。/products?category=shoes も /products?category=bags も、同じ app/products/page.tsx ファイルが使われる。ファイルの中で、クエリパラメータの値を読み取って、表示する内容を変えている。

パーツ5: フラグメント — 部屋の中の見てほしい場所

#reviews の部分がフラグメント（fragment）だ。ハッシュ、アンカーとも呼ばれる。

住所に例えると「部屋に入った後、見てほしい場所」にあたる。「応接室のテーブルの上に書類を置いてあります」のような、部屋の中のどこを見るかの指定だ。

フラグメントは、ページ内の特定の位置にジャンプするために使われる。たとえばWikipediaの記事で目次のリンクをクリックすると、URLの末尾に #歴史 のような文字列がつく。ページ全体を読み込み直すのではなく、ページの中の「歴史」という見出しの位置までスクロールする。

他の4つのパーツとの大きな違いがある。フラグメントはサーバーに送られない。ブラウザだけが解釈する。住所に例えるなら、配達員（サーバー）は「ABCビル5階」まで届ければ任務完了。その後「応接室のテーブルの上」を見るのは、受け取った人（ブラウザ）の仕事だ。

5つのパーツをまとめて見る

もう一度、最初のURLを分解してみよう。

https://example.com/products?category=shoes&sort=price#reviews

https:// → 暗号化して安全に届ける（スキーム）
example.com → example.comという建物に届ける（ドメイン）
/products → productsという部屋を開く（パス）
?category=shoes&sort=price → カテゴリは靴、並び順は価格（クエリパラメータ）
#reviews → ページの中のレビュー欄を表示する（フラグメント）

5つのパーツそれぞれに意味がある。全部を暗記する必要はないが「URLには構造がある」という感覚を持っておくことが大事だ。

ルーティング — URLとページを結びつける仕組み

URLの読み方が分かったところで、CursorやClaude Codeが作るアプリの中で、URLがどう処理されているかを見てみよう。

ルーティング（routing）とは、URLのパスを見て「どのページを表示するか」を決める仕組みのことだ。レストランに例えるなら、案内係（ルーター）がお客さんの予約番号（URL）を見て、どのテーブル（ページ）に案内するかを決めるようなものだ。

Next.jsでは、ファイルの置き場所がそのままルーティングのルールになる。これは先ほどパスの説明で触れた「ファイルベースルーティング」のことだ。

AIがアプリを生成したとき、app/ フォルダの中にたくさんのフォルダとファイルが作られる。その構造を見れば、アプリのどのURLにどのページが対応しているかが分かる。

例として、こんなフォルダ構造があったとする。

app/ page.tsx → / about/ page.tsx → /about products/ page.tsx → /products [id]/ page.tsx → /products/123 api/ users/ route.ts → /api/users

フォルダの名前が、そのままURLのパスになっている。シンプルだ。

ここで1つ注意点がある。app/api/ フォルダの中にあるファイルは、ページではなくAPIのエンドポイント（データの受け渡し口）だ。第3回で解説したREST APIの話を思い出してほしい。/api/users にアクセスすると、HTMLのページではなく、JSONデータが返ってくる。

バイブコーディングでURLを意識する場面

実際にCursorやClaude Codeでアプリを作っているとき、URLの知識が役に立つ場面を3つ紹介する。

場面1: 404エラーが出た

アプリを作って、ブラウザで開いたら「404 Not Found」が表示された。このとき確認するのは、URLのパスとファイルの場所の対応だ。

/about にアクセスして404が出たなら、app/about/page.tsx が存在するか確認する。よくある原因は次の3つ。

ファイル名のスペルミス（page.tsx が Page.tsx になっているなど）
フォルダの場所が間違っている（app/about/page.tsx ではなく about/page.tsx に置いてしまった）
ファイルの作り忘れ（AIに指示したが、ファイルが生成されていなかった）

場面2: データが取得できない

ページは表示されるが、データが表示されない。開発者ツールのNetworkタブ（第1回で紹介した）を見ると、/api/products へのリクエストが404になっている。

この場合、app/api/products/route.ts が正しい場所にあるか確認する。パスの /api/products に対応するファイルが見つからないので、データが取得できていない。

場面3: AIに新しいページを追加してもらう

AIに「ユーザーのプロフィールページを追加して」と頼むとき、URLの知識があるとこう指示できる。

「/users/[id] でアクセスできるプロフィールページを作ってほしい。app/users/[id]/page.tsx に配置して」

URLとファイルの場所を明示すると、AIは迷わずに正しい構造でコードを生成してくれる。

よくある不安と答え

URLの仕組みを全部覚えないと使いこなせないのか？

覚える必要はない。日常的に意識するのはパス（部屋番号）の部分だけだ。スキームやドメインは、公開するときに1回設定すれば終わる。クエリパラメータとフラグメントは、必要になったときに調べれば十分だ。

localhostの3000という数字は変えられるのか？

変えられる。ただし、特に理由がなければ変える必要はない。CursorやClaude Codeが自動で設定してくれるので、あなたが意識することはほぼない。もし他のアプリがすでに3000番を使っていると、自動的に3001や3002に変わることがある。

URLが長くなるのは問題ないのか？

通常は問題ない。ただし、URLに機密情報（パスワードやAPIキー）を含めてはいけない。URLはブラウザの履歴に残り、サーバーのログにも記録される。機密情報はリクエストの本文（body）に含めるのが安全だ。これはAIが自動的に正しく処理してくれるが、知っておくと安心できる。

まとめ

URLは5つのパーツで構成されている。スキーム（届け方）、ドメイン（建物名）、パス（部屋番号）、クエリパラメータ（追加の指示）、フラグメント（部屋の中の場所）。バイブコーディングで最も重要なのはパスの部分だ。Next.jsではファイルの置き場所がそのままURLのパスになる。404エラーが出たらパスとファイルの対応を確認する。この知識があるだけで、エラーの原因特定とAIへの指示が格段に速くなる。

次回は「いいURLの設計 — RESTfulという考え方」。URLにどんな名前をつけるとアプリが分かりやすくなるのか、AIに指示するときのコツを解説する。

参考リファレンス

MDN Web Docs「URLとは何か」— URLの構造と仕様に関する公式リファレンス
前回: 第3回「Webの歴史を5分で — なぜ今の形になったのか」（/articles/vc-003）
次回: 第5回「いいURLの設計 — RESTfulという考え方」（/articles/vc-005）
バイブコーディング入門カリキュラム（/vibe-coding）

URLの読み方 — アドレスバーの文字列を分解してみる｜バイブコーディング入門第4回