Claude Opus 4.8 の fast mode は 11 月 30 日で終了。Opus 5.5 はトークン単価では安いが、リクエスト単位では安いとは限らない

10 月 30 日、Anthropic は Claude Opus 4.8 の fast mode を非推奨にしました。2026 年 11 月 30 日以降、claude-opus-4-8 に speed: "fast" を付けたリクエストはエラーを返します。自動で standard に切り替わることを期待していた人にとって肝心な点は、Claude Code v2.1.316 のリリースノートにはっきり書かれています。リクエストは standard の Opus 4.8 にフォールバックしません。失敗します。

モデル自体はなくなりません。claude-opus-4-8 はアクティブとして掲載されており、提供終了は早くても 2027 年 5 月 28 日です。終わるのはその上の設定ひとつで、公式の移行先は Opus 5.5 です。Opus 5.5 の fast mode はトークン単価が安くなっています。ただ、トークン単価が安いこととリクエスト単位で安いことは別の話で、今回の移行では両者が逆を向くことがあります。

Claude Opus 4.8 の fast mode で、11 月 30 日に何が使えなくなるのか

claude-opus-4-8 上の speed: "fast" だけです。同じモデルへの standard 速度のリクエストは引き続き動きますし、Opus 5.5 の fast mode も、まだ research preview の Opus 5 の fast mode も使えます。

4.8 の fast mode は最初から、ベータヘッダー fast-mode-2026-02-01 の裏にある research preview でした。Opus 5.5 は 10 月 15 日に preview を抜けています。ヘッダーは不要で（送っても動きます）、Start、Build、Scale の各 usage tier にデフォルトの fast レート制限があるので、アクセスを申請する必要もありません。Evaluation tier の組織は、上の tier に上がった時点で使えるようになります。

Opus 4.7 はすでに同じ道をたどっています。fast mode は 6 月 25 日に非推奨となり 7 月 24 日に削除され、4.7 での speed: "fast" は今ではエラーを返します。4.8 も 12 月 1 日には同じ挙動になると考えておくべきです。

まだ残っている Claude Opus 4.8 fast mode の呼び出しをどう見つけるか

三方向から探します。どの方法にも見落としがあるからです。コードは fast を指定している場所を、レスポンスは実際に得た速度を、analytics API は実際に fast を送っているのが誰かを、忘れていたスクリプトも含めて教えてくれます。

まずコードから。この設定はたいていのコードベースでリテラルか SDK の enum になっています。ベータヘッダーも二つ目の目印として有効です。Opus 5.5 ではもう不要なので、これが残っていれば 4.8 時代のコードである可能性が高いからです。次のコマンドは dict、YAML、JSON の書き方と、Go、C#、Java の enum を拾います。

grep -rnE "fast-mode-2026-02-01|speed[\"']?[[:space:]]*[:=][[:space:]]*[\"']?fast|Speed\.?(Fast|FAST)" \
  --include='*.py' --include='*.ts' --include='*.js' --include='*.go' --include='*.cs' \
  --include='*.java' --include='*.json' --include='*.yaml' --include='*.yml' --include='*.toml' .

これで見つかるのは「fast」と書いてあるリクエストです。どのモデルに送られるかまではわかりません。モデル ID が環境変数や設定サービスから来る場合、コードを変えなくても 4.8 への fast リクエストが 5.5 への fast リクエストに変わることがありますし、その逆もあります。モデル名がどこで決まるかも確認してください。

実行時には、すべてのレスポンスに usage.speed が入っていて、値は "fast" か "standard" です。モデル名と並べてログに残しましょう。fast リクエストが 429 や 529 で返ってきたら、fast のレート制限か容量の上限に当たっています。モデル自体の問題ではありません。11 月 30 日以降に 4.8 で同じリクエストを送った場合は、これとは別のエラーで失敗します。

組織全体については、Usage and Cost Analytics API（10 月 29 日からベータで、従来の Usage and Cost API とは別物）に speed ディメンションと speeds[] フィルターがあります。管理者レベルの認証情報が必要なので、個人アカウントでは使えません。この Console 用の例では Admin API キーを使います。公開日までの 30 日間に 4.8 へ fast トラフィックを送った API キーとプロダクトが返ってきます（日付は自分の期間に合わせて変えてください。1 リクエストあたり最大 31 日です）。

curl --globoff "https://api.anthropic.com/v1/organizations/analytics/usage?\
starting_at=2026-10-10T00:00:00Z&\
ending_at=2026-11-09T00:00:00Z&\
models[]=claude-opus-4-8&\
speeds[]=fast&\
group_by[]=api_key_id&\
group_by[]=product&\
limit=1000" \
  -H "anthropic-version: 2026-10-21" \
  -H "anthropic-beta: analytics-usage-cost-2026-08-24" \
  -H "x-api-key: $ANTHROPIC_ADMIN_KEY"

これは最初のページです。レスポンスに has_more: true があれば、その next_page を page として渡し、出なくなるまで繰り返します。

結果を読むときの落とし穴が二つあります。結果が空でも、問題がないとは限りません。この API では、存在しない、あるいはスペルを間違えた models[] の値はエラーにならず、単に何にも一致しません。つまりタイプミスひとつで、まさに期待していた結果が出てしまいます。一度 group_by[]=model を付け、フィルターなしで同じクエリを実行し、返ってきた行からモデル名をコピーしてください。

もう一つ、データはリアルタイムではありません。通常は 4 時間以内に更新されますが、最大 24 時間かかることもあり、data_refreshed_at より後のデータは欠けているか不完全です。移行がうまくいったかを確かめるなら、デプロイ後の時間帯を照会するのは data_refreshed_at がそこを過ぎてからにしてください。データがまだカバーしていない空の期間は、何の証明にもなりません。Console では Usage と Cost のページの Group by で、同じ内訳を「Speed (research preview)」として見られます。

呼び出し元の一覧が手に入ったら、それぞれについて問うべきなのは、5.5 fast のほうがトークン単価で安いかどうかではありません。どの行を見ても安いからです。問うべきは、各リクエストがどれだけ出力するかです。

Claude Opus 5.5 fast mode は Opus 4.8 fast mode と比べていくらか

料金表のどの行でも安くなります。fast mode はどちらのモデルでも standard 料金の 2 倍で、Opus 5.5 の standard 料金のほうが低いため、fast の料金は 100 万トークンあたり入力 $10、出力 $50 から、$8 と $40 に下がります。

キャッシュの行はもっと動きます。プロンプトキャッシュの倍率は fast の料金の上にかかり、Opus 5.5 のキャッシュ読み取りは入力料金の 0.05 倍、4.8 は 0.1 倍です。公開されている倍率を当てはめると、100 万トークンあたり次のようになります。

つまり 4.8 fast のワークロードを 5.5 fast に移すと、トークン単位で入力と出力が 20%、キャッシュ読み取りが 60% 安くなります。三行目も見てください。キャッシュ読み取りを除けば、Opus 5.5 fast は standard 速度の Opus 4.8 よりトークン単価が高く、これは後半の判断に関わってきます。

なぜ Claude Opus 5.5 fast mode で同じリクエストが高くつくことがあるのか

もう同じリクエストではないからです。Opus 4.8 では、thinking フィールドのないリクエストは thinking なしで動きます。Opus 5.5 では thinking は常にオンで、thinking: {"type": "disabled"} は 400 を返し、thinking のトークンは、たとえ thinking のテキストが返ってこなくても出力トークンとして課金されます。回答だけを出力していた 4.8 の fast 呼び出しは、今では回答に加えてモデルが考えるのに使った分も出力し、そのすべてが 100 万トークンあたり $40 で課金されます。

出力はトークン単価で 20% 安くなったので、出力行が 4.8 fast より高くなるまでに、リクエストは最大 25% 多く出力トークンを使えます（$50 / $40）。これは出力行だけの話です。リクエスト全体には入力、キャッシュ書き込み、キャッシュ読み取りも含まれ、三つとも安くなっています。私の見立てでは、thinking なしで動いていた、プロンプトが短く回答の量が多い呼び出しがこの線を越えやすく、長いキャッシュ付きのエージェントセッションは、それを吸収できるだけの割引が最も大きくなります。どちらも保証ではありません。Anthropic 自身のチェックリストも、選んだ effort レベルでコストを測り直すよう求めています。比べるべき数字は、ログから取ったリクエストあたり、またはタスクあたりの総コストです。

それを左右する設定が二つあります。output_config.effort は今や thinking の深さを決める唯一のレバーで、Opus 5.5 のデフォルトは medium です。以前ならトークン節約のために thinking をオフにしていた場面では、移行ガイドはより低いレベルを選ぶよう勧めており、例では low を使っています。そして max_tokens は thinking とテキストの両方を含むようになったので、thinking なしの回答向けに調整した上限だと、stop_reason: "max_tokens" で終わり始めることがあります。どちらも 200 で返ってきます。Opus 5 から Opus 5.5 へのアップグレードで生じた静かな破損と同じ種類のもので、移行の残りはその記事で扱っています。強制 tool_choice と thinking の無効化は 400 を返すようになり、ツールループでは thinking ブロックを変更せずに送り返す必要があります。

Claude Opus 5.5 fast mode は、あなたのリクエストで本当に速いのか

書くのは速くなりますが、書き始めが速いとは限りません。fast mode は 1 秒あたりの出力トークン数を最大 2.5 倍に上げます。ドキュメントによると、効果はそこに集中していて、最初のトークンまでの時間ではありません。

thinking なしの 4.8 では、最初のトークンは回答のテキストでした。5.5 ではレスポンスが thinking ブロックから始まることがあり、デフォルトの display: "omitted" では thinking フィールドが空の状態で届きます。ストリームを見ているユーザーにとっては、見えるテキストが出るまでの間が空くことになります。生成が速くなれば thinking の段階も短くなるかもしれませんが、ドキュメントはそれを約束していません。つまり 5.5 fast は、トークンあたりでは速く、最初に見える単語までは遅い、ということが同時に起こりえます。

移行の前後で、ストリームの中で最初に空でないテキスト delta が届くまでの時間を測ってください。1 秒あたりのトークン数はどちらにしても上がっています。ユーザーが待っているのはその数字ではありません。最初に見える単語が遅くなったなら、まず effort を下げます。作業に thinking が必要で、それでもユーザーに進捗を見せたいなら、display: "summarized" を設定して、待ち時間に中身を持たせましょう。Claude Code のドキュメントも逆の側から同じ組み合わせを勧めています。単純なタスクで最大の速度を出すなら、fast mode と低い effort レベルの組み合わせです。

Claude の fast mode がレート制限に達したら、standard に落とすべきか待つべきか

長いキャッシュ付きコンテキストなら、待つべきです。ここがリクエストあたりの請求額が上がるもう一つの場所で、原因はモデルではなくエラーハンドラーにあります。fast mode には standard の Opus とは別のレート制限があり、レスポンスヘッダーの anthropic-fast-input-tokens-* と anthropic-fast-output-tokens-* で報告されます。これを超えると API は retry-after ヘッダー付きの 429 を返し、SDK はデフォルトで 2 回リトライします。fast の容量は継続的に回復するので、待ち時間はたいてい短い、とドキュメントは説明しています。

ドキュメントにはフォールバックの例も載っています。429 を捕まえて speed を外し、standard 速度で送り直すというものです。これ自体は機能します。ただ、その横にある注記にコストの問題がすべて詰まっています。速度の異なるリクエストはキャッシュされたプレフィックスを共有しないので、フォールバックはプロンプトキャッシュのミスになります。キャッシュのドキュメントによると、速度を変えると system とメッセージのキャッシュが無効になり、キャッシュに残るのはツール定義だけです。

Opus 5.5 で 200,000 トークンのキャッシュ済みプレフィックスを持つエージェントセッションで計算してみます。プレフィックス全体が system とメッセージにあると仮定します。fast でのウォームな読み取りは約 $0.08 です。フォールバックすると、それを standard のキャッシュに $1.00 で書き込みます。戻ったときに fast のエントリが期限切れになっていれば（デフォルトでは 5 分）、次の fast リクエストがもう一度書き込み、$2.00 かかります。一往復でキャッシュ書き込みに $1 から $3 かかるのに対し、fast に留まっていればウォームな読み取り 1 回あたり $0.08 で済みました。プロンプトが短ければフォールバックは安く、問題ありません。長いなら、ユーザー向けの締め切りがその遅れを許さない場合を除き、retry-after を待ちましょう。

モデルの選択も同じです。モデルごとにキャッシュは別なので、長い会話で最初に送る 5.5 のリクエストは、コンテキスト全体をキャッシュなしで読みます。切り替えはセッションの区切りで行ってください。300k トークンの実行の途中だと、最初の 5.5 リクエストがそのすべてを書き直します。また、プロンプトを変えていないのに切り替え後にキャッシュ読み取りが激減したなら、速度もプロンプトのテキストの外にあるパラメーターの一つだと思い出してください。プロンプトを読むだけのキャッシュ診断では見つからない種類のミスです。

Claude Code のユーザーは 11 月 30 日までに何をすべきか

二つのコマンドのどちらかです。fast mode を使い続けるなら、/model で明示的に Opus 5.5 に切り替えます。Claude Code v2.1.280 以降が必要で、切り替え後も fast mode はオンのままです。/fast をオンにするのは移行ではありません。fast mode に対応したモデルでは今のモデルがそのまま使われ、11 月 30 日まではそこに 4.8 も含まれます。4.8 に留まるなら /fast off を実行します。何も変えずに Opus 4.8 で fast mode を使い続ける、という組み合わせだけが壊れます。

ドキュメントにはほかに四つの注意点があります。fast mode がモデルを切り替える必要がある場合、v2.1.280 以降ではデフォルトで Opus 5.5 が選ばれます。Pro、Max、Ultra、Team、Enterprise の各プランでは、fast mode は usage credits からのみ支払われ、プランに含まれる利用枠からは、枠が残っていても使われません。Claude Code の fast mode は Anthropic API とサブスクリプション経由でのみ提供され、Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、Claude Platform on AWS では使えません。そして Claude Code の中で fast のレート制限に達すると、自動的に standard 速度にフォールバックし、↯ アイコンをグレーにして、クールダウン後に fast を再び有効にします。アイコンはフォールバックが起きたことを教えてくれます。教えてくれないのは、切り替えのたびに会話がキャッシュなしで読み直されること（前のセクションのミスです）と、サブスクリプションではその standard 速度のターンが credits ではなくプランの利用枠から引かれることです。

Claude Opus 4.8 を standard 速度で使い続けるのは妥当な選択か

速度を求めていたわけではないなら、妥当です。standard 速度の Opus 4.8 は、キャッシュ読み取りを除けば Opus 5.5 fast よりトークン単価が安く（$5 と $25 に対して $8 と $40）、2027 年 5 月より前に提供終了の予定はありません。しかも 5.5 で廃止されたものが残っています。デフォルトで thinking がオフであること、強制 tool_choice、Claude API での computer_20251124 ツール、そして Opus 5.5 がまったくサポートしない Priority Tier です。さらに非推奨の告知が触れていない第三の選択肢もあります。standard 速度の Opus 5.5 で、$4 と $20 です。5.5 で動き、速度を必要としないものならこれで足ります。

私なら、fast の呼び出しそれぞれに、なぜ fast だったのかを問います。人が出力を待っているなら速度こそが目的で、移行先は 5.5 fast です。その場合は上で書いた effort と max_tokens を確認してください。誰も見ていないパイプラインやバッチで動いているなら、fast mode は何の役にも立たない割増料金だったのかもしれません。Claude Code 自身のドキュメントも、長い自律タスクや CI を standard モード向けの作業として挙げています。今回の非推奨は、どの fast 呼び出しが意図したものだったかを確かめる安上がりな機会です。

Claude Opus 4.8 fast mode が削除される前に何を変えるべきか

飛ばしたときの損失が大きい順に並べます。

1. 呼び出し元をすべて見つける：fast とヘッダー fast-mode-2026-02-01 を grep し、各モデル ID がどこで決まるかを追い、モデル名で行が返ることを確かめてから analytics のクエリをページ送りする。
2. 呼び出し元ごとに移行先を決める：人が出力を待つなら Opus 5.5 fast、誰も待たないなら standard 速度の Opus 5.5 か 4.8。
3. fast の 429 で何をするか決める：長いキャッシュ付きプロンプトならリトライ、フォールバックはプロンプトが短いか締め切りが求める場合だけ。
4. 5.5 では effort を明示的に設定し、thinking の分だけ max_tokens を上げ、移行ガイドにある 400 エラーと thinking ブロックのルールを順に片付ける。
5. 5.5 で測り直す：4.8 fast と比べたリクエストあたりの総コストと、最初に見えるテキストまでの時間。
6. モデルの切り替えはセッションの区切りで行い、そのたびに会話ごとに一度はキャッシュが冷えると見込んでおく。

12 月 1 日のエラーは簡単な部分です。予告されてやって来るからです。thinking のトークンとフォールバックによるキャッシュ書き込みは 200 で返ってきて、請求書に現れます。