17
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ootakazuhiko(太田 和彦)Team Tea & Waterin株式会社アイティードゥ

Windows 11 PCで動作する開発用途のローカルLLMの選定

17
Last updated at Posted at 2026-04-14

はじめに

2026年4月時点では利用できるローカルLLMの候補がかなり増えています。いざ導入しようとすると実際に以下のような点で迷います。

  • 結局どのモデルから試すべきか
  • どこまでを候補に入れるべきか
  • ハードウェア制約の中で、何を諦めるべきか

そこで今回は、導入の前段階として手許にある以下の環境を使う前提でモデルを選定します。

  • Windows 11 Pro
  • eGPU で RTX 4060 Ti 16GB

また選定基準として以下を考えます。

  • 開発用途
  • ローカル実行前提
  • 機密情報を扱うことに配慮する

なお、この記事では選定のみを行い、導入は別記事とします。
また「なぜこの候補を残し、なぜ他を落としたか」が分かるように書きます。

2026-06-04追記: 本記事公開後の最新状況は、補遺記事「Windows 11 PCで動作するローカルLLM候補選定のアップデート 2026年6月版」にまとめました。Ollama v0.30系、Granite 4.1、LLM-jp-4-VL 9B beta、Foundry Local、Gemma 4 12B について追記しています。なお、この記事で選んだ第一陣4モデルは変更していません。

(2026/05/17追記) : 2026年5月中旬時点の状況を確認し、Ollama v0.24.0、Granite 4.1、Foundry Local、LLM-jp-4-VL 9B beta まわりの記述を更新しました。
結論である第一陣の4モデル、gpt-oss-20b / Devstral Small 2 / Gemma 4 E4B / LLM-jp-4-8b-thinking は変更していません。

(2026/04/29追記) : 公開後に LLM-jp-4-VL 9B beta、Microsoft Foundry Local、Ollama v0.21 系以降の更新を確認したため、追加候補と実行基盤に関する注記を追記しました。
結論である第一陣の4モデル、gpt-oss-20b / Devstral Small 2 / Gemma 4 E4B / LLM-jp-4-8b-thinking は変更していません。

今回の前提条件

今回は、手元の開発用PCで実際に動かせることを前提に置きました。最新でない比較的入手しやすいスペックです。

項目 条件
用途 開発用途、コード支援、技術文書要約、ローカル検証
OS Windows 11 Pro を維持
ハードウェア ミニPC + eGPU
GPU RTX 4060 Ti 16GB
メモリ 64GB
実行基盤 まずは Ollama を主系にする
方針 機密情報を扱うことに配慮する

ここで重要なのは、**「最強モデル」探しではなく「この構成で回る候補を選ぶ」**ことです。
24B級までは比較対象に含められる一方、70B級以上は最初の比較対象として現実的ではありません。

また、今回はローカル推論の実用性を見たいので、
「強いけれどクラウド前提」「巨大すぎて専用サーバ前提」のものは最初から除外します。

比較対象の前提と除外基準

基準について先に明記しておきます。

本記事では、単純な性能比較ではなく、機密情報を扱う開発環境に導入できるかも評価軸に含めています。
そのため、比較対象は ローカル実行を前提に、法域、データ経路、更新経路、供給網の透明性を確認しやすいものに絞りました。

この方針に基づき、本記事では PRC法域のベンダ／サービス、または PRCへのデータ保存・更新経路を持つ製品を比較対象から外しています。
ここで重視しているのは国籍や民族ではなく、法域リスク、支配関係、データガバナンス、供給網の検証可能性です。

この整理は独自基準ではありません。デジタル庁の「生成AIの調達・利活用に係るガイドライン」概要資料でも、特定秘密や安全保障等の機微情報を扱うシステムは対象外と整理されており、機微情報を扱う環境ではより厳格な前提を置くべきことが示唆されています[1]。
また英国NCSCは、AI/MLの供給網では transparency / traceability / validation / verification を確保し、作成方法が不透明なモデルでは supply chain contamination のリスクが高まると整理しています[2]。

加えて、2025年には豪州政府が DeepSeek 製品・アプリ・Webサービスについて、政府システム上での利用・インストール防止と既存導入物の除去を求める指示を出しています[3]。
本記事は政府調達の話そのものではありませんが、法域・供給網・統制可能性の観点で特定AI製品を制限する判断には公的な先例があることは補足しておきます。

要するに、この記事の除外基準は
「機密開発環境に説明責任を持って導入しにくいものを外す」
という整理です。

なお、PRC起源のアーキテクチャを採用した派生モデルまで一律に除外するかは別論点です。
この記事ではそこは個別注記にします。
たとえば LLM-jp-4 32B-A3B のように、国内で学習・公開されていてもベースアーキテクチャが Qwen 系のものは、法域・データ経路とは別の境界ケースとして扱います。

実行基盤は Ollama から始める

実行基盤は、まず Ollama を主系に置きます。

理由は単純で、今回の条件では Windows で最短で比較に入れるからです。

  • Windows ネイティブで入れられる
  • ローカルAPIがすぐ立つ
  • モデルの取得と切り替えが簡単
  • 比較記事を書くときに再現しやすい

LM Studio も有力ですが、調査時点では 主系は Ollama、LM Studio は必要なら後で使う という整理にしました。

追記: Ollama v0.24.0 について

2026年5月中旬時点では、Ollama は v0.24.0 が latest になっています。
v0.24.0 では Codex App 連携が追加され、ollama launch codex-app が案内されています。

本記事の目的である「複数モデルをローカルで比較する」段階では、引き続き Ollama を主系にします。
特に gpt-oss:20b、devstral-small-2、gemma4:e4b、granite4.1:8b のようなモデルを同じ実行基盤で比較しやすい点は、Ollama の利点です。

なお、この記事の当初調査時点とは Ollama のバージョンが進んでいるため、実測時には最新の Ollama で再確認する前提にします。

追記: Foundry Local について (2026/04/29追記)

公開後に、Microsoft の Foundry Local も確認しました。
Foundry Local は、アプリケーションにローカルAIランタイムを同梱して配布する用途では有力です。Windows / Linux / macOS に対応し、SDK、モデル取得、ハードウェアアクセラレーション、ローカル推論をまとめて扱えます。

ただし、Microsoft の公式ドキュメントでは、Foundry Local は production applications 向けであり、general-purpose model experimentation 向けではないと説明されています。
そのため、本記事の目的である「複数モデルを比較しながら開発用途に絞る」段階では、引き続き Ollama を主系とします。

Foundry Local は、後で Windows アプリにローカルAI機能を組み込んで配布する段階で再評価する候補です。
また、Foundry Local の curated catalog には Qwen や DeepSeek なども含まれるため、本記事の除外基準を適用する場合は、ランタイム単位ではなく モデル単位で allowlist を作る必要があります。

まず候補に入れたモデル

最初に洗い出した候補は以下です。

主に検討した候補

  • gpt-oss-20b
  • Devstral Small 2
  • Gemma 4 E4B
  • Gemma 4 26B-A4B
  • LLM-jp-4-8b-thinking
  • LLM-jp-4-32b-a3b-thinking
  • **LLM-jp-4-VL 9B beta (2026/04/29追記)
  • Mistral Small 3.2 24B
  • Granite 3.3 8B
  • CyberAgent Mistral-Nemo-Japanese 12B

最初から外した候補

  • Qwen / DeepSeek / GLM 系
  • Llama 4 系
  • 70B 以上の重量級モデル
  • クラウド前提でしか意味が薄いもの

ここから、用途と制約に合わせて絞り込みます。

評価軸

今回は、次の4軸で見ました。

  1. 日本語
  2. コード
  3. 軽量マルチモーダル
  4. 導入成熟度

1. 日本語

日本語での自然さ、日本語文書の要約・リライト・説明の安定性です。
単に「日本語対応」と書いてあるだけではなく、実際に日本語を強く見ていそうかを重視しました。

2. コード

実務のコード支援に使えるかです。
単なるコード生成だけでなく、設計説明、既存コードの修正、ログからの推定まで含めて見ています。

3. 軽量マルチモーダル

画像入力やUI理解を、4060 Ti 16GB で現実的に回せるかです。
テキスト専用モデルはこの軸では不利です。

4. 導入成熟度

ここはかなり重要です。
モデル自体が強くても、

  • 実行導線が不安定
  • 変換が必要
  • テンプレートが特殊
  • 量子化版や実行実績が少ない

というものは、初手の比較対象としては扱いづらいです。

採点結果

5点満点、0.5刻みでざっくり採点するとこうなりました。

モデル 日本語 コード 軽量マルチモーダル 導入成熟度 一言
gpt-oss-20b 4.0 4.5 1.0 5.0 ローカル推論の基準機にしやすい
Devstral Small 2 3.0 5.0 3.0 5.0 コード主力候補
Gemma 4 E4B 3.0 3.0 5.0 5.0 軽量マルチモーダルの本命
LLM-jp-4-8b-thinking 5.0 3.0 1.0 2.5 日本語枠の本命、ただしまだ荒い
LLM-jp-4-VL 9B beta 4.5 2.5 4.0 2.0 日本語マルチモーダル候補。ただし beta で導入は重め (2026/04/29追記)
Mistral Small 3.2 24B 3.5 4.0 3.0 5.0 強いが初手の役割がやや重複
Granite 3.3 8B 2.5 3.5 1.0 4.5 軽量補助候補として優秀
CyberAgent Mistral-Nemo-Japanese 12B 4.5 2.5 1.0 3.0 日本語実務文には期待できる

ここで大事なのは、総合1位を決めることではないです。
この時点で必要なのは、役割が違うモデルを比較対象として残すことです。

最終的に候補となった4モデル

実測比較の第一陣として残したのは、この4モデルです。

モデル 残した理由 想定役割
gpt-oss-20b ローカル推論の基準機にしやすい 推論・コードの基準モデル
Devstral Small 2 コード用途で最も面白い コード主力候補
Gemma 4 E4B 軽量でマルチモーダル 画像込みの軽量比較枠
LLM-jp-4-8b-thinking 日本語比較で外せない 日本語枠の本命

以下、それぞれの理由を書きます。

1. gpt-oss-20b

OpenAI公式でも gpt-oss-20b は 21B total / 3.6B active の reasoning モデルで、Ollama やローカル実行向け案内でも 16GBメモリ級 が目安とされているため、今回の構成では基準機として置きやすいです。

これは最初から外しづらいモデルでした。

理由は3つです。

  • ローカル前提で設計された感が強い
  • 推論・コード・ツール利用のバランスが良い
  • 導入成熟度が高い

特に今回のような 16GB VRAM クラス では、
「とりあえずこれを基準にすればよい」と言えるモデルがあるのは大きいです。

実際、今回の候補群の中でも、
比較の基準機という役割を一番担いやすいのがこれでした。

日本語専用モデルではありませんが、
日本語もそこそこ見られる / コードも見たい / 実装のしやすさも重要
という前提なら、最初に外す理由がありません。

2. Devstral Small 2

Mistral公式でも Devstral Small 2 は 24B / 256K / Apache 2.0 の locally deployable な coding モデルで、image inputs にも対応しているため、コード主力候補として残す理由がかなり明確です。
コード用途の本命候補です。

このモデルを残した理由は明快で、
「コード用途で試す価値がある open model」 として、かなり分かりやすい立ち位置だからです。

今回の比較は単なる雑談モデル比較ではなく、
開発用途での使い勝手が主題です。
その意味では、候補群の中で一番「試す理由」が明確なのが Devstral Small 2 でした。

さらに、画像入力も扱えるので、
将来的に スクリーンショットからのUI説明やエラーダイアログ解釈 まで見られる可能性があります。

要するに、
コード主力候補として外せない という判断です。

3. Gemma 4 E4B

Gemma 4 の small 系は 128K context を持ち、Ollama 上でも gemma4:e4b は Text / Image 対応の軽量モデルとして扱えます。Google/Ollama のモデル情報では E2B / E4B の audio 対応も示されていますが、本記事ではまず 画像入力を含む軽量マルチモーダル枠として評価します。
Gemma 4 を調べ始めた当初は、正直 26B-A4B が本命に見えていました。
ただ、調査を進めると、最初に触るべきはむしろ E4B だと判断しました。(2026/04/29修正)

理由は単純で、役割が明確だからです。

  • 軽量
  • マルチモーダル
  • 将来的な微調整導線も見やすい
  • 今回の 16GB VRAM クラスでも無理が少ない

24B級や26B級は、強くても「重い比較」になります。
一方で E4B は、軽量マルチモーダル枠として比較に入れたときの意味がはっきりしています。

同じ「強そうなモデル」でも、
初手の比較記事では 役割がかぶらないこと の方が大事です。
その意味で、Gemma 4 E4B はかなり扱いやすい候補でした。

4. LLM-jp-4-8b-thinking

NII公表の llm-jp-judge では LLM-jp-4-8b-thinking の 日本語 MT-Bench が 7.54 とされており、日本語比較の本命として外しにくい一方、公式 model card でも 研究開発の初期段階で、安全性整合のための調整は未十分とされているため、導入成熟度は控えめに見ています。
日本語比較枠として残しました。

このモデルは、今回の候補の中でも一番おもしろい存在です。
理由は、日本語での立ち位置が明確だからです。

  • 国産
  • 日本語評価が目立つ
  • 8B クラス
  • しかも「thinking」版がある

一方で、導入成熟度は高くありません。
ここはかなり重要です。

つまり、
「すぐに常用したいモデル」ではないが、「比較対象から外すと記事として片手落ちになるモデル」
という位置づけです。

開発主力候補ではなく、
日本語の比較軸を成立させるための本命として残しました。

今回見送ったモデル

Gemma 4 26B-A4B

最初に気になったモデルですが、初手の比較対象としては後回しにしました。

強そうなのは間違いないのですが、
今回のハードウェアだと 「快適に使えるか」より「ギリギリ入るか」寄り の話になりやすいです。

比較記事の第一弾でやりたいのは、
境界ギリギリのモデルの根性試しではありません。
なので、Gemma 4 系はまず E4B を先に見ることにしました。

LLM-jp-4-32b-a3b-thinking

性能的にはかなり気になります。
ただし、今回は後回しにしました。

理由は2つです。

  • 初手に入れるには重い
  • Qwen3 MoE アーキテクチャを採用しており、法域・データ経路とは別に、今回の除外方針に照らして境界ケースとして扱う必要がある

このモデルは「悪いから外した」のではなく、
初回比較のメンバーとしては扱いづらいので外しています。

LLM-jp-4-VL 9B beta (2026/04/29追記)

公開後に追加で確認した候補です。
LLM-jp-4 8B 系をベースにした国産の視覚言語モデルで、日本語マルチモーダル比較ではかなり面白い位置づけです。

日本語タスク平均では Qwen3-VL-8B とほぼ同程度の性能と説明されており、軽量マルチモーダル枠として無視しにくい存在です。

ただし、現時点では beta であり、Hugging Face では custom code を伴うモデルとして公開されています。
また、本記事の第一陣はまず Ollama で横並び比較しやすいモデルに寄せたいので、今回は後続のマルチモーダル比較候補として扱います。

つまり、悪いから外すのではなく、第一陣ではなく第二陣に回す候補です。

Mistral Small 3.2 24B

かなり強いです。
実際、最終候補に残してもおかしくありませんでした。

それでも今回は外したのは、
Devstral Small 2 と役割が近いからです。

24B級を2本同時に最初から回すと、
記事としては「結局どっちがどう違うのか」がぼやけやすいです。
初回比較は、まず役割が異なる4本に寄せた方が読みやすいと判断しました。

Granite 3.3 8B

良いモデルだと思います。
特に軽量補助やコード補助としてはかなり現実的です。

ただ、今回の第一弾比較では
Granite を見る前に、まず gpt-oss と Devstral を見たい
という順番にしました。

Granite は、
「主力が固まった後で、軽量な補助モデルとしてどこまで使えるか」を見る回で扱う方が収まりが良さそうです。

CyberAgent Mistral-Nemo-Japanese 12B

これも悪くありません。
日本語実務文の比較対象としては依然有力です。

ただ、今回は
日本語比較の顔として LLM-jp-4-8b-thinking を優先しました。
同じ記事の中で日本語寄りモデルを複数入れると、焦点が散るからです。

Qwen / DeepSeek / GLM 系

今回は方針上、比較対象から外しました。
性能の話ではなく、この記事の前提条件と合わないためです。

Llama 4 系

今回は外しました。
大きすぎる、もしくは初手の比較対象として優先度が低い、という判断です。

70B級以上

これは単純に、今回の構成では初手の比較対象として現実的ではありません。

この時点の結論

調査段階の結論はかなりシンプルです。

比較対象の第一陣

  • gpt-oss-20b
  • Devstral Small 2
  • Gemma 4 E4B
  • LLM-jp-4-8b-thinking

役割ごとの見立て

  • コード主力候補: gpt-oss-20b / Devstral Small 2
  • 軽量マルチモーダル枠: Gemma 4 E4B
  • 日本語比較の本命: LLM-jp-4-8b-thinking

後回しにしたもの

  • 境界ギリギリの重量級
  • 役割が重複する24B級
  • 方針上除外する系列
  • beta 段階、または Ollama での横並び比較がまだ重い候補

要するに、
初回比較では「強そうなものを全部並べる」のではなく、「役割が違う4本を選ぶ」のが正解
という判断です。

次回予告

次はこの4モデルのうち、まずは導入成熟度が高いところから順に動かします。

当面の順番はこう考えています。

  1. gpt-oss-20b
  2. Devstral Small 2
  3. Gemma 4 E4B
  4. LLM-jp-4-8b-thinking

なお、公開後に確認した LLM-jp-4-VL 9B beta は、日本語マルチモーダル比較の追加候補として後続で扱います。

次回は、実際に Windows 11 + eGPU + Ollama でどこまで動くか、
そして どのモデルがこの構成で現実的か を検証します。

参考

17
9
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
17
9

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?