Claude Opus 5.5のタスク当たりコストは低下、ただしトークン価格で説明できるのは半分

AnthropicはClaude Opus 5.5のトークン料金を20%引き下げたが、推定されるClaude Opus 5.5のタスク当たりコストはそれ以上に下がる可能性がある。キャッシュ読み取りはOpus 5より60%安く、長時間のClaude Codeセッションの経済性を変える。

Claude Devsは、2026年9月22日に公開したタスクコスト分析とインタラクティブ計算ツールを通じ、この違いを強調した。この分析では、個別のトークン料金を比較するのではなく、完了した作業を測定するよう開発者に促している。

この区別が、Opus 5.5とOpus 5の本当の勝負を生む。トークンが安くなっても、機能開発、移行、デバッグのセッションが安くなるとは限らない。ターン数、キャッシュの挙動、推論出力、リトライ、モデル設定が最終結果を左右する。

Claude Opus 5.5のタスク当たりコストで変わったこと

Anthropicは主要なトークン区分をすべて値下げしたが、最も大幅に引き下げられたのはキャッシュ読み取りだった。

入力・出力トークンの料金はいずれもOpus 5比で20%低下した。Anthropicのモデル発表によれば、キャッシュ読み取りは60%安くなっている。

これは、Claude Codeが以前の会話内容を繰り返しモデルに送り返すため重要だ。再利用される内容には、多くの場合、指示、ソースファイル、ツールの実行結果、それまでに完了した作業が含まれる。

プロンプトキャッシュにより、サービスは以前に処理されたコンテンツを認識できる。キャッシュ読み取りでは、その再利用可能なコンテキストを新規入力として処理するより低い料金で取得する。

Anthropicによれば、多くのコーディングおよびエージェント型ワークロードでは、キャッシュ読み取りがトークン量の大半を占める。この主張はトークン構成を示すものであり、すべての請求書で最大の費目になることを必ずしも意味しない。

推論と生成テキストは出力トークンとして課金されるため、最終コストでは依然として出力が支配的になり得る。入力が控えめでも推論量が多いセッションでは、キャッシュ読み取りの値下げによる恩恵は小さくなる可能性がある。

公式のタスクコスト分析は、これらの影響を分けている。まず両モデルを同一のトークン数で比較し、料金変更の影響を切り分ける。

その例示セッションには、大量のキャッシュ済みコンテキスト、一部の新規入力、より少量の出力が含まれる。これらの固定条件では、Opus 5.5のコストはOpus 5より約31%低い。

この結果は、見出しとなる値下げ幅の中間に位置する。セッションが安価なキャッシュ読み取りの恩恵を受けるため20%を上回る一方、他のトークン区分も重要であるため60%には届かない。

Anthropicは別途、デフォルト設定での一般的なワークロードのコストは約40%低下すると見積もっている。このより広い見積もりには、料金低下だけでなく、Opus 5.5がより効率的に作業を完了するという同社の予測も含まれる。

これらは別の主張だ。20%と60%の数値は、公開された料金変更から直接得られる。31%の例は、例示的なトークン構成に依存する。

推定40%の削減には、モデルの挙動に関する仮定が加わる。開発者はこれを、すべてのリポジトリ、プロンプト、コーディングワークフローに自動的に当てはめるべきではない。

Opus 5.5は9月22日、Claude APIおよび複数の主要クラウドプラットフォームを通じて利用可能になった。このモデルはClaude CodeとAnthropicのサブスクリプション製品にも導入された。

モデル概要には、100万トークンのコンテキストウィンドウと、デフォルトのmedium effort設定が記載されている。Adaptive thinkingは常時有効だ。

これらの詳細は、新料金表を超えてコストに影響する。より大きな利用可能コンテキストは長いセッションを支え得る一方、Adaptive thinkingはタスクの難易度に応じて課金対象の出力を追加する。

結果として、単価は下がる一方、総額はワークロードに依存する。料金変更は機会を生むが、エージェントがタスクをたどる経路が、その恩恵がどの程度現れるかを決める。

Claude Codeのタスクが最終コンテキスト以上にコストを要する理由

Claude Codeは、最後に見える会話だけでなく、ターンをまたぐ繰り返し処理にも料金がかかる。

Claude Codeのタスクはループとして機能する。モデルはコンテキストを読み、ツールを選択し、その結果を調べ、推論を更新し、これらの手順を繰り返す。

ループのたびに新たなリクエストが作成される。そのリクエストには、以前のターンで蓄積した会話の多くが含まれる。

中程度のコンテキストで始まり、Claudeがファイルを読み、テストを実行し、ターミナル出力を受け取るにつれて成長するセッションを考えてみよう。最終的なコンテキストサイズは、処理された入力の合計とは等しくない。

タスクに多数のターンが必要なら、モデルは以前の内容に繰り返し触れる。プロンプトキャッシュはこうした反復読み取りを安くするが、無料にするわけではない。

この仕組みは、似たようなコード変更で終わる2つのセッションでもコストが異なり得る理由を説明する。一方のモデルは関連ファイルをすぐに特定し、短い検証ループの後で完了するかもしれない。

もう一方は誤ったサブシステムを調べ、修正を試み、失敗に遭遇し、経路をたどり直す可能性がある。後者のセッションでは、より多くのツール呼び出し、推論、反復コンテキストに対して料金が発生する。

したがって、ターン数はコストの乗数として機能する。不必要なターンには、新たなコンテンツと既に蓄積された会話の両方が伴う。

Anthropicの例では、コンテキストは6倍に拡大し、40ターン続く。処理入力の合計は最終的なコンテキストウィンドウを大幅に上回る。

この例を25ターンに減らすと、総入力は大きく低下する。節約は、成長する同じ会話に対する反復処理を避けることで生じる。

このため、信頼できるテストコマンドはClaude Codeのタスクコストを下げ得る。モデルは、その変更が機能するかどうかについて直接的なシグナルを得られる。

そのシグナルがなければ、さらに多くのファイルを調べたり、推測的な説明をいくつも検討したりする可能性がある。ビルド、ユニットテスト、再現スクリプトはその探索を短縮できる。

ツールのバッチ処理も同様の効果をもたらし得る。関連する複数のファイルを1回で読むことで追加のリクエストサイクルを避けられる場合があるが、無差別な取得はコンテキストを膨らませかねない。

目標は、可能な限り少ないトークン数ではない。正しく検証済みの結果に至る、最短で信頼できる経路だ。

この区別は、Opus 5.5とOpus 5を比較する際に重要となる。新しいモデルは1ターンでより多くの推論を生成しても、全体として必要なターン数は少ない場合がある。

逆のことも起こり得る。Opus 5.5は常にAdaptive thinkingを使用し、Anthropicによれば、同じ名称のeffortレベルでもより多く考えることがある。

1回のリクエストの出力だけを比較する開発者は、タスク全体のパターンを見落とす可能性がある。意味のある単位には、探索、編集、テスト、修正、最終報告が含まれる。

リトライには特に注意が必要だ。低いeffortでの実行が失敗して繰り返しを要する場合、より高い設定で一度成功する実行より高くつくことがある。

モデルのダウングレードにも同じことが当てはまる。小型モデルは検索時のトークンを節約できるが、誤った結果によって主エージェントが高コストな回り道に導かれる可能性がある。

Anthropicの分析は、これを完了タスク当たりのコストとして捉えている。この指標は正確な完了を評価し、基礎となるトークン料金が魅力的に見えても、出だしの失敗にはペナルティを課す。

エンジニアリングチームへの教訓は実践的だ。1つの応答や1つのコンテキストのスナップショットではなく、スコープを定めた依頼から検証済みの結果まで、ループ全体を数えるべきだ。

キャッシュ読み取りが最大の料金逆転を生む

Opus 5.5で最も大きく引き下げられたのは、長時間のエージェントセッションで最も多く使われるトークン区分だ。

Opus 5では、キャッシュ読み取りの料金は標準入力料金の10分の1だった。Opus 5.5では、この比率が20分の1に引き下げられる。

入力料金の低下と組み合わせることで、キャッシュ読み取りは60%削減される。新規入力と出力の削減幅は、より小さい20%だ。

したがって、キャッシュの比率が高いほど、タスクの節約額は大きくなる。再利用コンテキストが少ない短いリクエストでは、基本的なトークン料金の削減幅に近いままとなる。

Anthropicの計算ツールでは、総入力、キャッシュ済み部分、出力、1日のタスク量、効率性の仮定を変更できる。最後の操作項目は、Opus 5.5が使用するトークンの減少を表す。

この効率性の仮定をゼロのままにすると、料金のみを切り分けられる。追加される削減分はすべて、モデルの挙動がタスクをどう変えるかという仮説を表す。

この分離は重要だ。料金表は外部から検証できる一方、モデルの効率はリポジトリと依頼される作業に左右される。

キャッシュ性能もセッションの挙動に依存する。安定したプロンプト接頭辞と継続的な作業は、サービスが以前に処理した内容を再利用する助けとなる。

いくつかの操作はこのパターンを崩し得る。モデルを切り替えると、新モデルでの最初のリクエストは別のキャッシュとして会話を処理することになる。

クラウドプロバイダーやゲートウェイ経由で特定の設定を変更した場合も、再利用が減る可能性がある。セッション中に新たなツールサーバーを接続すると、プロンプト構造が変わることがある。

長い中断により、キャッシュされた内容が期限切れになる場合がある。正確な影響は、キャッシュ期間とリクエストのルーティング方法に左右される。

キャッシュ書き込みには別の条件がある。新しい内容をキャッシュへ書き込むコストは、後でそれを読み取るコストより高い。

計算ツールは、単純化した比較から意図的にキャッシュ書き込みを除外している。そのため、このツールは主要変数の理解には役立つが、完全な請求額シミュレーターではない。

そのため、大規模リポジトリの最初の走査は依然として高額になり得る。後続のターンでモデルが既に処理した内容を再利用すると、節約が積み上がる。

コンパクションは別のトレードオフをもたらす。古い会話内容を短い要約に置き換え、後続リクエストで再送されるコンテキストを減らす。

ただし、コンパクションは新たなプロンプト状態も作り出す。直後のリクエストではその要約を処理する必要があり、一部の詳細コンテキストを再び取得し直す必要が生じることもある。

無関係なタスクの間にセッションをクリアすれば、不要になった過去のコンテキストが作業について回ることを防げる。1つの一貫したタスクの途中でクリアすると、有用なキャッシュ済みコンテキストを捨てることになり得る。

モデル切り替えも同様の境界を生む。Anthropicは、コンテキスト再構築のコストがモデルの優位性を打ち消しにくい、自然な区切りで切り替えるよう勧めている。

サブエージェントは請求の内訳をさらに複雑にする。各サブエージェントは独自のコンテキストウィンドウを持ち、メインの会話へ要約を返す。

この分離により、大量のファイル検索を主コンテキストの外に保てる。ただし、すべてのサブエージェントは依然としてトークンを消費し、別途設定しない限りモデルを継承する。

キャッシュ料金の削減は、長く一貫したセッションに有利に働くが、終わりのない会話を最適にするわけではない。古い指示や無関係なツール結果は、後続のすべてのリクエストを増大させ得る。

チームは、キャッシュ比率と総入力の両方を調べるべきだ。キャッシュ率が高いことは有益だが、肥大化した会話では依然として過剰な内容を処理する可能性がある。

適切に管理されたセッションは、再利用可能なコンテキストを維持しながら、無関係な作業を取り除く。このバランスは、単発応答のチャットよりもエージェント型ワークフローで重要になる。

Opus 5.5とOpus 5の比較はワークロード試験である

Anthropicによる推定節約額は、チームが自らのタスクで再現するまではベンダーの予測にとどまる。

同社によれば、Opus 5.5は提供に必要なコンピューティング量が少なく、Opus 5より30%以上速く出力を生成する。また、複数の社内ベンチマークでより強い結果を示したとも報告している。

これらの知見は、コスト効率の改善を支持する材料となる。ただし、本番コードベースで一律の削減を証明するものではない。

ベンチマークは管理された比較を提供する一方、実際のリポジトリには不完全なテスト、特殊な依存関係、社内規約、変化する要件が含まれる。こうした要因はエージェントの経路を変える。

最も不確実な変数は、同等の作業を完了するために必要なトークン数だ。Opus 5.5は出だしの失敗を避ける可能性がある一方、Adaptive thinkingは一部のプロンプトで出力を増やす可能性がある。

デフォルトのeffortはmediumで、Opus 5のデフォルトはhighでした。両方のデフォルト設定を受け入れて比較すると、モデルのバージョン以上の違いが生じます。

migration guidanceでは、effortの再調整が明確に推奨されています。以前の設定をそのまま引き継ぐと、誤解を招く結果になる可能性があります。

このモデルには、挙動と統合面での変更も導入されています。Thinkingは無効化できず、複数のツール利用パターンで更新が必要です。

Claude APIまたはGoogle Cloudで旧来のcomputer-useインターフェースを利用しているアプリケーションは、新しいツールセットへ移行する必要があります。一部の強制的なツール選択設定は、現在エラーを返します。

ツール呼び出しの合間に表示される進捗テキストも、thinking blocks経由で到着する場合があります。これらのblocksを処理しないインターフェースでは、作業中に無反応に見える可能性があります。

これらの変更は、単なる移行上の詳細ではありません。リクエストの失敗、ツールの破損、進捗表示の欠落は、再試行を生み、導入時の運用コストを押し上げる可能性があります。

したがって、公平なOpus 5.5とOpus 5の比較では、タスクを一定に保ちつつ、設定を記録すべきです。両方の実行で、同一のリポジトリ状態、受け入れ基準、検証コマンドを用意する必要があります。

開発者は、玩具的なプロンプトではなく、実際のバックログ項目をテストすべきです。小規模な構文修正では、エージェントループ、キャッシュ再利用、不適切なアプローチからの回復についてほとんど分かりません。

有用な候補には、確実に再現できるバグ、複数ファイルにまたがる機能、定義済みのテストスイートを持つ移行作業などがあります。

1回の実行だけでは不十分です。リポジトリの状態、ツールのレイテンシ、モデル挙動の非決定性によって、タスクへの到達経路は変わり得ます。

ペアにしたタスクを3件または4件実施すれば、より信頼できる初期サンプルになります。大規模なチームでは、単一の混合平均を報告するのではなく、タスク種別ごとに結果を分類すべきです。

チームは成功の定義も一貫させなければなりません。もっともらしいコードを生成してもテストに失敗する実行は、より安価に完了したものとして数えるべきではありません。

生成終了後にエンジニアリング時間を消費する可能性があるため、トークン明細に現れなくても、人間によるレビュー時間は運用分析に含める必要があります。分かりにくいパッチは、その代表例です。

Claude Codeの最終レポートは、レビュー担当者が長時間の実行を理解する助けになるかもしれません。Anthropicは、より明確な完了レポートも効率向上の潜在的な要因として提示しています。

この利点はもっともですが、ワークロードに依存します。レビュー担当者に必要な追加プロンプトが減るか、エージェントの行動を再構築する時間が短くなるかを、チームは測定すべきです。

Opus 5.5はこの分析のわずか4日前にリリースされたため、独立した公開エビデンスは依然として限られています。初期のユーザー報告だけでは、安定した業界平均を確立できません。

妥当な結論は、より限定的です。Opus 5.5の公表料金は低く、キャッシュを多用するタスクでは構造的により大きな利点があります。

完了タスクあたりの削減がAnthropicの推定に近づくかどうかは、ターン数、出力、キャッシュ挙動、再試行、移行の品質に左右されます。

Claude Codeタスクのコストを自分で測定する方法

`/usage`コマンドにより、料金に関する主張を実際のセッションで再現可能なテストに変えられます。

一貫したタスクが完了したら/usageを実行してください。Claude Code内では/costでも同じ表示を確認できます。

セッションブロックには、入力、出力、キャッシュ済み入力、そしてリスト料金に基づく推定コストが表示されます。サブスクリプション利用者は、この推定値を作業指標として扱うべきです。

これは追加のサブスクリプション請求ではありません。プランの制限とトークン課金のAPI利用は、異なる請求体系です。

まず、モデルとeffort設定を記録します。これらの詳細がなければ、2つのセッション明細は比較可能に見えても、異なる運用モードを表している場合があります。

次に、タスクの定義と受け入れテストを記録します。明確な完了条件により、ある実行が別の実行より早く終了することを防げます。

その後、キャッシュ比率を確認します。長いセッションでは通常、入力の大部分を再利用しているはずです。

キャッシュ比率が低い場合、停止、モデル変更、effort変更、プロンプト修正を示している可能性があります。また、もともと短い、あるいは断片化されたタスクを反映していることもあります。

総入力を、観測された最大コンテキストと比較してください。総入力が何倍にもなる場合、そのセッションではおそらく多数のターンが使われています。

この差が自動的に無駄を意味するわけではありません。複数ステップのエンジニアリング作業には、特にテストが新たな情報を示す場合、自然に複数のリクエストが必要になります。

それでも、同じファイルを繰り返し調査している場合は、回避可能なループを特定できる可能性があります。その繰り返しの前後のトランスクリプトを確認し、不足している指示や検証ツールを探してください。

出力には内部のthinkingが含まれるため、別途確認する価値があります。小規模で機械的な変更に対して出力が多い場合、過剰なeffortや繰り返された推論を示している可能性があります。

ペアテストでは、リポジトリを同じ開始状態にリセットしてください。Opus 5でタスクを実行し、その後Opus 5.5で実行します。以降のテストでは、順序を交互に入れ替えます。

ターン数、新規入力、キャッシュ読み取り、出力、経過時間、テスト結果、必要な人間による修正を記録してください。これらの項目は、単一の合計値よりも結果を適切に説明します。

これらの測定値を集めてから、計算機を使ってください。実際のトークン量を入力すれば、有用な料金比較が可能になります。

最初の計算では、効率コントロールをゼロにしてください。これにより、同じトークンワークロードに対して公表料金の変更がどのように影響するかを確認できます。

次に、ペア実行から観測されたトークン差を計算します。この2つ目の視点では、料金とモデルの実際の挙動を組み合わせます。

今後のすべてのタスクがそのサンプルと一致するとは想定しないでください。デバッグ、機能開発、コードレビュー、リポジトリ検索、無人のエージェント実行は分けて評価すべきです。

effortもタスクカテゴリごとにテストすべきです。mediumは範囲が明確な日常作業に適する可能性がありますが、困難な障害にはhigh effortが妥当な場合があります。

low effortは決定論的な編集に適する場合がありますが、検証によってエラーを安価に検出できる場合に限られます。low effortでの試行が失敗すれば、見かけ上の節約は弱まります。

ゲートウェイを利用するチームには、追加の確認が必要です。ゲートウェイがprompt-cachingとusageフィールドを保持しなければ、社内レポートがセッション経済性を誤って示す可能性があります。

Anthropicのgateway documentationでは、使用状況の一元追跡、予算、リクエスト帰属について説明されています。また、古いゲートウェイが新機能を妨げる可能性があることも警告しています。

より大きな組織では、usageレポートを使って、開発者別・モデル別に結果を集計できます。ただし、タスクの成果がなければ、ユーザー単位の合計だけでは依然として不十分です。

有用な社内指標では、完了タスクとトークン消費量を組み合わせます。別の指標では、テスト失敗やレビュー担当者の却下後に発生する再試行を追跡します。

チームは、短い実験メモをエンジニアリング上の意思決定と併せて保存できます。検索可能なtechnical knowledge baseは、プロンプト、設定、成果、移行時の知見を保持できます。

この記録は、モデル変更とプロセス変更を区別する助けになります。また、共有された方法論なしにすべてのチームが同じベンチマークを繰り返すことも防ぎます。

目標は、すべてのセッションを最小の明細に最適化することではありません。予測可能なコストとレビュー工数で、受け入れられるコードを提供する設定を特定することです。

節約効果が持続するかを示す3つのシグナル

次の検証点は、料金の引き下げが通常のエンジニアリング作業において、安定して検証済みの出力へつながるかどうかです。

第1のシグナルは、実プロジェクトから得られるペアの/usageデータです。デバッグ、機能開発、レビューにわたって削減が繰り返し確認されれば、タスクあたりのコストという議論はより強まります。

これらの比較では、トークンカテゴリと成功基準を公開すべきです。キャッシュ比率、effort、再試行を伴わない見出しのパーセンテージでは、何が変わったのか説明できません。

第2のシグナルは、長時間セッションにおけるキャッシュの安定性です。チームは、Opus 5.5がツール呼び出し、コンパクション、モデル遷移をまたいで高いキャッシュ再利用を維持できるかを確認すべきです。

キャッシュ比率が一貫して低ければ、期待される優位性は弱まります。ワークフロー設計またはインフラが、ユーザーによる有利なキャッシュ料金への到達を妨げていることを示唆します。

第3のシグナルは、移行後の再試行頻度です。Opus 5.5は、effortのデフォルト、thinkingの挙動、複数のツールインターフェースを変更します。

失敗するループが減れば、モデルがより効率的に作業を完了するというAnthropicの主張を支持します。統合エラーが増えれば、公表された節約効果は一時的に失われる可能性があります。

開発者は、比較対象をOpus 5だけに絞ることも避けるべきです。小型のClaudeモデルは、検索、ログの閲覧、安価な要約に引き続き適している場合があります。

重要なのは、ワークロードの配置です。Opus 5.5は監督付きコーディングの主力モデルとなる一方、小型モデルは範囲の限定された取得処理を担えるかもしれません。

困難な無人タスクでは、複数回の失敗を避けられるなら、より高性能なモデルを正当化できます。成功に至る最も安価な経路は、より高コストのモデルから始まる場合があります。

Anthropicの計算機は、推定の背後にある変数を可視化することで、この議論を改善します。ただし、特定のチームにとっての結果を確定するものではありません。

Claude Opus 5.5のタスクあたりのコストは、トークン使用量が同等であれば低く、特にキャッシュ読み取りが入力の大部分を占める場合に顕著です。正確な削減幅は、依然として実証的な問題です。

実際のバックログ項目を1件選び、合格テストを定義して、各モデルで1回ずつ実行してください。/usage、ターン数、出力、キャッシュ比率、レビュー修正を比較します。

チーム全体のデフォルトを変更する前に、このプロセスを複数のタスク種別で繰り返してください。Opus 5.5がより少ない再試行で完了するなら、料金引き下げの効果は積み重なります。

より多くの推論を消費したり統合を妨げたりする場合、見出し上の節約は縮小します。次の1か月におけるペアの本番測定は、どの単一の計算機プリセットよりも重要になります。