はじめに
「HTTPって何？」「リクエストとレスポンスって結局どういうこと？」
Webアプリ開発をしていると毎日のように登場する HTTP ですが、なんとなくの理解で使っていませんか？
この記事では、HTTPの仕組みを 図解付き で基礎から丁寧に解説します。読み終わるころには、ブラウザで「Enter」を押してからページが表示されるまでに 裏側で何が起きているか を説明できるようになります。
この記事は 「図解でわかるWeb技術の仕組み」シリーズ の第1回です。
Web開発で必須の基礎知識を、1テーマ1記事で図解していきます。
1. HTTPとは
一言でいうと
HTTP（HyperText Transfer Protocol） とは、クライアント（ブラウザ）とサーバーが データをやり取りするためのルール（プロトコル） です。
もう少し具体的にいうと
- ブラウザで URL を入力してページを表示する
- アプリから API を呼び出してデータを取得する
- フォームに入力した内容を送信する
これらは すべて HTTP通信 で行われています。
2. HTTP通信の全体像
まず、HTTP通信の大きな流れを押さえましょう。
たったこれだけです。 HTTP通信は、以下の2ステップで成り立っています。
| ステップ | 方向 | 内容 |
|---|---|---|
| ① リクエスト | クライアント → サーバー | 「このデータをください」と依頼する |
| ② レスポンス | サーバー → クライアント | 「はい、どうぞ」とデータを返す |
ポイントは 「必ずクライアントから始まる」 ということ。サーバーが勝手にデータを送ってくることはありません（WebSocket等を除く）。
3. HTTPリクエストの構造
クライアントからサーバーに送る「お願い」の中身を見てみましょう。
HTTPリクエストは 4つのパーツ で構成されています。
① リクエスト行（Request Line）
GET /api/users HTTP/1.1
リクエストの 一番重要な1行 です。3つの情報が含まれます。
| 要素 | 例 | 意味 |
|---|---|---|
| メソッド | GET |
何をしたいか（取得・作成・更新・削除） |
| パス | /api/users |
どのリソースに対して |
| バージョン | HTTP/1.1 |
HTTPのバージョン |
② ヘッダー（Headers）
Host: example.com
Accept: application/json
Authorization: Bearer token123
リクエストの メタ情報（付加情報） です。「どのサーバー宛か」「どんな形式で返してほしいか」「認証情報」などを伝えます。
よく使うヘッダーをまとめます。
| ヘッダー | 用途 | 例 |
|---|---|---|
Host |
送信先のサーバー名 | example.com |
Accept |
受け取りたいデータ形式 | application/json |
Content-Type |
送信するデータ形式 | application/json |
Authorization |
認証情報 | Bearer xxxxx |
User-Agent |
クライアントの情報 | Mozilla/5.0 ... |
③ 空行
ヘッダーとボディの 区切り です。「ここからがボディだよ」という合図になります。
④ ボディ（Body）
{ "name": "Taro", "age": 25 }
サーバーに送りたい データ本体 です。GETリクエストでは通常ボディは空で、POST / PUT で使います。
4. HTTPレスポンスの構造
サーバーからクライアントに返す「回答」の中身です。
構造はリクエストとよく似ていますが、1行目がステータス行に変わります。
① ステータス行（Status Line）
HTTP/1.1 200 OK
| 要素 | 例 | 意味 |
|---|---|---|
| バージョン | HTTP/1.1 |
HTTPのバージョン |
| ステータスコード | 200 |
処理結果を表す数字 |
| 理由フレーズ | OK |
ステータスコードの説明 |
② ヘッダー
Content-Type: application/json
Content-Length: 85
レスポンスのメタ情報です。「返すデータの形式」「データサイズ」「キャッシュの制御」などを伝えます。
③ 空行 + ④ ボディ
リクエストと同じく、空行の後にデータ本体が続きます。
5. HTTPメソッド ― 「何をしたいか」を伝える
HTTPメソッドは 「サーバーに何をしてほしいか」を伝える動詞 です。
CRUD操作との対応
データ操作の基本である CRUD と HTTPメソッドは、以下のように対応しています。
| CRUD | HTTPメソッド | SQL に例えると |
|---|---|---|
| Create（作成） | POST |
INSERT |
| Read（読み取り） | GET |
SELECT |
| Update（更新） |
PUT / PATCH
|
UPDATE |
| Delete（削除） | DELETE |
DELETE |
PUTとPATCHの違い
-
PUT: リソース全体を置き換える（全フィールドを送る） -
PATCH: リソースの一部だけを更新する（変更するフィールドだけ送る）
6. ステータスコード ― 「結果」を3桁で伝える
ステータスコードは 処理結果を3桁の数字で表現 したものです。先頭の数字でカテゴリが決まります。
実務でよく遭遇するステータスコード
200 OK → 正常に処理できた
201 Created → リソースの作成に成功した
204 No Content → 成功したが返すデータはない（DELETE等）
301 Moved Permanently → URLが恒久的に変わった
302 Found → URLが一時的に変わっている
304 Not Modified → キャッシュを使ってOK
400 Bad Request → リクエストの形式がおかしい
401 Unauthorized → 認証が必要（ログインしていない）
403 Forbidden → 認証済みだがアクセス権がない
404 Not Found → リソースが見つからない
500 Internal Server Error → サーバー内部で予期しないエラー
502 Bad Gateway → 中間サーバーが不正な応答を受けた
503 Service Unavailable → サーバーが一時的に利用できない
401 と 403 の違い（よく混同されるポイント）
-
401: 「あなた誰？」 → ログインしていない、トークンが無効 -
403: 「あなたは知ってるけどダメ」 → ログイン済みだが権限が足りない
7. 実際のHTTP通信を見てみよう
ブラウザの開発者ツールで確認
実際のHTTP通信は、ブラウザの 開発者ツール（DevTools） で簡単に確認できます。
手順：
- ブラウザで任意のページを開く
-
F12（またはCmd + Option + I）で DevTools を開く - Network タブを選択
- ページをリロード（
Cmd + R）
一覧に表示される各行が 1回のHTTP通信 です。クリックすると、リクエスト/レスポンスのヘッダーやボディを確認できます。
curlコマンドで確認
ターミナルから直接HTTPリクエストを送ることもできます。
# GETリクエスト（ヘッダーも表示）
curl -v https://httpbin.org/get
# POSTリクエスト（JSONデータを送信）
curl -X POST https://httpbin.org/post \
-H "Content-Type: application/json" \
-d '{"name": "Taro", "age": 25}'
-v オプションをつけると、リクエストとレスポンスの ヘッダーがすべて表示 されるので、この記事で学んだ構造をそのまま確認できます。
8. まとめ
この記事で学んだポイントを整理します。
| 項目 | ポイント |
|---|---|
| HTTPとは | クライアントとサーバーがデータをやり取りするルール |
| 通信の流れ | 必ず「リクエスト → レスポンス」の順。クライアントから始まる |
| リクエストの構造 | リクエスト行 + ヘッダー + 空行 + ボディ |
| レスポンスの構造 | ステータス行 + ヘッダー + 空行 + ボディ |
| HTTPメソッド | GET（取得）/ POST（作成）/ PUT（更新）/ DELETE（削除） |
| ステータスコード | 2xx（成功）/ 3xx（リダイレクト）/ 4xx（クライアントエラー）/ 5xx（サーバーエラー） |
次回予告
第2回では 「Cookie・Session・JWT の違い」 を図解で解説します。HTTP通信のたびに「あなたは誰？」と毎回聞かれるのを防ぐ仕組み — ステートレスなHTTPに"状態"を持たせる方法 を学びます。
シリーズ目次
| # | テーマ |
|---|---|
| 1 | HTTPリクエスト/レスポンスの仕組み（この記事） |
| 2 | Cookie・Session・JWT の違い |
| 3 | OAuth 2.0 の仕組み |
| 4 | DNS解決の流れ |
| 5 | HTTPS・TLS通信の仕組み |
| 6 | CDN の仕組みと役割 |
| 7 | WebSocket ― 双方向リアルタイム通信 |
| 8 | キャッシュ戦略（ブラウザ・サーバー・CDN） |
| 9 | CORS ― クロスオリジンの壁を理解する |
| 10 | REST API 設計の基本原則 |
「この記事が役に立った」と思ったら、LGTM とストックをお願いします。
@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！