はじめに
Anthropicは2026年9月22日、Claude Code公式ブログで、Opus 5.5における「1タスクあたりのコスト」を解説する記事を公開しました。本稿では、ターン数・キャッシュ・出力トークンが費用を決める仕組みと、エフォート設定やモデル選択など、コストを抑えるための具体策を整理します。
参考記事
- タイトル: What a task costs on Opus 5.5
- 著者: Addy Osmani
- 発行元: Anthropic(Claude Blog)
- 発行日: 2026年9月22日
- URL: https://claude.com/blog/what-a-task-costs-on-opus-5-5
関連記事



要点
- Opus 5.5のAPI料金は入力・出力がOpus 5より20%安く、キャッシュ読み取りは60%安い
- 同じトークン量のセッションで比べると、価格変更だけで約31%のコスト減になる
- タスクのコストは主にターン数・キャッシュ読み取り・出力トークン・モデルの4要素で決まる
- まずエフォートを調整し、同じ問題で2回つまずいたらFable 5.1へ切り替えることが推奨されている
- エフォートやモデルの変更、MCPサーバーの接続変更などはキャッシュ書き込みを発生させる
詳細解説
タスクのコストと「やり直し」のコスト
記事はまず、私たちが買っているのはトークンではなく「完了したタスク」だという視点から始まります。トークン単価が同じモデル同士でも、コードを1回読んで済ませるモデルと、読んで修正を試し、また読み直すモデルとでは、同じタスクの費用が大きく変わります。各ステップは1ターンにあたり、ターンごとにそれまでの会話全体が再送されるためです。
記事の目標は、読者が自分の作業について次の3つに答えられるようになることだとされています。
- 普段のタスクはOpus 5.5でいくらかかるのか
- どの設定がそれを変え、どれくらい変わるのか
- 自分のセッションの使用量はどう確認するのか
著者は冒頭で、トークンを節約する方法はどれも「タスクが完了しない」リスクと引き換えになると強調しています。エフォートを下げる、小さなモデルを使う、文脈を減らすといった手段は確かにトークンを減らしますが、やり直しが1回起きればその節約分を上回るという考え方です。なお、記事中の数値には定価と、定価から組み立てた例示が混在しており、公式ドキュメントと自分の計算で確かめるよう呼びかけています。
本稿としては、「安く済ませる工夫」を単体で評価せず、完了までの総額で考えるという枠組みそのものが、この記事の一番の読みどころだと受け止めています。GitHub Copilotのコスト最適化も「短くする」より「終わらせる」ことを重視しており、エージェント型のコーディングでは共通した考え方になりつつあると思います。
タスクのコストを決める4つの要素
Claude Codeのタスクは、モデルが会話を読み、ツールを呼び出し、結果を読み、完了するまでまた繰り返すループです。1周が1リクエストにあたり、その費用は次の4つで決まります。
- ターン数: 毎ターン、それまでの会話全体が再送される。ターンが少ないほど処理される入力も減る
- キャッシュ読み取り: 再送分の大半は前のターンで読んだテキストで、入力単価のごく一部の「キャッシュ読み取り」として課金される
- 出力トークン: 最も高いトークンで、入力の5倍の単価。思考(Extended thinking)も出力として課金される
- モデル: モデルごとに単価が異なり、選んだモデルがすべてのトークンの価格を決める
記事の例では、Opus 5.5のAPI定価として入力100万トークンあたり4ドル、出力20ドル、キャッシュ読み取り0.20ドルが使われています(キャッシュ書き込みは計算から除外)。
ターン数について、記事は次の例を挙げています。2万トークンの文脈で始まり、ファイルやツールの結果を読むうちに12万トークンまで膨らむタスクを40ターンで行うと、1ターン平均の送信量は約7万トークン、合計で約280万トークンの入力になります。会話自体は12万トークンを超えていないにもかかわらずです。キャッシュ率90%なら入力費は約1.62ドル、同じタスクを25ターンで終えると約175万トークン・約1.02ドルになります。
ターン数を減らす習慣として、記事はモデルに「自分の作業を確かめる手段」を与えることを勧めています。実行できるテスト、ビルド、エンドポイントを呼ぶスクリプトなどがあれば、モデルは誤りに早く気づけます。また、必要な情報を1回でまとめて集め、ツール呼び出しをまとめて行うモデルは、再送の回数自体が減ります。
キャッシュ読み取りの影響はさらに大きく、同じ280万トークンでもキャッシュを使わなければ11.20ドル、キャッシュ率90%で1.62ドル、96%なら約0.99ドルです。記事は、入力費をこれほど動かす設定は他にないとしています。
出力トークンは、Opus 5.5ではキャッシュ読み取りの100倍の単価です。典型的なタスクの出力6万トークンは1.20ドルで、600万トークンをキャッシュから読むのと同額になります。Claude Codeが思考の要約しか表示しない場合でも、思考全体が課金対象です。エフォートが主に思考量を変えるため、請求額への影響が大きいという説明です。
モデルについては、キャッシュ読み取りが安いモデルは長いセッションで、出力が安いモデルは推論量の多いタスクで効いてくるとされています。
Opus 5.5で変わったこと
記事によれば、変わったのは「価格」と「モデルがこなす作業量」の2点です。
価格は全項目で下がりました。入力・出力はOpus 5より20%安く、キャッシュ読み取りは60%安くなっています。キャッシュ読み取りの単価は、入力単価の10分の1から20分の1へと比率自体も下がりました。Pro・Max・Teamプランでは、この値下げが利用上限に反映され、キャッシュされた文脈も含めてOpus 5より約25%多く使えるとされています。キャッシュ読み取りの追加値下げはAPI料金の変更です。
APIキーで使う場合、Claude Codeで最も効くのはキャッシュ読み取りの値下げです。長いエージェント的なセッションでは入力の大半がキャッシュ読み取りになるためです。節約幅は作業の形で変わり、ほぼキャッシュ読み取りのセッションなら入力費で最大60%、キャッシュのない短い質問に長い回答が返るケースでは出力が支配的なため最大20%です。多くのClaude Codeのタスクはその中間に位置します。
一方で、Opus 5.5は回答前に必ず思考するため、1回の回答で使うトークンが増える場合もあります。Anthropicは、Opus 5.5ではより多くの作業をこなせると見込みつつも、タスクによって異なるため自分の作業で測るよう求めています。範囲が明確なタスクでは両モデルのターン数はほぼ同じで、恩恵は値下げ分だけです。差が最も大きくなるのは、誤った方針に多くのターンを費やしうる自由度の高いタスクだとされています。
また、Opus 5.5は長い実行の最後に、変更内容・発見したこと・利用者に必要な対応をまとめた報告を出します。何が起きたかが分かればセッションを再実行する回数が減るため、これもコスト削減につながるという説明です。Opus 5の登場時にも性能と価格のバランスが話題になりましたが、今回は単価の引き下げに加えて「無駄なやり直しを減らす」方向の改善が重ねられていると読めます。
同じタスクで比べる
記事では、同じトークン量のセッションを両モデルの定価で計算した例(Fig B)が示されています。
| 項目 | トークン量 | Opus 5 | Opus 5.5 |
| キャッシュ読み取り | 200万 | $1.00 | $0.40 |
| 新規入力 | 20万 | $1.00 | $0.80 |
| 出力 | 6万 | $1.50 | $1.20 |
| 合計 | ─ | $3.50 | $2.40 |
※Opus 5.5の各項目は、記事に示された単価(キャッシュ読み取り0.20ドル、入力4ドル、出力20ドル)から本稿で算出
この3項目は、Claude Codeの /usage がセッションごとに表示する内容と同じです。トークン量ではキャッシュ読み取りが最大、出力が最小ですが、費用では出力が最大になります。新規入力は、各ファイルの初回読み込みや新しいツール結果にあたります。価格変更だけで約31%安くなり、1日10タスク・月22営業日で換算すると、月770ドルが528ドルになる(242ドル減)という試算です。
記事には、入力トークン量・キャッシュ率・出力トークン量・1日のタスク数・「Opus 5.5で減るトークンの割合(利用者の想定)」を入力できる計算ツールも用意されています。実際の値は、タスク終了時に /usage を実行してSessionブロックから入力・出力・キャッシュの数値を拾うと入れられます。最後の項目は価格変更だけを見たいなら0%のままにし、自分の作業で設定したい場合は同じタスクをOpus 5とOpus 5.5で実行してターン数と出力トークンを比べるよう案内されています。
エフォートはモデル変更より先に上げる
ここからは、セッションの価値を最大化するためのTipsです。エフォートは、モデルが1ターンに費やすトークン量(思考、書く文章、ツール呼び出し)の大まかな傾向を決める設定です。低いほどツール呼び出しが少なく短くなります。Opus 5.5には4段階とセッション限定の最大設定があります。
- low: 機械的な作業向け。リネームや既知のパターンを複数ファイルに適用する作業など
- medium: 範囲が明確な日常作業向け。highより1ターンの思考が少なく、ターン単価が下がる
- high: mediumで行き詰まったときに使う
- xhigh: 難しい問題向け
- max: 1セッション限りで使う最大設定
設定と確認は、Claude Codeで次のコマンドを実行します。
# エフォートをmediumに設定する(high、lowなども同様に指定できます)
/effort medium
# 現在のエフォートを表示する
/effort status
# 使用するモデルを確認・切り替える
/model
# セッションのトークン使用量と推定コストを表示する
/usageClaude Codeはモデルごとに既定のエフォートを設定しており、/effort status で確認できます。エフォートはタスクの途中でも変更でき、次のリクエストから適用されます。
エフォートの価格感について、記事は次の目安を示しています。highでタスク全体の思考が2万トークン増えると、Opus 5.5では0.40ドルです。これは、キャッシュ済み文脈10万トークンで10ターン、出力合計1万トークンのやり直しループとほぼ同額です。つまりhighは、やり直しを1回防げれば元が取れる一方、mediumで一発で終わるタスクでは無駄になります。
mediumが不足している典型例として、記事は「修正が1つの層で止まる」ケースを挙げています。APIハンドラーのフィールド名を変更したとき、mediumではハンドラーとそのテストは通っても、クライアントが古いフィールド名を送り続けることがあります。highでは書き込む前に呼び出し元をより多く読み、両方の層を一度に修正します。ただし、クライアントを通すテストを実行できれば、mediumでも同じバグをその場で検出できます。テスト実行は1ターン分のコストですが、エフォートを上げると毎ターンの思考が増えるため、まず検証手段があるかを確認し、それでも解決しなければより大きなモデルへ、という順番が勧められています。
注意: エフォートや思考の設定を変更すると、キャッシュされた会話がクリアされます。これらの設定はキャッシュが照合するプロンプトの一部だからです。次のリクエストでは会話全体にキャッシュ書き込みの料金がかかるため、変更は作業の区切りで行うのがよいとされています。
作業に合ったモデルを選ぶ
モデル選択はすべてのトークンの価格を決めるため、エフォート以上に請求額を動かします。メインのモデルを継承するサブエージェント(Claude Codeが作業を分担させる補助エージェント)も、その価格を継承します。記事は、日々の作業では検索用の小さなモデル、密に監督する作業用のOpus 5.5、最難関タスク用の大きなモデルの3つを使い分けることを勧めています。
- Opus 5.5(日常のメイン): 数ファイルにまたがる機能開発、デバッグ、修正を伴うコードレビューなど、人が監督する作業向け
- Fable 5.1(上位): トークン単価より結果が重要なとき。監督しない長時間の実行、コードベースに前例のない問題、多数のサブエージェントを連携させる大規模変更など
- Sonnet / Haiku(下位): コードを書く作業ではなく、検索・要約を担うサブエージェント、ログやテスト出力の読み取り、「これはどこで定義されているか」といった調べもの
Fable 5.1への切り替えは、3回目の失敗を待たず、Opus 5.5のhighで同じ問題に2回つまずいたら行い、解決したら戻すのが目安です。対話的な作業では、レイテンシが低くコストも安いOpus 5.5の方が適しているとされています。Anthropicによれば、Fable 5.1の定価は入力100万トークンあたり10ドル、出力50ドルでOpus 5.5の2.5倍ですが、キャッシュ読み取りは0.25ドル(入力単価の0.025倍)でOpus 5.5の1.25倍にとどまります。そのため価格差は、キャッシュ中心の長い実行で最も小さく、出力の多いタスクで最も大きくなります。
注意: キャッシュは前のモデルに属するため、切り替え後の最初のターンでは会話全体にキャッシュ書き込み料金がかかります。切り替える前に /compact を実行するか、短い計画メモを書いて新しいセッションを始めると、そのターンを小さくできます。また、/model での選択は新しいセッションの既定値としても保存されるため、難所を越えたら元に戻す必要があります。
複数ファイルにまたがる機械的な編集は、小さなモデルではなくOpus 5.5のままエフォートをlowにすることが勧められています。サブエージェントを小さなモデルで動かすには、定義ファイルで model: haiku や model: sonnet を指定するか、全サブエージェントを1つのモデルにそろえる環境変数 CLAUDE_CODE_SUBAGENT_MODEL を設定します。定義ファイルでの指定は環境変数より優先され、どちらもなければメインのモデルで動きます。以下は、記事の説明をもとに筆者が補足したサンプルです(詳細な書式は公式ドキュメントで確認してください)。
---
# 検索専用サブエージェントの定義ファイルの例(筆者による補足)
name: code-searcher
description: ファイルの場所や定義箇所を探して要約するサブエージェント
# このサブエージェントだけ小さなモデルで動かす指定
model: haiku
---
指定されたシンボルの定義箇所と呼び出し元を探し、ファイルパスと行番号を要約して返してください。
# すべてのサブエージェントを同じモデルで動かすための環境変数の例(筆者による補足)
export CLAUDE_CODE_SUBAGENT_MODEL=sonnet各サブエージェントは独自のコンテキストウィンドウで動き、要約だけを返すため、メインの会話にファイル読み込みが残りません。ただし、自身のトークン費用はかかります。また、小さなモデルが検索結果を読み違えるとメインのモデルが誤ったファイルを追うことになり、その回り道の費用はメイン側が負担します。記事は、ファイル探し・テスト実行・ログ読み取りのように誤りに気づきやすい作業に限定し、判断を要する作業はメインのモデルに残すよう勧めています。
なお、opusplan エイリアスは、Opusがプランモードで計画し、Sonnetが計画を実行するという逆の分担です。コード編集をSonnetに任せる形になるため、既定にする前に自分のタスクで測るよう注意が添えられています。本稿としては、「どこで間違えると高くつくか」を基準にモデルを割り振るという発想は、Claude Code以外のエージェント設計にも応用しやすい考え方だと思います。
移行時にはプロンプトを点検する
古いモデル向けに書かれた指示は、Opus 5.5に余計な文章を書かせたり、ツール呼び出しを繰り返させたりすることがあります。Claude Codeでは、次のコマンドでスキルやCLAUDE.mdなどの設定を、こうしたプロンプトのアンチパターンの観点から点検できます。Claude Platform上で構築したアプリのコードも点検対象です。
# スキルやCLAUDE.mdなどのプロンプト設定をアンチパターンの観点で点検する
/claude-api prompt-audit
Anthropicによれば、社内のカスタマーサポート用ベンチマーク(44チケット、アンチパターンを複数含むプロンプト)でOpus 4.8からOpus 5.5への移行を検証したところ、Opus 5.5(lowエフォート)への移行だけでコストが約18%下がり、prompt-auditの実行でさらに9%下がって、Opus 4.8比で約25%減になりました。削除されたのは次のような「儀式的な指示」です。
- 必須の6ステップ手順
- スクラッチパッド(作業メモ)の使用ルール
- 2回確認するルール
- 互いに矛盾する指示
記事は、これは1つのベンチマークの結果であり、期待値ではなく一例として扱うよう求めています。以前のモデルの弱点を補うために足した指示が、賢くなったモデルにとっては負担になるという構図は、モデルを更新するたびに見直す価値のある点だと考えられます。
キャッシュとコンパクションの仕組み
Claude Codeはキャッシュとコンパクション(会話の要約による圧縮)を自動で処理しますが、節約できる量はセッションの進め方で決まります。
キャッシュの対象は、システムプロンプト、ツール定義、それまでの会話など、リクエスト間で繰り返される部分です。Opus 5.5では、キャッシュ読み取りは新規入力の5%の価格です。一方、キャッシュ書き込みは新規入力より高く、5分キャッシュで入力単価の1.25倍、1時間キャッシュで2倍です。ヒットするたびに有効期限は無料でリセットされます。有効期限は支払い方法で異なり、Claudeのサブスクリプションでは1時間、APIキーやクラウドプロバイダー経由では既定で5分です。サブスクリプションでも利用クレジットを消費し始めると5分になります。
記事の試算では、12万トークンの文脈で5分キャッシュの書き込みは約0.60ドル、読み取りは約0.02ドルで、書き込み1回は読み取り25回分に相当します。APIキーで使っている場合、6分のコーヒー休憩で次の0.02ドルの読み取りが0.60ドルの書き込みに変わるという例は、実感しやすいと思います。1時間の書き込みは同じサイズで約0.96ドルで、APIではこの割増を払って作業の合間をカバーする選択肢もあります。
キャッシュは先頭から一致する部分(プレフィックス)しか再利用できません。会話の末尾に追記し続ける安定したセッションはヒット率が高く保たれますが、前の部分を変えるとヒット率が下がります。ツール定義の変更はキャッシュ全体を、システムプロンプトの変更はその地点以降(ほぼすべて)をクリアします。記事は、次のような場合にキャッシュ書き込みが発生すると想定するよう挙げています。
- キャッシュの有効期限より長く中断したとき
- エフォートや思考の設定を変えたとき
- MCPサーバーを接続・切断したとき(各リクエストの先頭で読み込まれる内容が変わりうるため)
- モデルを切り替えたとき(新しいモデルは空のキャッシュから始まるため)
- 会話がコンパクションされたとき(キャッシュが照合していた履歴が書き換わるため)
これらはセッション開始時に設定し、作業中は触らないのがよいとされています。
長いセッションほど1ターンが高くなる
毎ターン文脈全体が再送されるため、キャッシュが効いていても文脈が大きくなるほど1ターンは高くなります。Opus 5.5では、文脈2万トークンのキャッシュ読み取りは1ターン約0.004ドル、15万トークンでは約0.03ドルで、その大きさで30ターン進めると読み取りだけで0.90ドルかかります。同じ30ターンでも2万トークンなら約0.12ドルです。Claude 4.6以降はコンテキストウィンドウが大きくてもトークン単価は変わらないため、費用はすべて会話の再送から生じます。1時間前のスタックトレース、作業を終えたファイル、修正済みのテスト結果なども、残っていれば毎ターン送られ続けます。
文脈を減らす手段として、次のコマンドが紹介されています。
# 会話を空にする(費用はかからない)。無関係な作業に移るときに使う
/clear
# 会話を要約して続きを保つ(1リクエスト分の費用がかかる)。残したい内容を指示できる
/compact keep the failing test names and the schema change
# 自動コンパクションが始まる文脈の量をトークン数で指定する
/autocompact
# 接続中のMCPサーバーを確認する(使っていないものは無効化する)
/mcp記事の概算では、15万トークンでのコンパクションは約0.25ドル(読み取り、数千トークンの要約出力、短くなった文脈への新たなキャッシュ書き込み)です。その後の各ターンで約0.025ドル節約できるため、約10ターンで元が取れます。逆に、作業終了直前のコンパクションは節約より費用の方が大きくなります。要約では詳細も失われ、デバッグの途中で行うと重要なログの1行が消えることもあるため、区切りの良いところで、次に必要な具体的な情報を /compact の指示に含めるのがよいとされています。
入力前に読み込まれる内容にも注意が必要です。CLAUDE.mdはセッション開始時に文脈へ読み込まれるため、その1行1行が毎ターン再送されます。Claude Codeのコストに関するドキュメントでは、200行未満に抑えることが推奨されています。MCPのツール定義は遅延読み込みで、開始時にはツール名とサーバーの指示だけが読み込まれ、ツールが使われたときに完全な定義が読み込まれます。
なお、元記事ではClaude Codeのセッションに影響するその他の課金ルールが表で整理されています。
自分で測る
記事の数値はあくまで例示で、コードベースやプロンプト、使い方の癖によって結果は変わります。記事は次の手順で自分のタスクのコストを測るよう勧めています。
- セッション内で /usage(/cost も同じ)を実行する。Sessionブロックにトークン使用量と定価ベースの推定費用、プロンプトキャッシュの行に入力のうちキャッシュから来た割合が表示される。Pro・Max・Team・Enterpriseプランでは同じ画面にプラン使用量のバーも出る。費用は手元のマシンで定価から計算されるため、サブスクリプションでは請求額ではなく作業量の目安になる
- 同じタスクを2回実行する。おもちゃの例ではなくバックログから実際のタスクを選び、/model でOpus 5とOpus 5.5を切り替え、それぞれのターン数・出力トークン・費用を記録する。結論を出す前に3〜4タスク試す
- チームの場合は利用状況・コストのレポートを使う。Claude Code Analytics APIではユーザーごとの推定費用、Usage and Cost APIではモデル別・キャッシュ有無別の支出を確認できる
- エフォートの段階を試す。難しいタスク1つをmediumとhighで、機械的なタスク1つをlowで実行する
タスク終了時の /usage では、次の3点を確認するよう勧められています。
- キャッシュの割合: 長いセッションなら高いはず。低い場合は、長い中断、エフォートやモデルの変更、途中でのMCPサーバー接続がなかったかを確認する
- 入力に対する出力の量: 小さな変更で出力が多い場合、タスクに対してエフォートが高すぎるか、モデルがやり直しをしている可能性が高い
- 会話の大きさに対する総入力量: 総入力が会話サイズの何倍にもなっていれば、ターン数が多かったことを示す。会話を読み返してループが繰り返された箇所を探す価値がある
目安として、Claude Codeのコストに関するドキュメントでは、エンタープライズ導入の平均が開発者1人・稼働日1日あたり約13ドル、利用者の90%が1日30ドル未満とされています。自分の通常水準を大きく上回るセッションは見直す価値があるという位置づけです。
押さえておきたいポイント
最後には、実践のポイントが次のようにまとめられています。
- 範囲が明確な日常作業にはmediumエフォートを使う
- モデルに作業を確かめる手段を与え、複数ファイルにまたがる変更はプランモードから始める
- mediumで行き詰まったらhighに上げる。キャッシュ書き込みが発生しうるため、変更は区切りで行う
- highで同じ問題に2回つまずいたらFable 5.1に切り替え、解決したら戻す
- 検索やログ読み取りのサブエージェントはSonnetかHaikuに任せ、コード編集はOpus 5.5に残す
- 長いセッションは止めずに進め、キャッシュを温かい状態に保つ
- 無関係なタスクの間では /clear を、区切りでは残す内容を添えて /compact を使う
- 最も重要なのは、実際のタスクを各モデルで1回ずつ実行し、/usage の結果を比べること。信頼すべきは自分の数字である
Opus 5.5でOpus 5より利用上限が延びないと感じたら /feedback で知らせてほしいと呼びかけています。本稿としては、単価の比較表だけでは見えない「やり直し」「キャッシュ切れ」「文脈の肥大化」という3つの見えにくいコストに名前を付け、それぞれに確認方法を用意した点が実務的だと受け止めています。
まとめ
Opus 5.5は単価が下がった一方、実際の費用はターン数・キャッシュ・出力量の3つで大きく変わります。まずは実タスクで /usage を比べることが出発点になると思います。セッションのトークン消費を抑えるコツは過去記事でも整理していますので、あわせてご覧ください。
