Claude Opus の fast mode（リサーチプレビュー）

fast mode は、Claude Opus 5 と Claude Opus 4.8 の出力トークン毎秒を最大2.5倍にするリサーチプレビューの機能です。モデルそのものは変わらず、割増料金と専用のレート制限が付きます。ここでは公式ドキュメントの Fast mode に基づいて、有効にする方法・対応モデル・料金・制約を整理します。

fast mode とは何か

fast mode は同じモデルを、より速い推論構成で動かすものです。公式は「知能や能力に変更はない」と明記しています。つまり別のモデルに切り替えるのではなく、モデルの重みも挙動も同じままです。

効果の中身は次のとおりです。

• 標準速度と比べて出力トークン毎秒（OTPS）が最大2.5倍
• 速度の恩恵は OTPS に集中しており、最初のトークンまでの時間（TTFT）ではありません
• モデルの重みと挙動は同じ（別モデルではない）
• ストリーミングと併用でき、OTPS の向上はそこで最も見えやすい

この「TTFT ではない」という点は、使いどころの判断に直結します。短い応答を大量に返す用途では体感が変わりません。長い出力を1回で生成する用途（大きなリファクタリング、長文の分析）でこそ効きます。

なお fast mode はリサーチプレビューです。利用にはアカウントマネージャーへの依頼が必要で、担当がいない場合は公式のウェイトリストに登録します。

対応しているモデル

対応しているのは次の2つです。

• Claude Opus 5（claude-opus-5）
• Claude Opus 4.8（claude-opus-4-8）

提供範囲にも制限があります。Claude API（Claude Managed Agents を含む）のみで、Amazon Bedrock・Google Cloud・Microsoft Foundry では利用できません。

そして、非対応モデルの挙動が2種類に分かれる点は必ず押さえてください。ここを取り違えると、遅いまま割増でない料金を払い続けていることに気づけません。

• Claude Opus 4.7: speed: "fast" を送るとエラーが返ります。標準速度へのフォールバックはしません。モデル自体は標準速度で使えます。
• Claude Opus 4.6: speed: "fast" を送ってもエラーになりません。標準速度で実行され、割増ではなく標準料金で課金され、レスポンスの usage.speed は "standard" になります。

つまり Opus 4.6 では、コードが fast mode を要求していても静かに標準速度で動きます。fast mode を使い続けたいなら Claude Opus 5 か Opus 4.8 に移行してください。

有効にする方法

有効にするには2つを同時に指定します。リクエストに speed: "fast" を入れ、ベータヘッダ fast-mode-2026-02-01 を付けます。

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: fast-mode-2026-02-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 4096,
    "speed": "fast",
    "messages": [{
      "role": "user",
      "content": "Refactor this module to use dependency injection"
    }]
  }'

Python では beta 名前空間を使い、betas にベータ名を渡します。

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=4096,
    speed="fast",
    betas=["fast-mode-2026-02-01"],
    messages=[
        {"role": "user", "content": "Refactor this module to use dependency injection"}
    ],
)

TypeScript も同じ形です。

const response = await client.beta.messages.create({
  model: "claude-opus-5",
  max_tokens: 4096,
  speed: "fast",
  betas: ["fast-mode-2026-02-01"],
  messages: [{ role: "user", content: "Refactor this module to use dependency injection" }]
});

C#・Go・Java・PHP・Ruby にも同等の指定方法があり、いずれも beta 側の API に speed とベータ名を渡す構造です。

料金は割増になる

fast mode は標準料金に対する倍率での割増です。20万入力トークンを超えるリクエストを含め、文脈ウィンドウ全体に適用されます。

他の料金修正要素と重なります。プロンプトキャッシュの倍率は fast mode の価格の上に適用され、データレジデンシーの倍率も同様に上に乗ります。

コストの見積もりで注意すべき点を1つ挙げます。速くなるのは出力トークン毎秒であって、消費トークン数は減りません。したがって割増ぶんはそのまま費用増になります。「速い＝安い」ではないので、レイテンシに支払う価値があるかを用途ごとに判断してください。組織全体の fast mode 利用と費用は Usage and Cost API で追跡できます。

専用のレート制限とヘッダ

fast mode には標準の Opus 枠とは別の専用レート制限があります。超えると retry-after ヘッダ付きの 429 が返ります。

枠が別なので、標準の anthropic-ratelimit-* ヘッダに余裕があっても fast mode 側で 429 になることがあります。監視するヘッダを間違えると原因が分かりません。ティア別の具体値は Rate limits のページを参照してください。

どの速度で実行されたか確認する

実際にどちらの速度で実行されたかは、レスポンスの usage オブジェクトの speed フィールドで確認できます。値は "fast" か "standard" です。

{
  "id": "msg_01XFDUDYJgAACzvnptvVoYEL",
  "type": "message",
  "role": "assistant",
  "usage": {
    "input_tokens": 8,
    "output_tokens": 12,
    "speed": "fast"
  }
}

整理すると次のようになります。fast mode 非対応のモデルに speed: "fast" を送るとエラーになり、fast mode のレート制限や容量を超えた場合も 429 か 529 になります。成功したときは usage.speed が "fast" です。

唯一の例外が Claude Opus 4.6 です。他の非対応モデルと違ってエラーを返さず、静かに標準速度に切り替わります。ただし speed フィールドは正しく "standard" を返すので、この値をログに残しておけば「速いつもりで遅かった」状態を検出できます。fast mode を導入するなら、usage.speed の記録は最初から入れておくことをおすすめします。

標準速度へのフォールバック

fast mode のレート制限に当たったとき、SDK は既定で最大2回まで自動再試行します（max_retries で変更可）。サーバーが指定した遅延を待ってから再試行し、fast mode は継続的にトークンを補充する方式なので、retry-after の遅延は通常短く、容量が空き次第成功します。

待つのではなく標準速度に落としたい場合は、レート制限エラーを捕捉して speed: "fast" を外して再送します。最初の fast リクエストで max_retries を 0 にすると自動再試行を飛ばして即座に失敗させられます。

def create_message_with_fast_fallback(max_retries=0, max_attempts=3, **params):
    try:
        return client.with_options(max_retries=max_retries).beta.messages.create(**params)
    except anthropic.RateLimitError:
        if params.get("speed") == "fast":
            del params["speed"]
            return create_message_with_fast_fallback(max_retries=max_retries, **params)
        raise

ここで2つ注意があります。1つ目、max_retries を 0 にすると、過負荷や内部エラーといった他の一時的エラーに対する再試行も無効になります。公式のサンプルが、それらのケースでは既定のリトライ設定で元のリクエストを出し直しているのはこのためです。

2つ目、fast から標準へフォールバックするとプロンプトキャッシュがミスします。速度が違うリクエストはキャッシュ済みのプレフィックスを共有しません。大きな文脈をキャッシュして使っている場合、フォールバック1回のコストはレイテンシだけでなく、キャッシュ作成ぶんの費用としても跳ね返ります。

なお、この節のフォールバックはクライアント側で明示的に実装するものであり、Claude Opus 4.6 が自動的に標準速度で動く挙動とは別物です。

使う前に確認する制約

公式が挙げている制約をまとめます。導入前にここを一通り確認してください。

• プロンプトキャッシュ: fast と標準を切り替えるとプロンプトキャッシュが無効になります。速度が違うリクエストはキャッシュ済みプレフィックスを共有しません。
• 対応モデル: Claude Opus 5 と Claude Opus 4.8 のみです。
• TTFT: 効果は出力トークン毎秒に集中しており、最初のトークンまでの時間ではありません。
• Batch API: fast mode は Batch API では利用できません。
• Priority Tier: Priority Tier のコミットメントとは併用できません。
• Claude Platform on AWS: 現在利用できません。

この一覧から読み取れる使いどころは絞られます。大きな共通プレフィックスをキャッシュして回している対話型のワークロードでは、フォールバックのたびにキャッシュが飛ぶため、割増料金以上のコスト増になり得ます。逆に、キャッシュをあまり使わず、1リクエストの出力が長く、ユーザーが生成中の画面を見て待っているような用途では、OTPS 2.5倍の体感差がそのまま価値になります。