ペイロードとは｜ヘッダーとの違い・API・JWT・パケットを実物で解説

ペイロード（payload）は、もとは「運賃をもらって運ぶ荷物」という意味の言葉です。通信では、宛先や形式を書いたヘッダーが「荷札」、ペイロードが「荷物の中身」にあたります。

flowchart TD
    A[送りたいデータ<br>JSON・画像など] --> B[ペイロード<br>運ぶ中身]
    C[ヘッダー<br>宛先・形式・長さ] --> D[1つのメッセージ<br>またはパケット]
    B --> D
    D --> E[受け手はヘッダーを読んで<br>ペイロードを取り出す]

急いでいる人向けに、よく調べられることの答えを先にまとめます。

確認環境：Ubuntu 24.04.4 LTS。HTTP の POST は curl 8.5.0 と Python 3.11.15（requests 2.34.2）から、自作の受信サーバー（Python の socket で、届いたヘッダーと本文を分けて表示するもの）に送りました。ブラウザが送る本文は Chromium 141.0.7390.37（Playwright から起動）の fetch で、パケットのデータ部はネットワーク名前空間（ip netns）の中で tcpdump 4.99.4 で取りました。JWT は Python の標準ライブラリで作ってデコードし、PyJWT 2.15.1 で署名を確かめています。受け取った本文の検証は jsonschema 4.26.0 で行いました。本文の大きさの上限は nginx 1.24.0 と Express 5.3.0（body-parser 2.4.0、Node.js 22.22.2）で 413 を起こしました。用語と仕様は RFC 7231・RFC 9110（HTTP）、RFC 9293（TCP）、RFC 7515・RFC 7519（JWS・JWT）、MDN、nginx・Apache・AWS Lambda・GitHub・Chrome DevTools の公式ドキュメントで確かめました（確認日 2026年10月23日）。

ペイロードとは（意味と語源）

この節では、ペイロードという言葉の意味と、なぜ通信のデータをそう呼ぶのかが分かります。

IT のペイロードは、通信で送るまとまりのうち、ヘッダーやトレーラー（末尾の確認用の情報）などの制御情報を除いた、データ本体のことです。 IT 用語辞典（Weblio に収録の「IT用語辞典バイナリ」）も、パケット通信でヘッダーなどの付加的な情報を除いたデータ本体、と説明しています。データの大きさは「ペイロード長」と呼ばれます。

英語の payload は pay（支払う）＋ load（荷物）で、直訳は「有償荷重」です。トラックや飛行機では、乗り物そのものや燃料を除いた「お金をもらって運ぶ荷物・乗客」の重さを指します。通信でも同じ考え方で、届けるために付ける制御情報を除いた「届けたい中身」をペイロードと呼びます。

同じデータでも、どの層から見るかで「ペイロード」の範囲が変わります。 TCP から見れば HTTP のメッセージ全体（ヘッダーも本文も）がペイロードで、HTTP から見れば本文だけがペイロードです。この入れ子は、後の「パケットのペイロード」の節で実物のバイト数を数えて確かめます。

分野別のペイロードの意味（見分け表）

この節では、「ペイロード」が出てきたとき、どの分野の意味なのかを見分けられます。

エンジニアの会話で「ペイロードを見せて」と言われたら、多くは API の本文（JSON）か、パケットのデータ部です。 セキュリティの文脈では、マルウェアが侵入後に実行する処理の本体を「ペイロード」と呼びます。この記事では、その意味は名前を挙げるだけにして、データ通信の意味を扱います。

ロケットの分野では、打ち上げる人工衛星・探査機・実験装置などを「ペイロード」と呼び、「ペイロード重量」は運べる荷物の重さです。トラックや飛行機の「最大積載量」も英語では payload です。

ヘッダーとペイロードの違い（図と用語の整理）

この節では、ヘッダーとペイロードの役割の違いと、「ボディ」「コンテンツ」など似た言葉との関係が分かります。

ボディ・コンテンツ・ペイロードの違い

HTTP の仕様では、ペイロードの呼び方が変わっています。

• 2014年の RFC 7231 は 3.3 節を「Payload Semantics」とし、メッセージで運ぶ表現を「payload」と呼んでいました。状態コード 413 の名前も「Payload Too Large」でした。
• 2022年の RFC 9110 は 6.4 節で同じものを「content」と呼び、ヘッダーの後に送られるバイト列と説明しています。MDN によると、413 の名前も RFC 9110 で「Content Too Large」に変わり、以前の「Payload Too Large」も今も広く使われています。
• 「ボディ（body）」は、HTTP/1.1 のメッセージで、ヘッダーの後に続く部分を指す言葉です。

実務では「ペイロード」「ボディ」「本文」はほぼ同じ意味で使われます。 厳密には、圧縮（Content-Encoding）やチャンク転送をしたときに、回線を流れるボディのバイト列と、元に戻した中身が違うことがあります。後の節で、同じ JSON が gzip で約12分の1になる例を載せています。

HTTPのペイロード：curlで送ってヘッダーと本文を分けて見る

この節では、API に POST したとき、実際にどこまでがヘッダーで、どこからがペイロードなのかを、送ったバイト列で確かめられます。

受け取ったリクエストを分けて表示するサーバー

届いたバイト列を、空行（CRLF CRLF）の前後で「ヘッダー」と「本文」に分けて表示するサーバーです。標準ライブラリだけで動きます。

"""受け取った HTTP リクエストを「ヘッダー」と「本文（ペイロード）」に分けて表示するサーバー"""
import socket, sys

PORT = int(sys.argv[1]) if len(sys.argv) > 1 else 35100

def recv_request(conn):
    data = b""
    while b"\r\n\r\n" not in data:            # 空行（CRLF CRLF）までがヘッダー
        chunk = conn.recv(65536)
        if not chunk:
            return data, b""
        data += chunk
    head, body = data.split(b"\r\n\r\n", 1)
    length = 0
    for line in head.split(b"\r\n")[1:]:
        k, _, v = line.partition(b":")
        if k.strip().lower() == b"content-length":
            length = int(v.strip())
    while len(body) < length:                  # Content-Length の分だけ本文を読む
        body += conn.recv(65536)
    return head, body

with socket.create_server(("127.0.0.1", PORT)) as srv:
    print(f"listening on 127.0.0.1:{PORT}", flush=True)
    while True:
        conn, _ = srv.accept()
        with conn:
            head, body = recv_request(conn)
            print("===== ヘッダー（", len(head) + 4, "バイト）=====", flush=True)
            print(head.decode("latin-1"), flush=True)
            print("===== 本文＝ペイロード（", len(body), "バイト）=====", flush=True)
            print(body.decode("utf-8", "replace") if len(body) < 2000 else body[:200].decode("utf-8", "replace") + " …", flush=True)
            resp_body = ('{"received_bytes": %d}' % len(body)).encode()
            conn.sendall(b"HTTP/1.1 201 Created\r\nContent-Type: application/json\r\n"
                         b"Content-Length: " + str(len(resp_body)).encode() + b"\r\nConnection: close\r\n\r\n" + resp_body)

サーバーは「ヘッダーを空行まで読む → Content-Length の数だけ本文を読む」という順でペイロードを取り出します。 Content-Length が付いた HTTP/1.1 のリクエストは、この順で区切りが決まります。

curl で JSON を POST する

curl -v -X POST http://127.0.0.1:35100/api/users \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer demo-token' \
  -d '{"name":"山田","age":28}'

curl の -v の出力です。> が送ったヘッダー、} の行が送った本文、< が受け取ったヘッダーです。

> POST /api/users HTTP/1.1
> Host: 127.0.0.1:35100
> User-Agent: curl/8.5.0
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer demo-token
> Content-Length: 26
>
} [26 bytes data]
< HTTP/1.1 201 Created
< Content-Type: application/json
< Content-Length: 22
< Connection: close
<
{ [22 bytes data]
{"received_bytes": 26}

サーバー側の表示です。

===== ヘッダー（ 174 バイト）=====
POST /api/users HTTP/1.1
Host: 127.0.0.1:35100
User-Agent: curl/8.5.0
Accept: */*
Content-Type: application/json
Authorization: Bearer demo-token
Content-Length: 26
===== 本文＝ペイロード（ 26 バイト）=====
{"name":"山田","age":28}

ペイロードは {"name":"山田","age":28} の26バイトで、ヘッダーは174バイトでした。 見た目は22文字ですが、「山田」は UTF-8 で1文字3バイトなので26バイトです。Content-Length は文字数ではなくバイト数です。認証のトークン（Authorization）はヘッダー側に入り、ペイロードには入っていません。

curl の --trace-ascii - を使うと、curl 自身が「ヘッダー」と「データ（本文）」を分けて表示します（Authorization を付けずに送った例）。

=> Send header, 140 bytes (0x8c)
0000: POST /api/users HTTP/1.1
...
0076: Content-Length: 26
008a:
=> Send data, 26 bytes (0x1a)
0000: {"name":"......","age":28}
<= Recv header, 22 bytes (0x16)
0000: HTTP/1.1 201 Created
...
<= Recv data, 22 bytes (0x16)
0000: {"received_bytes": 26}

Send data, 26 bytes がリクエストのペイロード、Recv data, 22 bytes がレスポンスのペイロードです。日本語は ASCII でないので ...... と表示されます。curl のオプションは、関連記事「curlコマンドの使い方｜よく使うオプションとAPIの確認方法」で扱っています。

curl のオプションで本文がどう変わるか（実測）

同じサーバーに、オプションを変えて送りました。

-d @ファイル はファイルの改行を取り除いて送るので、ファイルをそのまま送るときは --data-binary @ファイル を使います。 -G を付けると、-d の値は本文ではなく URL のクエリ文字列になり、ペイロードは0バイトでした。GET に本文を付けることもできましたが、MDN は GET の本文の意味は定義されておらず、4xx で拒否するサーバーもある、としています。検索の条件などは、クエリ文字列で送ります。

リクエストのペイロードとレスポンスのペイロード

API の設計書で「リクエストペイロード」「レスポンスペイロード」と書いてあれば、それぞれの本文の JSON の形（項目名・型・必須）のことです。

Pythonでペイロードを送る（json=・data=・files= の違い）

この節では、Python の requests で本文を送る3つの書き方と、それぞれ実際に何バイトのどんな本文になるかが分かります。

"""requests で同じデータを3つの形（JSON・フォーム・multipart）で送る"""
import requests

URL = "http://127.0.0.1:35100/api/users"
data = {"name": "山田", "age": 28}
s = requests.Session(); s.trust_env = False      # プロキシの環境変数を使わない

r = s.post(URL, json=data)                                    # 1) JSON
print("json= :", r.status_code, r.json(), "| 送った本文:", r.request.body)
r = s.post(URL, data=data)                                    # 2) フォーム
print("data= :", r.status_code, r.json(), "| 送った本文:", r.request.body)
r = s.post(URL, data=data, files={"icon": ("a.txt", b"hello\n", "text/plain")})  # 3) multipart
print("files=:", r.status_code, r.json(), "| Content-Type:", r.request.headers["Content-Type"])

json= : 201 {'received_bytes': 35} | 送った本文: b'{"name": "\\u5c71\\u7530", "age": 28}'
data= : 201 {'received_bytes': 30} | 送った本文: name=%E5%B1%B1%E7%94%B0&age=28
files=: 201 {'received_bytes': 350} | Content-Type: multipart/form-data; boundary=1e0fa0db343dae4aadf9eb29216ba938

読み取れることです。

• json= は Content-Type: application/json を自動で付け、日本語を 山田 のように書き換えて送りました。 中身は同じ「山田」ですが、curl で送った26バイトより長い35バイトです。受け取る側の JSON パーサーはどちらも同じ文字に戻します。
• data= に辞書を渡すと、フォームの形（name=%E5%B1%B1%E7%94%B0&age=28）になります。 JSON の API に送ると、サーバーは JSON として読めません。
• files= を付けると multipart/form-data になり、項目ごとに区切り線で分けた350バイトになりました。ファイルのアップロードはこの形です。

Content-Typeごとのペイロードの形（JSON・フォーム・multipart）

この節では、よく使う Content-Type ごとに、ペイロードが実際にどんなバイト列になるかが分かります。

ペイロードの形は、ヘッダーの Content-Type で受け手に伝えます。 受け手は Content-Type を見て、本文を JSON として読むか、フォームとして読むかを決めます。

multipart/form-data のペイロードを、requests で送ったときのまま載せます（行の終わりは CRLF）。

--1e0fa0db343dae4aadf9eb29216ba938
Content-Disposition: form-data; name="name"

山田
--1e0fa0db343dae4aadf9eb29216ba938
Content-Disposition: form-data; name="age"

28
--1e0fa0db343dae4aadf9eb29216ba938
Content-Disposition: form-data; name="icon"; filename="a.txt"
Content-Type: text/plain

hello

--1e0fa0db343dae4aadf9eb29216ba938--

multipart のペイロードの中には、項目ごとに小さなヘッダー（Content-Disposition・Content-Type）と本文があります。 区切り線（boundary）はヘッダーの Content-Type に書かれ、最後の区切り線の後ろに -- が付きます。ペイロードの中に、さらにヘッダーとペイロードがある入れ子の形です。

レスポンスのペイロードを小さくする（gzip の実測）

ユーザー1,000件の JSON を、書き方を変えて gzip で圧縮した大きさです。

indent=2（整形）     104,226 バイト  gzip後  8,704 バイト
既定                82,224 バイト  gzip後  8,589 バイト
区切りの空白なし          74,225 バイト  gzip後  8,106 バイト

整形した JSON（104,226バイト）は、gzip で 8,704 バイトになり、約12分の1でした。 空白を除くと圧縮前は約3割小さくなりますが、gzip 後の差は6.9%です。レスポンスでは、サーバーが Content-Encoding: gzip を付けて圧縮したペイロードを返し、クライアントが元に戻します。このとき Content-Length は圧縮後のバイト数になります。

ブラウザのDevToolsでペイロードを見る（Payloadタブ）

この節では、ブラウザが送ったリクエストのペイロードを、Chrome の DevTools で見る方法と、実際に送られた本文が分かります。

Chrome DevTools のドキュメントでは、Payload タブはリクエストの「クエリ文字列のパラメーターとフォームデータ」を見る場所で、バイナリや圧縮された本文は、タブの下の選択で Base64・Hex・UTF-8 のどれで表示するかを選べる、とされています。

Payload タブに出る中身を、Chromium で fetch を3回実行して取り出しました。

await fetch("/api/json?debug=1", { method: "POST", headers: { "Content-Type": "application/json" },
                                   body: JSON.stringify({ name: "山田", age: 28 }) });
await fetch("/api/form", { method: "POST", body: new FormData(document.getElementById("f")) });
await fetch("/api/urlenc", { method: "POST", body: new URLSearchParams({ name: "山田", age: "28" }) });

Chromium 141.0.7390.37

POST /api/json?debug=1
  Content-Type : application/json
  Content-Length: 26
  本文: '{"name":"山田","age":28}'

POST /api/form
  Content-Type : multipart/form-data; boundary=----WebKitFormBoundaryniBIOoIABsCiInx5
  Content-Length: 233
  本文: '------WebKitFormBoundaryniBIOoIABsCiInx5\r\nContent-Disposition: form-data; name="name"\r\n\r\n山田\r\n------WebKitFormBoundaryniBIOoIABsCiInx5\r\nContent-Disposition: form-data; name="age"\r\n\r\n28\r\n------WebKitFormBoundaryniBIOoIABsCiInx5--\r\n'

POST /api/urlenc
  Content-Type : application/x-www-form-urlencoded;charset=UTF-8
  Content-Length: 30
  本文: 'name=%E5%B1%B1%E7%94%B0&age=28'

fetch の body に FormData を渡すと、ブラウザが multipart/form-data と区切り線（----WebKitFormBoundary…）を自動で付けました。 このとき Content-Type を自分で書くと区切り線が入らず、サーバーが本文を分けられなくなります。URLSearchParams を渡すと、フォームの形（;charset=UTF-8 付き）になりました。/api/json?debug=1 の debug=1 は URL のクエリ文字列なので、Payload タブでは本文とは別の「Query String Parameters」に出ます。

パケットのペイロード（tcpdumpで見るデータ部とMSS）

この節では、ネットワークの「ペイロード」が IP・TCP のヘッダーの後ろのデータ部であることと、1つのパケットに入る大きさを、実際のパケットで確かめられます。

curl の POST を tcpdump で取る

ネットワーク名前空間（ip netns）の中で受信サーバーを動かし、curl の POST を tcpdump -i lo -nn -X で取りました。本文は {"name":"yamada","age":28} の26バイトです。本文を運んだパケットだけを載せます。

IP 127.0.0.1.56158 > 127.0.0.1.35101: Flags [P.], seq 1:167, ack 1, win 64, options [nop,nop,TS val 4258309913 ecr 1500744524], length 166
    0x0000:  4500 00da 5b21 4000 4006 e0fa 7f00 0001  E...[!@.@.......
    0x0010:  7f00 0001 db5e 891d fb64 78a8 6d61 17b6  .....^...dx.ma..
    0x0020:  8018 0040 fece 0000 0101 080a fdd0 a719  ...@............
    0x0030:  5973 8b4c 504f 5354 202f 6170 692f 7573  Ys.LPOST./api/us
    0x0040:  6572 7320 4854 5450 2f31 2e31 0d0a 486f  ers.HTTP/1.1..Ho
    0x0050:  7374 3a20 3132 372e 302e 302e 313a 3335  st:.127.0.0.1:35
    0x0060:  3130 310d 0a55 7365 722d 4167 656e 743a  101..User-Agent:
    0x0070:  2063 7572 6c2f 382e 352e 300d 0a41 6363  .curl/8.5.0..Acc
    0x0080:  6570 743a 202a 2f2a 0d0a 436f 6e74 656e  ept:.*/*..Conten
    0x0090:  742d 5479 7065 3a20 6170 706c 6963 6174  t-Type:.applicat
    0x00a0:  696f 6e2f 6a73 6f6e 0d0a 436f 6e74 656e  ion/json..Conten
    0x00b0:  742d 4c65 6e67 7468 3a20 3236 0d0a 0d0a  t-Length:.26....
    0x00c0:  7b22 6e61 6d65 223a 2279 616d 6164 6122  {"name":"yamada"
    0x00d0:  2c22 6167 6522 3a32 387d                 ,"age":28}

16進数の読み方です。

tcpdump の length 166 は、TCP のペイロード（TCP ヘッダーの後ろ）の長さです。 その166バイトは HTTP のヘッダー140バイトと本文26バイトでできていて、HTTP のペイロードは最後の26バイトだけです。層ごとに「ヘッダー＋ペイロード」が入れ子になる様子を図にすると、次のとおりです。

flowchart TD
    A[IP パケット<br>218 バイト] --> B[IP<br>ヘッダー 20]
    A --> C[IP のペイロード<br>198 = TCP]
    C --> D[TCP<br>ヘッダー 32]
    C --> E[TCP のペイロード<br>166 = HTTP]
    E --> F[HTTP ヘッダー 140<br>本文 26]

層ごとのヘッダーの役割と Ethernet のフレームまで含めた見方は、関連記事「OSI参照モデルとは｜7層の早見表とTCP/IP対応・パケット実例」で、TCP の接続と tcpdump の読み方は、関連記事「ソケットとは｜TCPとUDPの違いをPythonの通信とtcpdumpで解説」で扱っています。

1つのパケットに入るペイロードの大きさ（MTU と MSS）

1つの TCP セグメントに入るペイロードの上限を MSS（Maximum Segment Size）と呼びます。 RFC 9293 は、MSS の値を「経路の MTU から、固定の IP ヘッダーと TCP ヘッダーを引いた値」にする、と定めています。イーサネットの MTU 1500 なら 1500 − 20 − 20 = 1460 バイトです。

名前空間の中の lo の MTU を 1500 にして、4,001 バイトの JSON を POST しました（実際の分割が見えるよう、まとめて送る機能の上限も1つに絞っています）。

Flags [S],  ... options [mss 1460,sackOK,TS val 2008468946 ecr 0,nop,wscale 10], length 0
Flags [S.], ... options [mss 1460,sackOK,TS val 2076933680 ecr 2008468946,nop,wscale 10], length 0
Flags [.],  seq 1:1449, ...    length 1448
Flags [.],  seq 1449:2897, ... length 1448
Flags [P.], seq 2897:4137, ... length 1240

HTTP のヘッダー135バイトと本文4,001バイト（合計4,136バイト）は、3つのパケットに分かれて届きました。 1つのパケットのペイロードが1460ではなく1448なのは、TCP のタイムスタンプのオプション（12バイト）がヘッダーに付いたためです。RFC 9293 でも、オプションの分は送るときにデータを減らす、とされています。受け取る側の TCP が3つをつなげて、アプリには4,136バイトの1つの流れとして渡します。

JWTのペイロード（3つの部分をデコードする）

この節では、JWT（JSON Web Token）の「ペイロード」が何で、どうすれば中身を読めるのか、なぜ秘密の情報を入れてはいけないのかが分かります。

JWT は「ヘッダー.ペイロード.署名」の3つを . でつないだ文字列で、ペイロードはクレーム（ユーザー ID・期限など）を入れた JSON を Base64url で変換したものです。 RFC 7515 は、署名つきの形を BASE64URL(ヘッダー) . BASE64URL(ペイロード) . BASE64URL(署名) と定めています。

標準ライブラリで作ってデコードする

"""JWT を標準ライブラリだけで作り、3つの部分をデコードして中身を見る"""
import base64, hashlib, hmac, json

def b64url(b: bytes) -> str:
    return base64.urlsafe_b64encode(b).rstrip(b"=").decode()

def b64url_decode(s: str) -> bytes:
    return base64.urlsafe_b64decode(s + "=" * (-len(s) % 4))   # 削られた = を戻す

secret = b"demo-secret-key-for-s351-article!"
header = {"alg": "HS256", "typ": "JWT"}
payload = {"sub": "1234567890", "name": "Yamada", "role": "admin", "iat": 1792713600, "exp": 1792717200}

h = b64url(json.dumps(header, separators=(",", ":")).encode())
p = b64url(json.dumps(payload, separators=(",", ":")).encode())
sig = b64url(hmac.new(secret, f"{h}.{p}".encode(), hashlib.sha256).digest())
token = f"{h}.{p}.{sig}"
print("JWT:", token)
print()
for name, part in zip(("ヘッダー", "ペイロード", "署名"), token.split(".")):
    raw = b64url_decode(part)
    print(f"[{name}] {len(part)}文字 → {len(raw)}バイト")
    print("   ", raw.decode() if name != "署名" else raw.hex())

JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IllhbWFkYSIsInJvbGUiOiJhZG1pbiIsImlhdCI6MTc5MjcxMzYwMCwiZXhwIjoxNzkyNzE3MjAwfQ.Q-3tN14RngtiSQUEMI9Nb0FJzpL-48lsHMmYJbozx68

[ヘッダー] 36文字 → 27バイト
    {"alg":"HS256","typ":"JWT"}
[ペイロード] 114文字 → 85バイト
    {"sub":"1234567890","name":"Yamada","role":"admin","iat":1792713600,"exp":1792717200}
[署名] 43文字 → 32バイト
    43eded375e119e0b62490504308f4d6f4149ce92fee3c96c1cc99825ba33c7af

ペイロードは暗号化されておらず、Base64url を戻すだけで誰でも読めます。 Auth0 のドキュメントも、JWS のペイロードは署名で守られていても暗号化はされていない、と説明しています。パスワードや個人情報はペイロードに入れません。iat・exp は1970年からの秒数で、1792713600 は 2026年10月23日 0時（UTC）です。

RFC 7519 が決めている主なクレームです。

コマンドでペイロードをデコードする

JWT の Base64url は、末尾の = を削っているので、base64 -d にそのまま渡すとエラーが出ます。

cut -d. -f2 token.txt | base64 -d

{"sub":"1234567890","name":"Yamada","role":"admin","iat":1792713600,"exp":1792717200}base64: invalid input

中身は表示されましたが、base64: invalid input が出て、終了コードは1でした。- と _ を含む部分は、base64 -d では正しく戻せません。URL 用の形を戻すには GNU coreutils の basenc --base64url -d を使い、足りない = を補います（文字数を4の倍数にする）。Base64 の各言語のコードは、関連記事「Base64エンコード各言語コード一覧｜sha256ハッシュのコマンド早見表」で扱っています。

署名で書き換えを見つける（PyJWT）

"""PyJWT 2.15.1 で署名と期限を確かめる。token.txt は上で作った JWT"""
import base64, json
import jwt

token = open("token.txt").read().strip()
secret = "demo-secret-key-for-s351-article!"
print(jwt.decode(token, options={"verify_signature": False}))          # 読むだけ

# ペイロードの role を "user" に書き換え、ヘッダーと署名はそのままにする
h, p, s = token.split(".")
body = json.loads(base64.urlsafe_b64decode(p + "=" * (-len(p) % 4)))
body["role"] = "user"
p2 = base64.urlsafe_b64encode(json.dumps(body, separators=(",", ":")).encode()).rstrip(b"=").decode()

for label, t, key, opts in (("正しい鍵", token, secret, {"verify_exp": False}),
                            ("書き換えた", f"{h}.{p2}.{s}", secret, {"verify_exp": False}),
                            ("違う鍵", token, "wrong-key-wrong-key-wrong-key-123", {"verify_exp": False}),
                            ("期限も確かめる", token, secret, {})):
    try:
        print(label, "→", jwt.decode(t, key, algorithms=["HS256"], options=opts))
    except jwt.PyJWTError as e:
        print(label, "→", type(e).__name__ + ":", e)

ペイロードは誰でも読めて書き換えることもできますが、署名を確かめれば書き換えは見つかります。 サーバーは、ペイロードの中身を使う前に、必ず署名と期限を確かめます。JWT の仕組みと注意点は、関連記事「JWTとは｜仕組みと、安全に使うための注意点」で扱っています。

Webhookのペイロードと署名

この節では、Webhook で届く「ペイロード」と、その署名をどう確かめるのかが分かります。

Webhook のペイロードは、イベントが起きたときに相手のサービスが POST してくる本文です。 GitHub のドキュメントでは、ペイロードは JSON（application/json）か URL エンコードの形で届き、上限は 25 MB、それを超えるイベントは届かない、とされています。秘密の値を設定すると、本文の HMAC-SHA256 を X-Hub-Signature-256 ヘッダーに付けて送ります。

署名は、本文のバイト列そのものにかかっています。届いた本文を一度 JSON として読み、作り直してから検証すると、次のように合わなくなりました。

import hmac, hashlib, json
secret = b"webhook-secret"
body = b'{"action":"opened","number":42}'          # 届いた本文（バイト列のまま）
sig = "sha256=" + hmac.new(secret, body, hashlib.sha256).hexdigest()
def ok(b): return hmac.compare_digest(sig, "sha256=" + hmac.new(secret, b, hashlib.sha256).hexdigest())
print("届いたバイト列で検証        :", ok(body))
re = json.dumps(json.loads(body)).encode()  # 一度パースして作り直す
print("パースして作り直した本文     :", re)
print("作り直した本文で検証        :", ok(re))

届いたバイト列で検証        : True
パースして作り直した本文     : b'{"action": "opened", "number": 42}'
作り直した本文で検証        : False

JSON として同じ意味でも、空白が1つ違えばバイト列が変わり、署名は合いません。 Webhook の署名は、フレームワークが本文を解析する前の、届いたままのペイロードで検証します。

ペイロードの大きさの上限と413エラー

この節では、ペイロードが大きすぎると何が起きるか、上限がどこで決まるか、どう直すかが分かります。

ペイロードがサーバーの上限を超えると、HTTP の状態コード 413 が返ります。 名前は仕様や製品によって違いますが、意味は同じです。

上限は、途中の機器とアプリのそれぞれにあり、いちばん小さいところで止まります。

flowchart TD
    A[クライアント<br>ブラウザ・curl] --> B[ロードバランサー・CDN]
    B --> C[nginx<br>client_max_body_size 既定 1m]
    C --> D[アプリ Express<br>express.json 既定 100kb]
    D --> E[処理して 201 を返す]

nginx：client_max_body_size（既定 1m）

nginx のドキュメントでは、client_max_body_size の既定は 1m で、超えると 413 を返し、0 にすると大きさを確かめなくなる、とされています。http・server・location のどこにでも書けます。

location /api/ {
    proxy_pass http://127.0.0.1:35100;      # 既定の client_max_body_size（1m）
}
location /upload/ {
    client_max_body_size 10m;              # この場所だけ上限を広げる
    proxy_pass http://127.0.0.1:35100;
}

== /api/ に 1,048,576 バイト（ちょうど 1m）
201 送信 1048576 バイト
== /api/ に 1,048,577 バイト（1バイト超え）
413 送信 0 バイト
== /upload/ に 2,000,000 バイト
{"received_bytes": 2000000} 201

HTTP/1.1 413 Request Entity Too Large
Server: nginx/1.24.0 (Ubuntu)
Content-Type: text/html
Content-Length: 192
Connection: close

error.log には次の行が出ました。

[error] 5579#5579: *3 client intended to send too large body: 1048577 bytes, client: 127.0.0.1, server: , request: "POST /api/x HTTP/1.1", host: "127.0.0.1:35102"

1m はちょうど 1,048,576 バイトまでで、1バイト超えると 413 でした。 このとき curl は Expect: 100-continue を付けて、サーバーの返事を待ってから本文を送ろうとしていました。nginx は Content-Length を見て先に 413 を返したので、本文は0バイトしか送られませんでした。

Express：express.json の limit（既定 100kb）

body-parser の README では、limit の既定は '100kb' で、超えたときのエラーは status が 413、type が 'entity.too.large' とされています。

// Express 5：JSON のペイロードを受け取り、上限を超えたら 413 を JSON で返す
const express = require("express");
const app = express();

app.use("/small", express.json());                    // 既定の limit は 100kb
app.use("/large", express.json({ limit: "1mb" }));    // 上限を広げる

app.post(["/small", "/large"], (req, res) => {
  res.status(201).json({ ok: true, body_type: typeof req.body, bytes: Number(req.get("content-length")) });
});

// ボディの解析で出たエラーをまとめて受ける（413・400）
app.use((err, req, res, next) => {
  console.error(`${err.status} ${err.type}: ${err.message}`);
  res.status(err.status || 500).json({ error: err.type, message: err.message, limit: err.limit, length: err.length });
});

app.listen(35103, "127.0.0.1", () => console.log("listening 35103"));

== 102,400 バイト → /small
{"ok":true,"body_type":"object","bytes":102400} [201]
== 102,401 バイト → /small
{"error":"entity.too.large","message":"request entity too large","limit":102400,"length":102401} [413]
== 102,401 バイト → /large
{"ok":true,"body_type":"object","bytes":102401} [201]
== 壊れた JSON
{"error":"entity.parse.failed","message":"Unexpected token 'y', \"{\"name\": yamada}\" is not valid JSON"} [400]
== Content-Type を付け忘れ
{"ok":true,"body_type":"undefined","bytes":17} [201]

100kb は 102,400 バイトで、1バイト超えると 413 になりました。 エラー処理を書かない場合、Express は HTTP/1.1 413 Payload Too Large と HTML を返し、ログに PayloadTooLargeError: request entity too large を出しました。Content-Type を付け忘れると、エラーにはならず req.body が undefined のまま進みます。 express.json は、Content-Type が application/json のリクエストだけを読むためです。

主な上限の早見表

上の値は 2026年10月23日時点の公式ドキュメントの値です。上限を広げる前に、本当にその大きさを1回で送る必要があるかを考えます。 大きなファイルは、ストレージに直接アップロードして URL だけを API に渡す、分割して送る、gzip で小さくする、といった方法があります。状態コードの一覧は、関連記事「HTTPステータスコード 一覧｜全コードの原因と対処・curl実例つき」で扱っています。

ペイロードのよくあるエラーと直し方

この節では、ペイロードまわりで実際に出たエラー文から、原因と直し方を引けます。

送る前に確かめることです。

• 1Content-Type が本文の形と合っているかJSON なら application/json。合わないと、サーバーは本文を読まずに進むことがある
• 2Content-Length はバイト数か日本語は UTF-8 で1文字3バイト。ライブラリに任せれば自動で正しい値になる
• 3大きさが途中の上限を超えないかnginx 1m・Express 100kb など、いちばん小さい上限で 413 になる
• 4秘密の値をペイロードに入れていないかJWT のペイロードは誰でも読める。認証情報はヘッダーで送り、通信は HTTPS にする
• 5受け取った本文を検証してから使うか型・必須の項目・大きさを確かめ、余分な項目は使わない

受け取ったペイロードを検証する（JSON Schema）

チェックリストの5番目を、JSON Schema（JSON の形を JSON で書く決まり）で行う例です。Python の jsonschema 4.26.0 で、4つの本文を検証しました。

"""受け取ったペイロードを JSON Schema で検証する"""
import json
from jsonschema import Draft202012Validator

schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string", "minLength": 1, "maxLength": 50},
        "age": {"type": "integer", "minimum": 0, "maximum": 150},
        "role": {"enum": ["user", "admin"]},
    },
    "required": ["name", "age"],
    "additionalProperties": False,          # 決めていない項目は受け付けない
}
validator = Draft202012Validator(schema)

for body in (b'{"name":"\xe5\xb1\xb1\xe7\x94\xb0","age":28}',
             b'{"name":"","age":"28"}',
             b'{"name":"Yamada","age":28,"role":"owner","is_admin":true}',
             b'{"age":28}'):
    payload = json.loads(body)
    errors = sorted(validator.iter_errors(payload), key=lambda e: list(e.path))
    print(body.decode(), "→", "OK" if not errors else "")
    for e in errors:
        print("   ", "/".join(map(str, e.path)) or "(全体)", ":", e.message)

{"name":"山田","age":28} → OK
{"name":"","age":"28"} → 
    age : '28' is not of type 'integer'
    name : '' should be non-empty
{"name":"Yamada","age":28,"role":"owner","is_admin":true} → 
    (全体) : Additional properties are not allowed ('is_admin' was unexpected)
    role : 'owner' is not one of ['user', 'admin']
{"age":28} → 
    (全体) : 'name' is a required property

型の違い（文字列の "28"）、空の名前、決めていない項目（is_admin）、必須の項目の抜けを、すべてエラーとして見つけました。 additionalProperties: False を付けないと、is_admin のような余分な項目も通ります。受け取ったペイロードは、大きさ（413）→ 形式（JSON として読めるか）→ 中身（スキーマ）の順に確かめると、どこで止まったかが分かりやすくなります。

ペイロードを見る方法の早見表

よくある質問

Q. ペイロードとは簡単に言うと何ですか？ A. 通信で送るまとまりのうち、宛先や形式などの制御情報（ヘッダー）を除いた「届けたいデータ本体」です。荷物にたとえると、荷札がヘッダー、中身がペイロードです。

Q. API のペイロードとは何ですか？ A. リクエストやレスポンスの本文（ボディ）のことです。多くは JSON で、{"name":"山田","age":28} のような部分を指します。認証のトークンや Content-Type はヘッダー側に入ります。

Q. ペイロードとボディ（body）の違いは？ A. HTTP ではほぼ同じ意味で使われます。仕様の言葉は、RFC 7231 の「payload」から RFC 9110 の「content」に変わりました。圧縮して送るときは、回線上のボディと元の中身のバイト数が違うことがあります。

Q. ヘッダーとペイロードの違いは？ A. ヘッダーは届け方と中身の説明（宛先・形式・長さ・認証）、ペイロードは届けたいデータそのものです。HTTP/1.1 では、ヘッダーの後の空行から後ろがペイロードです。

Q. パケットのペイロードとは？ペイロード長とは？ A. IP や TCP のヘッダーの後ろにあるデータ部です。その大きさがペイロード長で、tcpdump の length 166 のような値です。MTU 1500 の経路では、1つの TCP セグメントのペイロードは最大1460バイト（タイムスタンプ付きなら1448バイト）でした。

Q. JWT のペイロードには何が入っていますか？誰でも読めますか？ A. sub（ユーザー ID）・iat（発行時刻）・exp（期限）などのクレームの JSON です。暗号化されていないので、Base64url を戻せば誰でも読めます。秘密の情報は入れず、使う前に署名と期限を確かめます。

Q. 413 Payload Too Large はどう直しますか？ A. 本文がサーバーの上限を超えています。nginx なら client_max_body_size（既定 1m）、Express なら express.json({ limit })（既定 100kb）を、必要な場所だけ広げます。大きなファイルは分けて送る方法も考えます。

Q. GET リクエストにペイロード（本文）は付けられますか？ A. 送ること自体はでき、curl の -X GET -d で7バイトの本文が届きました。ただし MDN は GET の本文の意味は定義されておらず、拒否するサーバーもあるとしています。検索の条件はクエリ文字列で送ります。

Q. Chrome でリクエストペイロードを見るには？ A. DevTools の Network パネルでリクエストを選び、Payload タブを開きます。送ったままの形は view source、レスポンスの本文は Response タブで見ます。

Q. マルウェアのペイロードとは？ A. セキュリティの用語で、マルウェアが侵入した後に実行する処理の本体を指します。通信のペイロードとは別の意味で使われます。

Q. ロケットのペイロードとは？ A. ロケットが打ち上げる人工衛星・探査機・実験装置などの荷物のことです。「運ぶ中身」という意味は、通信のペイロードと同じです。

Q. ペイロードは英語で何と言いますか？語源は？ A. 英語は payload です。pay（支払う）と load（荷物）からなり、運賃をもらって運ぶ荷物（有償荷重）が元の意味です。

まとめ

• ペイロードは、ヘッダーなどの制御情報を除いた「運びたいデータ本体」。API では本文（ボディ）、ネットワークではパケットのデータ部を指す。
• HTTP/1.1 では空行から後ろがペイロード。curl の JSON は26バイト、requests の json= は日本語を書き換えて35バイトになった。Content-Length はバイト数。
• 形は Content-Type で伝える。JSON・フォーム・multipart で本文の形がまったく違う。FormData の Content-Type はブラウザに任せる。
• 層ごとに「ヘッダー＋ペイロード」が入れ子になる。218バイトのパケットは IP 20＋TCP 32＋HTTP ヘッダー140＋本文26。MTU 1500 では1つのペイロードは最大1460（実測1448）バイト。
• JWT のペイロードは誰でも読める。秘密を入れず、署名と期限を確かめてから使う。
• 本文が上限を超えると 413。nginx は 1m、Express は 100kb が既定で、いちばん小さい上限で止まる。

参考・出典

確認日はいずれも 2026年10月23日です。

• Weblio 辞書「payload」（IT用語辞典バイナリ・デジタル大辞泉ほか）：https://www.weblio.jp/content/payload
• RFC 7231「Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content」3.3 Payload Semantics：https://www.rfc-editor.org/rfc/rfc7231
• RFC 9110「HTTP Semantics」6.4 Content：https://www.rfc-editor.org/rfc/rfc9110
• RFC 9293「Transmission Control Protocol (TCP)」3.7.1 Maximum Segment Size Option：https://www.rfc-editor.org/rfc/rfc9293
• RFC 7515「JSON Web Signature (JWS)」：https://www.rfc-editor.org/rfc/rfc7515
• RFC 7519「JSON Web Token (JWT)」：https://www.rfc-editor.org/rfc/rfc7519
• Auth0 Docs「JSON Web Token の構造」：https://auth0.com/docs/ja-jp/secure/tokens/json-web-tokens/json-web-token-structure
• MDN「413 Content Too Large」：https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/413
• MDN「GET request method」：https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/GET
• Chrome for Developers「Network features reference（View request payload）」：https://developer.chrome.com/docs/devtools/network/reference
• nginx「Module ngx_http_core_module（client_max_body_size）」：https://nginx.org/en/docs/http/ngx_http_core_module.html
• Apache HTTP Server 2.4「core（LimitRequestBody）」：https://httpd.apache.org/docs/2.4/mod/core.html
• expressjs/body-parser「README」：https://github.com/expressjs/body-parser
• AWS Lambda Developer Guide「Lambda quotas」：https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
• GitHub Docs「Webhook events and payloads」：https://docs.github.com/en/webhooks/webhook-events-and-payloads
• python-jsonschema「Schema Validation」：https://python-jsonschema.readthedocs.io/en/stable/validate/

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。