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 service statusでserviceの状態とlocal endpointを確認する。
4. foundry model listでcatalog、利用可能なalias、初回のEP取得を確認する。

winget install Microsoft.FoundryLocal

foundry --version
foundry --help
foundry service status
foundry model list

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

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

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

foundry model list --filter device=GPU
foundry model list --filter device=NPU
foundry model list --filter provider=OpenVINOExecutionProvider
foundry cache list
foundry service ps

foundry model run 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 --filter alias=qwen*`でalias候補を確認し、`foundry model info MODEL_ID`で固定IDの詳細を確認する。
2. `foundry model list --filter device=GPU`、`device=NPU`、`provider=OpenVINOExecutionProvider`を別々に実行し、filter結果を保存する。
3. OpenVINO verified modelsでmodel、precision、device、Last Verifiedを照合する。掲載有無はFoundry catalogの有無と分ける。
4. aliasでの自動選択とfull model IDでの固定選択を別テストにし、provider、device、driver、load成否、RAM/VRAM、応答時間を記録する。
5. 同じモデルを比較するときは、model ID、precision、入力、出力上限、context、runtime版をそろえ、CPU fallbackとGPU/NPU経路を混ぜない。

• OpenVINO verified models - モデル・precision・device・Last Verifiedを確認する
• Foundry Local CLI reference - alias、model ID、filter、EP・driver条件を確認する

local APIをPowerShellから呼ぶ

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

foundry model run MODEL_ALIAS
foundry service 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_SERVICE_STATUS/v1/chat/completions" `
  -Method Post `
  -ContentType "application/json" `
  -Body $body

$response.choices[0].message.content

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

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

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

Windows向けSDK packageとcross-platform packageはハードウェア加速の前提が違います。WindowsでWinMLを使う場合のpackage名や、同時に両方を入れない注意は、プロジェクトのtarget frameworkと公式SDK referenceを確認してから決めます。

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の更新確認はネットワークを使う可能性があります。完全オフラインで使いたい場合は、実際にcache済みか、起動時に必要な取得がないかを確認します。

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を保存する。

つまずいた時の切り分け

関連記事

• ローカル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-08-12。Foundry Local CLI reference、CLI導入手順、architecture、REST API、SDK、inference SDK integration、Windows導入ガイド、Windows AI FAQ、OpenVINO verified modelsを確認しました。CLIとREST APIはpreview・active developmentのため、service、dynamic endpoint、model catalog、Execution Provider、SDK package、EP・driver条件は利用時点の公式情報を優先してください。