Claude Code コスト最適化7つの方法｜サブスクを使い倒して請求を半減

送信ボタンを押した瞬間、「利用上限に達しました」——その一文が表示されるたびに、思考の流れが完全に断ち切られる。

Claude Code を本格的に使い始めると、コストより先に「枠の壁」が現実になる。Pro サブスクでも、集中して作業した日の夕方には上限に張り付き、翌朝まで待つか API に逃げるかの二択を迫られる。API 従量課金に切り替えれば自由になる反面、月末の請求書を開くのが怖くなる。どちらに転んでも、ツールに振り回されている感覚は変わらない。

本来、Claude Code はコーディングを加速するためのものだ。なのに「今日あと何トークン使えるか」を気にしながら補完を呼ぶのは、燃費を心配しながらアクセルを踏めないのと同じで、生産性の半分を無駄にしている。

この記事では、サブスクを解約せずにコストと消費量を実質半減させた 7 つの方法をまとめた。設定変更から会話設計の見直しまで、今日から試せる順に並べている。

そもそもどう動くのか

「月末に請求を開いてため息をついた」—その正体、実は構造の問題だ。

Claude Codeのコストは、突き詰めると**「1リクエストあたりのトークン量 × リクエスト回数」**で決まる。ここでいう「トークン」とは、モデルに送るテキストの単位（おおむね1文字≒1〜2トークン）。問題は、Claude Codeが会話するたびに「これまでの全履歴」を毎回まるごとAPIに再送している点だ。

たとえば、長い会話の中でファイルを10本読み込み、ツール結果が返ってきて、あなたが「ちょっと修正して」と1行打ったとする。そのとき実際に送られるのは「1行」ではなく、その1行＋会話全履歴＋読み込んだ10本のファイル内容＋ツール出力だ。コンテキストウィンドウが大きければ大きいほど、1回の送信コストが跳ね上がる。

[あなたの1行の質問]
+ [これまでの会話履歴 全部]
+ [/読み込んだファイル 全部]
+ [ツール結果 全部]
= 実際のAPIリクエストサイズ

これを知るだけで、対策が「精神論」から「設計問題」に変わる。何を送らないか（会話を短く切る、読み込むファイルを絞る）、どの枠で動かすか（Max契約内 vs API従量課金）、この2軸を意識するだけでコストは大きく変わる。以降の7つの方法は、すべてこの原理の応用だ。

---

まとめ: コストの正体は「履歴の蓄積」にある。長い会話ほど1回が高くつく構造なので、「切る」「絞る」「枠を選ぶ」が基本の武器になる。まず試すなら、次の長い作業セッションの前に/clearで会話をリセットする習慣から始めてみよう。

①〜 会話が長くなったら惜しまず /clear する（最大の節約ポイント）

「なんか最近、同じ量の作業なのにトークン消費が増えてる気がする」——それ、気のせいじゃない。Claude Codeはデフォルトで会話履歴全体を毎リクエストに含めて送る。タスクを跨いで使い続けると、古いやりとりがトークンとして積み重なり、何もしていないのにコストが膨らんでいく。

仕組みを押さえると節約の筋道が見える

Claude Codeは文脈を保持するため、過去の会話をリクエストのたびにモデルに渡す。10ターン前のデバッグ議論も、20ターン前のファイル内容も、全部巻き込まれる。タスクが変わっても履歴は消えないので、「新しい作業をしているのに古い文脈を毎回送り続ける」状態になりやすい。逆に言えば、タイミングよくリセットするだけで送信トークン数を劇的に減らせる。

やること：タスク切り替えのたびに /clear を打つ

/clear

これだけ。一つの機能実装が終わった、バグを直し終わった、別ファイルの作業に移る——そのタイミングで打つ癖をつけると効果が大きい。長いリファクタリングセッションの途中でも、方針が固まって実装フェーズに入る瞬間に打てば、調査の往復分が丸ごとリセットできる。

「消したら戻れない」は過去の話

誤ってクリアしてしまっても、/rewindで/clear前の会話に戻れるようになった（Claude Code 2.1.191で追加）。「消すと取り返しがつかない」という心理的ブレーキが外れたので、もっと気軽にクリアしていい。

判断の目安

• 今の作業と関係ない会話が3〜4ターン以上ある → クリアのサイン
• 「このコード、さっき見せたやつ」と文脈に頼り始めている → むしろ明示的に渡したほうが安い
• 新しいファイルやモジュールを触り始める → タイミングとしてほぼ確実

まとめ

会話履歴の肥大化は静かにコストを押し上げる。/clearは設定でも課金プランでもなく、タイミングの問題だ。試しに今日のセッションを振り返って、「どこで切れていたか」を確認してみるところから始めると体感が変わる。

②〜 サブスク枠と従量課金を使い分ける

「今月また請求が跳ね上がった」——APIキーを雑に使っていると、毎月その恐怖が来る。Claude Codeには定額のサブスク枠と従量課金のAPI枠が共存していて、どちらを「どの仕事」に使うかを意識するだけでコストの景色が変わる。

仕組みをざっくり掴む

Pro/Maxプランは月定額で、Claude Code上のインタラクティブな会話セッションがその枠内に収まる。一方、API従量課金はトークン単位の請求なので、大量のバッチ処理や自動化スクリプトをここに当てると一気に膨らむ。逆に言えば、毎日のコーディング作業をサブスク枠で回し、バッチはAPI枠に限定するのが基本の切り分けだ。

損益分岐を自分で計算する手順

1. 先月の実績トークン数を確認するAnthropic Consoleの「Usage」タブを開き、月別のinput/outputトークン合計を確認する。ここが出発点。

2. サブスク単価を換算する例えばMaxプランの月額をそのトークン数で割って「1Mトークンあたりの実質コスト」を出す。APIのSonnet料金と並べて比較する。

3. インタラクティブ作業をサブスク枠に集約するClaude Codeのセッションはclaudeコマンドで起動するだけでサブスク枠が使われる。APIキーを直接叩くスクリプトとは別物なので、日常のコーディングは必ずCLI経由で行う。

4. バッチ処理は明示的にAPIキー経由に切り出すスクリプトを書くときはANTHROPIC_API_KEYを使う実装に限定し、claude -p（non-interactiveの--printモード）をバッチに流用しない。インタラクティブ枠を消費する経路とAPIを混在させると計測が難しくなる。

5. 月間利用量のアラートを設定するAnthropic Consoleの「Limits」から使用量アラートを設定できる。月途中で異常に増えたとき気づける仕組みを先に作っておく。

6. /usageコマンドで現在の枠消費を確認するセッション中に/usageを打つと現在のセッションでのトークン消費量が表示される。感覚を掴むのに使う。

7. 週単位で消費パターンを見直す一度計算して終わりにせず、週1回Consoleを眺める習慣を作る。「先週バッチを回した日だけ急増している」ようなパターンが見えてきたら、その処理をAPI枠に完全移行するサインだ。

---

まとめると、サブスク枠は「人間が手を動かす時間」に使い、自動化・バッチは従量枠に押し込む——この一線を引くだけで月末の請求が読めるようになる。まずConsoleの「Usage」タブを開いて、先月のトークン数を確認するところから始めてみよう。

③〜 重いタスクほどモデルを使い分ける

「ちょっとしたコード補完のためだけに、Opusを全力回転させてしまっている」——これに気づかず月末の請求額に驚く人は少なくない。

Claude Codeは複数のモデルを使い分けられる設計になっている。仕組みはシンプルで、セッション中に/modelコマンドを打てばその場でモデルが切り替わる。APIコストはモデルごとに大きく異なるため、「重い仕事はOpus、軽い仕事はHaiku」という分業を意識するだけで請求が激変する。

---

使い分けの基本判断

---

実際の切り替え方

# セッション中にモデルを切り替える
/model claude-haiku-4-5-20251001

# 重い設計タスクに切り替える場合
/model claude-opus-4-7

セッション開始時はデフォルトモデルで入り、設計の議論が終わったら即座にHaikuへ落とす。この「降格タイミング」を習慣にするだけで無駄なOpus課金を削れる。

---

具体的な運用フロー

1. ブレインストーミング・設計フェーズ: Opusで開始。「この機能をどう設計するか」を深く掘る
2. 設計確定後、実装フェーズへ移る前に:/model claude-haiku-4-5-20251001で切り替え
3. テストコード・繰り返しパターンの補完: Haikuのまま進める
4. バグが再発・原因不明になったとき:/model claude-opus-4-7で戻す
5. デバッグ完了後: 再びHaikuへ

---

Haiku適用で外さないポイント

定型作業かどうかの判断基準は「同じパターンが繰り返されるか」。CRUDの追加、既存コードへのテスト追加、JSDocの補完などはHaikuで十分まかなえる。一方、「なぜこのバグが起きるのか根本原因を探る」「複数ファイルにまたがる設計判断をする」といった作業はOpus一択だ。

コスト節約の落とし穴は、「安いから」という理由だけでHaikuを使い続けること。出力品質が下がって後戻りが発生すれば、Opusで最初からやり直すより高くつく。

---

まとめ

モデルの使い分けは「贅沢を我慢する」話ではなく、タスクに対して適切なリソースを当てるエンジニアリングだ。Haiku・Sonnet・Opusそれぞれに得意領域があり、それを理解して/modelで切り替えるだけで、品質を落とさず請求を抑えられる。

まず一週間、設計・デバッグ以外のタスクをHaikuで試してみてほしい。体感で「これはHaikuで十分」という感覚が身につけば、あとは自然に最適化が進む。

④〜 読ませるファイルを絞ってトークンを節約する

「とりあえずプロジェクト全体を渡しておけば大丈夫」——この感覚が請求額を静かに押し上げている。

Claude Code はプロンプトに含まれるファイルの文字数をそのままトークンとして消費する。node_modules、dist、ロックファイル、画像バイナリ……これらを無意識に読ませていると、本題のコードに到達する前に数千トークンが消えていく。仕組みはシンプルで、入力が少なければコストは下がる。それだけだ。

---

絞り込みの具体手順

1. .claudeignore を作る（最速で効く）

プロジェクトルートに.claudeignoreを置くと、Claude Code がファイルを自動で読む際にそのパスを除外する。.gitignoreと同じ書式だ。

# .claudeignore
node_modules/
dist/
.next/
*.lock
*.svg
*.png
coverage/

これだけで大型 Next.js プロジェクトなら入力トークンが体感で 3〜4 割減ることが多い。

2. プロンプトで対象ファイルを明示する

「このプロジェクトの認証周りを直して」ではなく、「lib/auth/session.tsとapp/api/login/route.tsの 2 ファイルだけ見て」と指定する。Claude Code はコンテキストに渡されたファイルしか読まないので、不要なものを渡さなければ読まれない。

3. /config で自動添付を確認・調整する

/config

を実行すると現在の設定が一覧表示される。autoContextやincludeの設定が意図せず広い範囲を取り込んでいないか確認しよう。プロジェクトごとに.claude/settings.jsonで上書きもできる。

{
  "autoContext": {
    "include": ["src/**/*.ts"],
    "exclude": ["src/**/*.test.ts", "src/generated/"]
  }
}

4. 生成ファイルは必ず除外する

prisma/generated/、src/generated/、__generated__/などの自動生成コードは巨大なうえ編集対象にならない。最優先で.claudeignoreに追加する。

5. 大きなファイルは該当箇所だけ渡す

1000 行超のファイルを丸ごと渡すより、「100〜150 行目のこの関数を直して」と範囲を指定したほうがトークンが少ない。Claude Code のプロンプトに行番号を書いて渡すか、関連部分だけコピーして貼り付けるのが現実的だ。

6. テストファイルを普段の作業から切り離す

実装中は.claudeignoreにテストを入れて除外し、テスト修正フェーズだけ外す——という使い分けで、不要なコンテキストが積み重なるのを防げる。

7. /rewind でやり直しコストを下げる

誤った方向にトークンを使いすぎたとき、/rewindで直前の状態に戻せる。会話を丸ごとリセットする/clearより無駄が少ない。

---

ファイル絞り込みはコード品質に影響しないコスト削減なので、真っ先に手を打てる施策だ。まず今日の作業プロジェクトに.claudeignoreを 1 ファイル追加してみよう。それだけで次の請求が変わり始める。

⑤〜 探索はサブエージェントに逃がしてメイン文脈を汚さない

「grep結果が500行ドバッと出てきて、その後の会話がどんどん遅くなる」——これ、実はコスト問題だ。Claude Codeのメイン会話は、過去のやり取りをまるごと再送しながら動いている。ファイル探索の生ログがコンテキストに積み上がるほど、次のリクエストで送るトークン数が膨れ上がる。

仕組みを押さえておこう。Claude Codeはサブエージェント（Agentツール）を使って別セッションを立てられる。サブエージェントの内部処理はメイン会話のコンテキストに残らない。「調べた結果のサマリーだけ」が返ってくる構造になっている。つまり、調査系の作業をサブエージェントに投げれば、重い生データをメインに持ち込まずに済む。

具体的な使い分け

1. grep・glob探索はサブエージェントへ
   Agentツールに「このディレクトリ内でuseEffectを使っているファイルと、依存配列が空のものを一覧にして」と渡す。メインには「3ファイルあり、src/foo.tsxのみ問題あり」という要約だけ戻る。

2. 複数ファイルの横断読みも委譲
   「lib/cortex/以下の全ファイルを読んで、外部API呼び出し箇所を洗い出して」という調査タスクは、サブエージェントが最適。自分で数十ファイルをRead連打するとその全出力がコンテキストに乗る。

3. subagent_type: "Explore"を明示する

   Agent({
     subagent_type: "Explore",
     description: "API呼び出し箇所の調査",
     prompt: "lib/以下でfetch/axiosを使っている箇所を列挙。200字以内で報告。"
   })
   

   Exploreエージェントは読み取り専用ツールのみ持つため、意図せぬ変更も防げる。

4. サブエージェントの返答は短く指定する
   プロンプトに「200字以内で報告」「箇条書きで最大5件」など上限を書く。サブエージェントが詳細を返しすぎると、結局その要約がメインに積まれてしまう。

5. 並列で複数投げる
   独立した調査なら、Agentを1つのメッセージで複数呼び出せば並列実行される。セキュリティ確認・型チェック・ドキュメント調査を同時に走らせても、それぞれの内部ログはメインに混入しない。

6. /clear後の復旧は/rewindで
   コンテキストが膨らみすぎて/clearした後でも、作業途中の状態に戻りたいなら/rewindが使える（v2.1.191で追加）。サブエージェントへの逃がしとセットで覚えておくと、クリア前後の行き来がしやすくなる。

7. 「調査」と「変更」でセッションを分ける
   探索フェーズ（何があるか調べる）と実装フェーズ（コードを書く）を別セッションに分けるだけでも効果がある。探索の膨大なログを引きずらないまま、クリーンな状態で実装に入れる。

---

要するに「汚れ仕事はサブエージェントに任せ、メイン会話はサマリーだけ受け取る」という分業だ。コンテキストがコンパクトなほど、後続の全リクエストが安くなる。まず次のファイル探索タスクで1回試してみよう——Agentに投げてみて、メインのレスポンスがどれだけすっきりするか、体感するのが一番早い。

⑥〜 CLAUDE.md で前提を先回りして往復回数を減らす

「毎回"TypeScriptで書いて""テストも書いて""app/以下は触るな"って言わないといけない」——この繰り返しはトークンの垂れ流しだ。説明コストは見えにくいが、積み重なると月次請求に確実に出てくる。

Claude Codeは会話を始めるとき、プロジェクトルートの.claude/CLAUDE.md（またはホームの~/.claude/CLAUDE.md）を自動で読み込む。ここに「前提」を書いておけば、毎リクエスト冒頭で同じ説明を繰り返す必要がなくなる。往復が減る＝リクエスト数が減る＝コストが下がる、という直結した構造だ。

書くべき内容と実例

まず/initコマンドを叩くと、AIがプロジェクトを走査して雛形を生成してくれる。

# プロジェクトルートで実行
/init

生成された.claude/CLAUDE.mdを以下の観点で肉付けする。

1. 変更禁止ファイル・ディレクトリを列挙する

## 変更禁止
- `app/` 以下のページコンポーネント
- `lib/supabase/` 配下（スキーマ変更はマイグレーションで行う）
- `.env.local`（秘密鍵は絶対にDiscordやコミットに出さない）

「触っていいファイル」より「触ってはいけないファイル」を先に書く方が事故が減る。

2. コーディング規約を1スクリーンに収める

## コーディング規約
- 言語: TypeScript strict mode
- フォーマッタ: Prettier（保存時自動実行）
- テスト: Vitest、カバレッジ80%以上
- コメント: WHYが自明でない場合のみ1行
- ミューテーション禁止（イミュータブルパターン必須）

長大なドキュメントは読まれない。箇条書き10行以内を目安にする。

3. よく使うコマンドと文脈を書く

## よく使うコマンド
- `npx tsx scripts/check-and-improve.ts` — CORTEX実データ確認
- `gh pr create` — PR作成（pushまで一気にやる）

「このコマンドが何をするか」が書いてあるだけで、毎回の説明が消える。

4. プロジェクト固有の用語集を追加するチーム内略語や独自命名（例：「CORTEX」「Ralph Loop」）を一言で定義しておく。これだけで文脈把握の往復が1〜2回は消える。

5. 「やっていいこと」を明示する禁止ばかりだと過剰確認が増える。「この範囲なら自律で動いていい」と書いておくと承認リクエストが減り、コストと時間の両方が下がる。

---

CLAUDE.mdは一度書けば全セッションで効く。「今日だけ節約する」のではなく「永続的に往復を減らす」仕組みだ。まず/initを一回叩いて、生成された雛形の禁止ファイル欄だけでも埋めるところから始めてみてほしい。

⑦〜 利用枠と消費を可視化して上限張り付きを防ぐ

作業の一番脂がのったタイミングで「利用上限に達しました」とブロックされる、あれほど集中を削ぐ体験はない。しかも再開できる時刻が分からず手が止まる。Claude Code のサブスクを使い倒すなら、枠の消費ペースを把握して「上限直前に重作業をねじ込む」失敗をゼロにしたい。

Claude Code の枠がどう動くか

Claude Code Pro/Max には「5時間枠（ローリングウィンドウ）」と「月次クレジット上限」の2層がある。5時間枠はリクエストを打った時点を起点に5時間後に消費分がリセットされる仕組みで、月次はカレンダー月で上限が決まる。重要なのは「5時間枠は固定の時刻でリセットされるわけではない」という点だ。最後にAPIを叩いた時間が起点になるため、何もしない時間が長ければ枠が自然に空く。

手を動かせる運用ステップ

1. 現在の設定を確認するターミナルでclaudeを起動し、/configを打つ。model・max_tokens・context_windowが表示される。ここで予想外のモデルが選ばれていたり、context_window が無駄に大きければ消費を圧迫している可能性がある。

2. 重い作業をセッション頭に寄せる長い実装・大量ファイルの読み込み・反復的なエージェント実行は、セッションを開始してすぐに着手する。枠の残りが少ない時間帯に回すと途中でブロックされる。

3. 枠リセットを待つ間に軽作業を挟む上限警告が出たら、ドキュメント読み・設計メモ整理・手動テストなど LLM を使わない作業に切り替える。5時間ウィンドウの消費が落ち着けば自動で復活する。

4. コンテキストを定期的にリセットする1セッションを長く続けると会話履歴がトークンを食い、同じ作業でも消費量が増える。区切りのいいところで/clearを打ち、履歴をリセットする。/rewindを使えば/clear前の状態に戻れるので、消し過ぎた場合のリカバリも効く（Claude Code 2.1.191 以降）。

5. モデルをタスクに合わせて使い分ける/configでモデルを切り替えられる。コード補完や簡単な質問は軽量モデルに任せ、アーキテクチャ設計など判断が必要な場面だけ高性能モデルを使う。これが消費ペースを最も直接的に下げる施策になる。

6. エージェント実行は必要最小限のスコープで「全ファイルをスキャンして」系の指示は思った以上に枠を食う。/projectでスコープを絞るか、対象ファイルを明示してから実行すると消費が大幅に減る。

7. ブロック時刻を記録してパターンを掴む上限に当たった時刻をメモしておくと、自分の作業リズムと5時間枠の関係が見えてくる。「午前10時に重作業を始めると午後3時前後にブロックされる」というパターンが分かれば、次から午後3時を超えてから着手する、といった調整ができる。

---

まず今日のセッションで/configを1回打って、自分が使っているモデルと設定を確認するところから始めてみてほしい。設定を把握しているだけで、消費を意識した動き方が自然に身についてくる。

まとめ

Claude Code のコストの正体は、毎回のリクエストで再送されるコンテキスト量だ。キャッシュを効かせ、モデルを使い分け、不要な会話履歴を断ち切る——この3つの軸を押さえるだけで、請求額は驚くほど変わる。サブスクユーザーならなおさら、API コストをゼロに近づけながら同じ出力品質を保てる余地がある。まず今日から試してほしいのは、タスクが切り替わったタイミングで/clearを打つ習慣だけ。それだけで翌日の請求が体感できるレベルで下がるはずだ。