AnthropicのAddy Osmani氏が公式ブログで公開した記事「What a Task Costs on Opus 5.5」(2026年9月22日公開)では、Claude Codeを運用するうえで重要な「1タスクあたりの実効コスト」という考え方が示されています。
モデルのトークン単価だけを比較しても、実際の開発コストや利用上限(制限)への影響は見えてきません。本記事では、Opus 5.5における料金体系の変化、コストを左右する要素、そして今日から実践できる推奨設定を分かりやすく解説します。
1. 導入:Opus 5.5は「トークン単価」より「1タスクいくらか」で見る
Claude Codeのようなエージェント型の開発支援ツールは、以下のような「ループ(ターン)」で処理を進めます。
- モデルがこれまでの会話・コンテキストを読み込む
- ツール(ファイルの読み書きやコマンド実行)を呼び出す
- ツールの実行結果を読み込む
この「1ターン」を終えるたびに、それまでの会話履歴全体が毎回モデルへ送り直されます。そのため、どれだけトークン単価が安いモデルを使っても、ターン数が多くなれば総コストは跳ね上がります。
コストを削ろうとして無理に思考量を減らしたり、コンテキストを削りすぎたりすると、タスクが途中で失敗してやり直し(リトライ)が発生します。この「やり直し」にかかる費用は、削って浮かせた分より高くつきます。見るべきなのは単価ではなく「1つのタスクを完了させるまでにいくらかかったか」です。
本記事では、以下の3つの疑問に答えていきます。
- 自分の典型的なタスクはOpus 5.5でいくらになるのか?
- どの設定を調整すれば、どれだけコストが変わるのか?
- 実際の使用量をどのように計測・管理すればよいのか?
2. タスクの料金を決める4つの要素
1タスクにかかる費用は、主に以下の4つの変数によって決定されます。
- ターン数:少ないターン数で完了するほど、毎回送り直す入力トークンの総量を抑えられます。
- キャッシュ読み込み:送り直すテキストの大半は前のターンで処理済みです。これらは「キャッシュ読み込み」として格安の単価が適用されます。
- 出力(思考・回答):出力トークンは入力の5倍と最も高価です。画面上では非表示になる思考(Thinking)トークンも全額課金対象です。
- モデルの選択:使用するモデルによって基本単価が異なります。
3. Opus 5 → 5.5で何が安くなったか(料金表)
API定価(100万トークンあたり)における各モデルの価格差は以下の通りです。
| モデル | 入力 (Input) | 出力 (Output) | キャッシュ読み込み (Read) |
|---|---|---|---|
| Opus 5 (値下げ率からの逆算値) | $5.00 | $25.00 | $0.50 |
| Opus 5.5 | $4.00 | $20.00 | $0.20 |
| Fable 5.1 | $10.00 | $50.00 | $0.25 |
変化のポイント
- Opus 5比での大幅値下げ:Opus 5.5は入力・出力が20%安くなっただけでなく、キャッシュ読み込み単価が60%値下げ(入力単価の1/20)されました。
- サブスクプランへの還元:Pro / Max / Team等の有料定額プランでは、この値下げが「利用上限(制限)の緩和」として反映されます。これにより、Opus 5時代と比べて約25%多く作業をこなすことが可能になっています。(※キャッシュ読み込みの追加値下げ分はAPI利用時の料金に直接反映されます)
- Fable 5.1との比較:最上位モデルであるFable 5.1のキャッシュ読み込み単価($0.25)はOpus 5.5の1.25倍程度に収まっています。そのため、長いコンテキストを保持したまま進める作業では価格差が小さくなり、逆に出力トークンを大量に吐き出すタスクで最も価格差が開きます。
4. キャッシュでいちばん差がつく理由と、キャッシュが消える5つの操作
1タスクの試算例
コンテキストが20Kトークンから始まり、最終的に120Kトークンまで膨らむタスクを例にします。
- 40ターンの場合:合計約280万トークンの入力。キャッシュ率90%なら入力費は約$1.62。
- 25ターンで終えた場合:合計約175万トークンに減り、入力費は約$1.02。
- キャッシュ率の影響:同じ280万トークンでも、キャッシュ0%なら$11.20かかりますが、96%をキャッシュから読めれば約$0.99まで下がります。入力コストを最も大きく変動させるのは「キャッシュの活用度」です。
なお、Opus 5.5の出力単価($20/1M)はキャッシュ読み込み単価($0.20/1M)の100倍です。一般的なタスクで発生する出力60Kトークン($1.20)は、キャッシュされたコンテキストを600万トークン読み込むコストと同等になります。
キャッシュ書き込み(リセット)が発生する5つの操作
リクエストの先頭から会話が一致していないとキャッシュは使えません。以下の操作を行うとキャッシュが途切れ、会話全体の再書き込み費用(5分キャッシュで120Kトークンあたり約$0.60)が発生するため注意が必要です。
- キャッシュの保持時間(寿命)を超えて手を止める(定額プランは1時間、API/従量課金は5分で切れます。定額プランでもusage creditsを使い始めると5分になります)
effort(思考量)やthinkingの設定を変更する- MCP(Model Context Protocol)サーバーを接続・切断する
- セッションの途中でモデルを切り替える
- 会話を
/compact(要約)する
5. effort(思考量)の上げ下げと損益分岐
Opus 5.5では思考レベルを4段階(low / medium / high / xhigh)+単発の max から選択できます。
基本の使い分け
medium:日常的な、タスク範囲がはっきりした作業(記事で推奨されている基本レベル。現在の設定は/effort statusで確認できます)high:mediumで行き詰まった複雑な問題low:変数の置換や名前変更など、単純・機械的な作業
損益分岐の考え方
high に上げると1タスクあたり思考トークンが約20K($0.40相当)増加します。これは「キャッシュされた100Kトークンの文脈で10ターンやり直すコスト」とほぼ同等です。つまり、high にすることで手戻り(リトライ)を1回防げるなら、コストの元は十分に取れます。
ただし、思考量を増やす前に「テストを自動実行させる仕組み」を整えるのが先決です。1回のテスト実行(1ターン分の出力)でバグに気づければ、毎ターン思考トークンを消費するよりはるかに安上がりになります。
6. 開発スタイルに応じたモデルの使い分け
全体の請求額や利用制限に対しては、effort の変更以上に「どのモデルを選ぶか」が影響を与えます。メインで使うモデルのほか、用途に応じて柔軟に切り替えるのが理想です。
【メイン(手動開発)】 --> Opus 5.5(応答速度・費用のバランスが良い)
【最難関・行き詰まり】 --> Fable 5.1(精度重視、無人作業や難解なバグに)
【調べもの・サブタスク】 --> Sonnet / Haiku(ログ解析、検索・要約に)
各モデルの役割
- Opus 5.5:エンジニアがリアルタイムでインタラクティブに進める開発全般。数ファイルに跨がる実装やデバッグに最適。
- Fable 5.1:難易度が極めて高い局面用。Opus 5.5(
high)で同じ問題に2回つまずいた場合、3回目を試す前にFable 5.1に切り替えます。解決したらすぐにOpus 5.5に戻します。 - Sonnet / Haiku:コードの直接編集ではなく、「情報の検索・ログ解析・定義場所の特定」といった下調べ用のサブエージェントに指定します。
注意:モデル切り替え時の注意点 モデルを変えると会話のキャッシュがリセットされます。切り替える際は、事前に
/compactで文脈を圧縮するか、要約メモを持って新しいセッションで始めるのが無駄な出費を防ぐコツです。
7. 長いセッションと compact / clear の運用
コンテキストウィンドウが大きくても、会話が長くなると毎ターンの読み込みコストは確実に増えていきます。
- 文脈20Kトークン:1ターンの読み込みコスト約$0.004
- 文脈150Kトークン:1ターンの読み込みコスト約$0.03(30ターンで読み込みだけで$0.90)
不要になった古いエラーログやスタックトレースを保持し続けるのはコストの無駄です。以下のコマンドを適切に使い分けましょう。
/clear:会話履歴を完全にリセット(費用$0)。全く別のタスクへ移るときに使用。/compact:文脈を要約して短縮。150Kトークンの文脈で要約した場合(約$0.25)、その後約10ターン作業を続ければ要約にかかったコストの元が取れます。「〜のエラー情報だけ残して要約して」と指示を添えるのが効果的です。
8. 自分の使用量を計測・分析する方法
Claude Code上で /usage(または /cost)を実行すると、現在のセッションにおけるトークン消費量、定価ベースの推定額、およびキャッシュヒット率が表示されます。
/usage でチェックすべき3つの指標
- キャッシュ比率:長時間のセッションなのに比率が低い場合、途中でモデルを変えたか、MCPサーバーを着脱した可能性があります。
- 入力に対する出力の量:小さな変更のわりに出力が多い場合、
effortが高すぎるか無駄な試行錯誤(リトライ)が起きています。 - 会話サイズに対する入力の総量:総量が膨れ上がっている場合、ターン数を重ねすぎています。会話を読み直して、どこで同じことを繰り返したかを探します。
※ 利用規模の目安として、企業導入(エンタープライズ)での平均は開発者1人・稼働1日あたり約$13、全体の90%のユーザーは$30/日未満に収まっています。
9. まとめ:最適なコストパフォーマンスを実現する推奨設定
最後に、Addy Osmani氏が推奨する設定と運用をまとめます。
- 日常的な開発タスクは
Opus 5.5+effort mediumでスタートする - モデルが自発的に成果をテスト・検証できる手段を与える(無駄な思考を減らすため)
- 行き詰まったら
effort highに引き上げる(セッションの区切りで行う) - 同じ箇所で2度失敗したら
Fable 5.1へ切り替え、解決したらすぐ戻す - ログ検索や調査タスクのサブエージェントには
SonnetやHaikuを割り当てる - 作業の途中で無闇にモデル変更やMCPの着脱を行わず、キャッシュを維持する
- コンテキストが肥大化したら
/compact(残す情報を指定)や/clearを活用する /usageコマンドで定期的に自身のコストとターン数・キャッシュ率を確認する
コスト最適化の第一歩は、お手元の実際のタスクをOpus 5とOpus 5.5の両方で動かし、/usage で出力されるリアルな数値を見比べることです。ご自身のプロジェクトにおける実測値を参考に、最適な運用環境を構築してみてください。
参考
この記事は Gemini の原稿をもとに Claude Opus 5.5 が編集しました。
