技術 約10分で読めます

MicrosoftのFoundry Local正式リリース、アプリにバンドルして配布できるローカルAIランタイム

Microsoft ローカルLLM Azure AI Foundry ONNX Runtime Windows ML
いけさん目次

ローカルLLMの実行環境は群雄割拠の状態が続いている。
OllamaがMLXバックエンドに切り替えてApple Siliconの推論速度を劇的に引き上げ、AMD LemonadeがGPU+NPUを束ねるマルチモーダルサーバーとして登場し、LM StudioはEVO-X2でも使ったようにGUIの手軽さで支持を集めている。

ただ、これらはすべてエンドユーザーが自分でインストールして起動するツールだ。
アプリ開発者が自分のプロダクトにローカル推論を組み込みたい場合、「まずOllamaを入れてください」とReadmeに書くか、ONNX Runtimeやllama.cppを直接リンクして自前でモデル管理を実装するかの二択になる。
前者はユーザー体験を損ない、後者は開発コストが高い。

MicrosoftがGA（正式版）として発表した「Foundry Local」は、この隙間を埋めるランタイムだ。
パッケージマネージャから追加するだけでアプリにAI推論をバンドルでき、ユーザー側に追加セットアップを要求しない。

「バンドル」とは具体的に何をするのか

「アプリにバンドルできる」と言われてもピンと来ない人が多いと思うので、具体的な仕組みを整理する。

Foundry Localは各言語のパッケージマネージャで配布される。

言語配布元
C#NuGet（Microsoft.AI.Foundry.Local）
PythonPyPI（foundry-local）
JavaScript / TypeScriptnpm
Rustcrates.io

C#の場合、NuGetパッケージをdotnet add packageすると、ビルド時にFoundry Local Coreのネイティブライブラリ（.dll / .so / .dylib）とONNX Runtimeのバイナリがアプリの出力ディレクトリにコピーされる。
このネイティブライブラリが約20MBで、インストーラのサイズへの影響は軽微だ。
Pythonならpip install、JavaScriptならnpm installで同じことが起きる。

モデル自体はランタイムに同梱されない。
初回起動時にFoundry Catalogからハードウェア構成に応じた最適版が自動ダウンロードされ、ローカルにキャッシュされる。
2回目以降はネットワーク不要で動く。
ダウンロード中断からのレジュームにも対応している。

OllamaやLM Studioとの導入フローの違いを図にするとこうなる。

graph TD
    subgraph "Ollama方式"
        A1[ユーザーが<br/>Ollamaをインストール] --> A2[ollama serveを起動]
        A2 --> A3[アプリがHTTPで接続]
    end
    subgraph "Foundry Local方式"
        B1[開発者がSDK<br/>パッケージを追加] --> B2[ビルドで<br/>ネイティブライブラリ同梱]
        B2 --> B3[ユーザーが<br/>アプリをインストール]
        B3 --> B4[AI推論が即利用可能]
    end

ポイントは、Foundry Local方式ではユーザーの手順にAI関連の操作が一切入らないことだ。
アプリをインストールするだけで推論環境が揃う。

以前NDLOCR-LiteをiOSアプリに載せたときは、ONNXモデルをアプリバンドルに直接同梱してONNX Runtime Mobileで推論した。
あのときはモデルの取得・変換・最適化を全部自分でやる必要があったが、Foundry Localはモデルのダウンロードとハードウェア選択をランタイムが自動で処理してくれる。
デスクトップ/クロスプラットフォーム向けに、あの手間を丸ごと吸収した形だ。

インプロセスで動くネイティブライブラリ

Foundry Localのアーキテクチャは、OllamaやLM Studioとは根本的に異なる。

Ollamaは独立したHTTPサーバー（デーモン）として動作し、アプリとの通信はlocalhostへのHTTPリクエストだ。
アプリ間でモデルを共有しやすい反面、別プロセスの管理をユーザーに意識させることになる。

Foundry Localはインプロセスのネイティブライブラリとして動作する。
アプリのプロセス内に直接ロードされ、SDK経由の関数呼び出しでやり取りする。
HTTPのオーバーヘッドがなく、デーモンの起動管理も不要。

graph TD
    A[アプリケーション] --> B[Foundry Local SDK<br/>Python / C# / JS / Rust]
    B --> C[Foundry Local Core<br/>ネイティブライブラリ<br/>.dll / .so / .dylib]
    C --> D[ONNX Runtime]
    C --> E[モデルマネージャー<br/>ダウンロード・キャッシュ・ロード]
    D --> F{ハードウェア検出}
    F -->|Windows| G[Windows ML<br/>GPU / NPU / CPU自動選択]
    F -->|macOS| H[Metal<br/>Apple Silicon GPU]
    F -->|Linux| I[CPUフォールバック]

「Foundry Local Core」がこのアーキテクチャの核で、モデルのダウンロード、ロード、推論、アンロードというライフサイクル全体を管理する。
推論エンジンにはONNX Runtimeを採用している。

なお、開発やデバッグ用に、Foundry Local CoreをOpenAI互換のHTTPサーバーとして起動するモードも用意されている。
LangChainやOpenAI SDKのHTTPクライアントと直接つなぎたい場合に使うが、本番ではインプロセスのSDK利用が推奨される。

ハードウェアアクセラレーションの仕組み

ローカル推論のパフォーマンスを左右するのがハードウェアアクセラレーションだ。
Strix HaloでVRAM配分と格闘したり、LemonadeでVulkanとROCmを比較した経験があると実感するが、どのバックエンドでどのハードウェアを叩くかの選択は開発者にとって面倒な問題だ。

Foundry Localはこの選択をWindows ML（Windows）またはMetal（macOS）に委ねることで、開発者をハードウェア差異から隔離する。

プラットフォームアクセラレーション仕組み
WindowsGPU / NPU / CPU自動選択Windows MLがハードウェアを検出し、最適なONNX実行プロバイダーを選択
Windows（Snapdragon X / XDNA2搭載機）NPU利用QNN（Qualcomm Neural Network）Execution Provider経由
macOS（Apple Silicon）GPU利用Metal経由
Linux x64CPUフォールバック（GPU対応はロードマップ上）

Windows MLはOSレベルのハードウェア抽象化レイヤーだ。
アプリ側はGPUかNPUかCPUかを気にする必要がなく、Windows MLが適切なONNX実行プロバイダー（DirectML、CUDA、QNN等）を自動で選んでくれる。
実行プロバイダーはWindows Update経由で配布されるため、新しいハードウェアのドライバ更新にも追従できる。

モデルも初回ダウンロード時にハードウェア構成に応じた最適なフォーマットにコンパイルされ、キャッシュされる。
同じモデルでもGPU向けとCPU向けでは異なるバイナリが使われる。

AMD環境でのLemonadeのようにバックエンドごとの性能差や挙動の違いを気にしなくてよいのは開発者にとって楽だが、裏を返せば細かいチューニングの余地がない。
llama.cppのようにVulkanかROCmかを明示的に選んだり、量子化方式を指定したりといった制御はできない。

Ollamaやllama.cppとの技術的な違い

ローカルLLMの実行環境として見たとき、それぞれ狙っているレイヤーが違う。

比較軸Ollama / LM Studiollama.cpp（直接利用）Foundry Local
想定ユーザーエンドユーザーが自分で使う開発者が推論エンジンとして組み込む開発者がアプリにバンドルして配布
デプロイ方式ユーザーが別途インストールライブラリリンクまたはサブプロセスパッケージマネージャでアプリに同梱
プロセスモデル独立デーモン（HTTP）インプロセスまたはサーバーインプロセス（ネイティブライブラリ）
推論エンジンllama.cpp / MLXllama.cppONNX Runtime
モデル形式GGUF（量子化自由）GGUF（量子化自由）ONNX（Foundry Catalogから取得）
モデル選択の自由度任意のモデル任意のモデルカタログにあるモデルのみ
ハードウェア選択手動またはバックエンド依存ビルドフラグで明示指定Windows ML / Metalが自動選択
パッケージサイズ数百MB〜ライブラリ単体は軽量約20MB（モデル除く）

Microsoftは「ONNX Runtimeはllama.cppに比べて平均3.9倍、長いシーケンスでは最大13.4倍高速」と主張している。
ただしこの数値はONNXに最適化されたモデルでの計測であり、GGUFの量子化モデルとの直接比較ではない点に注意が必要だ。

最大のトレードオフはモデルの自由度にある。
OllamaやLM StudioならHugging FaceからGGUFをダウンロードしてどんなモデルでも動かせる。
Foundry Localで使えるのはFoundry Catalogに登録されたモデルだけで、現時点では以下のファミリーに限られる。

  • Phi（Microsoft製、小型・高性能）
  • Qwen Family
  • DeepSeek
  • Mistral
  • Whisper（音声文字起こし）
  • GPT OSS系

主要なオープンモデルはカバーしているが、ニッチなモデルやファインチューニング済みモデルは使えない。
EVO-X2で使ったようなカスタムモデルを動かしたい用途にはFoundry Localは向いていない。

リソース要件

要件最小推奨
RAM8 GB16 GB
ディスク空き3 GB15 GB

16GB未満の環境では7Bパラメータを超えるモデルの実行は避けたほうがいい。
モデルのロード中はRAM（またはVRAM）を消費し、使い終わったモデルは明示的にアンロードしてメモリを解放する必要がある。

Strix HaloでVRAM配分を詰めたときのように、統合メモリ環境ではVRAMとメインメモリの配分が推論性能を大きく左右する。
Foundry LocalはWindows MLにハードウェア選択を委ねるため、このあたりの手動チューニングは効かない。
逆に言えば、VRAMを手動で割り当てるような知識がないユーザーのマシンでも、それなりに動くように設計されている。

開発者向けAPI

OpenAI互換のAPIを提供しており、チャット補完（chat completions）と音声文字起こし（transcription）の両エンドポイントに対応する。
既存のOpenAI SDKコードを最小限の変更でローカル推論に切り替えられる。

from foundry_local import FoundryLocalManager

manager = FoundryLocalManager()

# OpenAI互換クライアントでそのまま使える
import openai
client = openai.OpenAI(base_url=manager.endpoint, api_key="unused")
response = client.chat.completions.create(
    model="phi-4-mini",
    messages=[{"role": "user", "content": "Hello"}]
)
print(response.choices[0].message.content)

SDKはPython、JavaScript（TypeScript）、C#、Rustの4言語をサポートする。
C#向けにはWindows ML統合を強化したMicrosoft.AI.Foundry.Local.WinMLパッケージも別途用意されている。

どういうアプリで使うのか

Foundry Localが活きるのは、以下の条件が重なるケースだ。

条件理由
ユーザーにAIツールのセットアップを求められないエンタープライズやコンシューマー向けでは「Ollamaを入れてください」はハードルが高い。インストーラだけで完結する必要がある
データをクラウドに送れない社内文書の要約、医療データの処理、法務ドキュメントの分類など、プライバシーやコンプライアンスの要件でクラウドAPIが使えない
オフライン対応が必要工場、船舶、僻地のフィールドワークなど常時接続できない環境。初回ダウンロード後はオフラインで動く
レイテンシが重要ネットワーク往復がなく応答が速い。リアルタイムのアシスタント機能やインタラクティブなUI補助に向いている

逆に、以下のケースではFoundry Localを選ぶ理由は薄い。

ケース理由
ユーザーが技術者OllamaやLM Studioを自分で入れられるなら、Ollama前提で十分
モデルの自由度が重要GGUFエコシステム（Ollama / llama.cpp）のほうが圧倒的に選択肢が広い
GPUの細かいチューニングが必要llama.cppを直接使うほうがいい
Webアプリやサーバーサイドで使うクラウドAPIか、サーバー上でOllamaを動かすほうが素直

ロードマップ

GA時点で予告されている今後の強化。

  • リアルタイム音声文字起こし（Whisperのストリーミング対応）
  • LinuxでのGPUアクセラレーション
  • NPUの対応範囲拡大
  • モデルカタログの拡充
  • 複数アプリ間でのモデルキャッシュ共有（同一モデルを別アプリが重複ダウンロードしない仕組み）

GitHubリポジトリはmicrosoft/Foundry-Localで公開されている。
ドキュメントはMicrosoft Learnで参照可能。

なお、Azure AI Foundryというクラウドプラットフォームとは名前が似ているが別物だ。
Foundry Localはクラウド依存なしで動くオンデバイスランタイムであり、Azure契約は不要。