Claude Fable 5 レート制限徹底解説

Anthropicの最新モデルをベースに構築していて、Claude Fable 5のレート制限について疑問をお持ちの方へ、最初に率直な回答を申し上げます。Anthropicは、Fable 5専用のレート制限システムをリリース時に導入しませんでした。Fable 5（モデルID `claude-fable-5`、100万入力トークンあたり10ドル、100万出力トークンあたり50ドルで2026年6月9日リリース）は、標準のMessages APIを使用しており、お客様の組織の標準的なティアベースのAPIレート制限が適用されます。これらの制限は、アカウントの使用量と支払い履歴に応じてスケーリングされ、組織ごとおよびモデルクラスごとに適用されます。具体的な数値は、お客様がどの使用ティアに属しているかによって異なります。この枠組みが重要である理由は、Fable 5エージェントのキャパシティを計画する際、Anthropicのティアシステムに基づいて計画するものであり、リリース発表に記載された魔法の数字に基づいて計画するものではないからです。モデル自体が初めての方は、Claude Fable 5の概要が役立つでしょう。ボタン

要約

Claude Fable 5は、Anthropicの標準的なティアベースのレート制限を使用します。これは、1分あたりのリクエスト数（RPM）に加えて、1分あたりの入力トークン数（ITPM）および1分あたりの出力トークン数（OTPM）で、組織ごとおよびモデルクラスごとに適用されます。累計利用額が利用ティア（1から4まで）を上がるにつれて、制限は増加します。実際の数値は常にAnthropic Consoleで確認し、429エラーが発生した場合はそのretry-afterヘッダーを読み取って対処してください。

Anthropicのレート制限の仕組み

Anthropicは、単一のグローバルな「API制限」を設定していません。利用ティアシステムを運用しており、お客様のティアによってスループットが決まります。関連する概念が2つあります。支出制限（1暦月あたりに請求される上限額）とレート制限（APIを呼び出す速度）です。この記事は後者についてですが、両者は連動しており、お客様のティアが両方を進歩させるからです。

制限の種類

Messages APIの場合、レート制限は3つの側面で測定され、それぞれ1分ごとおよびモデルクラスごとに適用されます。

1分あたりのリクエスト数（RPM）。1分間に開始できるAPI呼び出しの独立した数。
1分あたりの入力トークン数（ITPM）。1分間に送信できる入力トークンの数。現在のほとんどのモデルでは、キャッシュされていない入力トークンのみがここにカウントされます。プロンプトキャッシュから読み取られたトークンはITPMにカウントされないため、キャッシュを使用すると実質的なスループットを元の数値よりも大幅に向上させることができます。
1分あたりの出力トークン数（OTPM）。モデルが1分間に生成できるトークンの数。これはトークンがストリーミングされる際にリアルタイムで評価され、max_tokensの上限が事前に課金されることはありません。max_tokensを高く設定しても、それ自体でOTPMを消費するわけではありません。実際に生成されたトークンのみがカウントされます。

Anthropicはこれらをトークンバケットアルゴリズムで強制します。毎分ごとに割り当てが完全にリセットされるのではなく、容量は最大値まで連続的に補充されます。実用的な結果として、「50 RPM」のような制限は、およそ1秒あたり1リクエストのように振る舞うことがあり、1分あたりの平均が問題なくても、短時間の集中した呼び出しが制限に引っかかる可能性があります。スパイク状のトラフィックよりも、スムーズで安定したトラフィックの方が同じ数値からより多くの処理を得られます。

組織ごと、モデルクラスごと

さらに2つの詳細が、数値がお客様にどのように適用されるかを決定します。第一に、制限はAPIキーごとではなく組織レベルで設定されるため、組織内のすべてのキーが同じプールから利用します（あるワークスペースを別のワークスペースから保護したい場合は、ワークスペースごとに小さな制限を設定できます）。第二に、制限はモデルクラスごとに適用されます。つまり、Fable 5のトラフィックとOpusのトラフィックは、それぞれ独自の分離されたバケットに対して測定されます。異なるモデルクラスをそれぞれの制限まで同時に実行でき、互いに競合することはありません。

ティアの進捗

ティアは、累計クレジット購入額がしきい値を超えると自動的に進捗します。Anthropicが公開しているティア（ご自身のステータスはコンソールでご確認ください）によると、構造は以下のようになっています。ティア1は5ドルのクレジット購入で解除され、ティア2は累計40ドル、ティア3は累計200ドル、ティア4は累計400ドルで、各段階で月間の利用上限額が上昇します。しきい値を超えた瞬間にティアが上がります。チケットを申請する必要はありません。ティア4より上の高い上限は、営業担当者または月次請求を通じて行われます。

これらの購入がこの特定のモデルでどのようにコストに変換されるかについて深く知りたい場合は、Claude Fable 5の価格の内訳がこのセクションとよく合います。

Claude Fable 5に特化した意味

ここが最も皆さんが知りたがる部分です。Fable 5には、特別なモデル固有の制限フレームワークはありません。標準のティアテーブルに独自のモデルクラスとして組み込まれるため、「Fable 5の制限は何ですか？」という質問は、「私の組織はどのティアに属していて、そのティアでFable 5の行には何と記載されていますか？」という質問に帰結します。

Anthropicが公開しているレート制限ティア（繰り返しになりますが、カスタム契約やエンタープライズ契約は異なるため、コンソールでご自身のものを確認してください）によると、Fable 5の行は概ね次のようにスケーリングされます。

ティア1: 50 RPM、100,000 ITPM、20,000 OTPM。
ティア2: 1,000 RPM、500,000 ITPM、100,000 OTPM。
ティア3: 2,000 RPM、1,500,000 ITPM、300,000 OTPM。
ティア4: 4,000 RPM、4,000,000 ITPM、800,000 OTPM。

これらはシステムの「形状」として扱ってください。契約ではありません。Anthropicはテーブルを更新し、優先ティアやエンタープライズ契約は状況を変え、あなたのコンソールが真実のソースです。ここに記載されている数値があなたのアカウントと異なる場合は、アカウントの情報を信じてください。

Fable 5で最も厳しくなる側面はOTPMです。Fable 5は何百万ものトークンを扱う、長期間にわたる作業、つまりエージェントが大規模なタスクを処理し、途中で大量の出力を生成するような種類の作業のために構築されています。長い生成は、開始時にOTPMを一度に大量に消費するのではなく、ストリーミングされるにつれて出力バジェットを着実に消費します。そのため、野心的なFable 5ジョブが1つあるだけで、OTPM上限に近い状態を長時間維持する可能性があります。そして、そのようなジョブを複数同時に実行すると、通常はRPMではなくOTPMが最初に限界に達します。そこから2つの習慣が生まれます。暴走する生成が膨大にならないようにmax_tokensを適切に設定することと、巨大な非ストリーミング応答を待って接続を開いたままにしないように長い出力をストリーミングすることです（これはリクエストタイムアウトを回避するのにも役立ちます）。モデルを初めて使用する場合は、Claude Fable 5 APIガイドが、これらの制限が適用されるリクエストの形式について詳しく説明しています。

制限の確認方法

この記事を含め、ブログ記事から制限を推測してはいけません。実際の数値を確認するための信頼できる方法は2つあります。

1つ目はAnthropic Consoleです。設定下の制限ページには、組織の現在のティアと有効なモデルごとのレート制限が表示されます。使用量ページには、実際の入力トークンと出力トークンのレートが、キャッシュヒット率を含めて、時間経過とともに上限と比較してグラフで表示されます。これらのグラフは、トラフィックを増やす前に「まだ余裕があるか、それとも限界に近づいているか？」を判断する最も速い方法です。

2つ目は、すべてのAPI呼び出しのレスポンスヘッダーです。Anthropicは、その時点での状況を正確に伝える一連のanthropic-ratelimit-*ヘッダーを返します。

RPMについてはanthropic-ratelimit-requests-limitとanthropic-ratelimit-requests-remaining。
ITPMについてはanthropic-ratelimit-input-tokens-limitとanthropic-ratelimit-input-tokens-remaining。
OTPMについてはanthropic-ratelimit-output-tokens-limitとanthropic-ratelimit-output-tokens-remaining。
それぞれに一致する*-resetヘッダーがRFC 3339形式で、いつそのバケットが完全に補充されるかを示します。

残りのトークンヘッダーは最も近い千に丸められ、結合されたトークンヘッダーは現在最も制限が厳しい方を報告します（たとえば、設定した場合のワークスペースレベルの上限など）。各応答で*-remainingを読み取ることで、クライアントは429エラーを受け取る前に自身を調整でき、これは優雅なバックプレッシャーとエラーの連続との違いです。

429エラーを適切に処理する

429レスポンスは、いずれかの制限に達したことを意味します。本文でどの制限に達したかが示され、決定的に重要なのは、再試行するまでに待つべき秒数を記載したretry-afterヘッダーが含まれていることです。retry-afterが示すよりも早く再試行すると、再び失敗するため、これを尊重してください。

良いニュースは、公式SDKがすでに適切な処理をしていることです。Anthropic SDKは、429および5xxレスポンスを指数関数的バックオフ（デフォルトでは2回のリトライ）で自動的に再試行し、retry-afterを読み取って各試行のタイミングを計ります。ほとんどのアプリケーションでは、この組み込みの動作で十分であり、SDKが提供しない何かが必要な場合を除き、手動でリトライループを実装すべきではありません。以下に、Fable 5でのベースラインの呼び出しを示します。

import anthropic

client = anthropic.Anthropic()  # 環境変数からANTHROPIC_API_KEYを読み取る

# 429エラーが発生しやすいバッチ処理の場合、max_retriesをデフォルトの2より高く設定する。
resilient = client.with_options(max_retries=5)

message = resilient.messages.create(
    model="claude-fable-5",
    max_tokens=4096,
    messages=[
        {"role": "user", "content": "6月の変更ログのリリース概要を作成してください。"}
    ],
)

print(message.content[0].text)

例えば、独自のUIで「現在混雑しており、再試行中です」という状態を表示するなど、明示的な制御が必要な場合は、型付けされた例外をキャッチし、ヘッダーを自分で読み取ることができます。

import anthropic

client = anthropic.Anthropic()

try:
    message = client.messages.create(
        model="claude-fable-5",
        max_tokens=4096,
        messages=[{"role": "user", "content": "このインシデントレポートを要約してください。"}],
    )
except anthropic.RateLimitError as exc:
    wait_seconds = int(exc.response.headers.get("retry-after", "60"))
    print(f"レート制限されました。{wait_seconds}秒待ってから再試行します。")

リトライを超えて、持続的な負荷に対する永続的な修正策はキューイングです。トラフィックがバースト状である場合、リクエストをキューに入れて、お客様のティアが吸収できる速度でキューを処理し、anthropic-ratelimit-*-remainingヘッダーを使用して処理速度を調整します。これにより、429エラーの壁が、スムーズでわずかに遅いパイプラインに変わり、これはほとんどの場合、実際に望ましい結果です。同じスロットルとキューの規律は、レート制限されたAPIをテストするときに現れ、ApidogでChatGPT APIをテストする方法のパターンは、Claudeの作業にも直接適用されます。

制限を増やし、負荷を軽減する

制限に繰り返しぶつかる場合、2つのレバーがあります。余裕を増やすか、必要な余裕を減らすかです。

余裕を増やすには、ティアを進めます。ティアは累計クレジット購入額に応じて変動するため、安定した実際の使用量が自動的にティアを引き上げ、各ステップでRPM、ITPM、OTPMが大幅に増加します。自動スケジュールより早くティアを上げたい場合や、カスタムまたはエンタープライズの制限が必要な場合は、コンソールの制限ページから営業担当者にお問い合わせください。優先ティアと月次請求は、コミットされた大量のワークロードのために正確に存在します。

必要な余裕を減らすには、トークンスループット自体にアプローチします。

レイテンシーに敏感ではない作業には、Batches APIを使用します。これはMessages APIリクエストを標準コストの約50%で非同期に処理し、独自のレート制限プールを持つため、ライブのインタラクティブなトラフィックと大量のジョブが競合するのを防ぎます。
繰り返されるコンテキストにはプロンプトキャッシュを有効にします。キャッシュされた入力トークンは通常ITPMにカウントされないため、Fable 5のバッチ全体で大きなシステムプロンプト、ツールセット、または参照ドキュメントをキャッシュすると、ティアに影響を与えることなく実質的な入力スループットを何倍にも増やすことができます。キャッシュが有効になっていることを確認するために、使用量ページでキャッシュヒット率を監視してください。
max_tokensを適切に設定します。高い上限を設定してもOTPMにペナルティはありませんが、寛大なmax_tokens設定では、単一の応答が長くなり、OTPMを長く消費することになります。タスクに実際に必要な値に設定してください。
長い出力をストリーミングします。ストリーミングは、大量の生成におけるリクエストタイムアウトからあなたを保護し、OTPMヘッダーを読み取るのと自然に組み合わせられる、リアルタイムでの出力の蓄積を可能にします。

これらのテクニックは複合的です。キャッシュされ、バッチ処理され、適切にストリーミングされたFable 5パイプラインは、素朴なパイプラインよりもはるかに多くの作業を同じティア内で実行できます。エージェントスタイルのワークロードに特化して、Claude Fable 5エージェントのチュートリアルは、これらのレバーが長時間実行されるループにどのように適合するかを示しています。また、スループットに敏感なジョブのモデルクラスを比較している場合、Claude Opus 4.8 APIガイドとOpus 4.8の価格ノートは、各モデルクラスが独自の個別の制限バケットを持つため、有用な参考資料となります。

ApidogでFable 5の使用状況を監視する

実際の制限を理解する最も明確な方法は、ライブのリクエストでそれらを監視することであり、APIクライアントはそれを具体的にします。Apidogを使用すると、Messages APIに対してFable 5リクエストを構築し、送信し、anthropic-ratelimit-*ヘッダーや、その呼び出しの入力、出力、キャッシュされたトークン数を報告するusageオブジェクトを含む完全なレスポンスを検査できます。これらの数値をリクエストごとに並べて見ると、ITPMとOTPMにどれだけ近づいているか、そしてキャッシュが実際にどれだけ節約になっているかを、429エラーが発生するまで待つことなく正確に知ることができます。

Apidogを使用してClaude Fable 5のAPI制限と使用量を監視する様子を示すスクリーンショット

構築中の実践的なループとしては、Apidogで代表的なFable 5プロンプトを送信し、レスポンスからanthropic-ratelimit-output-tokens-remainingとusage.output_tokensの値を読み取り、長い生成が残りのカウントをどれだけ速く減少させるかを確認します。次に、キャッシュされたシステムプロンプトを追加して再度送信し、ITPM消費がほとんど動かない間にusage.cache_read_input_tokensが増加することを確認します。この2つのリクエストの比較により、抽象的なティアテーブルが、ご自身の余裕の感覚へと変わります。また、リクエストを保存し、max_tokensを変更し、OTPM消費が上限ではなく実際の出力にどのように追従するかを観察することもできます。これは、高いmax_tokensが安全であると確信するための最も速い方法です。ご自身のキーでこの実験を行いたい場合はApidogをダウンロードし、リクエストレートを調整する際にレスポンスヘッダーに注意してください。API設計とテストにApidogをすでに標準化しているチームは、Fable 5の監視を、他のすべてに使用している同じワークスペースに組み込むことができます。