Claude Code × Ollama でコストを抑える — ローカルLLM 使い分け

Claude Code を本格的に使い始めると、月末の請求額に一度は驚くのではないでしょうか。私自身、複数サイトの自動化ワークフローで Claude Code を酷使していたとき、思ったより早くコストが膨らんでいくのを感じました。

そこで試してみたのが「ローカル LLM との使い分け」です。すべてのタスクを Claude に任せるのではなく、定型的・繰り返し系のタスクは手元の GPU で動く Ollama に振ります。複雑な設計や判断が必要なタスクだけ Claude Sonnet/Opus にお願いします。この棲み分けで、私の環境では API コストを体感で 50〜60% 程度削減できました。

なぜローカル LLM × Claude Code なのか

Claude Code は強力ですが、リクエスト単価が安くはありません。Sonnet で入力 $3/1M トークン、Opus で $15/1M トークン（2026年5月時点）。ちょっとしたファイル整形や定型コメント生成が積み重なると、じわじわコストがかさみます。

一方、Ollama はローカルマシンで LLM を動かすためのランタイムです。一度モデルをダウンロードしてしまえば、それ以降は完全無料。GPU がなくても CPU で動きますし、M シリーズ Mac なら Apple Silicon の恩恵で思ったより快適に使えます。

ポイントは「全部ローカルにしよう」ではなく「使い分け」です。Ollama で動く中規模モデル（Gemma 3 27B や Qwen 2.5 Coder など）は、Claude Sonnet と比べると複雑な推論や長いコンテキスト処理では見劣りします。ここを正直に理解したうえで、得意領域に集中させるのが肝です。

環境構築：Ollama + litellm プロキシ

Claude Code はリクエスト先として ANTHROPIC_BASE_URL 環境変数を参照します。ここを litellm プロキシに向けることで、Claude Code からのリクエストを Ollama に中継できます。litellm 側が Anthropic Messages API 形式のリクエストを受け取り、Ollama 用の形式に変換し、返ってきた応答をまた Anthropic 形式に戻してくれる、という仕組みです。

1. Ollama をインストール

# macOS（curl インストール）
curl -fsSL https://ollama.com/install.sh | sh
 
# Homebrew の場合
brew install ollama
 
# サービス起動
ollama serve &
 
# モデルをダウンロード（コーディング用途なら Qwen2.5-Coder または Gemma 3）
ollama pull qwen2.5-coder:32b
# GPU メモリが少ない場合は 14B か 7B に
# ollama pull qwen2.5-coder:14b

ollama run qwen2.5-coder:32b で動作確認しておきましょう。「Hello, how are you?」など簡単な質問を投げて返答が返れば OK です。

2. litellm をインストール

litellm は、Anthropic・OpenAI・Ollama などの異なる API フォーマットを統一的に扱えるプロキシです。

# uv を使う方法（推奨・環境を汚さない）
uv tool install 'litellm[proxy]'
 
# pip でも入ります
pip install 'litellm[proxy]'

3. litellm の設定ファイルを作成

~/.claude-local/litellm_config.yaml を作成します。

ここで一つ、私が最初にやって遠回りした設定があります。Claude Code が内部で使うモデル ID（claude-sonnet-4-5 のような文字列）を model_name に書いて乗っ取る、というやり方です。動きはするのですが、Claude Code 側の既定モデルが更新されるたびに設定が空振りするようになり、原因の切り分けに時間を取られました。

いまは自分で決めた名前を付けて、起動時にその名前を指定する方式に落ち着いています。設定が Claude Code のバージョンに依存しなくなります。

# Claude Code → litellm → Ollama のルーティング設定
model_list:
  # 主力: コード理解が必要なローカル作業用
  - model_name: local-coder
    litellm_params:
      model: ollama_chat/qwen2.5-coder:32b
      api_base: http://localhost:11434
 
  # 軽量: リネームやコメント追加など反射的な作業用
  - model_name: local-fast
    litellm_params:
      model: ollama_chat/qwen2.5-coder:14b
      api_base: http://localhost:11434
 
general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

master_key は外部に公開するキーではなく、プロキシに触れるのは自分だけという前提を機械的に担保するためのものです。ローカル専用でも設定しておくことをおすすめします。ポート番号は設定ファイルではなく起動オプションで渡します（既定は 4000）。

注意: Ollama は Anthropic Messages API に完全準拠しているわけではないため、ツール使用（tool_use）など高度な機能は litellm 側で互換処理が行われます。機能によっては動作しない場合もありますので、実際の利用前に確認しておくと安心です。

4. litellm プロキシを起動して疎通を確認する

export LITELLM_MASTER_KEY="sk-local-$(openssl rand -hex 8)"
litellm --config ~/.claude-local/litellm_config.yaml
 
# バックグラウンドで動かしたい場合
nohup litellm --config ~/.claude-local/litellm_config.yaml > /tmp/litellm.log 2>&1 &

起動すると http://0.0.0.0:4000 でリクエストを待ち受けます。Claude Code をつなぐ前に、Anthropic 形式のエンドポイントが応答するかを直接叩いて確かめておくと、あとの切り分けが楽になります。

curl -X POST http://0.0.0.0:4000/v1/messages \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "local-coder",
    "max_tokens": 128,
    "messages": [{"role": "user", "content": "2 + 2 は?"}]
  }'

ここで応答が返らないのに Claude Code を起動すると、Claude Code 側のエラー表示だけを見て原因を探すことになります。プロキシ・Ollama・Claude Code のどこで止まっているのかを、この一手間で確実に分けられます。

Claude Code を litellm プロキシに向ける

環境変数を 2 つ設定し、起動時に使うモデル名を渡します。認証情報は ANTHROPIC_API_KEY ではなく ANTHROPIC_AUTH_TOKEN に入れます。前者は本物の Anthropic キーと取り違えやすく、切り替え忘れの事故につながりやすいためです。

export ANTHROPIC_BASE_URL="http://0.0.0.0:4000"
export ANTHROPIC_AUTH_TOKEN="$LITELLM_MASTER_KEY"
 
# 設定ファイルで付けた名前をそのまま指定する
claude --model local-coder
 
# 軽い作業なら
claude --model local-fast

切り替えをスムーズにするために、シェルエイリアスを用意しておくと便利です。

# .zshrc に追記
 
# Claude API（本番）モード
alias cc-cloud='unset ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN'
 
# ローカル LLM（節約）モード
alias cc-local='export ANTHROPIC_BASE_URL=http://0.0.0.0:4000 && export ANTHROPIC_AUTH_TOKEN=$LITELLM_MASTER_KEY'

いまどちらのモードにいるかを右プロンプトに出しておくと、うっかり事故が減ります。

# .zshrc のプロンプト設定
# ANTHROPIC_BASE_URL が設定されている場合は黄色表示で知らせる
RPROMPT='%F{yellow}${ANTHROPIC_BASE_URL:+[LOCAL]}%f'

セッションを閉じずに /model で切り替える

エイリアス方式の弱点は、切り替えるたびに Claude Code を落として立ち上げ直す必要がある点です。作業の文脈が毎回リセットされるため、私はここが一番のストレスでした。

Claude Code v2.1.129 以降であれば、ゲートウェイのモデル一覧を取り込む機能を有効化することで、セッションを保ったまま /model で切り替えられます。

export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1
claude

この状態で起動すると、Claude Code は ANTHROPIC_BASE_URL に対して GET /v1/models を投げ、返ってきたモデルを /model の選択肢に「From gateway」として並べます。設定ファイルに書いた local-coder や local-fast がそのまま出てくる、ということです。

私の使い方はこうです。まず local-fast で下ごしらえをして、設計判断が必要な場面になったら /model でクラウド側に上げる。会話の履歴を保ったまま担当を入れ替えられるので、「安いモデルで粗く進めて、要所だけ良いモデルに任せる」が自然な操作になりました。

なおこの機能は既定では無効です。環境変数を設定しない限り Claude Code はプロキシの /v1/models を叩きに行かないため、有効化を忘れると選択肢は増えません。

どのタスクをローカルに振るか — 判断軸

「何でもかんでもローカルに振ればいい」というわけではありません。私が実際に使って感じた境界線を、判断の理由とあわせて整理します。

表を作ってみて改めて言葉になったのは、境界線を引いているのは「タスクの難しさ」ではないということでした。判断に迷ったときの基準は一つです — この作業、AI が間違えたとき自分ですぐ気づけるか。気づけるならローカル、間違いが静かに紛れ込むならクラウド。難易度ではなく検算のしやすさで切っています。

よくある落とし穴と対策

落とし穴 1: Ollama サーバーが落ちていてエラーになる

Claude Code 起動前に Ollama が動いているか確認するのを忘れがちです。起動スクリプトを用意しておきましょう。

#!/bin/bash
# ~/bin/start-local-claude.sh
 
# Ollama が起動していなければ起動
if ! pgrep -x "ollama" > /dev/null; then
  echo "Ollama を起動します..."
  ollama serve &
  sleep 3
fi
 
# litellm が起動していなければ起動
if ! curl -s http://0.0.0.0:4000/health/liveliness > /dev/null 2>&1; then
  echo "litellm プロキシを起動します..."
  nohup litellm --config ~/.claude-local/litellm_config.yaml > /tmp/litellm.log 2>&1 &
  sleep 2
fi
 
echo "ローカル Claude Code モードの準備が整いました"
cc-local

chmod +x ~/bin/start-local-claude.sh で実行権限を付けておきます。

落とし穴 2: tool_use が期待通りに動かない

Claude Code は内部的にファイル操作や検索を tool_use として実装しています。ローカル LLM がこの形式に対応していない場合、エラーや予期せぬ挙動が起きることがあります。特にファイル編集を伴う複雑な操作では、ローカルモードが途中で詰まることがあります。そういった場合は素直に cc-cloud でクラウドに切り替えるのが最善です。

落とし穴 3: ローカルモードのまま本番作業をしてしまう

プロンプトへのモード表示（前述の RPROMPT 設定）と、作業前の echo $ANTHROPIC_BASE_URL 確認を習慣にすることをおすすめします。

API コストの実際の変化

コスト削減の効果は使い方によって大きく変わります。私の場合、1日に Claude Code を 4〜6 時間使うセッションで、以前は月 $40〜60 かかっていたものが $20〜30 前後まで下がりました。特に、記事生成補助やコード整形などの反復作業をローカルに振ったのが効いています。

正直に付け加えると、この差額は「浮いたお金」ではありませんでした。ローカルに振った分だけ私の確認作業が増えているからです。個人開発で全工程を一人で抱えている以上、削れたコストと引き換えに増える手間は必ず自分の時間に返ってきます。それでも続けているのは、金額そのものより「このタスクは本当に高い方に投げる価値があるか」と毎回考える癖がついたことの方が効いていると感じているためです。

litellm を使ったより高度なマルチプロバイダー構成については、Claude API と litellm で組むマルチプロバイダー AI ゲートウェイで詳しく扱っています。クラウド側でどのモデル階層を使うかの判断については、Claude Code のモデル選択と Opus+Plan モード戦略もあわせてご覧ください。

実装現場でやってよかった3つの判断

半年ほどこの構成で運用してきて、設定の細部より効いていたのは次の 3 つでした。どれも最初から分かっていたわけではなく、遠回りをした結果として残ったものです。

1. モデル ID を乗っ取らず、自分で名前を付けた

claude-sonnet-4-5 のような実在のモデル ID に Ollama を割り当てる方式は、書いた直後は気持ちよく動きます。破綻するのは Claude Code 側が既定モデルを更新したときです。設定は変えていないのに挙動だけが変わるため、原因にたどり着くまでが長い。local-coder のような自分の語彙で名前を付けておけば、Claude Code の更新と自分の設定が切り離されます。運用を止めない設定とは、正しい設定より壊れ方が分かりやすい設定のことでした。

2. Claude Code をつなぐ前に、必ず curl で疎通を確かめた

最初のうちは Claude Code から直接試して、エラーが出るたびに Ollama・litellm・環境変数のどこが原因か手探りしていました。/v1/messages に curl を一本投げる工程を挟むだけで、切り分けが三分の一になります。層をまたぐ構成では、下の層が生きていることを先に確定させる。これは Claude Code に限らず、私が自動化パイプラインで何度も学び直してきたことです。

3. 「難しさ」ではなく「検算しやすさ」で振り分けた

当初はタスクの難易度でローカルとクラウドを分けていました。うまくいかなかった理由は明確で、簡単に見える作業ほど確認を省いてしまうからです。ローカルモデルが静かに間違えたコメントを書いても、私はそれを読み飛ばしていました。判断軸を「間違いに気づけるか」に置き換えてから、振り分けの精度が上がりました。安いモデルに任せてよいのは、失敗が自分に返ってくる作業だけです。

まとめ — まず 1 つのタスクをローカルに振るところから

「Claude Code + ローカル LLM」の設定は、一度動かしてしまえば使い分けが自然と身につきます。最初の一歩として、Ollama に qwen2.5-coder:14b をダウンロードし、設定ファイルに local-fast として登録して、コメント追加だけをそこに振ってみてください。所要時間は 20 分ほどです。

重要なのは「完全移行」ではなく「使い分けの習慣」です。複雑な設計判断はやはり Claude の方が質が高い。ローカル LLM はその補佐として使う — この役割分担が、コストと品質を両立させる現実的な答えだと感じています。

私自身まだ調整を続けている途中ですが、同じようにコストと向き合っている方の手がかりになれば嬉しいです。お読みいただきありがとうございました。