GET vs POST:その違いとは? (2026年版)
HTTP GETおよびPOSTメソッドの明確な解説と具体的な活用例
Hyperealで構築を始めよう
Kling、Flux、Sora、Veoなどに単一のAPIでアクセス。無料クレジットで開始、数百万規模まで拡張可能。
クレジットカード不要 • 10万人以上の開発者 • エンタープライズ対応
GET vs POST:違いは何ですか? (2026年版)
GETとPOSTは、最も一般的に使用される2つのHTTPメソッドであり、それぞれの使い分けを理解することは、Web開発やAPI設計の基本です。このガイドでは、コード例、比較表、実務に即したガイダンスを用いて、その違いを分かりやすく解説します。
クイック比較
| 特徴 | GET | POST |
|---|---|---|
| 目的 | データの取得 | データの送信/作成 |
| データの場所 | URLクエリ文字列 | リクエストボディ |
| 可視性 | データがURLに表示される | データはボディに隠される |
| キャッシュ | デフォルトでキャッシュ可能 | デフォルトでキャッシュ不可 |
| ブックマーク | 可能 | 不可 |
| ブラウザ履歴 | パラメータが保存される | パラメータは保存されない |
| データ長 | 制限あり (URL制限 約2,048文字) | 実質的な制限なし |
| べき等性 | あり (同じリクエスト = 同じ結果) | なし (重複作成の可能性あり) |
| 安全性 | あり (データを変更すべきでない) | なし (サーバーの状態を変更する) |
| 戻るボタン | 再実行しても安全 | 再送信の前にブラウザが警告 |
| エンコーディング | application/x-www-form-urlencoded |
複数のタイプをサポート |
GET の仕組み
GETリクエストは、サーバーからデータを取得するために使用されます。パラメータはURLのクエリ文字列として送信されます。
例:ユーザーデータの取得
GET /api/users?page=1&limit=10&sort=name HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer token123
サーバーはリクエストされたデータで応答します:
{
"users": [
{"id": 1, "name": "Alice", "email": "alice@example.com"},
{"id": 2, "name": "Bob", "email": "bob@example.com"}
],
"total": 42,
"page": 1,
"limit": 10
}
コード内での GET
JavaScript (fetch):
// シンプルな GET リクエスト
const response = await fetch('https://api.example.com/users?page=1&limit=10');
const data = await response.json();
// ヘッダー付き
const response = await fetch('https://api.example.com/users?page=1', {
method: 'GET',
headers: {
'Authorization': 'Bearer token123',
'Accept': 'application/json'
}
});
Python (requests):
import requests
# シンプルな GET
response = requests.get('https://api.example.com/users', params={
'page': 1,
'limit': 10,
'sort': 'name'
})
data = response.json()
# params 辞書は次のように変換されます: /users?page=1&limit=10&sort=name
cURL:
curl -X GET "https://api.example.com/users?page=1&limit=10" \
-H "Authorization: Bearer token123" \
-H "Accept: application/json"
GET を使用すべき場面
- アイテム一覧(ユーザー、製品、記事など)の取得
- IDによる単一リソースのロード (
/users/42) - 検索クエリ (
/search?q=python+tutorial) - フィルタリングとページネーション (
/products?category=electronics&page=2) - サーバー上のデータを変更しないあらゆる操作
POST の仕組み
POSTリクエストは、通常、新しいリソースを作成したり情報を送信したりするために、サーバーにデータを送信します。データはURLではなく、リクエストボディで送信されます。
例:ユーザーの作成
POST /api/users HTTP/1.1
Host: api.example.com
Content-Type: application/json
Authorization: Bearer token123
{
"name": "Charlie",
"email": "charlie@example.com",
"role": "developer"
}
サーバーは作成されたリソースを返します:
{
"id": 43,
"name": "Charlie",
"email": "charlie@example.com",
"role": "developer",
"createdAt": "2026-02-06T10:30:00Z"
}
コード内での POST
JavaScript (fetch):
const response = await fetch('https://api.example.com/users', {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'Authorization': 'Bearer token123'
},
body: JSON.stringify({
name: 'Charlie',
email: 'charlie@example.com',
role: 'developer'
})
});
const newUser = await response.json();
Python (requests):
import requests
response = requests.post('https://api.example.com/users', json={
'name': 'Charlie',
'email': 'charlie@example.com',
'role': 'developer'
}, headers={
'Authorization': 'Bearer token123'
})
new_user = response.json()
cURL:
curl -X POST "https://api.example.com/users" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer token123" \
-d '{
"name": "Charlie",
"email": "charlie@example.com",
"role": "developer"
}'
POST を使用すべき場面
- 新しいリソース(ユーザー、注文、コメントなど)の作成
- フォームデータの送信(問い合わせフォーム、ログインフォームなど)
- ファイルのアップロード
- アクションのトリガー(メール送信、決済処理など)
- 機密データ(パスワード、トークンなど)の送信
- サーバー上のデータを変更するあらゆる操作
主な違いの解説
1. データの場所
GET はデータをURLのクエリパラメータとして送信します:
https://api.example.com/search?query=javascript&page=1
POST はデータをリクエストボディで送信します:
POST /search HTTP/1.1
Content-Type: application/json
{"query": "javascript", "page": 1}
これは重要です。なぜなら、URLはログに記録され、キャッシュされ、ブラウザの履歴に保存され、アドレスバーに表示されるからです。機密情報をURLに含めるべきではありません。
2. べき等性 (Idempotency)
GET はべき等です: 同じGETリクエストを10回行っても、同じ結果が得られます。/users/42 の取得は(データ自体が別途変更されない限り)常にユーザー42を返します。
POST はべき等ではありません: 同じPOSTリクエストを10回行うと、10個の重複したリソースが作成される可能性があります。同じデータで /orders にPOSTすると、10件の同一の注文が作成される恐れがあります。
# GET: リトライしても安全
for _ in range(10):
response = requests.get('/api/users/42') # 常にユーザー42を返す
# POST: 対策なしのリトライは危険
for _ in range(10):
response = requests.post('/api/orders', json=order_data) # 10件の注文が作成される!
これが、POSTによって読み込まれたページを更新しようとすると、ブラウザが警告を表示する理由です。
3. キャッシュ
GETレスポンスはデフォルトでキャッシュされます(ブラウザ、CDN、プロキシによる)。これにより繰り返しのリクエストが高速化されますが、データが古くなる(スタール)問題が発生する可能性があります。
POSTレスポンスはデフォルトでキャッシュされません。 各リクエストはサーバーに到達します。
# GET: 2回目のリクエストはキャッシュから返される可能性がある
requests.get('/api/products') # サーバーから取得
requests.get('/api/products') # キャッシュされたレスポンスを返す可能性がある
# キャッシュを防ぐには、キャッシュバスターまたはヘッダーを追加する
requests.get('/api/products', headers={'Cache-Control': 'no-cache'})
4. データサイズの制限
GET は最大URL長の制限を受けます。HTTP仕様では制限を定義していませんが、ブラウザやサーバーは通常制限を設けています:
| ブラウザ/サーバー | URL長さ制限 |
|---|---|
| Chrome | 約 2 MB (実用的制限は約 8,000 文字) |
| Firefox | 約 65,536 文字 |
| Safari | 約 80,000 文字 |
| Internet Explorer (旧式) | 2,083 文字 |
| Apache | 8,190 文字 (デフォルト) |
| Nginx | 8,192 文字 (デフォルト) |
| IIS | 16,384 文字 (デフォルト) |
POST はボディサイズに実質的な制限がありません。数メガバイトのデータ、ファイルのアップロード、大規模な JSON ペイロードなどを送信できます。
5. セキュリティ
GETもPOSTも本質的に「安全」というわけではありません。暗号化には両方とも HTTPS が必要です。ただし、セキュリティ上の重要な違いがいくつかあります。
GET パラメータが露出する場所:
- ブラウザのアドレスバー
- ブラウザの履歴
- サーバーのアクセスログ
- Referrer ヘッダー
- ブラウザのブックマーク
- プロキシサーバーのログ
POST ボディのデータは:
- URLには表示されない
- ブラウザの履歴に保存されない
- Referrer ヘッダーに含まれない
- サーバーログには(サーバーがリクエストボディを記録するように設定されていない限り)表示されない
- ネットワークツールでは(HTTPSを使用していない限り)依然として表示される
# 悪い例: URLにパスワードが含まれている (GET)
GET /login?username=alice&password=secret123
# 良い例: ボディにパスワードが含まれている (POST)
POST /login
Content-Type: application/json
{"username": "alice", "password": "secret123"}
# 実際のセキュリティには、どちらも HTTPS が不可欠です
よくある間違い
間違い 1: データの変更に GET を使用する
# 誤り: GET はデータを変更すべきではない
@app.route('/api/users/42/delete', methods=['GET'])
def delete_user():
db.delete_user(42)
return {'status': 'deleted'}
# 正解: データの変更には DELETE または POST を使用する
@app.route('/api/users/42', methods=['DELETE'])
def delete_user():
db.delete_user(42)
return {'status': 'deleted'}
これが重要な理由:Webクローラー、ブラウザの先読み、プロキシサーバーなどは、自動的にGET URLを巡回することがあります。GETエンドポイントがデータを削除する場合、サイトをクロールしている Google ボットがデータベース全体を削除してしまう可能性があります。
間違い 2: GET 経由で機密データを送信する
# 誤り: URL内の API キー (あらゆるところに記録される)
requests.get('/api/data?api_key=sk-secret-key-12345')
# 正解: ヘッダー内の API キー
requests.get('/api/data', headers={'Authorization': 'Bearer sk-secret-key-12345'})
間違い 3: POST の重複を処理していない
# 誤り: 重複保護がない
@app.route('/api/orders', methods=['POST'])
def create_order():
order = db.create_order(request.json)
return order
# 正解: べき等性キー (Idempotency Keys) を使用する
@app.route('/api/orders', methods=['POST'])
def create_order():
idempotency_key = request.headers.get('Idempotency-Key')
if idempotency_key:
existing = db.get_order_by_idempotency_key(idempotency_key)
if existing:
return existing
order = db.create_order(request.json, idempotency_key=idempotency_key)
return order
GET と POST 以外:その他の HTTP メソッド
GETとPOSTが最も一般的ですが、HTTPは特定の操作のために追加のメソッドを定義しています:
| メソッド | 目的 | べき等性 | 例 |
|---|---|---|---|
| GET | データの読み取り | あり | GET /users/42 |
| POST | データの作成 | なし | POST /users |
| PUT | データの完全な置き換え | あり | PUT /users/42 |
| PATCH | データの一部更新 | なし* | PATCH /users/42 |
| DELETE | データの削除 | あり | DELETE /users/42 |
| HEAD | ヘッダーのみ取得 (ボディなし) | あり | HEAD /users/42 |
| OPTIONS | サポートされているメソッドの取得 | あり | OPTIONS /users |
*PATCHはべき等として実装することも可能ですが、仕様上必須ではありません。
RESTful API 設計パターン
| 操作 | HTTP メソッド | エンドポイント | ボディ |
|---|---|---|---|
| ユーザー一覧 | GET | /api/users |
なし |
| 特定ユーザーの取得 | GET | /api/users/42 |
なし |
| ユーザーの作成 | POST | /api/users |
ユーザーデータ |
| ユーザーの更新 | PUT | /api/users/42 |
ユーザーの全データ |
| 部分更新 | PATCH | /api/users/42 |
変更フィールドのみ |
| ユーザーの削除 | DELETE | /api/users/42 |
なし |
| ユーザーの検索 | GET | /api/users?name=alice |
なし |
よくある質問
GETリクエストでボディを送信できますか? 技術的には可能ですが、強く推奨されません。多くのサーバー、プロキシ、ライブラリはGETリクエストのボディを無視したり削除したりします。中には拒否するものもあります。GETデータにはクエリパラメータを使用してください。
POSTはGETよりも安全ですか? 本質的にはそうではありません。POSTはURLバーやブラウザ履歴からデータを隠しますが、HTTPSがない場合、どちらもネットワーク上ではプレーンテキストで送信されます。セキュリティのために常にHTTPSを使用してください。
ログインフォームには GET または POST のどちらを使うべきですか? 常に POST です。ユーザー名やパスワードをURL、ブラウザ履歴、サーバーのアクセスログに残したくはありません。
POST ではなく PUT を使うべきなのはいつですか? サーバーがリソースのURLを決定する場合(例:自動生成のID)は POST を使用します。クライアントが作成または置換するリソースを正確に指定する場合は PUT を使用します。
GraphQL についてはどうですか? すべてに POST を使用しています。 GraphQLは通常、すべての操作(クエリとミューテーション)にPOSTを使用します。これは、クエリがURLに対して長すぎる可能性があるためです。これはGraphQL APIにおける有効な設計上の選択ですが、一部の実装ではクエリに対するGETもサポートしています。
まとめ
核心となるルールはシンプルです:データの読み取りには GET を使い、データの書き込みには POST を使います。 GETリクエストは決してサーバーの状態を変更すべきではなく、機密データをURLに含めるべきではありません。
それ以上に、GETはキャッシュ可能でべき等(リトライしても安全)であるのに対し、POSTはそのどちらでもないことを覚えておいてください。両方にHTTPSを使用し、重要なPOSTエンドポイントにはべき等性キーを実装し、クリーンなAPI設計のためにRESTfulな慣習に従いましょう。
AI生成メディアを処理するAPIを構築している場合は、Hypereal AI を無料でお試しください。クレジットカードは不要です。その REST API はこれらのHTTP慣習に従っており、画像や動画の生成をアプリケーションに直接統合することが容易です。
