Claude APIのレート制限を引き上げる方法 — Tierの上がり方と申請

Claude APIのレート制限を引き上げる方法は2つあります。使い続けてTierが自動で上がるのを待つ方法と、Claude Consoleの「Rate limits」ページから引き上げを申請する方法です。入金や購入でTierを上げる手段はありません。

どちらを取るかは、いまの使用率で決まります。この記事では、Tierの仕組み、申請できる条件、申請の前に確かめたいこと、申請しても足りないときの行き先を順に扱います。

レート制限はTierで決まる

Claude APIのレート制限は、組織単位で適用されます。単位は3つあり、1分あたりのリクエスト数(RPM)、入力トークン数(ITPM)、出力トークン数(OTPM)です。どれか1つでも超えると429エラーが返り、どの制限に当たったかと、待つべき秒数を示すretry-afterヘッダーが付きます。

制限の水準を決めるのが利用Tier(usage tier)です。標準のTierは3段階あります。

これとは別に、アカウントチームと個別に上限を取り決めている組織はCustom Tierに置かれます。Customには月間の支出上限がなく、制限はアカウントチームとの取り決めで決まります。

もう1つ押さえたいのがEvaluation Tierです。新しい組織や利用履歴の少ない組織は、標準より低い制限から始まることがあります。これは不正利用を防ぐ仕組みの一部で、利用履歴が積み上がると自動で上がります。

自分の組織がどのTierにいて、いまの制限がいくつかは、ConsoleのRate limitsページで見られます。サポート記事では、Settings > Limitsの場所として案内されています。

Tierは自動で上がる

Tierの移動で、ユーザーが何かをする必要はありません。組織は利用履歴とアカウントの状態をもとに自動でTierへ置かれ、使い続けるうちに上のTierへ移ります。

ここで誤解が多いのが、お金で買えるかどうかです。サポート記事は、Tierの上昇に効く入金や購入はなく、必要な操作もないと明記しています。クレジットを多めにチャージしても、それだけでは制限は変わりません。

例外が1つあります。Teamプランに紐づけて月間APIクレジットを受け取るConsole組織は、少なくともBuild Tierに移ります。月500ドルのクレジットが、組織の支出上限に収まるようにするためです。クレジットを受け取ること自体は、それ以外にTierを動かしません。

Tierが上がると、モデルごとの制限と月間の支出上限の両方が広がります。たとえばOpus 5.5の標準制限は次のとおりです。

制限はモデルごとに別々に数えられます。Fable 5系のように、Start Tierで入力が50万、出力が10万と低めに置かれたモデルもあります。全モデルの値は公式のRate limitsページが表で持っているので、実装前にそちらで確かめてください。

引き上げを申請できる条件

自動の昇格を待てないときは、Consoleから申請します。申請できるのは、現在の制限の50%以上を使っているときです。使用率が低いうちは、申請の窓口が開きません。

手順は短く、次の流れです。

申請はレート制限だけでなく、月間の支出上限にも使います。月の途中で支出上限に達すると、翌月1日の0時(UTC)までAPIが止まります。このときも429が返りますが、retry-afterヘッダーは付かず、待ってもリトライは通りません。エラー本文のerror_codeがenforced_spend_limit_reachedなら、通常のレート制限ではなく支出上限です。この場合も、上のTierに移れば再開できます。

自分で設定した支出上限に達した場合は挙動が違います。こちらはHTTP 400のinvalid_request_errorで、上限を上げるか外せば再開できます。Tierの申請とは別の話です。

申請の前に確かめたいこと

50%の条件を満たしていても、申請の前に見ておくと無駄が減る点が3つあります。

本当に上限にぶつかっているか

ConsoleのUsageページには、入力トークンと出力トークンのレート制限グラフがあります。時間ごとの最大使用量と現在の制限が重ねて出るので、ピークがどこまで上限に近いかが読めます。ここで余裕があるなら、429の原因は上限そのものではないかもしれません。

急に使用量が増えた組織では、加速制限(acceleration limit)に当たることもあります。こちらは通常の上限とは別の仕組みで、避けるには、トラフィックを段階的に増やして安定した使い方を保つ必要があります。Tierを上げても解決しない型なので、申請前に切り分けておく価値があります。

キャッシュで実効スループットを伸ばせないか

多くのモデルでは、ITPMに数えられるのはキャッシュされていない入力トークンだけです。具体的には、input_tokensとcache_creation_input_tokensが数えられ、cache_read_input_tokensは数えられません。

公式の例では、ITPMが200万でキャッシュヒット率が80%なら、1分あたり合計1,000万の入力トークンを処理できます。システムプロンプト、ツール定義、長い参考資料のように繰り返し送る部分をキャッシュすれば、申請しなくても実質の余裕が広がります。Usageページには入力トークンのキャッシュ率も出るので、見直しの材料になります。

例外はClaude Haiku 3.5で、こちらはcache_read_input_tokensもITPMに数えられます。このモデルはGoogle Cloud以外では提供を終えています。

出力側の見積もりを誤っていないか

OTPMは、実際に生成されたトークンだけで、リアルタイムに評価されます。max_tokensの値は計算に入りません。出力の上限を恐れてmax_tokensを絞る必要はなく、そこで制限を節約しても効果はありません。

申請に書く材料を手元に集める

Rate limitsページの説明には、申請フォームに入れる項目の一覧がありません。一方、Claude Platform on AWSの案内には、サポートへ連絡するときに含める内容が具体的に書かれています。Consoleから申請するときの材料集めにも使える並びです。

• 引き上げたいモデル
• モデルごとの、入力・出力トークン数のピーク(1分あたり)
• 入力のうち、キャッシュされた部分や繰り返しのコンテキストが占める大まかな割合

ピークの把握には、レスポンスヘッダーが使えます。anthropic-ratelimit-input-tokens-limitとanthropic-ratelimit-input-tokens-remainingの差を取れば、その時点で上限のどれだけを使っているかが分かります。次の例は、Pythonで残量を記録する最小の形です(公式の例ではなく、ヘッダー名に沿った書き方の一例です)。

import anthropic
 
client = anthropic.Anthropic()
 
raw = client.messages.with_raw_response.create(
    model="claude-opus-5-5",
    max_tokens=256,
    messages=[{"role": "user", "content": "ping"}],
)
h = raw.headers
limit = int(h["anthropic-ratelimit-input-tokens-limit"])
remaining = int(h["anthropic-ratelimit-input-tokens-remaining"])
print(f"入力ITPMの使用率: {(limit - remaining) / limit:.0%}")

残量は千トークン単位に丸められて返ります。厳密な値ではなく、傾向を見る用途に向きます。ヘッダー13種の分岐の書き方はClaude APIレート制限ヘッダー13種の読み方にまとめています。

申請しても足りないとき

Scale Tierの上限でも足りない規模の場合、行き先はCustom Tierです。公式のRate limitsページは、Scaleを超える制限が必要なときは、ConsoleのRate limitsページから営業チーム(sales)に連絡するよう案内しています。サポート記事も、独自の上限や確保済みの処理容量が必要な場合は営業チームへ、としています。

Priority Tierの扱いも変わっています。優先処理枠の容量コミットメントは、新規購入が停止しています。「枠を買って安定させる」という選択肢は、いまは新しく取れません。経緯とservice_tierの使い分けはClaude APIのservice_tier解説に書いています。

Claude Platform on AWSで使っている場合は、前提が違います。組織はStart Tierに置かれ、AWS Marketplaceの支払い済みインボイスの履歴が積み上がると自動で上のTierへ移ります。「Request tier increase」の流れは使えず、Anthropicの担当者かサポートに連絡します。

上限を分け合う側の設計も見る

引き上げが通っても、組織の枠を1つのワークスペースが食い尽くす構成では、他の用途が429になります。ワークスペースごとに低めの制限をかけると、組織全体の枠を公平に分けられます。ただしデフォルトのワークスペースには制限を設定できません。組織の上限は、ワークスペースの合計が超えていても常に有効です。設定の手順はClaude APIでWorkspace単位のレート制限を設定する手順で扱っています。

現在の組織とワークスペースの制限値をコードから読みたいときは、Claude Rate Limits APIが使えます。引き上げ後に値が反映されたかの確認にも向いています。

まとめ

Tierは買えず、使い続けることで自動的に上がります。待てないときは、制限の50%以上を使った状態でConsoleから申請します。その前にUsageページでピークとキャッシュ率を見ておけば、そもそも申請が要らない場合も見つかります。

Scaleでも足りない規模は、営業チームとのCustom Tierです。申請の前に切り分けるのは、通常の上限・支出上限・加速制限のどれに当たったか、という一点です。429のエラー本文でerror_codeを読むところから始めると、打ち手を取り違えずに済みます。