Claude Codeのトークン消費を見直す｜エスカレート式のコスト管理

安い応答を重ねても、総コストが下がるとは限らない

軽い設定で何度も修正を頼んだ結果、最初から十分に考えてもらうより時間がかかることがあります。一方、表記の統一のような明確な仕事へ、毎回大がかりな調査を依頼する必要もありません。最初に分けたいのは「推論が難しい仕事」と「前提が足りない仕事」です。

仕様が抜けているのにモデルだけ変えても、違う推測が返ってくるだけかもしれません。入力を整理する、範囲を絞る、合否の基準を決める。それでも解けない部分に、より深い検討を使います。料金の考え方や使用量の確認は公式のコスト管理資料を参照してください。契約形態によって、表示される使用量と請求の関係は異なります。

計画は短くても、完成条件を省かない

元記事では、計画不足による作り直しを問題としていました。ここから実務に取り入れたいのは、すべての仕事で長い計画書を書くことではありません。どこまでできれば完成か、何を変更しないか、何を使って確認するかを先に決めることです。

問い合わせ一覧に、担当者で絞り込む機能を追加します。
既存の並び順と権限は変えません。
担当者なし・該当0件・読み込み失敗でも表示が崩れないことを確認します。
まず変更箇所と検証方法を示してください。

上の依頼は編集部の例です。Plan Modeを使えば処理が無料になる、という意味ではありません。調査や推論にも使用量は発生します。計画に使う手間と、作り直しを減らせる可能性を比較します。公式の実践ガイドも、仕事の大きさに応じて進め方を選ぶ参考になります。

失敗したら、同じ依頼をそのまま繰り返さない

1回目が失敗したら、まず原因を分類します。ファイルが見つからなかったのか、権限がなかったのか、仕様を誤解したのか、複雑な推論が必要なのか。この区別がないと、考える深さを上げても同じ場所で止まります。

第1段階：必要な材料だけで試す

対象のファイル、求める出力、検証方法を指定します。プロジェクト全体を読む必要がなければ、最初から全ファイルの調査を頼みません。ただし、影響範囲の確認が必要な変更では、読み込む範囲を狭め過ぎないようにします。

第2段階：不足している前提を補う

出力が違った理由を短く示します。「違います」だけでなく、「削除済みの顧客が集計に入っている。除外条件はこの仕様にある」と根拠を添えます。新しいモデルへ変える前に、正しい条件が渡っていたかを確認します。

第3段階：難しい部分へ検討を集中させる

条件をそろえても解けない場合に、使えるモデルや、どの程度深く考えさせるかを指定するeffort設定を見直します。すでに正しい部分まで作り直させず、未解決の問い、試した方法、否定された仮説を渡します。モデル名だけを固定した「軽い・中くらい・重い」の順序は、製品更新に合わせて見直す必要があります。

会話を短くするなら、再説明の手間も含めて考える

無関係な仕事を同じ会話へ積み重ねると、必要のない履歴が増えます。一方、細かく会話を分け過ぎると、同じ仕様やコードを何度も読み直すことになります。同じ機能の実装からテストへ進むなら続行し、別案件へ移るなら記録を保存して区切る、といった使い分けが現実的です。

繰り返す規則は、短く保ったCLAUDE.mdや必要な資料へ整理します。ファイルに書けば必ずすべての文脈が自動で読み込まれるわけではありません。公式のメモリ仕様に沿って、共通の規則と案件固有の記録を分けます。

削減率を出す前に、同じ完成条件で測る

「以前より安くなった」と判断するには、仕事の難しさと成果の品質をそろえる必要があります。簡単な案件だけを新方式で試し、難しい案件と比べても意味がありません。まず少数の同種の仕事で、実行に必要だった回数と人の確認を記録します。

こうして記録すれば、「常に軽くする」より「この種類の仕事だけ最初から深く考える」ほうがよい、といった判断ができます。単一の削減率より、自分の業務で再現できる条件を見つけることを優先します。

同条件で比べる記録例：同じCSVから同じ集計表を作る仕事で、試行ごとにモデル、effort、入力件数、開始時の会話条件、再試行回数、入力・キャッシュ入力・出力トークン、人の確認時間を残します。最終成果物が期待値に合った試行同士を比較し、失敗した試行の使用量も総量へ含めます。/usageの定価換算額は請求額とは別欄に置き、契約側の使用明細と混ぜないでください。キャッシュの有無が違えば、その条件差も記録します。

使用量と会話の占有率を、別々に確認する

現行の公式コスト管理ガイドでは、まず/usageで使用量を確認できます。Session欄の金額は推定値であり、請求書ではありません。定額プランの利用者は、契約の利用枠と、APIトークンから計算した金額を混同しないようにします。

/usage
/context

/contextは、いまの会話で何が文脈の枠を使っているかを見る入口です。長いツール出力が原因なら、その取得範囲を絞る余地があります。利用枠が減った理由と、会話が長くなった理由を同じ問題として扱わないことがポイントです。

モデルを変更する入口は/model、取り組む労力の設定は/effortです。選べる値や挙動はモデル・契約・環境によって異なるため、現在の選択画面で確認します。最初は標準設定で試し、必要な情報がそろっているのに解けないときは、モデルの能力や労力を見直します。

比較記録は「対象の変更／モデルとeffort／開始・終了時の使用量／再試行回数／合格した検証／人が直した内容」の6欄で残します。例えば入力チェックの修正なら、空欄・正常値・不正値を同じ条件で試し、やり直し分も含めます。数値の欄には実際の表示を転記し、合格条件を満たさない試行を「安く完成した」と数えません。

/clearで新しいセッションにすると現在の使用量集計もリセットされるため、区切る前に記録します。複数セッションの合計を比べる場合は、対象を明記して足し合わせてください。

よくある質問

Plan Modeならトークンは減りますか？

計画にも使用量はかかります。手戻りが減れば総量が下がる可能性はありますが、必ず削減できるとは限りません。

モデルを変えれば利用制限を回避できますか？

契約やモデルごとの制約があるため、回避を前提に運用しません。利用できる範囲で仕事の優先順位と実行方法を調整します。

まとめ：強いモデルを使う理由を、仕事ごとに持つ

エスカレート式は、能力を惜しむための方法ではありません。必要な場所へ検討を集中させる方法です。次の仕事では、完成条件、失敗の理由、全試行の結果を記録し、どの段階で設定を変えると役に立ったかを確かめてみてください。