Claude Codeの全文生成だけで月12.4Mトークン溶けたので、Ollama下書きで4.9Mまで削った話

Claude Codeで新規ファイルを量産していたら、月のトークン消費が12.4Mに達して3週間でレートリミットに当たりました。

最後の5日間は/compactを6回連打して凌ぎ、月末2日は完全に手が止まりました。最初は「プランを上げるしかないのか」と思ったんですが、/costで使用ログを集計してみたら、原因はプランの大きさではなく全文生成タスクの多さでした。今回はそれを別LLMに逃がして、翌月のトークン消費を4.9Mまで削った話です。

先に断っておくと、月100ドルプランそのものの損得判断はこの記事では扱いません。料金プランをどう選ぶかは別記事に分けます。ここでは「同じプランのまま全文生成だけを減らす実装」に絞ります。Pro maxに上げるか悩んでいる人より、「いまのプランのまま消費を半分にしたい」人向けの内容です。

Claude CodeとOllamaをハイブリッドにする前にやらかした失敗(5時間消滅)

ハイブリッドの話に入る前に、私がやらかした派手な失敗を共有させてください。

「Claude Codeが高いなら全部Ollamaでよくない?」と考えて、3時間かけてgemma3:12bに200行のCSV集計スクリプトを書かせました。動かしたら最初はエラーが出た、というレベルではなく、最初の20行で落ちて止まりました。デバッグに2時間かかって、結局Claude Codeに「全部見直して」と投げ直す羽目になり、合計5時間がほぼ無駄になりました。

内訳はこんな感じです。

• 型ヒントが微妙に間違っている: 6箇所
• 実在しないモジュールをimport(urllib.requestsという存在しないやつ): 1箇所
• try/exceptが空っぽ: 4箇所
• エンコーディング指定なしで日本語CSVを開いて文字化け: 1箇所

しかも数字を出したあとに気づいたんですが、集計結果が正解と12,800円ズレていました(187件中42件が別カテゴリに混入)。これに気づくのに翌日まで6時間。修正したClaude Codeへの投げ直しに約40分。最初からClaude Codeで書かせていれば1時間で終わっていた作業です。

ここで学んだのは、ローカルLLMに「完成品」を求めてはいけないということでした。ローカルが得意なのは型どおりの骨格を吐くところまでで、ロジック検証と仕上げを兼任させた瞬間に破綻します。

Claude CodeとOllamaをハイブリッドにした理由(トークン内訳の話)

失敗から立て直すために、Claude Codeの自分の使用ログを集計しました。/costコマンドで出る数字を1ヶ月分Excelに転記しただけです。

• 新規ファイルの全文書き起こし: 約45%
• 既存コードの局所修正(Edit)とレビュー: 約25%
• 設計判断・原因究明・対話: 約20%
• その他(ファイル探索・差分確認など): 約10%

つまり全文書き起こし1つで使用枠の半分近くを持っていかれていました。書き起こしの中身は関数定義・import文・docstring・引数チェックといった「型どおりの骨格」が大半で、ここに毎回最高級のLLMをぶつけるのは贅沢すぎました。

ここから出てきた仮説が、「骨格はローカル、仕上げと検証はClaude」という役割分担です。骨格生成の45%をOllamaに逃がせるなら、それだけで使用量は大きく減る計算になります。

私の環境(参考までに)

• Windows 11 Pro
• GPU: RTX 4060 8GB
• メモリ: 32GB
• Ollama: 0.4系
• モデル: gemma3:12b(Unsloth Dynamic 2.0 量子化版)
• Claude Code: Max 5xプラン

gemma3:12bを選んだ理由は、8GB VRAMで実用速度が出る最大級のモデルだからです。7Bだとコードの構造把握が甘く、20B以上だとRTX 4060では遅すぎてストレスでした。日本語の指示にもそこそこ素直に従ってくれます。

Claude Code Ollama ハイブリッドの導入手順(3ステップ)

最終的に落ち着いた手順を残します。コピペで動くはずです。

ステップ1: Ollamaを入れてgemma3:12bを引く

# Ollama公式インストーラ(Windowsはexe)で導入後
ollama pull gemma3:12b
ollama serve

ollama listでgemma3:12bが出ればOK。初回pullは約8GBあるので、回線によっては15分前後かかります。

ステップ2: scaffoldラッパーを置く

scaffold.pyという30行ほどのラッパーをかませる構成です。Claude Codeが新規ファイルを作るときに、内部的に1ステップだけ挟みます。

# tools/scaffold.py
import json
import sys
import time
import urllib.request
from pathlib import Path

OLLAMA_URL = "http://localhost:11434/api/generate"
MODEL = "gemma3:12b"

PROMPT_TEMPLATE = """\
あなたはPythonコードの骨格だけを書く下書き担当です。
完成品ではなく、関数定義・import文・docstring・引数チェックだけを正しく書いてください。
ビジネスロジックの中身は `# TODO: implement` のままで構いません。
余計な解説は不要です。コードだけ返してください。

依頼:
{request}
"""


def scaffold(request: str) -> str:
    payload = {
        "model": MODEL,
        "prompt": PROMPT_TEMPLATE.format(request=request),
        "stream": False,
        "options": {"temperature": 0.2, "num_ctx": 8192},
    }
    data = json.dumps(payload).encode("utf-8")
    req = urllib.request.Request(OLLAMA_URL, data=data, method="POST")
    req.add_header("Content-Type", "application/json")
    with urllib.request.urlopen(req, timeout=120) as resp:
        body = json.loads(resp.read().decode("utf-8"))
    return body.get("response", "").strip()


if __name__ == "__main__":
    request = " ".join(sys.argv[1:]) or sys.stdin.read()
    out_dir = Path("output/scaffolds")
    out_dir.mkdir(parents=True, exist_ok=True)
    stamp = time.strftime("%Y%m%d_%H%M%S")
    out_path = out_dir / f"{stamp}.py"
    out_path.write_text(scaffold(request), encoding="utf-8")
    print(str(out_path))

ステップ3: Claude Code側の運用ルールに1行追加する

CLAUDE.md(プロジェクト直下)に下記を1行入れるだけです。

新規ファイル作成時はまず `python tools/scaffold.py "<依頼内容>"` を実行し、出力された骨格を読んでから仕上げに入る。

これでClaude Codeは新規ファイルを書くとき、まずscaffoldの出力を読み込み、TODO部分だけ埋める動作に変わります。「全文書き起こせ」と頼むより「下書きを見ながら埋めて」と頼むほうが、Claude側の出力量がずっと短くなります。

失敗談その2: 「下書き丸呑み」で集計が4,200円ズレた

ハイブリッドにして1週間ほど経ったとき、地味だけど痛い事故をもう1つ起こしました。

Claude Codeに「scaffoldの出力をそのまま使っていいよ」と投げる場面があって、生成されたスクリプトをそのまま実行したところ、想定と違うCSVカラムを参照していて中身の集計が全部ズレていました。気づいたのは翌朝、出てきた合計が明らかにおかしくて再計算したときです。差は約4,200円。原因切り分けに1時間半、修正に20分かかりました。

原因はシンプルで、Ollamaが生成した骨格に紛れ込んだ架空のカラム名(amount_jpyという、実際のCSVには存在しないフィールド)を、Claudeが「TODOを埋めるだけ」モードだったので無批判に使ってしまったんです。ローカルLLMは「ありそうな名前」を平気で創作してきます。

それ以降、scaffoldの出力には必ず「この骨格を検証してから使って。架空の関数名・カラム名・モジュール名がないかチェックして」という1行を添えるようにしました。具体的にはscaffold呼び出し後にClaude Codeへ渡す指示文に固定で入れる運用です。これで同じ事故は再発していません。

ハイブリッドは便利ですが、「下書きは下書き」と扱う規律を運用ルールに組み込まないと、安く速いだけのバグ製造機になります。

トークン節約できた作業、できなかった作業

導入前と導入後を、Claude Codeの/costコマンドで出る使用量で比較しました。

• 導入前(4月): 約12.4M トークン消費、月末3週間でレートリミット到達
• 導入後(5月): 約4.9M トークン消費、レートリミット0回

差し引き約60%減でした。私の場合、新規ツール作成が週に2、3本ある業務スタイルだったので、骨格生成のオフロード効果が大きく出たんだと思います。逆に「既存コードの修正がメイン」の使い方ならここまで減らないはずです。

副次効果として、ローカルLLMで雑に試行錯誤できるようになったので、「これ作るかどうか迷う」というアイデアを気軽にscaffoldだけ流して、骨格を見てから判断する習慣ができました。Claude課金を気にせずアイデアを叩けるのは精神衛生上もよかったです。

具体的にハイブリッドが効いた作業と効かなかった作業を整理するとこうなります。

トークン削減が大きかった作業:

• 新規Pythonスクリプトの骨格(50行以上のもの)
• ライブラリのラッパー関数
• argparseの引数定義
• 型ヒント・docstringのまとめて追加

トークン削減が小さい/逆効果だった作業:

• 既存ファイルの局所Edit(数行差し替え)
• 原因究明系のデバッグ
• 設計判断が絡むリファクタ
• 仕様が曖昧な探索フェーズ

「下書きしてから磨く」より「直接書く」のほうが効率的な領域があるという話です。最初の2週間は上の4つだけハイブリッド化して、それ以外はClaude単独に戻すのが事故も少なくて済みました。

振り返って

1ヶ月前の自分に伝えたいのは、「料金プランを触る前に、ワークフローを2段にしてみてくれ」です。Claude Codeの価値は思考の質と最終アウトプットの精度にあって、骨格を書くこと自体ではないんですよね。そこを別のLLMに任せても、Claude Codeの良さは1ミリも損なわれませんでした。

しかも下書き役のOllamaは無料です。ハードがあれば、というか8GB VRAMさえあれば、月60%のトークン削減がほぼ追加コストなしで手に入ります。これに気づくのに3週間と5時間の失敗1回と4,200円の集計ズレが必要だったのが少し悔しいですが、気づけてからは毎月安定して同じプランで運用できています。

「Claude Codeがすぐ枠を使い切ってしまう」と感じている人は、プランを触る前に一度ハイブリッドを試してみてください。私の環境では実際にやってみた結果、これはコストではなく運用設計の問題だったことがわかりました。