Foundry Localとは？使い方・対応モデル・SDK実装を解説【Microsoft製ローカルAI】

Foundry Localは、AIモデルの取得・ハードウェア高速化・推論までを端末内で完結させるMicrosoft製のローカルAIソリューションです。2026年4月9日に一般提供（GA）となり、Windows・macOS（Appleシリコン）・Linux x64で本番利用できます。Azureサブスクリプションもトークン課金も不要で、データは端末外に出ません。この記事では、winget・brewでのインストールからfoundry model runでの実行、対応モデルとハードウェア別バリアントの選び方、Python・C#のSDK組み込み、そしてOllama・LM Studioとの使い分けまで、実際のコマンドとコードで解説します。

まとめ：Foundry Localの要点

• 正体：ONNX Runtime上で動く軽量ランタイム（アプリへの追加は約20MB）＋C#/JavaScript/Rust/PythonのSDK＋厳選モデルカタログ。単体のチャットアプリではなく「自社アプリに同梱して配布する推論基盤」。
• 導入：Windowsはwinget install Microsoft.FoundryLocal、macOSはbrew install foundrylocal。最初のモデルはfoundry model run qwen2.5-0.5bの1コマンドで実行できる。
• モデル選択：エイリアス指定なら端末のGPU/NPU/CPUに最適なバリアントを自動選択。モデルID指定で実行環境を固定できる。
• 実装：SDKはインプロセスで推論する方式が基本。OpenAI互換エンドポイントを持つローカルサーバーはLangChainやOpen WebUI連携など任意用途向け。
• 使い分け：機密データ・オフライン・低遅延・単一ユーザーが得意。多人数同時アクセスのサーバー推論には非対応（その用途はvLLMやTriton）。

Foundry Localとは何か（Microsoft製オンデバイスAI推論基盤）

GA済みのローカル完結型AIソリューション

Foundry Localは、モデルのダウンロード、ハードウェアアクセラレーション、推論をユーザー端末の中だけで実行する仕組みです。Microsoft Foundryブログの告知によれば、2026年4月9日にWindows・macOS（Appleシリコン）・Linux x64で製品としてGAに到達しました（開発用の付属CLIは公式リファレンス上まだプレビュー表記が残ります）。推論エンジンにはONNX Runtimeを採用し、ランタイム自体はアプリケーションパッケージに約20MBを加えるだけなので、サイズ制約のあるクライアントアプリにも組み込めます。仕組みの前提となるONNXについてはONNXとは？モデル変換・推論の仕組みと使い方で整理しています。

ローカルで完結するため、プロンプトも生成結果も端末内で処理され、Azureサブスクリプションは不要です。ネットワークを使うのは初回のモデル・実行プロバイダーのダウンロード時と、ユーザーが任意で診断ログを共有する場合に限られます。トークン単位の課金や維持すべきバックエンドも存在しません。

Azure FoundryやAzure Local版との位置づけの違い

「ローカルでAIを動かす」選択肢としてMicrosoftは2系統を用意しています。エンドユーザー端末にAIを組み込む用途がこのFoundry Localで、データは端末に残りオフラインでも動作します。一方、Kubernetesネイティブな運用やAzure Arc管理で自社インフラ上に大規模推論を置きたい場合は、Arc対応Kubernetesクラスターへ展開する「Foundry Local on Azure Local」という別製品が該当します。名前が近いため、クライアント配布向けか、自社サーバー基盤向けかで取り違えないことが重要です。

インストールと最初のモデル実行（Windows・macOS・Linux）

wingetまたはbrewでの導入と動作確認

パッケージマネージャーからCLIを導入します。Windowsは以下の1行です。

winget install Microsoft.FoundryLocal

macOSはHomebrewのtapを追加してインストールします。

brew tap microsoft/foundrylocal
brew install foundrylocal

導入後はfoundry --versionでバージョンを、foundry service statusでサービスの稼働と割り当てエンドポイントを確認できます。アップグレードはWindowsがwinget upgrade --id Microsoft.FoundryLocal、macOSがbrew upgrade foundrylocalです。

foundry model runで初回モデルを実行する

モデルの取得から対話開始まではfoundry model run1つで完結します。初回はモデルを自動ダウンロードし、そのまま対話セッションに入ります。

foundry model run qwen2.5-0.5b

ここで重要なのがエイリアスとモデルIDの違いです。qwen2.5-0.5bのようなエイリアスを渡すと、NVIDIA GPUがあればGPU向け、対応NPUがあればNPU向けというように、端末のハードウェアに最適なバリアントが自動選択されます。実行環境を固定したい場合はモデルIDを指定します。たとえばハードウェアに関係なくCPUで動かすなら次のようにします。

foundry model run qwen2.5-0.5b-instruct-generic-cpu

サービス接続エラー・ポート競合が出たときの対処

foundry model listなどの実行時にRequest to local service failedや127.0.0.1:0を含むエラーが出ることがあります。これはサービスは起動しているのにポートバインドの問題でアクセスできない状態で、次のコマンドで解消します。

foundry service restart

Foundry Localはサービス起動のたびに動的なポートを割り当てるため、エンドポイントURLを固定値として扱わず、foundry service statusで都度確認するのが安全です。

対応モデルとハードウェア別バリアントの選び方

キュレーションされたモデルカタログの中身

Foundry Localのカタログは、汎用の実験ツールではなく本番アプリへの同梱を前提に厳選されています。対応するのはチャット補完系（GPT OSS、Qwen、DeepSeek、Mistral、Phi）と音声文字起こし系（Whisper）です。各モデルは量子化・圧縮を経て品質と性能のバランスが調整され、バージョン管理されているため、アプリ側で特定バージョンに固定することも自動更新を受けることもできます。

なお「Gemmaは使えるか」という検索が一定数ありますが、Gemmaは現時点の公式カタログには見当たりません（カタログは随時更新されるため導入時にfoundry model listで確認するのが確実です）。カタログ外のモデルを使う場合はONNX形式であることが前提となる点に注意してください。

foundry model listで探す・絞り込む

利用可能なモデルはfoundry model listで一覧できます（初回実行時はハードウェアに応じた実行プロバイダーも併せてダウンロードされます）。--filterでデバイス種別やタスク、実行プロバイダーで絞り込めます。

foundry model list --filter device=GPU
foundry model list --filter task=chat-completion
foundry model list --filter provider=CUDAExecutionProvider

比較はキーと値が1対1で、大文字小文字は区別されません。エイリアスは--filter alias=qwen*のように末尾ワイルドカードで前方一致でき、値の先頭に!を付ければ--filter device=!GPUのように除外もできます。個別モデルの詳細やライセンスはfoundry model info <alias>およびfoundry model info <alias> --licenseで確認します。

GPU・NPU・CPUの自動選択とダウンロードモデルの管理

Foundry Localは端末のハードウェアを検出して最適な実行プロバイダーを選び、GPU・NPUが使えればそれで高速化し、無ければCPUへシームレスにフォールバックします。ハードウェア判定のコードをアプリ側に書く必要はありません。ダウンロード済みモデルはローカルキャッシュに保持され、次回以降は即座に起動します。キャッシュの場所や一覧、削除はfoundry cache location／foundry cache list／foundry cache remove <model>で管理します。

実行プロバイダー（EP）とNPU・GPUの具体的な動作条件

競合記事では「NPU・GPU対応」とだけ書かれがちですが、実際にアクセラレーションが効くかはチップとドライバのバージョン条件で決まります。公式リファレンスが挙げる条件を、導入前に自分の端末が該当するか判断できる形で整理します。

内蔵の実行プロバイダー（CPU・WebGPU・CUDA）

Foundry Localには3つの実行プロバイダーが内蔵されています。CPU向けはMLAS（Microsoft Linear Algebra Subroutines）を使い、あらゆるCPUで動くフォールバックです。GPU向けのフォールバックはDawnベースのWebGPU実行プロバイダーで、任意のGPUで動きます。NVIDIA GPU向けのCUDA実行プロバイダーはより高速ですが、GeForce RTX 30シリーズ以降、推奨ドライバ32.0.15.5585以上、CUDA 12.5が条件です。

プラグイン実行プロバイダーと対応チップ

Windowsでは、端末とドライバの互換性に応じて次のプラグイン実行プロバイダーが初回実行時に自動ダウンロード・登録され、新版が出れば自動更新されます。自分のNPU/GPUが該当するか確認してください。

Intel NPUをWindowsで使う場合は、最適なNPUアクセラレーションのためにIntel NPUドライバの導入が推奨されます。システム要件はモデルごとに異なるため、実行前にfoundry model info <alias>で必要な条件を確認するのが確実です。

SDKでアプリに組み込む（Python・C#・JavaScript・Rust）

パッケージとWindows ML版の違い

Foundry Localの本体は、アプリのプロセス内で推論するSDKです。パッケージ名は言語ごとに次の通りで、Windows向けにはWindows MLランタイムと統合されたパッケージが別に用意されています。Windows版はAPIは同じまま、より広いハードウェアアクセラレーションに対応します。

Pythonでのチャット補完実装（ストリーミング）

クロスプラットフォーム版はPythonなら次の1行で導入します。

pip install foundry-local-sdk openai

実装は、マネージャーを初期化してカタログからモデルを取得し、ダウンロード・ロードしてからチャットクライアントで推論します。以下はトークンを逐次表示するストリーミングの最小例です。

from foundry_local_sdk import Configuration, FoundryLocalManager

config = Configuration(app_name="foundry_local_samples")
FoundryLocalManager.initialize(config)
manager = FoundryLocalManager.instance

# 実行プロバイダーの登録（Windowsは初回にEPを自動ダウンロード。
# クロスプラットフォームでは即座に返る）
manager.download_and_register_eps()

# 端末に最適なモデルを取得・ダウンロード・ロード
model = manager.catalog.get_model("qwen2.5-0.5b")
model.download()
model.load()

client = model.get_chat_client()
messages = [{"role": "user", "content": "黄金比とは何ですか？"}]

for chunk in client.complete_streaming_chat(messages):
    if not chunk.choices:
        continue
    content = chunk.choices[0].delta.content
    if content:
        print(content, end="", flush=True)

model.unload()

ここでよく出るのがModuleNotFoundError: No module named 'foundry_local_sdk'です。これはSDK未インストールが原因で、pip install foundry-local-sdkで解消します。OpenAI SDKのbase_urlを差し替えて呼ぶ方式も引き続き利用できますが、GA後のクイックスタートは上記のネイティブなチャット補完APIを標準採用しています。

C#（.NET）での実装

C#はクロスプラットフォーム版なら次を追加します（Windows向けはMicrosoft.AI.Foundry.Local.WinML）。

dotnet add package Microsoft.AI.Foundry.Local
dotnet add package OpenAI

基本の流れはPythonと同じで、マネージャー生成→カタログからモデル取得→ダウンロード→ロード→チャットクライアント取得→ストリーミングです。以下は要点の抜粋で、ChatMessageの名前空間やロガー定義を含む完全版は公式のfoundry-samplesリポジトリを参照してください。

using Microsoft.AI.Foundry.Local;

var config = new Configuration { AppName = "foundry_local_samples" };
await FoundryLocalManager.CreateAsync(config, Utils.GetAppLogger());
var mgr = FoundryLocalManager.Instance;

var catalog = await mgr.GetCatalogAsync();
var model = await catalog.GetModelAsync("qwen2.5-0.5b")
            ?? throw new Exception("Model not found");
await model.DownloadAsync();
await model.LoadAsync();

var chatClient = await model.GetChatClientAsync();
var messages = new List<ChatMessage> {
    new ChatMessage { Role = "user", Content = "Why is the sky blue?" }
};
await foreach (var chunk in chatClient.CompleteChatStreamingAsync(messages))
{
    Console.Write(chunk.Choices[0].Message.Content);
}
await model.UnloadAsync();

JavaScript（npm install foundry-local-sdk openai）やRust（cargo add foundry-local-sdk）も同じライフサイクルのAPIを備えており、4言語で書き味が揃っています。

OpenAI互換エンドポイントとローカルサーバーの使いどころ

Foundry LocalはOpenAIのリクエスト/レスポンス形式（Responses API形式を含む）に対応します。既存アプリがOpenAI SDKを使っているなら、向き先をFoundry Localのエンドポイントに変えるだけで最小限の変更で動きます。ただし多くの組み込み用途では、別プロセスのサーバーを挟まずSDKでインプロセス推論する方が無駄がありません。任意のローカルサーバー（OpenAI互換のWebサーバー）は、LangChainとの連携、複数プロセスへの配信、RESTでの実験といった場面で使います。ブラウザでチャットUIを使いたい場合は、モデルを起動したうえでfoundry service statusのエンドポイントをOpen WebUIにhttp://localhost:PORT/v1（認証なし）として登録します。GitHub Copilotなどローカルエンドポイントを指定できるツールから、このOpenAI互換APIを呼び出す使い方もできます。

OllamaやLM Studioとの違いと使い分け

ローカルLLMの実行環境としてよく比較されるOllamaやLM Studioと、Foundry Localは設計思想が異なります。OllamaはGGUF（llama.cpp）系を常駐サービスとして動かし幅広いモデルを扱えるのが強みで、コミュニティとエコシステムも成熟しています。対してFoundry Localは、ONNX形式の厳選モデルをアプリに同梱して配布することを主眼に置き、ハードウェア別バリアントの自動選択とEPの自動更新を標準で持ちます。

使い分けは目的で決まります。自社アプリにAI機能をゼロ設定で同梱して配るのがゴールならFoundry Localが向きます。逆に、カタログにないモデルを自由に試したい、既にOllama/LM Studioのワークフローが回っているなら無理に乗り換える必要はありません。実際の連携例はOllama Web Searchの使い方・API設定・Python実装や、LM StudioのMCP設定とGemma 4の動かし方が参考になります。

向いている用途と導入前に確認すべき制約

得意な領域（機密データ・オフライン・低遅延・単一ユーザー）

Foundry Localが適するのは、音声・テキスト・画像などの機密データを端末に留めたいケース、通信が不安定またはオフラインの環境、クラウド推論のトークンコストを削りたいケース、そしてリアルタイム応答のために低遅延が要るケースです。単一ユーザーが一度に1モデルを使う前提で、KVキャッシュ管理やモデルのライフサイクル管理が最適化されています。医療・法務・行政のように外部にデータを出せない現場や、工場・建設現場・離島拠点のようなエッジ環境が典型的な適用先です。

不向きな場面と代替（多人数同時・非ONNX・フロンティアモデル）

一方で採用すべきでない場面もはっきりしています。多数のユーザーが同時アクセスするサーバー推論には向きません。Foundry Localは同時リクエストのキューイングや連続バッチング、GPU共有を備えないため、その用途ではvLLMやTriton Inference Serverのようなサーバー向けランタイムを使うべきです。また対応モデルはONNX形式に限られ、MLXやGGUF形式はそのままでは動きません。カタログはオンデバイスに最適化された小〜中規模モデル中心で、最先端の巨大モデル（フロンティアモデル）を端末で動かす用途にも当てはまりません。ローカルでコーディングエージェントを動かしたい場合は、OllamaでCodexをローカルLLM実行する方法のような専用の構成も検討に値します。

よくある質問

Foundry Localは無料で使えますか？

Azureサブスクリプションは不要で、トークン単位のクラウド課金も発生しません。推論は端末上で完結します。ただしソフトウェアと使用するモデルには、それぞれ適用される製品条項やライセンスがあるため、商用利用時はfoundry model info <alias> --licenseなどでモデルのライセンスを確認してください。

LinuxやGUIでも使えますか？

GAに伴い、Windows・macOS（Appleシリコン）に加えてLinux x64でも動作します。GUIが欲しい場合は、モデルを起動してOpen WebUIをFoundry Localのローカルエンドポイントに接続すれば、ブラウザ上のチャット画面を端末内だけで構築できます。

Gemmaなどカタログにないモデルは動きますか？

Gemmaは現時点で公式カタログに含まれていません。公式にサポートされるのはチャット補完系のGPT OSS・Qwen・DeepSeek・Mistral・Phiと、音声のWhisper系です。カタログ外のモデルを使う場合はONNX形式であることが前提となります。

OllamaやLM Studioとどちらを選ぶべきですか？

アプリにAIを同梱して配布し、ハードウェア差の吸収を自動化したいならFoundry Localが有利です。手元で多様なモデルを自由に試す用途や、既存のワークフローがあるならOllama/LM Studioが引き続き適します。目的が「配布」か「実験」かで判断するのが分かりやすい基準です。

GitHub Copilotなどのツールと連携できますか？

Foundry LocalはOpenAI互換のエンドポイントを提供できるため、ローカルモデルのエンドポイントを指定できるツールから呼び出せます。エンドポイントは起動ごとに動的ポートが割り当てられるので、foundry service statusで確認したURLを使ってください。

関連記事

• ONNXとは？モデル変換・推論の仕組みと使い方を初心者向けに解説
• Ollama Web Searchとは？使い方・APIの設定・料金とPython実装をわかりやすく解説
• LM StudioのMCP設定とGemma 4の動かし方｜OAuth・MTP高速化・Web検索
• OllamaでCodexをローカルLLM実行する方法｜ollama launch codex-appの手順と対処法
• Pi（pi-coding-agent）をローカルLLMで動かす設定手順と実用ラインを解説