Anthropicは2026年9月25日、開発者向けブログで、Claude Opus 5.5を使った作業の費用と、推論などにかける計算量を調整するエフォート（effort）の使い分けを解説した。AnthropicのAddy Osmani氏は、Claude Codeの/usageによる推定費用の確認方法、「⁠Opus 5より40％安い」という数字の前提、キャッシュの利用が費用に与える影響を説明した。また、AnthropicのThariq Shihipar氏は、作業内容や利用者の関わり方に応じたエフォートの選び方を紹介している。

• What a task costs on Opus 5.5 - Anthropic
• Using Claude Code: Spending your effort - Anthropic

/usageで分かる使用量と推定費用

Claude Codeで会話中に/usageまたは/costを実行すると、Session欄に、そのセッションで使った入力・出力のトークン数と推定費用が表示される。ドル建ての金額は手元の端末でAPIの通常単価を基に計算した推定値で、サブスクリプションの請求額を表すものではない。

プロンプトキャッシュの欄では、そのセッションの入力のうち、どれだけをキャッシュから再利用できたかも確認できる。Pro、Max、Team、Enterpriseの利用者には、同じ画面にプランの利用状況を示すバーも表示される。

自分の作業で費用を比べるには、/modelでOpus 5とOpus 5.5を切り替え、同じ作業をそれぞれに行わせる。Addy氏は、応答とツール実行を繰り返した回数、出力トークン数、費用を記録し、3～4件の作業で比較するよう勧めている。

「40％安い」の前提と⁠、API料金⁠・利用枠への反映

発表時の「Opus 5より40％安い」という数字は、典型的な作業をデフォルト設定で行い、トークン単位で課金した場合の推計を指したものだった。APIの通常単価は、入力・出力がOpus 5比で20％、キャッシュからの読み出しが60％下がった。

40％という推計は、この単価の値下げに加え、Opus 5.5のエフォートをデフォルトの「medium」にした場合、作業当たりの使用トークン数も減るという想定に基づく。ただし、Opus 5.5のほうが多くのトークンを使う場合もあり、費用の削減幅は作業によって異なると説明している。

ブログでは、両モデルの使用トークン数を同じにそろえ、単価の違いで費用がどれだけ変わるかを試算している。キャッシュからの読み出しを200万トークン、キャッシュを使わない入力を20万トークン、出力を6万トークンと仮定すると、費用はOpus 5の3.50ドルからOpus 5.5の2.40ドルへ、約31％下がることが説明されている[1]。

また、ブログによると、サブスクリプションプランのPro、Max、Teamでも値下げが利用枠に反映され、同じ利用枠でOpus 5より約25％多く使えるという。

Opus 5.5の性能や提供先、安全策などは、発表時の記事「Anthropic⁠⁠、「⁠Claude Opus 5.5」を発表」で詳しく紹介している。

処理の繰り返しと出力トークンが作業費用を左右

Addy氏は、作業全体の費用を左右する要素として、モデルとのやり取りの回数、キャッシュの再利用、出力トークン数、モデルごとの単価を挙げる。Claude Codeは、会話を読み、ツールを実行し、その結果を読んで次の処理に進む。この繰り返しでは、それまでの会話も毎回入力として送られる。キャッシュを再利用できる部分には安い読み出し単価が適用されるが、処理の回数が増えるほど入力の累計も膨らむ。

出力には、回答文だけでなく思考に使ったトークンも含まれる。トークン単位の課金では、Claude Codeの画面に思考の要約しか表示されない場合も、思考に使ったすべてのトークンが課金対象になる。このため、エフォートの設定は作業費用にも影響する。

ただし、エフォートを下げて使用トークン数を減らしても、作業を完了できず再試行が増えれば、かえって高くつく場合がある。ブログでは、テストやビルドなど、Claudeが作業結果を確認できる手段を用意し、誤りを早く見つけられるようにすることも勧めている。

エフォートは作業内容と利用者の関わり方で選ぶ

エフォートのデフォルトは、Opus 5の「high」からOpus 5.5では「medium」に変わった。同じエフォートに設定しても、Opus 5.5はOpus 5より応答する際に多く考え、両モデルの思考量の差は「xhigh」「⁠max」で特に大きくなるという。Addy氏はOpus 5で使っていた設定をそのまま引き継がず、まず「medium」から試し、「⁠xhigh」「⁠max」は効果を確かめた作業に使うよう勧めている。

Thariq氏は、自身の試作とベンチマークの分析を基に、エフォートの選び方を掘り下げている。エフォートを高く設定すると、Claudeが利用者に代わって判断することが増え、検証や例外的な条件のテストをより念入りに行うと説明している。

同氏が複数のモデルを比較した「Terminal-Bench 3.0」の分析では、エフォートを上げると例外的な条件の見落としによる失敗が減る傾向が見られた。一方で、解き方そのものを誤った失敗は、エフォートを上げても残ったという。

使い分けについては、利用者が結果を確認しながら案を練ったり、小さな変更を重ねたりする場面に、応答の速い「low」を挙げる。通常の機能実装には「medium⁠」⁠、既存コードの不具合修正など検証が重要な作業には「high⁠」⁠、難しい作業を自律的に進めさせたい場面には「max」を使うという目安を示した。

仕様の具体性による違いも見られた。Thariq氏がフィットネスアプリの作成を大まかに依頼した試作では、エフォートを上げるほどClaudeが独自に決めることが増え、機能も充実した。一方、Claudeからの質問に答えて仕様を詳しく詰めた試作では、モデルやエフォートが違っても、設計や実装は似たものになったという。

同氏自身も、Claude Codeを使った機能開発では、仕様を渡し、不足する点をClaudeに質問させてから「low」で実装し、自分でレビューしている。必要に応じて修正を重ねた後、「⁠high」で検証とテストを行うようにしているとのこと。

キャッシュの再利用と会話の長さが費用に影響

Claude Codeは、システム指示やツールの定義、それまでの会話など、繰り返し送る入力をプロンプトキャッシュで再利用する。APIでは、キャッシュを使わず処理する部分には通常の入力単価、新たに保存する部分には書き込み単価、保存済みの内容を再利用する部分には読み出し単価が適用される。

ブログによると、Claude Codeのキャッシュの有効期限は、APIキーやクラウドサービス経由ではデフォルトで5分、サブスクリプションでは1時間となる。サブスクリプションでも、追加使用のクレジットを消費する場合は5分になる。キャッシュが再利用されるたびに期限は更新されるが、期限が切れると再び書き込みが必要になる。

Opus 5.5のAPI料金では、読み出し単価は通常の入力の5％となる。書き込み単価は、5分のキャッシュでは通常の入力の1.25倍、1時間のキャッシュでは2倍。書き込む部分にはこの単価が適用され、通常の入力料金に加算されるわけではない。

キャッシュを再利用できるのは、前のリクエストと先頭から一致する部分に限られる。MCPサーバーの接続・切断などでツールの定義が変わると、キャッシュの一部または全部を書き直すことになる。モデルを切り替えた場合も、新しいモデルではキャッシュを作り直すことになる。

また、会話の途中で初めて高速実行のfast modeを有効にすると、直後のリクエストではそれまでの会話全体にキャッシュが効かず、fast modeの入力料金がかかる。fast modeは通常料金の2倍で、サブスクリプションでもプランの利用枠とは別に追加使用のクレジットを消費する。

エフォートの変更でキャッシュが維持される場合

Claude Codeでは、会話の途中でも/effortで設定を変更できる。Addy氏の説明によると、APIキーまたはClaudeのサブスクリプションを使ってOpus 5.5を動かす場合は、変更後もキャッシュが維持される。一方、Amazon Bedrock、Google CloudのAgent Platform、Claude apps gateway経由では、変更で会話のキャッシュが無効になり、次のリクエストで会話全体をキャッシュに書き直す料金がかかる。

会話を圧縮するタイミングと注意点

キャッシュが使えても、会話が長くなるほど毎回読み出す量は増える。Claude Codeは会話がコンテキストの上限に近づくと古い履歴を要約するほか、利用者が/compactで圧縮することもできる。関係のない別の作業に移る場合は、/clearで会話を空にできる。

/compactは後の入力を減らせる一方、要約の生成と、短くなった会話のキャッシュへの書き込みに費用がかかる。作業終了の直前に圧縮すると、その後に減らせる入力費用より、圧縮自体の費用の方が高くつく場合もある。要約で細部が失われる可能性もあるため、ブログでは作業の区切りで実行し、残すべき情報を指定するよう勧めている。作業を中断する場合は、キャッシュの期限が切れた後に圧縮するより、中断前のキャッシュが有効なうちに圧縮するほうが入力費用を抑えられるという。

モデルとプロンプトも作業に合わせて見直す

Addy氏は、利用者が確認しながら進める機能開発などにはOpus 5.5、検索やログの要約にはHaikuやSonnet、難しい自律的な作業にはFable 5.1を使うという目安も示した。サブエージェントを使う場合は、そのモデルと使用量も費用に影響する。複数のClaude Codeが並行して動くエージェントチームでは、それぞれがトークンを消費するため、チームを小さく保ち、作業を終えたエージェントを停止するよう勧めている。

古いモデル向けの指示が、不要な出力やツールの繰り返し実行を招く場合もある。ブログでは、/claude-api prompt-auditでSkillsやCLAUDE.mdなどの指示を点検し、見直しの前後で実際の作業の使用量を比較する方法を紹介した[2]。

最後に、Addy氏は/usageの数値から作業の進め方を見直す方法も紹介している。キャッシュから読み出した割合が低ければ中断やモデル変更などを、小さな変更なのに出力が多ければエフォートの設定や再試行を確認する。現在の会話のトークン数に対して、そのセッションの累計入力トークン数が大幅に多い場合は、処理を繰り返した箇所がないかを調べることを勧めている。