HTTP 406 Not Acceptable(エイチティーティーピーヨンジュウロク・ノット・アクセプタブル)とは | 意味や読み方など丁寧でわかりやすい用語解説

HTTP 406 Not Acceptableは、クライアントがサーバーに対して特定の形式のデータを要求したものの、サーバーがその要求された形式のデータを生成または提供できない場合に返されるHTTPステータスコードである。このエラーは、クライアントとサーバー間の「コンテンツ交渉（Content Negotiation）」の失敗を示しており、サーバーが指定された条件に合致する「表現（Representation）」を見つけられなかったことを意味する。例えば、クライアントがJSON形式のデータのみを要求したにもかかわらず、サーバーがそのリソースに対してJSON形式のデータを生成する能力がなく、HTML形式のデータしか提供できない場合にこのエラーが発生する可能性がある。これは、リソースそのものが見つからないことを示す404 Not Foundや、アクセス権限がないことを示す403 Forbiddenとは異なり、リソースは存在するものの、その提供形式に関する問題であることを明確に示している。

HTTPプロトコルにおいて、クライアント（Webブラウザやアプリケーションなど）がサーバーにリソースを要求する際、クライアントは自身が処理できるデータの形式や言語、文字エンコーディングなどの条件をリクエストヘッダを通じてサーバーに伝える。この情報伝達の仕組みが「コンテンツ交渉」の基礎となる。クライアントは、Acceptヘッダ、Accept-Charsetヘッダ、Accept-Encodingヘッダ、Accept-LanguageヘッダといったHTTPヘッダフィールドを用いて、サーバーに対して自身が受け入れ可能なコンテンツの条件を明示的に示すのである。

具体的に、これらのヘッダは以下の役割を果たす。 Accept: クライアントが受け入れ可能なメディアタイプ（MIMEタイプとも呼ばれる）を指定する。例えば、text/html（HTMLドキュメント）、application/json（JSONデータ）、image/jpeg（JPEG画像）などが挙げられる。クライアントは、Accept: text/html, application/xhtml+xml, application/xml;q=0.9, image/webp, */*;q=0.8のように、複数のタイプと優先度（q値）を指定できる。 Accept-Charset: クライアントが理解できる文字エンコーディングを指定する。例えば、utf-8、iso-8859-1などがある。 Accept-Encoding: クライアントが解凍できるコンテンツエンコーディング（主に圧縮方式）を指定する。例えば、gzip、deflateなどが用いられる。 Accept-Language: クライアントが理解できる言語を指定する。例えば、ja（日本語）、en-US（アメリカ英語）などである。

HTTP 406エラーは、サーバーがリクエストされたURIで指定されたリソースに対応する「表現」を生成しようとした際に、クライアントがAcceptヘッダなどで指定したどの条件にも合致する表現を提供できない場合に発生する。サーバーはクライアントの要求を評価し、最も適切と思われる表現を特定しようと試みる。しかし、サーバーが提供できる表現（例えば、あるデータをHTML形式で表示すること、JSON形式で提供することなど）のどれもが、クライアントが提示した条件と一致しない場合、サーバーは406ステータスコードとともに、状況に応じたエラーメッセージを返すことになる。

このエラーが発生する具体的なシナリオはいくつか考えられる。 API利用時のメディアタイプ不一致: RESTful APIなどを利用する際に、クライアントがAccept: application/jsonと指定してJSON形式のデータを強く要求したにもかかわらず、サーバーがそのエンドポイントでJSON形式のデータを生成する機能を持たず、例えばXML形式のデータしか提供できない場合。 Webサイトの言語対応不足: クライアントのWebブラウザがAccept-Language: fr（フランス語）と指定してページを要求したが、サーバーがそのページのフランス語版を提供しておらず、他の言語版（例えば日本語版や英語版）しか提供できない場合。 コンテンツエンコーディングの不一致: クライアントがAccept-Encoding: br（Brotli圧縮）のみを受け入れると指定したが、サーバーがgzip圧縮しか対応していない場合。 サーバー側の設定ミスや機能不足: サーバーが本来提供すべき表現の生成ロジックが実装されていなかったり、設定が誤っていたりする場合も406エラーの原因となる。

システムエンジニアを目指す初心者にとって、このエラーに遭遇した際の対応は重要である。

クライアント側として対応する場合:

1. リクエストヘッダの確認: 自身のアプリケーションやブラウザが送信しているHTTPリクエストのヘッダを詳細に確認する。特にAccept、Accept-Charset、Accept-Encoding、Accept-Languageヘッダにどのような値が設定されているかを確認することが第一歩である。cURLコマンドやPostmanなどのAPIテストツールを使用すると、ヘッダを明示的に指定してテストできるため、原因特定に役立つ。
2. APIドキュメントの参照: 連携しようとしているAPIやサービスのドキュメントを参照し、サーバーがどのようなメディアタイプ、文字エンコーディング、圧縮方式、言語などをサポートしているか、またそれらをどのように要求すべきかを確認する。ドキュメントには、サーバーが期待するAcceptヘッダの値や、どのエンドポイントがどのような形式のデータを返すかが明記されていることが多い。
3. リクエスト内容の修正: サーバーが受け入れ可能な形式に合わせて、自身のアプリケーションが送信するリクエストヘッダの値を修正する。例えば、JSONを要求するならAccept: application/jsonを、HTMLを要求するならAccept: text/htmlを正しく設定する。

サーバー側として対応する場合:

1. リソースの表現の確認: 自身が開発・運用しているサーバーが、リクエストされたリソースに対してどのような「表現」（HTML、JSON、XML、画像など）を生成・提供できるかを改めて確認する。
2. コンテンツ交渉ロジックの検証: サーバーがクライアントのAcceptヘッダなどの情報に基づいて、適切に表現を選択・生成するロジックが正しく機能しているか検証する。複数の表現を提供している場合、クライアントの指定した優先度（q値）が正しく評価されているか確認が必要である。
3. サポート追加の検討: クライアントが要求している形式の表現をサーバーが現在提供できていない場合、その表現を生成する機能を追加する必要があるかを検討する。例えば、APIがJSON形式のみをサポートしていたが、クライアントからXML形式の要求が多い場合、XML形式のレスポンスも生成できるように改修を検討する。

HTTP 406エラーは、リソースが見つからないといった単純な問題ではなく、クライアントとサーバー間の「コミュニケーションの齟齬」を示唆するものである。このエラーを理解し適切に対処することは、WebアプリケーションやAPIを開発・利用する上で非常に重要なスキルとなる。