誰が頼むかの次は、どこへ頼むか
前回のD-01では、通信で要求を出す側の役割がクライアント、受けて処理し応える側の役割がサーバーだと見ました。誰が頼むかがわかったので、次は「どこへ頼むか」を正確に書く番です。その宛先を表す文字列がURLです。今回は、ふだん何気なく目にしているURLを部品に分解して、一つひとつの意味を読めるようにしていきます。
このスライドのポイント
- D-01: 要求を出す側がクライアント、受けて応える側がサーバー
- 今回は「どこへ頼むか」＝宛先を正確に書く番
- その宛先を表すのがURL
URLを6つの部分に分解する
URLは、通信の宛先を表す一本の文字列です。例として、https://shop.example.com:443/products/list?category=tea&page=2#reviews を6つに分けます。スキームは https で、通信の方式を表します。ホストは shop.example.com で、相手の名前です。ポートは 443 で、相手の窓口番号にあたり、https では省略すると443になります。パスは /products/list で、相手の中のどの場所かを示します。クエリは ? 以降の category=tea&page=2 で、その場所に渡す条件です。フラグメントは #reviews で、ページ内の位置を表し、サーバーへは送られません。
このスライドのポイント
- 例:
https://shop.example.com:443/products/list?category=tea&page=2#reviews - スキーム=通信の方式（https）／ホスト=相手の名前（shop.example.com）
- ポート=窓口番号（443。httpsでは省略時443）／パス=相手の中の場所（/products/list）
- クエリ=渡す条件（category=tea&page=2。?以降、&区切り）
- フラグメント=ページ内の位置（#reviews。サーバーへは送られない）
なぜURLを読める必要があるのか
この分解ができないと、「このページのこの状態」をAIや他の人に正確に伝えられません。たとえば同じ画面に見えても、実際にはクエリの値だけが違うことがよくあります。URLのどの部分が違うのかを言えないと、不具合の原因を切り分けられず、AIにも見当違いの調査をさせてしまいます。6つの部品の名前を持っておくと、報告の精度が一段上がります。
このスライドのポイント
- 「このページのこの状態」を正確に伝えられない
- 同じ画面に見えてもクエリの値だけが違うことがある
- URLのどこが違うかを言えないと、不具合の切り分けができない
6分割の並びを図で見る
構造を図で見てみましょう。先ほどのURLを一本の帯にして、左から順にスキーム、ホスト、ポート、パス、クエリ、フラグメントの6つに区切ります。前半のホストとポートが相手そのもの、パスがその中の場所、クエリがその場所へ渡す条件、という並びです。注意したいのはフラグメントで、これはブラウザの中でページ内の位置を示すために使われ、サーバーへは送られません。まずはこの6分割の並びを、目で追えるようにしてください。
このスライドのポイント
- 1本の帯を左から6つに区切る: スキーム→ホスト→ポート→パス→クエリ→フラグメント
- ホストとポート=相手そのもの／パス=その中の場所／クエリ=場所へ渡す条件
- フラグメントはブラウザ内で使い、サーバーへは送られない
同じ場所か、条件違いかを見分ける
具体例で確かめます。商品一覧のページで、?category=tea と ?category=coffee を比べると、違っているのはクエリの部分だけです。パスはどちらも同じ /products/list、つまり同じ場所に対して、お茶かコーヒーかという違う条件を渡しているだけです。ページ送りの page=2 も同じ仕組みで、同じ場所に「何ページ目か」という条件を渡しています。同じ場所なのか、渡す条件が違うだけなのかを見分けられると、URLの読み方がぐっと楽になります。
このスライドのポイント
?category=teaと?category=coffeeの違いはクエリだけ- パスはどちらも同じ /products/list（同じ場所に違う条件を渡している）
- ページ送りの
page=2も同じ仕組み
サンプル: URLを6つに分解する
サンプルとして、先ほどのURLと6つのラベルの対応図を用意しました。読み方のポイントは二つです。一つ、クエリは ? で始まり、複数の条件は & で区切られます。二つ、フラグメントはサーバーには届かず、ブラウザの中だけで使われます。AIに読み解いてもらいたいときは、「このURLをスキーム・ホスト・ポート・パス・クエリ・フラグメントに分解して説明してください」と頼むとよいでしょう。
パスとクエリを混同しない
混同しやすいのが、パスとクエリの違いです。パスは相手の中のどの場所か、クエリはその場所に渡す条件、という役割の違いがあります。見分け方はこうです。指す場所そのものが変わるならパス、場所は同じで渡す値だけが変わるならクエリです。先ほどの、お茶とコーヒーで変わるのはクエリ、商品一覧から注文履歴のように別ページへ移るならパス、と考えるとはっきりします。
このスライドのポイント
- パス=相手の中のどの場所か／クエリ=その場所に渡す条件
- 場所そのものが変わるならパス、場所は同じで値だけ変わるならクエリ
バイブコーディングでの確認点
バイブコーディングでの確認点です。不具合をAIへ報告するときは、URL全体をそのまま貼るのが基本です。要約して一部だけ伝えると、肝心のクエリの違いなどが抜け落ちてしまいます。ただし一つ注意があります。クエリに氏名やメールアドレスなどの個人情報が入っている場合は、その値だけを伏せてから貼ってください。A-08で見た公開範囲の感覚を、URLの共有にも当てはめる、ということです。
このスライドのポイント
- 不具合をAIへ報告するときはURL全体をそのまま貼る
- 要約すると、肝心のクエリの違いなどが抜け落ちる
- クエリに個人情報（氏名・メール等）が入る場合はその値だけ伏せる（A-08の公開範囲）
まとめと次回
最後に一問一答です。?category=tea の部分の名前は何でしょうか。……答えはクエリ、クエリパラメータとも呼びます。30秒のまとめです。URLはスキーム・ホスト・ポート・パス・クエリ・フラグメントの6つに分解でき、パスは場所、クエリは条件、フラグメントはサーバーには送られません。次回のD-03では、この宛先へ実際に送る要求文、HTTPリクエストの中身に入っていきます。関連資料は、API連携 超入門、API連携ワード100、Vercel公開 完全手順書です。
このスライドのポイント
- 一問一答: 「
?category=teaの部分の名前は？」→ クエリ（クエリパラメータ） - 30秒まとめ: URLは6つに分解でき、パス=場所・クエリ=条件・フラグメントは送られない
- 次回D-03: この宛先へ送る要求文＝HTTPリクエストの中身へ
- 関連資料: API連携 超入門／API連携ワード100／Vercel公開 完全手順書
