16GB のノートPC でも、Claude Code + ローカル LLM は本気で使える — CodeRouter で Tool Call が安定するまで(2026年7月版)

TL;DR
16GB RAM の Mac(M シリーズ)や Windows ノートでも、Qwen2.5-coder:7b や Qwen3.5 9B、低 quant の MoE モデルで Claude Code + ローカル LLM が実用レベルになりました。鍵は 3 つ ── ①16GB に収まる「今の」モデル選び、②小さいモデルほど壊す Tool Call を修復層で直すこと(実測で 0%→100% が 3 モデル)、③メモリを溢れさせない事前ガード。月額 0 円・プライバシー重視の環境が、16GB クラスで現実的に組めます。

対象読者

• 16GB RAM の MacBook / Mac mini / Windows ノートを使っている人

• Claude Code(または他のエージェント)をローカルモデルで安定して使いたい人

• Tool Call(AI がファイルを読んだりコマンドを実行したりする仕組み)をローカルで実用的に回したい人

• 8〜12GB クラスでも軽く試してみたい人

特に M シリーズ Mac の 16GB モデルが最も相性が良いです(ユニファイドメモリで GPU/CPU の割り振りに悩まなくてよい)。

なぜ「16GB でローカル」が難しかったのか

理由は 2 つあります。

1 つ目はメモリ。 16GB に OS とブラウザとエディタを載せると、モデルに使えるのは実質 8〜10GB。快適に動くのは 7B〜9B クラス(4〜7GB)までで、俗に「賢い」とされる 30B 級 dense モデルは入りません。

2 つ目が本題の Tool Call。 小さいモデルは、ツールを呼ぼうとしたときに正式な形式ではなく本文のテキストに書いてしまう癖があります。当方の実測(温度 0、各 100 リクエスト)では:

つまり 16GB で動くサイズのモデルは、そのままだとエージェントとして使い物にならないことがある。ここが長年「ローカルは Tool Call が不安定」と言われてきた正体です。

そしてこの 2 つ目は、直せます。

2026 年 7 月の 16GB おすすめモデル(X / Reddit 調査ベース)

コミュニティの最新の声を反映した傾向です。MoE モデル(有効パラメータが少なく見かけより軽い)が 16GB 勢の新トレンドで、純粋な dense 27B より「低 quant MoE の方が動く・速い・実用的」という報告が増えています。

ポイント:

• Qwen Coder 系は Tool Call との相性が伝統的に強い。修復層と組み合わせたときの安定度が頭一つ抜けています

• Gemma4 系は急上昇中だが、Tool Call で稀にループやフォーマット問題の報告あり ── ここは後述の修復層とフォールバックがカバーします

• dense 26B 級(gemma4:26b 素の Q4 は約 17GB)は 16GB には収まりません。26B 級を狙うなら MoE(A4B)+ 低 quant が前提です

修復層で何が変わるか — 実測の数字

CodeRouter は Claude Code とローカルモデルの間に挟む小さなルーターで、看板機能が Tool Call の修復です。モデルがテキストに書いてしまった壊れた呼び出しを、正式な形式に直してから Claude Code に渡します。

直結 vs CodeRouter 経由の実測(温度 0、各 100 リクエスト、M3 Max、2026-07-05):

0% → 100% が 3 モデル。 1.5B のような超軽量モデルでも、修復層を挟めば 100 回中 100 回ツールが届くようになります。逆に強いモデルは経由しても一切劣化しない ── 挟むデメリットがない、というのも実測済みです(数字の一次データはリポジトリの benchmarks/tool-repair に全部置いてあります)。

phi4-mini の残り 20% は、引数の中身自体をモデルが壊してしまうケースで、これはあえて直しません(間違った引数でコマンドが実行される方が危険)。修復層は「勝手な呼び出しを作らない」= 偽陽性 0% を回帰テストで固定しています。

もう 1 つ、Gemma4 系で報告のある「空の応答が返ってくる」問題は、修復では直せません(直すテキストが無い)。これは v2.7.3 の 空応答フォールバック(`empty_response_action: fallback`)で、空を検知した瞬間に次のモデルへ同じリクエストを流して救います。実測では空応答 20% のモデルが chain 経由で 100% になりました。16GB 環境ではモデルの載せ替え時間が挟まりますが、「黙って止まる」よりずっとましです。

ステップバイステップ構築

1. Ollama をインストール

curl -fsSL https://ollama.com/install.sh | sh

2. モデルを pull(16GB 向け)

まずはこれ:

ollama pull qwen2.5-coder:7b     # 主力(約4.7GB)
# または
ollama pull qwen3.5:9b           # daily driver 派に(約6.6GB)

さらに軽くしたい / 補助用:

ollama pull qwen2.5-coder:1.5b   # 約1GB。修復層前提なら十分戦える
ollama pull phi4-mini            # 約2.5GB

Gemma4 を試したい場合(MoE + 低 quant 前提):

ollama pull gemma4:26b-a4b

pull したら `ollama show <モデル名>` で Capabilities に `tools` があるかを確認してください。tools が無いモデル(例: gemma3 系)は Tool Call リクエスト自体をエラーで弾くため、この用途には使えません。

3. CodeRouter を起動(Tool Call 修復の要)

mkdir -p ~/.coderouter
curl -fsSL https://raw.githubusercontent.com/zephel01/CodeRouter/main/examples/providers.ollama-auto.yaml \
  > ~/.coderouter/providers.yaml
uvx --from coderouter-cli coderouter serve --port 8088

同梱のスターター設定は、リクエスト内容(コード比率・画像の有無)で coding / writing / multi のプロファイルに自動振り分けします。まずはそのままで OK。

4. Claude Code を接続

ANTHROPIC_BASE_URL=http://localhost:8088 \
ANTHROPIC_AUTH_TOKEN=dummy \
claude

これで Tool Call 修復 + フォーマット変換 + フォールバックが効いた状態でローカルモデルを使えます。

16GB ならではの Tips

• 低メモリガードを頼る: CodeRouter には実機の空きメモリを検出して、送信前にコンテキスト長を自動で右サイズ化する事前ガードが入っています(8〜16GB 機向けに設計)。OOM で落ちてから対処ではなく、溢れる前に切り詰める方向

• swap 落ちに注意: メモリ使用量は Activity Monitor で常時確認。swap に落ちると速度が一桁変わります。ブラウザのタブを閉じるのが一番効く、は本当です

• MoE は低 quant で: Q3 / Q4_K_M / IQ2 系で 16GB に収める。quant を下げると Tool Call の壊れ方は増えますが、そこは修復層が受けます

• フォールバック chain を組む: 軽量モデル → 中型モデルの順で providers.yaml に並べておくと、空応答や失敗時に自動で次へ。16GB ではモデル切替のロード時間が入るので、chain の 2 番手は 7B 級までが現実的

注意点(2026 年のリアル)

• 速度はクラウドに劣ります。特に小型モデル。複雑なタスクはクラウドとの併用(CodeRouter はクラウド provider も同じ設定に混ぜられます)が現実的

• Gemma4 系の Tool Call ループ・フォーマット揺れは「修復層で減る」であって「ゼロになる」ではありません

• llama3.2:3b / llama3.1:8b は当方の実測(温度 0)では Tool Call がむしろ壊れませんでした。評判と実測は結構ずれます ── 疑わしければ 100 回撃って数えるのが確実で、そのためのベンチハーネスも公開しています

まとめ

2026 年 7 月現在、16GB クラスでも「本気でローカル LLM + Tool Call」は回ります。

• 入り口の鉄板は Qwen2.5-coder:7b / Qwen3.5 9B

• MoE 低 quant が 16GB の新しい選択肢

• 小さいモデルの壊れた Tool Call は修復層で 0%→100%(実測 3 モデル)、空応答はフォールバックで救う

• メモリは事前ガードで溢れさせない

「クラウドは高いけど、ローカルは Tool Call が不安定…」という長年の悩みは、だいぶ解消されてきています。実際に試しての感想や「このモデルはこう壊れた」という報告をもらえると嬉しいです ── 壊れ方の実例はそのままベンチのテストケースに追加します。

いいなと思ったら応援しよう！

この記事が参考になったら、ぜひ CodeRouter に スターをつけていただけると嬉しいです！ 開発の励みになり、今後の改善（特に16GB環境向けのさらなる最適化や新修復機能）の原動力になります☕

🔗 https://github.com/zephel01/CodeRouter （MITライセンス・Python 3.12+・軽量ランタイム）

> スターを押すだけでも本当に励みになります！
> 使ってみての感想・壊れ方報告・要望も大歓迎です（IssueやXでメンションいただけるとすぐ対応します）。

uvx --from coderouter-cli coderouter serve --port 8088
ANTHROPIC_BASE_URL=http://localhost:8088 ANTHROPIC_AUTH_TOKEN=dummy claude

技術的な詳細(修復器の設計、ベンチの数字の出どころ)を知りたい方は、開発者向けの連作記事へ:
修復の定量ベンチ(第 23 話)
6 モデル横断計測と修復の限界(第 24 話)