ローカルLLM実行ツール比較2026:Ollama vs LM Studio vs llama.cpp vs vLLM vs Jan 完全ガイド

2026年8月現在、自分のノートPCや自社サーバーで大規模言語モデルを直接動かすことは、もはや趣味の開発者による実験ではありません。社内文書を外部APIに送れない企業、月に数万円のAPI料金を削りたい個人開発者、飛行機の中でもコーディングアシスタントを使いたいエンジニア。誰もが同じ問いの前に立っています。「で、結局どれで動かせばいいの?」 本記事は、その問いに答えるためのローカルLLM実行ツール比較ガイドです。2026年8月2日時点で各プロジェクトの公式リリースページと価格ページを直接確認したデータだけをもとに書いています。

このカテゴリで実質的に選択肢に挙がるツールは5つです。Ollama、LM Studio、llama.cpp、vLLM、そしてJan。GitHubのスター数を見るだけでも、この5つが市場を分け合っていることがわかります。2026年8月2日にGitHub APIで直接取得した結果は、Ollama 177,543、llama.cpp 122,385、vLLM 87,913、Jan 43,808でした。(LM Studioはアプリ本体がクローズドソースのため、スター数で比較してはいけません。公開されているのは lms CLIとSDKのみで、5,138です。)

2026年上半期にこの市場で起きた最も大きな変化は3つあります。第一に、「ローカル専用=完全無料」という等式が崩れました。 OllamaはPro/Max/Teamの有料サブスクを、LM Studioはトークン従量課金のクラウドクレジットをそれぞれ運営しています。第二に、Apple SiliconでMLXバックエンドが事実上の標準になりました。 Ollama(0.19〜)、LM Studio、Jan(0.7.7〜)がすべて採用しています。第三に、エージェント化です。Ollama 0.32.0は ollama と入力するだけでエージェントが起動し、LM Studioは「Bionic」という別建てのエージェント製品を投入しました。

本ガイドでは、5つのツールの最新バージョンとライセンス、実測ベンチマーク、料金プラン、ハードウェア別の制約、そしてユーザータイプ別の最終推奨まで、1万字を超えるボリュームで整理します。特に、ネット上の解説記事の多くがいまだに間違って書いている6つの事実を第6章で正します。結論から言うと、この選択の8割は「1人で使うのか、複数人が同時につながるのか」という1点だけで決まります。

1. Executive Summary:2026年8月・主要5ローカルLLMツールを一覧で

時間のない方のために、5つのツールの中核スペックを1つの表に圧縮しました。以下の表のバージョン・価格・ライセンスはすべて、2026年8月2日に公式ソースで直接確認した値です。

📊 2026年8月最新・主要5ローカルLLM実行ツール総合比較表

この表でまず目に入れるべき行は、同時サービング能力、Apple Silicon / MLX、そして対応モデルフォーマットの3行です。実務でツール選定を誤る事故のほとんどは、この3行を見ずに始めたことが原因です。MacBookにvLLMを入れようとして丸一日を溶かす、同時リクエストが数十本に増えたチャットボットをOllamaの既定設定のまま立てて「なぜこんなに遅いのか」と首をかしげる。典型はこの2つです。

とりわけ対応モデルフォーマットの行は、このカテゴリで最も重くのしかかるロックイン要因でありながら、ほとんどの比較記事から抜け落ちています。Ollama・LM Studio・llama.cpp・JanはいずれもGGUF(+MLX)のエコシステムを共有しますが、vLLMだけはHF safetensors系(FP8・AWQ・GPTQ)が主力で、GGUF対応は本体から外れてアウトオブツリープラグイン vllm-gguf-plugin へ移管された実験的機能です。vLLM公式ドキュメントの文言そのままに「highly experimental and under-optimized」であり、トークナイザーもGGUFではなくベースモデル側を使うよう推奨されています。つまり前者4つの間ではモデルファイルをそのまま持って引っ越せますが、vLLMへ移るときはモデルライブラリを丸ごと調達し直す必要があります。

2. 主要5ローカルLLM実行ツール比較:中核機能のディープダイブ

各ツールが「何を得意にするために作られたのか」を理解すると、選択は一気に楽になります。5つのツールは競合というより、それぞれ異なるレイヤーに立っています。実際、LM StudioとJanは内部でllama.cppをエンジンとして使っており、Ollamaもllama.cpp系の技術の上からスタートしました。

🦙 1) Ollama - CLI一行で完結するローカルモデルランチャー1位

• 圧倒的なデプロイの手軽さ:ollama pull と ollama run の2コマンドで、モデルのダウンロードから対話までが終わります。独自のモデルレジストリを運営しており、Docker Hubのようにモデルを名前で引っ張ってこられ、GGUFフォーマットに対応しています。GitHubスター177,543で5種中1位。このエコシステムの規模自体がOllama最大の資産です。たいていのサードパーティツールは、Ollama連携を標準でサポートしています。
• 対話型エージェントの導入(v0.32.0、2026年7月11日):ollama コマンドを実行するだけで、チャット・コーディング・Web検索・タスク委譲ができるエージェントが立ち上がります。ただし既定モデルが glm-5.2:cloud、つまりクラウドモデルである点は必ず押さえてください。「ローカル専用ツール」というイメージと実際の既定動作がズレ始めた地点です。
• MLXバックエンドによるApple Silicon対応(v0.19、2026年3月30日):Apple Siliconでの性能が大幅に改善しました。ただし公式ブログがMLXプレビューリリースの条件として明記したのが統合メモリ32GB超(「Please make sure you have a Mac with more than 32GB of unified memory」)です。誤読されやすい箇所なので正確に書くと、8GB・16GBのMacBookでOllamaが動かないのではなく、MLXアクセラレーションが効かないだけです。それ以下のMacでも従来のMetal(llama.cpp)経路で正常に動作します。これを「Ollamaは32GB以上のMac専用」と書き換えている記事は疑ってかかるべきです。
• 同時リクエスト処理の設定:公式FAQによれば OLLAMA_NUM_PARALLEL は「各モデルが同時に処理する並列リクエストの最大数、既定値1」、OLLAMA_MAX_LOADED_MODELS は「同時にロードできるモデル数、既定値はGPU数×3」です。つまりOllamaにもllama.cppの並列スロットデコードがそのまま露出しており、既定値が1なので何も設定しなければリクエストは事実上直列処理されるというのが実情です。社内チャットボットが遅いなら、最初の一手はツールの入れ替えではなくこの環境変数です。
• 旧モデルのサポート終了警告が開始(2026年7月11日):CodeLlama、Qwen2.5およびQwen2.5-coder、Llama 3.x、Mistral、StarCoder、DeepSeek-R1の既定タグを実行すると、deprecation警告が表示されます。2024〜2025年に書かれたチュートリアルをそのままなぞると警告を見ることになるという意味なので、これから始める方は最新のモデルタグを自分で確認することをおすすめします。
• 地道なエンジン改善:投機的デコーディング(speculative decoding)のドラフトモデルに対応し、Qwen3 MoEのデコードが最適化されました。プロンプトキャッシュをコンテキストシフトから分離することで、応答の一貫性の問題も解消しています。v0.32.3ではWindows ARM64向けのCUDA対応が追加され、v0.32.5ではNVFP4モデル(特にLaguna)の出力品質を落としていたMLX Metalのバグが修正されました。

💠 2) LM Studio - ターミナル不要のGUIオールインワンデスクトップ1位

• 二重ランタイムを内蔵:llama.cppとMLXの両ランタイムを内蔵しており、ダウンロードしたモデルのフォーマット(GGUF / MLX)に合ったエンジンでロードされます。ハードウェアを見て勝手に切り替える構造ではない、という点が重要です。Macなら、MLXフォーマットのモデルを落としてはじめてMLXエンジンを使うことになり、同じMacでGGUFを落とせばそのままllama.cpp経路で動きます。どのフォーマットを選ぶかがそのまま性能差になるので、ダウンロードの段階で一度は意識してください。
• 量子化レベルを視覚的に選択:GUIのモデルブラウザーで、Q4_K_MやQ8といった量子化レベルを目で見て選べます。自分のRAM・VRAMに合うのはどれなのか見当がつかない初心者にとって、このUIひとつが決定打になります。他のツールではファイル名を解読しながら選ぶ作業です。
• 連続バッチングによる並列リクエスト(0.4.0、2026年1月28日):サーバーデプロイモード、並列リクエスト処理、新規RESTエンドポイント、UI刷新が一気に入ったメジャーアップデートでした。デスクトップGUIツールの中では同時処理が最も進んでいる部類なので、小規模チームのサーバーとして使う余地が生まれました。
• llmsterヘッドレスデーモン:GUIなしでサーバーとしてのみ動かせるデーモンコンポーネントで、Mac・Linux・Windows向けのインストールコマンドが提供されています。「GUIで設定してサーバーとしてデプロイ」という流れが可能です。
• エージェント製品Bionic(2026年7月16日発表):オープンモデル専用のAIエージェントで、macOS・Windows向けの初期プレビューが公開され、7月27日にはBionicでのKimi K3の実行がサポートされました。ただしBionic Passの価格は、公式ページが「coming soon」と記すのみで未公開です。
• 業務利用の無料化(2025年7月8日):それ以前は会社で使うなら別途の商用ライセンスが必要でしたが、現在はフォーム記入も問い合わせも不要で職場で無料利用できます。この事実は日本語の情報ではあまり知られていません。

⚙️ 3) llama.cpp - すべての土台となる純粋な推論エンジン1位

• GGUFフォーマットの本家:16ビットの重みを8・6・5・4・3・2ビットへ量子化するエコシステムは、ここから始まりました。一部の報告によれば1ビット級の量子化まで登場しており、超低スペック機に対応できる幅は広がり続けています。LM Studio、Jan、Ollamaはいずれもこの系譜の上に立っています。
• バージョン番号を持たないプロジェクト:セマンティックバージョンではなくビルドタグ(bXXXXX)方式を採用しています。2026年8月2日08:15 UTC時点の最新ビルドはb10226ですが、ビルドは1日に何度も更新されます(8月1〜2日だけでb10218、b10219、b10221、b10223、b10224が出ています)。「llama.cpp 1.x系」といった表記は、そもそも存在しません。
• llama-server の機能密度:既定ポート8080でOpenAI互換APIを提供し、/v1/chat/completions、/v1/completions、/v1/embeddings、/v1/models の各エンドポイントに対応します。base URLを差し替えるだけで、既存のOpenAI SDKのコードがそのまま動きます。2026年のサーバーには、並列デコード(-np)、OpenAI + Anthropicの二重互換チャットルート、関数呼び出し、投機的デコーディング、実験的なマルチモーダル入力、埋め込み・リランキングのエンドポイント、複数モデルのLRU退避を処理するルーターモード、Web UI内蔵のMCPフックまで入っています。
• 圧倒的なバックエンドの広さ:CUDA、Metal、Vulkan、ROCm、SYCL、WebGPUに対応し、macOS・Linux・Android・Windowsのすべてで動きます。5つのツールの中でハードウェアカバレッジはllama.cppが独走の1位です。2026年4月にはQualcomm Hexagon NPUのLinux対応が入り、Snapdragonノートやエッジ機器まで射程に入ったという報告があります。
• --tools all フラグ:このフラグを立てると、Web UIからLLMがローカルファイルシステムに直接アクセスします。強力である分だけ危険なので、信頼できないプロンプトを扱う環境では絶対に有効化しないことをおすすめします。

🚀 4) vLLM - マルチユーザー本番サービングのスループット1位

• PagedAttention:KVキャッシュを連続したメモリの塊としてではなく、OSのページングのように固定サイズのブロックへオンデマンドで割り当てます。原論文系の資料によればメモリの無駄が最大4分の1に減り、その分だけはるかに大きなバッチをGPUに載せられます。vLLMの性能はどこから来るのかと問われたら、答えはここです。
• 連続バッチング(continuous batching):バッチ内のシーケンスが1本終わると、その空きに即座に新しいリクエストを差し込みます。従来の静的バッチングが「最も長いリクエストが終わるまでGPUが遊ぶ」という問題を抱えていたのとは対照的です。ここにチャンクドプリフィル(chunked prefill)とFlash Attentionが組み合わさります。
• 殺人的なリリース速度:2〜4週間サイクルでリリースが出ます。2026年5月29日のv0.22.0以降、6月5日に0.22.1、6月13日に0.23.0、6月30日に0.24.0、7月11日に0.25.0、7月14日に0.25.1、7月25日にv0.26.0と、2か月あまりでマイナーリリースが5回以上出ています。注意すべきは、2026年8月現在も依然として0.x系だという事実です。「vLLM 1.0」はまだ存在しません。
• ハードウェア対応の明確な境界線:GPUはNVIDIA CUDA、AMD ROCm、Intel XPUに対応し、CPUはx86、ARM AArch64、Apple Silicon、IBM Z(S390X)までカバーします。しかしApple SiliconのGPUアクセラレーションは vLLM-Metal という別プロジェクト経由でのみ可能であり、本体への統合ではありません。より重要なのは、Windowsが公式サポート一覧にないという点です。コミュニティフォークがあるという話はありますが、公式ではありません。
• エンタープライズ採用の証左:NVIDIAが独自に最適化したvLLMのリリースノートを別途配布しています(RN-11517-001_v26.06、2026年7月)。コンテナ親和的な構造なので、Kubernetesクラスターへのデプロイによく合います。この部分が気になる方は、Docker vs Kubernetes vs Podman コンテナツール比較の記事を併読すると、デプロイの全体像がクリアになります。

🟣 5) Jan - オープンソースGUI+MCPエージェント1位

• 完全なオープンソースデスクトップ:Windows・macOS・Linux向けアプリで、ライセンスはApache 2.0です。複数のレビューサイトがJanをAGPLv3やMITと誤記していますが、リポジトリのREADMEで直接確認した結果、Apache 2.0が正しい表記です。開発元はMenlo Research、スターは43,808です。LM Studioとの最大の違いがまさにこの点、すなわちアプリ本体がオープンソースかどうかにあります。
• 独特なポート1337:OpenAI互換APIを localhost:1337 で立ち上げます。Ollamaの11434、llama.cppの8080と混同しやすいので、連携設定のときに正確に覚えておいてください。
• MCP(Model Context Protocol)対応:インラインのMCPツール承認UIを備えており、エージェントがどのツールをいつ使うのかを、ユーザーがその都度承認できます。オープンソース陣営でエージェント機能をGUIに最もきれいに載せた部類に入ります。
• 6か月間の急速な進化:v0.8.0(5月22日)でマルチトークン予測(MTP)とllama.cppルータープロセスの統合、v0.8.1(5月29日)でAnthropic互換のカスタムプロバイダーとOSネイティブのTLS信頼、v0.8.2(6月1日)でAMD ROCm/HIPのLinuxバックエンドとダウンロードの一時停止・再開、v0.8.3(6月24日)でメッセージのバージョン分岐探索とHTML/SVGアーティファクトのプレビュー・動画入力、v0.8.4(7月)でネイティブの web_search・web_fetch ツールと資格情報のバックエンドストア移行が、順次投入されました。
• モデル調達の自由度:HuggingFaceからGGUFモデルを直接ダウンロードします(Llama、Gemma、Qwen、GPT-ossなど)。必要ならOpenAI・Anthropic・Mistral・Groq・MiniMaxといったクラウドAPIも接続できますが、その場合の料金は各提供元へ直接請求され、Janが中間で受け取る金銭はありません。

3. スループット・レイテンシー・Apple Silicon性能のベンチマーク対決

数字に入ります。ここで重要なのは「誰が速いか」ではなく「どの条件で速いか」です。条件を外して順位をつけた瞬間、そのベンチマークは嘘になります。

そこで以下の星取表は実測値ではありません。 各ツールがどんな構造を備えているか(PagedAttention・連続バッチング・並列スロットの有無)を基準にした定性評価であり、後に出てくる実測表とは性質が異なります。星の数をtok/sの倍率に換算して読まないでください。

[同時リクエスト集中時の総スループット — 構造ベースの定性評価]
vLLM              : ⭐⭐⭐⭐⭐ (PagedAttentionと連続バッチングの両方を保有)
llama.cpp         : ⭐⭐⭐⭐☆ (-np の並列スロット + ルーターモード、PagedAttentionはなし)
LM Studio         : ⭐⭐⭐☆☆ (0.4.0から連続バッチング、GUIツール中では1位)
Ollama            : ⭐⭐⭐☆☆ (OLLAMA_NUM_PARALLELで並列スロット可、ただし既定値は1)
Jan               : ⭐⭐☆☆☆ (1人1リクエストのデスクトップ用途に最適化)

※ Ollamaとllama.cppの星の差は「機能の有無」ではなく、既定値(Ollamaは1スロット)
   およびPagedAttentionの有無から来ています。Ollamaも環境変数1行で並列スロットを
   有効化できますが、ページドKVキャッシュがないためスロットを増やすほど
   キャッシュの無駄が膨らみ、曲線は比較的早く頭打ちになります。

[1人で使うとき(バッチサイズ1)の体感レスポンス速度 — 構造ベースの定性評価]
Ollama            : ⭐⭐⭐⭐⭐ (スケジューラのキューイング負荷がなく初回応答が速い)
llama.cpp         : ⭐⭐⭐⭐⭐ (自分でチューニングすれば上限が最も高い)
LM Studio         : ⭐⭐⭐⭐☆ (MLXフォーマットのモデル使用時、Macで特に有利)
Jan               : ⭐⭐⭐⭐☆ (ネイティブMLX対応以降、差が縮小)
vLLM              : ⭐⭐⭐☆☆ (単一リクエストでは優位なし、TTFTはむしろ不利)

📈 3-1. Apple Silicon:Ollama MLXバックエンドの実測(公式一次データ)

最も信頼度が高い数字は、Ollama公式ブログが公開したMLXベンチマークです。Apple M5系(M5 / M5 Pro / M5 Max、GPU Neural Accelerators搭載)、Qwen3.5-35B-A3Bモデルという条件です。

デコード基準で約1.9〜2.3倍の向上です。ただしこの表を「Ollamaを上げるだけで2倍」と読んではいけません。列見出しをもう一度見てください。0.18の列はQ4_K_M、0.19の2列はNVFP4とint4です。 つまりこの数値はバージョンアップと同時にNVFP4・int4の量子化モデルへ乗り換えたときの結果であり、既存のQ4_K_M GGUFをそのまま使いながらOllamaのバージョンだけ上げても、ここまでは出ません。公式ブログも「Qwen3.5-35B-A3BをNVFP4に量子化したものと、0.18の従来実装でQ4_K_Mに量子化したもの」を比較したと条件を明記しています。Macでこの向上を実際に得るにはOllamaのアップデートと量子化フォーマットの入れ替えをセットで行う必要があり、その幅は約1.9〜2.3倍の範囲と理解するのが正確です。そしてこのMLX経路自体が統合メモリ32GB超のMacでのみ開きます。 16GBのMacBook AirではOllamaが動かないのではなく従来のMetal経路で動作し、この表の向上幅が適用されないだけです。

📈 3-2. vLLM vs Ollama:同時実行性が生む格差

複数のベンチマーク資料によれば、NVIDIA A100で同時リクエスト128本を投げたとき、vLLMは約793 tok/s、Ollamaは約41 tok/sを記録し、P99レイテンシーはvLLM 80msに対しOllama 673msだったとされます。同時リクエスト8本ではvLLM 187 tok/s対Ollama 82 tok/s(約2.3倍)、同時ユーザー64人基準では総スループットに約8〜9倍の差が出たと報告されています。

これらの数字を、先ほどのOllama MLX表と同格に扱ってはいけません。 元のベンチマーク文書を確認できていない二次ソースであるうえ、モデル・量子化・コンテキスト長・Ollama側の並列スロット(OLLAMA_NUM_PARALLEL)設定がひとつも明記されていません。 この章の冒頭が「条件を外して順位をつければベンチマークは嘘になる」だった以上、同じ物差しをこの数値にも当てるのが筋です。とりわけOllama側が既定の1スロットのまま測定されていたなら、8〜9倍という格差のかなりの部分は構造差ではなく設定差かもしれません。正確な倍率は引用せず、方向性だけを受け取ってください。自分の環境の実数値が必要なら、vllm bench serve とOllama側の同条件測定を自分で回して比べるほうが、本記事のどの引用値より正確です。

方向性そのものは複数のソースで一致しており、技術的にも妥当です。まとめると3文になります。

1. バッチサイズ1、つまり1人で使うときは、OllamaとvLLMのtok/sは事実上同じです。 差は一桁台から20%程度で、むしろOllamaはスケジューラのキューイング負荷がないぶん、初回応答までの遅延(TTFT)はより速いケースが多いです。
2. 同時実行数が上がると、vLLMはスループットが滑らかに右肩上がりになる一方、Ollamaは相対的に早く頭打ちになります。 ただし「Ollamaには並列処理そのものがない」というのは誤りです。OLLAMA_NUM_PARALLEL を上げれば並列スロットが有効になり、既定値1から離れるだけでも曲線はかなり変わります。それでも残る差はPagedAttention(ページドKVキャッシュ)と連続バッチングの有無から来るもので、こちらは環境変数では埋められない構造差です。
3. したがって結論は、**「1人で使うならvLLMを使う理由はなく、同時リクエストが数十本規模まで上がればvLLM以外の答えがない」**ということです。その中間の区間は、Ollamaの並列スロット調整やllama.cppの -np、LM Studio 0.4.0以上の連続バッチングで十分しのげます。具体的な基準線は第6章のコツ⑧にまとめてあります。

📈 3-3. MLX vs llama.cpp、そしてMac世代間の格差

Macユーザーにとって、バックエンドの選択はそのまま性能です。二次ソースのベンチマークによればMLXはllama.cpp比で**20〜87%**優位で、短いコンテキストでの持続スループットはMLX約230 tok/s対llama.cpp約150 tok/sと報告されています。

もう一つ、よく引用される事例があります。Mac mini M4 Pro(64GB)でQwen3-Coder-30B-A3Bを動かしたとき、MLX約130 tok/s対Ollama(llama.cppバックエンド)43 tok/sで約3倍の差がついたという報告です。この3倍は、上の20〜87%のバンドと同じものを測っていません。 前者は純粋なMLX対llama.cppの比較であり、3倍の事例はMLX対「Ollamaというランタイムを経由したllama.cpp」なので、バックエンドの差にOllamaのランタイムオーバーヘッドが合算された単一事例です。2つの数字をつなげて「MLXは3倍」と一般化すると誇張になります。

ハードウェア世代の差も無視できません。llmcheck.netの集計によれば、M5 MaxはM4 Max比で約**+28%**のtok/sを出します。Llama 3 8B Q4でM5 Max 82 tok/s対M4 Max 64 tok/s、Qwen 3.5 30B-A3B Q4でM5 Max 58 tok/s対M4 Max 45 tok/sです。中型(14〜35B)モデルはM4 Pro 24GBで35〜55 tok/s程度、M5 Max 128GBのメモリ帯域幅は約600GB/sです。ローカルLLMで性能を決めるのはGPUコア数よりもメモリ帯域幅と容量だという事実が、これらの数字にそのまま表れています。

ここから実務的に導かれる結論はこうです。Macを使うなら、MLXに対応したツール(Ollama 0.19以上、LM Studio、Jan 0.7.7以上)を選び、MLXフォーマットのモデルを落としてください。 同じハードウェアでもバックエンドを変えるだけで**20〜87%(報告事例の多くは30〜50%台)**変わります。上の3倍の事例のようにさらに開くケースもありますが、あれはランタイムオーバーヘッドまで合算された特殊事例なので、期待値はバンド側に合わせておくのが安全です。逆にNVIDIA GPUサーバーならMLXは無意味なので、同時実行性の要件に応じてOllamaとvLLMから選べば十分です。

4. 料金プラン・価格の完全比較:無料の範囲はどこまでか

2026年のこのカテゴリで、最も誤解の多い領域です。結論から言うと、5つのツールはいずれもローカル実行そのものは無料で、有料になるのはあくまでクラウド推論のアドオンです。

[2026年8月 ローカルLLMツールの料金構造まとめ]
- llama.cpp        : $0        (有料ティア・クラウド・サブスクは一切なし。純粋なOSS)
- vLLM             : $0        (ソフトは無料、コストは全面的に自前のGPUインフラ)
- Jan              : $0        (デスクトップ無料・サブスクなし、外部APIは各提供元が課金)
- LM Studio        : $0        (ローカル・業務利用は無料 / クラウドはトークン従量課金)
- Ollama           : $0        (ローカルは無制限で無料 / クラウドProは月$20〜)

💰 4-1. Ollama公式料金表

Maxプランが新規登録を止めている状態なのが目を引きます。需要をさばききれていないシグナルと読めますし、これから新しく始めるユーザーにとって実質的な選択肢はFree・Pro・Teamの3つです。なお、円建ての公式価格表は存在しません。 韓国のブログなどに書かれている「月2万ウォン台」(約2,000〜3,000円)といった表記はすべて換算の推定値なので、決済前の実際の請求額はカード会社の為替レートで確認してください。

💰 4-2. LM Studioの料金構造

クラウド従量課金の単価(100万トークンあたり、USD)

キャッシュ単価が入力の10分の1程度まで落ちる構造なので、同じシステムプロンプトを繰り返し使うワークロードなら実質コストが大きく変わります。クラウドモデルの単価比較が本格的に気になる方は、ChatGPT vs Claude vs Gemini vs DeepSeek AIモデル比較の記事で、フロンティアモデル側の価格構造も併せて確認することをおすすめします。

💰 4-3. 本当のコストは料金表に載っていない

ここが肝心です。ローカルLLMの実質コストは、ソフトウェアの値段ではなくハードウェアと電気代、そして人の時間です。

第一に、ハードウェアコストです。ここでよく2つの話が混ざるので、切り分けましょう。OllamaのMLXアクセラレーションを使うには統合メモリ32GB超が条件ですが、それはあくまでOllamaのMLXバックエンドのゲート条件であって、30B級モデルのハードウェア要件ではありません。30B級モデル自体はM4 Pro 24GBでも35〜55 tok/sで動きます(3-3参照)。 32GB未満の機材がこの性能議論から脱落するのではなく、OllamaのMLX経路だけが使えず従来のMetal経路に回るという意味です。とはいえローカルLLMの性能を決めるのがメモリ帯域幅と容量である以上、大きなモデルを余裕をもって回すには統合メモリの潤沢なMacか十分なVRAMのNVIDIA GPUにお金がかかる、という事実は変わりません。月$20のサブスクを節約するために数十万円の機材を買うのが合理的かどうかは、使用頻度次第です。

ここに、なかなか捕捉されないコストがもう一つあります。モデルフォーマットの移行コストです。Ollama・LM Studio・llama.cpp・Janの間ではGGUFファイルをそのまま再利用できますが、vLLMへ移った瞬間にGGUFライブラリは付いてきません。 vLLMのGGUF対応は本体から外れてアウトオブツリープラグインへ移管された実験的機能なので、実務ではHF safetensors(FP8・AWQ・GPTQ)系を落とし直すのが定石です。モデル1本が数GBから数十GBある以上、ダウンロード時間・ストレージ・検証時間がすべて新たに発生します。トークナイザーもベースモデル側を別途指定する必要があります。「料金表に載っていないコスト」を語るなら、この項目を落としてはいけません。

第二に、vLLMのコスト構造は特に誤解されやすい点です。ソフトウェアは完全無料のApache-2.0ですが、vLLMがその存在意義を発揮するにはデータセンター級のGPUが前提になります。つまりvLLMの実コストは、GPUインスタンスの時間課金の全額です。逆に言えば、そのGPUをすでに保有していて複数ユーザーがつながる状況なら、vLLMは同じハードウェアでスループットを数倍に引き上げ、GPU1台あたりの単価を下げるツールになります。

第三に、運用時間のコストです。llama.cppはソフトウェアの値段こそ0円ですが、ビルドオプションとフラグを自分で扱う必要があり、ビルドタグが1日に何度も変わるプロジェクトなので「どのビルドでうまく動いたか」を自分で管理しなければなりません。対してLM Studioはインストール直後からすぐ使えます。エンジニアの時給を計算に入れると、無料のツールが常に最も安いツールとは限りません。

5. ユーザータイプ別の最終推奨ガイド

ここまでのデータをもとに、実際の状況ごとの最適解を整理します。この章だけ読んでも結論は出ます。

🎯 1) ローカルLLMを初めて触る非開発者・企画職・研究者

• 最適解:LM Studio
• 理由:ターミナルを一度も開く必要がなく、GUIのモデルブラウザーで量子化レベルを目で見て選べます。何より2025年7月8日から業務利用も完全無料なので、会社のPCに入れてもライセンス上の問題がありません。llama.cppとMLXの両ランタイムを内蔵しており、落としたモデルのフォーマットに合ったエンジンでロードされます。ただしMacならMLXフォーマットのモデルを自分で選んで落とさないとMLXエンジンにならない点だけ覚えておいてください。

🎯 2) CLIが手に馴染んでいて、複数モデルを素早く差し替える個人開発者

• 最適解:Ollama
• 理由:ollama run の一行で終わりますし、GitHubスター177,543が物語るとおり、サードパーティ連携のエコシステムが圧倒的です。バッチサイズ1の環境ではvLLM比でスループットが事実上同等でありながら、初回応答の遅延はむしろ速いケースが多いです。 ただし2024〜2025年のチュートリアルにあるモデルタグ(Llama 3.x、Qwen2.5、Mistralなど)はdeprecation警告の対象なので、最新タグを使ってください。

🎯 3) 同時リクエストが10本を超える社内チャットボット・RAG APIを運用するチーム

• 最適解:vLLM
• 理由:この区間から先は代替が乏しくなります。PagedAttentionでKVキャッシュの無駄を削り、連続バッチングでGPUのアイドル時間をなくす構造なので、同時リクエストが増えるほどスループットが右肩上がりになります。Ollamaも OLLAMA_NUM_PARALLEL で並列スロットを有効化できますが、ページドKVキャッシュがないためスロットを増やすほどキャッシュの無駄が膨らみ、曲線が先に頭打ちになります。ただしWindowsは公式非対応、Apple SiliconのGPUは別プロジェクト vLLM-Metal 経由という制約、そして既存のGGUFモデルライブラリをそのまま持ち込めないという移行コストを、必ず先に確認してください。社内の人数が10人でも同時にリクエストを投げる人数はずっと少ないことが多いので、基準は「登録ユーザー数」ではなくピーク時の同時リクエスト数で取るべきです。

🎯 4) 低スペック機・エッジデバイス・組み込みに極限まで押し込むエンジニア

• 最適解:llama.cpp
• 理由:バックエンドの広さが5種中で圧倒的です。CUDA・Metal・Vulkan・ROCm・SYCL・WebGPUに対応し、macOS・Linux・Android・Windowsのすべてで動きます。8/6/5/4/3/2ビットの量子化を自由に選べ、llama-server のルーターモードで複数モデルをLRU退避させながら回すこともできます。他のツールが動かないハードウェアで唯一動く選択肢になるケースが少なくありません。

🎯 5) オープンソースの原則を守る必要がある、またはMCPエージェントを試したいユーザー

• 最適解:Jan
• 理由:アプリ本体がApache 2.0のオープンソースである唯一のGUIツールです。LM Studioはアプリがクローズドソースなので、監査(audit)が必要な組織では通しにくくなります。JanはMCPのインラインツール承認UIを備え、v0.8.4ではネイティブの web_search・web_fetch ツールまで加わりました。AMD ROCmのLinuxバックエンド(v0.8.2)にも対応しています。

🎯 6) オフライン環境でコーディングアシスタントをつなぎたい開発者

• 最適解:OllamaまたはLM Studio
• 理由:どちらも外部コーディングツールとの連携経路が確保されています。LM Studioは2026年1月30日からモデルをClaude Codeで使えるようになり、Ollamaはv0.32.3でClaude Code Channels連携を復旧、ollama launch chatgpt でCodex App(名称変更後はChatGPT)との連携も提供しています。クラウドベースのコーディングエージェントとの性能差が気になる方は、Cursor vs GitHub Copilot vs Cline AIコーディングエージェント比較の記事も併せてお読みください。

🎯 7) 会社のセキュリティポリシー上、データが端末の外に出てはいけない場合

• 最適解:llama.cppまたはJan(次点:Ollamaのローカル専用設定)
• 理由:5つのツールはいずれも完全オフライン動作が可能ですが、クラウド接続の要素がそもそも一切ないのはllama.cppだけです。Janもデスクトップ自体にはサブスクや課金がなく、ローカルファーストの設計です。Ollamaを使うなら、v0.32.0エージェントの既定モデルが glm-5.2:cloud、つまりクラウドモデルである点を必ず確認し、ローカルモデルを明示的に指定してください。チーム単位で契約するなら、Teamプランがゼロデータリテンション・ログ非保持を明記しています。

6. 実践的な活用のコツ&よくある間違い(ネット記事が間違って書いていること)

この章が本記事で最も実用的な部分です。調査の過程で確認した、現在出回っている情報の多くが誤っている6つの事実と実践的なコツをまとめました。

① 「LM Studioは会社で使うなら商用ライセンスが必要」→ 誤りです。 2025年7月8日をもって、商用利用ライセンスの要件は撤廃されました。現在はフォーム記入も個別の問い合わせも不要で、職場で無料利用できます。 ところが今も多くの記事が旧ポリシーをそのまま書いており、これが理由でLM Studioを候補から外したチームが実際に存在します。社内導入を検討中なら、まずこの項目を訂正してください。

② 「JanはAGPLv3」→ 誤りです。Apache 2.0です。 複数のレビューサイトがAGPLv3またはMITと記載していますが、リポジトリのREADMEで直接確認したライセンスはApache 2.0です。AGPLはネットワークサービスとして配布する際にソース公開義務が付いてくるため、企業の法務レビューでしばしば引っかかるライセンスですが、Janはこれに該当しません。ライセンスを理由にJanを見送ったのなら、再検討する価値があります。

③ 「vLLM 1.0が出た」→ まだ存在しません。 2026年8月現在の最新はv0.26.0で、依然として0.x系です。2〜4週間サイクルでリリースが降ってくるプロジェクトなので、バージョン固定(pinning)が事実上必須です。requirements.txt に vllm とだけ書いておくと、2週間後にはチームメンバーの環境と自分の環境が食い違います。正確なバージョンを打ち込み、上げるときはリリースノートを読んでから上げてください。

④ 「Ollamaは完全無料のローカル専用ツール」→ 2026年には半分しか正しくありません。 ローカル実行は今も無制限で無料ですが、Pro 月$20などのクラウドサブスクが存在し、**v0.32.0の既定エージェントモデルはクラウドモデル(glm-5.2:cloud)**です。何気なく ollama とだけ入力して社内データを貼り付けると、そのデータが外に出る可能性があるという意味です。セキュリティが重要な環境では、初回セットアップでローカルモデルを明示的に指定する習慣をつけてください。

⑤ 「llama.cppの最新バージョンは1.x」→ そもそもそのバージョン体系が存在しません。 llama.cppはセマンティックバージョンを使わず、**ビルドタグ(bXXXXX)のみを使います。2026年8月2日時点でb10226ですが、明日には別の値です。実務上のコツは、「動作を確認したビルドタグを記録しておき、そのタグをチェックアウトして使うこと」**です。毎回masterを引っ張ってくると、昨日効いていたフラグが今日は効かない、という事態が起きます。

⑥ 「MLXを有効にするだけでMacが2倍速くなる」→ 条件が2つも付きます。 第一に、OllamaのMLXプレビューバックエンドは統合メモリが32GBを超えるMacが前提です。ただしこれを「16GBのMacではOllamaが使えない」と書き換えると誤りです。それ以下のMacでもOllamaは従来のMetal(llama.cpp)経路で正常に動作し、MLXアクセラレーションが効かないだけです。第二に、公式ブログの1.9〜2.3倍という数値はバージョンアップだけの効果ではなく、NVFP4・int4の量子化モデルへ乗り換えた結果です。Q4_K_Mのままバージョンだけ上げても、その幅は出ません。16GB以下のMacなら7〜8B級の小型モデルとQ4量子化を基準に計画を立てつつ、ツールを替えるよりモデルのサイズとフォーマットを先に調整するのが順序です。

⑦ ポート番号を覚えておくと、連携時の試行錯誤が半分に減ります。 Ollamaは11434、llama.cppの llama-server は8080、Janは1337です。3つともOpenAI互換APIを提供するので、既存のOpenAI SDKのコードはbase URLを変えるだけでそのまま動きます。 新しいクライアントを書く必要はありません。llama.cppはこれに加えてAnthropic互換のチャットルートまで提供するので、Anthropic SDKベースのコードも再利用できます。

⑧ 「ピーク時の同時リクエストは何本か」に先に答えてから、ツールを選んでください。(本記事の単一基準線) 最もありがちな設計ミスは、順序を逆にたどることです。社内サービスにOllamaを立て、遅くなったのでGPUを増設する、というチームをときどき見かけます。しかし最初の一手はGPU増設でもvLLM移行でもありません。 Ollama公式FAQによれば OLLAMA_NUM_PARALLEL の既定値は1(各モデルが同時に処理する並列リクエストの最大数)です。つまり何も設定していないOllamaはリクエストを事実上一列に並べて処理しており、この状態の遅さはハードウェアの問題ではなく環境変数の問題です。OLLAMA_MAX_LOADED_MODELS も既定値がGPU数×3なので、併せて見ておきたい値です。

そこで処方は2段階です。(1)まず OLLAMA_NUM_PARALLEL を上げてみて、(2)それでも曲線が立ち上がらなければvLLMへ移る。 順序を逆にすると、不要な移行にモデル再調達のコストまで上乗せすることになります。残る差はPagedAttentionと連続バッチングの不在から来るもので、スロット数では埋められません。

本記事は以下の基準線をすべての章で同一に用います。判断基準は登録ユーザー数ではなくピーク時の同時リクエスト数です。

[同時リクエスト数を基準とした単一の決定ライン]
同時リクエスト1〜4本   → Ollama(NUM_PARALLEL調整)・LM Studio・Jan
同時リクエスト5〜10本  → llama.cpp -np 並列デコード・LM Studio 0.4.0+ 連続バッチング
同時リクエスト10本超   → vLLM
またはSLAを負うサービス

⑨ モデルタグのdeprecation警告を無視しないでください。 2026年7月11日から、OllamaはCodeLlama、Qwen2.5・Qwen2.5-coder、Llama 3.x、Mistral、StarCoder、DeepSeek-R1の既定タグにサポート終了警告を出します。チュートリアルをコピペしてこの警告を見ているなら、そのチュートリアル自体が少なくとも1年は古い資料だというシグナルです。他の内容も古びている可能性が高いでしょう。

⑩ --tools all は信頼境界を壊します。 llama.cppのこのフラグを立てると、Web UIからLLMがローカルファイルシステムに直接アクセスします。個人の実験用としては強力ですが、外部から来た文書やWebページをモデルに食わせるパイプラインでは、プロンプトインジェクションがそのままファイルアクセスに直結します。外部入力を扱う環境では有効化しないでください。

⑪ vLLMへの乗り換えを考えているなら、モデル再調達のコストを先に計算してください。 「OpenAI互換APIだからbase URLを変えるだけ」という話は、クライアントコードにのみ当てはまります。モデル資産は付いてきません。Ollama・LM Studio・llama.cpp・JanはGGUF(+MLX)のエコシステムを共有しますが、vLLMはHF safetensors(FP8・AWQ・GPTQ)系が主力で、GGUF対応は本体から外れてアウトオブツリープラグイン vllm-gguf-plugin へ移管された実験的機能です。公式ドキュメントの表現そのままに「highly experimental and under-optimized」であり、他の機能と衝突しうるうえ、トークナイザーもGGUFではなくベースモデル側を別途指定するよう推奨されています。ですから移行計画書には必ずこの3行を入れてください。(1)落とし直すモデルの一覧と総容量、(2)ダウンロードと検証にかかる時間、(3)量子化フォーマットの変更に伴い品質を再確認すべき項目。 実際、ツール移行で最も重くのしかかるコストがここです。

7. よくある質問(FAQ)

Q. ローカルLLM実行ツール比較で、結局のところ1位はどれですか?

絶対的な1位は存在せず、条件別の1位があるだけです。1人で使う開発者はOllama、GUIが必要ならLM Studio、マルチユーザーのサービングはvLLM、極限のハードウェア対応はllama.cpp、オープンソースの原則とMCPエージェントはJanです。あえて「最も無難な1つ」を挙げるなら、エコシステムの規模(GitHubスター177,543)と使いやすさを兼ね備えたOllamaが最初の選択として無難です。

Q. OllamaとvLLMでは、どちらが速いですか?

条件によって答えがひっくり返ります。 1人で使うバッチサイズ1の環境では両者のtok/sは事実上同じで、むしろOllamaのほうがスケジューラのキューイング負荷がないぶん初回応答が速いケースが多いです。一方、同時リクエストが増えるとvLLMはスループットが伸び続けるのに対し、Ollamaは相対的に早く頭打ちになります。ただしOllamaを「同時処理機能のないツール」と誤解しないでください。公式FAQの OLLAMA_NUM_PARALLEL が並列スロット数を決めており、既定値が1なので、遅いと感じるケースの相当数はこの値を上げていないだけです。それでも残る差はPagedAttentionと連続バッチングの不在から来ます。「速い」をスループットで定義するのかレイテンシーで定義するのか、そこを決めてから比較すべきです。

Q. LM Studioは会社で無料で使ってもいいのですか?

はい、大丈夫です。2025年7月8日をもって商用利用ライセンスの要件が撤廃され、別途のフォーム記入や問い合わせなしで職場で無料利用できます。無料プランでもローカルLLM実行、オフライン音声文字起こし、Bionicエージェント、llama.cpp・MLXバックエンド、LM Link最大5台までが提供されます。まだ「業務利用は別ライセンスが必要」と書かれた記事を見かけたら、それは古い情報です。

Q. MacBookでローカルLLMを使いたいのですが、どのツールがよいですか?

MacならMLXバックエンドに対応したツールが正解です。Ollama(0.19以上)、LM Studio、Jan(0.7.7以上)がいずれもMLXに対応しています。ただしOllamaのMLXプレビューバックエンドは統合メモリ32GB超が条件です。ここで誤解が多いのですが、16GBのMacでOllamaが動かないのではなく、MLXアクセラレーションが効かないだけで、従来のMetal(llama.cpp)経路では正常に動作します。LM StudioとJanはMLX利用にこうしたメモリのゲート条件を公式には設けていませんが、メモリの上限そのものはどのツールを使っても同じように効きます。 16GBのMacならツールを問わず7〜8B級のQ4モデルが現実的な上限で、14B以上はコンテキストを削っても厳しくなります。つまり16GBのMacでの選択肢は「Ollamaか否か」ではなく、どのサイズ・フォーマットのモデルを載せるかです。vLLMはMacにはおすすめしません — Apple SiliconのGPU対応が別プロジェクト vLLM-Metal 経由でのみ可能で、本体統合ではないためです。

Q. WindowsでvLLMを使えますか?

公式には不可能です。 vLLM公式のインストールドキュメントのサポートハードウェア一覧にWindowsがありません。コミュニティフォークが存在するという話はありますが公式サポートではないので、本番投入するにはリスクがあります。Windowsでマルチユーザーのサービングが必要なら、第6章のコツ⑧の基準線をそのまま当てはめてください。同時リクエストが10本を超える区間なら、WSL2またはLinuxサーバーにvLLMを載せる構成が現実的です。5〜10本の区間なら、連続バッチングに対応したLM Studio 0.4.0以上やllama.cppの -np 並列デコードでWindows上でも十分さばけます。1〜4本の区間なら、Ollamaの OLLAMA_NUM_PARALLEL を上げるだけで解決するケースが多いはずです。

Q. ローカルLLMツールは全部無料ですか?隠れコストはありませんか?

ローカル実行そのものは5つとも無料です。llama.cpp、vLLM、Janには有料ティアがそもそも存在せず、OllamaとLM Studioはクラウド推論のアドオンにのみ課金します(Ollama Pro 月$20、LM Studioはトークン従量課金)。本当のコストはハードウェアと電気代、運用時間、そしてモデルの再調達です。ここでよく混ざるのが32GBの話ですが、統合メモリ32GB超はOllamaのMLXバックエンドの条件であって、30B級モデルの要求スペックではありません。 30B級自体はM4 Pro 24GBでも35〜55 tok/sで動きます。もちろん大きなモデルを余裕をもって回すにはメモリ容量と帯域幅にお金がかかりますし、vLLMは事実上データセンターGPUの料金がすべてです。最後に、vLLMへ移るときはGGUFのモデルライブラリをそのまま持ち込めないので、数十GBを落とし直す時間とストレージもコストに含めてください。

Q. LM StudioとJanは何が違うのですか?

どちらもGUI優先のデスクトップツールですが、決定的な違いはオープンソースかどうかです。LM Studioはアプリ本体がクローズドソースで、GitHubに公開されているのは lms CLIとSDKだけです。対してJanはアプリ全体がApache 2.0です。機能面ではLM Studioが量子化の視覚選択UIと連続バッチングによる並列リクエストで先行し、Janはインラインのツール承認やネイティブの web_search・web_fetch ツールなどエージェント側に強みがあります。監査が必要な組織ならJan、手軽さ優先ならLM Studioです。

Q. llama.cppのバージョンはどう確認するのですか?

セマンティックバージョンがありません。 代わりに bXXXXX という形式のビルドタグを使います。2026年8月2日08:15 UTC時点の最新ビルドはb10226ですが、8月1〜2日だけでb10218・b10219・b10221・b10223・b10224が立て続けに出るほど更新が頻繁です。実務では、正常動作を確認したビルドタグを記録しておき、そのタグを固定して使うことをおすすめします。

Q. 既存のOpenAI APIのコードを、そのままローカルモデルへ移せますか?

はい、ほとんどの場合は可能です。5つのツールはすべてOpenAI互換APIを提供するので、SDKのbase URLをローカルのアドレスに変えるだけで済みます。ポートはOllamaが11434、llama.cppの llama-server が8080、Janが1337で、LM StudioとvLLMもそれぞれ互換サーバーを提供しています。llama.cppは /v1/chat/completions、/v1/completions、/v1/embeddings、/v1/models に対応し、さらにAnthropic互換のチャットルートまで備えているので、移植性が特に良好です。

8. 結論:2026年のローカルLLM実行ツール比較は、結局2つの問いで終わる

ここまで5つのツールをバージョン・ライセンス・性能・価格・ハードウェア制約まで見てきましたが、実際の意思決定は驚くほどシンプルです。**1つ目の問いは「ピーク時の同時リクエストは何本か」**です。1〜4本ならOllama(OLLAMA_NUM_PARALLEL を調整)・LM Studio・Janから好みで選べばよく、5〜10本ならllama.cppの -np やLM Studioの連続バッチングが有効射程、10本を超えるかSLAを負うサービスならvLLMです。最後の区間で残る差は環境変数では詰めにくく、PagedAttentionと連続バッチングという構造の有無から来る差です(ただしこの区間の境界はモデルサイズ・コンテキスト長・SLAによって動くので、自分の環境で一度は測ってみることをおすすめします)。**2つ目の問いは「ターミナルを開けるのか」**です。開けるならOllamaとllama.cppの扉が開き、開けない・開きたくないならLM StudioとJanが残ります。

2026年上半期を経て、このカテゴリが確実に成熟したというシグナルも明確です。Apple SiliconではMLXが標準として定着し、同じハードウェアでデコードのスループットが大きく上がりました(Ollama公式ベンチマーク基準で0.18のQ4_K_M 58 tok/s → 0.19のint4 134 tok/s。ただしバージョンアップと量子化フォーマットの入れ替えがセットで行われた結果です)。そして5つのツールがすべてOpenAI互換APIを提供するようになりました。ここで1点だけは正確に押さえておく必要があります。API呼び出しのコードはbase URLの1行で済みますが、モデル資産は付いてきません。 前者4つの間ではGGUFファイルをそのまま持って引っ越せるので乗り換えは本当に軽いのですが、GGUFライブラリはvLLMへはそのまま渡りません(本体から外れ、実験的なアウトオブツリープラグインへ移管)。vLLM行きを視野に入れているなら、モデル再調達の時間とストレージを最初から計画に入れてください。

同時に、警戒すべき流れも生まれています。「ローカルツール=完全無料=データが絶対に出ない」という等式は、もはや自動的には成り立ちません。 Ollama v0.32.0のエージェントの既定モデルはクラウドモデルですし、LM Studioもクラウドクレジットを運営しています。プライバシーが導入理由だったのなら、初回セットアップでローカルモデルを明示的に指定したかを必ず確認してください。組織レベルなら、クラウド接続の要素がそもそも一切ないllama.cppか、オープンソースGUIのJanを優先的に検討することをおすすめします。

まとめ:自分の状況に合った最終推奨

┌─ ピーク時の同時リクエストは10本を超えるか?(またはSLAを負うサービスか?)
│   └─ YES → vLLM (v0.26.0)
│            ※ Windowsは公式非対応、Mac GPUは別建てのvLLM-Metal
│            ※ ソフトは無料、コストはGPUインフラ全額
│            ※ GGUFライブラリは持ち込めない → モデル再調達コストの計算が必須
│
├─ 同時リクエストは5〜10本か?
│   └─ YES → llama.cpp -np 並列デコード (b10226, MIT)
│            または LM Studio 0.4.0+ 連続バッチング (0.4.20)
│            ※ Windowsでマルチユーザーサービングが要るときに特に現実的
│
└─ NO (同時リクエスト1〜4本 / 事実上1人で使う)
    │
    ├─ ターミナルは得意か?
    │   ├─ YES ─┬─ 無難な最初の一手      → Ollama (v0.32.5, MIT)
    │   │       │                        ※ 遅いならまずOLLAMA_NUM_PARALLEL(既定1)から
    │   │       │                        ※ Mac MLXプレビューは統合メモリ32GB超が必要
    │   │       │                          (それ以下は従来のMetal経路で正常動作)
    │   │       │                        ※ エージェントの既定モデルはクラウド
    │   │       └─ ハードウェアの極限最適化 → llama.cpp (b10226, MIT)
    │   │                                ※ バックエンド最多、有料要素は皆無
    │   │
    │   └─ NO ──┬─ 手軽さ最優先          → LM Studio (0.4.20)
    │           │                        ※ 2025-07-08から業務利用も無料
    │           │                        ※ Macなら自分でMLXフォーマットのモデルを選ぶ
    │           │                        ※ ただしアプリ本体はクローズドソース
    │           └─ OSS・MCPが必須        → Jan (v0.8.4, Apache 2.0)
    │                                    ※ APIポート1337、完全無料
    │
    └─ データが絶対に外へ出てはいけないなら
        → llama.cpp (クラウド要素が皆無) または Jan
        → Ollama/LM Studio利用時はローカルモデルの明示指定が必須

[ポート早見表] Ollama 11434 · llama.cpp 8080 · Jan 1337
[料金早見表] ローカルはすべて$0 / Ollama Pro $20・Team $25(シート単価)
             LM Studioのクラウドはトークン従量課金
[フォーマット早見表] Ollama・LM Studio・llama.cpp・Jan は GGUF(+MLX)を共有
                     vLLM は HF safetensors・FP8・AWQ・GPTQ(GGUFは実験的プラグイン)

ローカルLLMはもはや「動くのか」という問題ではなく、「何で、どんな条件で動かすのか」という問題になりました。上の早見表を基準に、今日ひとつ選んでインストールしてみてください。GGUFエコシステムの中(Ollama・LM Studio・llama.cpp・Jan)なら、base URLの1行でいつでも乗り換えられます。vLLMへ移るときだけ、モデルを調達し直せば済みます。🚀