Claude Code を本格的に使い始めると、必ず出てくるのが「思ったよりトークンを食っている」「上限にすぐ当たる」という悩みです。とはいえコストを気にするあまり effort を下げすぎたり、安いモデルに固定したりすると、今度は手戻りが増えて結局トータルでは高くつきます。
大事なのは、闇雲に節約することではなく、どこにコストがかかっているかを把握したうえで、効く場面に絞って効果レベルを上げ、それ以外を削ることです。この記事では、まず Claude Code の料金プラン（サブスクリプションと API 従量課金）の全体像を押さえたうえで、/usage でコストの内訳を可視化し、モデルと effort を場面ごとに使い分け、コンテキストを整理してトークンを減らす、という実務の流れを順に解説します。
Claude Code の料金プラン — サブスクリプションと API 従量課金
コストを最適化する前に、まず Claude Code の料金体系を押さえておきましょう。料金は大きく 2 つの課金方式に分かれます。月額固定の Claude サブスクリプション (Pro / Max) で使う方法と、使った分だけ支払う API の従量課金です。どちらを選ぶかで支払いの形がまったく変わります。具体的な金額は変動するため、契約前に必ず公式の料金ページで最新を確認してください (以下は 2026 年 6 月時点の公開情報)。
サブスクリプションで使う (個人・少人数向け)
Claude のサブスクリプションは、Claude Code とチャット版 Claude の両方を月額固定で使える方式です。使用量の上限は両者で共有され、Claude Code とチャットの利用が同じ上限に合算されます。
| プラン | 月額 | 概要 |
|---|---|---|
| Pro | 20 ドル (年払いなら月 17 ドル) | 個人で日常的に使う基本プラン。Claude Code を含む |
| Max | 100 ドルから | Pro の 5 倍、最大 20 倍まで使用量を選べる上位プラン |
| Team | 1 席 25 ドル (年払い 20 ドル) | チーム向け。上位の Premium 席は 1 席 125 ドル (年払い 100 ドル) |
公式ヘルプでは、サブスクリプションで Claude Code を使えるのは Pro・Max プラン (および Team・Enterprise) とされています。まず使い勝手を確かめたい個人なら Pro、上限にすぐ当たるヘビーユーザーなら Max が目安です。認証方式ごとの設定手順は Claude Code のインストールから初期設定まで完全手順 にまとめています。
API 従量課金で使う (チーム・CI・従量管理向け)
API キーを使う方式では、入出力したトークン量に応じて課金されます。CI やサーバー上で動かす、使用量を部門ごとに按分する、といった用途に向きます。主要モデルの料金は次のとおりです (100 万トークンあたり / 2026 年 6 月時点)。
| モデル | 入力 | 出力 |
|---|---|---|
| Opus 4.8 | 5 ドル | 25 ドル |
| Sonnet 4.6 | 3 ドル | 15 ドル |
| Haiku 4.5 | 1 ドル | 5 ドル |
従量課金では、同じ入力を再利用するプロンプトキャッシュを使うとキャッシュヒット分は入力の 10 分の 1 に下がり、Batch API では入力・出力とも 50 パーセント引きになります。つまり同じ作業でも、選ぶモデルとキャッシュの使い方でコストは大きく動きます。ここを踏まえて、次章から /usage での把握とモデル・effort の使い分けに入ります。
/usage でコストの内訳を可視化する
何より先にやるべきは、現状の把握です。Claude Code には /usage というコマンドがあり、利用状況とコストの内訳をセッション内で確認できます。
/usage/usage を実行すると、利用上限に対してどれだけ消費しているか、そして何がその消費を押し上げているかがカテゴリ別に表示されます。スキル・サブエージェント・プラグイン・MCP サーバーといった単位でコストの内訳が見えるため、「漠然と高い」ではなく「この MCP サーバーが毎回大量のコンテキストを差し込んでいる」といった具体的な原因にたどり着けます。
コストを抑える作業は、推測から始めると必ず外します。まず /usage を 1 日の終わりや、重い作業の後に開く習慣をつけてください。「重いと感じたセッションで実際に何が重かったのか」を 1 週間分も眺めれば、自分の使い方のクセが見えてきます。たとえば常時接続している MCP サーバーが毎ターン数千トークンを消費していた、長いセッションを切らずに使い続けてコンテキストが肥大していた、といった主因はだいたいこの段階で特定できます。
コストが膨らむ主因 — コンテキスト肥大と過剰な effort
/usage で内訳を見ていくと、コストが膨らむ要因はおおむね次の 2 つに集約されます。
1 つはコンテキストの肥大です。Claude Code は、会話履歴・読み込んだファイル・ツールの実行結果・MCP サーバーが差し込む情報などをまとめてモデルに渡します。長く使い続けたセッションほどこの履歴が積み上がり、1 ターンあたりに送るトークン量が増えていきます。とくに大きなファイルを何度も読み込んだり、grep の結果を大量に貼り付けたりすると、その内容が以降のターンでも毎回送られ続けます。会話が進むほど 1 往復が高くつく、という構造を理解しておくことが第一歩です。
もう 1 つは過剰な effort です。effort（効果レベル）はモデルがどれだけ考えてから答えるかを決める設定で、高くするほど思考に使うトークンが増えます。難しい設計判断には high や xhigh が効きますが、ファイル名のリネームや単純な置換にまで高い effort を使うのは純粋なムダです。「全部しっかり考えさせれば安心」という発想が、地味にコストを押し上げます。
この 2 つを意識するだけで、削るべき場所の見当がつきます。次のセクションから、それぞれへの対処を具体的に見ていきます。
場面別のモデル・effort 使い分け方針
コストと品質のバランスは、作業の性質に応じてモデルと effort を切り替えることで取ります。基本方針は「既定は控えめに、難所だけ上げる」です。
effort は /effort で切り替えられます。
/effort high
/effort xhigh日常の実装やレビューは既定の effort のまま進めて問題ありません。引き返しにくい設計判断や、原因が見えない難しいデバッグのときだけ一段上げ、終わったら戻すのが基本です。xhigh は high と max の間の効果レベルで、ここぞという場面に絞って使うとコスト効率がよくなります。Opus 4.8 を前提にした effort の具体的な使い分けは、Opus 4.8 を使いこなす要点 に詳しくまとめています。
モデルの選択も同じ考え方です。/model で切り替えられます。
/model定型的な編集・小さなリファクタ・テストの雛形づくりのような、判断の重くない作業は軽量なモデルで十分こなせます。一方、アーキテクチャの検討や込み入ったバグの調査など、誤ると手戻りが大きい作業は上位モデルに任せたほうが、結果的に安く済みます。安いモデルで何度もやり直すより、作業の難易度に見合ったモデルで一発で通すほうが総コストは下がる、という視点を持つと判断がぶれません。
短い往復を何度も繰り返す時間帯（UI 調整や型エラー潰しなど）は、速度を優先して作業のテンポを上げたほうが、人間側の待ち時間という見えないコストも含めて効率的です。逆に腰を据えた設計には通常モードで深く考えさせる、とメリハリをつけます。
セッション分割とコンテキスト整理でトークンを減らす
コンテキスト肥大への一番効く対処は、セッションを適切に切ることです。1 つのセッションでタスクを延々と続けると、過去の無関係なやり取りまで毎ターン送られ続けます。区切りのいいタスクが終わったら /clear で履歴をリセットし、新しいタスクは新しいコンテキストで始めるのが基本です。
/clear履歴は捨てたくないが軽くしたい、という場合は /compact で会話を要約して圧縮できます。
/compact/compact は、それまでの経緯を要約に置き換えてからコンテキストを縮めるので、文脈を保ちつつトークンを減らせます。長い調査の途中で続きをやりたいときに向いています。
さらに、コンテキストに何を載せるかを設計でコントロールするのも効きます。プロジェクトの前提（技術スタック・コーディング規約・よく使うコマンド）は、毎回チャットで説明するのではなく CLAUDE.md に書いておけば、過不足のない前提を毎回安定して渡せます。逆に肥大しがちな MCP サーバーは、本当に必要なセッションだけ有効化し、常時接続を見直すとそれだけで 1 ターンの単価が下がります。大きなファイルは全文を読ませず、関係する範囲だけを対象にするよう指示するのも有効です。
hooks / subagent がコストに与える影響
hooks とサブエージェントは強力な仕組みですが、コストへの影響を理解せずに使うと、知らないうちに消費を押し上げます。
hooks 自体はローカルでコマンドを実行する仕組みなので、それ単体でトークンを消費するわけではありません。問題は、hooks が返す出力です。たとえば型チェックや lint の結果を毎ターン大量に出力する hook を仕込むと、その全文がコンテキストに積まれていきます。出力は head で行数を絞る、エラー時だけ表示する、といった設計にしておくと、フィードバックの価値を保ちながらコストを抑えられます。hooks の実用パターンそのものは Claude Code の hooks で品質を底上げする実用パターン で扱っているので、設計の勘所と合わせて押さえてください。
サブエージェントは、メインの会話とは別のコンテキストでタスクを処理し、結果だけを返す仕組みです。重い調査をサブエージェントに切り出せば、メインのコンテキストを汚さずに済むという利点があります。一方で、サブエージェント側でも当然トークンを消費するため、件数が多いと合計コストはそれなりに増えます。/usage の内訳でサブエージェントの消費が大きい場合は、本当に分割が必要だったか、1 つにまとめられなかったかを振り返るとムダが見つかります。挙動が不安定でやり直しが増えているなら、それも見えないコスト要因です。動作がおかしいときの切り分けは Claude Code のトラブルシューティング を参照してください。
チームでコストを管理する運用ルール
個人での最適化に加えて、チームで使うなら運用ルールを軽く決めておくと、コストの暴れを防げます。ポイントは、締めつけるのではなく、ムダになりやすい部分だけ揃えることです。
まず、プロジェクトの前提を CLAUDE.md に集約し、リポジトリで共有します。各人がバラバラに長い指示を毎回書く状態は、品質が安定しないうえにトークンも余計に使います。共通の前提を 1 か所にまとめておけば、誰が使っても過不足のないコンテキストから始められます。
次に、MCP サーバーや hooks の標準構成を決めて共有します。「全員が全部の MCP サーバーを常時接続している」状態は、気づかないうちにコストを底上げします。必要なものだけを推奨構成として .claude/settings.json などに整理し、重いものはオプション扱いにします。
そして、/usage を定点観測する習慣をチームに根づかせます。月初や週次の振り返りで「先週コストが大きかった作業は何で、それは必要なコストだったか」を軽く話すだけで、過剰な effort の常用や不要なセッションの引き延ばしといったクセが早めに是正されます。組織への導入と定着の全体像は Claude Code を実務に導入する完全ガイド にまとめているので、運用設計の参考にしてください。
品質とコストのバランスをどう取るか
最後に、コスト最適化で見失いがちな視点を確認します。Claude Code のコストは、トークン課金だけではありません。effort を下げすぎたりモデルを安くしすぎたりして手戻りが増えれば、エンジニアの時間という最も高いコストを浪費します。トークン代を数百円削るために、人間が数時間やり直す、というのは本末転倒です。
判断の軸はシンプルです。引き返しにくい作業・誤ると影響が大きい作業には、惜しまず効果レベルを上げる。やり直しがきく軽い作業は、軽量な構成で素早く回す。そして /usage で内訳を見ながら、「価値に見合わない消費」だけを狙って削る。この 3 点を回していけば、品質を落とさずに費用対効果を着実に上げられます。
コスト最適化は一度やって終わりではなく、使い方が変われば最適点も動きます。まずは /usage を開いて現状を把握するところから始め、効く場面に投資し、ムダな場面を削る、という当たり前を地道に続けるのが結局いちばんの近道です。
AI 駆動開発をチームの実務に根づかせる進め方や、コストと品質のバランス設計でお困りの際は、AI 駆動開発の進め方を相談する からお気軽にご相談ください。
よくある質問 (FAQ)
/usage では何が確認できますか？
/usage は、Claude Code の利用状況とコストの内訳をセッション内で確認するコマンドです。利用上限に対する消費量に加えて、スキル・サブエージェント・プラグイン・MCP サーバーといった単位で、何がトークン消費を押し上げているかがカテゴリ別に表示されます。コスト最適化はまず現状把握から始めるべきなので、重い作業の後や 1 日の終わりに /usage を開いて、自分の使い方のクセを見つけるのが出発点になります。
effort を下げればコストは下がりますか？
トークン単位では下がりますが、トータルで安くなるとは限りません。effort を下げると思考に使うトークンは減りますが、難しい作業で品質が落ちて手戻りが増えると、エンジニアの時間という高いコストがかさみます。定型的で軽い作業は低めの effort で素早く回し、引き返しにくい設計判断や難しいデバッグだけ effort を上げる、というメリハリのある使い分けが、結果的にいちばんコスト効率がよくなります。
コンテキストの肥大を防ぐ手早い方法はありますか？
区切りのいいタスクが終わったら /clear で履歴をリセットし、新しいタスクは新しいコンテキストで始めるのが最も手早く効きます。文脈を残したまま軽くしたい場合は /compact で会話を要約して圧縮できます。あわせて、プロジェクトの前提を CLAUDE.md に集約して毎回の説明を省く、常時接続している MCP サーバーを見直す、大きなファイルは必要な範囲だけ読ませる、といった工夫で 1 ターンあたりのトークンを継続的に減らせます。