SS-Infra ← ポータルに戻る

HEADメソッド

1. HEADメソッドの概要と目的

HEADメソッド（HEAD Method）は、HTTPリクエストの方式（メソッド）の一つで、レスポンスの本文を受け取らずに、ヘッダー情報だけを取得するためのものです。

Webサイトの調査や監視を行っていると、「ページが存在するかどうかだけ確認したい」「ファイルのサイズや更新日時だけ知りたい」という場面があります。HEADメソッドを利用すると、実際のコンテンツをダウンロードすることなく、サーバーからの応答内容を確認できます。

この章では、HEADメソッドがどのようなものなのか、また、なぜ知っておく必要があるのかを確認します。

HEADメソッドとは？

HEADメソッドとは、HTTPの仕様（RFC 9110。かつての RFC 7231 などを統合したもの）で定義されているメソッドの一つで、「GETと同じ処理を行うが、レスポンスの本文は返さない」という動作が定められています。

例えば、次のようなリクエストを考えてみます。

GET /download/manual.pdf HTTP/1.1
Host: example.com

この場合、サーバーはヘッダーに続けてPDFファイルの中身そのものを返します。ファイルサイズが大きければ、その分の通信が発生します。

一方、次のようにHEADメソッドを用いると、応答の内容が変わります。

HEAD /download/manual.pdf HTTP/1.1
Host: example.com

これにより、サーバーはステータスコードとヘッダーのみを返し、ファイルの中身は送信しません。ファイルの有無、サイズ、種類、更新日時といった情報は、ヘッダーから把握できます。

このように、本文の転送を伴わずにサーバーの応答内容を確認できる点がHEADメソッドの大きな特徴です。

なお、HEADメソッドは「安全（safe）」なメソッドと定義されており、サーバー上のデータを変更しないことが前提となっています。GETと同様、何度実行しても結果が変わらない冪等（べきとう）なメソッドでもあります。

HEADメソッドはどのような場面で登場するのか？

HEADメソッドは、主にWebサイトの調査や監視、プログラムからの自動処理といった場面で利用されます。

例えば、次のような場面が代表的な利用例です。

Web開発者やインフラ担当者にとって、HEADメソッドはサイトの状態を軽量に把握するための実用的な手段です。

2. HEADメソッドの仕組み・規格・主な特徴

HEADメソッドは、サーバー側ではGETとまったく同じ処理が行われ、応答を返す直前に本文だけが取り除かれる、という動作が基本になります。

そのため、返されるヘッダーの内容は、同じURLにGETでアクセスした場合と一致することが期待されます。

ここでは、GETメソッドとの違いや、実際のリクエスト・レスポンスの例を確認します。

GETメソッドとの違いと特徴

GETメソッドとHEADメソッドには、主に次のような違いがあります。

処理の流れを具体的に追うと、次のようになります。

  1. クライアントが対象のURLに対してHEADリクエストを送信する。
  2. サーバーがGETと同じ処理を行い、返すべきレスポンスヘッダーを組み立てる。
  3. サーバーはステータス行とヘッダーのみを返し、本文は送信しない。
  4. クライアントはヘッダーの内容から、リソースの有無・サイズ・種類・更新日時などを判断する。

このように、本文を受け取らずに必要な情報だけを得られるため、確認や監視の用途に適しています。

リクエストとレスポンスの記述

HEADメソッドのリクエストは、メソッド名を HEAD にする以外、GETと同じ形式で記述します。

例えば、次のようなやり取りになります。

【記述・構造の具体例】

HEADメソッドでリクエストを送り、ヘッダーのみを受け取る例です。

HEAD /download/manual.pdf HTTP/1.1
Host: example.com
User-Agent: curl/8.4.0
Accept: */*

これに対するレスポンスは、次のようになります。

HTTP/1.1 200 OK
Content-Type: application/pdf
Content-Length: 2458112
Last-Modified: Tue, 06 Oct 2026 09:00:00 GMT
ETag: "257c00-63e1f2a0"
Cache-Control: max-age=3600

このレスポンスには本文が続きません。Content-Length にはGETで取得した場合の本文のサイズが示されますが、実際にそのデータが送られてくるわけではない点が特徴です。

なお、仕様上、HEADのレスポンスでは Content-Length が省略される場合もあります。圧縮の有無や動的に生成されるページでは値が付かないこともあるため、この値が常に得られる前提で処理を組まないよう注意してください。

3. HEADメソッドが使われる理由・メリットと活用シーン

HEADメソッドが利用される大きな理由は、確認したい情報の多くがヘッダーに含まれており、本文を受け取らなくても目的を果たせることにあります。

特に、対象が多数ある場合や、定期的に繰り返し実行する処理で効果を発揮します。

HEADメソッドを使うメリット

GETメソッドで確認を行った場合、必要のない本文まで毎回ダウンロードすることになります。

HEADメソッドを適切に使用することで、次のようなメリットが生まれます。

ただし、サーバー側では本文を生成する処理まで行われている場合が多いため、「サーバーの負荷を下げられる手段」ではない点には注意が必要です。

サイト運用やシステム連携で活用する

実際のサイト運用やシステム開発では、以下のような場面で活用されます。

このように、コンテンツそのものではなく「状態」を知りたい場面で広く役立ちます。

HEADメソッドでの確認方法

HEADメソッドによる確認は、コマンドやWeb上のツールから実行できます。

# curlでHEADリクエストを送信する
curl -I https://example.com/

# リダイレクトを追跡しながら確認する
curl -I -L https://example.com/

# ステータスコードだけを取得する
curl -I -o /dev/null -s -w "%{http_code}\n" https://example.com/

curl では -I（または --head）オプションでHEADリクエストを送信できます。

なお、curl -X HEAD のようにメソッドを直接指定すると、本文が返ってくる前提で待機してしまい、応答が完了しないことがあります。HEADリクエストを送る場合は -X ではなく -I を使用してください。

Web上の確認ツールを利用すれば、コマンドを使わずに同様の確認ができます。返却されたヘッダーを一覧で見られるため、リダイレクトの連鎖やキャッシュ設定を把握する際にも有効です。

関連技術・関連用語との違い

HEADメソッドと混同されやすい関連用語として、次のようなものがあります。

HEADが「本文を除いた応答を得るためのメソッド」であるのに対し、OPTIONSは「対応状況を問い合わせるメソッド」です。

目的に応じて使い分けることで、不要な通信を避けながら必要な情報を取得できます。

4. HEADメソッドの導入・運用時の注意点と課題

HEADメソッドは軽量で便利な一方、サーバーやアプリケーションの実装状況によって応答が安定しない場合があります。

仕様どおりに動作しない環境を前提にしていないと、監視やチェック処理が誤った判定をすることがあります。

ここでは、実務上注意すべきポイントを説明します。

よくあるミス・設定ミス

よくある問題の一つが、アプリケーション側でHEADメソッドが考慮されておらず、GETでは正常に表示されるURLに対してエラーが返ってしまうことです。

ルーティングでGETのみを許可している場合や、CDN・WAFがHEADを遮断している場合に、405 Method Not Allowed や 403 Forbidden が返されることがあります。

また、次のようなミスも頻出します。

運用・セキュリティ上の注意点

リンクチェックや監視をHEADメソッドだけで行っていると、ページ自体は正常であるにもかかわらず、エラーとして判定されてしまう場合があります。

【よくある失敗・注意点の例】

同じURLに対して、HEADとGETで異なるステータスコードが返る例です。

HEADリクエストと、その応答

HEAD /article/123 HTTP/1.1
Host: example.com
HTTP/1.1 405 Method Not Allowed
Allow: GET, POST

同じURLへのGETリクエストと、その応答

GET /article/123 HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

この例では、ページは問題なく表示できる状態にもかかわらず、HEADメソッドに対応していないためにエラーが返っています。リンクチェックツールや監視システムがHEADのみで判定していると、正常なページを「リンク切れ」「障害発生」と誤検出する原因になります。

自社サイトであればHEADに正しく応答するよう実装を見直し、外部サイトを対象とする場合はHEADが拒否された際にGETで再確認する仕組みを用意しておくと確実です。なお、405 を返す場合は、仕様上 Allow ヘッダーで対応しているメソッドを示す必要があります。

また、HEADメソッドは本文を受け取らずに応答を確認できるため、攻撃者がURLの存在調査やファイルの探索を行う際にも利用されます。レスポンスヘッダーにサーバーやミドルウェアのバージョン情報が含まれていると、不要な手がかりを与えることになるため、公開する情報は必要最小限に抑えることが望ましいです。

加えて、アクセス制限をメソッド単位で指定する設定にも注意が必要です。許可・拒否の対象を特定のメソッド名で列挙すると、列挙されていないメソッドが制限の対象外となり、意図せず素通りしてしまう場合があります。Apacheであれば <Limit> ではなく <LimitExcept> を使うなど、「指定したメソッド以外をすべて制限する」書き方を選ぶのが安全です。

安全に利用するための対策

HEADメソッドを適切に運用するためには、以下の対策が有効です。

特に、外部サイトを対象としたチェック処理では、HEADに対応していないサーバーが一定数存在することを前提に設計しておくことが重要です。

5. まとめと関連ツールのご案内

ここまで解説したHEADメソッドについて、重要なポイントを振り返ります。

【お役立ちツールのご案内】

ここまで解説したHEADメソッドで取得できるレスポンスヘッダーの内容を、実際に確認したい場合は、当サイトの HTTPヘッダー確認ツール をぜひご活用ください。

URLを入力するだけで、ステータスコードやContent-Type、キャッシュ制御、リダイレクト先といったHTTPヘッダーの情報を確認できます。設定が意図どおりに反映されているかのチェックにお役立てください。