Local LLM on KnightLiブログ

Claude Code + Ollama ローカル導入ガイド：CC Switch で無料の AI コーディングアシスタントを作る

Fri, 15 May 2026 23:27:50 +0800

最近、Claude Code のような AI コーディングアシスタントが注目されています。魅力は単にコードについて会話できることではなく、プロジェクトを読み、ファイルを編集し、コマンドを実行し、依存関係を入れ、エラーを見ながら修正を続けられる点にあります。かなり Agent に近い使い方ができます。

ただし問題はコストです。プロジェクトが大きくなるとコンテキストも長くなり、複数ターンの Agent 操作で API クォータを一気に消費します。試用、小さなツールの修正、スクリプト作成、ローカルのプライベートプロジェクトで使いたいだけなら、Claude Code の操作感を残したままモデルだけローカルにできないか、と考えるのは自然です。

この構成の鍵になるのが CC Switch です。Claude Code から OpenAI 互換 API としてローカルの Ollama サービスへ接続し、公式 Claude API ではなくローカルモデルへリクエストを転送できます。

この構成で解決できること

全体の流れは次のように考えると分かりやすいです。

1
2
3

Claude Code デスクトップ
+ CC Switch API 転送レイヤー
+ Ollama ローカルモデル

Claude Code は引き続きコーディングワークフローとプロジェクト操作を担当します。CC Switch はモデルプロバイダー設定と API 互換性を受け持ち、Ollama はローカルでモデルを動かします。

これはローカルモデルが突然 Claude と同等になるという意味ではありません。価値があるのは、Claude Code の Agent ワークフローを低コスト、オフライン、プライベートなローカル環境で使えるようにする点です。

基本準備

始める前に、次のものを用意します。

Git をインストールする。
Ollama をインストールする。
コーディング向きのローカルモデルを取得する。
CC Switch をインストールする。
Claude Code をローカルで使える状態にする。

モデルは、まずコード能力が比較的強いものから試すとよいでしょう。たとえば Qwen Coder、DeepSeek Coder、またはツール呼び出しとコード生成がある程度安定しているモデルです。大きいモデルほど結果は良くなりやすい一方、メモリや GPU への負荷も高くなります。

メモリに余裕がないマシンでは、小さめのモデルで流れを確認してから、徐々に大きいモデルを試すのがおすすめです。

CC Switch の重要設定

Ollama を起動すると、通常のローカル API アドレスは次のようになります。

`1`	`http://127.0.0.1:11434/v1`

CC Switch では OpenAI 互換のプロバイダー種別を選びます。よく使う選択肢は次のものです。

`1`	`OpenAI Chat Completions`

そのうえで base URL を Ollama のローカルアドレスに向けます。

API key はローカル Ollama では通常、本物のキーを必要としません。ただし多くのツールは環境変数やプレースホルダーを求めます。次のような値を使えます。

`1`	`ANTHROPIC_API_KEY`

または、手元のローカル設定で受け入れられる別のプレースホルダー変数でも構いません。

特に注意したい設定項目があります。

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

これは Claude Code が期待するモデルロールをローカルプロバイダーへマッピングする設定です。実際には haiku、sonnet、opus を Ollama または CC Switch 側で利用できるモデル名に対応させる必要があります。この対応が間違っていると、Claude Code がモデルを呼べなかったり、意図しない設定へ戻ったりします。

Claude Code の強み

Claude Code の一番の価値は、単発の補完ではなくコーディング全体のワークフローにあります。

プロジェクト構造を読み取って理解する。
タスクに応じて関連ファイルを見つける。
コードを直接編集する。
コマンドやテストを実行する。
エラーを観察して修正を繰り返す。
1 つのセッションで複数ステップの作業を進める。

多くの人が Claude Code を残したい理由もここにあります。通常のチャット UI でもコード片は生成できますが、リポジトリ内で自然に作業してくれるわけではありません。Claude Code は、実行できる開発アシスタントに近い存在です。

Ollama の役割

Ollama はローカルモデルの実行と管理を担当します。モデルのダウンロード、ロード、ローカル推論を扱います。

利点は明確です。リクエストは手元のマシンに残り、繰り返し使っても API 課金が発生せず、ネットワークが制限された環境でも使えます。プライベートなコードを扱う場合も、すべてのコンテキストをクラウドモデルに送るより受け入れやすいでしょう。

一方で代償もあります。ローカルモデルはハードウェアとモデル品質に大きく左右されます。小さいモデルでも簡単な修正、説明、スクリプト生成はできますが、大規模な複数ファイルリファクタリングや細かな設計判断では能力差が出やすくなります。

体験の限界

この構成は、Claude の強力なクラウドモデルを完全に置き換えるものとして考えるべきではありません。

次のような問題に遭遇する可能性があります。

長いコンテキストの理解が弱い。
複雑なタスクでツール呼び出しが不安定になる。
CPU のみの環境では推論が遅い。
存在しないファイルパスや API を幻覚しやすい。
複数ターンの計画が安定しにくい。
大規模リポジトリのリファクタリング成功率が低い。

したがって、期待値としては「無料で使えるローカル開発アシスタント」が現実的です。トップクラスのクラウドモデルの完全な代替ではありません。

マルチモーダル互換性はまだ不安定

Claude Code にスクリーンショット、UI 画像、図、その他のマルチモーダル入力を扱わせたい人もいます。この部分はローカルモデルと転送レイヤーの対応状況に依存します。

選んだ Ollama モデルが画像入力に対応していない場合、または CC Switch がリクエスト形式を正しく変換できない場合、マルチモーダル機能は失敗する可能性があります。Vision モデルを使っても、公式 Claude API と同じ挙動になるとは限りません。

現時点では、この構成はテキストとコードのワークフロー向きです。マルチモーダル対応は実験的なものとして扱うのがよいでしょう。

試す価値がある人

この構成は次のような人に向いています。

Claude Code のワークフローを低コストで試したい開発者。
スクリプト、小さなツール、自動化をよく書く人。
コードをできるだけローカルに残したいチーム。
API コストを気にせず AI コーディングアシスタントを学びたい初心者。
さまざまなローカルコードモデルを検証している人。

長いコンテキスト、大規模 monorepo、厳密なコードレビュー品質、複雑なプロジェクト全体のリファクタリングに強く依存する場合は、まだ安定性が足りないかもしれません。

使い方のおすすめ

まずは小さなタスクから始めましょう。

たとえば次のような作業です。

1 つのファイルを説明させる。
小さな関数をリファクタリングする。
shell スクリプトを生成する。
単純なエラーを修正する。
小さな機能を追加する。
狭いモジュールに単体テストを追加する。

変更後は、自分でテストを実行するか、少なくとも diff を確認してください。ローカルモデルは便利ですが、生成された編集をすべて無条件に受け入れるべきではありません。

モデルがよくコンテキストを見失う場合は、タスク範囲を小さくします。「プロジェクト全体をリファクタリングして」ではなく、「この関数をリファクタリングして」や「このファイルにバリデーションを追加して」のように依頼すると安定しやすくなります。

まとめ

Claude Code + CC Switch + Ollama はかなり面白い組み合わせです。Claude Code の Agent 的な開発体験を保ちつつ、モデル推論をローカルへ移せます。

大きな利点は、コストの低さ、データのプライバシー、扱いやすい開発ワークフローです。一方で、モデル品質、ハードウェア性能、長いコンテキスト、ツール呼び出しの安定性が体験を左右します。

すでに Ollama を使っていて、より実践的なローカル AI コーディング環境が欲しいなら、この構成は試す価値があります。ただし小さな作業から始め、すべての変更を確認し、ローカルモデルを自動エンジニアではなくアシスタントとして扱うのが安全です。

Gemma 4 E4B の脱獄版と公式通常版の違い

Sat, 18 Apr 2026 10:20:00 +0800

HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive のようなモデルを見るときに一番重要なのは、これは Google が新しく出した別の Gemma 4 ではない という点です。公式の google/gemma-4-E4B-it をベースにした非公式派生版であり、主眼は「拒否応答を減らすこと」にあります。

つまり、通常版との本質的な差はモデル構造よりも アラインメント方針と応答スタイル にあります。

この派生版モデルカードが明示していること

Hugging Face のモデルカードでは、この HauhauCS 版について次のように書かれています。

google/gemma-4-E4B-it ベースである
「データセットや能力には変更がない」と主張している
違いは「拒否応答を外しただけ」と主張している
Aggressive 版は「完全に解放され、プロンプトを拒否しない」と説明している

これらは作者側の主張であり、独立した第三者評価ではありません。ただし、意図している方向性は明確です。これは「安全上の拒否を減らす」ことを狙った非公式派生版です。

公式版 vs いわゆる「脱獄版」

観点	公式 `google/gemma-4-E4B-it`	`Gemma-4-E4B-Uncensored-HauhauCS-Aggressive`
出所	Google 公式	Hugging Face 上の第三者派生版
ベースモデル	Gemma 4 E4B の instruction-tuned 版	同じモデル系統で、モデルカードにも `google/gemma-4-E4B-it` ベースと明記
主目的	汎用アシスタント能力 + Responsible AI 前提	拒否応答を減らし、とにかく出力を続ける
安全方針	Gemma 系列の安全文書・禁止用途ポリシーに沿う	拒否やガードレールを意図的に弱めている
応答傾向	敏感な要求では拒否・回避・慎重回答が増える	公式版なら止まる要求にもそのまま答えやすい
リスク	既定では比較的低いが、完全に安全という意味ではない	既定でより高リスク。不適切または非準拠の出力が出やすい
プロダクト適性	企業や公開サービスで説明しやすい	公開サービスやポリシー重視環境では扱いにくい
追加対策	アプリ側の安全対策は依然必要	モデル側の抑制が弱いため、下流側の安全対策がより重要

本質は「能力向上」より「挙動変更」

uncensored を「より高性能」と受け取るのは、たいてい正確ではありません。

こうした派生版で先に変わるのは次の点です。

どれだけ拒否するか
敏感な要求にどれだけ従うか
最終回答にどれだけ安全フィルタが残るか

一方で、名前に Uncensored と付いているからといって、次のものまで自動的に大きく向上するわけではありません。

モデルアーキテクチャ
コンテキスト長
マルチモーダル能力
推論能力の上限

より正確には、これは 同じモデル系列の中で挙動の調整が違う版 と見るべきであり、上位モデルとみなすべきではありません。

なぜ公式版のほうが保守的なのか

Google の Gemma 公式文書は、この系列を Responsible AI 開発の文脈で位置づけています。Gemma のモデルカードでは誤用、有害コンテンツ、プライバシー、バイアスといったリスクが明示されており、Gemma Prohibited Use Policy では Gemma または派生モデルを次の用途に使うことを禁じています。

危険・違法・悪意ある活動
有害、誤解を招く、欺瞞的なコンテンツ生成
安全フィルタの上書きや回避

つまり、公式版が保守的なのは偶然ではなく、文書・ライセンス・運用前提が最初からそう設計されているためです。

公式通常版が向いているケース

次の点を重視するなら、まずは公式 google/gemma-4-E4B-it のほうが適しています。

プロダクトへの組み込み
チーム利用
企業・公開向け運用
ポリシーや法務リスクの低減
出力挙動の説明可能性

多くの通常用途では、こちらが基本選択です。

あえて脱獄版を試す人がいる理由

こうした uncensored 派生版が選ばれるのは、たいてい次のような理由です。

ローカルでの私的実験
公式版が早すぎる拒否をしていないかの確認
ロールプレイや自由度の高い創作
アラインメント違いの比較

ただし、その分だけ安全責任はモデル提供者ではなく利用者側に移ります。

結論

Gemma 4 E4B のいわゆる「脱獄版」と公式通常版の最も大きな違いは次の通りです。

公式版は「ガードレール付きの実用性」を重視
脱獄版は「拒否を減らした出力継続性」を重視

これは 自動的に高性能になることを意味しません。主に より許容的になる だけです。

安定性、説明可能性、配備のしやすさを重視するなら、まず公式版を使うのが妥当です。ローカル実験目的で、安全性・コンプライアンス・出力リスクを自分で引き受けられる場合に限って、uncensored 派生版を「挙動違いの別バリアント」として比較するのが現実的です。

参考リンク

Hugging Face: HauhauCS/Gemma-4-E4B-Uncensored-HauhauCS-Aggressive
Hugging Face: google/gemma-4-E4B-it
Google AI for Developers: Gemma Prohibited Use Policy
Google AI for Developers: Gemma model card