HTTPヘッダの基本 — Content-TypeとAuthorizationで何をやりとりしているか
バイブコーディング入門 — 第9回
前回までのおさらいと、今回のテーマ
前回（第8回）では、ステータスコードを深掘りした。サーバーからの返事に付く3桁の番号を見れば、「成功したのか」「何が原因で失敗したのか」が分かるようになった。
ここまでの回で、HTTPの主要な要素を1つずつ学んできた。
- 第5回: URL（手紙の宛先）
- 第7回: HTTPメソッド（手紙の用件 — GET・POST・PUT・DELETE）
- 第8回: ステータスコード（返事のスタンプ — 200・404・500 など）
手紙に例えると、宛先（URL）、用件（メソッド）、返事のスタンプ（ステータスコード）は揃った。今回は、封筒そのものに書かれている「付帯情報」を見ていく。これがHTTPヘッダだ。
日常の郵便でも、封筒には本文以外の情報が書かれている。差出人の名前と住所、「速達」の赤線、「取扱注意」のスタンプ、「親展」の印。これらは手紙の中身（本文）とは別に、配達する人や受け取る人に伝える情報だ。
HTTPヘッダも同じだ。リクエスト（ブラウザ→サーバー）にもレスポンス（サーバー→ブラウザ）にも、データの本体とは別に、さまざまな付帯情報が付いている。「このデータはJSON形式です」「このリクエストを送っているのはログイン済みのユーザーです」「レスポンスのデータ量は2,048バイトです」といった情報だ。
今回は、バイブコーディングで特に知っておくと役立つ2つのヘッダ — Content-Type と Authorization — を中心に解説する。
HTTPヘッダとは — 封筒に書かれた付帯情報
図: HTTPヘッダ = 封筒に書かれた付帯情報
HTTPヘッダは「名前: 値」のペアで構成される。たとえば、こんな形だ。
Content-Type: application/json
これは「このデータの形式はJSON（アプリケーション/ジェイソン）です」という意味だ。名前が Content-Type、値が application/json。
リクエスト（ブラウザ→サーバー）に付くヘッダをリクエストヘッダ、レスポンス（サーバー→ブラウザ）に付くヘッダをレスポンスヘッダと呼ぶ。
1回の通信で、ヘッダは1個だけではない。実際には何十個ものヘッダがやりとりされている。DevToolsのNetworkタブでリクエストをクリックし、「Headers」タブを開くと、ずらりとヘッダが並んでいるのが見える。
すべてを理解する必要はない。バイブコーディングで知っておくと便利なのは、ごく一部のヘッダだけだ。
Content-Type — 「この荷物の中身はこれです」
Content-Type は、やりとりするデータの「形式」を示すヘッダだ。
手紙の例で言えば、封筒に「中身: 書類」「中身: 写真」「中身: CD-ROM」と書いてあるようなものだ。受け取る側は、封筒を開ける前に中身の種類が分かるので、適切な処理ができる。
よく見るContent-Typeの値
application/json — JSON形式のデータ。WebアプリのAPIでは、ほとんどのデータがこの形式でやりとりされる。バイブコーディングで最もよく見るContent-Typeだ。
text/html — HTMLのページ。ブラウザでWebページを表示するときに返ってくる。
multipart/form-data — ファイルアップロードに使う形式。画像やPDFをアップロードするとき、この形式でデータが送られる。
application/x-www-form-urlencoded — HTMLのフォームから送信されるデータの形式。名前=値&名前=値 の形で送られる。
text/plain — プレーンテキスト（装飾なしの文字列）。
なぜContent-Typeが重要なのか
サーバーは、受け取ったデータをどう解釈するかをContent-Typeで判断する。
たとえば、POSTリクエストでデータを送るとき。フロントエンドが { "title": "企画書を提出する" } というJSONデータを送るとする。このとき、Content-Type: application/json というヘッダが付いていれば、サーバーは「JSONとして解析しよう」と判断する。
もしContent-Typeが付いていなかったり、間違った値（たとえば text/plain）が設定されていたりすると、サーバーはデータをJSONとして解析できず、400（Bad Request）エラーを返す。
バイブコーディングでの遭遇パターン
Content-Typeが原因のエラーで最も多いのは、「APIにデータを送るとき、Content-Typeが正しく設定されていない」ケースだ。
たとえば、AIにフォーム送信機能を作ってもらったとき、fetch（フェッチ、データを取得・送信するための関数）の設定でContent-Typeが指定されていないことがある。ブラウザのデフォルトでは text/plain が使われることがあり、サーバーがJSONを期待しているのにプレーンテキストとして送ってしまう。
DevToolsのNetworkタブで、リクエストの「Headers」タブを開き、「Request Headers」セクションの Content-Type を確認する。application/json になっていなければ、それがエラーの原因かもしれない。
AIへの伝え方
（症状）フォームから新しいタスクを送信すると400エラーが返る。 （DevToolsの情報）POST /api/tasks が 400 を返している。 （ヘッダの確認）Request HeadersのContent-Typeが text/plain になっている。application/json であるべきかもしれない。
Authorization — 「私はこの人です」
Authorization は、リクエストを送っている人が「誰であるか」をサーバーに伝えるヘッダだ。
第8回で401（認証されていない）と403（権限がない）を学んだ。Authorizationヘッダは、まさにこの認証の仕組みを支えているものだ。
仕組み
手紙の例で言えば、封筒に「会員証のコピー」を貼り付けて送るようなものだ。サーバーは封筒を受け取ったら、まず会員証を確認する。「田中太郎さん、会員番号123、有効期限2026年12月まで。OK、本人確認できました」となって、はじめてリクエストを処理する。
Webの世界では、この「会員証」はトークン（token）と呼ばれる長い文字列だ。ログインが成功すると、サーバーがトークンを発行する。以降のリクエストでは、このトークンがAuthorizationヘッダに自動的に含まれる。
Authorizationヘッダの形式は、通常こうなっている。
Authorization: Bearer eyJhbGciOiJIUzI1NiIs...
「Bearer」は「持参人」という意味で、「このトークンを持っている人です」ということを示す。その後ろの長い文字列がトークン本体だ。
なぜAuthorizationが重要なのか
ログインが必要なアプリでは、ほぼすべてのAPIリクエストにAuthorizationヘッダが付いている。マイページの表示、データの追加・編集・削除 — これらの操作は「誰がやっているか」をサーバーが知る必要があるからだ。
Authorizationヘッダが欠けていると、サーバーは「誰か分からない人からのリクエスト」と判断して401を返す。トークンが期限切れでも同じだ。
バイブコーディングでの遭遇パターン
最も多いのは、「ログイン後のAPIリクエストにAuthorizationヘッダが含まれていない」ケースだ。
ログイン処理は成功している（200が返っている）。トークンもサーバーから発行されている。しかし、その後のAPIリクエスト（タスク一覧の取得など）にトークンが付与されていない。サーバーは「ログインしていない人からのリクエスト」と判断して401を返す。
DevToolsで確認するには、401が返っているリクエストの「Headers」タブを開き、「Request Headers」セクションにAuthorizationヘッダが存在するかを見る。
AIへの伝え方
（症状）ログイン後にタスク一覧を取得しようとすると401が返る。 （DevToolsの情報）GET /api/tasks が 401 を返している。 （ヘッダの確認）Request HeadersにAuthorizationヘッダが含まれていない。ログインAPI（POST /api/auth/login）は200を返してトークンを返却しているように見える。
この情報から、AIは「ログイン後にトークンを保存する処理」か「APIリクエストにトークンを付与する処理」のどちらかに問題があると判断できる。
その他のよく見るヘッダ
Content-TypeとAuthorization以外にも、DevToolsでよく見かけるヘッダをいくつか紹介する。覚える必要はないが、DevToolsで目にしたときに「ああ、これか」と分かる程度に知っておくと便利だ。
リクエストヘッダ（ブラウザ → サーバー）
図: よく見るリクエストヘッダとレスポンスヘッダ
Accept — ブラウザが「こういう形式のデータを受け取れます」とサーバーに伝える。Accept: application/json なら「JSONで返してください」という意味だ。
User-Agent — リクエストを送っているブラウザの種類やバージョン。サーバーが「Chromeからのアクセスか、iPhoneからのアクセスか」を判断するのに使う。バイブコーディングで気にすることは少ない。
Cookie — サーバーから預かった情報を、リクエストのたびに送り返す。ログインセッションの管理に使われることが多い。次回以降のテーマで詳しく扱う。
レスポンスヘッダ（サーバー → ブラウザ）
Content-Length — 返ってきたデータのサイズ（バイト数）。大きなデータが返ってきているかどうかの目安になる。
Set-Cookie — サーバーがブラウザに「この情報を預かっておいてください」と渡す。次のリクエストから、ブラウザがCookieヘッダとしてこの情報を自動的に送り返す。
Cache-Control — データのキャッシュ（一時保存）に関する設定。「このデータは1時間キャッシュしてよい」「キャッシュしないでください」といった指示が書かれている。
Access-Control-Allow-Origin — CORS（コルス、Cross-Origin Resource Sharing）に関する設定。異なるドメイン（例: フロントエンドが localhost:3000、バックエンドが localhost:8080）間の通信を許可するかどうかを制御する。CORSエラーはバイブコーディングでよく遭遇するので、次回以降で詳しく扱う。
DevToolsでヘッダを確認する実践
図: DevToolsでHTTPヘッダを確認する手順
実際にDevToolsでHTTPヘッダを確認してみよう。
ステップ1: DevToolsのNetworkタブを開く
F12キー（Macの場合は Command + Option + I）を押してDevToolsを開き、Networkタブを選ぶ。
ステップ2: リクエストを選ぶ
アプリを操作して（ページを読み込む、ボタンを押す、など）、Networkタブに通信の行が表示されたら、確認したい行をクリックする。
ステップ3: Headersタブを確認する
右側（または下側）に詳細パネルが開く。「Headers」タブが選ばれているはずだ。
General セクション: リクエストのURL、メソッド、ステータスコードなどの基本情報。
Response Headers セクション: サーバーが返したヘッダ。Content-Type や Set-Cookie などが表示される。
Request Headers セクション: ブラウザが送ったヘッダ。Content-Type、Authorization、Cookie などが表示される。
ステップ4: 特定のヘッダを探す
ヘッダの数が多いので、目的のヘッダを探すにはブラウザの検索機能（Command + F または Ctrl + F）を使うのが便利だ。「Content-Type」や「Authorization」で検索すると、すぐに見つかる。
確認すべきポイント
エラーが起きたときに確認すべきヘッダは、主に2つだ。
Request Headers の Content-Type: データを送信するリクエスト（POST、PUT）で、application/json になっているか。
Request Headers の Authorization: ログインが必要なAPIで、Authorization: Bearer ... が含まれているか。
この2つを確認するだけで、かなりのエラーの原因が判明する。
よくある不安と答え
ヘッダの設定は自分でやらないといけないか
バイブコーディングでは、AIがヘッダの設定を含めたコードを書いてくれる。あなたがヘッダを直接書く場面はほとんどない。ヘッダの知識は「エラーが起きたとき、DevToolsでヘッダを確認して、AIに的確に伝える」ために使う。
Authorizationヘッダのトークンは誰かに見られないか
HTTPS（URLがhttps://で始まるサイト）で通信している限り、ヘッダの内容は暗号化されている。途中で第三者に覗き見られることはない。ただし、DevToolsは自分のブラウザ内の情報を表示しているので、自分のトークンは見える。トークンの文字列を他人に教えたり、スクリーンショットに含めたりしないように注意が必要だ。
ヘッダは全部覚えないといけないか
覚える必要はない。この記事で紹介した Content-Type と Authorization の2つを知っていれば十分だ。他のヘッダが気になったときは、DevToolsに表示されているヘッダ名をAIに聞けば、その場で説明してくれる。
Content-Typeを間違えるとどうなるか
多くの場合、400（Bad Request）エラーが返る。サーバーが「送られてきたデータを、指定された形式で解析しようとしたが、形式が合わない」と判断するからだ。DevToolsでRequest HeadersのContent-Typeを確認し、APIが期待する形式（通常はapplication/json）と一致しているかを見る。
まとめ
HTTPヘッダは、リクエストやレスポンスに付く「封筒の付帯情報」だ。データの本文とは別に、データの形式や認証情報といったメタ情報を伝える役割がある。バイブコーディングで特に重要なのは2つ。Content-Type（データの形式 — 通常は application/json）と Authorization（認証トークン — Bearer + トークン文字列）。エラーが起きたとき、DevToolsのHeadersタブでこの2つを確認し、AIに伝えるだけで、デバッグの精度が格段に上がる。
次回は「ステートレスとCookie — なぜログイン状態を覚えておく仕組みが必要なのか」。Webの「毎回記憶を失う」という特性と、それを補うCookie・セッション・JWTの仕組みを解説する。
参考リファレンス
- MDN Web Docs「HTTP ヘッダー」— Mozilla が提供するHTTPヘッダの技術リファレンス
- 前回: 第8回「ステータスコードを深掘りする — 404、500、401、403で何が起きているか」（/articles/vc-008）
- 次回: 第10回「ステートレスとCookie — なぜログイン状態を覚えておく仕組みが必要なのか」（/articles/vc-010）
- バイブコーディング入門 カリキュラム（/vibe-coding）