皆さん、こんにちは！ネットワークの奥深さに魅せられ、パケットの挙動を追いかけるのが生きがい、自称「パケット探偵」の私がお届けする技術ブログの時間です。
Webサイトを見る、APIを叩く、クラウド上のサービスを利用する…今や私たちのデジタルライフに欠かせない「インターネット」ですが、その裏側でどんな会話が飛び交っているか、意識したことはありますか？特に、私たちが「こんな情報が欲しいな！」とリクエストしたときに、「どの形式で返してほしいか」まで細かく伝えられる仕組みがあるんです。
今回は、そんなクライアントとサーバーの賢い「おしゃべり」の一つ、HTTPの「Acceptヘッダー」について、初心者の方でも「なるほど！」と膝を打つような形で、とことん優しく紐解いていきたいと思います。小難しい専門用語はなるべく避け、身近な例え話で一歩ずつ理解を深めていきましょう！
—
## あなたはどんな情報が欲しい？「Acceptヘッダー」はクライアントのわがままを伝える手紙なんです
インターネットの世界でWebサイトを見るとき、皆さんのブラウザ（ChromeやSafariなど）は、裏側でサーバーに対して「このページの情報をください！」とお願いしていますよね。このお願いのことを「HTTPリクエスト」と呼びます。
さて、ここでちょっと想像してみてください。
あなたが友達に「本を貸してほしい」とお願いしたとします。その本が「漫画」なのか「小説」なのか「専門書」なのかを伝えないと、友達は「どれを貸せばいいんだ？」と困ってしまいますよね。
これと全く同じことが、インターネットの世界でも起こりえます。
ブラウザがサーバーに「このURLの情報をください！」とだけ伝えたら、サーバーは「HTML形式のWebページとして返せばいいの？それとも、JSON形式のデータとして返せばいいの？それとも画像？」と迷ってしまいます。
そこで登場するのが、今回の主役である`Accept`ヘッダーなんです！
`Accept`ヘッダーは、HTTPリクエストの中に含まれる「追加情報」の一つで、「私はこんな形式のデータなら処理できますよ！」「できれば、この形式で返してくれると嬉しいな！」という、クライアント（ブラウザなど）からの「おもてなしのリクエスト」のようなものなんです。
# 例えるなら「レストランでの注文」
もっと身近な例で考えてみましょう。
あなたがレストランに入ってメニューを見たとき、「この料理をください！」と注文しますよね。その際、「和食がいいな」「イタリアンがいいな」といった好みを伝えることもできます。
`Accept`ヘッダーは、まさにこの「お客様のご希望」を伝える役割を果たします。
ブラウザが「私はHTMLのWebページを表示できますよ！」と伝えれば、サーバーは「なるほど、じゃあHTML形式でページを返してあげよう」と判断できるわけです。
HTTP/0.9やHTTP/1.0といった初期のHTTPプロトコルでは、このような「クライアントの好み」を伝える仕組みはシンプルでした。しかし、Webが進化し、様々な種類のコンテンツ（画像、動画、JSONデータなど）がやり取りされるようになると、「何でもかんでもHTMLで返す」わけにはいかなくなります。そこで、HTTP/1.1の時代になって、この`Accept`ヘッダーがコンテンツネゴシエーション（内容の話し合い）の重要な要素として活躍するようになったんですよ。
## Acceptヘッダー、具体的にどう書くの？
では、実際に`Accept`ヘッダーがどんな風にリクエストに盛り込まれているのかを見てみましょう。
難しそうに見えますが、大丈夫！一つずつ見ていけば、きっと理解できますよ。
# 基本的な書き方：メディアタイプを指定する
`Accept`ヘッダーは、「メディアタイプ（MIMEタイプ）」と呼ばれる形式で、クライアントが処理できるデータの種類をサーバーに伝えます。メディアタイプは、「データの大分類 / データの中分類」という形で書かれます。
例えば、皆さんがWebページを見るブラウザは、主にHTML形式のデータを受け取って表示しますよね。その場合、ブラウザはサーバーにこんな風にリクエストを送っています。
GET /index.html HTTP/1.1
Host: example.com
Accept: text/html
User-Agent: Mozilla/5.0 (…)
ここで注目してほしいのが、`Accept: text/html` の部分です。
これは、「私は`text/html`、つまりHTML形式のテキストデータを受け取って表示できますよ！」とサーバーに伝えているんです。サーバーはこれを見て、「よし、じゃあHTMLファイルを返してあげよう」と判断するわけですね。
他にも、よく使われるメディアタイプにはこんなものがあります。
- `text/plain`: ただのプレーンなテキストデータ
- `application/json`: JSON形式のデータ（APIなどでよく使われます）
- `application/xml`: XML形式のデータ
- `image/jpeg`: JPEG形式の画像データ
- `image/png`: PNG形式の画像データ
- `application/pdf`: PDF形式のドキュメント
# 複数の種類に対応できるよ！と伝えるとき
最近のブラウザは、HTMLだけでなく画像もCSSもJavaScriptも、様々な種類のデータを受け取って表示できますよね。その場合、`Accept`ヘッダーには複数のメディアタイプをカンマ区切りで指定することができます。
例えば、こんな感じです。
GET /some_data HTTP/1.1
Host: api.example.com
Accept: application/json, application/xml, text/plain
User-Agent: MyApiClient/1.0
このリクエストは、「私は`application/json`（JSON）、`application/xml`（XML）、`text/plain`（プレーンテキスト）のどれでも受け取れますよ！」とサーバーに伝えています。サーバーは、これらのうち、自分が持っている最適な形式を選んで返してくれるでしょう。
# 「なんでもいいから何かちょうだい！」を表す「ワイルドカード」
もし、クライアントが「特定の形式にこだわらないけど、とにかく何かデータが欲しい」という場合や、「どんな形式でも受け取れるよ！」と伝えたい場合は、ワイルドカードという特別な記号を使うことができます。
ワイルドカードは“（アスタリスク）で表され、「どんなものでも」という意味になります。
- `type/`: `type`という大分類なら、どんな中分類でもOK
- `/`: どんな大分類、どんな中分類でもOK（つまり、どんなデータ形式でもOK！）
例を見てみましょう。
GET /any_content HTTP/1.1
Host: example.com
Accept: /
これは、「どんな形式のデータでも受け取れますよ！」という、非常に柔軟なリクエストになります。
ブラウザがWebページを取得する際のリクエストでは、HTMLだけでなく画像なども同時に取得するため、この`/`が指定されていることが多いんですよ。
## 「これが一番好きだけど、ダメならこれもアリ！」優先順位を伝える「q値」
ここまでの説明で、「クライアントが受け取れるデータの種類を伝える」という`Accept`ヘッダーの基本的な役割は理解できたと思います。でも、ちょっと考えてみてください。
もしクライアントが「HTMLもJSONもXMLも受け取れるよ！」と伝えたとして、サーバーが「どれを返せばいいんだ？」と迷ってしまったらどうでしょう？
クライアント側にも「できればHTMLがいいな。でもHTMLが無理ならJSONでもいいよ」といった「優先順位」があるはずですよね。
そんなときに使うのが、「q値（quality value）」と呼ばれるものです。
q値は、`Accept`ヘッダーで指定したメディアタイプごとに、どれくらいの優先度で受け取りたいかを数値（0.0〜1.0）で示すことができます。
- `q=1.0`（省略された場合もこれに相当）：最も優先度が高い
- `q=0.5`: 中くらいの優先度
- `q=0.1`: 優先度は低いけど、一応受け取れる
例を見てみましょう。
GET /api/data HTTP/1.1
Host: api.example.com
Accept: application/json;q=1.0, application/xml;q=0.9, text/html;q=0.8, /;q=0.5
この`Accept`ヘッダーは、サーバーにこんなメッセージを伝えています。
- 「一番欲しいのは`application/json`（JSON形式）です！優先度1.0！」
- 「JSONが無理なら、`application/xml`（XML形式）でもOKです。優先度0.9！」
- 「それも無理なら、`text/html`（HTML形式）でも受け取れます。優先度0.8！」
- 「どれもダメだったとしても、とにかく何かあれば受け取れます（`/`）。優先度0.5！」
このようにq値を使うことで、クライアントはサーバーに対して、より細かく自分の好みを伝えることができるんです。サーバー側は、このq値と、自分が提供できるコンテンツの種類を比較して、最も適切な形式を選んでレスポンスを返してくれます。賢いですよね！
# `curl`コマンドで試してみよう！
実際に`Accept`ヘッダーを指定してリクエストを送ってみましょう。`curl`というコマンドラインツールを使うと、簡単にHTTPリクエストを送信できます。
JSON形式を優先してリクエストを送る例
Google Books APIを例にしてみましょう（実際のリクエストURLは適宜調整してください）
curl -v -H “Accept: application/json;q=1.0, text/html;q=0.9” “https://www.googleapis.com/books/v1/volumes?q=harry+potter”
-v オプション: 詳細な情報を表示（リクエストヘッダーやレスポンスヘッダーが見えます）
-H オプション: HTTPヘッダーを手動で追加します。
“Accept: application/json;q=1.0, text/html;q=0.9”: JSONを最優先、次にHTMLを要求しています。
最後のURL: Google Books APIの検索例です。
出力の中で、以下のようなレスポンスヘッダーを探してみてください
Content-Type: application/json; charset=UTF-8
これはサーバーが「JSON形式で返したよ！」と教えてくれています。
もしサーバーがJSONを返せない場合は、他の形式で返してくるか、エラーになることもあります。
この`curl`コマンドを実際に実行してみると、サーバーが`Accept`ヘッダーを見て、ちゃんとJSON形式でデータを返してくれているのが確認できると思います。もし`application/json`を外して`text/html`だけを指定したら、APIによってはエラーになったり、全く違う形式で返ってくるかもしれません。ぜひ試してみてくださいね！
## もしAcceptヘッダーがなかったら？サーバーはどうするの？
`Accept`ヘッダーはHTTP/1.1の仕様で非常に重要な役割を担いますが、実はリクエストに含めることが必須ではありません。
もし`Accept`ヘッダーがリクエストに含まれていなかった場合、サーバーはどうするのでしょうか？
一般的には、サーバーはデフォルトの形式でレスポンスを返します。Webサーバーであれば、多くの場合、HTMLファイルを返そうとします。APIサーバーであれば、JSON形式をデフォルトとしていることが多いでしょう。
しかし、もしサーバーが複数の形式を提供できるのに、クライアントが何も指定しなかった場合、サーバーは「最適な形式を返そう」という努力をすることができません。結果として、クライアントが本当に欲しかった形式とは違うものが返ってきてしまい、正しく処理できない、といった問題が起こる可能性もあります。
だからこそ、クライアント側は`Accept`ヘッダーを適切に指定することで、サーバーに「私はこれが欲しいんです！」と明確に意思表示し、スムーズなデータ交換を促すことが大切なんですね。これは、クライアントとサーバー間の「思いやり」のようなものだと思いませんか？
## まとめ：「おもてなし」の心でつながるインターネット
今回は、HTTPプロトコルにおける「Acceptヘッダー」が、クライアントとサーバー間でどのように「コンテンツネゴシエーション（内容の話し合い）」を助けているのかを、優しく紐解いてみました。
- `Accept`ヘッダーは、クライアントが受け取れるデータの種類や形式をサーバーに伝える「要望書」のようなものです。
- `text/html`や`application/json`といったメディアタイプ（MIMEタイプ）で具体的に形式を指定します。
- `q値`を使うことで、複数の形式に対する優先順位まで細かく伝えられます。
- サーバーは、この`Accept`ヘッダーの情報をもとに、クライアントにとって最適な形式のレスポンスを選んで返してくれます。
普段何気なく使っているWebブラウザの裏側で、こんなにも賢いやり取りが行われているなんて、ちょっと感動しませんか？
「通信」とは、ただデータを送り合うだけではなく、相手の状況を理解し、相手に合わせた最適な情報を提供する「おもてなし」の心が大切なんだな、と改めて感じます。
今回の記事で、HTTPの奥深さに少しでも興味を持っていただけたら嬉しいです。一歩ずつ、ネットワークの知識を深めていきましょう！それでは、また次回の記事でお会いしましょう！
コメント