Opus 5.5が安くなった分は、どこに使うべきか。

入力4ドル、出力20ドル。この2つの数字だけでOpus 5.5の値下げを受け取ると、エージェントを回している人にいちばん効く一行を読み飛ばすことになります。効くのは3行目、キャッシュ読み取りが0.20ドルに下がったところです。

値下げの本体は、入力と出力の20%ではない

2026年9月22日に出た claude-opus-5-5 の単価を、Opus 5と並べるとこうなります。

入力も出力も20%減。ここまでは速報記事にも出ています。ただしキャッシュ読み取りだけが60%減で、下げ幅が3倍違う。

Anthropicはこの単価に「キャッシュ読み取りはエージェント作業とコーディング作業のコストの大半を占める」と添えています。典型的なワークロードで40%安くなるという公式の数字は、20%減の単価から出てくるものではありません。長いプレフィックスを何十回も読み直す作りのコストが、そこに乗っています。

Claude Opus 5.5

Claude Opus 5.5 at a glance: what it's for, model IDs on every platform, context window, output limits, pricing, availability, and the guides and resources for building with it.

platform.claude.com

キャッシュ読み取りが、入力の20分の1になった

なぜここだけ下げ幅が大きいのか。単価が一律で下がったからではなく、掛け率そのものが変わったからです。Claudeのキャッシュ読み取りは通常、入力単価の0.1倍。Opus 5.5はこれが0.05倍で、この扱いを受けるのは現時点でFable 5.1とMythos 5.1（0.025倍）、そしてOpus 5.5だけです。

キャッシュヒットの相対的な価値が「入力の10分の1」から「入力の20分の1」へ倍に上がったということです。長時間のコーディングセッションでキャッシュ読み取りが500万トークン発生したケースを置いてみます。

• Opus 5: 5,000,000 × $0.50 / 1M = $2.50（約375円）
• Opus 5.5: 5,000,000 × $0.20 / 1M = $1.00（約150円）

1セッションで225円。1日10セッション回すチームが20営業日続ければ、この項目だけで月4万5,000円ほど差が出ます（1ドル150円前後の概算です）。単価20%減の方で予算を立てると、下振れ方向に読み違えることになります。

ここから先の判断は全部この一点に紐づきます。キャッシュが効いている限り入力は安い。裏返せば、キャッシュを壊す操作の代償はOpus 5のときより重くなりました。

effortをどこで上げて、どこで下げるか

Opus 5.5はアダプティブ思考が常時オンで、切ることができません。思考の深さとコストを動かす取っ手は output_config.effort の1つだけになりました。5段階の公式の想定はこうです。

見落とされがちなのは、effortが思考の量だけでなく出力トークン全部に効く点です。低いレベルではツール呼び出しの回数が減り、複数の操作がまとめられ、前置きなしで動き出します。エージェントの挙動そのものが変わります。

では具体的にどう振るか。私の線引きはこうです。

• 1: 探索が要る作業は上げる。原因の見当がついていない不具合の追跡や複数ファイルにまたがる移行は xhigh。ここでツール呼び出しを節約されると往復が増えて結局高くつきます
• 2: 仕様が確定している作業は下げる。決まったインターフェースの実装やテスト追加は medium で十分です
• 3: 大量に回す下請けは low。ファイルの読み取り、要約、分類をサブエージェントに投げる用途は公式も low を名指ししています
• 4: max は常用しない。xhigh で2回外した1件だけに絞ります

効かせ方でひとつ注意があります。トップレベルの effort を途中で変えるとレンダリングされるプロンプトが変わり、キャッシュが無効化されます。Opus 5.5はメッセージ単位でeffortを変えるベータ（ヘッダー mid-conversation-output-config-2026-07-01）に対応していて、こちらならキャッシュが残ります。途中で上げ下げしたいなら使うのは後者です。

fast modeの倍単価が割に合う作業は、そう多くない

fast mode はOpus 5.5を入力8ドル、出力40ドルで走らせる代わりに、出力速度が最大2.5倍になる仕組みです。モデルの重みも挙動も同じで、変わるのは推論の構成だけ。ちょうど標準単価の2倍です。

確認しておきたいのは、速くなるのがどこか。公式は「速度の利得は出力トークン毎秒に集中しており、最初のトークンまでの時間ではない」と明記しています。短い往復を繰り返す対話では体感がほとんど変わらず、倍の単価だけが乗ります。

割に合うのは、出力が長いことと人が画面の前で待っていること、この2つが同時に成り立つときだけだと考えています。大きめのリファクタの差分をストリーミングで流す作業がこれに当たります。逆に、以下は対象外です。

• Batch API では使えません
• Priority Tier のコミットメントとも併用できません
• Bedrock、Google Cloud、Microsoft Foundry では提供されていません（Claude APIとClaude Codeのみ。research preview扱いで、利用にはウェイトリストか担当者経由の申請が要ります）
• 速度を切り替えるとキャッシュミスになります。標準とfastでキャッシュのプレフィックスは共有されません

最後の1点がキャッシュの話と繋がります。キャッシュの倍率はfast modeの単価に乗るので、キャッシュ読み取りも0.40ドル相当になる。長いプレフィックスを抱えたエージェントループを丸ごと乗せ換えると、速度の見返りより先にキャッシュ側のコストが立ち上がります。速くしたいのはループ全体なのか、1回の長い出力なのか。そこを分けてから決めた方がいいです。

既定値がhighからmediumに下がったことに、気づいているか

Opus 5.5には、設定を移植した人ほど踏みやすい変更があります。effort未指定のときの既定値が、Opus 5以前の high から medium に1段階下がりました。effortをサポートするモデルの中で、既定が medium なのはOpus 5.5だけです。

モデルIDだけ差し替えて effort を書いていないコードは、思考の深さが1段階下がった状態で走ります。単価も既定も下がっているので請求額は素直に減る。減った理由を単価だと思い込んだまま、出力の質が落ちたことに気づくのが遅れる。公式も、以前のモデルから設定を持ち越さず自分のevalでeffortを振り直せと書いています。

Opus 5から持ち越すと落ちる変更も並べておきます。

• thinking: {"type": "disabled"} は全effortレベルで400を返します。思考を切る運用はもう成立しません
• ツール呼び出しの強制もエラーになります
• ツール呼び出しの間のテキストが thinking ブロックに入り、既定の display 設定では中身が空になります。進捗表示としてそのテキストを流していたUIは、ツール呼び出しの間だけ黙ります

最後の1件はリクエストが失敗しないぶん見つけにくい。自前のエージェントUIを持っているなら、真っ先に確認する価値があります。

私は、値下げ分をこう配分する

安くなった分をそのまま財布に戻すのが悪いわけではありません。ただこの値下げは「キャッシュを効かせている人ほど得をする」形になっているので、受け取り方で差がつきます。

• 1: 先に固めるのはキャッシュ前提の設計。システムプロンプトとリポジトリのコンテキストを安定したプレフィックスに寄せ、途中で書き換えない。入力の20分の1という単価は、プレフィックスが一致している間しか使えません
• 2: effortは会話単位ではなく作業単位で振る。探索には xhigh、確定した実装には medium、下請けには low。途中で変えるならメッセージ単位のベータを使い、トップレベルの値は動かしません
• 3: fast modeは対象を絞って試す。出力が長く、人が待っている作業だけ。ループ全体を乗せ換えるのは最後です

最初の一歩は、いま動いているコードで effort を明示していない箇所を探すところからで十分です。そこが medium で走っていると分かった時点で、上げるか下げるかの判断が自分の手に戻ってきます。