Foundry Local入門2026｜API課金ゼロでLLMを動かす全手順

Claude APIのトークン課金を眺めながらプロトタイプを回す日々。テスト用のチャットボットだけで月$40を超えた請求書が届いた。「ローカルで済む処理はローカルに逃がすべきだ」と腹を括ったタイミングで、2026年4月9日にGA（一般提供）を迎えたのがMicrosoft Foundry Localだ。

約20MBのパッケージをインストールするだけで、Phi-4やDeepSeek R1が自分のマシン上で動く。クラウド通信なし。従量課金なし。OpenAI互換のAPIをローカルで叩ける。実際にプロトタイプのバックエンドをこのツールに差し替えてみたところ、API課金は月$40から$0になった。Ollamaと何が違うのか、どこまで実務に耐えるのか。導入からPython SDKでのアプリ構築、Whisper音声文字起こしまで、手を動かした結果を整理する。

Foundry Localの正体

一言で片づけると、MicrosoftがONNX Runtime上に構築した「ローカル推論専用の実行環境」だ。クラウドのAzure AI Foundryと同じモデルカタログ体験を、手元のPCで再現する。弁当箱に例えるなら、Azureがレストラン、このツールは同じレシピで作るテイクアウト弁当に近い。

構成は3層。

• モデルカタログ -- Microsoftが量子化・最適化済みのモデルを配布。foundry model listで一覧を取得し、ダウンロードするだけ
• 推論エンジン -- ONNX Runtimeが裏側で動く。GPUがあればCUDA、NPUがあればNPUバリアント、どちらもなければCPUへ自動フォールバック
• OpenAI互換API -- http://localhost:5272 で立ち上がるローカルサーバー。既存のOpenAI SDKコードをほぼ無修正で流用できる

開発者にとって大きいのは、ハードウェアの差異を吸収してくれる点だ。対応範囲が広い。NVIDIA GPU（2000シリーズ以降）、AMD GPU（6000シリーズ以降）、Intel NPU、Qualcomm Snapdragon X Elite、Apple Silicon。筆者のチームではWindows（RTX 4070）とMac（M3 Pro）が混在しているが、同じPythonコードがどちらでも動いた。環境差を意識せず済むのは、地味だが開発速度に直結する。

Ollama・LM Studioとの使い分け

選び方は明快だ。

Foundry Localが合う場面。 NPU搭載のCopilot+ PCで推論を走らせたい。Whisperの音声文字起こしも1ツールで済ませたい。Azureへ将来移行する可能性がある。こういう条件が1つでも当てはまるなら、Foundry Localを起点にするのが筋が良い。

Ollamaが合う場面。 コミュニティモデルを自由に試したい。GGUFで量子化パラメータを細かく制御したい。既にOllamaベースのワークフローが回っている。月間5,200万ダウンロードのエコシステムはトラブル時の情報量が桁違いだ。

LM Studioが合う場面。 GUIでモデルを選んですぐ試したい非エンジニア。チーム内デモでの「とりあえず動くもの」が必要なとき。

インストールから初回起動まで

ここではmacOS（Apple Silicon）での手順を中心に示す。Windowsはwingetに読み替えるだけで、Linuxもパッケージマネージャが変わる以外は同じ流れだ。

Step 1: CLIのインストール

# macOS / Linux
brew install foundry-local

# Windows
winget install Microsoft.FoundryLocal

# 確認
foundry --version

Step 2: モデルのダウンロード

# カタログ確認
foundry model list

# Phi-4 mini（3.8B、約2.4GB）をダウンロード
foundry model download phi-4-mini

# DeepSeek R1 7B（推論特化）も追加
foundry model download deepseek-r1-7b

保存先は~/.foundry/models/。ストレージを圧迫しそうならFOUNDRY_MODEL_DIR環境変数で外付けSSDに逃がせる。Ollamaだとキャッシュパスの変更に設定ファイルの編集が要るが、こちらは環境変数1本。この差は些細に見えて、CIで複数マシンにデプロイするときに効いてくる。

Step 3: ローカルサーバーの起動と動作確認

# サーバー起動
foundry service start

# 動作確認
curl http://localhost:5272/v1/models

{"object":"list","data":[{"id":"phi-4-mini",...}]} のようなJSONが返れば起動完了。ここまでの作業でつまずく要素はほぼない。

推論環境はこれで整った。次は、どのモデルを落とすかを判断する。

対応モデル一覧と選び方

2026年4月時点のカタログから、実用上の選択肢を整理した。

自分ならまずPhi-4 Miniで動作確認し、タスクに応じてDeepSeek R1やWhisperを足していく。Qwen 2.5の0.5Bは8GBメモリのノートPCでも走る軽さで、テキスト分類や定型応答にはこれで十分だ。

Python SDKでチャットアプリを作る

OpenAI互換APIが立っているので、既存コードの書き換えは最小限で済む。エンドポイントを差し替えるだけだ。

SDKの導入

# macOS / Linux
pip install foundry-local-sdk

# Windows（GPU加速を使う場合）
pip install foundry-local-sdk-winml

最小構成のチャット

from foundry_local import FoundryLocalManager
from openai import OpenAI

# Foundry Localの起動とモデルロード
manager = FoundryLocalManager()
model_id = manager.download_and_load("phi-4-mini")

# OpenAI互換クライアント
client = OpenAI(
    base_url=manager.endpoint,
    api_key="not-needed"  # ローカルなので認証不要
)

response = client.chat.completions.create(
    model=model_id,
    messages=[
        {"role": "system", "content": "簡潔に日本語で回答してください。"},
        {"role": "user", "content": "Pythonのリスト内包表記を1文で説明して"}
    ]
)

print(response.choices[0].message.content)

# メモリ解放
manager.unload(model_id)

api_key="not-needed"の行が全てを物語っている。認証なし。トークン計測なし。課金なし。既存のOpenAI SDKプロジェクトでbase_urlとapi_keyの2行を書き換えるだけで、ローカル推論に切り替わる。実際に社内のFAQボットをこの方法で移行したが、コード差分は5行だった。

ストリーミング応答で体感速度を上げる

stream = client.chat.completions.create(
    model=model_id,
    messages=[
        {"role": "user", "content": "FastAPIの基本的なルーティングを教えて"}
    ],
    stream=True
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

M3 Pro（18GB）でPhi-4 Miniをストリーミングした実測値を載せておく。初回トークンまで約1.2秒。以降は毎秒30〜40トークン。クラウドAPIだとネットワーク往復で200〜500msのオーバーヘッドが乗るが、ローカルならゼロだ。「今日の予定を教えて」程度の短い応答なら、体感でクラウドの倍は速く感じる。

LangChainとの接続

from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    base_url="http://localhost:5272/v1",
    api_key="not-needed",
    model="phi-4-mini"
)

response = llm.invoke("RAGシステムの設計パターンを3つ挙げて")
print(response.content)

RAGパイプラインではChatOpenAIのbase_urlだけ差し替えればいい。Embedding部分はOpenAIのまま残してもコードの分岐は不要だ。テキスト処理の配線はこれで足りる。

もう1つ、OllamaにもLM Studioにもない機能を使ってみる。

Whisperで音声文字起こし

テキスト生成と音声文字起こしが同じ環境で動く。機密性の高い社内会議の録音をクラウドAPIに投げるのは、管理部門が首を縦に振らないケースが多い。そういう場面でWhisperがローカルで回るのは話が早い。

from foundry_local import FoundryLocalManager
from openai import OpenAI

manager = FoundryLocalManager()
whisper_id = manager.download_and_load("whisper")

client = OpenAI(
    base_url=manager.endpoint,
    api_key="not-needed"
)

with open("meeting.wav", "rb") as audio:
    transcript = client.audio.transcriptions.create(
        model=whisper_id,
        file=audio,
        language="ja"
    )

print(transcript.text)

30分の日本語会議音声（WAV、約150MB）をM3 Proで処理したところ、所要時間は約4分。「プロジェクトマネージャー」が「プロジェクト真似者」になるような固有名詞の誤認識は散見されたが、文脈から修正できるレベルだった。クラウドに音声を送れない機密会議の議事録作成なら、これで十分回る。

1つ注意点がある。複数話者の分離（ダイアライゼーション）には非対応だ。「誰が何を言ったか」を区別するには、Claude CodeやGPT-4oで後処理を挟む必要がある。Whisperで文字起こし → LLMで話者分離という2段構成が、2026年4月時点での現実的な落としどころだろう。

使ってわかった制約と注意点

正直なところ、GA直後のツールには粗さが残る。導入前に知っておかないと時間を無駄にする制約を列挙する。

モデルの選択肢が狭い

ここが最大の不満だ。Ollamaの数千モデルに対して、カタログは約20種しかない。Llama 4もGemma 4も、2026年4月時点では載っていない。Microsoftが1つずつONNX最適化を施して配布する方式のため、新モデルの追加は数週間〜数ヶ月遅れる。最新モデルを即座に試す用途には向かない。

大型モデルは対象外

カタログの最大はDeepSeek R1の14B。70Bクラスは守備範囲外だ。エッジデバイスや一般的な開発PCを前提に設計されているので、意図的な線引きだろう。大型モデルが必要ならOllamaか、素直にクラウドAPIを使う。

GGUFモデルのインポートに非対応

ONNX形式に変換済みのHugging Faceモデルは読み込めるが、GGUFやSafetensors形式からの直接インポートは非対応だ。Ollamaならollama pull一発で終わる操作が、こちらではONNX変換パイプラインを自前で組むことになる。Microsoft Oliveという変換ツールが一応あるが、初見でスムーズに使えるかというと怪しい。ドキュメントを3回読み直してようやくモデル変換に成功した。

ドキュメントの混在問題

Microsoft Learnで検索すると、クラウド版「Azure AI Foundry」のドキュメントが混じって表示される。これが厄介だ。ローカル固有のAPIリファレンスを探すのに30分費やした経験がある。結論、公式GitHubリポジトリ（microsoft/Foundry-Local）のREADMEとサンプルコードから辿るのが最短ルートだった。

WSL2は未サポート

2026年4月時点でWSL2上では動作しない。Windows上で直接インストールする必要がある。WSL2でOllamaを使っている開発者は、Foundry LocalについてはWindows側に別途インストールすることになる。

よくある質問

まとめ

Microsoftが品質保証したローカルLLM実行環境。モデル選択肢はOllamaに遠く及ばない。しかしNPU対応の幅広さ、Whisper統合、ONNX Runtimeの安定性、Azureへの移行パス -- この4点はOllamaにもLM Studioにもない。

自分ならこう使い分ける。プロトタイプ初期でAPI課金を削りたいとき。機密データをクラウドに送れないとき。NPU搭載の社用PCで推論を回したいとき。この3場面ではFoundry Localを選ぶ。最新モデルを即座に試したい、70B以上を動かしたい場面ではOllamaに切り替える。両方をポート違いで立てておく運用が、現時点でのベストだと思っている。

VS CodeもTypeScriptも、出始めは「またMicrosoftか」と冷めた目で見られていた。数年後にデファクトになった。このツールが同じ道を辿るかはわからないが、brew install foundry-localの1行で試せる以上、触っておいて損はない。