Claude Opus 4.8でトークンが増える理由 — 対話型コーディングでの抑え方
Claude Opus 4.8は、ユーザーのターンが何度も挟まる対話型コーディングでトークンを多く使います。増える理由と、effortの選び方・最初のターンの書き方・auto modeによる抑え方を解説します。
対話するほどトークンが増えるのは、ユーザーのターンの後で考え直すから
Claude Opus 4.8は、ユーザーのターンが1回だけの非同期なコーディングエージェントより、ターンが何度も続く同期型の対話セッションでトークンを多く使います。理由はプロンプトガイドの「Interactive coding products」節に1行で書かれています。ユーザーのターンの後で、より多く推論するためです。
増えた分は無駄ではありません。この推論は、長い対話セッションでの一貫性・指示への追従・コーディング能力を高めます。つまり性能とトークン消費が同じ原因から出ています。
ここで押さえたいのは、抑える対象がモデルの癖そのものではなく、ユーザーのターンの回数と、各ターンの曖昧さだという点です。
単発タスクと対話セッションでの違い
使い方は、ユーザーのターンの数で大きく2つに分かれます。
| 使い方 | ユーザーのターン | トークンの傾向 |
|---|---|---|
| 自律・非同期のコーディングエージェント | ユーザーのターン1回 | トークンの傾向推論はタスク本体に集中する |
| 対話・同期のコーディングエージェント | ユーザーのターン複数回 | トークンの傾向ターンごとに再び推論するため、多くなりやすい |
プロンプトガイドの該当節には、増加率の数値が載っていません。自分の環境で同じタスクを単発と対話で流し、トークン量を比べるのが確実です。
Opus 4.8は従来のモデルより自律的に動きます。曖昧な指示を複数のターンに分けて伝えると、トークン効率が相対的に落ち、性能が落ちることもあります。
同じ作業でも、伝え方で消費が変わる
小出しに伝える
最初は「ログイン機能を直して」だけ。エラーの内容、触ってよい範囲、テストの有無は、Claudeが動き始めてから1つずつ補う。
最初にまとめて伝える
最初のターンで、タスク・意図・制約を書き切る。以降のターンは確認と微調整だけで済む。
抑える3つの手段
抑える手段は3点です。effortをxhighかhighにする、auto modeのような自律機能を足す、人に求める操作の回数を減らす。
effortはxhighかhighに置く
effortはトークン消費と知能を引き換えにする設定で、Opus 4.8ではlowからmaxまでの5段階を選べます。コーディングやエージェント用途の出発点はxhigh、ほとんどの知的作業ではhigh以上が目安です。maxは伸びが鈍る場面があり、考えすぎることもあります。
| effort | 位置づけ |
|---|---|
high | 位置づけ知能とトークン消費のバランスが取れた設定。多くの場合で品質と効率の釣り合いが最もよい |
xhigh | 位置づけコーディングとエージェント作業の出発点。ツールの繰り返し呼び出しや詳細な検索のような探索的な作業に向く。highより、トークン使用量が大きく増える |
「抑えたいからlow」と飛びつくのは危険です。Opus 4.8はeffortを厳密に守り、lowとmediumでは頼まれた範囲に作業を絞ります。中程度に複雑なタスクをlowで流すと、考えが浅くなるおそれがあります。浅さが見えたら、プロンプトで補う前にeffortをhighかxhighへ上げるのが先です。
xhighかmaxで動かすときは、出力トークンの上限を大きく取ります。64kから始めて調整する案があります。
下の段階は、effortのページに載る一般的な位置づけで見ておくと迷いません。mediumは中程度のトークン節約になる釣り合い型で、速度・コスト・性能のバランスが要るエージェント作業に向きます。lowはもっとも効率的な設定です。トークンを大きく減らせる代わりに能力は多少落ち、サブエージェントのような単純な作業が想定されています。Opus 4.8の指針は、mediumやlowへ下げるのは、自分の評価で品質が保てると測れてからに限っています。対話型のトークン増を理由に、測らないまま一段下げるのは順序が逆です。
ここで注意したいのは、対話によるトークン増を抑える目的でxhighを選ぶと、別の経路で消費が増えることです。品質より消費を優先する運用ならhigh、長く自走させる作業ならxhighが目安になります。API直接の呼び出しでは、effortを指定しないと既定のhighで動きます。
Claude Codeでの切り替え
Claude Codeでは/effortで切り替えられ、起動時の--effortと環境変数CLAUDE_CODE_EFFORT_LEVELも同じ役割です。明示的な指定がなければ、保存した設定を経て、モデルの既定値に落ち着きます。Opus 4.8の既定はhighです。
claude --model opus --effort xhighセッション中は/effortのスライダーで変えます。レベルを選んでEnterを押すと既定として保存され、sを押すとそのセッションだけに適用されます。後者はClaude Code v2.1.257以降の機能です。
effortの段階ごとの使い分けは、Terminal-Bench 3.0で見るeffortの効き方で数値と合わせて見られます。maxを選ぶと出る警告はmax effortの3.5倍警告の対処にまとめています。
承認の回数を減らす
対話型でターンが増える大きな原因は、人が毎回確認を挟むことです。Claude Codeのauto modeは、確認の代わりに別のモデル（分類器）が操作を審査する仕組みで、ユーザーへの確認を減らせます。
auto modeはClaude Code v2.1.283以降、対話型のターミナルとVS Codeでの標準の開始モードです。それより前の版では、Pro・Max・Teamプランに限られます。分類器は、頼んだ範囲を超える操作、見覚えのないインフラへの操作、Claudeが読んだ内容に仕込まれた敵意ある指示に従っていそうな操作を、実行前に止めます。明示した確認ルール（askルール）は、auto modeでも確認が出ます。承認の手間は減りますが、安全側の止め方は残ります。実行中はShift+Tabでモードを切り替えます。対応するモデルが必要で、組織側で無効にされることもあります。
最初のターンに書くもの
最初の人間のターンで、タスク・意図・関連する制約を指定します。整った明確な依頼を先に渡すと、自律性と知能を引き出しつつ、ターン後の余計なトークンを減らせます。
この3要素を、コーディングの依頼に当てはめた例です。公式が示す文面ではなく、3要素を満たすための一例です。
## タスク
注文一覧APIのページネーションを、offset方式からカーソル方式に変える。
## 意図
件数が増えると末尾ページで応答が遅くなるため。UIの見た目は変えない。
## 制約
- 変更してよいのは src/api/orders/ と対応するテストだけ
- 既存のレスポンス形式のフィールド名は変えない
- テストは npm test -- orders で通す。通るまで自分で直す
- 判断に迷う点は、実装を止めずに最後にまとめて報告する最後の1行が効きます。途中で質問して止まる代わりに、判断を終了時にまとめさせると、ターンが増えません。
依頼文の組み替え
曖昧な依頼
注文APIが遅いので速くして。
3要素を先に渡す
目的（末尾ページの遅延解消）、範囲（src/api/orders/のみ）、完了条件（npm test -- ordersが通る）を最初のターンに書く。
繰り返し使う制約は、毎回のプロンプトではなくCLAUDE.mdに置くと、最初のターンを短く保てます。プロンプトの書き方の発想は、Opus 4.8のデザイン既定値を上書きする方法にも通じます。否定形で止めるのではなく、選ぶ範囲を渡す点が共通です。
文面で細かく調整するとき
Opus 4.8は指示を文字どおりに解釈し、ある項目への指示を別の項目へ勝手に広げません。適用範囲は明示します。「この書式を最初の節だけでなく、すべての節に適用して」という書き方が使えます。
出力が長すぎる場合は、次の一文を足す案があります。
Provide concise, focused responses. Skip non-essential context, and keep examples minimal.避けたい行為を並べるより、望ましい簡潔さの実例を見せるほうが効きやすいです。
考える頻度が高すぎると感じるときは、思考をいつ使うかを文で指定できます。たとえば「思考は遅延を増やす。複数手順の推論が必要なときだけ使い、迷ったら直接答える」という趣旨の指示です。なお、Opus 4.8ではthinking: {type: "adaptive"}を明示しない限り思考はオフで、大きなシステムプロンプトでは思考が増えることがあります。
進捗報告を強いる指示は外せる
対話型のプロンプトには、途中経過を引き出すための足場が入りがちです。「ツールを3回呼ぶたびに進捗を要約して」のような指示がその例です。
Opus 4.8は、長いエージェント処理の途中でも、より定期的で質の高い報告をユーザーに返します。こうした足場は、外して試せます。報告の長さや中身が用途に合わないときは、どんな報告にしたいかを文で説明し、例を添えます。
足場を外すと、強制された要約の出力が減ります。ただし減る量はプロンプトガイドに書かれていないため、外す前後で同じタスクのトークンを比べて確かめます。
ツールの使い方にも傾向があります。Opus 4.8はツール呼び出しより推論を優先しやすく、effortをhighやxhighにすると、検索やコーディングでツールの利用が目に見えて増えます。ツールを使ってほしい場面は、いつ・どう使うかをプロンプトに明記します。
よくある質問
対話型でも、途中で方針を変えたいときはどうしますか
ターンを足すこと自体は問題ではありません。効率を下げやすいのは、曖昧で情報不足の指示が複数のターンに分けて少しずつ伝わるパターンです。方針変更は、変更点と理由を1回で書き切ります。
auto modeが使えない環境では何を減らせますか
auto modeは、対応モデルが必要で、組織の設定で無効にされることもあります。使えない場合でも、最初のターンの具体化は効きます。コードを読んで調べる段階だけを切り出したいなら、Shift+Tabで切り替えられるplanモードがあります。コードベースを変更前に調べる用途のモードなので、調査結果を踏まえて、タスク・意図・制約を書き直してから実装に進めます。
まとめ
対話型で増える分は、ユーザーのターンごとの再推論に由来します。抑える鍵は、effortをlowへ落とすことではなく、最初のターンにタスク・意図・制約を書き切り、確認の回数を減らすことです。まず同じ依頼を「小出し」と「まとめて」で流し、トークン量の差を自分の環境で測ると、効果が分かります。