Claude Code ローカルLLM完全ガイド――構成・手順・モデル選定まで

Claude Codeは公式にはAnthropicのMessages APIクライアントとして設計されており、OllamaやDeepSeekといったサードパーティLLMの直接サポートは公式ドキュメントに記載がない。ただし、ANTHROPIC_BASE_URL環境変数でエンドポイントを差し替えることで、Anthropic Messages API互換ゲートウェイを介してローカルLLMと接続する構成が試みられている。本記事ではその仕組みと限界、実装上の注意点を公式情報に基づいて整理する。

Claude Code ローカルLLM接続の全体像――アーキテクチャと公式の立場

Claude Codeは、デフォルトではAnthropicのAPIエンドポイントへ通信してクラウド上のClaudeモデルを呼び出す。公式ドキュメント（Claude Code公式 LLMゲートウェイ）によれば、ANTHROPIC_BASE_URLに任意のゲートウェイURLを指定し、ANTHROPIC_AUTH_TOKENまたはANTHROPIC_API_KEYで認証することで、Anthropic Messages API互換のゲートウェイを経由した接続が可能になる。

重要な前提として、OllamaやDeepSeek、Qwenといったサードパーティ製LLMはClaude Codeの公式サポート対象ではない。公式が対応しているのは、あくまで「Claudeモデルの別ホスティング」（Amazon Bedrock・Google Vertex AI・Microsoft Foundry）と「Messages API互換ゲートウェイ」（LiteLLM等のサードパーティOSSを含む）の2系統だ（Claude Code公式 モデル設定）。ローカルLLMを接続するには、OllamaやLM Studioが公開するOpenAI互換APIを、LiteLLMのようなゲートウェイでAnthropic Messages API形式へ変換する層を挟む必要がある。この構成は動作保証のない非公式な試みであることを前提として理解しておく必要がある。

なお、OLLAMA_BASE_URL・DEEPSEEK_API_KEY・QWEN_ENDPOINT・LLM_MODEL_OVERRIDEといった環境変数はClaude Codeに存在しない。これらの名称を見かけた場合は、情報源の信頼性を確認されたい。

Claude Code全般の概要はClaude Codeとはを、インストール手順の詳細はClaude Codeインストール手順記事を参照されたい。

Claude Codeでローカルのllmは使える？

結論として、Claude CodeでOllamaやLM StudioなどのローカルLLMを使うことは技術的に可能ですが、Anthropic公式のサポート対象ではありません。ANTHROPIC_BASE_URL環境変数にLiteLLMなどのゲートウェイのURLを指定し、OpenAI互換APIをAnthropic Messages API形式に変換すれば接続自体は成立します。

ただしAnthropicの公式ドキュメントでは「Anthropicはサードパーティ製ゲートウェイ製品を推奨・保守・監査しておらず、いかなるゲートウェイを通じてもClaude Code以外のモデルへのルーティングをサポートしない」と明記されています。つまり接続はできても動作保証はなく、Tool use（関数呼び出し）の互換性が完全でない、Thinking・プロンプトキャッシュなど拡張機能が使えないといった制約が伴います。APIコストの削減やオフライン運用が目的であれば選択肢になりますが、複雑なタスクでの推論品質や動作の安定性を重視する場合はクラウド版のClaudeモデルを利用するのが現実的です。

公式サポートされるモデル接続――クラウドプロバイダ経由とゲートウェイ経由

ローカルLLM接続の設計を検討する前に、Claude Codeが公式にサポートする接続方式を把握しておく必要がある。公式ドキュメントが明示する接続先はいずれもClaudeモデルのホスティング先変更か、Messages API互換ゲートウェイの2種類だ。

クラウドプロバイダ経由（Claudeモデルを別環境でホスト）

• Amazon Bedrock: CLAUDE_CODE_USE_BEDROCK=1 を設定し、AWS認証を構成する（Claude Code公式 Amazon Bedrock）。
• Google Vertex AI: CLAUDE_CODE_USE_VERTEX=1 を設定し、GCP認証を構成する（Claude Code公式 Google Vertex AI）。
• Microsoft Foundry: CLAUDE_CODE_USE_FOUNDRY=1 を設定する（Claude Code公式 Microsoft Foundry）。

いずれの場合も、実際に動作するモデルはAnthropicのClaudeである。サードパーティLLMへの切り替えとは根本的に異なる。

LLMゲートウェイ経由

Anthropic Messages API（/v1/messages）と互換性のあるゲートウェイであれば、ANTHROPIC_BASE_URLにゲートウェイのURLを指定することで接続できる（Claude Code公式 LLMゲートウェイ）。ゲートウェイ側には/v1/messagesの実装とanthropic-beta・anthropic-versionヘッダの転送が必要だ。認証はANTHROPIC_AUTH_TOKENまたはANTHROPIC_API_KEYで行う。

サードパーティOSSのLiteLLMはこの互換ゲートウェイの代表的な実装例として言及されているが、AnthropicによるLiteLLM自体の動作保証はない点に注意が必要だ。

ローカルLLM接続のセットアップ手順――LiteLLMゲートウェイを介した構成例

以下はLiteLLMゲートウェイ経由でOllamaのローカルLLMをClaude Codeに接続する際の概略手順だ。これは公式サポート対象外の構成であり、ツール呼び出し（function calling）の互換性や拡張機能（thinking・prompt caching・長コンテキスト等）については動作保証がない。検証・実験的用途に限定して利用されたい。

1. Ollamaをインストールし、対象モデルを取得する。
   ollama pull gemma4:26b（例）
2. Ollamaの推論サーバーを起動する。デフォルトポートは11434。
   ollama serve
3. LiteLLMをインストールし、OllamaのOpenAI互換エンドポイントをAnthropic Messages API形式へ変換するゲートウェイとして起動する。具体的な設定はLiteLLMの公式ドキュメントを参照のこと。
4. Claude Code側の環境変数を設定する。ANTHROPIC_BASE_URLにLiteLLMゲートウェイのURLを指定する。
   export ANTHROPIC_BASE_URL=http://localhost:4000（LiteLLMのデフォルト例）
   export ANTHROPIC_API_KEY=dummy（ローカル利用時はダミー値を設定）
5. claudeコマンドを起動し、応答が返ることを確認する。

なお、claude-code-routerなどのコミュニティツールでローカルLLMとの接続を試みる事例もあるが、これらは非公式・無保証であり、Claude Codeのアップデートにより予告なく動作しなくなる可能性がある。APIキーを仲介する構成はセキュリティリスクも伴うため、本番環境への採用は推奨されない。

動作確認で最初に踏むトラブルとその対処

接続後に頻出するのがtool use（関数呼び出し）非対応に起因するエラーだ。Claude Codeはファイル操作・コマンド実行・コード編集をfunction callingで呼び出す設計になっており、この機能を正確に実装していないモデルでは会話が成立しないかエラーが連続する。さらに、Claude Code固有の拡張機能（thinkingモード・prompt caching・大容量コンテキスト等）はローカルLLMでは利用できない。モデル選定の段階でtool use対応状況を確認するのは必須工程だ。

次に多いのがコンテキスト長不足だ。Claude Codeはエージェントとして複数ターンにわたる長いコンテキストを保持する。Ollamaの場合はnum_ctxパラメータを明示的に設定しなければデフォルト値（モデルによっては4K程度）で動作し、長大なコードベースを扱う最中に無言でトランケートされる問題が発生する。起動オプションまたはModelfileで32K以上に引き上げることを推奨する。

Claude Codeのスラッシュコマンドや操作全般についてはClaude Codeスラッシュコマンド解説とClaude Codeの使い方ガイドも参照されたい。

推奨モデル比較と選定基準――2026年6月時点で実用に耐えるローカルモデル

GMOエンジニアブログ（2026/04/20）は、十分なGPUメモリを備えたデスクトップPCであればGemma 4（26B-A3B）が有効な選択肢と報告し、Qwen3系も有力候補として言及している（GMO Next Generationブログ, 2026/04/20）。Knowleful AI（2026/04/22）は「2026年にローカルLLMが注目されているのは、使わない理由がなくなってきたから」と評し、コーディング性能の底上げを背景として指摘している（Knowleful AI, 2026/04/22）。

Harmonic Society（2026/03/22）は「量子化によってモデルサイズを圧縮し、少ないVRAMでも動作させることが可能」と整理しており（Harmonic Society, 2026/03/22）、Q4_K_M等のフォーマットを使えばVRAM 12GB前後の一般的なデスクトップGPUでも30B規模のモデルを動作させられる場合がある。ただし量子化の深さに比例してコーディング精度が低下するリスクも伴う。

Mac環境では、Reddit（r/LocalLLaMA）のスレッドでMac Studio M3 Ultra（256GBユニファイドメモリ）を推論サーバーとして活用している事例が報告されており（Reddit r/LocalLLaMA）、Apple Siliconの大容量ユニファイドメモリがローカルLLM実行環境として有効に機能することが確認できる。

以下の比較表は2026年5〜6月時点で入手可能な情報をもとに整理したものだ。推論速度・品質はハードウェア環境により大きく変動するため、あくまでモデル選定の出発点として参照されたい。なお、これらのモデルはいずれもClaude Codeの公式サポート対象外であり、ゲートウェイを介した接続においても動作が保証されるわけではない。

表1: Claude Code ローカルLLM接続 モデル候補比較（2026年6月時点・非公式構成）

モデル	パラメータ規模	VRAM目安	tool use対応	コーディング適性	主な特徴・留意点
Gemma 4 (26B-A3B)	26B（MoEアーキテクチャ）	約16GB	対応	高	Google製MoE。Claude Codeとの連携報告あり（非公式）。量子化版で12GB環境にも対応可
Qwen3系（30B前後）	30B前後	約18〜24GB	対応	高	多言語・コーディング双方に強い。Function calling実装の完成度が高い
Qwen2.5-Coder系	7B / 32B	6GB〜20GB	モデルサイズによる	高（コーディング特化）	コード補完・補修に特化。7B量子化版は低スペック環境でも動作
DeepSeek-Coder-V2系	16B〜（MoE上位は大規模）	10GB〜（量子化依存）	一部対応	高	大規模コードベースの理解に強いとされるが、tool use互換性は要検証
Llama 3系（8B）	8B	約6GB	対応	中	省リソース・汎用。軽量構成の動作確認や入門的な試験運用に適する

モデル選定で外せない実務上のチェックポイントは3点だ。第一にtool use（function calling）の対応状況、第二にコンテキスト長（実用上32K以上が望ましい）、第三に商用ライセンスの可否だ。これらを満たさないモデルをバックエンドに採用しても、エージェント動作が安定しない。加えて、Claude Code固有の拡張機能（thinking・prompt caching等）はいずれのローカルLLMでも利用できない点を前提として計画する必要がある。

Claude CodeをクラウドAPIで運用する場合のコスト構造についてはClaude Code APIの料金詳細解説を参照されたい。ローカル運用との費用対効果を比較する際の基準値になる。また、Claude Code料金プランの全体像はClaude Code料金・プラン解説記事にまとめてある。

VRAM容量別 推奨構成の早見表

上表のモデル軸に加えて、「自分の環境のVRAMでどれが動くか」から逆引きできるよう、容量別に整理する。数値は上表に記載のVRAM目安をもとにした構成の目安であり、実際の必要量は量子化方式・コンテキスト長・同時実行プロセス数によって変動する。

迷う場合は、まず自分のGPUのVRAM容量を確認し、上の早見表で「動く」候補に絞ってから、前掲の比較表でtool use対応・コーディング適性を照合する、という2段階の絞り込みが実務的である。

セットアップでつまずきやすい点

ローカルLLM側のOpenAI互換API（Ollama・LM Studioとも標準搭載）をLiteLLMゲートウェイ経由でClaude Codeに接続する際、実際の構成作業でつまずきやすいのは主に次の点である。

• エンドポイントのパス指定漏れ：Ollama・LM StudioともOpenAI互換APIは /v1 を含むパス（例: http://localhost:11434/v1）で待ち受けている。ゲートウェイ側の設定でこの /v1 を書き忘れると、接続自体はできても応答がエラーになる。
• ツール本体のバージョン差：Ollama・LM Studioとも更新頻度が高く、tool use（function calling）の互換性はバージョンによって挙動が変わることがある。Ollamaは2026年7月時点でv0.32.5系がリリースされており、導入前に自分の環境のバージョンをollama -v等で確認し、公式リリースノートで既知の不具合を確認しておくと手戻りが少ない。
• モデルの量子化形式とtool use対応の不一致：同じモデルでも量子化版によってはfunction calling用のチャットテンプレートが欠落している配布物があり、「動くが tool use だけ効かない」という状態になりやすい。導入前に配布元のモデルカードでtool use対応の明記を確認する。

この記事の検証スタンスについて

本記事はClaude Codeを自社開発現場で1年以上日常的に運用している知見（自社サイトの表示速度改善など、実運用で得た一次情報）をもとに、「公式にサポートされる範囲」と「非公式だが技術的には接続可能な範囲」を意図的に切り分けて記載している。ローカルLLM接続は非公式構成であるため、本記事では実在しないコマンドや未確認のバージョン挙動を断定的には書かず、公式ドキュメントで確認できる情報と、実際に日常業務でClaude Codeを使う中で得た運用上の注意点とを区別して提示することを方針としている。

よくある質問

コスト削減・セキュリティの実態とトレードオフ――ローカル運用の限界を正確に把握する

ローカルLLM接続を検討する主要な動機は2つだ。APIコストの排除と、コード・データを外部へ送出しないセキュリティ要件の充足。機密性の高いソースコードや個人情報を扱うプロジェクトでは、ネットワーク外への通信を物理的に遮断できる点が意思決定の決め手になることが多い。

IPAが2026年3月に公開した「AIセキュリティ短信 2026年3月号」は、LLMを活用したシステムにおけるリスク管理の重要性とデータ送信先の管理体制について言及している。組織的なセキュリティポリシーの観点からクラウドLLMの利用可否を検討する際の参照資料として有用だ（IPA AIセキュリティ短信 2026年3月号）。

IPAの2025年度未踏IT人材発掘・育成事業の採択案件評価書でも、LLMを活用した開発支援ツールの実用化において「モデルの出力精度と応答速度のバランス」が開発体験を左右する重要因子として言及されており（IPA 2025年度未踏IT人材採択案件評価書）、ローカル運用においても同じ観点が適用される。

一方でトレードオフも明確に存在する。採用前に把握しておくべき主要な制約を以下に整理する。

• 推論品質の差: 2026年時点においても、複雑なリファクタリング・大規模アーキテクチャ設計・曖昧な要件からの仕様起こしなど、難度の高いタスクではクラウド上の最新世代Claudeモデルが依然として品質優位を持つ。シンプルなコード生成や補完には対応できる場合があるが、要件の複雑さに応じてローカルとクラウドを使い分ける判断が求められる。
• 拡張機能の非対応: thinkingモード・prompt caching・大容量コンテキスト（1Mトークン等）はローカルLLMでは利用できない。これらの機能に依存したワークフローはローカル構成では再現できない。
• 初期投資と損益分岐点: 高性能GPU（RTX 4090等）やApple Silicon搭載Macの調達費用は数十万円規模になる。APIの利用頻度が低いチームでは、クラウドAPIの課金総額が調達費用を下回る可能性があり、単純な「コスト削減」の論理が成立しないケースがある。
• インフラ管理オーバーヘッド: モデルのバージョン管理・量子化設定・推論サーバーの安定稼働・ゲートウェイ（LiteLLM等）の維持管理など、クラウドAPIにはないインフラ管理コストが発生する。特に複数人が共有する開発環境では設計が煩雑になる。
• tool use互換性の個体差: tool useの実装品質はモデルごとに差があり、同じモデルでもバージョンや量子化フォーマットにより挙動が変わることがある。セットアップ段階での徹底した動作確認を必須工程として位置づける必要がある。
• 非公式構成のサポートリスク: Claude Codeのアップデートにより、ゲートウェイ経由の接続が予告なく動作しなくなる可能性がある。本番環境への採用は慎重に検討されたい。

J-STAGEに掲載された「LLM時代における障害者のソフトウェア開発参加の可能性」（LAM Vol.3）は、LLMを用いた開発支援が多様な開発者の参加機会を拡大する可能性を論じており（J-STAGE, LAM Vol.3）、ローカルLLMの普及がオフライン・機密環境の開発者にも恩恵をもたらしうるという視点は、ユニバーサルな開発環境整備を考える上で参照に値する。

ローカルLLM接続を現実的にどう使うか（一次情報）

当メディアの監修者・河合継はClaude Codeを3.5の時代から1年以上、実務で運用してきた。ローカルLLM接続は魅力的に見えるが、実際に効く場面は限られる。期待と現実のギャップを補足する。

• 主力の開発はホストされたモデルに任せ、ローカルは目的を絞る。込み入った実装や難しいデバッグでは、品質差がそのまま手戻りに跳ね返る。ローカルLLMは「外に出せないコードを扱う」「オフラインで動かしたい」といった、品質より制約が優先される場面に絞ると失望が少ない。
• 「コストが浮く」は運用と機材のコストまで含めて考える。API料金は減っても、動かすマシン・セットアップ・保守の手間が乗る。トータルで本当に得かは扱う量と求める品質次第で、安易な「ローカル＝無料」では計算が合わないことが多い。
• 機密性が目的なら、接続経路と権限まで設計する。モデルをローカルにしても、周辺の通信や権限設計が緩ければ意味が薄れる。本文の注意点のとおり、目的が機密保持なら経路全体を設計して初めて効果が出る。

実装上の注意点とセキュリティ設計――本番導入前に確認すべき事項

ローカルLLM接続を組織的な開発環境やCIパイプラインへ組み込む際には、単なる動作確認を超えた設計判断が求められる。

エンドポイント認証とネットワーク分離

OllamaをはじめとするローカルLLMサーバーは、デフォルトで認証なしのエンドポイントを公開する設定になっている場合が多い。複数人が利用する共有開発環境では、バインドアドレスの制限（localhostのみ許可）またはリバースプロキシでの認証付加を設計段階から組み込む必要がある。開発機と推論サーバーが異なるホストになる場合は、VPN経由の通信を基本として設計するべきだ。IPAのAIセキュリティ短信が示すLLMシステムのリスク管理の観点は、ローカル運用においても同様に適用される（IPA AIセキュリティ短信 2026年3月号）。

モデルライセンスの事前確認

商用利用可否・再配布条件はモデルごとに異なる。Gemma、Qwen、Llama系それぞれのライセンス条項を法務確認した上で採用する必要がある。量子化・GGUF変換版は元モデルのライセンスを継承することが多いが、変換元と変換版で条件が異なる場合もあるため個別確認が必要だ。エンタープライズ利用においてこの確認を省略するリスクは高い。

プロンプト・ログの管理

ローカル運用であってもプロンプトのログは残る。コードに含まれる認証情報・APIキー・個人情報がログに混入するリスクを考慮し、ログの保存先・保存期間・アクセス権限を明確に定義しておく必要がある。特にCI環境でClaude Codeを自動実行する場合は、ログのマスキング処理を組み込むことを推奨する。

量子化精度と実用性のバランス

VRAM制約からQ3_K_Sなど深い量子化を選ぶと、コーディングタスクでの精度低下が顕著になる場合がある。実際の開発タスク（例: 特定コードベースへの機能追加、バグ修正）でのベンチマークを自組織の環境で取得し、許容できる精度水準を定量的に把握した上で量子化フォーマットを確定することを勧める。Harmonic Society（2026/03/22）が指摘するように量子化による軽量化は有効な手段だが（Harmonic Society, 2026/03/22）、精度との兼ね合いを自組織のユースケースで検証する工程は省略できない。

Claude CodeとCursorの比較・ツール選定の観点についてはClaude Code vs Cursor比較記事を参照されたい。ローカルLLM対応の有無はツール選定の重要な軸の一つになる。また、Claude CodeとCodexの比較についてはClaude Code vs Codex比較記事も有用だ。初めてClaude Codeに触れる場合はClaude Code入門ガイドから始めることを勧める。