結論から：Claude 公式ドキュメントによると、ファーストパーティの Claude API では Messages と Token Counting のリクエスト上限が 32 MB から 128 MB に引き上げられました。Batch は 256 MB、Files API は 500 MB です。ただしこれは Anthropic 自身の API の話で、Amazon Bedrock は 20 MB、Google 管理の Claude（Vertex）は 30 MB、Claude Platform on AWS・Anthropic 管理の Google Cloud・Microsoft Foundry は 32 MB のままです。サードパーティのゲートウェイにも独自の上限があります。
私たちは自分たちの Key で 10 MB から 130 MB までの Messages リクエストを試しました：
- 約 50 MB まではすべて 200、所要時間は 5〜9 秒；
- 約 54 MB からは 413 が返り、大きなリクエストは 1 秒ほどで拒否されました。
413 が出たらモデルを変える前に、まずリクエストのサイズを測り、画像を縮小し、PDF を分割し、古いスクリーンショットを削ってください。コンテキストウィンドウは大きくなっていません。128 MB に収まっても token に収まるとは限りません。
API Key を作成して Claude Code で Claude を使う →
413 request_too_large の見分け方
公式 API は上限を超えると HTTP 413、エラータイプ request_too_large を返します：
{
"type": "error",
"error": {
"type": "request_too_large",
"message": "Request exceeds the maximum allowed number of bytes."
}
}
公式エラードキュメントによると、ファーストパーティの Claude API では、このエラーはリクエストが API サーバーに届く前に Cloudflare が返します。つまり：
- リクエストはモデルに届いておらず、出力も token の消費もありません；
- 同じリクエストを再送しても通りません。本文を小さくする必要があります；
- 400
invalid_request_error（形式エラー）、429（レート制限）、529（過負荷）とは別の問題です。
サードパーティ経由では 413 の本文が変わります。今回のテストでは 2 種類ありました。ゲートウェイ自身の中国語メッセージ（「リクエストが大きすぎます。内容を減らして再試行してください」）と、上流が 413 を返したことを示す bad response status code 413 です。どちらも「リクエストが大きすぎる」と考えてください。ほかのエラーはClaude Haiku 5.5 API エラーの対処を参照。
まず自分のリクエストを測ります：
import json
body = json.dumps(payload).encode()
print(f"{len(body) / 1024 / 1024:.1f} MB")
プラットフォーム別の上限
| 接続先 | 1 リクエストの上限 |
|---|---|
| Claude API：Messages、Token Counting | 128 MB |
| Claude API：Message Batches | 256 MB |
| Claude API：Files API アップロード | 500 MB |
| Claude API：Sessions、Agents、Environments | 32 MB |
| Claude Platform on AWS | 32 MB |
| Claude on Google Cloud（Anthropic 管理） | 32 MB |
| Microsoft Foundry | 32 MB |
| Claude on Google Cloud（Google 管理、Vertex） | 30 MB |
| Amazon Bedrock | 20 MB |
| 当サイトのゲートウェイ（今回の実測） | 約 50 MB まで通過、約 54 MB から 413 |
数値は公式 API 概要によるもので、各クラウドの値はそれぞれのドキュメントが正としています。AlphaSignal によると、今回の引き上げは画像の多いリクエスト向けです。
サイズと同時に効く制限もあります（Vision ドキュメントとPDF ドキュメントより）：
- 画像 1 枚は最大 8000×8000 px。1 リクエストに 20 枚を超える画像があると、各画像の長辺は 3000 px 以下（AlphaSignal によると以前は 2000 px）。超えると many-image requests に触れた
invalid_request_errorになります； - 画像は 1 リクエスト最大 600 枚、200K コンテキストのモデルは 100 枚；
- PDF は 1 リクエスト最大 600 ページ、コンテキストウィンドウが 1M token 未満なら 100 ページ；
- base64 にするとサイズは約 3 分の 1 増えます。3 MB の PNG は約 4 MB になります。
対策 1：画像を圧縮・縮小する
モデルは画像をそのままの解像度では見ません。ドキュメントによると、Claude 4.7 以降のモデルは長辺 2576 px に、それ以外は 1568 px に縮小します。4K のスクリーンショットを送ってもバイト数が増えるだけです。送信前に縮小しましょう：
from PIL import Image
import base64, io
def shrink(path, max_side=1568, quality=80):
im = Image.open(path).convert("RGB")
im.thumbnail((max_side, max_side))
buf = io.BytesIO()
im.save(buf, "JPEG", quality=quality, optimize=True)
return base64.b64encode(buf.getvalue()).decode()
目安：
- スクリーンショットは JPEG（品質 75〜85）に。PNG よりずっと小さくなります；
- 長辺は 1568 px、細かい文字を読ませたいときだけ 2576 px；
- 20 枚を超えるときは必ず 3000 px 未満；
- 同じ画像は会話で 1 回だけ送り、以降はテキストで参照します。
対策 2：大きな PDF は Files API の file_id で
公式 API では、大きなファイルを Files API（1 ファイル 500 MB）にアップロードし、Messages では file_id を参照します。本文には ID しか入りません：
curl https://api.anthropic.com/v1/files \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: files-api-2025-04-14" \
-F "file=@report.pdf"
# -> {"id": "file_011C...", ...}
{"type": "document", "source": {"type": "file", "file_id": "file_011C..."}}
ドキュメントによると、マルチターンやエージェントでは毎ターン履歴全体を送り直すため、base64 画像も毎回送られます。file_id にすれば画像が増えても本文は小さいままです。
使っているゲートウェイが Files API に対応していない場合（今回当サイトのゲートウェイでアップロードを呼ぶと 400 でした）は、PDF を 100 ページ以内・上限以内に分割して送ります：
qpdf report.pdf --pages . 1-100 -- part1.pdf
qpdf report.pdf --pages . 101-200 -- part2.pdf
PDF の各ページは画像として処理されるので、スキャン PDF は埋め込み画像の解像度を下げるとかなり小さくなります。
対策 3：長い computer use / Claude Code セッションでは古いスクリーンショットを削る
computer use やスクリーンショットの多いエージェントは 413 に最もなりやすい使い方です。各ステップで tool_result にスクリーンショットが入り、毎ターン履歴全体が送られるため、数十ステップで本文は 100 MB を超えます。ドキュメントによると、tool_result 内のスクリーンショットも「20 枚」のしきい値に数えられます。
やり方：
- 直近の数枚だけ残し、古いものは 1 行のテキスト（「ステップ 12：設定画面を開いた」）に置き換える；
- 自作のエージェントループなら N ステップごとに履歴を要約して続ける；
- Claude Code では
/compactを実行するか、長いタスクは新しいセッションで。自動圧縮のタイミングはClaude Code のアイドル時自動圧縮を参照。
Claude Code をサードパーティのエンドポイントにつなぐ場合、グローバル設定は ~/.claude/settings.json に書きます：
{
"env": {
"ANTHROPIC_BASE_URL": "https://api.aicodewith.ai",
"ANTHROPIC_AUTH_TOKEN": "あなたの API Key"
},
"model": "claude-sonnet-5-5"
}
アドレスは https://api.aicodewith.ai で、/v1 は付けません。手順はClaude Code でサードパーティ API を設定する、10 月 21 日の API バージョンと SDK の変更はClaude API 2026-10-21 移行ガイドへ。
実測：当サイトのゲートウェイはどこまで受け付けるか
方法：claude-sonnet-5-5、max_tokens 16。1 つの Messages リクエストに base64 画像を複数入れ（token を抑えるため 16×16 px の画像に埋め草バイトを追加）、10 MB から 130 MB まで増やして https://api.aicodewith.ai/v1/messages に POST しました。
| 本文サイズ | ステータス | 所要時間 |
|---|---|---|
| 4.8 MB | 200 | 約 14 秒 |
| 10.1 MB | 200 | 約 5 秒 |
| 40.3 MB | 200 | 約 6 秒 |
| 50.3 MB | 200 | 約 9 秒 |
| 52.0 MB | 200 | 約 9 秒 |
| 53.7 MB | 413 | 約 6 秒 |
| 60.4 MB | 413 | 約 10 秒 |
| 75.5 MB | 413 | 約 1 秒 |
| 98.8 MB | 413 | 約 4 秒 |
| 129.6 MB | 413 | 約 1 秒 |
結果：今回のテストでは、当サイトのゲートウェイ経由の Messages リクエストは約 52 MB まで 200、約 54 MB から 413 で、公式の 128 MB には届きませんでした。画像付きの普段の会話、数枚のスクリーンショット、数十ページの PDF ならまったく問題になりません。数十 MB を送る必要があるときは、上の 3 つの対策で小さくするほうが確実です。一部のリクエストはアップロード中に接続が切れ、再送で通りました。テスト後、スクリプトとリクエストファイルは削除しました。
API Key を作成して Claude を Claude Code につなぐ →
よくある質問
128 MB になったら、もっと多くの内容を送れますか？
増えたのはバイトの上限で、コンテキストウィンドウは同じです。大きな画像も処理用の解像度に縮小されれば token 数は一定なので、余分なバイトは帯域の無駄です。テキストは 128 MB よりずっと前にコンテキストウィンドウに当たります。
413 と 400「prompt is too long」の違いは？
413 はバイトが多すぎてモデルの手前で止められた状態、prompt is too long は token がコンテキストウィンドウを超えた状態で、リクエストは API に届いています。前者はバイトを減らし、後者は内容を削るか履歴を圧縮します。
Bedrock ではなぜまだ 413 が出るのですか？
Bedrock の上限は 20 MB、Google 管理の Vertex は 30 MB で、128 MB はファーストパーティの Claude API だけです。各プラットフォームの上限に合わせて圧縮してください。
Batch ならもっと大きなリクエストを送れますか？
バッチ全体は 256 MB までですが、中の 1 件 1 件は Messages リクエストです。大量のオフライン処理向けで、1 件あたりのサイズを回避するものではありません。
再送で 413 は直りますか？
直りません。同じ本文は毎回拒否されるので、まず小さくしてください。
