ローカルLLMとClaude APIを月1000回使い続けて、コストの現実が見えてきた話

最終更新: 2026-04-28

正直に言う

最初は「Ollamaでほぼ無料でいける」と思ってた。

電気代だけで動く。APIクレジットは減らない。月5万円収益化を目指してパイプラインを組み始めた頃、そう判断した。合理的だと思っていた——実際に3ヶ月ログを取り続けるまでは。

結論を先に言うと、「全部Ollamaに置き換えれば安くなる」は半分正解で半分嘘だった。嘘の半分が、けっこう痛かった。

---

使った構成と測定条件

環境はMacBook Pro M5 32GB。ローカルLLMは qwen3.5:9b をメインに使っていて、Claude は Haiku と Sonnet を用途別に振り分けている。呼び出しはすべて 01_Scripts/lib/ai_client.py 経由で一元管理した。この設計が後でデータを取るときに効いた。

# ai_client.py の呼び出し側
result = await ai_client.generate(
    task="bsky_post",
    prompt=prompt,
    prefer_claude=True  # False にすれば即 Ollama へ
)

ai_config.yaml でタスクごとのモデル割り当てを定義してあって、prefer_claude: false に書き換えるだけで全パイプラインがOllamaに切り替わる。この一行で擬似的なABテストができた。測定期間中の月あたり呼び出し数はこんな感じ。

BSky投稿生成:       約300回
X投稿生成:          約200回
note記事生成:        約80回
ブログ記事:          約40回
KDP本文:             約30回
品質チェック:        約250回
Discord通知文:       約150回
その他（雑）:        約50回
------------------------------
合計:               約1100回/月

---

コスト実測値

Claude API 側は Haiku と Sonnet で単価が全然違う。Haiku（claude-haiku-4-5）は入力1Mトークンあたり$0.80、出力が$4.00。短い投稿文を量産するのに使っているので1回あたり平均200〜400トークン程度。Sonnet（claude-sonnet-4-6）は入力$3.00、出力$15.00で、記事生成に使うから1回2000〜4000トークンいく。

3ヶ月分の請求書をまとめると、月あたり平均で Claude 側に$8〜12かかっていた。円換算で1,200〜1,800円くらい。

Ollama側は qwen3.5:9b を M5 で動かしたときの電力消費がアイドル比較で15〜25W増加する。1回の推論が平均5〜15秒。月1100回換算で電気代は30〜60円ほど。

---

数字だけ見ると「全部Ollama」が正解に見える

1,200円 vs 50円。差は圧倒的に見える。

で、実際に「全部Ollama」の週を作った。prefer_claude: false に書き換えて、パイプライン全体を切り替えた。3日後に気づいた——note記事の文体が均一になりすぎていた。BSky投稿の「絵文字✨のみ」ルールを守れないケースが増えた。multi_agent_quality.py の品質スコアが下がった。

Claude使用時: 平均スコア 81.3/100
Ollama使用時: 平均スコア 67.4/100

14ポイント落ちた。スコアが下がると投稿キューに積まれるまでが遅くなる。投稿頻度が落ちる。エンゲージが下がる。収益化の速度が鈍る——という連鎖が、実際に1週間のデータに出た。「安くなった」どころか、パイプラインの回転が悪くなっていた。

---

結局どう振り分けたか

試行錯誤の末に今の設定になっている。

タスク	モデル	理由
BSky/X短文	Haiku	安くて速い、品質差が小さい
note/ブログ	Sonnet	品質差が顕著に出る
KDP本文	Sonnet	文章の一貫性が必要
品質チェック	Haiku	採点精度はHaikuでも十分
ログ解析/画像判定	Ollama	精度より速度優先
Discord通知文	Ollama	短くてフォーマットが固定

短文でフォーマットが決まっているものは Ollama で十分だった。「ログ異常を検知して Discord に通知する」みたいな処理は、文章の質より確実性のほうが大事だから。一方、読み物として成立させたい note 記事や KDP 本文は、Sonnet との差が体感でわかるレベルで出る。ここをケチると直接収益に影響する——これは感覚ではなく実測で確認した話だ。

---

キャッシュで劇的に変わった話

途中でプロンプトキャッシュを入れた。

ペルソナ設定を毎回システムプロンプトで渡しているタスクがある。私の場合、一ノ瀬泰斗のペルソナ指示が400字近くあって、それを毎回渡していた。キャッシュヒット率が上がると入力コストが90%オフになる仕組みだから、文字数が多いほど効く。ai_client.py にキャッシュ制御を入れてから、月のAPI費用が$12→$7に落ちた。コードの変更は数行だった。

# キャッシュ対象にするシステムプロンプト
system_content = [
    {
        "type": "text",
        "text": LONG_SYSTEM_PROMPT,
        "cache_control": {"type": "ephemeral"}
    }
]

施策の中でコスト変動が一番大きかったのがこれだった。モデルの切り替えよりも効いた。ペルソナ文が長ければ長いほど恩恵が大きいので、システムプロンプトを短くしようとしていた方向性が完全に逆だったと気づいた。

---

Ollama の「隠れコスト」

Ollama 側に見えないコストが2つある。

ひとつは遅さ。qwen3.5:9b でブログ記事を生成すると4〜8分かかることがある。Claude Sonnet だと30〜60秒。パイプラインが詰まって launchd のタイムアウトに引っかかったことが、最初の2週間で3回あった。ジョブが途中で死んでいることに気づかず、翌朝ログを見て発覚するパターン。原因を特定するまでに丸一日かかった。

もうひとつは試行回数の消費。品質スコアが C や D だと自動リトライが走る設計になっている。Claude で1回通るところが、Ollama だと2〜3回回ることがあった。トークンは無料でも、時間と電力は消費する。夜間バッチが予想より3時間以上伸びていたことが1週間後に発覚して、その原因がリトライの連鎖だとわかったときはさすがに苦笑した。

---

まとめ

「ローカルLLMを使えばAPIコストがゼロになる」は本当だ。ただ、「だから全部ローカルで」は、少なくとも私のパイプラインでは動かなかった。

月1,000〜1,100回使い続けて落ち着いたのはハイブリッド構成。短文・分類・通知は Ollama、長文・品質が問われるコンテンツは Claude。これで月のAPI費用は$6〜9程度に収まっている。

Ollama の本当の価値は「量産の自由度」だと思っている。試行を繰り返しても課金されないから、プロンプトの実験がやりやすい。品質を詰めた後にそのプロンプトを Claude に渡す——という使い方が、コスパ的に一番よかった。完璧な切り替えじゃなくて、タスクに合った使い分け。それだけ。✨

---

---

関連記事

• Ollama をlaunchdで常駐させたら Mac がフル稼働になった話——KeepAlive の罠と2日かかった原因特定
• Ollama と Claude API を月1000回使い比べてわかったハイブリッド構成の正解
• Claude Code hookでPythonスクリプトが黙って落ちる問題——パス・環境変数・作業ディレクトリの三重奏を全部解決した