Claude Code に毎日寄りかかっていると、ふと「これ全部、向こうの会社が動いている前提で成立しているな」と思う瞬間がある。
サーバーが落ちる日。
新しい利用規約が来る日。
レートが急に絞られる日。
値段が変わる日。
どれもこちらの都合では止められない。フロンティアモデルに食わせている内容を、ふと考え直してしまう日もある。クライアントから預かったコード。書きかけの企画。整理しきれていない自分の思考。
そういうとき、もう一つの選択肢として ローカル LLM が手元にあるかどうかで、生活の落ち着きが変わる。
2026 年に入ってから、ローカル LLM は急に「実用上ありな選択肢」のラインを越えた。
毎日使う本機はやはり Claude Code でいい。ただし、その隣にもう一台、自分の機械の上で動く LLM を置いておく。これが今の落とし所だ。
この記事では、その「隣に置く」位置づけで、何のために使うか・どう入れるか・どのモデルを選ぶかを整理する。
ローカル LLM が、ようやくまともになった年
正直に言うと、去年まではローカル LLM はおもちゃだった。
動かしてみるのは楽しい。だが本気で日常作業に組み込もうとすると、性能がフロンティアモデルから何段階も落ちていて、結局メインのサブスクに戻る。そういうものだった。
その温度感が、2026 年に入ってから明確に変わった。
たとえば Qwen 3.5 は、合計 122B パラメータの MoE 構成で動かすときに活きるのは 10B ぶんだけという仕組みで、ユニファイドメモリが 64GB ある MacBook の上にそのまま乗る。前世代の Qwen 3 (235B) は GPQA Diamond 77%、AIME 85% という数字を出していて、Qwen 3.5 はその後継として 10B 実働でその系譜に並んできた。これはもう「家で動かす遊び」ではない。
コーディング特化なら GLM-5 がオープンモデルとして SWE-bench Verified で 77.8% に届いている。推論の深さで選ぶなら DeepSeek R1 が MATH-500 で 97.3% を出している。万能型で言うと Gemma 4 (26B) がコンシューマー機の上で 1 秒あたり 85 トークン出る。
もちろん、Claude Opus の最新世代と並べたら差はある。
でも、「ローカルだから劣る」と言って切り捨てる距離ではもうない。用途を絞れば、十分日常的に使えるレンジに入ってきた。
何のためにローカル LLM を置くのか
毎日触っていると、ローカル LLM を起動する理由は大きく 4 つに整理されてくる。
1. 出したくない情報を食わせる。
クライアントから預かったコード。社内ドキュメント。書きかけの企画。NDA 越しに見たもの。
これらをフロンティアモデルの API に流すのは、規約上 OK だとしても、心情的にずっとうっすら気持ち悪い。
ローカルなら、その不快感そのものが消える。embedding を作るのも、要約させるのも、推論を回すのも、ぜんぶ自分の機械の中で完結する。
2. RAG の自前ベース。
自分の書きためたメモ、過去のチャットログ、業務ナレッジ。これらを検索・要約・引き出しに使うパイプラインを、丸ごとローカルで組める。AnythingLLM や LangChain といったツールが、ローカル LLM 前提の RAG をかなり素直に動かせるところまで来ている。
外に出ない知識ベースを自分専用に持てる、というのは思った以上に効く。サブスク横断で散らかっている知識を、一つのローカル AI が把握している状態は強い。
3. 終日まわす重い処理。
大量のテキスト整形、ログ解析、データクレンジング、定型変換。
API で回すと毎回お金が動くし、レートにも引っかかる。ローカルなら、機械が起きている間ずっと回せる。
寝ている間に何千件か処理しておく、みたいな使い方が、罪悪感ゼロでできる。
4. オフライン・低レイテンシ用。
ネットが弱い環境、移動中、海外、災害時。
普通の作業をしているときには気づかないが、いざフロンティアモデルにアクセスできない状況になると、人間の生産性は一気に落ちる。
ローカル LLM を一台抱えていれば、その落差を緩衝できる。レイテンシも当然短い。
この 4 つのうちのどれかが自分の動きに刺さるなら、ローカル LLM を入れる価値が出てくる。逆に、どれにも刺さらない人は、無理に入れる必要はない。Claude Code 一本のままで困らない。
一番楽な入り方は LM Studio
「とりあえず触ってみたい」段階なら、迷わず LM Studio から入る。
アプリをダウンロードして開いて、モデルを選んで、チャット欄に何か打つ。これでもう動く。インストールから最初のトークンが出るまで、感覚で言うと数分。Apple Silicon 機なら MLX バックエンドが裏で勝手に効いて、同じモデルでも 1.3 〜 1.6 倍速くらいトークンが出る。
GUI で動くので、ターミナルにあまり親しんでいない人でも詰まらない。モデルごとの量子化を選ぶ画面も、温度などのパラメータも、全部マウスでいじれる。
「LLM をローカルで触る」がどういう体験なのかを、最初に肌で掴むには圧倒的にここが早い。
本気で組むなら Ollama を中心に置く
遊びを越えて、自分のスクリプトや自動化と組み合わせ始めると、LM Studio だと面倒な瞬間が来る。アプリを開かないと動かない。CLI でサクッと叩けない。他のプログラムから API として呼びにくい。
このフェーズに来たら、メインは Ollama に移す。
インストールは、公式サイトに置かれているワンライナーを実行するだけだ。ollama run qwen3 のような形でモデルが落ちてきて動き出す。OpenAI 互換の API がローカルに立つので、自分の Python スクリプトや Node スクリプトから、API キーなしの URL を叩くだけで会話できる。
Mac mini を据え置きで使っているなら、ここがほぼベストポジションになる。自動投稿、定型変換、夜間バッチ、自分専用ボット ── どれもこの土台で組める。「裏で常時動かしておく LLM サーバー」を、家の中に一台置くイメージだ。
2026 年に入ってから Ollama 側も Apple Silicon 向けに MLX バックエンドが入ったので、Mac で動かしたときの速度感もかなり改善した。
もっと細かく握りたければ llama.cpp と mlx-lm
Ollama も LM Studio も、結局は llama.cpp という推論エンジンを内側で使っている。
「ラッパーごしじゃなくて、自分で全部触りたい」「組み込み機器や省メモリ環境でも動かしたい」となったら、llama.cpp を直接使う選択肢になる。
バイナリは数十 MB と非常に軽い。コンテキスト長、量子化、スレッド数、その他の細かいパラメータを全部自分で握れる。逆に言えば、全部自分で面倒を見ないといけない。初手では選ばないが、長く使い込んでいくと結局ここに着地する人が多い領域だ。
Apple Silicon に最適化された mlx-lm も、検討に入れていい。ユニファイドメモリを前提に、CPU と GPU の間でデータをコピーせずに済むぶん、同じ Mac でも素の llama.cpp より速いケースがある。Mac mini の性能をフルに引き出したい人向けの選択肢だ。
モデルの選び方は、機械と用途で決める
2026 年現在で、迷ったら覚えておけばいいモデルはそれほど多くない。組み合わせ方を整理しておく。
RAM が 8 〜 16 GB の普通の PC しかない場合。
無理せず Phi-4-mini (3.8B) を入れる。GPU は要らない。手元のノート PC で、要約・下書き・軽い質問応答くらいなら普通に回る。ここでまず「ローカル LLM が動く」という事実に体を慣らす。
Mac mini や MacBook で 32 〜 64 GB のメモリを積んでいる場合。
本命は Qwen 3.5 (MoE) になる。動いている間に走るパラメータは 10B 前後で済むのに、合計サイズの大きい MoE 由来で賢さがぐっと上がる。汎用の壁打ち相手として、これを常時走らせておけば、ローカル側で困ることはほぼ無くなる。
万能型でもう少し堅実に行きたい場合は Gemma 4 (26B)。コンシューマー機で 1 秒あたり 85 トークンというのは、書きながら読める速度であり、待たされない。日常用途の安定感がいい。
コードを食わせる用途が中心の場合。
GLM-5 を入れる。オープンモデルとしてはコーディングベンチで頭ひとつ抜けている。Claude Code を母艦にしたまま、機密寄りのリポジトリ専用にこちらをサブで立てる、という構成と相性がいい。
数学やロジック寄りの推論を回したい場合。
DeepSeek R1 系を動かす形が一番強い。フル版は 671B のうち実働 37B という MoE 構成で、こちらをそのまま動かすには数百 GB クラスのメモリが要るので、現実的には DeepSeek R1 の蒸留版 (14B〜32B 帯) をローカルに置く形になる。蒸留でも推論能力はかなり残っていて、純粋な推論用途ではオープン側の頂点に近い位置にいる。すべての人が必要とする道具ではないが、推論を内製したい人にとってはここが入口になる。
ライセンス面で言うと、Qwen 3.5 は Apache 2.0、DeepSeek は MIT、GLM-5 も MIT というように、商用利用や微調整に対してかなり緩い側に寄ってきている。これも 2026 年の地殻変動の一部だ。「オープンモデルは商用には微妙」という前提は、もう古い。
Claude Code を置き換える話ではない
ここを誤解されると話がこじれるので、はっきり書いておく。
ローカル LLM は、Claude Code の代替ではない。
本気でコードを書くフェーズ、本気で企画を立てるフェーズ、本気でプロダクトを組むフェーズでは、引き続きフロンティアモデルが圧倒的に強い。Claude Opus の最新世代と、家の中の MoE モデルを並べたら、差はある。これは事実だ。
ローカル LLM は、その下にもう一段、自分の都合だけで動かせるレイヤーを持つという話だ。
外に出したくない情報、終日まわしたい処理、自分専用の RAG、オフライン用の補助。
これらを Claude Code に頼まずに済む側に逃がしておく。本機に余計な負荷をかけない。サブスクの利用枠も浪費しない。心理的な「これ出していいんだっけ」も消える。
表現を変えれば、ローカル LLM は 個人スタックの基礎工事だ。
表に見えるアウトプットを生むのはやはりフロンティアモデル側だが、その手前にもう一枚、自分の機械の上で動く層を置いておくことで、上モノの動きが安定する。
結局、入れるか入れないか
最後にもう一度整理する。
毎日 Claude Code でガリガリ前進していて、データの中身も特に気にしておらず、ネット環境にも困っていないなら、ローカル LLM を急いで入れる理由は無い。今のまま走り続けていい。
ただし、次のうちどれかに心当たりがあるなら、もう一台手元に置く判断は十分に合う。
クライアントから預かったコードを API に流すたびに、ちょっと迷っている。
サブスクの利用枠を、定型変換やログ整形で食い潰している実感がある。
ネットの弱い場所で AI が使えなくて、毎回テンションが落ちている。
自分の書きためたメモやログを、横断検索できる仕組みを欲しがっている。
このどれかが刺さるなら、入れたほうがいい。
2026 年のローカル LLM は、もうそれだけの実力を持ったレイヤーになっている。
本機 + 隣にもう一台。これがこれからの個人スタックの標準形になる。