APIを個人で触り始めた頃、最初の関門は性能でも料金でもなくレート制限だった、という人は多いはず。少し込み入ったものを作ろうとすると、すぐ429が返ってくる。今回Anthropicが出した変更は、その入口の壁を下げる話だ。全ユーザーのClaude Platform APIのレート制限を引き上げ、ティアの区分を簡素化し、そしてティアの決まり方から「API支出」という条件を外した。地味だけど、開発者にとっては実利のある更新だと思う。
- 「課金額でティアが上がる」時代が終わった
- 小さく作る人ほど、この変更は効く
- キャッシュを効かせると、制限は実質もっと高い
- モデルごとに別勘定、Sonnet 5と4.xは別の財布
- 429が返ってきたら、増枠を叫ぶ前にやること
- 本番にスケールさせる前に、コスト側で決めておくこと
- 自分ならまず何を確認するか
「課金額でティアが上がる」時代が終わった
まず何が変わったか。これまでのAPIティアは、累積の課金額で階段を上がっていく方式だった。使えば使うほど、正確には払えば払うほど上のティアに行けて、レート制限も緩くなる。個人開発者からすると「まず課金実績を積まないと枠が広がらない」という、鶏と卵みたいな構造だった。
新しいティアは Start / Build / Scale / Custom の4段。名前が用途ベースになって、そして昇格の条件が支出ベースではなくなった。公式ドキュメントの表現でも、組織は自動でティアに置かれ、APIを使っていくなかで上のティアに移る、という書き方に変わっている。「いくら払ったか」ではなく「どう使っているか」で枠が決まる方向に寄せてきた。
主要モデル（Opus 4.x、Sonnet 5、Sonnet 4.x、Haiku 4.5）のレート制限を、ティア別に並べるとこうなる。
| ティア | 月間支出上限 | RPM（毎分リクエスト） | ITPM（毎分入力トークン） | OTPM（毎分出力トークン） |
|---|---|---|---|---|
| Start | $500 | 1,000 | 2,000,000 | 400,000 |
| Build | $1,000 | 5,000 | 5,000,000 | 1,000,000 |
| Scale | $200,000 | 10,000 | 10,000,000 | 2,000,000 |
| Custom | 上限なし | 応相談 | 応相談 | 応相談 |
RPMは1分あたりに投げられるリクエスト数、ITPM/OTPMはそれぞれ1分あたりに流せる入力・出力トークン数のこと。いちばん下のStartでも、主要モデルなら毎分200万トークンの入力が通る。個人で試作する範囲なら、まず引っかからない水準だと思う。
ひとつ注意したいのが、これは支出上限（spend cap）が消えたという話ではないこと。Start $500、Build $1,000、Scale $200,000という月間の支出上限は残っている。変わったのは「ティアの昇格が支出に紐づかなくなった」ところで、「使った分の課金が青天井になった」わけではない。ここは混同しやすいので分けて捉えておきたい。
小さく作る人ほど、この変更は効く
狙いを読むと、入口の民主化という色が濃い。これまでは「Tier 1に上がるにはまず課金」という段差があって、これがAPIを初めて触る個人や、社内でPoCを回したいチームには地味なブレーキだった。使ってみたいのに、使い込まないと枠が広がらない。
半年前にClaude Codeの5時間制限が倍になったときも近い流れを感じたけど、Anthropicはここ最近、上位ユーザーを優遇するより「全体の枠を配って裾野を広げる」方向に舵を切っているように見える。背景には計算資源の増強もあるはずで、配れる余裕ができたから配っている、という読み方もできる。
現場感覚で言うと、これがいちばん効くのは「社内で誰かがAPIで試作したい」と言い出したとき。以前は課金と枠の説明から入る必要があったのが、これからは「とりあえずキー発行して触ってみて」で済む場面が増える。導入初速のハードルが1段下がるのは、チームに新しいものを入れる立場だとありがたい。
キャッシュを効かせると、制限は実質もっと高い
ここが今回いちばん伝えたい部分。表の数字だけ見て「毎分200万トークンか」と判断すると、実は損をする。Claudeのレート制限には、多くの人が見落としているレバーがある。
仕組みを噛み砕く。ITPM、つまり毎分の入力トークン制限にカウントされるのは、原則「キャッシュに載っていない入力トークンだけ」なんだよな。プロンプトキャッシュを使って一度読ませた内容は、次から cache_read_input_tokens として扱われて、これはITPMの計算に入らない（一部の旧モデルを除く）。
これが効く場面を具体で言うと、たとえば20万トークンの長い仕様書を毎回頭に付けて質問を投げるケース。素直に毎回全部送ると、20万トークンがまるごとITPMを食う。でも仕様書をキャッシュに載せておけば、2回目以降その20万トークンは制限にカウントされず、実際に数えられるのは新しく足した質問文の数十トークンだけになる。
公式が出している例がわかりやすい。ITPM上限が200万で、キャッシュヒット率が80%なら、実質は毎分1,000万トークン（キャッシュ外200万＋キャッシュ済み800万）を処理できる計算になる。制限の数字を変えなくても、キャッシュの使い方だけでスループットが数倍に化ける。しかもキャッシュ済みトークンは課金も割安（基本料金の1割）なので、レート制限とコストの両方に効く。長い共通コンテキストを何度も投げる設計なら、まずここを詰めるのがいちばんコスパがいいと思う。
モデルごとに別勘定、Sonnet 5と4.xは別の財布
もうひとつ、実装でハマりやすい落とし穴。レート制限はモデルごとに別々にカウントされる。裏を返すと、複数モデルを同時に、それぞれの上限まで使える。負荷分散の設計余地がある一方で、勘違いも生みやすい。
特に気をつけたいのが、昨日出たばかりのSonnet 5は、Sonnet 4.xとは別枠になっている点。ドキュメントにも「Sonnet 5は独立したレート制限を持ち、Sonnet 4.xの合算バケットには含まれない」と明記されている。逆にOpusは4.8/4.7/4.6/4.5の合算で1つの枠、Sonnet 4.6と4.5も合算で1つの枠。移行期にモデルを混在させると、どの枠を食っているか見えにくくなるので、切り替えのタイミングは意識しておきたい。
あとFable 5だけは制限が明確に低い。Startで見ると主要モデルが毎分200万トークンなのに対し、Fable 5は50万トークン、出力も10万トークンに絞られている。先日の再展開で安全マージンを広げた流れとも地続きで、最上位モデルは枠の面でも慎重に出している印象。Fable 5を本番の高負荷で回す前提だと、この差は設計に響く。
429が返ってきたら、増枠を叫ぶ前にやること
レート制限に当たると、429エラーが返り、retry-after ヘッダに「何秒待てばいいか」が入って戻ってくる。エンジニア側でまずやるのは、この retry-after を素直に読んで待つリトライ処理を入れること。ヘッダを無視して即リトライすると、かえって弾かれ続ける。
制限の回復の仕方も知っておくと動きが変わる。Claudeのレート制限はトークンバケット方式で動いている。これは、固定の時刻にドカッとリセットされるのではなく、時間とともに少しずつ枠が回復し続ける仕組み。バケツに水が一定速度で注がれ続けるイメージで、使った分がじわじわ戻る。だから「毎分ちょうどにリセット」を待つより、少し待って回復した分から再開するほうが理にかなっている。
もうひとつ知っておきたいのが、上限に達していなくても429が出るケース。トラフィックが急にはね上がると、加速度制限（acceleration limit）に引っかかることがある。負荷試験でいきなり最大までぶん回すと、上限内でも弾かれる。本番投入前にトラフィックは段階的に上げて、急なスパイクを作らないほうが安全だ。
そのうえで枠が足りないなら、Consoleの Limits ページから増枠申請ができる。ただ、申請の前にプロンプトキャッシュとリトライ設計を詰めるほうが先。実効スループットはそっちで大きく変わるので、枠を上げるのは最後の手段くらいの順番でちょうどいい。
本番にスケールさせる前に、コスト側で決めておくこと
APIをチームの本番に載せる立場だと、レート制限の緩和は素直に朗報だけど、コスト管理はむしろ気を配る場面が増える。枠が広がるということは、事故ったときに一気に使える量も増えるということだから。
救いは、支出上限（spend cap）が残っていること。ティアの昇格が支出連動でなくなっても、各ティアの月間支出上限は生きているし、自分でティア上限より低い支出上限を設定することもできる。マネージャー目線で言うと、ここは予算事故のブレーキとして歓迎したい。まず低めに支出上限を引いておいて、実トラフィックを見ながら上げる運用が安全。
ワークスペース単位の制限も使える。組織全体の枠のうち、特定のワークスペースにレート制限・支出上限を割り当てておけば、1つのプロジェクトが暴走して組織の枠を食い尽くす事故を防げる。複数チームで同じ組織アカウントを共有しているなら、ここを設計しておく価値は高い。Scaleを超える規模ならCustomティアで営業と個別調整、という段階になる。
自分ならまず何を確認するか
整理すると、今回の変更は「入口を下げて、実効スループットはキャッシュで自分で伸ばせる」という設計になっている。枠そのものの数字より、キャッシュを効かせられるかどうかで実力が決まる作りだ。
自分が明日確認するなら、まずConsoleの Limits ページで、自分の組織が今どのティアに置かれたかと現在の制限値を見る。次に Usage ページのキャッシュヒット率を見て、低いようならプロンプトキャッシュの設計を見直す。長い共通コンテキストを毎回投げているなら、そこを載せ替えるだけで実効の枠が跳ねる可能性がある。増枠申請はそのあと、まだ足りなければ、の順番でいい。
この「全ユーザーに枠を配る」流れは、たぶん他社も追随してくる気がする。計算資源の取り合いが各社の枠に直結する状況で、どこがどれだけ気前よく配れるかは、そのまま開発者の乗り換え先を左右する。次の四半期に他社がどう動くかを見ておくと、どのAPIを本番の土台に選ぶかの判断材料になるはず。
