BSkyへの投稿生成、note記事の下書き、KDP書籍の本文、Discordボットの返答——これを全部 Claude API に流してたら、月が終わる前に課金額を見て少し固まった。思ったより回っていた。1000回どころじゃなかった。launchd で朝昼晩に自動実行してるから、「気づいたら」が積み重なる。

それから3ヶ月かけてハイブリッド構成に移行して、ようやく落ち着いたのでまとめる。「どちらかに統一すればいい」という話じゃなかった。タスクの性質で完全に使い分ける、それだけだった。

Ollama vs Claude API — コスト観点の実態

まずざっくりした数字感から。

Ollama（ローカル）はモデルさえダウンロードすれば、生成コストはゼロだ。電気代と MacBook の発熱だけ。僕が今回すメインで動かしているのは qwen2.5:7b（旧 qwen3.5:9b）で、M5 の 32GB 環境だと体感で 3〜5秒/レスポンス。

Claude API は従量課金。Haiku が入力 $0.80/MTok・出力 $4/MTok、Sonnet がその 5〜10倍。1回あたりの生成コストに換算すると、1000トークン程度の出力なら Haiku で $0.004 前後。1000回まわすと $4。月4ドル。安く見えるが、Sonnet で長文記事を100本書いたら話が変わる。

# 概算モデル（あくまで僕の構成での計算）

Haiku: ~$0.004 / 1000トークン出力
Sonnet: ~$0.020 / 1000トークン出力

月1000回 × Haiku: 約 $4
月1000回 × Sonnet: 約 $20

Ollama (qwen2.5:7b): $0

Ollama がゼロコストに見えるのは正しいが、品質の差がある。これが問題の核心だった。

「全部 Ollama」で3日で挫折した

最初に試したのは「コスト削減のため全タスクを Ollama に切り替える」だった。ai_config.yaml の prefer_claude: false をセットして、全パイプラインを qwen に流した。

結果——BSky の投稿文は日本語がちょっとぎこちなくて、note 記事はスカスカで、KDP の本文は誤字まではいかないけど微妙なニュアンスのズレが積み重なった。

3日で戻した。ただし「全部戻す」じゃなくて「タスク別に分ける」に変えた。

ハイブリッド構成の答え

ai_client.py にタスク名ベースのルーティングを入れている。

# ai_client.py（抜粋）
TASK_ROUTING = {
    "bsky_post": {"use_claude": True, "model": "haiku"},
    "x_post": {"use_claude": True, "model": "haiku"},
    "note_article": {"use_claude": True, "model": "sonnet"},
    "kdp_book": {"use_claude": True, "model": "sonnet"},
    "quality_check": {"use_claude": True, "model": "haiku"},
    "tag_classify": {"use_claude": False},   # Ollama
    "log_parse": {"use_claude": False},      # Ollama
    "engagement_comment": {"use_claude": False},  # Ollama
}

「出力が外に出るか？」がまず一番の分岐点だ。BSkyや note に投稿される文章は Claude に任せる。読まれるものだから。逆に、ログの要約・タグ分類・内部処理は Ollama で十分だし、むしろ Ollama の方が速い（ローカルだから API ラウンドトリップがない）。

もう一個の分岐は「長文か短文か」。短文（SNS投稿、Discordボット返答）は Haiku で足りる。長文記事・書籍は Sonnet。Haiku で note 記事を書かせようとしたことがあるが、1500字で力尽きたような薄い構成になる。これは Haiku の限界じゃなくて、長い文脈を保持しながら論理を展開するのが苦手という特性だと理解した。

launchd との組み合わせで月何回まわってるか

現在のパイプライン稼働スケジュール（launchd ジョブ）:

07:00  sns_post_launcher.sh   → BSky投稿 + X投稿
12:30  sns_post_launcher.sh   → BSky投稿
20:30  sns_post_launcher.sh   → BSky投稿 + X投稿
01:00  engage_launcher.sh     → note/BSkyエンゲージ（5ステップ）
00:05  x_visual_content_engine → ビジュアル画像生成

✨ これが毎日自動で回っている。

SNS投稿生成だけで1日 8〜12回ほどの API 呼び出し。月30日で最大360回。そこに note 記事生成・KDP書籍執筆・エンゲージメントコメント生成が加わる。コメント生成は Ollama に任せているから、Ollamaの呼び出しは1日100回を超える日もある。

Claude API の月次呼び出しはざっくり 500〜700回。内訳は Haiku が7割・Sonnet が3割。Sonnet の出力量が多いのでコストはほぼ Sonnet に引っ張られる。

コスト計算してみた

# 2026-04月の概算（Claude API のみ）

Haiku 呼び出し: 約500回 × 平均600トークン出力 ≈ 300,000 トークン
  → 出力コスト: $1.20

Sonnet 呼び出し: 約200回 × 平均2000トークン出力 ≈ 400,000 トークン
  → 出力コスト: $8.00

入力トークン（推定）: 合計 600,000 トークン
  Haiku 入力: $0.48
  Sonnet 入力: $1.80

合計: 約 $11〜12 / 月

月千円強。これを「高い」と思うかは人次第だが、note 記事20本・BSky 投稿60本・KDP書籍4〜5本を自動生成しているコストだと思えば、体感はかなり違う。Ollama が担っているコメント生成・ログ解析・タグ処理も込みで動いているから、トータルの「AI生成量」に対するコストは相当抑えられている。

実際に詰まったところ

ai_client.py を書いたとき、claude -p 経由でサブプロセス呼び出しをしていた部分で変なエラーが出た。

Error: insufficient_quota

サブスクリプション利用なのに課金エラー？と思ったら、ANTHROPIC_API_KEY が環境変数にあると API 経由の認証を試みてしまうという問題だった。サブスクは API キー不要なのに、キーがあると「API で繋ごう→残高ゼロ→エラー」というフローになる。

# 修正後
env = {k: v for k, v in os.environ.items() if k != "ANTHROPIC_API_KEY"}
subprocess.run(["claude", "-p", prompt], env=env, ...)

これを入れてから安定した。新しいスクリプトで claude -p を使うたびに忘れそうになるので、コメントで残している。

どちらを選ぶかの判断フロー

まとめると、僕が今使っている判断基準はこれだ。

「外に出る文章か？」→ Yes なら Claude。No なら Ollama で試す。
「外に出る文章」の中で「長文か？」→ Yes なら Sonnet。No なら Haiku。
Ollama で試して品質が足りなければ Claude に格上げ。

ローカル環境が十分（M5/M4 あたり）なら Ollama の出力速度はストレスない。問題は品質の天井だけ。そこをちゃんと把握すれば、ハイブリッドは普通に機能する。「全部 Claude にすれば楽」という気持ちはわかるが、月のコストが読みにくくなるのが問題で——自動化が進むほど呼び出し回数が読めなくなるから。ローカルに逃がせるタスクは逃がす、が鉄則だと思っている。

まとめ

Ollama と Claude API は競合じゃない。役割が違う。

外に出る文章・品質が直結するものは Claude。内部処理・分類・要約・コメント生成のような「そこそこでいい」タスクは Ollama。月$10〜12 で自動化パイプライン全体を回せているのは、この分担がうまくいっているからだと思う。

「全部ローカルにすれば無料じゃん」というのは正論だが、品質の天井を感じたまま妥協するより、使うべきところに使う方が長続きする。自動化の目的は「楽に良いものを出し続けること」なので。

心理学で、人間関係をちょっとラクにする。

1ヶ月で気づいたこと