Microsoft Foundryとは｜Azure OpenAIとの違いと始め方

Microsoft Foundryとは｜旧Azure AI Foundryからの改称と中身の変化

結論から言えば、Microsoft Foundryはエージェント・モデル・ツールを単一のAzureリソースとして管理するための統合基盤です。RBAC、ネットワーク、ポリシーが1つのリソースプロバイダー名前空間に集約され、トレースや評価といった運用機能も最初から組み込まれています。

公式ドキュメントの定義はMicrosoft Foundry とは（Microsoft Learn）にまとまっています。

名称の変遷と、改称が意味するもの

名前は2回変わりました。Azure AI Studio から Azure AI Foundry へ、そして2025年11月のMicrosoft Ignite で Azure AI Foundry から Microsoft Foundry へ。改称の経緯と現在の位置づけはMicrosoft Foundry とは（Microsoft Learn）で確認できます。

注目すべきは「Azure」が名前から外れたことです。MicrosoftはFoundryを、Azure内の一機能にとどまらないエージェント開発基盤として打ち出しています。

案件の現場では、まだ旧称が混在します。募集要項に「Azure AI Foundry」と書かれている場合、多くはMicrosoft Foundryの旧称を指します。ただし、クラシックポータルや旧API前提の環境を指していないかは確認が必要です。

改称と同時に変わった5つの要素

ブランド名だけを追っていると、技術的な変更を見落とします。公式ドキュメントの対照表をもとに整理すると、次の5点が実務に効きます。詳細はMicrosoft Foundry 機能リファレンス（Microsoft Learn）とAzure OpenAI を Microsoft Foundry にアップグレードする（Microsoft Learn）もあわせて確認してください。

用語も入れ替わりました。スレッド・メッセージ・ラン・アシスタントという呼び方は、会話・アイテム・レスポンス・エージェントバージョンに置き換わっています。既存のAssistants APIベースのコードを引き継ぐ案件では、この用語差が設計レビューの論点になります。

ハブベースのプロジェクトを使っている環境は、引き続きFoundry（クラシック）ポータルからアクセスします。ただしMicrosoftは新ポータル側のFoundryプロジェクトを中心に機能追加を進めているため、新規構築では原則として新ポータルを優先して検討するのが安全です。

この章のミニFAQ

Azure AI Foundryという名前のサービスは消えたのですか。

消えていません。改称であり、リソースやデータが作り直されたわけではありません。ドキュメントやポータルの表記が順次Microsoft Foundryへ移行している段階です。

Windows AI Foundryとは別物ですか。

別物です。Windows AI FoundryはWindows端末上でモデルを動かすための仕組みで、本記事のMicrosoft Foundryはクラウド側のプラットフォームを指します。名前が似ているため、案件要件の読み違いに注意してください。

Azure OpenAI Serviceとの違い｜「モデルを呼ぶ」と「基盤で組む」

違いを一言でいえば、Azure OpenAI Serviceはモデルを呼ぶためのサービス、Microsoft Foundryはモデルを含めた開発・運用基盤です。公式ドキュメントは、Foundryリソースを「Azure OpenAIリソースに対する機能のスーパーセット」と表現しています。

対立する2択ではありません。Foundryの中にAzure OpenAIのモデルが入っている、という包含関係です。

機能差を表で押さえる

モデルカタログの規模も差があります。公式ドキュメントでは、Foundryのモデルカタログ全体として1万を超えるモデルにアクセスできると説明されています。ただし実際に利用できるモデルは、リージョン・契約・組織ポリシーによって異なります。

どちらで組むかの判断軸

判断はシンプルです。ツールもオーケストレーションも不要で、監査・評価・複数モデル管理の要件も薄いなら、Azure OpenAI単体で足りるケースが多いです。 逆に、ツール呼び出し・複数モデルの使い分け・評価・トレースのどれかが要件に入った時点で、Foundry側に寄せたほうが構成は素直になります。

例外もあります。社内のAzure Policyがモデルの種類を制限している組織では、Foundryへ広げても使えるモデルは増えません。この場合、移行の主目的はエージェントサービスと可観測性になります。

Azure OpenAI Service側の料金体系やモデル選定を詳しく知りたい場合は、Azure OpenAI Serviceとは｜料金・モデル選定と企業LLM導入案件の実務で整理しています。本記事はFoundryという基盤側に絞ります。

他クラウドの同種サービスと比べたい方は、Amazon Bedrockとは｜主要モデル・料金とAWS LLM開発案件とVertex AIとは｜主要モデル・料金とGoogle Cloud LLM開発案件もあわせてどうぞ。

Foundryで作れるもの｜3種類のエージェント

Foundry上のプロジェクトは、ほとんどがエージェントを中心に組まれます。エージェントとは、指示とツールを組み合わせ、依頼内容を推論して実際にアクションを実行するモデルのことです。

選択の軸はひとつ。実行方法をどこまで自分で制御するかです。宣言型からフルコードまでが一本の軸でつながっています。

プロンプトエージェント（宣言型・管理が最も少ない）

ポータルまたはSDKで、指示を書き、モデルを選び、ツールを紐づけるだけ。アプリケーションコードもコンテナも持たずに、Foundryがエージェントを実行します。

PoCの立ち上がりが速いのが利点です。要件が固まりきっていない初期フェーズでは、まずここから検証する進め方が現実的です。

音声ベースのプロンプトエージェント

リアルタイムの音声体験を作るための派生形です。モデル・指示・オーディオ設定・あいさつ文・ツールを構成し、Voice Live経由でエージェントに接続します。音声のオーケストレーションとエージェントのライフサイクルはFoundry側が持つため、音声基盤を自前でホストする必要がありません。

用途としては、コールセンター、受付、予約対応といったリアルタイム音声の体験が想定されます。ただし執筆時点でプレビュー扱いの関連機能もあるため、本番前提の提案では提供状況を必ず確認してください。

ホステッドエージェント（フルコード・最も制御できる）

自前のコードやフレームワークをコンテナとしてパッケージ化し、Foundryがマネージドエンドポイント・スケーリング・ID・可観測性を付けて実行します。公式ドキュメントでは、対応フレームワークの例としてMicrosoft Agent Framework、LangGraph、Semantic Kernelなどが挙げられています。実際の対応状況は利用時点のドキュメントで確認してください。

既存のエージェント実装を持ち込みたいチームには、この選択肢が噛み合います。LangGraphの設計思想についてはLangGraphとは｜LangChainとの違い・エージェント構築の基本を参照してください。

3種類の関係を整理すると、次のようになります。

宣言型で始めて、必要が出たらコードへ移る流れが公式にも推奨されています。最初からフルコードを選ぶ必要はありません。

この章のミニFAQ

プロンプトエージェントからホステッドエージェントへ、作り直しなしで移行できますか。

エージェントの定義（指示・ツール構成）は考え方を引き継げますが、実行形態が変わるためコードとデプロイ基盤は新規に用意します。段階移行を前提にするなら、ツール側のインターフェースを先に固めておくと差分が小さくなります。

エージェントを構成する要素｜モデル・ツール・知識

エージェントは3つの要素で動きます。モデル、ツール、知識です。ここを分けて理解しておくと、見積もりと障害切り分けがぶれません。

モデル｜Foundry Models カタログ

Microsoft、OpenAI、Anthropic、Meta などのモデルを、提供リージョンや契約条件の範囲内で横断的に比較・デプロイできます。デプロイの種類は、標準・グローバル・データゾーン・プロビジョニング済みスループット・バッチなどから選びます。

コストと品質で自動的に振り分けるモデルルーターや、デプロイを用意せずに試せるインスタントアクセスモデル（執筆時点でプレビュー）も用意されています。

ツール｜ツールボックスとMCP

組み込みツールには、Web検索、ファイル検索、コードインタープリター、関数呼び出し、OpenAPIツール、Azure Functions連携、Model Context Protocol（MCP）サーバー接続などがあります。ブラウザー自動化やComputer Use、画像生成は執筆時点でプレビューです。提供状況は機能・リージョン・APIバージョンで変わるため、本番利用の前に機能リファレンスで確認してください。

実務で効くのがツールボックスです。Web検索・ファイル検索・コードインタープリター・MCPサーバー・独自関数といったツール群を一度まとめておき、単一のマネージドMCPエンドポイント経由で複数のエージェントに配れます。認証・ガバナンス・バージョン管理が中央に寄るため、エージェントが増えてからの運用負荷が変わります。

AIエージェントにブラウザを操作させる論点はComputer Useとは｜AIエージェントのブラウザ操作と使いどころで扱っています。

知識｜RAG、Foundry IQ、メモリ

Azure環境では、Azure AI Searchのインデックスをエージェントの知識として使う構成が代表的です。ファイル検索用のマネージドベクターストアも用意されています。プライベートネットワークを含むナレッジベースを横断させる仕組みとしてFoundry IQがあり、セッションをまたいで記憶を持たせるメモリは執筆時点でプレビュー扱いです。

メモリの設計思想そのものはAIエージェントのメモリ設計｜短期記憶と長期記憶の実装パターンで整理しています。

機能ごとの提供状況は変動します。最新の状態はMicrosoft Foundry 機能リファレンス（Microsoft Learn）で確認するのが確実です。

料金はどこで発生するか

結論として、執筆時点の公式料金ページでは、Foundryネイティブエージェントの作成・実行そのものに追加料金はかからないとされています。 ただしモデル推論やツール、周辺のAzureサービスには別途課金されます。料金体系は改定されるため、見積もり時は必ず最新の料金ページで確認してください。

課金が立つのは、その周辺です。

さらに、Logic Appsコネクタ、Microsoft Fabricデータエージェント、SharePoint接続、Bingによるグラウンディング、Foundry IQ（Azure AI Search）、Speech・Language・Translatorといった周辺サービスは別課金です。詳細はFoundry Agent Service の料金（Microsoft Azure）を確認してください。

コストが跳ねやすい3つの条件

見積もりで外しやすいのは次の3点です。

1. ホステッドエージェントの常時起動。コンテナのvCPUとメモリは時間課金のため、トラフィックが薄い時間帯も費用が乗ります

2. ファイル検索の対象を広げすぎる。無料枠を超えると、保持しているぶんだけ日割りで積み上がります

3. Web検索を標準ツールとして全エージェントに付ける。利用頻度が高いエージェントほど検索トランザクションが増え、課金が膨らみやすくなります

通常、アップグレードしただけで既存のAzure OpenAI利用分の課金体系が大きく変わるわけではありません。費用増の主因は、新しく使い始めるエージェント機能・ツール・周辺サービスです。

Azure OpenAIリソースからFoundryへ移行する手順と落とし穴

条件を満たす既存のAzure OpenAIリソースは、新しいリソースを作り直さずにFoundryリソースへアップグレードできます。 エンドポイント、APIキー、作業状態はそのまま維持されます。ただしリージョン・ネットワーク構成・組織ポリシーによって手順や可否が変わります。

これはオプトインの機能で、問題があればロールバックも可能です。手順の詳細はAzure OpenAI を Microsoft Foundry にアップグレードする（Microsoft Learn）にあります。

維持されるもの・変わるもの

アップグレード後も維持されるのは、リソース名、Azureリソースタグ、ネットワーク構成、アクセスとIDの構成、APIエンドポイントとAPIキー、カスタムドメイン名、そしてファインチューニングジョブ・バッチ・保存済み補完などの既存状態です。

変わるのはリソースの種類とポータルの見え方です。既定のビューがプロジェクト単位になり、モデルカタログが広がり、従来のAzure OpenAIエンドポイントに加えてFoundryエンドポイントが並びます。

先に潰しておく4つの落とし穴

ここが実務で詰まる箇所です。

プライベートエンドポイントがあるリソースはポータルからアップグレードできません。 事前にプライベートエンドポイントを削除して後から作り直すか、BicepまたはTerraformでアップグレードを管理します。Terraformの場合、AzureRMプロバイダーの対応バージョン（公式手順では4.56.0以降が案内されています）を確認し、事前にplanで破壊的変更が出ないかを必ず確認してください。

DNSは3つのFQDNを解決できる必要があります。 Foundryリソースは、openai系・services.ai系・cognitiveservices系の3つのドメインで機能を公開します。Azure DNSなら各ドメインにゾーンを作り、カスタムDNSなら条件付きフォワーダーを用意します。

ワイルドカードのRBAC割り当てとAzure Policyを先に見直してください。 組み込みロールのうち「Cognitive Services ユーザー」は、アップグレード前はOpenAI機能のみでしたが、アップグレード後はFoundryの全機能に届きます。段階的にロールアウトする計画なら、割り当てとポリシー定義の更新が先です。

OwnerやContributorなどの管理プレーンロールだけでは、エージェント作成に必要なデータプレーン権限が不足する場合があります。 これらは主に管理操作用のロールで、エージェント作成などの開発アクションにはEntra IDのデータプレーンロール（Foundry User、Foundry Project Manager、Foundry Owner など）が必要です。なおこれらのロール名は以前「Azure AI ユーザー」等と呼ばれており、名称変更の反映中は旧名が表示される場合があります。

そのほか、Weights & Biases との構成はFoundryリソースでは未対応です。リージョンによって使える機能も異なります。

ロールバックの条件と、移行済みかの確認方法

ロールバックするには、先にプロジェクト・接続・Azure OpenAI以外のモデルデプロイを削除します。つまりFoundry固有の資産を作り込んだ後は、削除や再構成が必要になり、実務上はロールバックしにくくなります。 検証フェーズのうちに判断する前提で計画してください。

インスタンス上限にも注意が必要です。ロールバック時にサブスクリプションあたり・リージョンあたりのAzure OpenAIインスタンス数30を超えるとエラーになります。Foundry側（AIServices）の上限は100です。

既に移行済みかどうかは、リソースのプロパティにpreviousKindが存在するかで判別できます。誰がいつ実行したかは、Azureのアクティビティログで Cognitive Services アカウントへの書き込み操作を絞り込めば追えます。

この章のミニFAQ

アップグレードしたら、既存アプリのコードを書き換える必要がありますか。

エンドポイントとAPIキーは維持されるため、Azure OpenAIのAPIを叩いているだけのアプリは原則そのまま動きます。書き換えが要るのは、Assistants APIベースのエージェント実装をResponses APIへ寄せるときです。

フリーランス案件から見たMicrosoft Foundryの位置づけ

短答から書きます。公開案件を見るかぎり、Foundry単体を明示する案件はまだ限定的で、入り口は「Azureのクラウド案件」または「生成AI基盤構築」の枠になるケースが多いと考えられます。 Foundryの知識は、その枠の中で評価される要素として効きます。

以下の数字は、フリコンに掲載中の案件のうちスキルタグ「Azure」が付くものを2026年11月5日時点で集計した参考値です。Azure案件全体の集計であり、Foundry案件やAI専任案件の内訳ではありません。単価は掲載時点の月額提示単価をもとにした集計で、稼働率・商流・契約条件・成約単価は案件ごとに異なります。

注意：以下はMicrosoft Foundry案件の単価ではなく、Azureタグ案件全体の参考値です。

実際の募集内容を見ると、大半はクラウド移行、インフラ構築、データ分析基盤といった従来型のクラウドエンジニアリングです。生成AI基盤の構築・保守を明示した案件も見られますが、AI専任はまだ一部にとどまります。

非公開案件については、個別条件で上振れするケースがあります。公開案件の数字とは性質が違うため、同じレンジとして受け取らないでください。

自分がどのくらいの単価を狙えるか気になる方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。単価を体系的に上げる考え方はフリーランスエンジニアの単価相場と単価の上げ方にまとめています。

掲載中のAzure案件はAzureの案件一覧から確認できます。

Foundry関連で評価されやすいスキル

フリコン掲載のAzure関連案件や生成AI基盤案件の募集要件を見るかぎり、純粋なモデル調整より運用側の設計が問われる傾向があります。具体的には次の5つです。

• Entra IDとRBACを前提にした権限設計。エージェントにIDを持たせる構成の理解

• プライベートエンドポイントとDNSを含むネットワーク分離の設計

• トレース・評価を回す仕組みづくり。品質を数字で説明できること

• ツールボックスやMCPを使ったツールの共通化とバージョン管理

• コスト設計。どの機能でいくら出るかを見積もれること

権限設計の考え方はAIエージェントの権限設計｜最小権限とHuman-in-the-loopの実装で詳しく扱っています。

Microsoft Foundryの始め方｜まず試す最小手順とケース別の入り口

最初の一歩は共通です。そのうえで、立ち位置によって次に伸ばす方向が変わります。

まず試す最小手順

1. 検証用のFoundryリソース、またはアップグレード対象の検証用Azure OpenAIリソースを用意する

2. プロンプトエージェントを1体作る（指示を書き、モデルを選び、ツールを紐づける）

3. モデル推論、ツール呼び出し、トレースが想定どおり動くかを確認する

4. 本番に寄せる前に、権限（データプレーンロール）・ネットワーク・料金・プレビュー扱いの機能を確認する

ここまでを一周すると、移行の可否も見積もりの前提も自分で判断できるようになります。

すでにAzure OpenAIを使っている場合

検証用のリソースを1つ用意し、そこでアップグレードを試すところからです。本番リソースでいきなり実行しないでください。ロールバックはFoundry固有の資産を作る前にしか効きません。

試す順序としては、アップグレード、プロンプトエージェントを1体作成、トレースの確認、というミニマムな流れが扱いやすいでしょう。

AWSやGoogle Cloudが主軸の場合

BedrockやVertex AIなど、他クラウドの生成AI基盤との対応関係を押さえてから入ると、学習コストが下がります。Bedrockのエージェント基盤と比較したい場合はAmazon Bedrock AgentCoreとは｜構成・料金と本番運用の勘所が参考になります。

どのクラウドから手を広げるかで迷っている方はクラウド案件の参入順序｜AWS・Azure・GCPどれから取るかの判断軸もあわせて読んでください。案件そのものの選び方は案件の選び方｜フリーランスエンジニアが単価・稼働・スキルで決める優先順位で整理しています。

Microsoft 365寄りの業務自動化から来た場合

Copilot Studioとの住み分けを先に理解しておくと迷いません。大まかには、業務部門向けにローコードで作るならCopilot Studio、モデル・ツール・実行基盤をエンジニア側で細かく設計するならFoundry、という分担で考えると整理しやすいでしょう。実際にはCopilot Studio側からFoundryを呼ぶ構成もあるため、完全な二択ではありません。実際、Copilot Studio側のドキュメントでもFoundryは「フルコードのエージェント基盤」として位置づけられています。

Copilot Studioの料金や案件動向はCopilot Studioとは｜使い方・料金とAIエージェント案件にまとめました。

よくある失敗と参画前チェックリスト

失敗1｜旧称のまま情報収集して古い手順を踏む

Azure AI Foundry時代の記事のうち、ハブベースやクラシックポータル前提の手順をそのまま使うと、新ポータルの画面と噛み合わないことがあります。ドキュメントを開いたら、まずクラシック向けか新ポータル向けかを確認する癖をつけてください。

失敗2｜プライベートエンドポイントを残したままアップグレードを試す

ポータルからは実行できず、途中で止まります。ネットワーク分離が効いている環境では、DNSゾーンの追加とプライベートリンクエンドポイントの再作成までを1セットの作業として見積もるべきです。

失敗3｜Ownerロールを渡したのにエージェントが作れないと騒ぐ

管理操作とデータプレーンの操作は別系統です。切り分けを知らないと、権限周りの調査に半日溶けます。

失敗4｜PoCの料金感で本番を見積もる

プロンプトエージェントだけで検証したコストに、ホステッドエージェントのコンピュートとWeb検索のトランザクション課金が乗ると、PoC時より大きく増えることがあります。

参画前チェックリスト

案件に入る前、または提案の前に次を確認してください。

• 対象環境は新しいFoundryポータルか、Foundry（クラシック）か

• リソースはアップグレード済みか（previousKindの有無で判別）

• プライベートエンドポイントとカスタムDNSの有無

• 自分に割り当てられるのは管理ロールか、データプレーンロールか

• エージェントの実行形態は宣言型かホステッドか

• 使う予定のツール・知識機能のうち、プレビュー扱いのものはどれか

• 課金が立つ機能と、別課金になる周辺サービスの一覧

• 評価とトレースを誰が設計し、誰が見るのか

まとめ

Microsoft Foundryは、旧Azure AI Foundryの改称版であり、Azure OpenAIリソースの機能を包み込む開発・運用基盤です。モデルを呼ぶだけならAzure OpenAIで足り、エージェント・評価・トレースが要件に入るならFoundryへ広げる、という線引きで判断してください。

要点を整理します。

• 改称はブランド変更にとどまらず、リソースモデル・API・ポータルの整理をともなった

• Azure OpenAIとの関係はスーパーセット。条件を満たせば移行はエンドポイントとキーを保ったまま可能

• エージェントは宣言型・音声・フルコードの3種類。宣言型から始めて必要に応じてコードへ移す

• 執筆時点で課金が立つのはモデル推論、ホステッドエージェントのコンピュート、組み込みツール

• 移行の落とし穴はプライベートエンドポイント、DNS、ワイルドカードRBAC、ロール種別の4つ

• 案件の入り口はAzureクラウド案件。差がつくのは権限設計・ネットワーク・評価・コスト設計

次の一歩としては、検証用リソースでアップグレードを1回通し、プロンプトエージェントを1体作ってトレースまで確認するところまでをおすすめします。手を動かした範囲は、そのまま案件面談で話せる材料になります。

参照した一次情報は以下のとおりです。

• Microsoft Foundry とは（Microsoft Learn）

• Azure OpenAI を Microsoft Foundry にアップグレードする（Microsoft Learn）

• Microsoft Foundry 機能リファレンス（Microsoft Learn）

• Foundry Agent Service の料金（Microsoft Azure）