Claude Codeのコスト最適化ガイド|トークン節約の実践【2026】

Claude Codeの利用コスト・トークン消費を品質を落とさず抑える実践手法を開発者向けに解説。使用量の見える化、コンテキスト管理、モデル選択、プロンプトキャッシュ活用まで2026年6月時点の公式仕様で整理します。

Claude Codeのコスト最適化ガイド|トークン節約の実践【2026】

Claude Codeのコスト最適化ガイド|トークン節約の実践【2026】

結論:Claude Code のコストは「コンテキスト(文脈)に何トークン載せているか」でほぼ決まる。だから品質を落とさずにコストを下げる王道は、コンテキストを小さく保つこと——具体的には ①使用量を /usage/context で見える化し、②不要な文脈を /clear/compact で捨て、③CLAUDE.md とモデル設定を最適化し、④冗長な処理をサブエージェントに逃がすことだ。

  • 要点1:コストはトークン消費に比例し、トークンはコンテキストサイズに比例する。「タスクが終わったら文脈を捨てる」が最も効く。
  • 要点2:Claude Code はプロンプトキャッシュを自動で効かせる。読み込み(キャッシュヒット)は通常入力の約10%のレートで課金されるので、キャッシュを壊さない使い方が安い。
  • 要点3:モデル選択(Sonnet 基本・Opus は要所)、拡張思考の調整、サブエージェントへの逃がし、で per-message コストをさらに削れる。

対象読者:Claude Code を日常的に使う開発者・エンジニア・PM。チームへの導入を検討していて「1人あたりのコストが読めない」「思ったより高い」と感じている人。
今日やること:まず /usage で現状を測り、/context で何がコンテキストを食っているか確認し、次の作業に移る前に /clear を打つ習慣をつける。

正直、Claude Code を使い始めて最初に面食らうのが「同じような作業をしているのに、日によってトークンの減り方が全然違う」という現象です。原因はだいたい決まっていて、長い会話を /clear せずに引きずっていたり、巨大な CLAUDE.md を毎セッション読ませていたり、MCP サーバーを大量に繋ぎっぱなしにしていたり——要するに「使っていない文脈にお金を払っている」状態なんです。

この記事では、Claude Code 公式ドキュメント(2026年6月時点)の仕様にもとづいて、品質を落とさずにコスト・トークンを抑える実践手法を、現場で実際に効いた順に並べていきます。コマンド名や挙動はすべて公式で裏取りしたものだけを載せています。

Claude Codeのトークンを節約する5つのレバー。①使用量の見える化(/usage)②コンテキスト管理(/compact・/clear)③CLAUDE.mdを小さく保つ④モデル選択を使い分け⑤プロンプトキャッシュ活用。
トークンを節約する5つのレバー(使用量可視化・文脈管理・CLAUDE.md圧縮・モデル選択・キャッシュ)

まず公式の前提:Claude Code のコストは何で決まるか

Claude Code は API トークン消費に対して課金されます(Pro / Max / Team / Enterprise などサブスクプランは別建てで、プラン内に使用量が含まれます)。公式ドキュメントによれば、エンタープライズ導入での平均は 開発者1人あたり1稼働日あたり約13ドル、月あたり150〜250ドル。そして全体の90%のユーザーは1日あたり30ドル未満に収まっています。

ここで重要なのは、コストが「コードベースの大きさ」「モデル選択」「複数インスタンスや自動化を回しているか」といった使い方のパターンで大きくブレるという点です。逆に言えば、使い方を整えればコストはコントロールできます。本記事のテーマはまさにそこです。

そして最重要の原則がこれです——トークンコストはコンテキストサイズに比例する。Claude がより多くの文脈を処理するほど、より多くのトークンを使う。だから「コンテキストを小さく保つ」がすべての施策の土台になります。

ステップ1:使用量を見える化する(/usage・/context・ステータスライン)

節約はまず計測から。何にトークンを使っているか分からないまま削っても、品質だけ落ちて効果が出ません。Claude Code には、セッション中に使用量を確認する手段が用意されています。

  1. /usage を実行する:現在のセッションのトークン使用量・概算コスト・API実行時間などが表示されます。Pro / Max / Team / Enterprise プランでは、プラン上限に対する内訳(スキル・サブエージェント・プラグイン・MCP サーバーごとの割合)も出ます。d / w キーで直近24時間/7日間を切り替えられます。
  2. 表示される金額の意味を理解する:セッションのドル表示はローカルのトークン数から概算したもので、実際の請求とは差が出ます。正確な請求は Claude Console の Usage ページで確認します(サブスク勢は金額より「プラン使用量バー」を見れば十分)。
  3. /context で内訳を見る:いま何がコンテキストを食っているかを表示します。CLAUDE.md・MCP のツール定義・読み込んだファイルなど、削るべき対象がここで見えます。
  4. ステータスラインに常時表示する:毎回 /usage を打たなくても、ステータスラインを設定すればコンテキスト使用量を画面に常時表示できます。「いまどれくらい食っているか」が常に視界に入ると、自然と /clear の判断が早くなります。

チーム導入なら、API 利用時に ワークスペースの支出上限を設定できます。Pro / Max プランでは /usage-credits コマンドで使用クレジットの月間上限を設定でき、上限に達すると CLI 内で上限引き上げ/解除を促されます(変更には課金権限が必要)。

ステップ2:コンテキストを能動的に管理する(/clear・/compact)

ここが一番効きます。古い文脈は、その後のメッセージすべてで毎回トークンを消費し続けるからです。公式も「stale context wastes tokens on every subsequent message(古い文脈は後続の全メッセージでトークンを浪費する)」と明記しています。

  1. タスクが切り替わったら /clear:無関係な作業に移るときは /clear で文脈をリセットします。あとで戻りたいセッションは、/clear の前に /rename で名前を付けておき、/resume で復帰できます。
  2. 長い会話の途中で /compact:会話履歴を要約に置き換えてコンテキストを圧縮します。/compact に指示を添えて何を残すか伝えられます。例:
/compact Focus on code samples and API usage

毎回同じ方針で圧縮させたいなら、CLAUDE.md に圧縮指示を書いておけます。

# Compact instructions

When you are using compact, please focus on test output and code changes

ひとつ注意。/compact は「タスクの自然な切れ目」で手動で打つのがコツです。自動圧縮(auto-compaction)がタスクの途中で発動すると、必要な文脈まで要約されてやり直しが発生することがあります。方針を完全に間違えて引き返したいときは、/compact ではなく /rewind(または Escape の2回押し)で以前のチェックポイントに戻すほうが、キャッシュ的にも安く済みます。

ステップ3:プロンプトキャッシュを壊さない使い方をする

Claude Code はプロンプトキャッシュを自動で効かせます。会話を続けるたびに、前回処理した部分(システムプロンプト・プロジェクト文脈・過去のやりとり)を再利用し、新しく追加された分だけを処理する仕組みです。キャッシュから読み出されたトークン(cache_read_input_tokens)は通常入力レートの約10%で課金されるので、キャッシュが効いているほど安くなります。

逆に言えば、キャッシュを無効化する操作をセッション途中で繰り返すと、その都度「遅くて高い1ターン」が発生します。公式が挙げる主なキャッシュ無効化トリガーは次の通りです。

  • モデルの切り替え/model):モデルごとに別キャッシュなので、内容が同じでも全履歴を読み直します。
  • 努力レベルの変更/effort):これもキャッシュキーの一部です。
  • MCP サーバーの接続/切断(ツールがプレフィックスに載っている場合)。
  • 会話の圧縮/compact):会話レイヤーを意図的に作り直します。
  • Claude Code 本体のアップグレード:システムプロンプトが更新されるため。

対策はシンプルです。モデルと努力レベルはセッション冒頭で決め、/compact はタスクの自然な切れ目に取っておく。途中での変更が少ないほどキャッシュヒット率が上がります。

キャッシュの寿命(TTL)も把握しておくと得です。サブスクではキャッシュが自動で1時間 TTLを使うため、少し離席してもキャッシュが温まったまま(プラン内なので追加費用なし)。API キーや第三者プロバイダ経由では従量課金のためデフォルト5分 TTLで、長い休憩を挟むと次のターンが重くなります。1時間 TTL に切り替えたい場合は ENABLE_PROMPT_CACHING_1H=1 を設定します。

キャッシュが効いているかは、ステータスラインスクリプトで cache_read_input_tokens(キャッシュから読んだ量)と cache_creation_input_tokens(書き込んだ量)を見れば分かります。read が多く creation が少ない=キャッシュが良く効いている状態です。creation が毎ターン高止まりしているなら、プレフィックスのどこかが毎回変わっているサインです。

ステップ4:CLAUDE.md と出力を小さく保つ

CLAUDE.md はセッション開始時にコンテキストへ読み込まれ、以降ずっと載り続けます。つまり、無関係な作業をしているときも、その分のトークンを払い続けるということです。公式の指針は明快で、CLAUDE.md は200行以内に抑え、本質的なものだけを入れる

  1. 特定ワークフロー用の詳細手順はスキルへ逃がす:PR レビューやDBマイグレーションのような「使うときだけ要る」手順は、CLAUDE.md ではなくスキルに移します。スキルは呼び出されたときだけオンデマンドで読み込まれるので、ベースのコンテキストが小さくなります。
  2. CLAUDE.md は「常に効くべき最小ルール」だけにする:コーディング規約、絶対に守らせたい禁止事項、プロジェクト構成の要点など。
  3. 出力(=生成トークン)も意識する:プロンプトを具体的にすると、Claude が余計な探索や長文出力をしなくなります(次のステップ)。

補足として、CLAUDE.md の編集はセッション途中だと反映されません(キャッシュを壊さない代わりに、読み込みは次の /clear/compact・再起動まで持ち越されます)。編集したら一度リフレッシュする、と覚えておくと混乱しません。

ステップ5:モデル選択と拡張思考を調整する

同じタスクでも、どのモデル・どの努力レベルで走らせるかでコストは変わります。

  • 基本は Sonnet:ほとんどのコーディング作業を十分こなし、Opus より安いです。Opus は「複雑なアーキテクチャ判断」「多段の推論」が要るときに温存します。/model でセッション途中に切り替え、/config でデフォルトを設定できます。
  • 単純なサブエージェントには Haiku:サブエージェント設定で model: haiku を指定すれば、軽い処理を安いモデルに任せられます。
  • 拡張思考(Extended thinking)を下げる:拡張思考はデフォルトで有効で、複雑な計画・推論では性能を大きく上げますが、思考トークンは出力トークンとして課金され、デフォルト予算はリクエストあたり数万トークンに達することもあります。深い推論が不要な単純作業では、/effort/config で努力レベルを下げる、あるいは MAX_THINKING_TOKENS=8000 で予算を絞ると節約できます。
# 拡張思考の予算を絞る例(環境変数)
export MAX_THINKING_TOKENS=8000

ただし努力レベルやモデルのセッション途中での変更はキャッシュを壊す点に注意(ステップ3参照)。だからこそ「冒頭で決める」が効きます。

ステップ6:冗長な処理をサブエージェント・ヘッドレス・フックに逃がす

テスト実行、ドキュメント取得、ログ解析のような「大量の出力が出るが、結論だけ要る」作業は、メインの会話に全部流し込むとコンテキストを一気に食います。これらは外に逃がすのが定石です。

  1. サブエージェントに委譲するサブエージェントは自分専用のコンテキストを持つので、冗長な出力はサブエージェント側に留まり、メイン会話には要約だけが返ります。親のコンテキスト(=親のキャッシュ)は汚れません。
  2. フックで前処理する:フックは Claude が見る前にデータを加工できます。例えば「1万行のログを Claude に読ませる」代わりに、フックで ERROR 行だけ grep して返せば、数万トークン → 数百トークンに圧縮できます。
  3. MCP のオーバーヘッドを減らす:MCP ツール定義はデフォルトで遅延読み込み(deferred)ですが、使っていないサーバーは /mcp で無効化します。gh / aws / gcloud のような CLI ツールはツール一覧をコンテキストに足さないぶん、MCP より context 効率が良いことも多いです。
  4. 具体的なプロンプトを書く:「このコードベースを改善して」のような曖昧な依頼は広範なスキャンを誘発します。「auth.ts の login 関数に入力バリデーションを追加して」のように具体的に書くと、最小限のファイル読み込みで済みます。

テスト出力をフックで失敗行だけに絞る最小例(公式パターンを簡略化):

#!/bin/bash
# PreToolUse フックでテスト出力を失敗だけに絞る
input=$(cat)
cmd=$(echo "$input" | jq -r '.tool_input.command')

if [[ "$cmd" =~ ^(npm test|pytest|go test) ]]; then
  filtered="$cmd 2>&1 | grep -A 5 -E '(FAIL|ERROR|error:)' | head -100"
  echo "{\"hookSpecificOutput\":{\"hookEventName\":\"PreToolUse\",\"permissionDecision\":\"allow\",\"updatedInput\":{\"command\":\"$filtered\"}}}"
else
  echo "{}"
fi

ステップ7:複雑なタスクの「やり直しコスト」を防ぐ

意外と見落とされがちですが、間違った方向に進んでしまったときの手戻りが、地味に一番トークンを溶かします。長尺・複雑な作業では、次の習慣でムダな消費を防げます。

  • 複雑なタスクはプランモードから:Shift+Tab でプランモードに入り、Claude にコードベースを探索させて方針を提案させ、承認してから実装に入ります。初手の方向が間違っていたときの高くつく作り直しを防げます。
  • 早めに軌道修正する:おかしな方向に進み始めたら Escape で即停止。/rewind や Escape 2回押しで会話とコードを以前のチェックポイントに戻せます。
  • 検証ターゲットを与える:テストケースを渡す、スクリーンショットを貼る、期待出力を書く。Claude が自分で検証できれば、修正依頼の往復が減ります。
  • 小さく刻んでテストする:1ファイル書く → テスト → 続行。問題を「直すのが安いうち」に見つけられます。

チーム導入時のコスト管理とエージェントチームの注意

個人利用の最適化に加えて、チームで使うなら次の2点を押さえておくと事故りません。

レートリミット設計:公式は組織規模に応じた1人あたり TPM(Token Per Minute)の目安を出しています。1〜5人なら 200k〜300k TPM、20〜50人なら 50k〜75k TPM、というように、規模が大きいほど同時利用率が下がるため1人あたりは小さくなります。これらは組織レベルで適用されるので、他の人が使っていないときは個人が一時的に多く使えます。

エージェントチームのコストエージェントチームは複数の Claude Code インスタンスを立ち上げ、それぞれが独立したコンテキストを持ちます。公式によれば、チームメイトがプランモードで動くと標準セッションの約7倍のトークンを使うことがあります。対策は「チームメイトは Sonnet」「チームは小さく」「スポーンプロンプトは絞る」「終わったら片付ける(アイドル中もトークンを消費する)」。なお、エージェントチームはデフォルト無効で、CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 で有効化します。

よくある失敗パターンと正しい型

最後に、現場で実際にコストを溶かしがちなパターンを、❌→⭕の形で整理します。

  • ❌ 1日中ひとつのセッションを /clear せず引きずる
    ⭕ タスクが切り替わるたびに /clear(戻りたいなら先に /rename
  • ❌ なんでもかんでも Opus で走らせる
    ⭕ 基本 Sonnet、Opus はアーキテクチャ判断など要所だけ。/config でデフォルトを Sonnet に
  • ❌ 巨大な CLAUDE.md に全ワークフローを書き込む
    ⭕ CLAUDE.md は200行以内、詳細手順はスキルへ移してオンデマンド読み込み
  • ❌ MCP サーバーを繋ぎっぱなし&作業中に頻繁にモデル切り替え
    ⭕ 使わない MCP は /mcp で無効化、モデル・努力レベルは冒頭で固定してキャッシュを温存
  • ❌ 1万行のログをそのまま Claude に読ませる
    ⭕ フックで失敗行だけに絞る、冗長処理はサブエージェントに逃がす

どれも「コンテキストを小さく保つ」という一本の原則に収束します。/usage/context で測りながら、この型を回せば、品質を落とさずにコストは着実に下がります。なお料金の具体額(プラン金額・API 単価)は変動するため、最新の数値は必ず公式・ご利用プランで確認してください。本記事の仕様は2026年6月時点のものです。

Claude Code の導入・運用設計を相談したい方へ

「コストの見える化はできたが、チーム全体でどう運用ルール化すればいいか」「CLAUDE.md やスキルの設計、権限・セキュリティ設定まで含めて整えたい」——こうした一段深い設計は、実装パターンを横断的に押さえると一気に楽になります。あわせて読みたい記事を置いておきます。

Uravation では、Claude Code の社内導入・コスト設計・運用ルール策定を含む個別指導・導入支援を提供しています。「自社のコスト構造に合わせて最適化したい」という方は、お気軽にご相談ください。

出典


著者:佐藤傑(さとう・すぐる) 株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援を手がける。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。

関連記事(Claude Code 実践ガイド)

Next Step

この事例を、自社の業務に置き換える。

対象業務、利用データ、評価基準、社内展開の順番まで整理すると、Claude Code導入の失敗を減らせます。

導入を相談する