Foundry LocalをWindowsで使う方法｜CLI・ローカルAPI・モデル選び

先に結論：Foundry Localは「Windows上のローカルruntime」として確認する

Foundry Localは、Windows PC上でモデルを取得・ロードし、CPU・GPU・NPUなど利用可能なハードウェアに合わせて推論するためのruntimeです。Windows AI APIsの組み込み機能、Windows MLのONNX開発基盤、LM StudioやOllamaのアプリ実行環境とは役割が違います。

Microsoft Foundryのクラウドとは別物

名前が似ていますが、Foundry Localは自分のWindows PCでモデルを動かすローカル側の製品です。CLI referenceではAzure RBACは適用されないと説明され、推論データをクラウドへ送るAPI keyを最初から設定する構成ではありません。

ただし「ローカル」と「最初からネットワーク不要」は同じではありません。モデル、hardware-optimized variant、Execution Providerを初回にcatalogから取得し、キャッシュ後の推論はローカルで行う、という段階を分けて考えます。

Windowsで始める前の確認

ここでは依存関係のインストールや実機操作を代行しません。まず公式CLIとWindows導入条件を確認し、仕事のデータやAPI keyを入れない短いテストから始めます。

wingetとCLIを確認する

1. PowerShellを開き、公式CLIをwingetから入れる。
2. foundry --versionとfoundry --helpで、実際に入ったCLIのコマンド名を確認する。
3. foundry server statusでdaemonの状態とlocal endpointを確認する。
4. foundry model listでcatalog、利用可能なalias、初回のEP取得を確認する。

winget install Microsoft.FoundryLocal

foundry --version
foundry --help
foundry server status
foundry model list

2026-09-16に確認した現行CLI referenceと導入手順は、daemonを`foundry server status`などで確認します。CLIはpreviewで変更される可能性があるため、実際にインストールしたCLIの`foundry --help`と利用時点の公式docsを優先してください。

モデルaliasと実行先を分けて見る

Foundry Localのmodel aliasは、短い名前でモデルを指定できるだけでなく、利用ハードウェアに合うvariantを選ぶ入口です。CLI referenceでは、aliasを使うとGPUや対応NPU向けの候補を自動選択し、特定のmodel IDを使えば実行variantを固定できると説明しています。

foundry model list --device gpu
foundry model list --device npu
foundry model list --type chat
foundry model list --search qwen
foundry model list --cached
foundry model list --loaded
foundry model list --variants
foundry model info MODEL_ID
foundry cache list

foundry chat MODEL_ALIAS

aliasでNPU候補が選ばれても、すべてのモデル計算がNPUだけで完結するとは限りません。モデルvariant、Execution Provider、driver、入力長、出力長を同じ実験条件で記録します。

FoundryのvariantとOpenVINO検証済みモデルを混同しない

Foundry Localのmodel catalogは、aliasとmodel ID、hardware-optimized variant、Execution Providerを選ぶための一覧です。一方、OpenVINOのverified models表は、OpenVINOで検証されたモデル・precision・device・最終確認版を示す別の資料です。OpenVINOの表にモデル名があることだけで、Foundry Localのcatalog、alias、Intel Arc、手元のdriverで動くとは判断しません。

OpenVINOの公式表は、掲載外のモデルも動く可能性はあるが未検証と説明しています。たとえば`qwen3.6-35b-a3b`のような行を見つけても、Foundry Localが同じID・variantを持つか、Intel Arcで同じdevice結果になるかは別に確認が必要です。表の空欄を失敗や非対応と断定せず、使う時点の表と実ロード結果を保存します。

1. `foundry model list --search qwen`でalias候補を確認し、`foundry model info MODEL_ID`で固定IDの詳細を確認する。
2. `foundry model list --device gpu`、`--device npu`、`--type chat`を別々に実行し、一覧結果を保存する。
3. OpenVINO verified modelsでmodel、precision、device、Last Verifiedを照合する。掲載有無はFoundry catalogの有無と分ける。
4. `--variants`や`--verbose`でvariant・model IDを確認し、aliasでの自動選択とfull model IDでの固定選択を別テストにする。
5. provider、device、driver、load成否、RAM/VRAM、応答時間を同じ条件で記録する。
6. 同じモデルを比較するときは、model ID、precision、入力、出力上限、context、runtime版をそろえ、CPU fallbackとGPU/NPU経路を混ぜない。

• OpenVINO verified models - モデル・precision・device・Last Verifiedを確認する
• Foundry Local CLI reference - alias、model ID、一覧オプション、EP・driver条件を確認する

local APIをPowerShellから呼ぶ

CLIの`foundry run MODEL_ALIAS`でモデルを起動し、`foundry server status`で表示されたlocal endpointを使います。現行CLI referenceはserver起動ごとのdynamic portを案内しているため、固定portを前提にせず、利用時点のstatus出力を記録します。

foundry run MODEL_ALIAS
foundry server status

最初はstream=falseの短いリクエストにし、`model`には`foundry model list`で確認したmodel IDまたはaliasを入れます。API referenceではendpointは`/v1/chat/completions`で、OpenAI Chat Completions形式のmessages、stream、max_tokensなどを扱います。

$body = @{
  model = "MODEL_ID_OR_ALIAS_FROM_FOUNDRY"
  messages = @(
    @{ role = "user"; content = "WindowsのローカルAIで短い回答を返してください" }
  )
  stream = $false
  max_tokens = 128
} | ConvertTo-Json -Depth 8

$response = Invoke-RestMethod `
  -Uri "http://127.0.0.1:PORT_FROM_FOUNDRY_SERVER_STATUS/v1/chat/completions" `
  -Method Post `
  -ContentType "application/json" `
  -Body ([System.Text.Encoding]::UTF8.GetBytes($body))

$response.choices[0].message.content

• localhostのportが応答するかを先に確認する。
• model ID、messages、stream、max_tokensを最小にする。
• 回答、finish_reason、usage、ログを保存してからstreamingやtoolsを足す。
• 別アプリから呼ぶ時は、base URLの末尾`/v1`と認証設定を個別に確認する。

Open WebUIからFoundry Localへつなぐ

Foundry LocalにはOpenAI互換の`/v1` endpointがあるため、Open WebUIをブラウザの画面として接続できます。ただし、Open WebUIを起動する場所、Foundry Localがモデルを推論する場所、ブラウザやcontainerが接続するURLは別々に確認します。Microsoftの現行CLI referenceは、`foundry server status`で毎回取得したdynamic portをOpen WebUIのDirect Connectionsへ入力する手順を案内しています。

1. Foundry Localでモデルを起動し、ターミナルを閉じずに残す。
2. `foundry server status`で表示されたendpointから、その時点のPORTを記録する。
3. Open WebUIのConnectionsでDirect Connectionsを有効にし、同じPCなら`http://localhost:PORT/v1`、AuthはNoneとして保存する。
4. モデル一覧が空なら、`foundry model list --loaded`でロード状態とmodel IDを確認し、Open WebUIを再読み込みする。
5. 機密でない短い入力を1回だけ送り、URL、model、Foundryのログ、外部provider設定を別々に確認する。

foundry run MODEL_ALIAS
foundry server status
foundry model list --loaded

# Open WebUI: http://localhost:PORT_FROM_FOUNDRY_SERVER_STATUS/v1
# Auth: None

Foundry Localのportはserver起動ごとに変わり得るため、以前のportや固定の5272などを使い回しません。Open WebUIのDocker接続では、container内の`localhost`はWindows hostを指さない場合があるため、Open WebUI公式docsにある`host.docker.internal`の考え方と、実際のネットワーク構成を分けて確認します。

Open WebUIのDirect Connectionsは、構成によって推論リクエストをOpen WebUI backendを経由せず、ブラウザからAPI endpointへ送る機能です。Foundry LocalとOpen WebUIを同じPCで使っていても、外部providerを追加すれば入力が外部へ送られる可能性があります。最初はlocal endpointを一つだけ登録し、送信先・保存先・認証・ログを確認してから他のproviderや文書を追加します。

• Foundry Local CLI reference - Open WebUI、dynamic port、server statusの公式手順を見る
• Foundry Local REST API - /v1 endpointとmodel・chat仕様を確認する
• Open WebUI provider connections - URL、model ID、Docker host接続、Direct Connectionsを確認する
• Open WebUIをWindowsで使う - Docker・WSL・volume・providerの役割を確認する
• ローカルAI APIサーバー比較 - endpoint・認証・公開範囲をruntime別に比較する
• ローカルAIのプライバシー - local UIと外部送信・保存の境界を確認する

SDK内蔵の実行とCLIのRESTを混ぜない

Foundry Localのarchitecture docsでは、SDKはCore APIをアプリ内へロードするin-process構成で、必要な場合だけOpenAI互換REST endpointを起動できると説明しています。一方、CLIはFoundry Local daemonを`foundry server`で管理します。どちらも「ローカル」ですが、プロセス境界が違います。

SDK packageは言語と配布targetで選びます。C#/.NETではWindows ML統合を使うWindows packageと、同じAPI面でWindows MLを含まないcross-platform packageがあります。PythonでもWindows ML統合版とcross-platform版は別packageです。Windows向けWinML quickstartはDirectX 12対応GPU（統合型または独立型）を前提とするため、CPU variantがあることだけでGPU要件を満たすとは判断できません。GPUがない端末では、CLIのCPU execution providerまたはWindows MLを含まないcross-platform SDKの経路と、選ぶmodel variantの対応条件を個別に確認してください。

Pythonで依存関係の競合が出た場合は、仮想環境ごとに使うpackageを一つにします。PyPIの`foundry-local`（`-sdk`なし）はMicrosoft SDKとは別のthird-party packageです。アプリ内SDKの基本経路にCLIは不要で、CLIはterminalからmodelやdaemonを管理したい場合に追加します。

NPU・GPU・CPUの期待値を確認する

Foundry Localは、対応するExecution Providerを動的に取得・登録し、モデルaliasから利用可能なhardware variantを選ぶ仕組みです。WindowsではQNN（Qualcomm）、OpenVINO（Intel）、VitisAI（AMD）などがdevice・driver条件付きで案内されています。

NPUの一覧に機種が出たことは、すべてのLLMがNPUで高速化される保証ではありません。NPUの有無、選ばれたvariant、EP、driver、モデルの演算、入力・出力長を一つずつ記録します。

• Copilot+ PCのNPUチェック - Windows AI APIs、Foundry Local、Windows MLの役割を比較する
• ローカルRAGの負荷分解 - embedding、検索、reranking、generationを分ける

オフライン・プライバシー・previewの注意

モデルとEPがcacheに入った後の推論はローカルで行えますが、初回の取得、catalog更新、CLIやSDKの更新確認はネットワークを使う可能性があります。完全オフラインで使いたい場合は、`foundry model download MODEL_ALIAS`で先に取得し、`foundry cache location`と`foundry cache list`でcache済みかを確認します。

foundry model download MODEL_ALIAS
foundry cache location
foundry cache list

Foundry Local CLIとREST APIは、公式docs上でpreviewまたはactive developmentとして扱われています。学習や個人開発の検証には使えても、productionへ固定する前にAPIの変更、model catalog、package version、ログと送信先を確認してください。

• 会社資料、個人情報、API key、未公開原稿は、local inferenceの確認が終わるまで入力しない。
• OpenAI-compatibleという表示だけで、クラウドへ送信されないと判断しない。base URLを127.0.0.1と外部URLに分ける。
• モデルの初回ダウンロード、EPの取得、catalog metadata、推論本体の通信を分けて記録する。
• preview APIを使うなら、利用時点の公式docsとchangelogを保存する。

オフラインの合格条件：catalog・EP・model・loadedを分ける

Foundry Localの「モデルがcacheにある」と「オフラインで今すぐ推論できる」は同じ確認ではありません。MicrosoftのFAQは、初回モデル取得にはインターネットが必要だが、モデルをdeviceへdownloadしてcacheした後の推論はon-deviceで行い、起動時のcatalog refreshに失敗してもcached catalogへfallbackできると説明しています。

1. `foundry model list --cached --variants`、`foundry cache location`、`foundry cache list`で、使うvariantのmodel cacheと保存先を記録する。
2. aliasの自動選択に任せるか、model IDでvariantを固定するかを決め、SDKなら`IsCachedAsync`/`is_cached`で実行前にcache状態を判定する。
3. `foundry model load MODEL_ID`またはSDKのload後に`foundry model list --loaded`/`is_loaded`、`foundry server status`を確認する。
4. ネットワークを切った検証環境で、cached catalogから同じvariantをloadし、短い入力を1回だけ送る。catalog、EP、model、serverのどこで失敗したかを分けて記録する。
5. メモリを解放するだけならunload、ディスクのmodelを消すなら`foundry cache remove MODEL_ID`を使う。cache directoryを移す場合は`foundry cache cd PATH`後に保存先と空き容量を再確認する。

foundry model list --cached --variants
foundry cache location
foundry cache list
foundry model info MODEL_ID
foundry model load MODEL_ID
foundry model list --loaded
foundry server status

cache済み・loaded・server応答は別の状態です。モデルがcatalogに表示されるだけ、またはserver endpointが開くだけで、完全オフラインの推論準備が完了したとは判断しません。

• Foundry Local FAQ - offline fallback、IsCachedAsync、初回downloadの条件を見る
• Foundry Local architecture - download・load・inference・unloadとcacheの関係を見る
• Foundry Local C# SDK - cached/loaded、download/load/unload/remove、EP downloadを確認する
• Foundry Local CLI reference - cache location、cache cd/remove、model cached/loadedを確認する

つまずいた時の切り分け

関連記事

• ローカルAI APIサーバー比較 - LM Studio・Ollama・JanのAPIとport・認証を比較する
• LM Studio Responses API - /v1/responsesとnative APIの違いを見る
• Ollama OpenAI互換API - Ollamaの/v1とlocal /apiを確認する
• Windows ARMローカルAI - ARM64アプリ、モデル、互換性を分けて考える
• ローカルLLMの安全・プライバシー - local server、ログ、外部APIの境界を確認する

公式確認日

情報確認日: 2026-09-30。Foundry Local CLI reference、CLI導入手順、architecture、REST API、SDK reference、Windows quickstart、Windows AI overview / APIs / FAQ、Foundry Local C# SDK、OpenVINO verified modelsを確認しました。Windows向けWinML quickstartにはDirectX 12対応GPU（統合型または独立型）が必要です。CLIのCPU execution provider、互換model variant、Windows MLを含まないcross-platform SDKは別経路として、利用時点の公式条件を確認してください。PythonのWinML版とcross-platform版は同じ環境へ共存できません。CLIとREST APIはpreview・active developmentのため、server、dynamic endpoint、model catalog、Execution Provider、SDK package、cache状態、EP・driver条件は利用時点の公式情報を優先してください。