Claude API の制限が引き上げ：Start、Build、Scale の新しい階層をどう見るか

Mon, 29 Jun 2026 05:04:40 +0800

Anthropic は 2026 年 6 月 26 日に Claude Platform release notes を更新しました。Claude API の rate limits が引き上げられ、Claude Sonnet と Claude Haiku の制限は、各 usage tier で Claude Opus と揃うようになりました。従来の usage tiers も、よりシンプルな Start、Build、Scale の 3 段階に統合されています。

公式説明では、多くの組織はより高い tier に移行し、以前より低い制限になる組織はなく、開発者側の手動操作も不要です。自分の tier と現在の limits は Claude Console で確認できます。

リリースノート：

https://platform.claude.com/docs/en/release-notes/overview

Rate limits ドキュメント：

https://platform.claude.com/docs/en/api/rate-limits

Rate Limits API ドキュメント：

https://platform.claude.com/docs/en/api/rate-limits-api

今回の更新で重要な点

Claude API を日常的なスクリプトや小さなツールで使っているだけなら、変化をすぐには感じないかもしれません。ただし Claude Code、AI Agent、バッチ要約、RAG Q&A、バックエンドキューを動かしているなら、今回の更新は確認する価値があります。

変更点は次の 3 つです。

Claude API 全体の制限が引き上げられた。
Sonnet と Haiku の制限が、各 usage tier で Opus と揃った。
usage tiers が Start、Build、Scale に簡素化された。

実務上は、Opus、Sonnet、Haiku を切り替えるたびにモデル別の制限を細かく確認する負担が減ります。複数モデルを使うアプリ、Agent 製品、社内プラットフォームでは理解しやすくなります。

ただし、無制限に並列数を上げてよいという意味ではありません。Claude API は引き続き、リクエスト数、入力 token、出力 token、トラフィック増加速度によって制限されます。

なぜ開発者に関係があるのか

Claude API を組み込むとき、本当に詰まりやすいのは「モデルが答えられるか」ではなく、本番投入後に突然 429 に遭遇することです。

よくあるケースは次の通りです。

ローカルスクリプトで数百ファイルを一気に Claude に要約させる。
Agent アプリが多数のツール呼び出しと長いコンテキスト要求を同時に実行する。
RAG システムが検索結果、会話履歴、システムプロンプトをまとめて prompt に詰め込む。
バックエンドキューの消費が速すぎて、数分で token 容量を使い切る。
失敗後の自動リトライで混雑がさらに悪化する。

今回の制限引き上げで、一部のワークロードは確かに動かしやすくなります。ただし、アプリがリクエストを増幅する構造なら、rate limit 対策は依然として必要です。上限が広がるのは良いニュースですが、レート制御、キュー、リトライ戦略は省けません。

Start、Build、Scale の考え方

新しい usage tiers は 3 段階です。

Tier	向いている使い方
`Start`	個人開発者、小さなスクリプト、初期プロトタイプ
`Build`	安定した呼び出し量のあるアプリ、チーム内ツール
`Scale`	本番サービス、高並列 Agent、バッチ処理、エンタープライズ連携

具体的な数値を記事からコピーして使うのは避け、Claude Console と公式ドキュメントを正としてください。Anthropic の制限は、アカウント、組織、workspace、モデル、製品ポリシーによって変わります。

現実的に言えば、たまにスクリプトを書く程度なら並列数を上げすぎないことが重要です。実際のプロダクトを作るなら、Claude を通常の関数呼び出しではなく、容量計画が必要な外部サービスとして扱うべきです。

RPM、ITPM、OTPM は引き続き重要

Claude API の rate limits は「1 分あたり何リクエスト」だけではありません。ドキュメントでよく出てくる指標は次の 3 つです。

指標	意味	つまずきやすい場面
`RPM`	requests per minute、1 分あたりのリクエスト数	小さなリクエストが多すぎる、高並列、自動リトライ過多
`ITPM`	input tokens per minute、1 分あたりの入力 token	prompt が長い、コンテキストが大きい、RAG 結果を詰め込みすぎる
`OTPM`	output tokens per minute、1 分あたりの出力 token	`max_tokens` が大きすぎる、長文やコードを大量生成する

429 の多くは、リクエスト回数ではなく token 量で発生します。たとえば 1 分に 10 回しか呼んでいなくても、各リクエストに数十万 token のコンテキストが入っていれば、先に ITPM に当たる可能性があります。逆に prompt が短くても、長いレポートを大量生成させると OTPM に当たることがあります。

そのため、調査時は API 呼び出し回数だけを見ないでください。少なくともモデル名、workspace、入力 token、出力 token、レスポンス状態、リトライ回数を記録するべきです。

Agent とバッチ処理は恩恵を受けやすい

今回の制限引き上げは通常のチャット型リクエストにも効きますが、より大きな恩恵を受けるのは Agent とバッチ処理です。

Agent の 1 回の「ユーザーリクエスト」の裏側には、Claude API 呼び出しが 1 回ではなく一連の処理として並ぶことがあります。

ファイルを読む。
コンテキストを要約する。
ツールを呼び出す。
ツール結果を確認する。
次の手を計画する。
最後に結果を出力する。

複数ユーザーが同時に使ったり、バックエンドでバッチ処理が走っていたりすると、token 使用量はすぐに増えます。制限引き上げ後はこの種の処理に余裕が生まれ、モデル切り替えもしやすくなります。それでも本番環境では、オンラインリクエストは低遅延経路、バッチ処理はキュー、長時間タスクは別の並列制限、という分離をおすすめします。

429 をモデルのせいだけにしない

429 が出たとき、すぐにモデルを変えたり、リトライ回数を最大まで上げたりしないほうがよいです。実用的な確認順序は次の通りです。

エラーメッセージを読み、rate limit、quota、その他制限のどれか確認する。
レスポンスヘッダーの limit、remaining、reset などを確認する。
直近 1 分の RPM、ITPM、OTPM を集計する。
フロントエンド、バックエンド、キュー、SDK が同時にリトライしていないか確認する。
バックエンド処理とユーザーリクエストが同じ組織や workspace を共有していないか確認する。
直近の急な流量増加で acceleration limits に触れていないか確認する。

Anthropic のドキュメントでも、短時間の急激なトラフィック増加が acceleration limits を引き起こす可能性に触れています。平均リクエスト量がそれほど大きく見えなくても、増え方が急なら制限されることがあります。

新機能を公開するときは、段階的に流量を増やすのが安全です。たとえば最初は 5% のユーザーだけに有効化し、429、レイテンシ、token 消費、コスト曲線を見てから全流量を Claude API に流します。

Rate Limits API は監視に組み込める

Anthropic は、組織と workspace の制限設定を確認する Rate Limits API も提供しています。これは内部監視、管理画面、運用スクリプトに向いています。

主な使い道は次の通りです。

デプロイ前に現在の workspace の制限を確認する。
事業部やチームごとに利用可能容量を見せる。
staging では動くのに production で 429 になる理由を説明する。
現在の制限に応じてキューの並列数を調整する。
ユーザーから障害報告が来る前に容量アラートを出す。

ただし、アプリ側のレート制御の代わりにはなりません。業務コードには、キュー、並列上限、指数バックオフ、最大リトライ回数が引き続き必要です。

いま自分のコードで見直すこと

すでに Claude API を使っているなら、まず次を確認するとよいです。

Claude Console で自分の tier が Start、Build、Scale のどれになっているか確認する。
よく使うモデルの現在の rate limits を確認し、古いスクリーンショットや記憶に頼らない。
並列数、1 分あたりのリクエスト数、最大出力 token を設定可能にする。
バッチ処理はキューに載せ、単純な for ループで API を叩き続けない。
429 には指数バックオフを使い、最大リトライ回数を制限する。
入力 token、出力 token、モデル名、workspace、リクエスト時間を記録する。
長いコンテキストを繰り返し使うなら prompt caching を検討する。ただしキャッシュが完全に制限外になるとは考えない。

今回の更新は明確に良い知らせです。Claude API の容量は広がり、usage tier も理解しやすくなりました。開発者にとって本当に必要な行動は「安心して強く叩く」ことではなく、この余裕を使って呼び出し経路、監視、リトライ戦略を整理することです。そうして初めて、引き上げられた制限は安定性につながります。

Development Tools on KnightLiブログ