ローカルLLM、結局どれで動かすのが正解か — Ollama・LM Studio・Foundry Localを実用観点で比較

クラウドAPIのトークン課金に疲れた開発者が、ローカルLLMに手を出す。2026年、これは珍しい話ではなくなった。

問題は「何で動かすか」だ。Ollama、LM Studio、Microsoft Foundry Local。この3つが現在の主要な選択肢で、それぞれ設計思想がまるで違う。「全部同じようなもの」と思って適当に選ぶと、後で移行する羽目になる。

3ツールの性格を30秒で

Ollamaはサーバーだ。バックグラウンドでデーモンが常駐し、REST APIでモデルを呼べる。CLIでollama run llama3と叩けば、ポート11434にAPIサーバーが立つ。スクリプト・Dockerコンテナ・CI/CDパイプラインから呼ぶならこれ一択。

LM Studioはデスクトップアプリだ。GUIでHugging Faceのモデルを検索し、ダウンロードし、チャットUIで試す。量子化のバリエーションごとに「あなたのRAMなら4bitがおすすめ」と教えてくれる。AIを「触ってみたい」人がまず最初に入れるツール。

Foundry Localはライブラリだ。約20MBのネイティブバイナリがアプリに埋め込まれる形で配布され、NuGet・npm・pip・crates.ioからインストールできる。HTTPを介さず、SDK経由の関数呼び出しでモデルを動かす。エンドユーザーがOllamaやLM Studioの存在を知る必要がないのがポイントだ。

対応モデルの自由度に大差がある

ここが最初の選択基準になる。

Ollamaは任意のGGUFフォーマットのモデルを動かせる。公式リストにはLlama 3、Qwen 3.5、Gemma 4、Phi-4、Mistral、DeepSeek V4 Flashなど主要モデルが並ぶが、それ以外もGGUFに変換すれば何でもいい。カスタムファインチューンしたモデルを持ち込みたい開発者にとっては、この自由度が命。

LM StudioもGGUFに対応しており、Hugging Faceのモデルブラウザが内蔵されているから、モデル探しから実行までワンストップで完結する。Ollamaとモデルの自由度はほぼ同等だ。

一方、Foundry Localは対応モデルがFoundryカタログに限定される。Phi-4、Qwen 3.5、Mistral Small 4など「Microsoftが検証・最適化したモデル」だけが使える。2026年6月時点でカタログに載っているモデルは20種類程度。Llama 3を使いたい？ カタログにないから動かない。

これは欠点のように見えて、企業にとっては利点でもある。「IT部門が承認したモデルだけを使わせたい」という要件にはぴったりだ。セキュリティ審査済みのモデルしか選べないことは、エンタープライズでは安心材料になる。

Apple Siliconでの速度: OllamaのMLX対応が効く

MacでローカルLLMを動かすなら、Ollama 0.19以降のMLX対応は見逃せない。

MLXはAppleが開発したML向けフレームワークで、Apple SiliconのGPU/Neural Engineを直接叩く。OllamaがMLXバックエンドを採用したことで、M5 Max上でQwen 3.5-35Bを走らせた場合のデコード速度は112トークン/秒に達した。MLX導入前の58トークン/秒から約2倍。これは実用上かなりの差で、ストリーミングで回答が返ってくる感覚がまったく変わる。

LM StudioもApple Silicon対応だが、MLXバックエンドは選択式で、デフォルトのllama.cppバックエンドよりは速いものの、OllamaのMLX統合ほど最適化されていない。

Foundry LocalのmacOS対応はMetal経由のみで、MLXもNeural Acceleratorもサポートしていない。Macユーザーにとっては明確にビハインドだ。Windows + NPU環境ではDirectML経由でGPU/NPU/CPU自動選択が効くので、Windowsに閉じた運用なら問題ないが、Apple Siliconの性能を引き出したいならOllamaの方が圧倒的に速い。

組み込み用途: Foundry Localの独壇場

ここまでの比較だとOllamaが万能に見えるが、Foundry Localには他の2つにない決定的な強みがある。アプリケーションへの直接埋め込みだ。

OllamaもLM Studioも「別プロセスとして動くサーバー」であり、エンドユーザーが自分でインストールして起動する必要がある。対してFoundry Localは、開発者がSDK（C#・JavaScript・Rust・Python）を通じてアプリ内に組み込む。ユーザーがアプリを起動すれば、初回だけモデルがダウンロードされ、以降はオフラインでも推論が動く。

これが意味するのは、たとえば社内ツールにAI要約機能を組み込む場合、ユーザーに「Ollamaをインストールしてください」と言わなくていいということだ。インストーラーにFoundry Localが含まれていて、アプリを開けばAIが使える。ネットワーク不通でも動く。プロンプトのデータがMicrosoftに送信されることもない。

企業のIT部門がWindowsアプリにAI機能を追加したい場合、このアーキテクチャは非常に魅力的だ。エンドユーザーの技術リテラシーに依存しないから。

実際の選び方

3つは競合しているように見えて、実は棲み分けが明確だ。

Ollama — バックエンド開発者の標準ツール。APIサーバーとしてスクリプトやアプリから呼びたい。カスタムモデルを使いたい。Apple Siliconで最速を求める。Dockerコンテナ内で動かしたい。この全てに対応できるのはOllamaだけ。

LM Studio — 初めてローカルLLMを試す人のスタート地点。GUIでモデルを探してダウンロードし、チャットしながら使用感を確認する。量子化の選択も丁寧にガイドされる。モデルの評価・比較フェーズに最適で、気に入ったモデルが見つかったら本番環境ではOllamaに移すのが定番の流れだ。

Foundry Local — Windowsアプリ開発者向け。エンドユーザーにOllamaの存在を意識させたくない。承認済みモデルだけを使わせたい企業ユースケース。macOSでの推論速度は劣るが、Windows + NPU環境なら自動最適化が効く。

正直なところ、「迷ったらOllama」というのが現時点での無難な答えだ。対応モデルの自由度、Apple Siliconの速度、コミュニティの厚さ、どれを取っても隙がない。ただ、「ユーザーにセットアップさせたくない」「社内Windowsアプリに組み込みたい」という要件が出た瞬間、Foundry Localが唯一の選択肢になる。LM Studioは評価・学習フェーズの入り口として使い、本番はOllamaかFoundry Localに移す——この使い分けが、2026年のローカルLLM運用の現実解だろう。