【調査・考察編】Microsoftの「Foundry Local」って何？Ollamaとの違いと、その背景を考えてみた

Microsoft AI LLM 開発 コンピュータ

Ollama、LM Studio、llama.cpp…ローカルLLMのツール、もうお腹いっぱい🙄と思っていたら、MicrosoftがFoundry Localというものを出していました。しかもつい最近GA(一般提供)になったらしい。

初めて名前を聞いたときは「Azure AI Foundryのローカル版かな？」くらいに思って流していたのですが、調べてみると思想が他のツールとかなり違うということがわかってきました。特にOllamaやLM Studioに慣れている目で見ると「え、なんでこういう設計にしたの？」というところがいくつも出てきます。

今回は「使う前にまず整理しておく」という立ち位置で、Foundry Localとは何者なのか、なぜMicrosoftがこのタイミングでこういうツールを出してきたのか、そして実際どう使い分けたらいいのかを自分なりにまとめてみます。

※本記事の情報は2026年4月時点のものです。Foundry Localは動きが早いので最新情報は公式ドキュメントも併せて確認してみてください。

Foundry Localとは何者か

公式の説明を一言でいうと、「ユーザーのデバイス上で完全に動くローカルAIソリューション」ということになります。

それだけ聞くと「Ollamaと何が違うんだ🤔」となりますよね。自分も最初そう思いました。でも、よく読んでみると以下のような特徴があります。

  • 軽量ランタイム(ONNX Runtimeベース、約20MB)
  • SDKの提供(C# / Python / JavaScript / Rust)
  • キュレーション済みのモデルカタログ(Phi、Qwen、DeepSeek、Mistral、GPT OSS、Whisperなど)
  • ハードウェア自動選択(NPU/GPU/CPU)
  • OpenAI互換APIあり
  • オプションでローカルHTTPサーバーも立てられる

ここまでは他のツールでもありそうな話ですが、設計思想が一番違う部分があります。公式ページをみると…

Foundry Localは、汎用モデルの実験ではなく、運用アプリケーションを出荷するために設計されています。

つまり、「アプリに同梱してエンドユーザーのPCで動かす」ことを主眼に置いているツールとなります。この点がOllamaやLM Studioと違う部分となります。

Ollama / LM Studioとの違いを整理する

整理するとこんな感じになるでしょうか？

観点 Ollama LM Studio Foundry Local
主な想定ユーザー 開発者・個人 個人・検証者 アプリ開発者(配布者)
主な使い方 サーバー起動→API GUIで完結 SDKでアプリ同梱
モデルの幅 広い(HF系多数) 広い(GGUF中心) キュレーション済み
GUI同梱 あり(v0.10以降、Win/Mac) あり(アプリ自体がGUI) なし
HW最適化 一定自動化 一定自動化 ONNX実行プロバイダ自動切替
思想 コミュニティ・汎用 個人ユーザー実験 アプリ配布インフラ

方向性としては、「Ollama/LM Studioと競合しているわけではない」ようです。

Ollamaなどが「手元で試すためのツール」だとすると、Foundry Localは「作ったアプリに組み込んで配るためのライブラリ」という点で、考えているレイヤーが違います。

この違いが、モデルカタログのキュレーション方針や、SDKファーストな設計、HTTPサーバーをオプション扱いしている設計にも現れている感じがします。

プロセス構成の違いがわかりやすい

一番わかりやすい違いはここかもしれません。

Ollamaなどは以下のように動作を行います。

【ターミナル1】$ ollama serve   ← サーバー常駐
【ターミナル2】$ python my_script.py  ← HTTPで叩く

上記のように2つのプロセス構成が基本となりますが、Foundry LocalのSDKは1プロセスで完結が可能です。

from foundry_local_sdk import Configuration, FoundryLocalManager

config = Configuration(app_name="my-app")
FoundryLocalManager.initialize(config)
manager = FoundryLocalManager.instance

model = manager.catalog.get_model("qwen2.5-0.5b")
model.download()
model.load()

client = model.get_chat_client()
response = client.complete_chat([
    {"role": "user", "content": "黄金比について3行で"}
])

print(response.choices[0].message.content)  #結果表示
model.unload()  #メモリ解放

FoundryLocalManager.initialize()を呼んだ時点で、Foundry Local Coreのネイティブライブラリ(ONNX Runtime含む)がPythonプロセス内にロードされる。実際の推論準備はmodel.load()で実行する。以降の推論はプロセス内の関数呼び出しで実行され、HTTPサーバーを介さないため、アプリ組み込み用途では従来のローカルLLMサーバー方式より軽量となります。

もちろんオプションでサーバーモードも使えるので、既存のOpenAI APIでの開発資産やLangChainをそのまま活かすこともできます。このあたりは柔軟になっていると思います。

なぜMicrosoftはこれを作ったのか？ちょっと考えてみる

ここからは完全に推測半分の余談となりますが、Microsoftがこのタイミングでこういう形のツールを出してきた背景を考えてみると面白いかなと思います🤔

① Copilot+ PCのNPUを活かしたい

個人的にはこれが一番大きな狙いかなと考えます。

MicrosoftはQualcomm・Intel・AMDと組んでCopilot+ PCというNPU搭載PCを推進していますが、NPUの現状の課題は「NPUを使うアプリが少ない」ことに尽きます。ユーザーに「NPU搭載のPC」を買わせる理由が弱い。

Foundry Localは、サードパーティアプリ開発者がNPUを自然に使えるようにする配布レイヤーとなります。 開発者は「NPU検出のコード」や「CUDA対応のコード」を書かなくていい。 このSDKを入れれば、ユーザーの手元のNPU/GPU/CPUを自動で使い分けてくれるのです。

つまりFoundry Localは、「Copilot+ PCというハードウェアカテゴリを推進するためのソフトウェアインフラ」という側面が強いように見えます。

② Azure AI Foundry(クラウド版)との連続性

名前が似ていますが、AzureにはAzure AI Foundry(旧Azure AI Studio)というクラウド製品があり、OpenAI互換APIで多数のモデルをホストしています。

Foundry Localは同じAPI構造を持つように設計されています。

つまり…

  • 開発時　…　Azure AI Foundryでクラウド側で実験
  • 配布時　…　Foundry Localでローカル実行に切り替え
  • ハイブリッド　…　軽い処理はローカル、重い処理はクラウド

このローカル⇔クラウドの行き来のハードルがゼロに近いという作りは、OllamaやLM Studioには無い強みといえます。 Microsoftとしては「Azureを捨てて完全ローカルへ」ではなく、「Azureエコシステムの一部として、ローカルも我々の土俵で」という囲い込みを考えているのかなと思います。

③ エンタープライズ向け「配布できるAIアプリ」の空白市場を狙う

ここが商業的に一番美味しい領域に見えるんですよね。 今、企業が「社内業務アプリにAIを組み込みたい」と思ったときの選択肢は以下となるでしょう。

  • クラウドAPI(OpenAI/Azure OpenAI)　…　トークンコストが読めない、データ漏洩懸念
  • Ollama/LM Studio　…　個人向け、全社展開しづらい(インストーラー配布、バージョン管理が弱い)
  • 自前でONNX Runtime実装　…　ハードルが高すぎる

この間に「アプリ同梱で配れる商用ランタイム」という空白領域があって、Foundry Localはその空白を狙っているように見えます。 特に以下のようなジャンルが当てはまりそうです。

  • 医療(患者データを外に出せない)
  • 金融(取引データのオンプレ要求)
  • 政府・防衛(エアギャップ環境)
  • 放送・メディア系(番組企画や視聴者データ、知財保護)

このあたりはAzureを契約している企業が多いので、Microsoftのエンタープライズ営業ルートとも相性がいいはずです。

④ .NET系開発者に優先的にAI機能を渡す

地味に重要なのがC# SDKが優先的に提供されている点です。Python/JSは当然として、C#を並列で出しているのはMicrosoft系エンタープライズ開発者への明確なメッセージだと思います。

業務システム開発の多くは今も.NETで動いていて、この層が「AI機能を入れたい」となったときの優先経路を用意している、という見方もできそうです。Python中心のOllama/LM Studioエコシステムではこの部分は到底拾いきれない層なんですよね。

総合すると🤔

Foundry Localは表向きは「ローカルAIランタイム」ですが、自分の推測ではこんな感じではないでしょうか？

Copilot+ PCのNPUを活かしたサードパーティアプリ市場を立ち上げ、Azure AI Foundryエコシステムの端末側の出口として機能させ、.NET/エンタープライズ開発者経由で商用アプリへのAI組み込みを一般化する

つまり、ハードウェア × クラウド × 開発者エコシステムを束ねる戦略製品なんじゃないかな、と考えています(あくまで個人の推測ですが🤔)。

OllamaやLM Studioが「コミュニティドリブンのローカルLLM文化」だとすれば、Foundry Localは「企業がAIアプリを量産・配布するためのインフラ」を担うプラットフォームではないかと。同じレイヤーで戦っていないのは、そもそも進む方向が違うからかと思います。

使えるモデルは？

カタログに入っているのは、2026年4月時点で以下のファミリーです。

  • Phi(Microsoft謹製の自社SLM)
  • Qwen / Qwen2.5 / Qwen3(Alibaba)
  • DeepSeek
  • Mistral / Ministral
  • GPT OSS(OpenAIがオープンウェイトで出した20B/120B)
  • Whisper(音声文字起こし)

よく使われるエイリアス例は以下のようになります。

phi-3.5-mini
phi-4
qwen2.5-0.5b
qwen2.5-7b
mistralai-Mistral-7B-Instruct-...
gpt-oss-20b
whisper-large-v3

最新のモデル一覧か、CLIならfoundry model listコマンドで確認できます。

⚠️ 注意点として、Foundry Localのカタログはキュレーション型で、量子化・検証済みのONNXモデルだけが使える仕組みとなっています。

これは思想の話で、公式も「予測できないデバイス上の挙動を持つ様々なモデルを提供するよりも、アプリに埋め込んだときに信頼性の高いパフォーマンスを実現することを優先している」と明言していました。試す楽しさより配布の品質保証を優先している設計です。日本語特化モデル(ELYZA、tsuzumi、Sarashinaなど)は現時点でカタログに入っていないので、日本語運用するならQwen系が現実的ですね。今後のカタログ拡充に期待したいところです。

では、どう使い分けるのがいいのか？

ここまで調べた時点での、自分なりの使い分け案です。

新しいモデルを試したい → LM Studioが最短。GUIで検索→DL→チャットまで一直線

Python/Jupyterで日常的にLLMを叩く → Ollamaが便利。ollama serve常駐で複数スクリプトから使える

RAGの実験 → Ollama + 既存コード。エンドポイント差し替えだけで済む

業務アプリに組み込む・社内配布する → Foundry Local ← ここがFoundry Localの本領

現時点では…

自分なりの結論としては

  • 主力は引き続きOllama / LM Studioでよさそう
  • Foundry Localは「配布アプリを作る」ときの候補として頭に入れておく
  • 1〜2年後にCopilot+PCが普及したタイミングで、そのポジションが上がってくる可能性が高い

Ollamaと競合する場所にいるわけではなく、これまで空いていた「配布可能なAIアプリ同梱ライブラリ」という枠を埋めに来ているという見立てです。なので今すぐ全部乗り換え、という話ではなく、なにかあったときのために、引き出しに1つ追加しておく感覚で向き合うのがちょうどいいのかなと考えます。

おわりに

ローカルLLMツールの乱立によって、Ollama、LM Studio、oLLM、AI Toolkit for VS Code、llama.cpp…と追いかけ続けていますが😅。

それでもFoundry LocalはMicrosoftの戦略が見えるという意味で面白い存在だなと感じています。 ただの便利ツールというより、エコシステム全体のパーツとして見ると面白いですね。

参考リンク