Microsoft Foundryとは|旧Azure AI Foundryから名前が変わった開発基盤
Microsoft Foundryとは、AIエージェントやAIアプリをAzure上で開発・運用するためのMicrosoftの基盤です。
エージェント、AIモデル、外部の機能を呼び出すツールを1つのAzureリソースで管理し、動作の記録(トレース)、監視、品質の評価をまとめて扱えます。アクセス権限、ネットワーク、利用ポリシーも同じ仕組みでそろえられるため、複数のチームがエージェントを作る組織でも管理の窓口を1つにできます。
関連記事:Copilot Studioとは?できること・Liteとの違い・無料範囲と管理の要点
名称の変遷|Azure AI StudioからMicrosoft Foundryへ
Foundryは、もともとAzureに分かれていたAI関連のサービスを1つにまとめた製品です。Microsoft Learnの解説では、以前の名称と現在の名称が次のように対応しています。
| 項目 | 以前の名称 | 現在の名称 |
|---|---|---|
| 製品ブランド | Azure AI Studio / Azure AI Foundry | Microsoft Foundry |
| AIの部品群 | Azure AI Services | Foundry Tools |
| ポータル | Foundry(classic) | Foundry |
| リソースの構成 | ハブ+Azure OpenAI+Azure AI Services | Foundryリソース(配下にプロジェクト) |
検索するとAzure AI FoundryとMicrosoft Foundryの記事が混在していますが、同じ製品の新旧の名前です。エージェントを動かす機能も、以前はAzure AI Agent Serviceと呼ばれ、現在はFoundry Agent Serviceとして案内されています。古い記事の手順は旧ポータル(classic)を前提にしている場合があるため、画面の名前が違うときは公開日を確かめると迷いにくくなります。
開発者向けの基盤だが、コードなしで作れる部分もある
Foundryの主な利用者は、Azureで仕組みを組み立てる開発チームです。作業の場は、ブラウザで操作するFoundryポータル、PythonやC#などのSDK、Visual Studio Codeの拡張機能から選べます。
一方で、指示文とモデルとツールを選ぶだけで動く「プロンプトエージェント」は、ポータル上でコードを書かずに作れます。ただし、その前提となるFoundryのリソースとプロジェクトの作成にはAzureのサブスクリプションと管理者権限が必要で、Microsoft 365の管理画面だけでは完結しません。この点が、Microsoft 365の延長で使えるCopilot Studioとの最初の違いです。
Microsoft Foundryでできること|Foundry Agent Serviceの仕組み
Foundryでできることの中心は、AIエージェントを作って動かすFoundry Agent Serviceです。これにモデル選択、ツール連携、評価と統制の機能が組み合わさっています。
Foundry Agent Serviceで作れる3種類のエージェント
Foundry Agent Serviceでは、どこまで自分で作り、どこからFoundryに任せるかで、エージェントの種類を選びます(2026年10月時点の公式の概要より)。
| 種類 | 作り方 | 自社で管理するもの | 費用の内訳 |
|---|---|---|---|
| プロンプトエージェント | 指示文・モデル・ツールを設定する | なし(Foundryが実行) | モデルの利用料+ツールの利用料 |
| 音声のプロンプトエージェント(プレビュー) | 音声の設定を加えて会話型にする | なし(Foundryが実行) | 音声処理とモデルの利用料 |
| ホステッドエージェント | 自社のプログラムをコンテナで渡す | エージェントのプログラム | モデルとツールの利用料+コンテナの計算資源 |
プロンプトエージェントから始めて、独自の処理が必要になった段階でホステッドエージェントへ移る進め方も案内されています。ホステッドエージェントは、LangGraphやMicrosoft Agent Frameworkなどで書いたプログラムをFoundryが実行し、拡張や認証の仕組みを引き受けます。
1万以上のモデルと外部ツールを選べる
モデルはMicrosoft、OpenAI、Anthropic、Metaなどの1万を超える選択肢から選べ、エージェントの設定を大きく変えずに切り替えられます。ツールはWeb検索、ファイル検索、プログラムを実行するコードインタープリター、MCP(AIと外部の仕組みをつなぐ共通規格)のサーバーなどを、ツールボックスとしてまとめて複数のエージェントで共有できます。
評価・監視・権限管理をまとめて持てる
作ったエージェントは、どの指示でどのツールを呼んだかを記録して確認でき、回答の品質を評価する仕組みもそろっています。エージェントごとにMicrosoft Entra IDの身元を持たせ、権限を絞ったうえで、Microsoft CopilotやTeamsへ公開することもできます。社内の閉じたネットワークで動かす設定もあり、データの扱いに厳しい要件がある業務でも設計の幅を確保できます。
Copilot StudioとMicrosoft Foundryの違いを比較
Copilot StudioとMicrosoft Foundryは、どちらもMicrosoftが提供するAIエージェントの作成環境で、作ったエージェントをTeamsやMicrosoft Copilotに公開できる点も共通しています。下表は、主な作り手、作り方、データの置き場所、課金の単位、向く業務の5観点で両者を整理したものです。自社でどちらを使うかは、作る人と保守する人が誰になるかから考えると判断しやすくなります。
| 観点 | Copilot Studio | Microsoft Foundry |
|---|---|---|
| 主な作り手 | 業務部門や情シスの担当者 | Azureを扱える開発チーム |
| 作り方 | 画面上でトピック・ナレッジ・コネクタを設定する | 設定で作るか、プログラムを書いてコンテナで動かす |
| データの置き場所 | Microsoft 365・Power Platformの環境 | 自社のAzureサブスクリプション(構成により自社リソース) |
| 課金の単位 | Copilot Credits(Microsoft 365 Copilotの利用者は一部対象外) | モデル・ツール・Azureリソースの従量課金 |
| 向く業務 | 社内の問い合わせ対応、申請受付、手順の案内 | 独自の処理、外部向けサービス、厳しいデータ要件 |
たとえば、社内規程を答えるエージェントならCopilot Studioで十分です。一方で、大量の文書を独自のルールで処理し、結果を自社のデータベースに保存する仕組みは、Foundryのほうが組み立てやすくなります。両者は二者択一ではなく、Copilot StudioのエージェントからFoundryのエージェントを呼び出す連携もプレビューで用意されています。
AIエージェントを「どう作り、どう育てるか」を、GiftX記事制作エージェントの実物で解説。
Copilot Studioだけで足りるか|FoundryやAzureが要る構成3通りの仕組み
AzureやFoundryが要るかどうかは、AIに任せたい処理をどこで動かすかで決まります。構成は大きく3通りで、下に行くほど自由度が上がる一方、社内で持つ仕組みも増えます。
構成1|Copilot Studioだけで作る
社内のナレッジを参照して答える、決まった手順で申請を受け付ける、といった業務はCopilot Studioだけで完結します。SharePointの文書やコネクタ経由の業務システムを使い、処理はMicrosoftのクラウド上で動くため、自社でサーバーを用意する必要がありません。費用はCopilot Creditsの消費が中心で、Microsoft 365の管理者が環境と利用量を管理できます。
構成2|Copilot Studio+Azure(FunctionsやContainer Appsで処理)
会話の入口はCopilot Studioに置いたまま、時間のかかる処理や独自の計算だけをAzure側のプログラムに任せる構成です。Azure Functions(必要なときだけ動くプログラムの実行環境)やAzure Container Apps(コンテナでプログラムを動かす環境)に処理を置き、Copilot Studioからはコネクタや外部ツールとして呼び出します。
文書の一括変換、複数システムのデータ突き合わせ、社外APIの呼び出しなどが典型です。利用者の画面は変えずに処理能力だけを足せる反面、Azure側のプログラムを書いて保守する人が社内か委託先に必要になります。
構成3|Microsoft Foundryを中心に作る
エージェント本体をFoundryで作り、モデルの選択、ツール、評価、監視までFoundry側で持つ構成です。
Copilot Studioにない独自のモデルや処理を使いたい場合、社外の顧客向けに提供する場合、会話履歴やファイルを自社のAzureリソースに保存する要件がある場合に向きます。作ったエージェントはMicrosoft CopilotやTeamsへ公開できるほか、Copilot Studioのエージェントから呼び出す形で社内の入口をそろえることもできます。設計、権限、ネットワーク、費用の監視まで自社で引き受ける範囲がもっとも広い構成です。
Foundryを含む3構成の費用と手間がかかる仕組み|Copilot CreditsとAzureの基盤費用
3つの構成は、費用のかかり方が違います。Copilot Studioは使った回数に応じたクレジット、Azure側は動かしている時間と確保している容量で費用が積み上がります。
Copilot Studio|クレジットとライセンス
Copilot Studioの費用は、Copilot Creditsという共通の単位で数えます。前払いパックは月額200ドルで25,000クレジットで、従量課金も選べます(2026年10月時点、出典: microsoft.com)。標準ハーネス(ルールに沿って動く実行方式)のエージェントでは、機能ごとに次のクレジットを消費します(2026年10月時点、出典: microsoft.com)。
| 機能 | 消費するクレジット |
|---|---|
| 決まった回答(作成者が用意した回答) | 1回あたり1 |
| 生成AIの回答 | 1回あたり2 |
| エージェントの処理(ツール呼び出しなど) | 1回あたり5 |
Microsoft 365 Copilotのライセンスを持つ社員が、Copilot ChatやTeams、SharePoint上でエージェントを使う場合、これらの回答はクレジットを消費しません(公正な利用の範囲内という上限つき)。逆に、ライセンスのない社員や社外の利用者が多いエージェントはクレジットの消費が増えます。前払い分を大きく超えるとエージェントが止まる仕組みもあるため、利用者の範囲から月の消費量を見積もっておく必要があります。
関連記事:Copilot Studioの料金|クレジット単価と購入方法、月額を試算する
Azure側|常時起動の稼働時間とプログラムの保守
構成2で処理を置くAzureのサービスは、動いている時間に応じて費用がかかります。Azure Container Appsは、利用がない間にゼロまで縮小する設定なら計算資源の費用はかかりませんが、応答を速くするために最低1台を起動し続ける設定では待機中も料金が発生します。Azure Functionsも、待ち時間を減らすために常に準備しておくインスタンスを持つと、その分が課金対象です。
費用以上に見落とされやすいのが保守の手間です。Azure Functionsでは旧来のプランが段階的に新しいプランへ移行しているように、実行環境の更新や言語のバージョン切り替えに合わせて、プログラムを直し続ける作業が発生します。処理を書いた人が異動すると止まってしまう構成にしないよう、保守の担当を最初に決めておくと安心です。
Foundry|standard setupのCosmos DBなどの基盤費用
Foundry Agent Serviceは、設定で作るエージェントの作成と実行そのものには追加料金がかからず、モデルの利用料とツールの利用料が別に発生します(2026年10月時点、出典: microsoft.com)。ただし、エージェントの環境構成を次のどちらにするかで、基盤の費用が変わります。
| 項目 | basic setup | standard setup |
|---|---|---|
| 会話履歴・ファイルの保存先 | Foundryが管理する領域 | 自社のAzureリソース |
| 自社に置くリソース | Foundryのリソースとモデル | 左に加えてAzure Storage・Azure AI Search・Azure Cosmos DB |
| 閉じたネットワークでの実行 | 対象外 | 自社の仮想ネットワークを持ち込む構成で対応 |
| 向く段階 | 試作・社内での検証 | データを自社で持つ要件がある本番運用 |
standard setupのCosmos DBは、合計で3,000 RU/s(1秒あたりの処理能力の単位)以上を確保しなければなりません。プロジェクトが増えると必要な処理能力も増え、2つのプロジェクトで新しい形式のエージェントを使う場合は10,000 RU/s以上が目安として示されています(2026年10月時点、出典: microsoft.com)。必要なリソースは、既存のものを指定しなければ構築時に自動で作られます。
Cosmos DBを処理能力の予約型で使う場合、実際の利用量に関係なく確保した分が時間単位で課金されます。Azure AI Searchも従来型の専用プランは、使っていない時間も含めてサービスがある間は費用がかかります。データを自社で持つ要件がなければbasic setupで始め、standard setupは要件が固まってから選ぶと、試行段階の固定費を抑えられます。
Copilot StudioかFoundryかを決める判断軸
どの構成にするかは、技術よりも業務と体制の条件で決まります。次の4つを確認すると、構成の候補が絞れます。
| 判断軸 | Copilot Studioで足りる目安 | AzureやFoundryを検討する目安 |
|---|---|---|
| 利用者 | Microsoft 365を使う社員 | 社外の顧客、ライセンスのない利用者が多い |
| 処理の重さ | 回答・案内・定型の申請 | 大量の文書処理、長時間の計算、独自のモデル |
| データの置き場所 | Microsoft 365内で完結してよい | 会話履歴やファイルを自社のAzureに残したい |
| 作る人と直す人 | 担当部門と情シスで設定できる | Azureのプログラムを保守できる人がいる |
オフィス系7職種のAI利用者669人の調査では、生産性向上を明確に実感した割合が、チャット中心の利用層14.3%に対しAIエージェント利用層54.3%。約3.8倍の差が見られました。
まだFoundryに進まなくてよいケース
4つの判断軸がすべて左側に当てはまるなら、AzureやFoundryはまだ必要ありません。社内向けの問い合わせ対応や手順の案内は、Copilot Studioだけで公開と運用まで進められます。とくに、Azureのプログラムを保守できる人がいない段階でFoundry中心の構成を選ぶと、作った後の修正が外部頼みになり、改善の速度が落ちます。
小さく始めてFoundryへ広げる導入ステップ
構成は最初から決め打ちせず、小さく始めて必要になった部分だけを広げると、費用と手間の両方を抑えられます。GiftXの調査では、生成AIを使うビジネス職のうち、質問や文章作成のようなチャットでの利用にとどまる人が約7割を占め、複数の工程をAIエージェントに任せている人は約1割でした。詳細な調査データは「ビジネス職生成AI活用実態調査(2026年版)」にてご覧ください。
ステップ1|Copilot Studioで1業務のエージェントを作る
最初は、社内の問い合わせ対応や手順の案内など、回答の正しさを確認しやすい1業務を選び、Copilot Studioだけで作ります。この段階で、クレジットの月間消費量と、誰が回答の誤りを直すかの運用を確かめます。Copilot Studioにはルールに沿って動く標準ハーネスと、目標から手順を組み立てて複数のツールをまたぐGitHub Copilotハーネスがあり、業務の複雑さで選びます。どちらでも足りない処理が出てきたかどうかが、次のステップに進む目安になります。
関連記事:Copilotエージェントの作り方|Copilot StudioとAgent Builderで作る5ステップ
ステップ2|重い処理だけをAzureに切り出す
運用するうちに、Copilot Studioだけでは時間がかかる処理や、独自の計算が必要な処理が見えてきます。その処理だけをAzure FunctionsやContainer Appsに移し、利用者の入口はCopilot Studioのまま残します。最初に任せる業務の切り分け方は「AIエージェントの作り方と育て方」にまとめています。
ステップ3|要件がそろったらFoundryに広げる
社外への提供、独自のモデル、データを自社のAzureに保存する要件がそろった段階でFoundryを検討します。まずbasic setupのプロンプトエージェントで動作を確かめ、データの保存要件が確定してからstandard setupへ移ると、Cosmos DBなどの固定費が先に膨らむのを避けられます。
AzureやFoundryでAIエージェントを広げるときに陥りがちな3つの落とし穴
Copilot StudioとAzureを組み合わせる構成は自由度が高い分、始め方を誤ると費用と手間だけが先行します。よくある3つの落とし穴と、その避け方を整理します。
落とし穴1|最初からFoundry中心で全部を作ろうとする
いきなりFoundry中心の構成で複数業務をまとめて作ると、standard setupの基盤費用と保守の体制が先に必要になります。どの業務で効果が出るかを確かめる前に固定費が積み上がり、見直しの判断も遅れます。
落とし穴2|全社のAI基盤構想から入って手が止まる
全社共通のAI基盤を設計してから個別の業務に進めようとすると、要件の調整だけで時間が過ぎがちです。基盤の要件は、実際に動かした業務から逆算したほうが決めやすくなります。
落とし穴3|既製のチャットで済ませて業務に組み込めない
Copilot Chatのような既製のチャットだけで済ませると、自社の手順やシステムに沿った処理まではつながりません。質問に答える段階から、申請や登録まで任せる段階へ進まないまま、利用が個人の工夫にとどまります。
スモールスタートで1業務をAIエージェントに任せる
落とし穴を避けるには、まず1業務をAIエージェントに任せ、必要になった処理だけをAzureやFoundryに広げることがポイントです。Copilot Studioで始めた1業務の運用データが、次にどこへ投資するかの根拠になります。
GiftXでは、こうしたスモールスタート前提のAIエージェント構築を1業務単位から伴走支援しています。詳細はAIエージェント構築支援サービスをご覧ください。
Microsoft Foundryに関するよくある質問
Azure AI FoundryとMicrosoft Foundryは別の製品ですか?
同じ製品です。Azure AI StudioからAzure AI Foundryを経て、現在はMicrosoft Foundryという名前で提供されています。エージェントを動かすAzure AI Agent Serviceも、現在はFoundry Agent Serviceと呼ばれています。
Microsoft Foundryは無料で使えますか?
設定で作るエージェントの作成と実行には追加料金がかかりませんが、モデルの利用料、ツールの利用料、ホステッドエージェントの計算資源は課金されます。standard setupを選ぶと、Cosmos DBやAzure AI Searchの費用も別にかかります。
エンジニアがいなくてもMicrosoft Foundryは使えますか?
プロンプトエージェントはポータル上でコードを書かずに作れます。ただし、Azureのリソースや権限の設定、ほかの仕組みとの連携には、Azureを扱える担当者が必要です。
Copilot StudioからMicrosoft Foundryのエージェントを呼び出せますか?
プレビューの機能として呼び出せます。Foundry側でエージェントの接続方式を有効にする設定が必要で、2026年10月時点ではプログラムからしか設定できません。
Microsoft 365 CopilotのライセンスがあればCopilot Studioは無料ですか?
ライセンスを持つ社員がCopilot ChatやTeams、SharePointでエージェントを使う場合、回答の多くはクレジットを消費しません。社外の利用者やライセンスのない社員が使う分と、利用者の操作以外のきっかけで動くエージェントフローはクレジットの対象です。
まとめ
Microsoft Foundryは、旧Azure AI Foundryから名前が変わった、AIエージェントとAIアプリの開発基盤です。設定だけで作るエージェントから自社のプログラムを動かすエージェントまで扱え、評価や権限管理もまとめて持てます。
一方で、社内向けの問い合わせ対応や申請受付であれば、Copilot Studioだけで足りる場面が多くあります。AzureやFoundryが要るのは、重い処理、社外への提供、データを自社のAzureに保存する要件が出てきたときです。費用はCopilot Creditsの消費に加えて、Azure側の常時起動の計算資源やstandard setupのCosmos DBなど、使っていない時間にもかかる部分があります。まずCopilot Studioで1業務を動かし、必要になった処理から順にAzureへ広げると、費用と手間を抑えながら構成を決められます。
Copilot StudioとAzureでのAIエージェント構築をご検討の方へ
本記事で紹介したCopilot StudioとMicrosoft Foundryの使い分けを踏まえて、自社の業務でもAIエージェントの構築を具体的に進めたい・相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら