Opus 5.5のタスクコストを試算する方法 — ターン数と読み取りで分解

Opus 5.5のタスクコストを決める4要素

Claude Codeのタスクは、モデルが会話を読み、ツールを呼び、結果を読んでまたループする一連の処理です。ループを1周するたびに1回のリクエストが発生し、その積み重ねがタスクの単価になります。

Anthropicのブログ記事「What a task costs on Opus 5.5」は、この単価を4つの要素に分解しています。ターン数・キャッシュ読み取り・出力トークンの種類・モデル選択です。トークン単価が同じ2つのモデルでも、片方が1回でファイルを読み切り、もう片方が読み直しと修正を繰り返せば、後者のほうが高くつきます。ターンが増えるたびに、それまでの会話全体が再送されるためです。

Opus 5.5のAPIリスト価格は、入力トークンが100万あたり4ドル、出力トークンが20ドル、キャッシュ読み取りが0.20ドルです。キャッシュ読み取りは入力価格の20分の1(5%)に相当し、この比率が試算全体の土台になります。

ターン数はコストにどう効くか

20,000トークンの文脈から始まり、ファイルやツール結果を読み込むうちに120,000トークンまで増えるタスクで考えます。

• 40ターンで完了した場合: 1タスクあたり約280万トークンの入力が発生し、キャッシュ読み取り率90%なら入力コストは約1.62ドル
• 25ターンで完了した場合: 入力は約175万トークンに収まり、コストは約1.02ドル

会話の最大サイズは120,000トークンで変わらないのに、ターン数が減るだけで入力コストは4割近く下がります。1ターンはそのターンで追加した分だけでなく、それ以前の会話全体を再送するコストを背負うため、減らせるターンが最も安いターンになります。

ターンを減らす具体策として、モデルが自分の作業を確認できる手段(テスト・ビルド・エンドポイント呼び出し)を用意することを挙げています。確認手段があると、モデルは自分の誤りをその場で見つけやすくなります。ツール呼び出しをまとめてバッチ実行するモデルも、再送の回数が減る分だけ安くなります。

キャッシュ読み取り率が変える金額

同じ280万トークンの入力でも、キャッシュ読み取り率によって金額は大きく変わります。

キャッシュ読み取りは入力価格の20分の1で課金されるため、他のどの設定よりも入力コストへの影響が大きい項目です。安定して同じ会話を継続するセッションは自然に高いヒット率を保ちますが、システムプロンプトの変更やモデルの切り替え、MCPサーバーの接続・切断はキャッシュを崩す要因になります。キャッシュの仕組みそのものは自動プロンプトキャッシュが多ターン会話でどう動くかで扱っています。

出力トークンとエフォートの関係

Opus 5.5では、出力トークン1個がキャッシュ読み取り100個分の価格に相当します。典型的なタスクの出力6万トークンは1.20ドルで、これはキャッシュから600万トークンを読むのと同じ金額です。

出力にはthinking(モデルの思考過程)も含まれ、画面に要約しか表示されなくても課金対象になります。エフォートレベル(low / medium / high / xhigh / max)は主にこの思考量を左右するため、エフォートを上げるとタスクの単価が大きく動きます。Opus 5.5の既定はmediumで、Opus 5の既定だったhighより1段階低い設定です。同じレベル名でも思考量はモデルごとに異なり、Opus 5.5はxhighとmaxで特にOpus 5より多く思考するため、Opus 5用に選んでいたレベルをそのまま引き継がないほうが安全です。

エフォートの費用対効果を測る目安になる試算もあります。highでタスク全体に20,000トークンの思考が追加されると仮定すると、Opus 5.5では0.40ドルです。これは、10ターンのリトライループ(キャッシュ済み文脈10万トークン・出力合計1万トークン)とほぼ同額です。つまりhighは、リトライを1回防げれば元が取れる計算になります。逆に、mediumで1回で終わるタスクにhighを使うと、その分は無駄なコストです。効率化の別の切り口は入力サイズ不明でも最大出力を引き出す実装パターンでも扱っています。

Opus 5からの価格変化と31%という数字

Opus 5.5では入力・出力トークンがOpus 5より20%安く、キャッシュ読み取りは60%安くなりました。キャッシュ読み取り価格は入力価格の10分の1(Opus 5)から20分の1(Opus 5.5)に下がっています。

同一トークン数での比較(Fig B)では、キャッシュ読み取り200万・新規入力20万・出力6万トークンのセッションが、Opus 5では3.50ドル、Opus 5.5では2.40ドルになり、価格差だけで約31%安くなります。この数字はトークン単価の変化だけを見たもので、Opus 5.5が同じタスクをより少ないトークンでこなせるかどうかは含んでいません。「40%安い」という広報上の数値は、既定エフォートでの典型的な作業量まで含めた見積もりであり、トークン単価そのものの下落率とは別物です。この2つの数字の違いは「40%安い」の実際の節約幅を検証するで扱っています。

自分のタスクで試算する手順

推奨されている測定手順は次の4段階です。

1. タスクの完了直後に /usage(または /cost)を実行し、Sessionブロックの入力・出力・キャッシュのトークン数を確認する
2. 同じタスクをOpus 5とOpus 5.5の両方で実行し、ターン数・出力トークン数・コストを記録する(Opus 5.5にはClaude Code v2.1.280以降が必要)
3. 結論を出す前に、3〜4件のタスクで同じ比較を繰り返す
4. エフォートを変えて同じ作業をlow・medium・highで試し、どのレベルで1回で完了するかを確認する

/usage の画面を読むときは、①キャッシュ読み取りの比率が長いセッションなのに低くないか、②小さな変更に対して出力が多すぎないか(エフォート過剰かリトライの兆候)、③入力合計が会話サイズの何倍になっているか、の3点を確認します。会話サイズの何倍もの入力が発生している場合は、ループが繰り返された可能性が高く、会話を読み返して原因を探る価値があります。

/usageの数字を式に入れて単価を出す

ここまでの試算例は一次ソースの想定値です。自分のタスクの単価を出すには、/usage で確認した3つの数値をそのまま次の式に入れます。

• 入力コスト(ドル)= (キャッシュ読み取りトークン数 × 0.20 + 非キャッシュ入力トークン数 × 4) ÷ 1,000,000
• 出力コスト(ドル)= 出力トークン数(thinking含む)× 20 ÷ 1,000,000
• タスク単価 = 入力コスト + 出力コスト

/usage のSessionブロックの値を、そのまま次の表に書き写すだけで埋まります。

どこを動かすと何ドル変わるかは、前段の試算例だけで比較できます。

3つの操作のうち、ターン数を減らすかキャッシュ読み取り率を上げるかは、エフォートを上げる場合よりも値幅が大きくなります。エフォートを上げるかどうかは、この0.40ドルとリトライ1回分のコストを比べて決めるのが目安です。

リトライと大きな構成変更のコスト

エフォートを上げても解決しない場合の次の一手はモデルの切り替えですが、キャッシュはモデルごとに独立しているため、切り替えた最初のターンは会話全体をキャッシュ書き込み価格で払い直すことになります。/compact で圧縮してから切り替えるか、短い計画メモから新しいセッションを始めると、この初回コストを抑えられます。

サブエージェントやAgent Teamsを使う構成では、コストの掛け算に注意が必要です。サブエージェントはそれぞれ独自のコンテキストウィンドウを持ち、要約だけを親に返しますが、自分の分のトークンは自分で支払います。実験的機能のAgent Teamsは、チームメイトがplanモードで動く場合、標準セッションのおよそ7倍のトークンを消費するとコストに関するドキュメントに記載されています。コスト管理の設定例はAgent Teamsのコスト管理にまとめています。

モデル移行そのものの手順はClaudeモデルの移行ガイド、料金体系全体の比較はClaude APIとサブスクの料金比較で扱っています。

プロンプトの棚卸しでコストが下がった実測例

Opus 4.8からOpus 5.5への移行を、社内のカスタマーサポート用ベンチマーク(44件のチケット)で検証した結果もあります。プロンプトには古いモデル向けの儀式的な指示(必須の6ステップ手順・スクラッチパッド指定・二重検証の指示など、互いに矛盾する指示も含む)が複数残っていました。

Opus 5.5への移行を低エフォートで行っただけで、ベンチマークのコストは約18%下がりました。さらに /claude-api prompt-audit コマンドでこうした指示を取り除いたところ、コストはさらに9%下がり、Opus 4.8の基準から見て合計で約25%の削減になりました。ただしこれは1つのベンチマークの結果であり、期待値ではなく一例として捉えるべき数字です。

そのほかの課金ルールと日常の目安

試算に直接は出てこないものの、日々の判断に効く課金ルールもあります。ファストモードはOpus 5.5を最大2.5倍速く動かす代わりに、入力・出力ともに標準の2倍(100万トークンあたり入力8ドル・出力40ドル)を課金します。Claudeのサブスクリプションではプランの上限ではなく利用クレジットに計上され、オンにした直後の1リクエストは会話全体を未キャッシュの価格で払い直す点に注意が必要です。

Message Batches APIを使うと入力・出力とも半額になり、即時応答が不要なバッチ処理に向きます。日常の支出感覚としては、エンタープライズ導入全体での平均が開発者1人・1稼働日あたり約13ドル、利用者の90%は1稼働日あたり30ドル未満に収まるという数字も示されています。自分のセッションがこの水準から大きく外れているなら、/usage を見直す良いきっかけになります。

まとめ

Opus 5.5のタスク単価は、ターン数・キャッシュ読み取り率・出力トークン量・モデル選択の4つで決まります。単価が下がっても、ターン数が増えたりリトライが発生したりすれば総コストは膨らむため、価格改定だけを見て月間コストを見積もるのは早計です。自分のタスクで判断するなら、/usage の記録を実タスクで比較するのが最も確実な方法です。エフォートやモデルの切り替えは、リトライ1回分のコストと比べてから選ぶと、判断の基準がぶれません。