Claude APIのリクエストサイズ上限が、32MBから128MBへ4倍に引き上げられました。Anthropicが公式に発表したもので、対象はMessages APIとToken Counting APIです。画像を大量に含むリクエストや大きなPDFを扱う開発者にとっては、地味ですが効いてくる変更なんですよね。
室谷代表取締役Claude APIのリクエストサイズ上限が32MBから128MBに上がった、という発表です。Anthropicが公式にアナウンスしました。
単純に4倍ですよ、4倍。
単純に4倍ですよ、4倍。
テキトー教師DotAI 認定講師はい、そこがまず押さえるべきポイントですね。対象はMessages APIとToken Counting APIの2つ。
つまり会話リクエスト本体と、送信前にトークン数を数えるAPIの両方で上限が緩和されたということです。
つまり会話リクエスト本体と、送信前にトークン数を数えるAPIの両方で上限が緩和されたということです。
室谷代表取締役これまで32MBで弾かれていたケースがあるわけですよね。Anthropicの説明だと、長いcomputer-useセッションや大きなPDFみたいな画像中心のリクエストが、コンテキストウィンドウをまだ十分残しているのに32MBの壁に当たっていた、と。
テキトー教師DotAI 認定講師そうなんですよ。ここが単に「数字が4倍になった」という話じゃないところで。
トークン数的にはまだ余裕があるのに、データ量の制約で送れない。もったいない状況が起きていたわけです。
トークン数的にはまだ余裕があるのに、データ量の制約で送れない。もったいない状況が起きていたわけです。
室谷代表取締役上限を超えたときに返るのは413のrequest_too_largeエラーです。これは公式ドキュメントのエラー一覧にも記載がある挙動ですね。
テキトー教師DotAI 認定講師ええ。しかも第一者Claude APIの場合、この413はCloudflareがAPIサーバーに届く前に返す、という説明になっています。
エラーの出どころが手前側というのも、切り分けのときに知っておくと役に立ちます。
エラーの出どころが手前側というのも、切り分けのときに知っておくと役に立ちます。
Claude APIのリクエストサイズ上限が32MBから128MBへ、何が変わったのか
リクエストサイズ上限の変更前後
変更前
- 上限は32MB
- Messages API・Token Counting API 共通
- 超過すると413エラー
- 高解像度スクリーンショットを数十枚入れると到達しやすい
変更後
- 上限は128MB(32MBの4倍)
- Messages API・Token Counting API 共通
- コンテキストウィンドウを残したまま32MBで止まる問題を解消
- モデル能力ではなく輸送量がボトルネックだった状態を改善
室谷代表取締役まず変更の全体像を整理したいんですけど、リクエストサイズっていうのは、画像やPDFを含めて一度に送れるデータ量のことですよね。
テキトー教師DotAI 認定講師そのとおりです。これまでMessages APIもToken Counting APIも上限は32MBで、超えると413エラー。
今回それが128MBになった。シンプルに言えばそれだけですが、影響範囲は結構広いです。
今回それが128MBになった。シンプルに言えばそれだけですが、影響範囲は結構広いです。
室谷代表取締役発表の言い回しが面白くて、「コンテキストウィンドウをまだたくさん残しているのに32MBで引っかかっていた」と。つまりモデルの能力以前の、輸送量の問題だったと。
テキトー教師DotAI 認定講師まさにボトルネックの種類が変わった話ですね。モデルが読める量は足りているのに、荷物が大きすぎて玄関で止められていた。
玄関の広さが4倍になった、というイメージです。
玄関の広さが4倍になった、というイメージです。
室谷代表取締役MYUUUでも画像をまとめて読ませる処理を書くことがあるんですけど、32MBって意外とすぐ到達するんですよ。高解像度のスクリーンショットを何十枚も入れると、あっという間ですからね。
テキトー教師DotAI 認定講師講座でも受講生さんから「トークンは余っているのにエラーになる」という相談が出ることがありました。原因がサイズ上限だと気づきにくいんですよね。
413が返っているなら、まずサイズを疑うのが定石です。
413が返っているなら、まずサイズを疑うのが定石です。
室谷代表取締役ちなみに適用開始日やリリース日について、今回の資料では日付が明示されていないんですよね。そこは現時点では明らかにされていません。
テキトー教師DotAI 認定講師はい、そこは正確にしておきたいところです。日付を断定せず、公式ドキュメントの記載ベースで話を進めましょう。
128MB化でできるようになること――大きなPDF・画像中心のcomputer-useセッション
128MB化でできるようになること（32MB→128MB）
PROS ／ メリット
- 長いcomputer-useセッションを途中で途切れさせずに継続できる（スクリーンショットの蓄積でリクエストが肥大化しても413が出にくい）
- 履歴や画像が積み上がるエージェント処理で、途中の413によるセッション途切れを回避しやすい
- 「分割して送る」設計を強いられず、約4倍の余裕で設計の自由度が上がる
- 図表を多く含む大きなPDFをページごとに切って送る手間が減る可能性がある
CONS ／ デメリット
- サイズが4倍になってもトークン数が4倍になるわけではない
- 画像はピクセル数に応じてトークンが消費されるため、コストの考え方は別途確認が必要
室谷代表取締役で、実際に何ができるようになるのか。Anthropicが挙げているのは、長いcomputer-useセッションと大きなPDFです。
テキトー教師DotAI 認定講師computer-useは画面のスクリーンショットを次々にモデルへ渡していくので、セッションが長引くほどリクエストが肥大化します。ここが32MBで詰まっていたのを、128MBまで送れるようにした。
室谷代表取締役エージェント系の処理って、1回1回のリクエストは小さくても、履歴や画像が積み上がっていくんですよね。途中で413が出ると、そこでセッションが途切れてしまう。
テキトー教師DotAI 認定講師そうなると実務的には「分割して送る」設計を強いられていたわけです。それが約4倍の余裕になることで、設計の自由度が上がる。
単に大きなファイルが送れるというより、ワークフローが組みやすくなるのが本質ですね。
単に大きなファイルが送れるというより、ワークフローが組みやすくなるのが本質ですね。
室谷代表取締役大きなPDFも同じです。図表を多く含む資料をまるごと読ませたいとき、ページごとに切って送る手間が減る可能性があります。
テキトー教師DotAI 認定講師ただし、サイズが4倍になったからといって、トークン数が4倍になるわけではない点は注意です。画像はピクセル数に応じてトークンが消費されますから、コストの考え方は別で確認が必要です。
室谷代表取締役画像20枚超のときの1枚あたり上限は2000pxから3000pxに
画像20枚超のときの解像度上限
20枚以下
- 従来どおりの扱い
- 1枚あたり上限2000px
20枚超
- 1枚あたり上限が2000pxから3000pxに緩和
- 細かい文字が読めるようになる
- トークン消費も増えやすい
室谷代表取締役もうひとつ発表に含まれていたのが画像の解像度です。1リクエストに20枚を超える画像を含める場合、1枚あたりの上限が2000pxから3000pxに上がりました。
テキトー教師DotAI 認定講師条件がついていて、「20枚超のとき」というのがポイントです。20枚以下なら従来どおりの扱いで、この緩和は画像をたくさん詰め込むケース向けですね。
室谷代表取締役20枚超えって、まさにcomputer-useのスクリーンショット連投みたいな場面ですよね。1枚あたりの解像度が上がると、画面上の細かい文字が読めるようになる。
テキトー教師DotAI 認定講師逆に言うと、解像度が上がるとトークン消費も増えやすい。3000pxまで使えるからといって全部最大にするのではなく、必要な場面で使うという判断が大事です。
室谷代表取締役ここ、地味に効く人にはすごく効く変更だと思います。小さなUIの文字が潰れて読めない、みたいな問題は解像度に直結しますからね。
テキトー教師DotAI 認定講師講座でも「画像の文字が読めない」という相談は多いんですよ。解像度を上げる以外に、トリミングして渡すという手もあります。
どちらが安く済むかはケースバイケースですね。
どちらが安く済むかはケースバイケースですね。
使えるのは第一者Claude APIのみ――Bedrock・Google Cloudなどクラウド経由の上限比較
室谷代表取締役ここが一番大事かもしれないんですけど、128MBが使えるのは第一者Claude APIだけなんですよね。
テキトー教師DotAI 認定講師はい、ここは誤解されやすいので整理しましょう。クラウド経由はそれぞれ独自の上限を持っていて、今回の引き上げの対象外です。
室谷代表取締役数字を並べるとわかりやすいので、表にしますか。
テキトー教師DotAI 認定講師そうですね。公式ドキュメントの記載はこうです。
| 経路 | Messages / Token Counting の上限 |
|---|---|
| 第一者Claude API | 128 MB |
| Amazon Bedrock | 20 MB |
| Claude Models on Google Cloud（Google管理） | 30 MB |
| Claude Platform on AWS | 32 MB |
| Claude Models on Google Cloud（Anthropic管理） | 32 MB |
| Microsoft Foundry | 32 MB |
室谷代表取締役こう見ると、第一者APIの128MBが突出しているのがわかります。Bedrockは20MBなので、以前の32MBよりさらに小さいわけですよね。
テキトー教師DotAI 認定講師そこなんですよ。発表では「クラウド経由では20〜32MBの間」とまとめられていて、内訳が上の表です。
つまりBedrockを使っている人は、今回の恩恵はゼロどころか、第一者APIとの差がより広がったことになります。
つまりBedrockを使っている人は、今回の恩恵はゼロどころか、第一者APIとの差がより広がったことになります。
室谷代表取締役6.4倍という比較を見かけるとしたら、これは128MBと20MBの比ですね。第一者APIとBedrockの差を表す数字です。
テキトー教師DotAI 認定講師はい。どの経路でClaudeを呼んでいるかを把握していないと、この変更の影響を読み違えます。
Bedrock経由の設定はClaude Code BedrockでAmazon Bedrock接続完全ガイドでも扱っていますが、上限はプラットフォーム側の値に従うという前提は変わりません。
Bedrock経由の設定はClaude Code BedrockでAmazon Bedrock接続完全ガイドでも扱っていますが、上限はプラットフォーム側の値に従うという前提は変わりません。
室谷代表取締役既存のクラウド経由ユーザーは恩恵を受けられない、と。ここは設計時に強く意識すべき点です。
テキトー教師DotAI 認定講師移行を検討するなら、コストやIAM連携とのトレードオフになります。単純に上限だけを見て移す話ではないですね。
Messages APIとToken Counting APIが対象、BatchやFilesとの上限の位置づけ
室谷代表取締役対象APIの整理もしておきたいです。今回128MBになったのはMessagesとToken Countingの2つで、他のAPIは別の上限を持っています。
テキトー教師DotAI 認定講師公式ドキュメントの表を並べるとこうなります。
| エンドポイント | 最大リクエストサイズ |
|---|---|
| Messages、Token Counting | 128 MB |
| Message Batches API | 256 MB |
| Files API | 500 MB |
| Sessions、Agents、Environments | 32 MB |
室谷代表取締役なるほど、Batchは256MB、Filesは500MBと、もともと大きいんですね。今回の引き上げで、対話型のMessages系がBatchに近づいたという位置づけですか。
テキトー教師DotAI 認定講師そう読めますね。大量処理はBatch、ファイルの受け渡しはFiles、そして対話型のMessagesという役割分担の中で、Messages側の余裕が増えたということです。
室谷代表取締役一方でSessions、Agents、Environmentsは32MBのままなんですよね。ここは据え置きだと。
テキトー教師DotAI 認定講師はい、資料上は32MBのままです。エージェント系のAPIを使っている場合は、そちらの上限は変わっていないので注意が必要です。
室谷代表取締役Token Countingが対象に入っているのも実務的にはありがたいですよね。送る前にトークン数を数える処理が、同じサイズのリクエストで動くわけですから。
テキトー教師DotAI 認定講師数える側だけ上限が低いと、本番では送れるのに事前見積もりができない、という妙な状態になりますからね。両方そろって128MBになったのは整合性として重要です。
実務での注意点――料金・トークン数・レイテンシへの影響と確認すべきこと
室谷代表取締役ここからは実務の話です。128MB送れるようになったからといって、料金が変わるわけではないですよね。
テキトー教師DotAI 認定講師はい、リクエストサイズの上限が上がっただけで、料金体系が変わったという発表ではありません。料金はトークン数に基づくので、大きなリクエストを送ればその分トークンも増えます。
室谷代表取締役画像はピクセル数に応じてトークンが消費されるので、3000pxまで上げると1枚あたりのコストも上がり得る、と。ここは誤解しないようにしたいです。
テキトー教師DotAI 認定講師そうです。上限が緩むのは「送れるかどうか」の話で、「安くなる」話ではない。
むしろ送れる量が増える分、コストは増えやすくなります。
むしろ送れる量が増える分、コストは増えやすくなります。
室谷代表取締役レイテンシも同じで、大きなリクエストは処理に時間がかかります。公式ドキュメントでは、10分を超えるような長いリクエストにはストリーミングのMessages APIやMessage Batches APIの利用が推奨されています。
テキトー教師DotAI 認定講師ネットワークがアイドル接続を切ってしまう問題もあるので、TCPのkeep-aliveを設定するという案内もされています。サイズが大きくなると転送時間も伸びるので、この注意はより効いてきますね。
室谷代表取締役あと、SDKが非ストリーミングのリクエストについて10分のタイムアウトを超えないか検証する、という話もありました。大きなリクエストを非ストリーミングで投げるのは、そろそろやめたほうがいい場面が増えそうです。
テキトー教師DotAI 認定講師実装としては、まず413が出ていた箇所を洗い出す。そのうえで、本当に大きなリクエストを1本で送るべきか、分割したほうが安く速いかを比べる。
この順番が現実的です。
この順番が現実的です。
室谷代表取締役分割できるものをわざわざ巨大化させる必要はないですからね。上限が上がったのは選択肢が増えたということで、常に最大で送るのが正解ではないと。
テキトー教師DotAI 認定講師あとはレート制限とコスト上限の確認ですね。1リクエストが大きくなると、トークン毎分の制限に当たりやすくなる可能性もあります。
Consoleでレート制限と使用量を見ておくべきです。
Consoleでレート制限と使用量を見ておくべきです。
室谷代表取締役テキトー教師DotAI 認定講師それと、今回の発表にはUsage and Cost API（ベータ）の話も一部で見かけますが、今回の資料ではその内容までは確認できません。現時点では明らかにされていない、としておくのが正確です。
室谷代表取締役そうですね、そこはソースに無いので触れないでおきます。あくまでリクエストサイズと画像解像度の話として読むのが正解です。
よくある質問
室谷代表取締役最後に、よく聞かれそうな点を整理しておきますか。
テキトー教師DotAI 認定講師そうしましょう。まず「いつから有効か」ですが、資料では適用開始日が明示されていません。
現時点では明らかにされていません、が正確な答えです。
現時点では明らかにされていません、が正確な答えです。
室谷代表取締役「Bedrockでも128MBになるのか」は、ならないです。Bedrockは20MB、Google Cloud（Google管理）は30MB、Claude Platform on AWS・Google Cloud（Anthropic管理）・Microsoft Foundryは32MBです。
テキトー教師DotAI 認定講師「画像は何枚まで、何pxまでか」は、20枚を超えるリクエストの場合に1枚あたり3000pxまで、が今回の緩和です。20枚以下は従来どおりの扱いです。
室谷代表取締役「料金は安くなるのか」は、安くなりません。トークン数に応じた課金は変わらず、大きなリクエストはトークンも増えます。
テキトー教師DotAI 認定講師「413が出たらどうするか」は、まずリクエストサイズを確認し、それでも超えるなら分割かFiles APIの利用を検討する、という流れですね。Files APIは500MBまで使えます。
室谷代表取締役「Batch APIは変わったのか」は、Batchはもともと256MBで、今回の変更対象ではありません。Messages系が128MBになったことで差が縮まった、という位置づけです。
テキトー教師DotAI 認定講師まとめると、今回の変更は画像中心のエージェント用途や大容量PDFを扱う人には実利がある一方、第一者API限定という適用範囲と、トークン・コスト・レイテンシの増加という副作用をセットで理解する必要があります。
室谷代表取締役数字だけ見ると地味ですけど、413で悩んでいた人にはかなり効く変更ですよね。自分の経路がどこか、まず確認してみてください。
