GETリクエスト完全ガイド：安全性・冪等性・キャッシュ戦略と実務ポイント
エバープレイ編集部GETリクエストとは：HTTPの「取得」操作を深掘りする
GETリクエストは、HTTPプロトコルにおける最も基本的なリクエストメソッドの一つで、「サーバー上のリソースを取得する」ために使われます。WebブラウザでURLを入力したときやリンクをクリックしたとき、静的ファイルやAPIの読み取り操作は主にGETで行われます。本稿ではGETの仕様的意味、動作、実装上の注意点、セキュリティ・パフォーマンス面での影響などを詳しく解説します。
仕様的な意味 — 安全性・冪等性・キャッシュ可能性
RFC 7231 によれば、GETは「安全（safe）」であると定義されます。つまり、GETを実行してもサーバー側の状態を変更すべきではない、読み取り専用の操作であることが期待されます。また、GETは冪等（idempotent）であり、同じリクエストを何度繰り返しても副作用がないことが前提です。さらにGETは通常キャッシュ可能（cacheable）に設計されており、適切なHTTPヘッダー（Cache-Control、ETag、Last-Modifiedなど）を利用して効率化できます。
リクエストの構造とクエリパラメータ
GETリクエストのスタートラインは「GET /path?query HTTP/1.1」のようになります。データは主にURLのパスやクエリ文字列（?key=value&...）として送られます。クエリはURLの一部であるため、ブラウザ履歴やサーバーのアクセスログ、Refererヘッダに記録され、目に見える形で残ることに注意が必要です。
- クエリ文字列のエンコード：予約文字や非ASCIIはパーセントエンコーディング（%20など）で表現します。現在のブラウザやAPIではUTF-8が標準的に使われます。
- URL長の実務上の制限：RFC自体に明確な長さ制限はありませんが、ブラウザやサーバー（例：Internet Explorerの2083文字制限、Webサーバー設定など）により実用上の上限があります。
ヘッダーと条件付きリクエスト
GETでは多様なリクエストヘッダーが使われます。代表例は Accept（受理するメディアタイプ）、Accept-Encoding、Accept-Language、User-Agent、Referer、Cookie などです。また、条件付きリクエスト（If-Modified-Since、If-None-Match）を用いることで、最小限のデータ転送で「変更がなければ304 Not Modified」を返す仕組みが利用できます。これがキャッシュ効率向上の要です。
部分取得（Range）とHEADメソッド
GETはRangeヘッダーを使って部分的なデータ取得（レスポンス206 Partial Content）を行えます。大きなファイルの分割ダウンロードや動画のシークなどで有効です。また、HEADメソッドはGETと同じヘッダを返しますがボディは返しません。リソースの存在確認やメタデータ取得に使われます。
ブラウザの振る舞い、フォーム、CORS
- HTMLフォームでは method="get" が指定されるとフォームデータはURLのクエリとして送信されます（敏感情報の送信には不向き）。
- CORS（クロスオリジン要求）では単純なGETはプリフライト（OPTIONS）を必要としない場合が多いですが、許可されているヘッダーや資格情報の送信により挙動が変わります。「withCredentials」を使うとCookieが送られ、サーバー側で適切な Access-Control-Allow-Credentials 設定が必要です。
- リダイレクト（301/302など）：ブラウザは通常GETに対するリダイレクトを自動的に追従します。過去における仕様差異（POST→GET変換など）には注意が必要です。
GETのセキュリティ・プライバシー上の注意
GETはURLにデータを含めるため、パスワードやクレジットカード番号などの機密情報をクエリに載せるべきではありません。ログやブラウザ履歴、Refererで露出するリスクがあるためです。また、サーバーがGETで副作用を起こす設計をしているとCSRF（Cross-Site Request Forgery）攻撃の対象になり得ます。設計原則として、状態変更はPOST/PUT/DELETEなどの非安全メソッドで行い、CSRFトークンやSameSite Cookie等の対策を行いましょう（OWASPの推奨事項参照）。
GETにボディを含める？（議論と実務）
技術的にはHTTP仕様上、GETにメッセージボディを付けることは完全に禁止されていませんが、GETのボディに意味を持たせることは広く非推奨です。多くのサーバー、プロキシ、リバースプロキシ、フレームワークがGETボディを扱わないか無視するため、互換性が損なわれます。したがって、追加データが必要ならばクエリ文字列やPOSTを使うのが実務的です。
RESTとGETの役割
RESTアーキテクチャでは、GETはリソースの「取得」操作に割り当てられます。RESTfulなAPI設計では、GET /users/123 のようにリソースを識別するURLに対してGETを実行し、200（OK）や404（Not Found）など適切なステータスコードで応答します。GETの冪等性を利用してキャッシュやCDN配信を容易にできます。
パフォーマンス最適化とキャッシュ戦略
- 静的リソース（画像、CSS、JS）は長めのCache-ControlやETagを設定してCDNを活用すると効率的です。
- APIレスポンスでも条件付きGET（If-None-Match/If-Modified-Since）を導入すると帯域とレイテンシを削減できます。
- キャッシュの無効化が必要な場面では Cache-Control: no-store/no-cache や適切なExpires設定を使います。
実例（短いイメージ）
ブラウザではリンククリックや fetch('https://example.com/api/items') のようにGETがデフォルトで使われます。curlでも curl https://example.com/ でGETが送られます。サーバー側では Accept ヘッダやクエリパラメータに基づいてレスポンスを生成します。
ベストプラクティスまとめ
- GETは読み取り専用に留め、サーバー状態を変更しない。
- 機密データをURLに含めない（クエリに載せない）。
- 長いクエリや多量のデータはPOSTや別の手段を検討する。
- キャッシュヘッダー（Cache-Control、ETag、Last-Modified）を適切に設定してパフォーマンスを改善する。
- GETボディは互換性の問題があるため避ける。
- クロスオリジンや認証の挙動を理解し、必要に応じてCORS設定やSameSite等を設定する。
まとめ
GETはWebのコアをなす基本的なメソッドであり、正しく使えば安全で効率的にリソースを取得できます。しかし、その「読み取り専用」という期待を裏切る実装や、機密情報をクエリに載せる運用はセキュリティ・プライバシー問題を招きます。GETの仕様（RFC）やブラウザ・サーバーの挙動を理解し、キャッシュやCORS、リダイレクトなどの実務的側面を押さえて設計することが重要です。
