WebブラウザがWebサーバーに情報を要求するとき、その通信の裏側ではHTTPリクエストと呼ばれるメッセージがやり取りされています。
そのHTTPリクエストの中でも特に重要な役割を担うのがリクエストヘッダーです。
リクエストヘッダーはブラウザの種類・受け入れ可能なデータ形式・認証情報・Cookieなど、サーバーが適切なレスポンスを返すために必要な様々な付加情報を含んでいます。
本記事では、リクエストヘッダーの基本概念と仕組みをわかりやすく解説するとともに、主なヘッダーフィールドの種類・HTTP通信の流れ・Web開発やAPIにおける活用方法についても詳しく説明します。
Web開発を学んでいる方やAPIの仕組みを理解したい方はぜひ参考にしてみてください。
リクエストヘッダーとはHTTPリクエストに含まれるメタ情報の集合体（結論）
それではまず、リクエストヘッダーの基本的な意味と役割について解説していきます。
リクエストヘッダー（Request Header）とは、クライアント（ブラウザやAPIクライアントなど）がサーバーにHTTPリクエストを送る際に付加されるメタ情報のセットのことです。
HTTPリクエストは大きく「リクエストライン」「リクエストヘッダー」「リクエストボディ」の3つの部分で構成されます。
リクエストラインにはHTTPメソッド（GET・POST等）とURLが含まれ、リクエストヘッダーにはリクエストに関する付加情報が含まれ、リクエストボディには送信するデータ本体が含まれます。
リクエストヘッダーはいわば「手紙の封筒に書かれた情報」のようなものです。手紙の本文（ボディ）とは別に、差出人・受取人・優先度・取り扱い注意など配達に必要な情報が封筒（ヘッダー）に記載されています。サーバーはこのヘッダー情報を見て、どのような形式でレスポンスを返すべきかを判断します。
リクエストヘッダーは「フィールド名: フィールド値」という形式のキーと値のペアで構成されており、1つのリクエストに複数のヘッダーフィールドが含まれます。
HTTPリクエストの全体構造
リクエストヘッダーを理解するために、まずHTTPリクエスト全体の構造を確認しましょう。
HTTPリクエストの構造例
【リクエストライン】
GET /index.html HTTP/1.1
【リクエストヘッダー】
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Chrome/120.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ja,en-US;q=0.9,en;q=0.8
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: session_id=abc123; user_pref=dark_mode
【空行（ヘッダーとボディの区切り）】
【リクエストボディ（GETの場合は通常なし）】
このようにリクエストヘッダーには複数のフィールドが並び、それぞれがサーバーへの指示や情報提供の役割を担っています。
ヘッダーフィールドの基本的な書式
リクエストヘッダーの各フィールドは以下の書式で記述されます。
フィールド名: フィールド値
例：
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9…
Accept: application/json
フィールド名は大文字・小文字を区別しない（Case-Insensitive）というHTTP仕様があります。
ただし慣習的にHTTP/1.1では先頭大文字のキャメルケース（Content-Type・User-Agentなど）が使われます。
HTTP/2では小文字のみが使われます。
主要なリクエストヘッダーフィールドの種類と役割
続いては、HTTPリクエストでよく使われる主要なヘッダーフィールドの種類と役割について確認していきます。
リクエストヘッダーには多くの種類がありますが、特によく使われるものを理解しておくことがWeb開発・API開発の基礎となります。
Hostヘッダー
Hostヘッダーは送信先のサーバーのホスト名（ドメイン名）とポート番号を指定するフィールドで、HTTP/1.1では必須のヘッダーです。
Host: www.example.com
Host: api.example.com:8080
1台のサーバーが複数のドメインをホスティングしている（バーチャルホスト）場合、HostヘッダーによってどのWebサイトへのリクエストかをサーバーが判別します。
Hostヘッダーがない場合、HTTP/1.1に準拠したサーバーは400 Bad Requestエラーを返します。
User-Agentヘッダー
User-Agentヘッダーはリクエストを送ったクライアント（ブラウザ・アプリ）の識別情報を含むフィールドです。
# ChromeブラウザのUser-Agent例
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36
# スマートフォン（iPhoneSafari）のUser-Agent例
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) AppleWebKit/605.1.15
サーバーはUser-Agentを見てPC向け・スマートフォン向けのコンテンツを出し分けたり、ボットのアクセスを識別したりします。
スクレイピングや自動テストツールではUser-Agentを偽装するケースもありますが、不正利用は利用規約違反になることがあります。
AcceptヘッダーとContent-Typeヘッダー
Acceptヘッダーはクライアントが受け取ることができるコンテンツタイプ（MIMEタイプ）をサーバーに伝えるフィールドです。
# HTMLとXMLを優先しつつ、他も受け入れる
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
# JSONのみ受け入れる（API通信でよく使う）
Accept: application/json
q=0.9などの値は「品質値（Quality Value）」と呼ばれ、優先度を表します（最大1.0）。
Content-TypeはリクエストボディのデータのMIMEタイプを示すフィールドで、POSTリクエストでJSON・フォームデータ・ファイルなどを送る際に使います。
| Content-Typeの値 | 用途 |
|---|---|
| application/json | JSON形式のデータ送信（REST API） |
| application/x-www-form-urlencoded | HTMLフォームのデータ送信 |
| multipart/form-data | ファイルアップロード |
| text/plain | プレーンテキスト |
認証・セキュリティ関連のリクエストヘッダー
続いては、認証やセキュリティに関わる重要なリクエストヘッダーについて確認していきます。
現代のWeb開発・API開発において認証関連のヘッダーの理解は不可欠です。
Authorizationヘッダー
AuthorizationヘッダーはAPIやWebサービスへの認証情報を送るために使われる最も重要なヘッダーの一つです。
# Bearer（JWTなどトークン認証）
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIn0…
# Basic認証（ユーザー名:パスワードをBase64エンコード）
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
# APIキー認証（サービスによって形式が異なる）
Authorization: ApiKey your_api_key_here
Bearer認証はOAuth 2.0・JWTと組み合わせて使われることが多く、REST APIの標準的な認証方式です。
Authorizationヘッダーには機密情報が含まれるため、必ずHTTPS通信で送ることが必須です。
CookieヘッダーとSet-Cookieヘッダー
Cookieヘッダーはブラウザに保存されたCookieをサーバーに送るためのフィールドです。
同じドメインのすべてのCookieが自動的にリクエストヘッダーに含まれます。
Cookie: session_id=xyz789; user_lang=ja; tracking_id=abc123
一方Set-Cookieはレスポンスヘッダー（サーバーからクライアントへ）で使われ、ブラウザにCookieを保存させる指示を出します。
リクエストヘッダーのCookieとレスポンスヘッダーのSet-Cookieは方向が逆であることを混同しないように注意が必要です。
OriginヘッダーとCORSの関係
OriginヘッダーはCORS（Cross-Origin Resource Sharing）において重要な役割を果たします。
クロスオリジン（異なるドメイン間）のリクエストでは、ブラウザが自動的にOriginヘッダーを付加し、リクエスト元のオリジン（プロトコル+ドメイン+ポート）をサーバーに伝えます。
Origin: https://www.example.com
サーバーはOriginヘッダーを見て、そのオリジンからのアクセスを許可するかどうかをレスポンスのAccess-Control-Allow-Originヘッダーで返します。
APIサーバーの開発ではCORSの設定がよく問題になるため、Originヘッダーの仕組みを理解しておくことは非常に重要です。
リクエストヘッダーのWeb開発・API開発での活用
続いては、リクエストヘッダーをWeb開発・API開発でどのように活用するかを確認していきます。
リクエストヘッダーはJavaScript・Python・各種APIクライアントから自由に設定・参照できます。
JavaScriptのfetch APIでのヘッダー設定
// fetch APIでカスタムヘッダーを設定してAPIリクエスト
fetch(‘https://api.example.com/data’, {
method: ‘POST’,
headers: {
’Content-Type’: ‘application/json’,
’Authorization’: ‘Bearer ‘ + token,
’Accept’: ‘application/json’,
’X-Custom-Header’: ‘custom-value’ // カスタムヘッダー
},
body: JSON.stringify({ key: ‘value’ })
})
.then(response => response.json())
.then(data => console.log(data));
headersオブジェクトにキーと値のペアを指定することで、任意のリクエストヘッダーを送信できます。
Pythonのrequestsライブラリでのヘッダー設定
import requests
headers = {
’Content-Type’: ‘application/json’,
’Authorization’: f’Bearer {token}’,
’Accept’: ‘application/json’,
’User-Agent’: ‘MyApp/1.0’
}
response = requests.post(
’https://api.example.com/data’,
headers=headers,
json={‘key’: ‘value’}
)
print(response.json())
requestsライブラリではheadersパラメータに辞書を渡すことでカスタムヘッダーを指定できます。
API開発では特にAuthorization・Content-Type・Acceptの3つのヘッダーを正しく設定することが、APIの正常動作の基本となります。
ブラウザの開発者ツールでリクエストヘッダーを確認する方法
実際のリクエストヘッダーの内容はブラウザの開発者ツールで確認できます。
Chrome開発者ツールでの確認手順
① F12キーまたは右クリック→「検証」で開発者ツールを開く
② 「Network」タブを選択
③ ページをリロード（F5）してリクエストを発生させる
④ 一覧から確認したいリクエストをクリック
⑤「Headers」タブ→「Request Headers」で全ヘッダーを確認できる
開発者ツールでリクエストヘッダーを確認することはAPI開発・デバッグ・セキュリティ検証に非常に役立ちます。
リクエストヘッダーに関連するセキュリティの注意点
続いては、リクエストヘッダーに関連するセキュリティの注意点について確認していきます。
リクエストヘッダーはクライアント側で自由に操作できるため、セキュリティ上の考慮が欠かせません。
リクエストヘッダーは改ざん可能であることを理解する
リクエストヘッダーはクライアント側（ブラウザ・スクリプト・curlなど）から自由に設定・改ざんができます。
そのため、サーバー側でリクエストヘッダーの内容を信頼することは危険です。
User-Agentを見て特定のブラウザだけに機能を制限しても、User-Agentは簡単に偽装できます。
認証・認可はAuthorizationヘッダーのトークン内容をサーバー側で検証することで実装する必要があります。
HTTPSによるヘッダー情報の保護
HTTP通信（暗号化なし）では、リクエストヘッダーは平文で送受信されます。
AuthorizationヘッダーのトークンやCookieのセッションIDが盗聴されると、なりすまし攻撃（セッションハイジャック）に悪用される危険があります。
機密情報を含むリクエストヘッダーは必ずHTTPS通信で暗号化して送信することが絶対的なルールです。
カスタムヘッダーのXプレフィックスについて
独自のカスタムリクエストヘッダーには、かつてX-プレフィックス（例：X-Request-ID・X-API-Key）をつける慣習がありました。
しかしRFC 6648（2012年）によってこの慣習は非推奨となり、現在は標準化を検討しているヘッダーでもXプレフィックスなしで命名することが推奨されています。
ただし既存のシステムではX-プレフィックスのカスタムヘッダーが広く使われているため、実務ではまだ多く見かけます。
まとめ
リクエストヘッダーはHTTPリクエストに付加されるメタ情報のセットで、サーバーが適切なレスポンスを返すために必要な情報を伝える役割を担っています。
Host・User-Agent・Accept・Content-Type・Authorization・Cookieなど様々なフィールドがあり、それぞれ異なる役割を持ちます。
Web開発・API開発ではfetch API・requestsライブラリなどを通じてリクエストヘッダーを自由に設定でき、認証・コンテンツネゴシエーション・CORS制御などに活用されます。
リクエストヘッダーはクライアント側から改ざん可能であることを理解し、機密情報を含む場合は必ずHTTPS通信を使うことがセキュリティの基本です。
ブラウザの開発者ツールを活用してリクエストヘッダーを確認する習慣を持つことで、Web開発のデバッグ力が大きく向上するでしょう。
