ローカルLLMをClaude Code / Codex CLIから使う：Ollama接続の実行ログと限界、使い所

ローカルLLMをClaude CodeやCodex CLIから使う話は、2026年9月時点ではプロキシなしで動くところまで来ています。OllamaとLM Studioの両方がAnthropic互換の /v1/messages とOpenAI互換の /v1/responses を実装しているので、Claude Codeは ANTHROPIC_BASE_URL を、Codexは --oss を向けるだけで接続できます。

問題は「動くか」ではなく「どこまで使えるか」です。この記事では、公式ドキュメント（Ollama、Claude Code、Codex、LM Studio、LiteLLM）で設定方法を確認したうえで、RTX 3090でClaude CodeとCodexをそれぞれ1往復ずつ実際に動かし、トークン消費と挙動をそのまま載せます。Ollamaの導入はOllama導入ガイド、モデル選びは用途別モデル選び 2026を参照してください。

構成の全体像

Claude Code × Ollama

公式が示す設定

Ollama公式の「Claude Code」ページの手動設定は、環境変数3つと claude --model です。

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
claude --model qwen3-coder:30b

ollama launch claude を使うと、モデル選択のプロンプトが出て設定と起動まで自動で行われます（ollama launch claude --model gemma4:cloud --yes -- -p "prompt" のように非対話でも呼べる、と同ページにあります）。Ollama側は「大きなコードベースではコンテキスト長を64K以上に」と推奨しています。

Claude Code側の仕様は「Connect Claude Code to an LLM gateway」と「Gateway compatibility guide」にあります。ANTHROPIC_BASE_URL に向けた先は Anthropic Messages形式として扱われ、/v1/messages と任意の /v1/messages/count_tokens が呼ばれること、ANTHROPIC_AUTH_TOKEN は Authorization: Bearer、ANTHROPIC_API_KEY は x-api-key ヘッダに乗ること、設定を永続化するなら ~/.claude/settings.json の env ブロックに書くこと、が明記されています。

{
  "env": {
    "ANTHROPIC_BASE_URL": "http://localhost:11434",
    "ANTHROPIC_AUTH_TOKEN": "ollama"
  }
}

まず curl で /v1/messages を確認

Claude Codeの公式ドキュメントも「先にcurlで1トークン投げて疎通を確認」を勧めています。Ollamaに対して実行した応答です。

{"id":"msg_906c680ecdc295181b7aa081","type":"message","role":"assistant",
 "model":"qwen3-coder:30b",
 "content":[{"type":"text","text":"OK from local"}],
 "stop_reason":"end_turn","usage":{"input_tokens":15,"output_tokens":4}}

{"id":"msg_ で始まり content 配列があれば疎通OK、というのが公式の判定基準です。

実行ログ

Claude Code 2.1.261 を -p（非対話）で、Ollamaの qwen3-coder:30b に向けて実行しました。プロンプトは「このディレクトリにある .json ファイルの名前を列挙して、最後に1行で要約してください」です。

ANTHROPIC_AUTH_TOKEN=ollama ANTHROPIC_API_KEY= ANTHROPIC_BASE_URL=http://localhost:11434 \
  claude --model qwen3-coder:30b -p "..." --output-format json

出力（要点のみ抜粋）です。

[claude-code:unrecognized_model] {"model":"qwen3-coder:30b","query_source":"sdk"}
duration_api_ms: 25275
num_turns: 2
is_error: false
usage.input_tokens: 51877   usage.output_tokens: 549
result: ファイル一覧:
- egov/pkg/package/package.json
- kokkai-out/speech1.json
- openapi.json
...（省略）

モデルはディレクトリを走査するツールを呼び、実在するファイル名を列挙して要約まで返しました。ollama ps を見ると、Ollamaは要求に合わせて qwen3-coder:30b を32,768コンテキストでロードし直し、VRAMは21GBでした（8Kでロードしたときは17.95GiB）。

気づいた挙動

• 起動時に「claude.ai connectors are disabled because ANTHROPIC_API_KEY or another auth source is set」と警告が出ます。ゲートウェイ資格情報が有効な間はclaude.aiのログインが使われない、という公式ドキュメント通りの挙動です。
• [claude-code:unrecognized_model] の警告は出ますが処理は続きます。公式の互換性ガイドには「認識できないモデル名は現行モデルとして扱い、thinking: {"type": "adaptive"} を送る」とあり、Ollama側がこのフィールドを受け流したようです。拒否された場合はClaude Codeが再試行して当該機能を無効化する、とも書かれています。
• total_cost_usd は0.27ドルと表示されますが costBasis: "unknown" で、ローカル実行の実コストは電気代だけです。

Codex CLI × Ollama

公式が示す設定

Codexの「Advanced Configuration」には、openai ollama lmstudio の3つが予約済みの組み込みプロバイダで、--oss フラグで「ローカルの open source プロバイダ」に切り替え、--local-provider か config.toml の oss_provider でどちらを使うか選ぶ、とあります。

oss_provider = "ollama"   # または "lmstudio"

任意のOpenAI互換サーバーを使う場合は [model_providers.<id>] を定義して model_provider で参照します。Ollama公式の「Codex CLI」ページに載っている例は次の形です（wire_api = "responses"、つまりOllamaの /v1/responses を使う）。

model = "gpt-oss:120b"
model_provider = "ollama-launch"

[model_providers.ollama-launch]
name = "Ollama"
base_url = "http://localhost:11434/v1/"
wire_api = "responses"

Ollama側も「Codexはより大きなコンテキストが必要。64K以上を推奨」と明記しています。ollama launch codex で設定を自動生成し、ollama launch codex --restore で戻せます。

実行ログ

Codex 0.144.1 で、return a - b になっている add 関数を置いた calc.py に対し、読み取り専用サンドボックスで実行しました。既存の config.toml は編集せず、フラグだけで切り替えています。

codex exec --oss --local-provider ollama -m gpt-oss:20b -s read-only \
  "calc.py を読んで、バグがあれば1行で指摘してください。ファイルは編集しないでください。"

model: gpt-oss:20b
provider: ollama
sandbox: read-only
warning: Model metadata for `gpt-oss:20b` not found. Defaulting to fallback metadata
exec  pwsh -Command 'Get-ChildItem -Recurse -Filter calc.py'   succeeded in 1523ms
exec  pwsh -Command "Get-Content -Path ...\calc.py"           succeeded in 1273ms
codex
`add`関数が減算（ `return a - b` ）になっており、本来の加算に直す必要があります。
tokens used
49,894

ファイルを探し、読み、正しい指摘を1行で返すまで完走しました。起動時に「failed to refresh available models: … missing field models」というエラーがログに出ましたが、これはCodexがOllamaの /v1/models（OpenAI形式の data 配列）を独自形式で読もうとして失敗したもので、実行自体には影響しませんでした。フォールバックのメタデータで動くという警告も同様です。

LM Studio と LiteLLM という代替

LM Studio も同じ2つの互換APIを持ちます。公式の「Anthropic Compatibility Endpoints」は ANTHROPIC_BASE_URL=http://localhost:1234、ANTHROPIC_AUTH_TOKEN=lmstudio、claude --model openai/gpt-oss-20b を案内し、2026-01-30のブログでは「コンテキストは最低25Kから、増やすほど良い」としています。「OpenAI Compatibility Endpoints」には「Codexは /v1/responses を実装しているので対応」と明記。同日に google/gemma-4-e4b をロードして /v1/messages を叩いたところ、Ollamaと同じ形式で "OK from LM Studio" が返りました。Claude CodeやCodex本体をLM Studioに向けての実行はしていません。

LiteLLM が必要になるのは、Anthropic形式を持たない推論サーバー（vLLMなど）をClaude Codeにつなぐ場合です。LiteLLM公式ドキュメントによると、プロキシの /v1/messages は「Anthropic messages仕様に従い」openai、bedrock、vertex_aiなど各プロバイダへ変換します。Ollamaは ollama_chat/<model> の形で model_list に登録します。

# LiteLLM config.yaml（公式ドキュメントの形式。本記事では未実行）
model_list:
  - model_name: "local-coder"
    litellm_params:
      model: "ollama_chat/qwen3-coder:30b"
      keep_alive: "8m"

Claude Code側は ANTHROPIC_BASE_URL=http://localhost:4000 と LiteLLMのキーを ANTHROPIC_AUTH_TOKEN に入れる形になります。筆者の環境にはLiteLLMが入っておらず、この経路は公式仕様の確認のみで実行していません。

できること・できないこと・期待値

実行ログと公式仕様から、現時点の線引きはこうなります。

できる

• ファイルの探索・読み取り・要約・バグ指摘のような、ツール呼び出し1〜2回で終わる作業（Claude Code、Codexとも今回完走）
• 機密コードを外に出さずにエージェントの手順だけ試す
• ollama launch claude / ollama launch codex による設定の自動化と復元

条件付き

• コンテキストは64K以上（Ollama公式推奨）。Claude Codeは1ターン約26Kトークンを入力するので、8Kや16Kでは初手で溢れる。24GB GPUでqwen3-coder:30bを32Kで動かすと21GBまで使う（VRAM別モデルサイズ早見参照）
• モデルに tools capabilityが必須。ollama show で確認
• 思考モデルは出力トークンを推論で使い切ることがある。gpt-oss:20bは think: false を付けても思考を返した

できない・未検証

• Claude Codeのプロンプトキャッシュ、token countingによる正確な /context、Remote Control（ゲートウェイ資格情報が有効な間は無効、と公式に記載）
• コスト表示の信頼（costBasis: unknown）
• 複数ファイルにまたがる実装やリファクタの品質は、本記事では実行していません。ローカルとクラウドの代替率は別途J-WorkBenchの記事で扱っていますが、そちらの数値は現時点でサンプル値なのでここでは引用しません

どの作業をローカルに寄せるか

接続できることと、仕事を任せられることは別です。ここからの線引きは運用上の目安で、上の実行ログで裏付けたのはツール呼び出し1〜2回で終わる読み取り作業までです。

ローカルLLMを選ぶ理由は「無料だから」だけではありません。コードを外部APIに送らない運用にしやすい、API従量課金を抑えやすい、大量の単純タスクを回しやすい、モデルや量子化を自分で検証できる、ネットワーク制約のある環境でも使いやすい、といった点があります。その代わり、GPU・メモリ、セットアップ、モデル選定、速度、品質のばらつきは自分で引き受けます。

ローカルに向くのは、パターン化しやすく、失敗しても影響が小さい作業です。

• READMEやコメントの下書き
• テストケースのたたき台
• 単純なリファクタ候補の列挙
• 型エラーの説明
• 小さなスクリプト生成
• コードレビュー前の予備チェック

ローカル単体では慎重に扱うのは次の作業です。クラウドモデルを使う場合でも人間のレビューが要る領域で、ローカルならさらにタスクを小さく切る必要があります。

• 認証・決済・権限まわりの実装
• 複数サービスをまたぐ障害調査
• 大規模リファクタリング
• 暗黙知の多い古いコードの改修
• 長時間の自律実行
• 仕様が曖昧な新機能開発

現実的なのは、ローカルに下調べ・単純修正・テスト案・コメント生成を、クラウドに設計判断・複雑なバグ修正・大規模変更・レビューを任せるハイブリッドです。ローカルLLMに本番判断は任せず、下書き・候補出し・検査役として使うと安定します。Claude Code / Codex CLIのほか、ClineやContinueなどのエディタ拡張からOllamaやLM Studioのモデルを呼ぶ構成もあります（ツール選びはAIコーディングエージェント選定ガイド）。

導入前には次を確認します。

• ローカルLLMに任せるタスクを限定した
• 機密コードをローカルで扱う理由が明確
• モデルのライセンスを確認した
• 量子化、メモリ要件、コンテキスト長を確認した
• 失敗時にクラウドLLMへ切り替える基準がある
• 出力を人間がレビューする前提になっている

まとめ

• OllamaもLM Studioも /v1/messages と /v1/responses を実装済み。Claude Codeは ANTHROPIC_BASE_URL、Codexは --oss でプロキシなしに接続できる
• Claude Code 2.1.261 + qwen3-coder:30b: 2ターン、入力51,877トークン、API 25.3秒でファイル列挙と要約が返った
• Codex 0.144.1 + gpt-oss:20b: 探索→読み取り→バグ指摘まで完走、49,894トークン
• LiteLLMはAnthropic形式を持たないサーバー向け。公式仕様は確認したが未実行
• Anthropicは非Claudeモデルをサポート外と明記。64K以上のコンテキスト、tools 対応、VRAMの余裕が前提で、コスト表示は架空
• ローカルに寄せるのは下書き・読み取り・予備チェックのような失敗の影響が小さい作業から。設計判断や大規模変更はクラウドと人間のレビューに回す

「ローカルで動くか」の答えはYesになりました。どの作業をローカルに寄せ、どこからクラウドに戻すかは、上の目安をもとに読み取り中心の作業から試して決めるのが安全です。損益の考え方はローカルLLMの損益分岐、両CLIの使い分けはClaude Code vs Codexに続きます。