16GB のノートPC で Claude Code + CodeRouteer + ローカル LLM、次の一手 — 生成を速くする(MTP)と、重い仕事だけ Claude に投げる(外部エージェント)

前回のおさらい(3 行)

前回(16GB のノートPC でも、Claude Code + ローカル LLM は本気で使える)は、小さいモデルの Tool Call が壊れる問題を CodeRouter の修復レイヤで潰し、Ollama + CodeRouter で「安定して動く」ところまで組み立てました。読んでいなくても今回の記事は単体で読めますが、前提は「Claude Code を CodeRouter 経由でローカル LLM に向けている」状態です。ここから先は、その土台の上に「速度」と「賢さ」を足していく話になります。

今回やること — 見取り図

土台の柱0 と 2 本の柱は、目的もあなたの作業量も別物です。まず全体像を表で押さえておきます。

以下、この記事で使う CodeRouter は v2.7.7 時点を前提にします。まだ入れていない、あるいは古い人は、まず更新しておいてください。

uv tool install coderouter-cli          # 恒久インストール
uv tool update-shell
exec $SHELL -l
coderouter --version                    # → 2.7.7 以降ならOK

`uvx` 派なら `uvx coderouter-cli serve --port 8088` で起動時に最新を引けます。

それでは柱0から。

柱0: まずモデルを選ぶ — 結論だけ(詳細は別記事へ)

この後の柱1(MTP)・柱2(外部エージェント)の効果を最大化する土台として、載せるモデルを 1 本決めておきます。前回の「定番どころ」(Qwen2.5-Coder 7B 等)のままの人は、蒸留モデルへの差し替えだけで精度が一段上がります。蒸留モデルとは、大型モデル(教師)の出力や推論過程を小型モデル(生徒)に学習させたモデルのこと。Claude 系のトレース等で学習した「エージェント特化」系は、同サイズの汎用モデルよりコーディングや Tool Call が強く出る傾向があります。

筆者の実測ベンチ(llmbench・コーディング 40 タスク)からの、16GB 向けの結論だけ表にします。

前提は 2 行だけ。スコアは RTX5090 環境の実測なので、「16GB に収まるか」の判断とモデル間の相対比較に使ってください。16GB 実機の実効メモリは 6〜8GB 程度なので、gguf は 6〜7GB 台+ctx 控えめが安全圏です。

部門別(コーディング / Tool Call / 日本語 / 超軽量 / 推論数学)の詳しいガチンコ比較、量子化の選び方、選外にした理由は、別記事に一本まるごとまとめてあります → 16GBノートPCの部門別最強LLMはどれか — 蒸留・9B級モデルガチンコ比較(2026年7月版)

この記事として大事なのは、ここから先の接続です。Ornith-1.0-9B と Qwythos-9B には nextn(MTP)層入りの gguf 変種が配布されており、次の柱1 の自動検出がそのまま効きます(筆者が実機で MTP 起動を確認したのも Ornith 系 9B の変種でした)。つまり ── ①蒸留モデルを選ぶ → ②MTP 変種があればそちらを取る → ③launcher に置けば自動で速くなる。①で精度、②③で速度。その②③の仕組みが柱1 です。

柱1: MTP / 投機的デコード — ローカル生成を速くする

まず理屈 — なぜ 16GB マシン「こそ」効くのか

投機的デコード(speculative decoding)は、小さく速い「下書き(draft)」で数トークン先読みし、本体モデルで一括検証して当たった分をまとめて確定する高速化手法です。その中でも MTP(Multi-Token Prediction) は、本体モデルの gguf に内蔵された nextn 層を draft に使う方式で、別の draft モデルファイルが要らないのが特徴です。

llama.cpp はこれを `--spec-type` フラグで切り替えます。

先読みトークン数は `--spec-draft-n-max`(既定 3)で決まり、MTP では 2〜3 が推奨とされています。llama.cpp の PR #22673 では、3 draft トークンで採択率およそ 75%、デコードが2 倍超に速くなったという報告があります(計測は CUDA 中心で、バックエンドごとの成熟度にはばらつきあり)。

ここで「MTP は VRAM 潤沢なマシンの話でしょ」と思われがちなのですが、16GB クラスでも恩恵はあります。むしろ構造的には、帯域が細いマシンほど相対的な伸びしろが大きい。

理由は、ローカル LLM のデコードが帯域律速だからです。1 トークン生成するたびに、モデルの重みをメモリから読み直している。draft で 2〜3 トークンをまとめて一括検証すれば、その 1 回の重み読み込みを複数トークンで償却できる。演算そのものより前に、メモリ帯域の使い方で得をする構図で、これは 16GB の Mac やミニ PC こそ該当します。

手順 — あなたがやることは 3 つだけ

CodeRouter v2.7.6 の launcher は、MTP まわりを全自動でやります。`mtp_mode="auto"`(既定)の 3 段判定は次の通り。

1. 本体 gguf の nextn を検出 → あれば `--spec-type draft-mtp`。別ファイル不要。

2. なければ、同じフォルダから companion gguf を自動検出(名前に `mtp` / `draft` を含む、サイズがメインの 50% 未満、arch 一致、等)→ 見つかれば `draft-simple` + `--model-draft` を内部で組み立て。

3. どちらもなければ通常起動。

しかも、auto で付けた spec 起動が異常終了したら、1 回だけ spec なしで自動再起動します(後述の「テスト段階」の安全網)。つまり、対応が未成熟なモデルを掴んでも壊れません。

その分、ユーザーがやることは 3 つに減ります。

(a) llama.cpp を新しくする ── ここが一番の罠

MTP を試す前提として、llama.cpp が新しいことが絶対条件です。`--spec-type` 系フラグに対応した最近のビルドが必要なのはもちろんですが、もっと分かりにくい罠があります ── nextn 内蔵 gguf は、古いビルドだと「MTP が使えない」ではなく「モデル自体がロードできない」。

古いビルドで nextn 入り gguf をロードすると、こんなエラーで死にます。

llama_model_load: error loading model: missing tensor 'blk.32.ssm_conv1d.weight'

通常層が 0〜31 の 32 層モデルで、`blk.32` は MTP(nextn)用の追加ブロック。nextn を知らない古いビルドはこれを通常層だと思ってテンソルを探しに行き、「無い」で死ぬ。エラーメッセージからは MTP の M の字も見えないのが意地悪なところです。

まず対応を確認します。

llama-server --version                  # b99xx 台の新しめか
llama-server --help | grep spec-type    # draft-mtp が列挙されるか

古ければビルドし直します。Mac(Apple Silicon)は Metal が既定で有効、フラグ不要です。

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build
cmake --build build --config Release -j $(sysctl -n hw.ncpu)

更新時は必ず `rm -rf build` してから。`CMakeCache.txt` に古いフラグが残ったまま再ビルドされる罠は、OS を問わず踏めます。

(b) MTP が効くモデルを選ぶ

2 通りあります。

• nextn 内蔵の gguf 変種を使う。名前に `-mtp` が付いていることが多い。柱0 で挙げた Ornith-1.0-9B や Qwythos-9B の MTP 変種がまさにこれです。

• nextn を内蔵したモデルを使う。GLM 系(GLM-4 MoE など)は `{arch}.nextn_predict_layers` をメタデータに持っており、これが 0 より大きければ「自前で draft ヘッドを持っている」モデルです。

16GB で使うなら、別 draft モデル方式より、メモリ追加が小さい内蔵 nextn 型を選ぶのが安全です(理由は後述の注意)。

(c) launcher で普通に起動する

あとは CodeRouter の launcher でモデルを選んで起動するだけ。MTP の欄は空欄・auto のままで構いません。上の 3 段判定が勝手に走ります。ログにこう出れば第 1 段が当たっています。

[launcher] MTP: nextn layers (1) detected in main gguf → --spec-type draft-mtp

実測例を 1 つ。柱0 で挙げた **Ornith 系 9B の MTP 変種(nextn=1)**を掴ませたところ、検出が第 1 段で当たり、別ファイルなしで `--spec-type draft-mtp` が付き、12 秒でロード完了して正常動作しました。

16GB での注意 — スワップに入ったら逆効果

MTP は無条件に速くなる魔法ではありません。nextn 層の分だけ gguf もコンテキストもメモリが増えます(モデル規模にもよるが数百 MB〜1GB 弱)。それでスワップに入ったら本末転倒 ── 帯域を稼ぐために足したものが、もっと遅いストレージ I/O を呼び込んで逆効果になります。

16GB で使うときの指針はシンプルです。

• 内蔵 nextn 型を選ぶ(別 draft モデル方式よりメモリ追加が小さい)。

• ctx-size は控えめに。

• `--spec-draft-n-max` は既定の 2〜3 のままいじらない。

「効く環境では効かせ、壊れる環境では壊さない」は、性能の面でも同じ話です。まずはメモリに余裕を残す設定から始めてください。

正直な注意 — MTP 対応は「テスト段階」だと思って使ってほしい

ここは強調しておきます。MTP 対応は「テスト段階」だと思って使ってください。

未成熟なのは CodeRouter の launcher ではなく、llama.cpp 側のアーキテクチャ別の成熟度です。GLM 系や一部の内蔵 nextn モデルは今日から効く。一方で、検出が 100% 正しく動いても、llama.cpp 側が起動時に落ちる arch がある。実際、あるコミュニティ製の 12B(nextn=4)モデルは、検出は完璧なのに `llama-server` が SIGSEGV。ビルドやフラグを変えても、MTP を切った素の起動でも落ちる ── launcher では救えない、upstream 側がまだ作りかけの領域でした。

だから CodeRouter は「auto で付けた spec 起動が異常終了したら、1 回だけ spec なしで自動再起動」する安全網を持っています。落ちても、通常起動へ静かに戻る。

[launcher] MTP startup failure detected (exit code -11); retrying without speculative decoding

まとめると ── 効く環境では速くなり、壊れる環境では(自動フォールバックで)壊れない。だから「入れておいて損はないが、全モデルで速くなると期待はしない」くらいの温度感で使ってください。この経緯(検出は当たったのに起動できなかった話、ビルドの切り分け、自動フォールバックの設計)は、開発日記側で詳しく書いています → 検出は当たっていたのに起動できなかった — CodeRouter v2.7.6 の MTP 対応は「テスト段階」だと思って使ってほしい話。

柱2: 外部エージェント backend — 重い仕事だけサブスク Claude に投げる

考え方 — 16GB の 7〜9B に「全部」やらせない

前回は「ローカルで安定して動かす」がゴールでした。でも正直なところ、16GB マシンに載る 7〜9B モデルに、設計や難しいバグまで全部やらせるのは荷が重い。ローカルで気持ちよく回るのは、日常の軽い編集・リファクタ・説明生成あたりまでで、「ここは頭を使う」という場面ではやはり Opus / Sonnet 級の判断力が欲しくなります。

そこで v2.7.7 の 外部エージェント backend(`kind: "agent_cli"`) です。狙いは「軽い作業はローカル、重い箇所(設計・難バグ)だけ Claude(Opus/Sonnet)」というハイブリッドを、1 つの CodeRouter から使い分けること。

仕組みはシンプルで、`claude -p`(Claude Code CLI のヘッドレスモード)を 1 プロバイダとして登録します。CodeRouter から見れば、外部エージェントを「プロンプトを入れたらテキストが出てくる箱」として one-shot で叩くだけ。普段扱っている LLM プロバイダと同じ形に縮退するので、fallback チェーン・profile・guards・コスト計上をそのまま継承できます。

いちばん効くのはここです ── Pro / Max サブスクの OAuth で動く=API キー不要・従量課金ゼロ。1 リクエストごとの API 課金は発生しません(サブスクの 5 時間窓を消費するだけ)。「クラウドの賢いモデルを、追加の請求なしで、ここぞの場面だけ呼ぶ」が実現します。

設定 — providers に 1 個足す

`providers.yaml` に、既存のローカルプロバイダはそのまま残して 1 個だけ足します。動く完全な例はリポジトリ同梱の `examples/providers-agent-cli.yaml` にあるので、ここでは核になる数行だけ示します。

providers:
  # --- 既存のローカル(前回組んだもの) ---
  - name: ollama-qwen-coder-7b
    model: qwen2.5-coder:7b
    # ...

  # --- 今回足す: 外部エージェント backend ---
  - name: claude-agent
    kind: agent_cli            # ← 新しい種類の backend
    model: sonnet              # CLI へ渡す --model。軽用途は sonnet 推奨(理由は後述)
    paid: false                # サブスク=従量ゼロ。有料ゲートの対象外
    capabilities:
      streaming: false         # 擬似ストリームのみのため明示
    agent_cli:
      agent: claude            # Phase 1a は claude のみ実装済み
      # 既定で read-only(FS を書き換えさせない)

`paid: false` がポイントです。サブスク OAuth で呼ぶ claude backend は従量課金がゼロなので、意味論的に `paid: false` が正しい。有料ゲート(`ALLOW_PAID`)は「1 コールごとに課金が走る backend」を止める仕組みなので、サブスク backend はそもそもゲートの対象外であるべき、という整理です。

使い分けは profile を分けて `X-CodeRouter-Profile` ヘッダで切り替えるのが基本形です。「普段はローカル profile、ここぞの重い作業だけ claude-agent を先頭にした profile」を用意しておき、リクエスト側でヘッダを差し替える。

# 重い作業だけ、claude-agent を含む profile を指名する
curl -s localhost:8088/v1/chat/completions \
  -H "X-CodeRouter-Profile: claude-agent" \
  -d '{"model":"claude-agent","messages":[{"role":"user","content":"..."}]}'

コスト実測 — 「1+1は?」で prompt_tokens 約 2.5 万

ここは数字で正直に見せます。`1+1は?` という 4 文字を投げただけの実測(ぼかし済み)です。

# → "usage":{"prompt_tokens":25657,"completion_tokens":25},
#    "coderouter_cost_usd":0.2227

prompt_tokens が約 2.5 万。たった 4 文字で 25,000 トークン超を消費しています。理由は明白で、`claude -p` を叩くと Claude Code のシステムプロンプト一式(ツール定義、各種指示、環境情報……)が丸ごと載るからです。

コストにすると 1 呼び出しで $0.2 相当。サブスク認証なので請求はゼロですが、Claude Code のサブスクには 5 時間窓のレート制限があり、この呼び出しはその枠を確実に食います。「請求ゼロ」と「無料」は違う、ということです。

ただし救いもあります。2 回目以降はプロンプトキャッシュが効いて、コスト相当額が初回の 1/4 程度($0.22 → $0.05)に下がります。同じセッションで続けて叩くほど、システムプロンプト分が償却されていきます。

この数字から出る結論は明確です。

• 外部エージェント backend は「ここぞ」で使う重装備。電卓代わり・チャット連打には向かない。

• 軽い用途には `model: sonnet` を指す(上のサンプルで sonnet にしてあるのはこのため)。判断力が本当に要る場面だけ opus を指す profile を別に用意する。

検証状況を正直に

実機で確認できているのは macOS と Ubuntu(Linux)の 2 つです。

また、実装済みの backend は現時点で **`claude` のみ(Phase 1a)**です。`codex` / `gemini` / `grok` は今後の追加予定で、現時点では設定を書くと「未実装」と明確に拒否されます。

認証 Tips

• macOS / Linux のデスクトップ: `claude /login` 済みなら、そのまま `claude-agent` が動きます。追加のトークン設定は不要。

• ヘッドレスサーバー / コンテナ: 画面が無いので `claude setup-token` でトークンを発行し、`.env` に `CLAUDE_CODE_OAUTH_TOKEN` を置いて、CodeRouter 側の `passthrough_env` で子プロセスへ転送します。この経路は未検証扱いなので、動いたら教えてもらえると助かります。

小ネタ — launcher の自動同期と、プロンプトキャッシュ

短く 2 つだけ。

launcher provider auto-sync(v2.7.4〜)。launcher でモデルを起動すると、そのモデルが自動でルーティングに登録されます。以前のように `providers.yaml` を手で編集して「起動したモデルとルーティング設定を一致させる」手間が消えました。柱1で MTP 付きのモデルを launcher から起動すれば、そのまま Claude Code のバックエンドとして繋がります。

プロンプトキャッシュの効き。柱2で触れた「2 回目以降 1/4」は、外部エージェントに限らず効く一般的な話です。同じ前提(システムプロンプトや長い文脈)を繰り返し投げる使い方ほど実消費が下がる ── 連続した作業セッションの中で使うほど得です。

まとめ — まず何をやるべきか(優先順位表)

土台 1 つと 2 本柱を紹介しましたが、全部を一度にやる必要はありません。あなたの「今いちばん困っていること」から 1 つずつで十分です。

順番の考え方はこうです。まず優先度 1(llama.cpp 更新)は、MTP をやるやらないに関わらず、新しいモデルを触るなら遅かれ早かれ必要になります。原因の分かりにくい `missing tensor` 罠を先に潰しておくと後がラクです。

次に優先度 2(蒸留モデル)。gguf を 1 本落として差し替えるだけで、実測ベンチで裏の取れた精度向上が手に入ります。今回いちばん費用対効果が高い一手です。優先度 3(MTP)はその続きで、選んだモデルに MTP 変種があればそちらを取るだけ。効かなくても自動フォールバックで壊れないので、リスクがほぼありません。

優先度 4〜5(外部エージェント)は、ローカルだけで回していて「ここは 7〜9B にはキツいな」と感じ始めてから足すのが自然です。いきなり opus に全部投げると 5 時間窓をすぐ使い切るので、まず sonnet から。慣れてきたら opus の profile を分ける。

いずれも共通しているのは、「入れておいて、効く場面で効かせる」道具だということです。蒸留モデルで底上げし、MTP は速くなる環境で速くし、外部エージェントは頭が要る場面だけ賢いモデルを借りる。16GB という制約の中で、無理せず伸ばせるところを伸ばす ── 前回の「安定して動く」の、その次の景色です。

リンク集

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

• 柱0 の詳細(モデル選びの部門別比較): 16GBノートPCの部門別最強LLMはどれか — 蒸留・9B級モデルガチンコ比較(2026年7月版)

• MTP の「テスト段階」の内幕(開発日記): 検出は当たっていたのに起動できなかった — CodeRouter v2.7.6 の MTP 対応は「テスト段階」だと思って使ってほしい話

• CodeRouter(GitHub・MIT ライセンス): https://github.com/zephel01/CodeRouter

CodeRouter は `uv tool install coderouter-cli` で動く個人開発 OSS(MIT)です。手順が役に立ったら、GitHub のスターが次のリリースの優先順位を決める力になります。「16GB でこう効いた/効かなかった」の実機フィードバックも Issue / Discussion で歓迎です。それでは、よい AI コーディングライフを。
また、こちらに質問、または質問箱などでもよいです。