Claude CodeでOllamaのローカルモデルを使い、クラウドへ戻す方法
Claude Codeを使い込んでいる開発者向けの実践ガイドです。端末とタスクがローカル推論に向くか判断し、OllamaのAnthropic互換API経由でQwen3.5を接続します。1ファイルだけの可逆なテストで読み取り・編集・コマンド実行を確認し、コンテキストとCPU/GPU配置、互換性の限界を点検したうえで、必要なときは明示的にクラウドAPIへ戻します。
目次

Claude Codeは、OllamaのAnthropic互換APIを介してローカルモデルを利用できます。ただし、チャットで返答できたことと、coding agentとして実用になることは別です。実案件を任せる前に、モデルがツール呼び出しへ対応しているか、端末が少なくとも64kのコンテキストを維持できるか、タスクをコマンドとdiffで検証できる小さな範囲へ絞れるかを確認します。
この手順は、いつでも元へ戻せる構成にします。Ollama公式の方法でClaude Codeをqwen3.5へ接続し、1ファイルの受け入れテストを行い、推論が本当にローカルで動いているか、APIとデータの境界がどこにあるかを確認します。最後にローカル設定を明示的に外し、クラウドendpointへ戻します。以下のコマンドはmacOS、Linux、WSLのBash向けです。読者が自分の環境で実行するための手順であり、この記事がその端末で実測した結果ではありません。
最初に判断する:ローカル、クラウド、ハイブリッド
ローカルモデルに向くのは、範囲が明確で、結果を機械的に検証できるタスクです。大規模リポジトリ、サービス横断の移行、複雑な調査では、小さなローカルモデルを大量にCPU offloadして使うより、クラウドモデルのほうが実用的なことが多くあります。
| 作業 | 最初に試す経路 | 理由 |
|---|---|---|
| 1ファイルの修正、テスト1件の追加、局所関数の説明 | まずローカル | コンテキストを限定でき、コマンドとdiffで確認できる |
| 依存関係が明確な小〜中規模モジュール | ローカルまたはハイブリッド | smoke testを通してから徐々に範囲を広げられる |
| 大規模monorepo、サービス横断refactor、難しい障害調査 | まずクラウド | より大きな有効コンテキストと安定したツール計画が必要 |
| 64kを維持すると大きくCPU offloadする | まずクラウド | 遅延や停止でローカルの利点が薄れる |
| prompt caching、Batches API、PDFブロック、正確なtoken計数が必要 | まずクラウド | Ollamaが実装するAnthropic Messages APIは現時点で一部のみ |
| ソースコードをリモートモデルへ送れない | cloud機能を止めてローカル | web tools、MCP server、shell commandの通信は別途監査が必要 |
実用的なのは、範囲が狭く再現可能な変更をローカルに置き、リポジトリ全体の推論、未対応API機能、ローカルで繰り返し失敗するタスクだけ明示的にクラウドへ切り替える方法です。Claude Codeという同じ操作面を維持しながら、2つのbackendを同等だとは扱いません。
手順1:ツール対応モデルを選び、64kコンテキストを確保する
Claude Codeに必要なのは文章生成だけではありません。ファイルを読み、変更を適用し、コマンドを実行するには、モデルが安定してツール呼び出しを生成する必要があります。OllamaのQwen3.5モデルページにはtools対応とClaude Codeの起動コマンドが掲載されています。手元にpullした具体的なモデルは、Ollamaのmodel details APIでも確認できます。
モデルをpullし、capabilitiesを確認します。
ollama pull qwen3.5
curl http://localhost:11434/api/show \
-H "Content-Type: application/json" \
-d '{"model":"qwen3.5"}'
次へ進む前に、capabilitiesへtoolsが含まれていることを確認してください。含まれていない場合、普通のチャット返答をagentの検証代わりにしてはいけません。現在のOllamaライブラリで明示的にツール対応とされているモデルへ変更し、pull後にもう一度確認します。
2つ目の条件はコンテキストです。Ollamaのcontext lengthドキュメントは、web search、agent、coding toolに少なくとも64,000 tokensを推奨し、コンテキストを増やすほど必要メモリも増えると説明しています。Ollama Appではcontext lengthを64000以上へ設定します。shellからserviceを起動する場合は既存instanceを停止し、専用terminalで次を実行します。
OLLAMA_CONTEXT_LENGTH=64000 ollama serve
このterminalは開いたままにします。serverの起動を待って、別のterminalで作業を続けてください。portが使用中ならOllamaはすでに動いています。2つ目を起動せず、そのinstanceのcontext設定を変更します。
手順2:Ollama公式integrationからClaude Codeを起動する
最短の公式経路は次です。
ollama launch claude --model qwen3.5
まず接続を通すにはこの方法が簡単です。Claude Codeが起動したら/statusを実行し、読み込まれているsettings sourceを控えます。クラウドへ戻したつもりなのにOllamaへ接続し続ける場合、この情報から永続的なoverrideの場所を探せます。
変更を現在のterminalだけに限定するなら、環境変数を手動で設定します。以下もBashです。
read -rs ANTHROPIC_AUTH_TOKEN
export ANTHROPIC_AUTH_TOKEN
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL="http://localhost:11434"
claude --model qwen3.5
read -rsでは入力内容が表示されません。ollamaと入力してEnterを押します。Ollamaの互換endpointは認証変数の存在を求めますが、local serverは値を検証しません。ANTHROPIC_BASE_URLがモデルrequestをlocal Ollamaへ向け、--model qwen3.5がテスト対象を明示します。古いANTHROPIC_MODELや保存済みdefaultに結果を左右させないためです。
手順3:1ファイルで読み取り・編集・コマンド実行を検証する
最初のテストに本番repositoryを使わないでください。ファイル、終了status、diffのすべてを確認できる隔離directoryを作ります。
mkdir -p claude-ollama-smoke
cd claude-ollama-smoke
git init
cat > total.py <<'PY'
def total(values):
return sum(values)
if __name__ == "__main__":
assert total([2, 3]) == 5
PY
git add total.py
python3 total.py
python3 total.pyは何も表示せず、status 0で終了するはずです。このdirectoryからlocal Claude Codeを起動し、次のタスクを送ります。
total.pyだけを変更してください。
valuesの要素にintでもfloatでもない値があれば、totalがTypeErrorを送出し、エラーメッセージは正確にnumbers onlyとなるようにしてください。
__main__に[2, "3"]のチェックを追加し、同じTypeErrorとメッセージを確認してください。
python3 total.pyを実行してください。
他のファイルは変更しないでください。完了後にdiffを表示してください。
タスクは意図的に小さくしていますが、agentの重要な循環を確認できます。既存ファイルを読み、変更を計画し、編集toolを呼び、Bash commandの実行を求め、結果を観察し、最後の差分を提示する流れです。Claude Codeのpermission promptは有効なままにします。モデルがlocalでも、制限のないshellが安全になるわけではありません。
終了後、自分のterminalで次を実行します。
python3 total.py
git status --short
git diff -- total.py
ollama ps
受け入れ条件は次のとおりです。
python3 total.pyがstatus0で終わる。git status --shortにtotal.pyだけが現れ、git diff -- total.pyに要求した型checkとassertionだけが含まれる。- Claude CodeのtranscriptにファイルtoolとBash toolの呼び出し、またはpermission requestがあり、提案コードの文章だけではない。
- タスク中に
ollama psがqwen3.5を表示し、CONTEXTが64000以上で、PROCESSORからGPUのみ、部分offload、主にCPUのどれかを判断できる。
1つでも失敗したら、実際のrepositoryへ範囲を広げません。まず後半のtroubleshootingを行い、model変更、タスク縮小、cloud移行のどれが必要か判断します。
手順4:localhostだけでなく実行境界を確認する
ANTHROPIC_BASE_URL=http://localhost:11434は、Claude Codeのmodel requestがlocal portへ送られることを示します。ただし、workflow全体がofflineである証明にはなりません。より強い確認材料は、model tagに:cloudがないこと、タスク中にmodelがollama psへ現れること、PROCESSORとCONTEXTが端末の割り当てと一致することです。
OllamaのFAQは、local実行時にOllamaがpromptやdataを見ない一方、cloud-hosted modelではpromptとresponseをcloud serviceが処理すると説明しています。現在のQwen3.5ページでClaude Code用に示されているのはlocal tagのqwen3.5です。local tagにsuffixを付けてcloud model名を推測しないでください。cloud boundaryを確認するなら、現在の公式Cloud catalogまたはintegration guideに明記された有効なtag、たとえばgemma4:cloudを使います。実際の実行場所は、有効なtag、ollama ps、local resource allocationを組み合わせて判断します。
次のnetwork経路は別に監査します。
- Bash経由で実行されたcommandはnetworkへ接続し、fileをuploadし、別のCLIを呼べます。
- MCP serverには独自のprocess、permission、data routeがあります。
- web search、web fetch、Ollama cloud modelはlocal inferenceではありません。
- repositoryのhooks、test script、package managerも外部serviceへ接続する場合があります。
Ollamaをより厳密なlocal-only modeにする場合、既存の~/.ollama/server.jsonへ他の設定を消さずに次のkeyをmergeします。
{
"disable_ollama_cloud": true
}
Ollamaを再起動し、logにOllama cloud disabled: trueが出ることを確認します。Ollamaの説明では、これによりcloud modelとweb searchが無効になります。ただし、Claude Code、MCP server、shell commandによる他のnetwork accessまで監査する設定ではありません。
手順5:互換layerが保証しない範囲を理解する
Ollamaが提供するのはAnthropic Messages APIの互換layerであり、Anthropic API全体の再実装ではありません。現在のdocumentでは、messages、streaming、system prompts、images、tool calls、tool results、thinkingなどが対応機能に含まれており、Claude Codeの基本的なagent loopを構成できます。
protocolが通ることと、modelの振る舞いが同等であることは別です。tool選択、patch品質、長時間タスクの安定性、instruction遵守は、model、quantization、context割り当て、hardwareに左右されます。1ファイルtestの合格は、その環境で最小経路が動くことだけを示し、大規模repositoryでcloud Claude modelと同等だとは示しません。
Ollamaは現在、/v1/messages/count_tokens、prompt caching、Batches API、citations、PDFのdocument block、streaming中のserver-sent errorsを未対応として挙げています。またtoken countは基礎modelのtokenizerによる近似値です。これらへ依存するworkflowでは、途中で不足へ気づくのではなく、最初からcloud経路を残しておきます。
手順6:設定を残さず明示的にクラウドへ戻す
local変数を現在のBash sessionだけで設定した場合は、Claude Codeを終了して次を実行します。
unset ANTHROPIC_BASE_URL ANTHROPIC_AUTH_TOKEN ANTHROPIC_API_KEY ANTHROPIC_MODEL ANTHROPIC_DEFAULT_HAIKU_MODEL ANTHROPIC_DEFAULT_SONNET_MODEL ANTHROPIC_DEFAULT_OPUS_MODEL
claude
新しいprocessは通常のaccount loginまたはcloud provider設定を解決できます。起動後に/statusを確認し、小さなread-only questionを1件送ります。clientが起動しただけでは、cloud requestが完了した証拠になりません。
それでもClaude CodeがOllamaへ接続する場合、overrideはcurrent shellではなくsettingsに保存されている可能性があります。Claude Codeの公式環境変数referenceでは、settings fileのenvがshellから継承した同名変数を上書きします。/statusでactive sourceを確認し、該当layerからlocalのANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_API_KEY、model overrideを削除します。
~/.claude/settings.json.claude/settings.json.claude/settings.local.json- 組織が配布するmanaged settings
変更後はClaude Codeを完全に終了して再起動します。managed valueは下位layerで打ち消せないため、administratorによる変更が必要です。
local modelがタスクに合わない一方、同じClaude CodeでAnthropic互換cloud APIを使いたい場合は、現在のBetterToken Claude Codeガイドに従えます。現在のBase URLはhttps://bettertoken.aiで、wwwも/v1も付きません。最初にmodel plazaから正確なModel IDをコピーします。現在のmanual setupでは、ANTHROPIC_MODELがprimary modelを指定し、3つのANTHROPIC_DEFAULT_*_MODELがHaiku、Sonnet、Opusのaliasを割り当てます。controlled smoke testでは、まず4変数すべてを同じ正確なIDへ向けられます。API Keyをcommand historyへ残さない一時的なBash setupは次のとおりです。
read -rsp "BetterToken API Key: " ANTHROPIC_AUTH_TOKEN
export ANTHROPIC_AUTH_TOKEN
read -rp $'\nBetterToken Model ID: ' ANTHROPIC_MODEL
export ANTHROPIC_MODEL
export ANTHROPIC_BASE_URL="https://bettertoken.ai"
export CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC="1"
export API_TIMEOUT_MS="3000000"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
claude
最初のpromptではAPI Keyの入力が非表示になり、2つ目ではmodel plazaからコピーした正確なModel IDを貼り付けます。このsmoke testではprimary modelと3つのaliasを同じIDへ向けます。役割ごとに別のmodelが必要なら、各default変数へそれぞれの正確なIDを設定してください。Base URLへ/v1を追加してはいけません。persistent settingsを変更した場合はClaude Codeを完全終了して再起動し、temporary sessionでもこのblockを実行する前に古いprocessを閉じます。最後に短いread-only requestを1件送ります。正常な応答が返り、401、接続、modelのerrorがなく、/statusに期待したactive sourceが表示された場合だけ切り替え完了と判断します。これはlocal pathとcloud pathの全機能が同等であることを意味しません。
よくある失敗を切り分ける
ConnectionRefused、またはlocalhost:11434が応答しない
Ollama processが動いているか、endpointのportが正しいか確認します。必要ならollama serveで起動します。portが使用中なら、2つ目を起動せず既存instanceを探します。Claude Codeを再度開く前に、curl http://localhost:11434/api/psがJSONを返すことを確認します。
チャットはできるが、Claude Codeがファイルを読まず編集もしない
/api/showを再度呼び、modelがtoolsを示すことを確認します。次にClaude Codeのpermission requestを見ます。モデルが「このように変更できます」と文章だけを返し、tool callを生成しない場合は、明示的にtool対応のmodelへ変更します。tool fieldをtransportできることは、全modelのtool planning品質を保証しません。
極端に遅い、または長いタスクでcontextを失う
ollama psを実行し、PROCESSORとCONTEXTを確認します。大きなCPU offload、64k未満のcontext、繰り返すmemory pressureがあれば、タスクを小さくする、より小さなtool対応modelを選ぶ、cloudを使うのいずれかが必要です。速く見せるためだけにpermissionや検証を外してはいけません。
shell変数を変えてもendpointやmodelが変わらない
Claude Codeで/statusを実行します。settingsのenvはshell valueを上書きでき、--modelと/modelはANTHROPIC_MODELより優先されます。実際に勝っているsourceを整理し、完全に再起動してread-only requestをもう一度行います。
実務上の判断基準
local Claude Codeは単なるtoggleではなく、より大きな範囲を任せられるか検証すべき実行経路として扱います。toolsを確認し、少なくとも64k contextを確保し、1ファイルタスクでtool call、終了status、diff、ollama psを点検します。これらが安定してから範囲を広げます。
タスクが端末の能力を超える、未対応のAnthropic機能が必要、実コードでlocal modelが繰り返し失敗する、という条件になったらlocal endpointを外して意図的にcloudへ戻します。すべてを無理にlocalへ置くより、確実なrollback pathを持つほうが重要です。