ローカル環境で AI を動かす、という流れが少しずつ現実的になってきました。
これまでは ChatGPT のように、クラウド上の AI を Webブラウザや API 経由で使うのが一般的でしたが、最近では自分の PC で AI を動かす環境も整ってきています。
その中でも、
・Ollama（ローカルLLM 実行環境）
・Claude Code（コーディングエージェント）
を組み合わせることで「ローカルでコーディング支援 AI を動かす」という使い方ができるようになってきました。
API 課金をせず、ローカル環境だけで動かす構成です。
ただ、実際に触ってみると、
- 思ったより普通に動く部分もあれば
- モデルによって挙動が変わる部分もあり
- 安定しない場面もそれなりにある
というのが正直なところです。
特に最近は、Ollama のアップデート（MLX対応）や 新しいモデル（qwen3.5:35b-a3b-coding-nvfp4）の登場によって、このあたりの状況が少し変わってきました。
これまで「厳しい」と思われていたクラスのモデルが、手元の環境でも現実的に動くようになりつつあります。
Claude Code × Ollama とは何か
Claude Code × Ollama は、「コーディングエージェント」と「ローカルLLM 実行環境」を組み合わせた構成です。
それぞれの役割を分けて考えると、イメージしやすくなります。
まず、Ollama はローカル環境で大規模言語モデル（LLM）を動かすためのツールです。
モデル（Qwen や Llama など）をダウンロードし、それを自分の PC 上で実行できるようにする、いわば「実行基盤」です。
一方で Claude Code は、
- コード生成
- ファイル編集
- ツール実行
といった処理をまとめて扱う「コーディングエージェント」です。
単なるチャットではなく、「コードを書く」「修正する」「ファイルを操作する」といった作業を前提に設計されています。
通常は、この Claude Code はクラウドのモデル（API）と接続して使いますが、その接続先を Ollama に置き換えることで、ローカルLLM をバックエンドにした構成になります。
つまり、
- Claude Code（操作・実行側）
- Ollama（モデル実行側）
という役割分担です。
この構成にすることで「ローカル環境だけでコーディング支援AIを動かす」という使い方ができるようになります。
最初は少しややこしく感じますが、
- Claude Code は操作する側
- Ollama は考える側
と分けてしまうと、かなりシンプルに理解できます。
この記事では、
- Claude Code × Ollama の基本的な構成
- 実際の使い方
- モデル選びの考え方
- そして、35Bモデルを含めた実験ログ
を、実際に触りながら整理していきます。
- ローカルでコーディング AI を動かしたい
- API 課金を避けたい
- モデルを自由に試したい
そういった前提で触っている内容です。
まずは、「どんな構成なのか」から見ていきます。
なぜこの構成を使うのか
Claude Code × Ollama の構成は、「ローカルで完結させること」を前提にした運用です。
クラウドのモデルは便利ですが、API 課金が発生する以上、試行回数を増やす使い方とはどうしても相性が良くありません。
そのため、
- まずはローカルで試す
- ローカルで完結できる範囲を広げる
という使い方がベースになります。
実際に触っていると、
- プロンプトの試行錯誤
- 軽いコード生成
- 挙動の確認や比較
といった作業は、ローカルでも十分回せる場面が多いです。
このあたりを気兼ねなく回せるだけでも、かなり使い勝手が変わります。
一方で、
- 精度が足りない
- うまくまとまらない
- どうしても詰まる
といった場合に限って、クラウドを検討する、という流れになります。
つまり、
- 基本はローカル
- 必要なときだけクラウド
という使い分けです。
最初からクラウドに寄せるのではなく、「どこまでローカルでいけるか」を探る前提の方が、
この構成は活かしやすいと感じています。
セットアップの流れ
Claude Code × Ollama の構成自体はシンプルで、最低限やることはそこまで多くありません。
大まかな流れは以下の通りです。
- Ollama をインストール
- Claude Code をインストール
- モデルを指定して起動
まずは一度「動かす」ことを優先して進めていきます。
Ollama の導入
Ollama がまだ入っていない場合は、先にインストールを行います。
OS ごとの具体的な手順は、以下の記事にまとめています。
すでに Ollama が動いている場合は、このまま次に進んで問題ありません。
Claude Code のインストール
Claude Code は公式スクリプトからインストールできます。
curl -fsSL https://claude.ai/install.sh | bashインストールが完了すれば、claude コマンドが使える状態になります。
Claude Code の起動（Ollama 経由）
Ollama が起動している状態で、以下のコマンドを実行します。
① 対話形式で起動する
ollama launch claude
モデル選択を含めて、対話形式で起動します。
まずはこの方法で OK です。
② モデルを指定して起動する
ollama launch claude --model qwen3.5:9b
モデルを指定して起動したい場合はこちらを使います。
検証や比較をする場合は、この形が基本になります。
最初のゴール
最初の段階では、以下ができれば十分です。
- Claude Code が起動する
- モデルを指定して動かせる
- 簡単なコード生成ができる
ここまでできれば、環境としては問題ありません。
細かい設定や最適化は、使いながら調整していく方がスムーズです。
モデル選びの考え方（Claude Code 前提）
Claude Code × Ollama の構成で一番重要なのは「モデル選び」です。
というのも、Ollama はあくまで実行環境で、実際にコードを生成しているのはモデル側だからです。
同じプロンプトでも、モデルが変わると結果は変わります。
これは触ってみるとすぐに実感します。
Claude Code で求められる性能
Claude Code は「ただのチャット」ではなく、コーディングエージェントです。
そのため、モデルには以下のような能力が求められます。
- コード生成の精度
- 文脈の理解力（長めの指示でも崩れない）
- 修正・リファクタリングの安定性
- ファイル操作との相性
ここが弱いモデルだと、
- 意図と違うコードが出る
- 修正を繰り返すと崩れる
- エラー対応が雑になる
といった形で、使いにくさがすぐに出てきます。
「とりあえずこれ」は存在しない
よくある「おすすめモデル1つ教えて」という話ですが、環境によって変わるので答えがありません。
- メモリ容量
- CPU / GPU 性能
- 実行環境（MLX など）
このあたりでおすすめが変わります。
さらに、モデル自体も更新が速いので、「これがおすすめ」という状態が長く続くこともあまりありません。
実際の運用はこうなる
実際に使っていると、運用はだいたいこうなります。
- 軽量モデルをまず試す
- 違和感があれば別モデルに切り替える
- 良さそうなものを残す
結果的に、「いくつかのモデルを使い分ける」形に落ち着きます。
ここは少しふわっとして見えますが、実際にはかなり現実的な運用です。
判断軸はこの3つで十分
モデル選びで見るポイントは、シンプルに絞った方が判断しやすいです。
- 日本語の自然さ
- コードの安定性
- 指示への追従性
この3つを見れば、「使えるかどうか」はだいたい判断できます。
逆に言うと、ベンチマークや細かい数値はそこまで気にしなくても問題ありません。
まずは触って判断する
最終的にはここに尽きます。
- 実際に使う
- 違和感があるかを見る
- ダメなら変える
このサイクルを回すのが一番早いです。
ローカルLLM は「選んで終わり」ではなく、「試して残す」前提で考えた方がしっくりきます。
実際に使ってきたモデル（実験ログ）
ここからは、実際に Claude Code × Ollama で触ってきたモデルのログです。
あくまで「その時点での体感」にはなりますが、モデル選びのイメージは掴みやすいと思います。
qwen3.5:9b
最初に触るモデルとしてはかなりバランスがいい印象です。
- 軽くて動作が安定
- 応答も比較的速い
- 日本語もそこまで違和感はない
ただし、コーディング用途になると少し物足りなさは出てきます。
- 複雑な処理になると崩れる
- 修正指示に対してズレることがある
とりあえず動かす、軽く試す、といった用途にはちょうどいいですが、メイン運用にするには少し弱いという位置づけです。
gpt-oss:20b
一段上のモデルとして試したのがこれです。
- コード生成の精度は qwen3.5:9b より明らかに上
- 指示への追従性も安定している
- それなりに実用レベル
ただ、環境によっては少し重さを感じます。
- レスポンスが遅くなる場面がある
- メモリ使用量もそれなりに増える
「ちゃんと使えるライン」に入ってくるモデルですが、少し古いモデルかつ、エージェント用に作られた LLM という感じでもなさそうです。
qwen2.5-coder:14b
コーディング特化モデルとして試したのがこれです。
- コード生成自体はかなり強い
- 構造を意識した出力が出やすい
ただし、安定性という意味では少しクセがあります。
- 指示の解釈がズレることがある
- 日本語の自然さにばらつきがある
- JSON のみのレスポンスが返ってくることがある
毎回安定して使えるかというと微妙、という印象です。
使ってみて感じたこと
ここまでいくつか試してみて感じたのは、「どれか1つで完結する感じではない」という点です。
- 軽いモデルは快適だが精度が足りない
- 重いモデルは精度が上がるが扱いが重くなる
- モデルごとに得意・不得意がはっきりある
結果的に、
- 普段使い用
- しっかり書かせる用
のように、用途で分ける形に落ち着きました。
ここは少し曖昧に見えますが、実際にはかなり現実的な使い方だと思っています。
35Bが現実的に動く（2026年4月の変化）
ここまで軽量〜中量モデルを触ってきた中で、一番印象が変わったのが「35Bクラスが普通に動いたこと」です。
今回試したのは以下のモデルです。
- qwen3.5:35b-a3b-coding-nvfp4
結論から言うと、「思っていたより普通に使える」という感触でした。
Mac mini M4 32GB でも動く
今回の検証環境は Mac mini M4 32GB メモリですが、この条件でも一応動作しました。
もちろん余裕があるとは言えませんが、
- 起動できる
- 応答も返ってくる
- ファイルの読み書きもできる
ここまでできる時点で、かなり印象が変わります。
少し前までは「35B = ミドルエンド〜ハイエンド環境前提」という感覚だったので、このラインが崩れたのは大きいです。
体感は確実にワンランク上
実際に使ってみると、軽量モデルとの差ははっきり出ます。
- コードの一貫性が高い
- 指示の理解が深い
- 修正時のブレが少ない
特に Claude Code のようなエージェント用途では、「途中で崩れない」という点がかなり効いてきます。
このあたりは、9B〜20B 帯ではどうしても差が出ていた部分です。
ただし “万能ではない”
とはいえ、良いことばかりではありません。
- メモリの余裕はほぼない
- 他アプリの同時起動は厳しい
- 長時間運用は少し気を使う
このあたりは、実際に使っていて普通に感じる制約です。
とはいえ、それを踏まえても運用は十分可能で、「扱いづらい」という印象はそこまでありません。
「クラウド級」とまでは言えないですが、ローカルとしてはかなり現実的なラインに来ている、という感触です。
運用の前提が変わった
この体験で一番変わったのは、モデルの位置づけです。
以前は
- 軽量モデルをメインに使う
という前提でしたが、今は
- 35Bを基本として使う
という運用に落ち着いています。
メモリ的に余裕があるとは言えませんが、それでも安定して動いているので、常用すること自体に不安はありません。
結果的に、「軽量モデルで我慢する」という感覚はほぼなくなりました。
ローカルLLM でも、ある程度しっかりしたモデルを日常的に使える段階に来ていると感じています。
なぜ 35Bが動くのか
ここまでで「35Bが普通に動いた」という話をしてきましたが、少し前までの感覚だと、これは正直かなり違和感のある挙動です。
ではなぜ動くのかというと、いくつかの要因が重なっています。
Ollama の MLX 対応
まず大きいのが、Apple Silicon 向けの最適化です。
Ollama の MLX 対応によって、
- メモリの使い方が効率化される
- CPU / GPU のリソースをうまく使える
といった改善が入っています。
特に Mac 環境では、この恩恵はかなり大きく、「スペック以上に動いている感覚」が出やすいです。
NVFP4 などの軽量化技術
今回使ったモデルは NVFP4 という形式になっており、そのままの状態よりもかなり扱いやすくなっています。
これはいわゆる単純な量子化というよりは、
- 精度をある程度保ちながら
- メモリ使用量を抑える
ための軽量化の仕組みです。
その結果として、
- モデルサイズのわりに動かしやすい
- ローカル環境でも現実的に扱える
という状態になっています。
本来であれば厳しいはずの 35B クラスが、手元の環境でも動くラインに収まっているのは、こうした最適化の影響が大きいです。
キャッシュまわりの改善
Ollama version 0.19 のアップデートで、推論時のキャッシュ処理も改善されています。
これによって、
- 同じ文脈でのやり取りが速くなる
- 無駄な再計算が減る
といった効果があり、体感の快適さに影響しています。
「いきなり進化した」わけではない
こうした要素が積み重なった結果として、
- モデル側の最適化
- 実行環境（Ollama）の改善
- ハードウェア側の進化
がうまく噛み合い、今の状態になっています。
なので、「急に35Bが動くようになった」というよりは、いくつかの改善が積み重なって、ラインを超えてきた、という感覚が近いです。
このあたりを踏まえると、今後も同じように “動くライン” は少しずつ上がっていく可能性があります。
実際に使ってみた感想
ここからは、実際に 35B モデルを使ってみたときのログに近い感覚です。
ベンチマークというよりは、「普段どう使えるか」という視点で見ています。
使ってみた感覚
まず結論としては、「普通に使える」です。
これまでのローカルLLM は、
- 試すもの
- 軽く触るもの
という位置づけでしたが、今回は違いました。
- 普段の作業にそのまま組み込める
- 無理なく使い続けられる
この違いはかなり大きいです。
メモリと動作の体感
Mac mini M4 32GB 環境での使用ですが、余裕はほぼありません。
ただし、
- 動作が止まることはない
- 極端に不安定になることもない
という状態では動いています。
裏で他のアプリを動かしすぎると厳しいですが、Claude Code をメインに据えるなら現実的な範囲です。
速度感について
速度は「速い」とは言えません。
- 体感としてはやや待つ
- ただしストレスになるほどではない
というラインです。
軽量モデルのようなサクサク感はないですが、その分、出てくる内容の安定性は明らかに上がっています。
エラーまわり（Error editing file）
実際に使っていて出たのが、ファイル編集まわりのエラーです。
- Error editing file が出ることがある
- 書き込みがうまくいかないケースがある
ただ、このあたりは
- 再実行で通ることも多い
- モデルというより環境側の影響もありそう
という印象です。
致命的に使えないというよりは、「たまに詰まるポイントがある」くらいの位置です。
総合的な感触
全体としては、
- 完璧ではない
- でも十分実用
というラインにしっかり入っています。
特にコーディング用途では、
- 指示の理解
- 修正の安定性
- 出力の一貫性
このあたりが効いてくるので、結果的に作業のストレスはかなり減りました。
ローカルLLM に対して持っていた「あと一歩足りない感じ」は、かなり薄れてきている印象です。
コーディング性能について
ここでは、実際に Claude Code × 35B モデルでどの程度コーディングができるのかを見ていきます。
ベンチマークではなく、あくまで実運用ベースの感覚です。
HTML / CSS の生成
まずシンプルなところですが、HTML / CSS の生成は問題なくこなせます。
- レイアウトのあるページ
- シンプルな UIコンポーネント
- 軽いアニメーション
このあたりは、ざっくりした指示でも形になります。
特に感じたのは、
- 構造が崩れにくい
- 途中で破綻しにくい
という点です。
軽量モデルだと、途中で div 構造がおかしくなったり、スタイルが噛み合わなくなることがありますが、その頻度はかなり減ります。
雑なプロンプトでも動く
これは地味に大きいポイントです。
例えば、
- 「このページいい感じに整えて」
- 「このコードリファクタして」
といった、少し曖昧な指示でもちゃんと動きます。
軽量モデルだと、
- 解釈がズレる
- 意図と違う方向に進む
ことが多いですが、35B だとこのあたりのブレが少ないです。
結果として、やり取りの回数が減ります。
修正・リファクタリング
既存コードの修正も比較的安定しています。
- バグ修正
- コード整理
- 関数の分割
このあたりは「一回で通る率」が上がった印象です。
特に、
- 変更範囲を理解する
- 余計な部分を触らない
という挙動が安定しているのは大きいです。
ファイル操作との相性
Claude Code の特徴であるファイル操作も問題なく動きます。
- ファイルの読み込み
- 追記・修正
- 複数ファイルの編集
このあたりを含めても、途中で崩れるケースは少なめです。
ただし、
- まれに書き込みエラーが出る
- 再実行が必要になる
といった点はあるので、完全にノーストレスとはいきません。
総合評価
コーディング用途として見ると、
- 軽量モデルより明確に上
- 実用レベルとして十分成立
という位置づけです。
特に、
- 雑な指示でも動く
- 修正が安定する
この2点が効いてくるので、結果的に作業効率はかなり上がります。
「ローカルでもここまでできるのか」というラインには、しっかり到達している印象です。
モデル選定の現実解
ここまでいくつかのモデルを試してきましたが、最終的な結論はかなりシンプルです。
基本は 35B を使う
現時点では、
- qwen3.5:35b-a3b-coding-nvfp4
このモデルをベースにするのが一番しっくりきています。
理由は単純で、
- コードの安定性が高い
- 指示の理解が深い
- 修正時に崩れにくい
といった、コーディング用途で重要なポイントが揃っているためです。
「少し重い」よりも「安定している」方が、結果的に作業効率は上がります。
軽量モデルの役割
とはいえ、軽量モデルが不要になるわけではありません。
- すぐに試したいとき
- 軽い確認をしたいとき
- メモリに余裕がないとき
こういった場面では、9B〜20B クラスのモデルも十分役に立ちます。
ただし、メインとして使うよりは、あくまで補助的な位置づけになります。
「使い分け」から「軸」ができた
以前は、
- モデルを使い分ける前提
で運用していましたが、今は
- 35B を軸にする
という形に変わりました。
この「軸がある状態」になると、判断に迷わない、環境が安定する、というメリットが出てきます。
よくある問題と対策
Claude Code × Ollama を実際に触っていると、いくつか共通して詰まりやすいポイントがあります。
ここでは、実際にハマった部分とその対処をまとめておきます。
動作が遅い
まず一番感じやすいのが速度です。
- 応答に時間がかかる
- 処理中に待たされる
これは特に 20B 〜 35B モデルで起きます。
対策としてはシンプルで、
- 軽い作業は軽量モデルに切り替える
- 常駐アプリを減らす
この2つで体感はかなり変わります。
メモリが足りない
32GB 環境でも、余裕があるとは言えません。
- 他アプリを開くと重くなる
- スワップが発生する
といった挙動は頻繁に発生します。
対策としては、
- 不要なアプリを閉じる
- Claude Code を使うときは集中させる
「専用時間を作る」くらいの感覚の方が安定します。
モデルがうまく動かない
- 起動しない
- 応答が返ってこない
といったケースもあります。
この場合は、
- モデルの再ダウンロード
- Ollama の再起動
で解決することがあります。
ローカル環境なので、このあたりは割り切りが必要です。
ファイル編集エラー（Error editing file）
実際に使っていて出るのがこれです。
- 書き込みに失敗する
- 途中で止まる
ただし、
- 再実行で通ることが多い
- 毎回発生するわけではない
ので、致命的な問題ではありません。
現状は「そういうもの」として付き合うのが現実的です。
思ったより賢くないと感じる
これはローカルLLM 全体に言える部分です。
- 意図とズレる
- クラウドほどの精度ではない
このギャップで「微妙」と感じることがあります。
対策としては、
- 指示を少し具体的にする
- モデルを変えてみる
この2つで改善するケースがあります。
「思ったより使えない」と感じる理由
ここまで見ると、「普通に使えそう」と感じる一方で、実際に触ると「思ったより微妙かも」と感じる場面もあります。
これはローカルLLM 特有のギャップです。
クラウドとの比較で見てしまう
一番大きいのはここです。
普段、ChatGPT や Claude といった クラウドAI に慣れていると、
- 応答の速さ
- 精度の高さ
- 安定感
このあたりとどうしても比較してしまいます。
その結果、「ちょっと弱い」と感じやすくなります。
すべてを任せようとする
ローカルLLM は便利ですが、「全部これでやる」となると途端に厳しくなります。
- 重い処理
- 長文の一貫性
- 高度な推論
こういった部分では、まだ差が出ます。
そのため、
- できることに使う
- 無理な部分は切り分ける
という前提の方がしっくりきます。
セットアップと運用の手間
ローカル環境である以上、
- モデル管理
- 環境調整
- トラブル対応
といった手間はどうしても発生します。
ここを「面倒」と感じると、クラウドとの差が気になってきます。
それでも使う理由
ではなぜローカルLLM を使うのかというと、やはりこの点に尽きます。
- API 課金を気にしなくていい
- 自分の環境で完結する
- モデルを自由に選べる
このメリットがあるからこそ、多少の手間や制約があっても使う価値があります。
まとめ
Claude Code × Ollama の構成は、ローカルでコーディングAI を動かす選択肢として、かなり現実的なラインに来ています。
特に今回検証した 35B モデルでは、
- コードの安定性
- 指示の理解
- 修正時の一貫性
このあたりが大きく改善されており、「実用として使える」感覚ははっきり出てきました。
もちろん、
- メモリの制約
- 速度の問題
- 運用の手間
といった課題は残っています。
それでも、
- API 課金を気にせず使える
- ローカルで完結できる
- モデルを自由に選べる
というメリットは大きく、実験用途にとどまらず、日常的な作業にも組み込める段階に来ています。
現時点での結論としては、
- 基本は 35B を使う
- 必要に応じて軽量モデルを併用する
この形が一番しっくりきています。
ローカルLLM はまだ発展途中ですが、「あと一歩」の段階から、「普通に使える」段階に入ってきた印象です。
今後もモデルや実行環境の改善は続くので、このラインはさらに上がっていくはずです。
引き続き、実際に触りながら検証していきます。
