blog

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

監修

河合 継（クリスタルメソッド株式会社 代表取締役）

AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組でのAI解説実績を持つAI研究者として、AIの研究開発を主導している。
運営会社について ｜ 編集方針

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 CLI （ターミナル）

ANTHROPIC_BASE_URL

LiteLLM等ゲートウェイ Messages API互換変換層

OpenAI互換API

Ollama / LM Studio ローカル推論サーバー

LLM ローカル

ユーザー端末 非公式・動作保証なし localhost:11434 / 1234

⚠ サードパーティLLMはClaude Code公式サポート対象外。ゲートウェイ経由での接続も動作保証なし。 ツール呼び出し形式の差・thinking/prompt caching等の拡張機能非対応により挙動が不安定になりうる。

図1: ローカルLLM接続の基本構成。Claude CodeはAnthropic Messages API互換ゲートウェイ（LiteLLM等）を介してローカル推論サーバーへ接続する。この構成はClaude Code公式の動作保証対象外である。出典: Claude Code公式 LLMゲートウェイ

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

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

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

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

いずれの場合も、実際に動作するモデルは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料金・プラン解説記事にまとめてある。

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

ローカル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接続を組織的な開発環境や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入門ガイドから始めることを勧める。

ローカルLLM導入判断フロー

機密コード・オフライン要件あり？ GPU / Apple Silicon を調達済みか？

Yes ゲートウェイ経由の 非公式構成を検証 （動作保証なし）

No 費用対効果を再試算 クラウドAPIも検討 （Bedrock/Vertex等）

tool use対応・コンテキスト長・ライセンスを確認 LiteLLMゲートウェイ経由で接続・十分な検証を実施 本番利用は公式サポート対象のCloud構成を推奨
図2: ローカルLLM導入判断フロー。セキュリティ要件・ハードウェア調達状況・コスト比較を順に検討し、採用可否を判断する。ローカルLLM接続はClaude Code公式の動作保証対象外であることに注意。

弊社が開発するDeepAIは、機械学習・深層学習（CNN）を用いた2D画像認識・異常検知に特化したソリューションだ。ソファーのような不定形な製品の正常・異常分類において弊社DeepAIでは実際におよそ99%の精度を実現しており、コーディングエージェントとは異なる用途で産業向けAI活用を支援している。ローカルLLMによる開発効率化と組み合わせた製造・検査ラインの自動化について相談したい方は、弊社クリスタルメソッドまでお問い合わせいただきたい。

まとめ

Claude Codeは公式にはAnthropic Messages APIクライアントであり、OllamaやDeepSeek、Qwenといったサードパーティ製ローカルLLMの直接サポートは存在しない（Claude Code公式 モデル設定）。ローカルLLMとの接続を試みる場合は、LiteLLM等のAnthropic Messages API互換ゲートウェイを介する非公式な構成が現実的な選択肢だが、ツール呼び出し形式の互換性やClaude Code固有の拡張機能（thinking・prompt caching等）については動作保証がない（Claude Code公式 LLMゲートウェイ）。

公式にサポートされる代替ホスティングはAmazon Bedrock（公式）・Google Vertex AI（公式）・Microsoft Foundry（公式）の3系統であり、いずれもClaudeモデルを別環境でホストするものだ。セキュリティ要件やコスト要件によっては、これらの公式サポートルートを優先的に検討するべきであり、ローカルLLM接続は実験的・検証的な用途に留めることを推奨する。

参考文献

関連記事

AIブログ購読

　
クリスタルメソッドがお届けする
AIブログの更新通知を受け取る

Study about AI

AIについて学ぶ

  • Claude Code 公式ドキュメント完全読解ガイド｜導入判断から運用まで

    Claude Code 公式ドキュメント完全読解ガイド｜導入判断から運用まで

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code ベストプラクティス完全解説｜実装現場で使える設計指針2026

    Claude Code ベストプラクティス完全解説｜実装現場で使える設計指針2026

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

  • Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    Claude Code 自動化の実装ガイド――設計・事例・セキュリティを徹底解説

    監修 河合 継（クリスタルメソッド株式会社 代表取締役） AI・ディープラーニングに関する特許16件の発明者。国立がん研究センターとの共同研究や、テレビ番組での...

View more

AIで、業務の生産性を変革しませんか？

無料デモ・資料請求は1分で完了。お気軽にお問い合わせください。

無料デモを試す お問い合わせ