GET vs POST：その違いとは？ (2026年版)

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慣習に従っており、画像や動画の生成をアプリケーションに直接統合することが容易です。

GET vs POST：違いは何ですか？ (2026年版)

クイック比較

特徴	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 /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}

2. べき等性 (Idempotency)

# 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. キャッシュ

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 文字 (デフォルト)

5. セキュリティ

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'}

間違い 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`	なし

Hyperealで構築を始めよう

GET vs POST：違いは何ですか？ (2026年版)

クイック比較

GET の仕組み

例：ユーザーデータの取得

コード内での GET

GET を使用すべき場面

POST の仕組み

例：ユーザーの作成

コード内での POST

POST を使用すべき場面

主な違いの解説

1. データの場所

2. べき等性 (Idempotency)

3. キャッシュ

4. データサイズの制限

5. セキュリティ

よくある間違い

間違い 1: データの変更に GET を使用する

間違い 2: GET 経由で機密データを送信する

間違い 3: POST の重複を処理していない

GET と POST 以外：その他の HTTP メソッド

RESTful API 設計パターン

よくある質問

まとめ

関連記事

HTTP Content-Type ヘッダー：完全ガイド (2026年版)

HTTP DELETE メソッド：完全ガイド (2026年版)

HTTPメソッド詳解：GET, POST, PUT, DELETE およびその他のメソッド (2026年版)

今日から構築を開始

Hyperealで構築を始めよう

GET vs POST：違いは何ですか？ (2026年版)

クイック比較

GET の仕組み

例：ユーザーデータの取得

コード内での GET

GET を使用すべき場面

POST の仕組み

例：ユーザーの作成

コード内での POST

POST を使用すべき場面

主な違いの解説

1. データの場所

2. べき等性 (Idempotency)

3. キャッシュ

4. データサイズの制限

5. セキュリティ

よくある間違い

間違い 1: データの変更に GET を使用する

間違い 2: GET 経由で機密データを送信する

間違い 3: POST の重複を処理していない

GET と POST 以外：その他の HTTP メソッド

RESTful API 設計パターン

よくある質問

まとめ

関連記事

HTTP Content-Type ヘッダー：完全ガイド (2026年版)

HTTP DELETE メソッド：完全ガイド (2026年版)

HTTPメソッド詳解：GET, POST, PUT, DELETE およびその他のメソッド (2026年版)

今日から構築を開始