Windows向けの「Get started with Foundry Local」でまず押さえるべき結論は、C#/.NETアプリからLLMをローカル実行する導線が、Microsoft.AI.Foundry.Local.WinML NuGetパッケージを中心に整理されたことです。クラウドAPIだけに頼らず、Windows端末上で大規模言語モデルを動かしたい開発者は、OSビルド、.NET SDK、DirectX 12対応GPU、モデルキャッシュ、配布方法を先に確認する必要があります。
2026年5月11日に更新されたMicrosoft公式情報では、Foundry LocalはMicrosoft Foundry on Windowsの一部として、Windowsデバイス上でLLMを直接実行する手段として説明されています。Copilot+ PC専用のWindows AI APIsより深い制御が必要な場合や、Copilot+ PC以外のハードウェアも対象にしたい場合の選択肢になります。(Microsoft Learn)
Windowsの「Get started with Foundry Local」は何が変わるのか
2026年5月11日時点の公式ページで重要なのは、WindowsアプリでローカルLLMを扱うための実装パターンが、次のように明確化されている点です。過去版との差分が公式に細かく列挙されているわけではないため、ここでは「現在の導入前提として確認すべき変更・明確化ポイント」として整理します。
| 確認ポイント | 内容 | 実務への影響 |
|---|---|---|
| Windows向けNuGetパッケージ | Microsoft.AI.Foundry.Local.WinMLを使う | Windowsでハードウェアアクセラレーションを活用する前提になる |
| .NETプロジェクト設定 | net9.0-windows10.0.26100.0などWindowsターゲットが必要 | 既存の.NETプロジェクトに単純追加するだけでは動かない場合がある |
| GPU要件 | DirectX 12対応GPUが必要 | 仮想マシン、VDI、GPU非搭載端末での検証に注意が必要 |
| モデル指定 | フルモデルIDではなくモデルエイリアスを使う | Foundry Localが端末に合うモデルバリアントを選びやすくなる |
| 初回ダウンロード | モデルと実行プロバイダーは初回取得が必要 | ネットワーク、プロキシ、キャッシュ容量を事前に確認する |
| SDKとCLIの役割 | CLIは検証・管理、SDKはアプリ組み込み向け | エンドユーザー端末にCLIを必須とする設計は避けられる |
公式のWindows向けクイックスタートでは、Foundry Local CLIの導入、Windowsターゲットの.NETプロジェクト作成、Microsoft.AI.Foundry.Local.WinMLの追加、モデルの取得・ロード・チャット実行という流れが示されています。前提条件として、Windows 10 build 26100以降、.NET 9.0 SDK以降、DirectX 12対応GPUが挙げられています。(Microsoft Learn)
Foundry Localを使うべきケース、使わない方がよいケース
Foundry Localは「WindowsアプリにローカルAI機能を組み込みたい」場合に向いています。たとえば、社内文書の要約、入力テキストの分類、チャット型UI、オフラインに近い環境での補助機能、クラウド送信を抑えたい業務アプリなどです。
一方で、すべてのAI用途をFoundry Localに置き換えるべきではありません。大量ユーザー向けの集中処理、複数マシンにまたがる推論基盤、コンテナ化された本番推論環境を前提にする場合は、Azure OpenAIやAzure AI Foundry、または別の推論基盤を検討した方が現実的です。Microsoftのベストプラクティスでも、Foundry Localはオンデバイス推論向けであり、分散・コンテナ化・マルチマシン本番展開向けではないと説明されています。(Microsoft Learn)
| 利用シーン | Foundry Localの適性 | 判断ポイント |
|---|---|---|
| Windowsデスクトップアプリに要約・生成AIを追加 | 高い | 端末性能とモデルサイズを確認する |
| WinUI 3、WPF、コンソールアプリでLLMを試す | 高い | .NET 9とWindowsターゲットを用意する |
| Copilot+ PC以外にもAI機能を提供 | 高い | GPU/NPU/CPUの差で性能が変わることを前提にする |
| 社内端末で初回だけモデルを取得し、以後ローカル実行 | 中〜高 | キャッシュ容量、ライセンス、更新管理が必要 |
| Webサービスの全リクエストを集中処理 | 低い | クラウド推論やサーバー向け基盤を検討する |
| GPUパススルーなしの仮想マシンで運用 | 低い | WinMLバックエンドでは想定外の挙動になりやすい |
管理者と開発者が最初に確認すべき前提条件
Foundry Localの導入で失敗しやすいのは、コードではなく環境条件です。特にWindows端末のOSビルド、GPU、ドライバー、ネットワーク、モデルキャッシュの扱いは、開発前に確認しておくべきです。
| 項目 | 確認内容 | 確認方法の例 | 注意点 |
|---|---|---|---|
| OS | Windows 10 build 26100以降、Windows 11 24H2以降推奨 | winverでビルド確認 | 古いOSでは検証対象から外す |
| .NET | .NET 9.0 SDK以降 | dotnet --version | .NET 8以前の既存プロジェクトは移行確認が必要 |
| GPU | DirectX 12対応GPU | dxdiag、デバイスマネージャー | VMではGPUパススルーの有無を確認 |
| CLI | Foundry Local CLI | foundry --version | インストール後はターミナルを開き直す |
| ネットワーク | 初回モデル取得、カタログ取得 | foundry model list | プロキシやファイアウォールで失敗しやすい |
| キャッシュ | モデル保存先と空き容量 | foundry cache location、foundry cache list | 大きなモデルではディスク容量が問題になる |
| ライセンス | 利用モデルのライセンス | foundry model info <model> --license | 商用利用・再配布条件を確認する |
| セキュリティ | 端末・ディスク保護 | 組織ポリシー、BitLockerなど | 機密データを扱う場合は端末管理が重要 |
Foundry Localは、初回にモデルや実行プロバイダーをネットワークから取得し、その後はローカルキャッシュから実行できます。アーキテクチャ説明では、モデルは初回取得後にディスクへキャッシュされ、ネットワークなしでもローカルキャッシュから実行できるとされています。(Microsoft Learn)
C#/.NETアプリでFoundry Localを使う基本手順
C#または.NETでWindows向けに始める場合は、まずFoundry Local CLIで環境を検証し、その後にNuGetパッケージを使ってアプリへ組み込みます。CLIはモデルカタログの確認、対話実行、キャッシュ管理に便利ですが、アプリを配布する場合はSDKを組み込む設計を前提に考えるのが安全です。SDKリファレンスでは、エンドユーザー端末にFoundry Local CLIを必須にせず、アプリ側にローカルAI機能を組み込めると説明されています。(Microsoft Learn)
Foundry Local CLIをインストールする
WindowsではwingetでFoundry Local CLIをインストールします。
winget install Microsoft.FoundryLocalインストール後は、PowerShellやWindows Terminalを閉じて開き直し、foundryコマンドがPATHに反映されているか確認します。
foundry --versionモデル一覧を確認するには、次のコマンドを使います。
foundry model listGPU向けモデルやチャット用途のモデルだけを確認したい場合は、フィルターを使うと調査しやすくなります。
foundry model list --filter device=GPU
foundry model list --filter task=chat-completion初回実行時は、端末に合った実行プロバイダーやモデルの取得が発生する場合があります。開発チームで検証する場合は、最初に小さめのモデルで動作確認し、その後に本命のモデルへ切り替えるとトラブルを切り分けやすくなります。
.NETコンソールアプリを作成する
まず、検証用のコンソールアプリを作ります。
dotnet new console -n FoundryLocalDemo
cd FoundryLocalDemo公式のWindows向け手順では、Windowsターゲットフレームワークとランタイム識別子を指定する必要があります。FoundryLocalDemo.csprojのPropertyGroupを次のように調整します。
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net9.0-windows10.0.26100.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<RuntimeIdentifiers>win-x64;win-arm64</RuntimeIdentifiers>
</PropertyGroup>設定を変更したら、復元します。
dotnet restore既存のWPFやWinUI 3アプリへ追加する場合も、ターゲットフレームワークとランタイム識別子を先に確認してください。net9.0だけのプロジェクトや、Windowsターゲットになっていないプロジェクトでは、Windows固有のネイティブバイナリを扱う前提と合わないことがあります。
NuGetパッケージを追加する
Windows向けのクイックスタートでは、次のパッケージ追加例が示されています。
dotnet add package Microsoft.AI.Foundry.Local.WinML --version 1.0.0
dotnet add package Betalgo.Ranul.OpenAI --version 9.1.0Microsoft.AI.Foundry.Local.WinMLは、Windows向けのハードウェアアクセラレーションを使うためのパッケージです。公式ページでは、WinMLパッケージがONNX Runtime経由でQualcomm NPU、NVIDIA GPU、CPUなど利用可能なハードウェアを使うと説明されています。(Microsoft Learn)
本番プロジェクトでは、パッケージバージョンを固定し、CIでdotnet restoreが再現できるようにしておきます。複数チームで開発する場合は、packages.lock.jsonの利用も検討すると、環境差によるビルド失敗を減らせます。
モデルを取得してチャットを実行する
実装の基本は、Foundry Localを初期化し、カタログからモデルを取得し、未キャッシュならダウンロードし、ロードしてチャットクライアントから推論する流れです。
using Microsoft.AI.Foundry.Local;
using Microsoft.Extensions.Logging.Abstractions;
using Betalgo.Ranul.OpenAI.ObjectModels.RequestModels;
await FoundryLocalManager.CreateAsync(
new Configuration { AppName = "my-app" },
NullLogger.Instance);
var manager = FoundryLocalManager.Instance;
try
{
var catalog = await manager.GetCatalogAsync();
var model = await catalog.GetModelAsync("qwen2.5-0.5b")
?? throw new InvalidOperationException("Model not found.");
if (!await model.IsCachedAsync())
{
await model.DownloadAsync(progress =>
{
Console.Write($"\rDownloading... {progress:F1}%");
});
Console.WriteLine();
}
await model.LoadAsync();
var chatClient = await model.GetChatClientAsync();
var response = await chatClient.CompleteChatAsync(new[]
{
new ChatMessage
{
Role = "user",
Content = "Foundry Localを日本語で短く説明してください。"
}
});
if (!response.Successful)
{
throw new InvalidOperationException(
response.Error?.Message ?? "Chat completion failed.");
}
Console.WriteLine(response.Choices?[0].Message.Content);
}
finally
{
manager.Dispose();
}ポイントは、最初の検証で大きなモデルを選ばないことです。公式ページでは、qwen2.5-0.5bが小さくクイックテストに適した例として挙げられています。モデルの品質、速度、メモリ使用量は端末構成で変わるため、まず小さなモデルで「取得・ロード・応答」が通ることを確認し、その後にphi-4やqwen2.5-7bなど候補モデルを比較します。(Microsoft Learn)
モデルエイリアスを使う理由
Foundry Localでは、GetModelAsync("phi-3.5-mini")のようにモデルエイリアスを渡すのが基本です。公式ドキュメントでは、フルモデルIDではなくモデルエイリアスを渡すことで、SnapdragonではQNN NPU向け、NVIDIA環境ではCUDA向け、その他ではCPUフォールバックなど、ハードウェアに応じたバリアントを選択できると説明されています。(Microsoft Learn)
モデルをフルIDで固定すると、特定端末では速くても、別の端末で動かない、または想定より遅くなることがあります。社内展開では、まずエイリアスで標準モデルを決め、例外的に必要な場合だけフルIDを使う方が運用しやすくなります。
| 用途 | モデル選定の考え方 | 注意点 |
|---|---|---|
| 初回動作確認 | 小さなモデルを使う | 応答品質ではなく環境確認を優先する |
| 業務アプリのPoC | 複数モデルで速度と品質を比較 | 日本語品質、レイテンシ、メモリ使用量を測る |
| オフライン利用想定 | 事前にモデルをダウンロード | 初回取得にネットワークが必要 |
| 商用利用 | ライセンスを確認 | モデルごとに条件が異なる場合がある |
| 全社展開 | エイリアスを標準化 | 端末差を吸収しやすくする |
Windows AI APIs、Windows ML、Azure OpenAIとの使い分け
WindowsのローカルAIには複数の選択肢があります。整理すると、次のように考えると判断しやすくなります。
| 選択肢 | 向いている用途 | 主な前提 |
|---|---|---|
| Windows AI APIs | Copilot+ PC向けに、少ないコードでAI機能を使いたい | Copilot+ PCが必要 |
| Foundry Local | Windows端末でLLMや音声認識モデルをローカル実行したい | Windows 10以降の幅広いPCを対象にできるが、性能はハードウェア依存 |
| Windows ML | 独自ONNXモデルを細かく制御して動かしたい | モデル選定・最適化の知識が必要 |
| Azure OpenAI / Microsoft Foundry | 高性能なクラウドモデルを使いたい | ネットワーク、コスト、データ取り扱いの設計が必要 |
Microsoftの比較ページでは、Windows AI APIsはCopilot+ PC向け、Foundry Localは20以上のオープンソースLLMや音声モデルをOpenAI互換APIで扱う選択肢、Windows MLは任意のONNXモデルをローカル実行する選択肢として整理されています。(Microsoft Learn)
実務では、どれか一つに固定するよりも、段階的なフォールバック設計が有効です。たとえば、Copilot+ PCではWindows AI APIsを優先し、非対応端末ではFoundry Localへ切り替え、ローカルで処理できない場合はAzure OpenAIへフォールバックする構成です。公式比較ページでも、Windows AI APIs、Foundry Local、Azure AIを組み合わせるパターンが示されています。(Microsoft Learn)
WinUI 3やWPFアプリへ組み込むときの注意点
コンソールアプリで動作確認ができたら、次はWinUI 3やWPFなど実際のUIアプリに組み込みます。このとき重要なのは、初期化、ロード、推論、解放のタイミングです。
UIアプリでは、アプリ起動時に一度だけFoundryLocalManager.CreateAsyncを呼び、各画面からFoundryLocalManager.Instanceを参照する設計が扱いやすくなります。終了時にはDispose()を呼んでリソースを解放します。公式ページでも、WinUI 3やWPFではApp.xaml.csやApp.csで初期化し、終了ハンドラーで破棄する流れが示されています。(Microsoft Learn)
また、チャットUIでは通常の一括応答よりもストリーミング応答が適しています。応答が完了するまで画面が無反応に見えると、ユーザーはアプリが停止したと感じます。CompleteChatStreamingAsyncを使い、トークン単位で表示を更新すると、体感速度を改善できます。
using var cts = new CancellationTokenSource();
await foreach (var chunk in chatClient.CompleteChatStreamingAsync(
new[]
{
new ChatMessage
{
Role = "user",
Content = "WindowsアプリでローカルLLMを使う利点を説明してください。"
}
},
cts.Token))
{
Console.Write(chunk.Choices?[0]?.Message?.Content);
}生成結果の長さや多様性を制御したい場合は、Temperature、MaxTokens、TopPなどの設定も確認します。業務アプリでは、創造性を上げるより、出力の安定性や文字数制御を優先する場面が多いため、初期値のまま公開せず、ユースケースごとに検証してください。
管理者が展開前に確認すべきポイント
Foundry Localを社内端末へ展開する場合、開発者だけでなく、端末管理者、セキュリティ担当者、ネットワーク担当者も関係します。特に次の項目は、PoCの段階で確認しておくべきです。
初回ダウンロードとキャッシュを設計する
Foundry Localはモデルを初回取得し、ローカルにキャッシュします。これは便利ですが、モデルサイズが大きい場合、初回起動が遅い、端末ディスクを圧迫する、ネットワーク帯域を消費する、といった問題が起きます。
展開前に、次のコマンドでキャッシュの状態と場所を確認します。
foundry cache list
foundry cache location事前にモデルを取得したい場合は、次のようにダウンロードだけを実行できます。
foundry model download phi-4-miniキャッシュ場所を変更する必要がある場合は、CLIのキャッシュ管理コマンドを確認します。公式CLIドキュメントでは、foundry cache cd /path/to/new/cacheでキャッシュディレクトリを変更する例が示されています。(Microsoft Learn)
モデルライセンスを確認する
Foundry Localで使えるモデルは、モデルごとにライセンス条件が異なる可能性があります。業務利用や商用アプリへの組み込みでは、モデルの利用条件を確認せずに公開するのは危険です。
foundry model info <model> --licenseモデル選定では、応答品質や速度だけでなく、利用目的、配布形態、生成物の扱い、社内規程との整合性を確認します。Microsoftのベストプラクティスでも、Foundry Localで実行するモデルのライセンス上の影響を確認することが推奨されています。(Microsoft Learn)
機密データを扱う端末の保護を確認する
ローカル実行は、すべてのデータをクラウドに送らずに済む点で有利です。ただし、端末上で入力データ、ログ、キャッシュ、アプリデータを扱うため、端末自体のセキュリティが重要になります。
たとえば、機密性の高い社内文書を要約するアプリでは、次のような確認が必要です。
| 項目 | 確認内容 |
|---|---|
| ディスク暗号化 | BitLockerなどで端末ストレージが保護されているか |
| ログ出力 | プロンプトや応答を不用意にログへ保存していないか |
| キャッシュ管理 | モデルや関連データの保存場所を把握しているか |
| 端末紛失対策 | MDM、リモートワイプ、認証ポリシーが整備されているか |
| 利用者権限 | 一般ユーザーが不要な設定変更をできないようにしているか |
Microsoftのベストプラクティスでは、組織のセキュリティポリシーに準拠した環境でFoundry Localを実行すること、機密データを扱う場合は端末要件を満たすこと、機密性の高いファインチューニングデータを含むモデルをキャッシュする端末ではディスク暗号化を行うことが示されています。(Microsoft Learn)
移行・展開で失敗しやすいポイント
Foundry Localは導入手順自体はシンプルですが、既存システムから移行するときには注意が必要です。
クラウドLLMと同じ応答を期待しない
Azure OpenAIや他のクラウドLLMからFoundry Localへ移行する場合、モデルが変われば応答傾向も変わります。プロンプトをそのまま流用しても、同じ品質・同じ文体・同じ推論性能になるとは限りません。
移行時は、次の観点で再評価してください。
| 評価項目 | 確認内容 |
|---|---|
| 日本語品質 | 敬体・常体、専門用語、要約精度 |
| レイテンシ | 初回ロード時間、1回あたりの応答時間 |
| 安定性 | 同じ入力に対する出力のぶれ |
| 最大出力 | 業務上必要な文字数を出せるか |
| エラー処理 | モデル未取得、空応答、ネットワーク断を扱えるか |
| コスト | クラウド利用料は減っても、端末要件や運用コストが増えないか |
Windows AI APIsからの置き換えと考えない
Windows AI APIsとFoundry Localは競合というより、対象が異なります。Copilot+ PC向けに標準APIで素早く実装したいならWindows AI APIsが有力です。一方、Copilot+ PC以外も対象にしたい、複数のLLMを試したい、OpenAI互換の形でローカル推論を扱いたい場合はFoundry Localが候補になります。Microsoft Foundry on Windowsの概要でも、Windows AI APIs、Foundry Local、Windows MLは異なる選択肢として整理されています。(Microsoft Learn)
Windows専用パッケージとクロスプラットフォーム版を混同しない
Windowsで開発・配布する場合は、Microsoft.AI.Foundry.Local.WinMLを使うのが基本です。非Windowsプラットフォームも対象にする場合は、Microsoft.AI.Foundry.Localを使います。公式ページでは、非Windowsをターゲットにする場合はMicrosoft.AI.Foundry.Localを使い、APIは同一で、Windows固有のハードウェアアクセラレーションを含まないと説明されています。(Microsoft Learn)
複数OS対応アプリでは、条件付きのプロジェクト設定を用意し、WindowsではWinML版、非Windowsではクロスプラットフォーム版を使い分ける設計にします。SDKリファレンスにも、Windowsと非Windowsでパッケージ参照やターゲットフレームワークを分ける構成例が掲載されています。(Microsoft Learn)
よくあるトラブルと対処法
Foundry Localの初期導入で詰まりやすい問題を、実務向けに整理します。
| 症状 | 主な原因 | 対処 |
|---|---|---|
foundryコマンドが見つからない | PATHが反映されていない | ターミナルを開き直し、foundry --versionを実行 |
| モデルが見つからない | カタログ取得失敗、エイリアス誤り | foundry model listで利用可能モデルを確認 |
| 初回実行が遅い | モデルや実行プロバイダーの初回取得 | 小さなモデルで検証し、必要なら事前ダウンロード |
| 応答が空になる | DirectX 12対応GPUがない、VMにGPUパススルーがない | 物理端末またはGPUパススルーありの環境で検証 |
| 推論が遅い | CPU実行、大きすぎるモデル | GPU利用、量子化モデル、小さなモデルを検討 |
| サービス接続エラー | ローカルサービスのポートや起動問題 | foundry service restartを実行 |
| Python環境で依存関係エラー | foundry-local-sdk-winmlとfoundry-local-sdkの混在 | 片方をアンインストールし、仮想環境を使う |
公式のトラブルシューティングでは、WinMLバックエンドではDirectX 12対応GPUが必要で、GPUパススルーのない仮想マシンでは成功レスポンスでも空の内容が返る場合があると説明されています。また、Model not foundの場合はネットワーク接続やモデルエイリアスを確認し、foundry model listで利用可能なエイリアスを確認する流れが示されています。(Microsoft Learn)
本番導入前のチェックリスト
PoCで動いた段階から本番導入へ進む前に、次のチェックを済ませてください。
| チェック項目 | 完了の目安 |
|---|---|
| 対象端末のOSビルドを確認した | Windows 10 build 26100以降、またはWindows 11 24H2以降を基準にできている |
| GPU要件を確認した | DirectX 12対応GPUがあり、VM利用時はGPUパススルーを確認済み |
| .NETプロジェクト設定を確認した | Windowsターゲットフレームワークとwin-x64;win-arm64を設定済み |
| パッケージバージョンを固定した | CI/CDで再現可能なrestoreができる |
| モデルエイリアスを決めた | 端末差を吸収できるエイリアス運用にしている |
| モデルライセンスを確認した | 商用利用・社内利用・再配布条件を確認済み |
| 初回ダウンロードを設計した | プロキシ、帯域、キャッシュ容量を考慮している |
| エラー時のフォールバックを用意した | モデル未取得、空応答、ローカル推論不可に対応できる |
| ログとデータ保護を確認した | プロンプトや応答を不用意に保存しない |
| ユーザー体験を検証した | ストリーミング表示、キャンセル、タイムアウトを実装している |
特に重要なのは、Foundry Localを「入れればすべてのWindows端末で同じように速く動くもの」と考えないことです。実際の性能は、GPU/NPU/CPU、ドライバー、モデルサイズ、メモリ、ディスク、初回キャッシュ状態に左右されます。開発端末だけでなく、実際に配布する標準PCで必ず検証してください。
次に取るべき行動
まずは、開発用Windows端末でwinget install Microsoft.FoundryLocalを実行し、foundry model listでモデルカタログを確認します。その後、.NET 9のコンソールアプリを作成し、Microsoft.AI.Foundry.Local.WinMLを追加して、小さなモデルでチャット応答まで通してください。
PoCが成功したら、すぐに大規模展開へ進むのではなく、対象端末のGPU、初回ダウンロード、キャッシュ場所、モデルライセンス、ログ保存方針を確認します。WindowsアプリにローカルLLMを組み込む場合、Foundry Localの価値は「クラウドを使わないこと」だけではありません。端末ごとのハードウェアを活かしながら、必要に応じてWindows AI APIsやAzure OpenAIへフォールバックできる設計にすることで、実用性の高いAI機能を提供できます。
コメント