Claude Codeを使い込むほど、月額の壁にぶつかる人が増えています。Opusで全部やればコストは跳ね上がり、かといってSonnetだけだと設計品質が落ちる。SE歴20年・2026年3月27日からClaude Code Maxプラン5xで複数の自動化パイプラインを運用している筆者が、トークンコストを50〜75%削減する実践施策を整理します。3層スタック・Prompt Cache・コンテキスト管理に加え、追加コストゼロで効く運用施策まで含みます。
APIコストで悩むエンジニア向け。Maxプランのレート制限で詰まる人にも使える残トークン枠の延命策です。
- 3層スタック（Opus5〜10%・Sonnet55〜65%・Haiku25〜35%）でモデルを使い分ける。OpusPlan適用でZenn実測54%削減を確認。
- Prompt Cacheで固定コンテキストの入力コストを最大84%削減できる（Sonnet 4.6・20ターン実測）。
- 追加コストゼロの3施策（原始人モード・/compact 50%ルール・リビルド判断）で出力トークンを削れる。
Claude Codeのコスト構造を理解する
削減を始める前に、コストの内訳を把握する必要があります。Claude Codeは「モデル料金 × トークン量」で課金され、削減できるのはこの2つの軸だけです。
トークン消費が膨らむ典型パターン
トークンが増える原因はだいたい決まっています。長い会話履歴を毎ターン読み直す、不要なファイルをそのままコンテキストに入れる、シンプルなタスクに最上位モデルを使う、プロンプトを後出しで継ぎ足す。単体では小さな無駄でも、1セッションで積み重なると数倍のコスト差になります。筆者がcontent-pipeline（RSS収集→記事生成→WordPress投稿）を構築した初期は、CLAUDE.mdに細かいルールを書き足すうちに肥大化し、毎セッションの初期トークンが増えていました。Prompt Cacheの仕組みを理解する前は「何となく高い」という状態が続きます。
Opus・Sonnet・Haikuの料金差と特性
2026年4月時点の公式API料金は次の通りです。出力料金は入力の5倍という比率がClaude全モデルで共通しており、見積りがしやすい構造になっています。
| モデル | 入力 | 出力 | キャッシュ読込 | 適性タスク |
|---|---|---|---|---|
| Haiku 4.5 | $1.00 | $5.00 | $0.10 | 整形・分類・要約 |
| Sonnet 4.6 | $3.00 | $15.00 | $0.30 | 実装・テスト・通常タスク |
| Opus 4.7 | $5.00 | $25.00 | $0.50 | 設計・難所リファクタ |
※ 単位は1Mトークンあたり米ドル。キャッシュ読込は標準入力の10%。OpusとSonnetの差は1.67倍で、出力が長くなる設計ドキュメント生成では効いてきます。Haikuはopus比で5分の1なので、サブエージェントや雑務に振り分けるだけで全体コストが大きく下がります。
重要なのは「入力と出力の料金比が1:5」という点です。同じ1万トークン削るなら、出力を削る方がコスト効率が5倍高い。後述する「原始人モード」が劇的に効く理由はここにあります。
削減目標を50〜75%に置く根拠
Zennのrural writer氏の記事では、認証リファクタリングの実測でOpus単独 $1.23 → OpusPlan（OpusでPlan・Sonnetで実行）$0.57で54%削減、最適なモデルティアリングを1,000タスクにスケールすると75%削減という数字が出ています。筆者がcontent-pipelineを開発した際も「3層スタック適用前後で月額が半減した」レベルで、この50〜75%という幅は再現性のある数字です。
参考: Zenn: Claude Codeのコストを50〜75%削減する
3層スタック戦略でモデルを使い分ける
3層スタックとは、タスクの複雑度でOpus・Sonnet・Haikuを振り分ける戦略です。全部Opusで動かすのは、ファイルにラベルを貼るためにチーフアーキテクトを雇うようなもの。役割を分けるだけでコストの構造が大きく変わります。
設計・難所はOpusに任せる
Opusは全タスクの5〜10%に絞ります。アーキテクチャ設計、複雑なリファクタリング方針の決定、セキュリティレビュー、性能ボトルネックの分析といった領域です。Plan Modeで使うのが定石。
OpusPlanパターン（/model opusplanで有効化）はOpusで計画を立てさせ、Sonnetに切り替えて実行させる組み合わせです。設計品質を落とさずに実行コストを下げられる、最もROIが高い使い方。筆者がcontent-pipelineのRSS評価ロジックを作り直したときも、この方法で進めました。
実装の主戦場はSonnetで回す
Sonnetは55〜65%の比率で使う「主戦場モデル」です。機能実装、ユニットテスト、API連携、通常のリファクタはほぼSonnetで足ります。Opusに比べて入力出力ともに40%安く、プロダクション用途でも十分な品質です。
Maxプランには、Opusだけでなく「Sonnetの週次上限」も設定されています。レート制限で詰まらないために、この仕様を覚えておく必要があります。
雑務・整形はHaikuで処理する
Haikuは25〜35%。JSONフォーマット、docstring生成、変数リネーム、コミットメッセージ、ログ整形など「Sonnetでやると贅沢」な仕事をすべてHaikuに振ります。
サブエージェントのモデルにHaikuを指定するのが特に効きます。環境変数 CLAUDE_CODE_SUBAGENT_MODEL=haiku を設定すると、調査タスクや大量ファイル読み込みのコストが大きく下がります。Opusのサブエージェント機能と使い分け方については別記事で詳しく書いています。
モデル選択の基準は「複雑さ」であって「重要度」ではない。コミットメッセージは重要だがHaikuで足ります。
Prompt Cacheでトークンを圧縮する
3層スタックがモデル選びの最適化なら、Prompt Cacheは同じトークンを繰り返し計算しない工夫です。削減効果は3層スタックより大きい。
Prompt Cacheの仕組みと割引率
Prompt Cacheは入力プロンプトの先頭から共通する部分をキャッシュに乗せ、2回目以降は10%の料金で読み出す。Sonnet 4.6では標準入力 $3.00/Mに対しキャッシュ読込は $0.30/M。Opus 4.7なら $5.00 → $0.50/M。
書き込み側はTTL5分なら標準の1.25倍、1時間TTLなら2倍のコストがかかる。Maxプラン（1時間TTL）でも、2回読み込めば書き込みコストの元が取れる。
固定コンテキスト100Kトークンで20ターンやり取りした場合の比較を見ると効果が明確だ。
| 方式 | 入力コスト | 削減率 |
|---|---|---|
| キャッシュなし | 20 × $0.30 = $6.00 | — |
| キャッシュあり | $0.375 + 19 × $0.03 = $0.945 | 84%削減 |
CLAUDE.mdとシステムプロンプトの設計
キャッシュは先頭から1文字でも違えばそこから先は再計算される。つまりCLAUDE.mdとシステムプロンプトは、頻繁に書き換えないことが効く。
筆者が陥った失敗は、CLAUDE.mdに作業途中で気づいた制約を追記し続けたこと。ファイルを更新するたびにキャッシュが無効化され、毎セッションで初期コストを払い直していた。
記事制作ルール（このブログのarticle_prompt.md相当）のように頻繁に更新するファイルは別管理にして、CLAUDE.md本体は安定させるのが正解だ。CLAUDE.mdとプロンプト肥大化の運用限界では、888行で破綻した実例をまとめている。
キャッシュヒット率を高める運用ルール
キャッシュを最大化する運用ルールはシンプル。最初のメッセージに目的・制約・完了条件をすべて書く。あとから「あ、テストもグリーンで」と継ぎ足すと、その追加分がキャッシュ外になる。
スクリーンショットや画像はメッセージの最後に置く。画像はそれより後ろの全テキストのキャッシュを破壊するため、テキスト部分を守るための鉄則だ。
複数の質問は1セッションに集約する。同じファイル群に対して5つの質問があるなら、5セッションを開かず1セッションでまとめて聞くと3.8倍安くなる。
MCPサーバーの追加・skillのON/OFFはキャッシュを最上位から破壊するので、セッション中に変更しない。意外な落とし穴だ。
参考: Anthropic公式 Pricing & Prompt Cachingドキュメント
コンテキスト管理で無駄な再読を防ぐ
3層スタックとPrompt Cacheは、コンテキストが綺麗に保たれていてこそ機能します。長時間セッションが膨らみ続けると両者の効果が低下します。
/compact 50%ルールで予防的に圧縮する
筆者がすべてのプロジェクトのCLAUDE.mdに共通で設けているルール：「コンテキスト使用率が50%を超える前に/compactを実行する」。
公式ドキュメントは「タスク切替時に/clear、継続時に/compact」までしか示していません。ここに50%という閾値を加えています。
理由は明確。50%を超えると指示遵守率が急激に落ちます。コンテキスト使用率が高まると同じ指示でも誤った解釈が増え、修正に余計なトークンを消費します。50%は予防ラインです。70%まで使い切ってから/compactしても、すでにミスが混入しており、そのコストは取り戻せません。
CLAUDE.mdに「50%超で/compact」と明記すると、Claude自身が自動的にコンテキストを圧縮してくれます。
サブエージェントで履歴を切り離す
「src/全体を読んで認証関連を探して」と指示するとメインコンテキストに全ファイル内容が流れ込みます。一方「サブエージェントで調査してfile:line形式でサマリーを返して」と指示すれば、独立コンテキストで動いた結果を200トークン程度のサマリーだけ受け取れます。
メインセッションは「判断・設計・統合」に集中させ、調査・大量読み込み・定期タスクはサブエージェントに委任する。これでコンテキスト汚染を防げます。
不要ファイル読み込みを抑える設定
.claudeignoreで除外ファイルを指定すれば、node_modulesやビルド成果物がコンテキストに混入するのを防げます。ファイル読み込みはRead offset=120 limit=50のように範囲指定で必要部分だけ取得すれば、2,000行ファイルが50行に削減できます。
CLAUDE.mdに「Bashのrg/findより組み込みのGrep/Glob/Readを優先」と書いておくのも有効です。Bashの生テキスト出力よりネイティブツールの構造化出力の方が、同じ情報量でもトークン消費が少なくなります。
出力トークンと外部ツールで攻める追加施策
ここまでの施策に加えて、追加コストゼロで効く運用テクニックを4つ紹介する。筆者が全プロジェクト横断で実運用しているものばかりです。
原始人モードで出力トークンを削る
Claudeの応答にはデフォルトで敬語・クッション言葉・前置きが大量に含まれます。「承知しました」「念のため確認ですが」「いかがでしょうか」のような社交的な表現が、出力トークンを膨らませている。
筆者は全プロジェクトのSessionStart hookで「敬語・クッション・前置きを排除し、技術的中身だけを出せ」というプロンプトを注入する設定にしています。
これだけで応答長が体感1/3〜1/2になった。入力と出力の料金比は1:5です。入力を削るより、出力を削る方がコスト効率が5倍高い。応答スタイルを変えるだけで設定不要・追加コストゼロです。
agent-browser CLIでブラウザ自動化のトークンを削る
ブラウザ操作が必要なときにPlaywright MCPを使うのが定番ですが、これは構造的にトークンを大食いします。MCPはツール呼び出しごとにDOMやアクセシビリティツリー全体をモデルのコンテキストに流し込む設計だからです。
筆者は現在、Vercelのagent-browser CLIを使っています。CLIはスナップショットをディスクに保存し、エージェントには「ファイルパス」しか返さない。必要な部分だけagentが読む構造です。
1ページあたり200〜400トークンで済むという公開ベンチマークがあり、Playwright MCP比でおおむね80%以上のトークン削減が報告されています。
参考: Playwright CLI vs agent-browser vs Claude in Chrome 比較記事
WebFetchで取れる静的ページなら不要ですが、ログインが必要なページや動的レンダリングのページではブラウザ自動化が必須になります。その場面での第一選択をMCPからCLIに切り替えるだけで効きます。
リビルド判断で累積パッチを断ち切る
小さな修正を10回積み重ねた結果、コードが泥沼化することがあります。増分修正を続けると、毎ターン「前の修正の文脈」がコンテキストに引きずられ、バグ修正のたびに周辺コードの再読が発生し、結局同じ成果物をN倍のトークンで作っている状態になる。
筆者が使っているトリガー文言は「今知っていることを踏まえて、一度捨ててエレガントに作り直して」。一見もったいなく見えますが、実際には累積パッチを続ける場合は毎ターン前の文脈を引きずるため線形コストが発生する一方、全体再構築なら初期コストは高いものの以降のセッションがクリーンになる。総コストでは後者が逆転することが多い。「もう一度書き直したほうが早い」と感じた時点で、それは数値的にも正しい判断です。
並列ツール呼び出しでラウンドトリップを削る
「git statusを見せて」→ 結果確認 →「git diffも見せて」のように独立した操作を別メッセージに分けると、ラウンドトリップが増えてセッション長が伸びます。
CLAUDE.mdに「独立した操作は同一メッセージで並列実行」と明記しておくと、Claudeが自律的に並列化するようになる。往復削減はそのままコンテキスト累積の削減でもあるので、3層スタックやキャッシュ最適化の効きを底上げする土台施策と考えるとよいです。
ここで挙げた4つの追加施策はすべて追加費用ゼロ。設定・習慣・判断基準の変更だけで効きます。
実測で効果を検証する
施策を入れたら必ず数字で確認する。やらないと「効いた気がする」で終わります。
ccusageによるトークン可視化
ccusageはClaude Code/Codex CLIのローカルJSONLファイルから使用量を集計するOSSのCLIツール。npx ccusage@latestを叩くだけで日次・月次・セッション別のコストレポートが見られます。
# 日次レポート（デフォルト）
npx ccusage@latest
# モデル別ブレークダウン
npx ccusage@latest daily --breakdown
# プロジェクト別集計
npx ccusage@latest daily --instances --project content-pipeline--breakdownオプションを付けるとOpus・Sonnet・Haikuそれぞれのコスト内訳が見えるので、3層スタックが意図通り機能しているか確認できます。
参考: ccusage公式リポジトリ{target=”_blank” rel=”noopener noreferrer”}
Before/Afterのコスト比較
筆者がcontent-pipelineに3層スタック＋Prompt Cache最適化を入れる前後でccusageの集計値を見ると変化が出ます。記事評価フェーズはHaiku、構成生成はSonnet、最終リライトの難所のみOpusと振り分けただけでセッション単価が半分以下になりました。
重要なのは「単発タスク」ではなく「継続的なワークロード」で測ること。1回だけのタスクではキャッシュの効果が出ないので、同じ系統のタスクを3〜5回回した平均で評価する必要があります。
ROIで見るプラン選択の判断基準
プラン選択の月額しきい値は次の通りです。
| 月間トークン | 推奨プラン | 月額 |
|---|---|---|
| 〜50M | Pro + 必要に応じて従量 | $20 |
| 50M〜200M | Max 5x | $100 |
| 200M〜1B | Max 20x | $200 |
| 1B超 | API直 + Batch APIで50%オフ | 変動 |
筆者は2026年3月27日からMaxプラン5x（$100/月）に乗り、複数の自動化パイプラインを並行稼働させていますが、Pro $20/月で従量課金にした場合より割安に収まっています。
月$300超えたら絶対Max——これが筆者の閾値です。Maxプランへの移行と料金感の実体験については個人開発記事に詳しく書きました。Opus 4.7・Sonnet 4.6・Haiku 4.5の副業でのモデル使い分けも参考にしてください。
ccusageで自分の使用パターンが見えてくると、無駄なOpus呼びに自然と気づくようになります。可視化が一番効きます。
よくある質問（FAQ）
- QOpusPlanパターンを使えば本当に半分のコストになりますか？
- A
タスクの種類による。設計フェーズが大きく、実装が定型的なほど削減効果が高い。Zenn記事の実測では認証リファクタリングで54%削減。逆に実装9割のようなシンプルなタスクではOpusPlanの恩恵は限定的です。
- QPrompt Cacheは設定が必要ですか？
- A
Claude Codeなら設定不要。自動でキャッシュマーカーを配置します。「先頭部分を変えない」「画像をメッセージ末尾に置く」といった運用ルールを守れば十分機能します。APIの直接操作では cache_control フィールドの指定が必要です。
- Q原始人モードってどう設定しますか？
- A
SessionStart hookで「敬語・クッション言葉・前置きを排除し、技術的中身だけを返答」という規約をプロンプト注入します。セッション間で永続させ、「通常モード」といった指示で解除。応答が短くなる分、出力トークンが減り、料金比1:5の効果でコスト削減につながります。
- Qccusageで見られる「Cache creation」と「Cache read」の違いは？
- A
Cache creation（書き込み）は標準入力の1.25倍（5分TTL）または2倍（1時間TTL）。Cache readは標準の10%。比率を見ると最適化が機能しているかわかります。Cache readがCache creationの数倍以上なら、キャッシュが活躍している。Creation主体ならキャッシュが毎回壊れている可能性があります。
- Q個人開発でもこの戦略は意味がありますか？
- A
ある。むしろ予算が限られた個人ほど効果的です。月$100のMax 5xで全部Opusに振ると週次レート制限で詰まる。Sonnet中心に切り替えると稼働時間が2～3倍に伸びます。Claude Codeで個人サービスを作った実例もあります。
まとめ
Claude Codeのコスト削減で押さえるべきポイントは3つだ。
- 3層スタックでモデルを使い分ける。設計はOpus（5〜10%）、実装はSonnet（55〜65%）、雑務はHaiku（25〜35%）。OpusPlanパターンが特にROIが高い。
- Prompt Cacheとコンテキスト管理で無駄な再計算を防ぐ。CLAUDE.mdを安定させ、/compactは50%超で予防的に使う。サブエージェントとagent-browser CLIで大量データをメインコンテキストから切り離す。
- 追加コストゼロの運用施策を重ねる。原始人モードで出力を削り、リビルド判断で累積パッチを断ち切る。ccusageで実測して、意図通りに振り分けられているかチェックする。
3つを組み合わせれば、50〜75%のコスト削減は現実的に達成できる。導入順序は3層スタック→キャッシュ最適化と原始人モード→コンテキスト管理の順が進めやすい。
セッション中のトークン消費を「ゼロ」にする運用
本記事の3層スタック・Prompt Cache・原始人モードと並んで、もう1つコスト構造に効く施策がある。それが「セッション中の LLM 呼び出しをそもそも発生させない」アンビエント蓄積型のナレッジベース運用だ。
SessionEnd hook でtranscriptをファイルコピーするだけ（LLM未呼出）、結晶化は深夜の Task Scheduler に逃がす。日常運用中の追加トークン消費は完全にゼロになる。MCP 経由の Obsidian 連携と違い、毎セッション数千〜数万トークン食う問題が消える。
📘 Claude Codeに記憶を持たせる｜Obsidian Second Brain実装ガイド全文版（¥980）
本記事のコスト削減施策の延長として、運用全体のトークン消費構造を変える実装を全コード公開している。
- PowerShell hook・スラッシュコマンド4つ・サブエージェント3つ・Task Scheduler 設定の全コード(約350行)
- サブエージェントに
model: sonnetを明示してデフォルト Opus 引きを防ぐ運用ルール - 3週間運用実測: transcript 28本 / wiki 14トピック / 日常運用の追加トークン消費 0
- 3週間で踏んだハマりポイント8件と回避策(Task Scheduler の stdin 警告 exit 1 問題ほか)
