前回の続き ── ヘッダーの代表選手を4つ
前回のD-06では、返ってきた番号、つまりステータスコードを分類で読めるようにしました。ヘッダーそのものについては、D-03とD-04で「本文以外の付加情報」とだけお伝えしています。今回はその付加情報の代表選手を4つ取り上げ、名前と役割を結びつけていきます。ヘッダーが読めるようになると、通信がらみの不具合の多くを、自分で切り分けられるようになります。
このスライドのポイント
- D-06: 返ってきた番号（ステータスコード）を分類で読めるようにした
- D-03・D-04では「ヘッダー＝本文以外の付加情報」とだけ触れた
- 今回はその付加情報の代表を4つ、名前と役割で結びつける
4つのヘッダーの定義
ヘッダーは「名前、コロン、値」という形式で書かれます。代表的な4つを見ましょう。Content-Typeは、ボディの形式を伝えます。application/jsonなら、中身がJSON形式だという意味です。Authorizationは、本人確認の情報を運ぶヘッダーで、Bearer方式のトークンなどが入ります。Cookieは、ブラウザが保存し、同じ相手へ毎回自動で送る小さなデータで、ログイン状態の維持に使われます。Cache-Controlは、その応答を保存して再利用してよいかを指示します。
このスライドのポイント
- ヘッダーの形式:
名前: 値 - Content-Type ＝ ボディの形式（例: application/json）
- Authorization ＝ 本人確認の情報を運ぶ（例: Bearer方式のトークン）
- Cookie ＝ ブラウザが保存し、同じ相手へ毎回自動で送る小さなデータ（ログイン状態の維持など）
- Cache-Control ＝ 応答を保存・再利用してよいかの指示
なぜ必要か ── 頻出の不具合を切り分ける
ヘッダーを知らないと、頻出する不具合の切り分けができません。JSONを送ったのにサーバーが読めないというときは、Content-Typeの指定漏れが疑われます。ログインしたのに毎回はじかれるというときは、AuthorizationやCookieの不備が疑われます。さらに深刻なのは、AuthorizationやCookieが秘密情報だと知らないまま、通信ログをそのまま共有してしまう事故です。役割を知っていれば、こうした場面で立ち止まることができます。
このスライドのポイント
- 「JSONを送ったのにサーバーが読めない」→ Content-Type未指定を疑う
- 「ログインしたのに毎回はじかれる」→ Authorization・Cookieの不備を疑う
- Authorization・Cookieが秘密情報だと知らずにログを共有する事故を防ぐ
構造 ── 役割と付く場所で整理する
4つのヘッダーを、役割と付く場所で整理します。Content-Typeはボディの形式を表し、リクエストにもレスポンスにも付きます。Authorizationは本人確認の情報で、主にリクエストに付きます。Cookieも本人確認に関わる情報で、主にリクエストに付きます。Cache-Controlは保存の可否を指示し、主にレスポンスに付きます。このうちAuthorizationとCookieは、扱いに注意が要る秘密情報です。
処理の流れ ── 会員ページの取得
会員ページを取得する場面で考えてみましょう。リクエストにAuthorizationやCookieが付いているからこそ、サーバーは「これは誰の依頼か」を判断できます。もしこれらが付いていなかったら、D-06で見た401、つまり本人確認ができていないという応答が返ってきます。つまりヘッダーは、単なる飾りではなく、誰の要求かを成立させる中身なのです。
このスライドのポイント
- リクエストにAuthorization・Cookieが付くから、サーバーは「誰の依頼か」を判断できる
- 付いていなければ、D-06で見た401（本人確認ができていない）が返る
- ヘッダーは飾りではなく、要求を成立させる中身
技術サンプル ── 本人確認と形式のヘッダー
サンプルを見ましょう。種別はhttp、目的は、本人確認と形式指定のヘッダーが実際にどう付くかを確かめることです。まず注意点です。ここに書かれたAuthorizationとCookieの値は、すべてダミー、つまり説明用の偽の値です。本物のトークンやセッションIDは秘密情報ですので、ログや質問文に貼るときは必ず伏せ字にしてください。読み方は3つです。リクエスト側には本人確認のAuthorizationとCookie、レスポンス側には形式を表すContent-Typeと、保存を禁じるCache-Control、no-storeが付いています。no-storeは、この応答を保存するなという指示で、個人情報を含むページでよく使われます。
混同しやすい概念 ── Content-Type と Accept
混同しやすいのが、Content-TypeとAcceptです。Content-Typeは、自分が送るボディの形式を伝えるヘッダーです。いっぽうAcceptは、相手に返してほしい形式を伝えるヘッダーです。どちらも形式についての話ですが、向きが逆になっています。自分が出す形式のことなのか、相手に求める形式のことなのかを意識すると、この2つを取り違えなくなります。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIへ通信ログやエラーを渡す前に、AuthorizationとCookieの値を伏せたかを毎回確かめてください。これは、A-07で身につけた、エラー原文をそのまま貼る習慣とセットで行います。あわせて「トークンをコードに直書きしていませんか」とAIに聞いておくと安心です。伏せる判断に迷ったら、AIに「伏せるべき箇所を指摘して」と頼んでも構いません。
このスライドのポイント
- AIへ通信ログやエラーを渡す前に、Authorization・Cookieの値を伏せたか毎回確認
- A-07の「エラー原文をそのまま貼る」習慣とセットで行う
- あわせて「トークンをコードに直書きしていませんか」とAIに聞く
- 質問例: 「この通信ログのうち、伏せるべき秘密情報はどこですか」
まとめと次回
最後に一問一答です。ボディの形式を伝えるヘッダーは何でしょうか。……答えは、Content-Typeです。30秒まとめです。Content-Typeは形式、AuthorizationとCookieは本人確認、Cache-Controlは保存の可否を伝えます。AuthorizationとCookieは秘密情報なので、共有する前に必ず伏せる。これが今日の要点です。次回のD-08では、通信そのものを守る仕組み、HTTPSへ進みます。関連資料は「環境変数・APIキー管理入門」「AIアプリのセキュリティ超入門」「API連携ワード100」です。
このスライドのポイント
- 一問一答:「ボディの形式を伝えるヘッダーは？」→ Content-Type
- 30秒まとめ: Content-Type＝形式／Authorization・Cookie＝本人確認（秘密情報）／Cache-Control＝保存の可否
- 次回: D-08 通信そのものを守る仕組み、HTTPSへ
- 関連資料: 「環境変数・APIキー管理入門」「AIアプリのセキュリティ超入門」「API連携ワード100」
