Microsoft「Foundry Local」徹底解説｜端末上でAI推論を完結させ、クラウド依存とトークン課金を回避する

2026年5月30日2026年6月9日

「生成AIを業務に組み込みたいが、クラウドAPIを叩くたびにトークン課金が積み上がる。それに、入力したデータが外部に出ていくのも気になる」——こうした悩みを抱えるインフラエンジニアにとって、Microsoftが正式リリースした「Foundry Local」は一度きちんと押さえておきたい選択肢です。

Foundry Localは、AI推論を端末上で完結させる仕組みです。クラウドに問い合わせず、ユーザーのデバイス内でモデルを動かすため、トークン課金がかからず、入力データもデバイスの外に出ません。クラウド前提だった生成AIの常識を、もう一段下のレイヤーから組み立て直す技術と言えます。

この記事では、Foundry Localとは何か、どんな仕組みで動くのか、クラウドAPIと比べてどこにメリットがあり、どんな業務に向くのかを、オンプレ経験者にもわかりやすく解説します。料金とデータの扱いという、実務でいちばん効いてくる2つの観点を軸に整理します。

Foundry Localとは何か

Foundry Localは、Microsoftが提供する「エンドツーエンドのローカルAIソリューション」です。アプリケーションにAI機能を組み込み、その推論をユーザーのデバイス上で完全に実行することを目的としています。

公式ドキュメントの説明を借りると、Foundry Localは使いやすいSDK、最適化されたモデルのカタログ、そして自動ハードウェアアクセラレーションを軽量パッケージで提供します。ポイントは「ユーザーデータがデバイスから離れることはなく、応答はネットワーク待機時間ゼロですぐに始まり、アプリはオフラインで動作する」という設計思想です。トークンごとのコストはなく、維持すべきバックエンドインフラもありません。

オンプレ経験者にとっては、これは「推論サーバーを自前で立てる」のに近い発想に見えるかもしれません。ただしFoundry Localは、サーバーラックに推論基盤を据えるのではなく、エンドユーザーが使うPCやデバイスそのものを推論の実行環境にする点が異なります。サーバー集約型ではなく、端末分散型のAI実行モデルです。

仕組み：ONNX Runtimeと自動ハードウェアアクセラレーション

Foundry Localの中核には、推論ランタイムとしてONNX Runtimeが採用されています。ONNX Runtimeは、機械学習モデルを効率的に実行するためのオープンな実行基盤です。Foundry Localのランタイムは、モデルの取得・ハードウェアアクセラレーション・モデル管理・推論をこのONNX Runtime経由で処理します。

注目すべきは、このランタイムがアプリケーションパッケージに約20MBしか追加しないという軽量さです。サイズが重要なアプリケーションにも、AI機能を直接埋め込めます。

ハードウェアアクセラレーションは自動で行われます。Foundry Localは、ユーザーのデバイスで使えるハードウェアを検出し、最適な実行プロバイダーを選びます。GPUやNPU（ニューラル処理ユニット）が使える場合はそれらで推論を高速化し、なければCPUにシームレスにフォールバックします。エンジニアがハードウェア検出のコードを書く必要はありません。

モデルの管理も自動化されています。モデルは最初に使ったときに自動ダウンロードされ、その後はローカルにキャッシュされて素早く起動します。ユーザーのハードウェアに最適なバリアントが選ばれる仕組みです。

利用できるモデルは、デバイス上での実行に最適化されたカタログから選びます。チャット補完にはGPT OSS、Qwen、DeepSeek、Mistral、Phiなど、音声の文字起こしにはWhisperなどが含まれます。いずれも量子化・圧縮を施し、品質とパフォーマンスのバランスを取った構成になっています。

モデルカタログがあえて限定されている点も、設計思想として理解しておく価値があります。Foundry Localは、汎用的なモデル実験ではなく、運用アプリケーションを出荷するために設計されています。そのため、さまざまなコンシューマー向けハードウェアでテスト済みで、エンドユーザーに配布できる程度に小さいモデルだけを意図的にキュレーションしています。あらゆるモデルを提供してデバイス上の挙動が読めなくなるより、カタログ内のモデルが埋め込み時に信頼できるパフォーマンスを出すことを優先した結果です。

量子化と圧縮も、このローカル実行を支える重要な要素です。大規模言語モデルは本来、膨大なメモリと計算資源を要しますが、量子化によってモデルの数値表現を圧縮すると、メモリ使用量と計算負荷を大きく減らせます。Foundry Localのモデルはこうした最適化を施したうえでカタログに載せられているため、一般的なPCのハードウェアでも現実的な速度で動作します。サーバーグレードのGPUがなくても生成AIを動かせるのは、この最適化の積み重ねによるものです。

モデルはバージョン管理されており、アプリケーションは特定のバージョンにピン留めしたり、自動で更新を受け取ったりできます。本番アプリケーションでは、想定外の挙動変化を避けるためにバージョンを固定し、検証を経てから更新する運用が取りやすくなっています。

加えて、Foundry LocalはOpenAI互換APIをサポートします。OpenAIのリクエスト・レスポンス形式（OpenAI応答API形式を含む）に対応しているため、すでにOpenAI SDKを使っているアプリケーションなら、エンドポイントをFoundry Localに向けるだけで、最小限のコード変更で移行できます。これは既存資産を活かせる実務上の大きな利点です。

ローカルLLM実践入門（日経ソフトウエア編）

手元の環境でLLMを動かす方法を、GUI操作からPythonへの組み込みまで実践的に解説した一冊。Foundry Localの背景にある「ローカルでAIを動かす」考え方を、手を動かしながら理解したい方の入門書に向いています。

クラウドAPIとの違い：料金とデータの扱い

Foundry Localの価値は、クラウドの生成AI APIと比較すると鮮明になります。両者の違いを表に整理します。

観点	Foundry Local（端末上）	クラウド生成AI API
課金	トークン課金なし	トークン量に応じた従量課金
データの送信	推論はデバイス内で完結	入力がクラウドへ送信される
ネットワーク	オフラインで動作可能	常時接続が前提
レイテンシ	ネットワーク待機ゼロ	通信往復の遅延あり
バックエンド運用	維持するインフラなし	事業者側で管理（利用者は不要）
モデルの幅	最適化済みの限定カタログ	最新・大規模モデルが選べる
同時多人数処理	単一ユーザー向け設計	マルチユーザーに対応

料金面では、クラウドAPIがリクエストのたびに課金されるのに対し、Foundry Localはトークン課金そのものが発生しません。利用量が増えても推論コストが青天井にならない点は、大量に処理を回す用途で効いてきます。

データの扱いも対照的です。Foundry Localではプロンプトとモデルの出力がローカルで処理され、Microsoftに送信されません。公式ドキュメントも「アプリケーションがFoundry Localエンドポイントにプロンプトを送信すると、プロンプトとモデルの出力がローカルで処理される」と明記しています。ネットワークを使うのはモデルやコンポーネントのダウンロード時と、ユーザーが任意で選ぶ診断ログの共有時に限られます。機密データを外に出せない業務では、この性質が決定的な意味を持ちます。

さらに、Foundry LocalはAzureサブスクリプションを必要としません。ローカルハードウェア上で完全に動作するため、クラウド契約なしで導入できます。

どんな業務に向くか

Foundry Localが特に力を発揮するのは、次のような業務です。

・機密データを扱う処理: 医療・金融・法務など、データを外に出せない領域での要約・分類・抽出
・オフラインや不安定な回線の環境: 現場作業や移動中など、常時接続が前提にできない場面
・大量処理でのコスト抑制: トークン課金が積み上がる用途で、推論コストを固定化したいケース
・低レイテンシが必要な対話: リアルタイム性が求められるアプリケーションへの組み込み

一方で、向かない用途もはっきりしています。Foundry Localは、1人のユーザーが一度にモデルへアクセスするハードウェア制約のあるデバイス向けに最適化されており、サーバー推論スタックとしては設計されていません。多数の同時ユーザーにモデルを提供する必要がある場合は、vLLMやTriton Inference Serverといったサーバー指向のランタイムが適しています。最新・最大規模のモデルを使いたい場合も、デバイス向けに最適化された限定カタログより、クラウドAPIのほうが選択肢が広がります。

具体的な業務に落とし込むと、向き不向きの判断がしやすくなります。たとえば、患者情報を含む診療メモの要約や、顧客の取引履歴をもとにした問い合わせ分類は、データを外部に送れない典型例です。こうした処理をクラウドAPIで回すと、データガバナンス上の懸念が常につきまといますが、Foundry Localなら推論がデバイス内で完結するため、その懸念を構造的に取り除けます。

工事現場や災害対応のように、ネットワークが安定しない環境での利用も好例です。クラウドAPIは常時接続が前提のため、回線が切れれば機能が止まります。一方Foundry Localはオフラインで動くため、接続状態に左右されずにAI機能を提供できます。

コストの観点では、社内の問い合わせ対応ボットのように、利用量が読めて処理が定型的な用途が向きます。クラウドAPIだと利用が増えるほど課金が積み上がりますが、Foundry Localなら推論コストが端末側に固定されるため、スケールしても料金が膨らみません。逆に、利用頻度が低く散発的な用途では、モデルのダウンロードや端末リソースの確保というコストのほうが相対的に重くなる場合もあり、その見極めが必要です。

つまりFoundry Localは「クラウドAPIの完全な代替」ではなく、「端末上で完結させたほうが合理的な処理を切り出す」ための道具です。クラウドとローカルを使い分ける設計の引き出しが、また一つ増えたと捉えるのが実務的です。判断の軸は「データを外に出せるか」「常時接続が前提にできるか」「処理量が読めるか」の3点で、これらをチェックすれば多くのケースで方針が定まります。

導入の第一歩

Foundry Localは、Windows、macOS（Appleシリコン）、Linuxに対応しています。クロスプラットフォームで動くため、利用者の環境を選びにくい点も実務では扱いやすいところです。

SDKはC#、JavaScript、Rust、Pythonに対応しています。アプリケーションに直接組み込むのが基本的な使い方ですが、開発ワークフロー向けにオプションのWebサーバーとCLIも用意されています。LangChainのようなツールと統合したり、REST呼び出しで実験したりする場合は、OpenAI互換のローカルサーバーを立てる選択肢もあります。ただし、ほとんどの埋め込みシナリオでは、別サーバーのオーバーヘッドなしにインプロセスで推論を実行するSDK直接利用が推奨されています。

導入を検討する際は、まず小さなユースケースで試すのが定石です。たとえば社内文書の要約や、定型的な問い合わせ分類など、機密性が高く処理量が読める業務から始めると、料金とデータ保護の両面で効果を測りやすくなります。クラウドAPIで動かしているプロトタイプがあるなら、OpenAI互換APIを活かしてエンドポイントを差し替え、ローカル実行との比較検証から入るのも現実的な進め方です。

検証フェーズでは、開発ワークフロー向けに用意されているCLIとローカルサーバーが役立ちます。まずCLIでモデルを動かして応答品質や速度を確かめ、手応えがあればSDKでアプリケーションに組み込む、という段階的な進め方が取りやすくなっています。REST呼び出しで実験できるOpenAI互換のローカルサーバーを立てれば、既存のクラウドAPI向けのテストコードをほぼそのまま流用して、ローカル実行の挙動を比較できます。

検証で確認したい観点を整理しておきます。

・応答品質: 業務で扱う文章・データに対し、ローカルモデルの出力が実用に耐えるか
・処理速度: 想定する端末のハードウェアで、許容できるレイテンシに収まるか
・リソース消費: 推論中のメモリ・CPU/GPU使用率が、業務PCの常用に支障を出さないか
・モデル選定: カタログの中から、用途に対して最小限のサイズで要件を満たすモデルはどれか

これらを小さく回して確かめてから本番に展開すれば、端末ごとの挙動のばらつきというローカル実行特有のリスクを早期に把握できます。

本記事のまとめ

Foundry Localは、AI推論を端末上で完結させるMicrosoftのローカルAIソリューションです。ONNX Runtimeを基盤に、約20MBの軽量ランタイムでアプリにAIを組み込み、GPU・NPU・CPUを自動で使い分けます。

最大の特徴は、トークン課金がなく、入力データがデバイスの外に出ないことです。オフラインで動作し、Azureサブスクリプションも不要。機密データを扱う処理、回線が不安定な環境、コストを抑えたい大量処理、低レイテンシが求められる対話に向きます。一方で、多人数同時処理や最新の大規模モデルが必要な用途では、引き続きクラウドAPIやサーバー指向ランタイムが適しています。

クラウドとローカルのどちらか一方ではなく、処理の性質に応じて使い分ける。その判断の引き出しとして、Foundry Localを押さえておく価値は十分にあります。生成AIの実装が当たり前になるほど、コストとデータ保護の両立は避けて通れない課題になります。端末上で完結する選択肢を知っているかどうかが、設計の幅を大きく左右するはずです。まずは小さく試し、自分の業務に合う処理を見極めるところから始めてみてください。

クラウドのコスト管理や設計の考え方については、当サイトの他の記事もあわせてご覧ください。AI活用の幅広い実務については、姉妹サイトAIMasters.TOKYOでも解説しています。

AWS認定資格試験テキスト AWS認定クラウドプラクティショナー（山下光洋・海老原寛之著）

クラウドとローカルを使い分ける設計には、クラウド全体の基礎理解が前提になります。AWSの入門資格を題材に、クラウドサービスの基本概念を体系的に整理できる定番テキストです。