前回までと、この講義の役割
D-01では、通信は要求を出す側と応える側のやり取りだと確認しました。D-02では、その要求をどこへ送るかを表すURLの構造を、6つの部分に分けて読みました。今回は、その宛先へ実際に送られる要求そのもの、HTTPリクエストの正式な書式を、上から読めるようにします。誰が、どこへ、何を送っているのかが、一枚の要求文として目に見える形になります。
このスライドのポイント
- D-01: 通信は「要求を出す側」と「応える側」のやり取り
- D-02: その要求を「どこへ送るか」を表すURLの構造（6分割）
- 今回: その宛先へ実際に送られる「要求そのもの」＝HTTPリクエストの書式を読む
HTTPとリクエストの定義
まずHTTPとは、ブラウザとサーバーが要求と応答をやり取りするための取り決め、つまりプロトコルです。そのうち、クライアントからサーバーへ送る要求のメッセージをリクエストと呼びます。リクエストは4つの要素でできています。ひとつ目はメソッドで、これは要求の種類を表します。詳しい使い分けはD-05で扱います。ふたつ目はURLで、これはD-02で見た宛先です。三つ目のヘッダーは本文以外の付加情報、四つ目のボディが実際に送るデータ本体です。
このスライドのポイント
- HTTP＝ブラウザとサーバーが要求と応答をやり取りするための取り決め（プロトコル）
- リクエスト＝クライアントからサーバーへ送る要求メッセージ
- 構成する4要素:
なぜ書式を読める必要があるか
この書式を読めないと、AIが書いた通信のコードが実際に何を送っているのかを、自分の目で確かめられません。バイブコーディングでは、AIに通信処理を任せる場面が多くあります。そのとき、飛んでいるリクエストの中身が読めるかどうかで、不具合の切り分けの速さが大きく変わります。逆に読めれば、どこへ何を送っていて、何が足りないのかを具体的に指摘できるようになります。
このスライドのポイント
- 読めないと: AIが書いた通信コードが「実際に何を送っているか」を自分で確かめられない
- バイブコーディングでは通信処理をAIに任せる場面が多い
- 飛んでいるリクエストが読めるかどうかで、不具合の切り分けの速さが変わる
リクエストの構造
リクエストは、上から順に決まった形で積み上がっています。一番上の行に、メソッドとパス、そしてHTTP/1.1という表記が並びます。その下に、名前と値の組であるヘッダーが、必要な数だけ続きます。ヘッダーの並びが終わると、一行だけ空の行が入ります。この空行が仕切りで、その下がボディ、つまり送るデータ本体です。空行を境に、上が付加情報、下が中身だと覚えてください。
このスライドのポイント
- 1行目: メソッド＋パス＋HTTP/1.1
- 2行目以降: ヘッダー群（名前: 値）を必要な数だけ
- 空行（1行）＝仕切り
- 空行の下: ボディ（送るデータ本体）
画面の裏で起きていること
A-03で見たお問い合わせフォームを思い出してください。名前とメッセージを入力して送信ボタンを押した瞬間、フロントエンドがこのリクエストを組み立てて、サーバーへ送っています。画面には何も表示されませんが、裏側では毎回この要求文が作られ、宛先へ飛んでいます。私たちが普段アプリを操作するたびに、目に見えない場所でリクエストが行き来している、という感覚を持っておくと、通信の話がぐっと具体的になります。
このスライドのポイント
- A-03で見たお問い合わせフォームが例
- 送信ボタンを押した瞬間、フロントエンドがリクエストを組み立ててサーバーへ送る
- 画面には出ないが、操作のたびに要求文が作られ、宛先へ飛んでいる
技術サンプル: HTTPリクエストの実物
実物を見てみましょう。要点にあるのが、お問い合わせを送るリクエストの一例です。一行目は、何を、どこへ、を表します。ポストがメソッド、エーピーアイ・コンタクトがパスです。Content-Typeというヘッダーは、ボディの形式がJSONだと伝えています。この正式な意味はD-07で扱います。そして空行の下が、実際に送るデータ本体です。AIには、この機能が送るリクエストをメソッド・パス・ヘッダー・ボディの形で書き出してもらうと、中身を自分の目で確認できます。
このスライドのポイント
- 種別: http
- 目的: お問い合わせを送るリクエストの中身を、上から1行ずつ読む
- サンプル本体:
混同しやすい: ヘッダーとボディ
混同しやすいのが、ヘッダーとボディの違いです。荷物の配送でたとえると、ヘッダーは荷物に貼る送り状、ボディは荷物の中身です。送り状には、中身の扱い方や送り主の情報が書かれますが、送りたいものそのものではありません。ヘッダーは扱い方を伝える情報、ボディが渡したいデータそのもの、と役割で分けて覚えてください。
このスライドのポイント
- ヘッダー＝荷物に貼る「送り状」（扱い方の情報）
- ボディ＝荷物の「中身」（渡したいデータそのもの）
- 送り状は中身の扱い方を伝えるが、送りたいものそのものではない
バイブコーディングでの確認点
通信がからむ不具合をAIに相談するときは、A-07で身につけたエラー原文を渡す習慣に加えて、実際に送ったリクエストも見せると、切り分けが早く進みます。もし、そのリクエストをどこで見ればいいのか分からなければ、まずAIに、このリクエストを確認する方法を教えてください、と聞くところから始めます。何を送っているかが見えて初めて、送り方の間違いに気づけます。
このスライドのポイント
- 通信の不具合では、A-07のエラー原文に加えて「送ったリクエスト」もAIに見せる
- 見方が分からなければ、まず「このリクエストを確認する方法を教えてください」と聞く
- 何を送っているかが見えて初めて、送り方の間違いに気づける
まとめと次回
最後に一問一答です。送るデータ本体は、リクエストのどこに入るでしょうか。……答えは、ボディです。三十秒でまとめます。HTTPはやり取りの取り決め、リクエストはクライアントからの要求メッセージで、メソッド・URL・ヘッダー・ボディの4つでできています。空行から下がボディでした。次回は、送った要求への返事、HTTPレスポンスの読み方へ進みます。関連資料は、API連携 超入門、Webhook入門、API連携ワード100です。
このスライドのポイント
- 一問一答: 「送るデータ本体はリクエストのどこに入る？」→ 答: ボディ
- 30秒まとめ: HTTP＝やり取りの取り決め／リクエスト＝クライアントからの要求メッセージ／構成はメソッド・URL・ヘッダー・ボディ／空行から下がボディ
- 次回: HTTPレスポンス（送った要求への返事）の読み方へ
- 関連資料: 「API連携 超入門」「Webhook入門」「API連携ワード100」
