Opus 5.5 でのタスクの費用

タスクのコストと再試行のコスト

何百万ものトークンを購入しようとして始めるわけではありません。機能の構築、移行の完了、あるいはタスクの実行を目指して始めるのです。トークンの数は、その目標を達成するためにモデルが必要とした分だけになります。

トークンあたりのコストが同じ2つのモデルでも、同じタスクを実行する際のコストは大きく異なる場合があります。1つはコードを1回読み込むだけですが、もう1つはコードを読み込み、修正を試みて、再び読み込みます。これらの各ステップが1ターンとなり、ターンごとにそれまでの会話内容が再送信されます。そのため、より多くのターンを必要とするモデルは、たとえ単価が同じであっても、コストが高くなります。

この記事を読み終える頃には、自分の仕事について次の3つの質問に答えられるようになるはずです：

• Opus 5.5 では、私が普段行っている作業にはどれくらいのコストがかかるのでしょうか？
• どの設定を変更すればそれが変わり、どの程度変わるのでしょうか？
• 自分のセッション利用状況を確認するにはどうすればよいですか？

まず最初に指摘しておきたいトレードオフは、トークンの消費を抑えるあらゆる方法には、タスクの完了が犠牲になる可能性があるということです。労力を減らしたり、モデルの規模を小さくしたり、コンテキストを少なくしたりすれば、確かにトークンを節約できます。しかし、再試行にかかるコストは、そうした節約分を上回ります。この記事では、それぞれのトレードオフに具体的なコストを割り当ててみたいと思います。

ここにある数値には、定価のものもあれば、それを基に作成された試算例もあります。図はインタラクティブになっているため、読み進めながら入力値を変更してみてください。これらはあくまで試算例ですので、必ず当社のドキュメントやご自身の計算結果と照らし合わせてご確認ください。

タスクの費用はいくらですか？

Claude Codeにおけるタスクとは、ループのことです。このモデルは、会話を読み取り、ツールを呼び出し、結果を読み取り、完了するまでこの処理を繰り返します。ループを1周するごとに1回のリクエストとなります。ループにかかるコストは、4つの要素によって決まります。

ターン。ターンごとに、それまでの会話内容が再送信されます。ターン数が少ないほど、処理される入力データも少なくなります。

キャッシュ読み取り。ターンが再送信する内容のほとんどは、モデルが前のターンに認識したテキストです。これはキャッシュ読み取りとして扱われ、入力コストのごく一部で済みます。

出力トークンのタイプ。入力価格の5倍という、最もコストの高いトークンです。推論は出力として課金されるため、答えに至るまでの推論が少ないモデルほどコストは低くなります。

モデル。各モデルには独自の価格設定があり、それらは価格ページに記載されています。そのため、選択したモデルによって、すべてのトークンの価格が決定されます。

この例では、Opus 5.5のAPI定価を使用しています。入力トークン100万個あたり4ドル、出力トークン100万個あたり20ドル、キャッシュ読み取り100万回あたり0.20ドルです。後述の計算ツールと同様、この例ではキャッシュされた入力は読み取り単価で、それ以外は入力単価で課金され、キャッシュ書き込みは考慮されていません。トークンの数はあくまで例示です。

ターン

あるタスクが2万トークンのコンテキストから始まり、モデルがファイルやツールの結果を読み込むにつれて12万トークンまで増加すると仮定しましょう。40ターンで、1ターンあたりの平均送信トークン数は約7万トークンになります。 これは、会話が120Kを超えることはなかったにもかかわらず、タスク全体の入力トークン数が約2.8Mになることを意味します。キャッシュからの読み込み率が90%の場合、入力コストは約$1.62となります。一方、25ターンで実行される同じタスクでは、約1.75Mのトークンが処理され、入力コストは約$1.02となります。

1ターンにかかるコストは、そのターンで追加されるトークンのコストよりも高くなります。なぜなら、それ以前のすべての処理が再実行されるからです。したがって、最もコストの低いターンは、必要のないターンです。

反復回数を減らすことができる習慣の一つは、モデルに自身の動作を確認する手段を与えることです。例えば、実行するテスト、ビルド、あるいはエンドポイントを呼び出すスクリプトなどです。自身の動作を確認できるモデルは、ミスを早期に発見することができます。

必要な処理を1回のパスでまとめて行い、ツールの呼び出しをバッチ処理するモデルは、再送信の回数も減らすことができます。

キャッシュからの読み取り

キャッシュから取得されるトークンが1つもない場合、同じ280万個の入力トークンのコストは11.20ドルになります。ヒット率が90％の場合は1.62ドル、96％の場合は約0.99ドルとなります。これほど入力コストに大きな影響を与える設定は他にありません。安定したセッションであれば、それだけで高いヒット率が維持されます。 この投稿の後半では、キャッシュが破綻するのを防ぐための対策について解説します。

トークンの出力

Opus 5.5 では、出力トークン 1 個あたりのコストはキャッシュ読み取りの 100 倍です。一般的なタスクの 6 万個の出力トークンは 1.20 ドルかかり、これはキャッシュから 600 万個のトークンを読み取るのと同じコストです。出力には「思考」も含まれます。 Claude Codeが要約のみを表示する場合でも、そのすべてに対して料金が発生します。そのため、主にモデルの思考量に影響を与える「労力」が、請求額をこれほど大きく変動させるのです。

モデル

キャッシュ読み取りのコストが低いモデルは、主に長時間のセッションに役立ちます。一方、出力のコストが低いモデルは、主に多くの推論を必要とするタスクに役立ちます。

OPUS 5.5での変更点

変わった点は2つあります。価格と、モデルが担う作業量です。

すべての価格ラインが低くなっています。入力および出力トークンの価格は、Opus 5.0 よりも 20% 安くなっています。キャッシュ読み取りのコストは 60% 安くなっています。入力価格が低下すると、読み取りレートもそれに伴って低下し、入力価格の 10 分の 1 から 20 分の 1 になります。 図Aは、100万トークンあたりの2つのモデルを比較したものです。これらはAPIの定価です。Pro、Max、またはTeamプランでは、Opus 5.5のより低い価格が、キャッシュされたコンテキストを含め、利用制限に反映されるため、Opus 5よりも約25％多く利用できます。キャッシュ読み取りの追加割引は、API価格の変更によるものです。

また、Pro、Max、Team、およびシートベースのEnterpriseプランでは、5時間の利用制限が引き上げられました。対象となる加入者には、任意のタイミングで利用できる利用制限のリセットが提供されます。このリセットは、端末の「Claude Code」ではなく、Web版またはClaude Desktopの「設定」＞「利用状況」から確認できます。リセットはアカウント全体に適用され、Claude Codeも対象となります。

APIキーに関しては、キャッシュ読み取りの価格引き下げがClaude Codeにとって最も重要である。長期のエージェンティック・セッションでは、入力の大部分がキャッシュ読み取りに費やされる。下の図Bに示された価格設定のセッションでは、キャッシュラインの価格が1.00ドルから0.40ドルへと下落しており、これは領収書上で最大の値下がりとなっている。

どの程度の節約になるかは、処理の性質によって異なります。キャッシュからの読み取りが大部分を占めるセッションでは、入力処理を最大60%削減できます。キャッシュがなく、回答が長い短い質問の場合、出力処理が大部分を占めるため、最大20%の削減が可能です。Claude Codeのタスクのほとんどは、この2つの間にあると言えます。以下の計算ツールで、ご自身のタスクがどの位置にあるかを確認できます。

Opus 5.5 の運用コストが、Opus 5 よりも 40% 安いことは、すでにご存知かもしれません。これは、デフォルト設定でトークン単位の課金が行われる一般的なワークロードについて、当社が算出した推定値です。 これは、Opus 5.5が、価格の引き下げに加え、中程度のデフォルト設定においてタスクあたりのトークン使用数が少ないことを前提としているため、単にトークン単価が40％引き下げられたわけではありません。トークン価格は図Aに示されているものであり、図Bは価格変動そのものがもたらす影響を示しています。

Opus 5.5は、返信する前に常に熟考するため、回答に多くのトークンを使用できます。Opus 5.5では、より多くの作業をこなせるものと期待していますが、これはタスクによって異なるため、ご自身の作業で実際に測定してみてください。図Cは、2つのモデルにおけるタスクごとのコストを比較したものです。この部分は、価格よりもはるかにご自身の作業内容に左右されます。

範囲が明確に定義されたタスクでは、どちらのモデルもほぼ同じターン数で処理を完了し、得られるメリットはコスト削減だけとなります。この差は、モデルが誤った考え方に多くのターンを費やしてしまう可能性のある、範囲が定まっていないタスクにおいて最も大きくなるはずです。すべてのコードベースに通用する一概な数値はないため、実際に測定してみてください（最後のセクションを参照）。

長期実行はレポートで締めくくられます。Opus 5.5 では、長期実行の終了時に、変更点、検出結果、およびユーザーへの要望がまとめられます。これにより、何が起きたかが把握できるため、セッションの再実行頻度が減り、コスト削減にもつながります。

同じタスクを並べて比較

図Bでは、両方のモデルについて、トークン数が同じ状態で1セッション分の価格が表示されています。したがって、違いは価格変動だけであり、それ以外は何も変わりません。モデルを切り替えて比較してみてください。トークン数はあくまで例示のためのものです。

レシートには、1回のセッションにおける3つの行（/usage）が表示されています。トークン数ではキャッシュ読み取りが2Mで最も多く、出力はトークン数では最も少ないものの、コストでは最も高くなっています。新規入力は、その中間に位置しています。これには、各ファイルの最初の読み取りと、各新しいツールの結果が含まれます。

図Bでは、両モデルともトークン数が同じになっているため、価格の変化のみが示されています。Opus 5.5では、ご自身のセッションで使用するトークン数を増減させることができます。この価格設定の場合、セッションのコストは約31％安くなります。

記録された実行結果により、2つ目の効果、すなわちモデルが行う作業量の変化が加わります。フライングが発生したタスクでは、その差はさらに広がるはずです。

自分なりの数字を試してみてください

タスクで使用する値を設定するか、プリセットから開始してください。プリセットはかなりわかりやすいですが、それでも自分で計算してみることをお勧めします。キャッシュされた入力請求書はキャッシュ読み取り価格、新しい入力は入力価格で計算されるため、キャッシュスライダーは、その差額のどれだけがキャッシュ読み取りに起因するかを示しています。

実際のセッションのデータでスライダーを埋めるには、タスクの最後に /usage を実行してください。「Session」ブロックには、入力、出力、キャッシュの数値が表示されます。最後のスライダーは、Opus 5.5 がタスクを処理する際に、どれだけの作業負荷が軽減されるかというあなたの想定値です。価格変動のみを考慮する場合は、0% のままにしておいてください。 自身の作業結果に基づいて設定するには、次の手順に従ってください。Opus 5とOpus 5.5の両方で同じタスクを実行し、ターン数と出力トークンを比較します。「Measures it yourself」ではその手順を詳しく解説しており、「Reading a session」では /usage で確認すべき項目が示されています。

セッションの価値を最大限に引き出すためのヒント

Opus 5.5は価格が安いため、1トークンあたりのコストも安くなります。セッションの進め方によって使用するトークンの数は変わりますが、以下の手順が参考になります。

モデルを変更する前に、取り組みを強化しましょう

「Effort」は、モデルが各ターンで消費するトークンの量に関する一般的な傾向を設定します。これには、モデルの思考、生成するテキスト、およびツールへの呼び出しが含まれます。Effortの値が低いほど、ツールへの呼び出し回数が減り、呼び出し内容も短くなります。Opus 5.5には4つのレベル（low、medium、high、xhigh）に加え、単一セッションの最大値（max）があります。 以下の各レベルを選択して、その使用場面や設定コマンドを確認してください。

Claude Code 各モデルのデフォルトレベルを設定し、/effort status コマンドで自分の設定を確認できます。範囲が明確で日常的な作業には「medium」を試してみてください。「medium」で処理が滞る場合は、「high」を試してみてください。「high」は 1 ターンあたりの消費量が「medium」より多くなりますが、より大きなモデルに切り替えるよりは少なくて済みます。ファイル名の変更や、既知のパターンを複数のファイルに適用するといった機械的な作業には「low」を使用してください。

『Opus』5.5では、デフォルトは「中」に設定されており、これは『Opus』5のデフォルトである「高」より1段階低い設定です。ただし、このレベル設定は、すべてのモデルにおいて同じ程度の思考量を意味するわけではありません。 特定のレベルにおいて、Opus 5.5はOpus5よりも1ターンあたりの思考量が多く、特にxhighおよびmaxレベルではその差が顕著です。したがって、Opus5で選択したレベルをそのまま引き継がないでください。mediumから始め、xhighおよびmaxは、効果を確認できた作業に限定して使用してください。

エフォートプライシングを大まかに考えると、例えば「high」設定では、タスク全体で2万トークンの思考トークンが追加されるとします。Opus 5.5では、これは0.40ドルに相当します。キャッシュされたコンテキストが10万で、合計1万トークンの出力を生成する10ターン分のリトライループも、ほぼ同程度のコストがかかります。 したがって、「high」は、1回のリトライを節約できるタスクであれば元が取れます。一方、「medium」で初回に完了するはずのタスクでは、無駄になってしまいます。

メディアが1つのレイヤーを固定するとき

さらなる努力が必要だという最も明らかな兆候は、修正が1つのレイヤーだけで終わってしまうことです。

APIハンドラー内でフィールドの名前が変更されたとしましょう。 「medium」レベルでは、モデルがハンドラを更新し、ハンドラのテストは合格しますが、クライアントは依然として古いフィールドを送信します。モデルは求められた動作は行いましたが、2番目の呼び出し元を見つけるまで読み込みが進まなかったのです。「high」レベルでは、書き込みを行う前に呼び出し箇所を読み込むターン数を増やし、1回のパスで両方のレイヤーを変更します。

チェックを行うことで、同じバグを見つけ出すことができます。モデルがクライアントを経由するテストを実行できる場合、その古いフィールドは、記述されたターンにおいて、難易度「中」のテストに失敗します。したがって、労力を増やす前に、モデルがその動作を確認する方法があるかどうかを確認してください。テストの実行には1ターンと、その出力が必要です。労力を増やすと、毎ターン、思考のプロセスが増えます。

努力のレベルを引き上げたり、チェックを追加したりしても効果が得られない場合は、より大規模なモデルに切り替えてください。

セッションの途中で努力量を変更する

Claude Code では、レベルを指定して /effort を実行します（例：/effort high）。/effort status を実行すると、現在のレベルが表示されます。タスクの途中でレベルを変更することも可能で、新しいレベルは次のリクエストから適用されます。

Opus 5.5 で、API キーまたは「Claude」サブスクリプションを使用している場合、エフォートの変更を行ってもキャッシュは保持されます。会話内容を書き換えることなく、エフォートを 1 段階上げてから、再び下げることも可能です。 Amazon Bedrock、Google CloudのAgent Platform、またはClaude Apps Gatewayでは、エフォートの変更によってキャッシュされた会話がクリアされ、次のリクエストではそのすべてに対してキャッシュ書き込みコストが発生します。Opus 5.5では「Thinking」は常に有効になっているため、変更すべき「Thinking」設定はありません。

ご自身の業務に適したモデルをお選びください

モデルの選択によって、セッション内のすべてのトークンの価格が決定されるため、労力よりも価格の方が影響を大きく及ぼします。また、その影響範囲も広範囲に及びます。メインモデルを継承するすべてのサブエージェントは、その価格も継承します。通常、3つのモデルが必要です。ルックアップ用の小規模なモデル、Opus 5.5（厳密に監督する作業用）、そして最も困難なタスク用の大規模なモデルです。

Opus 5.5：日常使いの車として

監督する作業には「Opus 5.5」を活用しましょう。複数のファイルにわたる機能開発、デバッグ、および編集を伴うコードレビューなどに適しています。プログラムの動作を確認し、軌道から外れた際にはすぐに介入することで、ループを短く保つことができます。

Fable 5.1 へのアップグレード

トークンの価格よりも結果が重要になる場合は、Fable5.1へ移行してください。例えば、監視できない長期実行、コードベースに既存のパターンがない問題、および多数のサブエージェントを連携させる大規模な変更などが該当します。 3回目の失敗を待たないでください。xhigh設定のOpus 5.5で同じ問題が2回発生した場合は、切り替えを行い、解決次第、元に戻してください。対話型の作業には、レイテンシが低くコストも安いOpus 5.5の方が適しています。

Fable 5.1では、入力トークン100万枚あたり10ドル、出力トークン100万枚あたり50ドルとされており、これはOpus 5.5の価格の2.5倍にあたります。キャッシュ読み取りのコストは100万枚あたり0.25ドルで、Opus 5.5の料金の1.25倍にとどまります。これは、キャッシュ読み取りの料金が入力価格の0.025倍で請求されるためです。 したがって、キャッシュを多用する長時間の実行では価格差が最も小さくなり、書き込みの多いタスクでは最も大きくなります。

自然な区切りで切り替えてください。キャッシュは以前のモデルに属しているため、新しいモデルでの最初のターンでは、会話全体に対して書き込みコストが発生することを想定してください。 そのターンを小さくするには、まず /compact を実行するか、短い書き込みプランで新しいセッションを開始してください。切り替えるには、エイリアスまたはモデル名を指定して /model を実行します。/model を実行すると、その選択が新しいセッションのデフォルトとして保存されるため、難しい部分が終了したら元に戻してください。

検索のために下へ移動する

コードの記述ではなく、検索を行う場合は、Sonnet または Haiku に移動してください。これらは、検索や要約を行うサブエージェント、ログやテスト出力の読み取り、および「これはどこで定義されているか」といった質問に対応しています。 多数のファイルにわたる機械的な編集を行う場合は、Opus 5.5 を使用し、労力を「低」に設定してください。編集は、残りのコードを記述するモデル上で行われ、1ターンあたりのコストが低くなります。

サブエージェントをより小規模なモデルに割り当てるには、その定義で `model: haiku` または `model: sonnet` を指定します。 すべてのサブエージェントを1つのモデルに配置するには、環境変数 `CLAUDE_CODE_SUBAGENT_MODEL` を設定してください。サブエージェントの定義内でモデル名が指定されている場合、その設定がこの変数の設定を上書きします。モデル設定がないサブエージェントは、この変数が設定されていない限り、メインモデル上で実行されます。

各サブエージェントは独自のコンテキストウィンドウで実行され、要約を返すため、そのファイルへの読み込み操作はメインの会話には影響しません。各サブエージェントは依然として自身のトークン代を負担するため、その費用がいくらになるかはモデル設定によって決まります。

実験的な機能である「エージェントチーム」では、この消費量がさらに増大します。各チームメンバーは、独自のコンテキストウィンドウを持つ独立したClaude Codeインスタンスであり、終了するまでトークンを消費し続けます。当社のコストに関するドキュメントによると、チームメンバーがプランモードで実行されている場合、チーム1つあたりのトークン消費量は標準セッションの約7倍になります。 チームは小規模に保ち、各タスクを独立したものとするとともに、チームメイトの役割が完了したら終了させてください。

トレードオフ：検索結果を誤って読み取った小型モデルは、メインモデルに間違ったファイルを追跡させてしまい、メインモデルはその回り道の代償を払うことになる。ファイルの検索、テストの実行、ログの読み取りなど、間違いに気づいてもコストが低い作業には、小型モデルを活用すべきである。

判断を要する処理はメインモデルに残しておきましょう。opusplanというエイリアスは、作業を別の方法で分割しています。Opusはプランモードで計画を立て、Sonnetは計画を実行します。これにより、コードの編集はSonnetで行われることになり、上記のアドバイスとは逆の仕組みになります。これをデフォルト設定にする前に、ご自身のタスクで実際に試してみてください。

移行の際はプロンプトを確認してください

旧モデル向けに作成された指示書は、Opus 5.5 において、不要な記述を増やしたり、ツールの呼び出しを繰り返し行わせたりする原因となる可能性があります。Claude Code で /claude-api prompt-audit を実行すると、スキルや CLAUDE.md ファイルなど、Claude Code の設定にこうしたプロンプト作成上のアンチパターンが含まれていないかを確認できます。また、Claude Platform 上で構築したアプリのコードもチェックされます。

この検証は、Opus 4.8 から Opus 5.5 への移行において、プロンプトにこれらのパターンのいくつかが含まれる 44 件のチケットからなる社内カスタマーサポートのベンチマークを用いて実施しました。Opus 5.5 への移行により、わずかな労力で、ベンチマークのコストを約 18% 削減できました。 さらに「prompt-audit」を実行した結果、コストはさらに9%削減され、Opus 4.8の開始時点と比較して約25%低くなりました。この監査により、モデルによる記述量を増やしたりツール呼び出しを繰り返させたりしていた定型的な指示が削除されました。具体的には、必須の6段階の手順、スクラッチパッドに関するルール、2回確認するルール、および互いに矛盾する指示などです。

この結果は1つのベンチマークに基づくものであるため、期待値としてではなく、あくまで一例として捉えてください。監査を実行した後、実際のタスクにおける /usage を前後で比較してください（「ご自身で測定する」を参照）。

キャッシュとコンパクション

Claude Code キャッシュとコンパクションを自動的に処理します。セッションの実行方法によって、節約できる容量が決まります。

キャッシュの仕組み

Claude Code システムプロンプト、ツールの定義、これまでの会話内容など、リクエストの中で繰り返し出現する部分をキャッシュします。

Opus 5.5 では、キャッシュからの読み取りにかかるコストは、新規入力トークンの 5% です。キャッシュへの書き込みは、新規読み取りよりもコストが高く、現在の価格設定では、5 分間のキャッシュの場合は入力価格の 1.25 倍、1 時間のキャッシュの場合は入力価格の 2 倍となります。ヒットするたびに、有効期間は無料でリセットされます。

Claude Code では、有効期間は支払い方法によって異なります。Claudeのサブスクリプションの場合は1時間です。APIキーまたはクラウドプロバイダーを利用する場合は、デフォルトで5分間となり、サブスクリプションでも利用クレジットが消費され始めると、有効期間は5分間に短縮されます。

コンテキストが 120K トークンの場合、Opus5.5 での 5 分間の書き込みにかかる費用は約 0.60 ドル、読み取りは約 0.02 ドルです。1 回の書き込みにかかる費用は、25 回の読み取りに相当します。 APIキーを使用する場合、6分間のコーヒーブレイクを取ると、次の0.02ドルの読み取り操作が0.60ドルの書き込み操作に変わります。同じサイズの書き込みを1時間行うと約0.96ドルの費用がかかりますが、APIではそのプレミアムを支払うことで、1日の中の空き時間を埋めることができます。

セッションの形状とヒット率

キャッシュにはプレフィックスが保存されるため、リクエストのうち、先頭から以前のリクエストと一致する部分のみを再利用することができます。

安定したセッションでは、ターンごとに会話の末尾に内容が追加され、ヒット率が高水準に保たれます。リクエストの初期部分に変更が加わると、ヒット率は低下します。ツールの定義を変更するとキャッシュ全体がクリアされ、システムプロンプトを変更すると、その時点以降についてはキャッシュがクリアされますが、これは事実上すべてに当てはまります。

実際には、次のような場合にキャッシュへの書き込みが行われると予想されます：

• キャッシュの有効期間よりも長く一時停止すると、
• Amazon Bedrock、Google Cloudのエージェントプラットフォーム、またはゲートウェイ上で、キャッシュの照合条件の一部となるレベルを変更します。
• 会話の中で初めて「高速モード」を有効にすると、キャッシュの一致対象の一部が変更されます。
• MCPサーバーへの接続を確立または切断すると、各リクエストの開始時に読み込まれる内容が変更される場合があります。
• 新しいモデルではキャッシュが空の状態から始まるため、モデルを切り替えます。そして、
• 会話が圧縮されることで、キャッシュに一致した履歴が書き換えられます。

セッションが始まったらこれらを設定し、動作中はそのままにしておいてください。

なぜ長時間のセッションは1ターンあたりのコストが高くなるのか

ターンごとにコンテキスト全体が再送信されるため、キャッシュが温まっている場合でも、コンテキストが大きくなるにつれて1ターンのコストは高くなります。 Opus 5.5 において、コンテキストが 20K トークンの場合、1ターンあたりのキャッシュ読み取りコストは約 $0.004 です。150K の場合、コストは約 $0.03 となり、このサイズで 30 ターン実行すると、読み取りだけで $0.90 かかります。 一方、コンテキストが20Kトークンの場合の同じ30ターンでは、コストは約$0.12となります。Claude 4.6以降のモデルでは、コンテキストウィンドウが大きくなってもトークンあたりの価格は変わらないため、コストはすべて会話の再送信によるものです。

そのコンテキストの多くは、以前の作業の名残です。1時間前のスタックトレース、すでに処理を終えたファイル、すでに修正済みのテスト実行の結果などです。それらはすべて、ターンごとに依然として送信され続けています。

Compaction、/compact、および /clear

セッションのコンテキスト制限に近づくと、Claude Codeは古い履歴を要約し、その後の送信量を減らします。この処理が行われるまでのコンテキストの満杯度を変更するには、トークン数を指定して /autocompact を実行してください。

これを実行するには、2つのコマンドがあります。/clear は会話履歴を消去し、コストはかかりません。関連のない作業に移る際に使用してください。/compact は会話の流れを維持し、1リクエスト分のコストがかかります。このコマンドは要約対象の会話履歴を読み込みますが、残すべき内容を指定することも可能です。例えば、「/compact keep the failing test names and the schema change」と入力すると、失敗したテスト名とスキーマの変更内容を残すことができます。

15万トークンのコンパクションにかかるおおよそのコストは、約0.25ドルです。これには、読み取り操作、数千個の出力トークンの要約、およびより短いコンテキストへの新しいキャッシュ書き込みが含まれます。その後の各ターンで読み取りコストが約0.025ドル節約されるため、コンパクションの費用はおよそ10ターン以内に回収できます。 終了直前のコンパクションは、節約できるコストよりもコストがかかってしまいます。

この価格は、キャッシュが「ウォーム」な状態であることを前提としています。キャッシュがウォームな状態では、サマリーリクエストはそのキャッシュから会話を読み取るため、休憩前の状態が読み込まれ、休憩後の状態は読み込まれません。キャッシュの有効期間を超える休憩があった後、同じ /compact コマンドを実行すると、会話全体が再度読み込まれ、キャッシュに書き戻されます。 5分間のキャッシュで15万トークンの場合、入力だけでも約0.75ドルかかります。もし、進んだ経路を破棄したい場合は、代わりに /rewind コマンドを使って以前のターンに戻ってください。キャッシュがウォームな状態であれば、その操作により、すでにキャッシュされているプレフィックスに戻ることができます。

要約では詳細も失われてしまいます。デバッグセッションの途中でコンパクションが行われると、重要なログ行が1行だけ抜け落ちてしまう可能性があります。自然な区切りでコンパクションを行い、次のステップが特定の事項に依存する場合は、/compact 命令でその旨を明記してください。

入力する前に読み込まれるもの

CLAUDE.mdファイルは、セッションの開始時にコンテキストに読み込まれるため、その中の各行は、すべてのターンで再送信される内容の一部となります。 コストに関するドキュメントでは、200行以内に抑えることが推奨されています。MCPのツール定義は遅延読み込みされます。開始時にはツール名とサーバーへの指示のみが読み込まれ、そのツールが使用された際に完全な定義が読み込まれます。/mcpを実行して接続中のサーバーを確認し、使用していないサーバーはオフにしてください。

法案の残りの部分

この表には、Claude Codeセッションに影響を与えるその他の課金ルールが記載されており、ドキュメントが存在する場合はそのリンクも併記されています。

高速モードでは、Opus 5.5 の処理速度が最大 2.5 倍に向上しますが、標準価格の 2 倍の料金がかかります。入力トークン 100 万件あたり 8 ドル、出力トークン 100 万件あたり 40 ドルです。 Claudeのサブスクリプションでは、この機能の利用料はプランの制限枠ではなく、使用クレジットから請求されます。有効化後の最初のリクエストでは、キャッシュされていない状態の会話全体に対して、高速モードの入力料金が適用されます。そのため、セッションの途中ではなく、開始時に有効化するようにしてください。

自分で測ってみよう

この記事の数値はあくまで参考例です。皆さんのコードベースやプロンプト、作業習慣はそれぞれ異なるため、ご自身のタスクに合わせてコストを測定してください。確認方法は以下の通りです。

1. セッション内で、/usage を実行してください。/cost でも同様の操作が可能です。セッションブロックには、トークンの使用量と、定価に基づく推定費用（ドル）が表示されます。 「prompt-cache」行には、入力内容のどれだけがキャッシュから取得されたかが表示されます。Pro、Max、Team、またはEnterpriseプランでは、同じ画面にプランごとの使用状況バーが表示されます。金額は、お使いのマシン上で定価に基づいて計算されるため、サブスクリプションプランでは、これは請求額ではなく、どれだけの作業を行ったかの目安となります。
2. 同じタスクを2回実行してください。Opus 5.5では、Claude Code v2.1.280以降が必要ですので、まず claude update を実行してください。単純なサンプルではなく、バックログから何かを選んでください。/model オプションを使用して、Opus 5 と Opus 5.5 を切り替えてください。各実行のターン数、出力トークン、コストを記録してください。結論を出す前に、3～4つのタスクを実行してください。
3. チーム単位で分析する場合は、利用状況およびコストレポートを活用してください。Claude Code Analytics API では、ユーザーあたりの推定コストが提供されます。Usage and Cost API では、支出がモデル別、およびキャッシュ済みトークンとキャッシュなしトークン別に内訳表示されます。
4. 「努力のラダー」を試してみてください。難しいタスクを1つ、まず「中」のレベルで、次に「高」のレベルで実行します。そして、単純なタスクを1つ、「低」のレベルで実行します。

セッションの読み取り

タスクの終了時に、/usage で以下の3点を確認してください。

• キャッシュシェア。セッションが長期間にわたる場合は、この値は高くなるはずです。値が低い場合は、長時間の休止、モデルの切り替え、セッションの途中でMCPサーバーが接続されたこと、あるいはクラウドプロバイダーやゲートウェイにおける処理負荷の変化などを確認してください。プロンプトのキャッシュ行には、多くの場合、直近のミス（キャッシュミス）の考えられる原因が示されています。
• 入力に対する出力。わずかな変化に対して出力が多すぎる場合は、通常、そのタスクに対して労力が過剰であるか、モデルが再試行を行っていることを意味します。
• 会話の規模に対する入力総量。入力総量が会話の規模の何倍にも及ぶ場合、そのセッションでは多くのやり取りが行われており、どこでループが繰り返されたのかを確認するために、その会話内容を読む価値がある。

参考として、『Claude Code』のコストに関する資料によると、エンタープライズ導入事例の平均コストは、開発者1人あたりアクティブデー1日につき約13ドルであり、ユーザーの90％についてはアクティブデー1日あたり30ドル未満となっています。通常のレベルを大幅に上回るコストが発生しているセッションについては、見直す価値があります。

ご留意ください

• 範囲が明確に定められた日常業務には、中程度の労力を費やしてください。
• モデルが自身の処理結果を確認できる仕組みを用意し、プランモードで複数のファイルにまたがる変更を開始できるようにします。
• 「中」の状態が停滞したら、負荷を「高」に上げてください。APIキーまたはサブスクリプションを利用している場合、この変更後もキャッシュは保持されます。クラウドプロバイダーやゲートウェイでは、処理の合間に変更を行ってください。
• もし xhigh で同じ問題が 2 回発生した場合は、Fable5.1 に切り替えてください。問題が解決したら、元に戻してください。
• 検索およびログ読み取りのサブエージェントは、Sonnet または Haiku に配置してください。コードの編集は Opus 5.5 で行ってください。
• 長いセッションを継続させて、キャッシュが温まった状態を保つようにします。
• 関連性のないタスクの間には「/clear」を使用し、休憩時には「/compact」を実行して、何を残すべきかをメモしておきましょう。
• 最も重要なのは、各モデルで実際のタスクを1つ実行し、`/usage`が報告する内容を比較することです。信頼すべきは、ご自身で得た数値です。

この記事がお役に立てば幸いです。もし、Opus 5.5 での制限が Opus 5 よりも厳しくなっている場合は、/feedback でご連絡ください。

関連情報：コストの効果的な管理 · モデルの構成 · 『Claude Code』におけるClaudeモデルの選択と工数レベルの決定 · 工数 · プロンプトのキャッシュ · Claude Codeセッションの価値を最大限に引き出す

マイケル・セグナー氏、ケイシー・ジェンキンス氏、モリー・ヴォルウェルク氏に、レビューをしていただいたことに感謝いたします。