Microsoft Foundryとは？できることや使い方、料金を徹底解説！

Microsoft Foundry（旧Azure AI Foundry）は、モデル・エージェント・ナレッジ・評価・デプロイを1つのプラットフォームで扱えるMicrosoftのAI開発統合基盤です。

Build 2026（2026年5月）でブランド名が「Microsoft Foundry」に整理され、Foundry Agent Serviceは2026年3月にGA、Foundry IQは2026年6月にGAと、いよいよ「試作」から「本番運用」へと軸足が移っています。

本記事では、Microsoft FoundryのレイヤーとMicrosoft IQファミリーの中での位置づけ、Agent Service・Foundry IQ・モデルカタログ・Model Router・Foundry Localの主要機能、始め方と使い方、セキュリティ設計、料金体系、Amazon Bedrock・Google Vertex AIとの違い、活用事例まで、2026年6月時点の最新情報で体系的に解説します。

Microsoft Foundryとは？Microsoftの統合AI開発プラットフォーム

Microsoft Foundry（旧Azure AI Foundry）は、モデル・エージェント・ナレッジ・ツール・メモリ・評価・ガードレール・監視・デプロイを1つのプラットフォームで扱えるMicrosoft純正のAI開発統合基盤です。

2026年5月のMicrosoft Build 2026でブランドが「Azure AI Foundry」から「Microsoft Foundry」へと整理され、Azureの傘下にあったAI開発統合プラットフォームが、Microsoft全体の「AI開発の入口」として位置づけ直されました。

Microsoft Foundryが他のAzure系AIサービスと根本的に違うのは、個別サービス（Azure OpenAI Service・Azure AI Search・Azure AI Content Safety等）を束ねるだけでなく、エージェントの実行ランタイム（Foundry Agent Service）と知識基盤（Foundry IQ）まで含めた「AIファクトリー」として設計されている点です。

つまり開発者は、モデル選定からエージェント設計、知識接続、評価、本番デプロイ、運用監視までを別々のサービスを行き来せず、1つのポータルで完結させられます。

Microsoft Foundryのレイヤー構造

Microsoft Foundryは単一機能のサービスではなく、AI開発のライフサイクル全体をカバーする複数レイヤーの集合体です。

以下の表で、Microsoft Foundryを構成する主要レイヤーを整理しました。

レイヤー	主な構成要素	役割
ポータル	Microsoft Foundryポータル・VS Code拡張	開発・運用の統一インターフェイス
モデル	Foundry Models（11,000以上のカタログ）・Model Router	モデル選定・動的振り分け・デプロイ
エージェント	Foundry Agent Service（GA）	エージェントの構築・実行・スケーリング
ナレッジ	Foundry IQ（GA）	社内データ横断のRAG基盤
評価・監視	Foundry Evaluations・Foundry Observability	品質評価・本番監視・トレース
デプロイ・実行	Azure Cloud・Foundry Local・Azure Local	クラウド／オンデバイス／ソブリン環境への展開
ガードレール	Azure AI Content Safety・Guided Guardrails	有害コンテンツ検出・運用ポリシー

このレイヤー構造から分かるのは、Microsoft Foundryは「個別サービスのバンドル」ではなく、レイヤー間のデータ・統制を一気通貫で扱う設計になっているという点です。

たとえば、モデルカタログでデプロイしたモデルに対してFoundry IQでRAGを接続し、その評価をFoundry Evaluationsで継続的に計測し、本番運用をFoundry Observabilityでトレースするまでが、ポータル内でつながります。

「Azure AI Foundry」から「Microsoft Foundry」へ：何が変わったか

Microsoft Foundryのブランド変遷を理解しておくと、過去資料との照合がスムーズになります。

時期	サービス名	主な位置づけ
2023〜2024年	Azure AI Studio	Azure上の生成AIアプリ開発ツール
2024年11月	Azure AI Foundry	Studioに運用機能を統合した統合プラットフォーム
2025年〜2026年	Microsoft Foundry	Microsoft全体のAI開発入口として再定義

Build 2026でのブランド整理に合わせて、Foundry RBACロールも従来の「Azure AI User／Owner／Account Owner／Project Manager」から「Foundry User／Owner／Account Owner／Project Manager」へ改名されました（公式ドキュメントの注記による）。

ロールID自体は変わっていないため既存のRBAC設定は引き続き有効ですが、Azure Portal上の表記が新旧混在することがあります。

ここで重要なのは、ブランド名が変わってもAzureインフラ上で動く事実は変わらないという点です。Microsoft Foundryの裏側は引き続きAzure OpenAI Service・Azure AI Search・Azure OpenAI Service・Cognitive Servicesなどの既存資産を使い続けているため、既存のAzure環境からの移行コストは限定的です。

Microsoft IQファミリーの中での位置づけ

Microsoft Foundryの「ナレッジ層」はFoundry IQですが、Microsoftは2025年Igniteと2026年Buildにかけて、Microsoft IQというナレッジファミリーを打ち出しています。

以下の表で、Microsoft IQに含まれる主要なIQの守備範囲を整理しました。

IQ	主な接続先	想定利用者
Foundry IQ	Foundry Agent Service・カスタムエージェント	開発者・AIアーキテクト
Work IQ	Microsoft 365 Copilot・Teams・SharePoint・OneDrive	業務利用者（Copilot経由）
Fabric IQ	Microsoft Fabric・データエージェント	データアナリスト・データエンジニア
Web IQ	Web上の公開情報をエージェントから取得	エージェント開発者（外部知識の参照）

つまり、Microsoft IQは「開発者が作るエージェント（Foundry IQ）」「業務利用者が触るCopilot（Work IQ）」「データ分析（Fabric IQ）」「Web上の公開情報（Web IQ）」を束ねるナレッジ層で、それぞれ別の利用者層・接続先に最適化された設計になっています。Foundry IQとWeb IQは公式ブログで「Microsoft IQに含まれる」と明示されており、Foundry IQ自体もWork IQ／Fabric IQ／Azure SQL／File Search／MCPを横断的に束ねる構造です。

本記事ではFoundryを扱う開発者視点で、後段の専用セクションでFoundry IQを詳述します。Work IQ・Fabric IQ・Web IQの詳細は個別記事や公式ブログを参照してください。

---

Microsoft Foundryでできること——5つの代表ユースケース

Microsoft Foundryは複合的なプラットフォームのため、「結局何に使えるのか」が分かりにくい側面があります。

ここでは、実際に企業導入で採用される代表的な5つのユースケースを整理し、それぞれFoundryのどの構成要素が対応するかを明確にします。

代表的な5つのユースケース

以下の表で、ユースケースと対応するFoundry機能を整理しました。

ユースケース	Foundryでの対応機能	想定される効果
社内ナレッジに基づくRAGエージェント	Foundry IQ＋Foundry Agent Service	SharePoint・OneLake・Web横断の社内Q&A、回答の根拠提示
マルチエージェントによる業務自動化	Foundry Agent Service（マルチエージェントワークフロー・A2A）	営業/経理/HR等の複数業務をエージェント連携で自動化
モデル選定とコスト最適化	モデルカタログ＋Model Router	用途・コスト・品質に応じた動的振り分け、トークンコスト削減
生成AIアプリの品質評価・本番監視	Foundry Evaluations＋Observability	デプロイ前評価、Azure Monitor連動の本番トレース・品質計測
オンデバイス・ソブリン環境でのAI実行	Foundry Local／Foundry Local on Azure Local	機密データを外部に出さないオフライン・国内完結のAI推論

このうち、社内RAGエージェントとマルチエージェント自動化は、Foundryのなかで最も問い合わせが多い2大ユースケースです。Foundry IQとAgent Serviceが両方GAに到達した2026年6月以降は、PoCで止まらず本番運用まで一気に組める設計が現実的になりました。

逆に、モデル選定の自動化（Model Router）やソブリン実行（Foundry Local on Azure Local）は、企業の事情によって導入時期が大きく変わる領域です。「とりあえずチャットボットを作る」段階の組織には早すぎる選択肢ですが、複数のフロンティアモデルを使い分ける段階に入った組織には強力な差別化要素になります。

2026年6月時点の主要機能の提供状況

Microsoft Foundryは新機能のリリースペースが速く、GA／プレビュー／発表ベースの混在が読者の混乱の原因になりやすい領域です。

以下の表で、2026年6月時点で利用可能な主要機能の提供状況を整理しました。

機能	状態	主な対応リージョン
Foundry Agent Service（サービス本体）	GA（2026年3月）	Japan East含む6リージョン以上
Hosted Agents	プレビュー（2026年7月初旬GA予定）	Foundry対応リージョン
Foundry IQ（Core）	GA（2026年6月）	基盤のAzure AI Search／Azure OpenAI in Foundry Modelsのリージョン可用性に依存（要リージョン別確認）
Foundry IQ Serverless（Developer Tier）	プレビュー	一部リージョン
Voice Live（Prompt Agents）	GA	主要USリージョン
Voice Live（Hosted Voice Agents）	プレビュー	主要USリージョン
A2A受信エンドポイント	プレビュー	Foundry対応リージョン
Foundry Local（macOS・Windows）	一般提供	クライアント端末
Foundry Local on Azure Local	発表（2026年5月Build）	順次拡大
Model Router	GA	East US 2 / Sweden Central（Claude／DeepSeek／xAI系のRouter対応はプレビュー）
Customer-Managed Key暗号化	一部GA・一部プレビュー（cross-tenant CMKはプレビュー）	Foundry対応リージョン
Microsoft Purview連携（感度ラベル監査・SharePoint権限同期）	プレビュー	Foundry対応リージョン
Guided Guardrails	プレビュー	Foundry対応リージョン

プレビュー段階の機能はSLA非対象・予告なき仕様変更が原則です。本番ワークロードに組み込む場合は公式の「What's new」ページで最新状態を確認することを推奨します。

ここで特に注意したいのは、**Foundry Agent Service自体はGAだがHosted Agentsはまだプレビュー（2026年7月初旬GA予定）**という点です。Voice Liveも音声インターフェイスを直接呼ぶPrompt AgentsはGA、フルマネージドで運行するHosted Voice Agentsはプレビューと、機能単位でGA/プレビューが分かれます。本番組込み時は機能単位での状態確認が必須です。

---

Microsoft Foundry Agent ServiceでできるAIエージェント開発

Microsoft Foundry Agent Serviceは、Microsoft FoundryのなかでもAIエージェントの構築・デプロイ・スケーリングを担う中核機能です。

2026年3月16日にGA（一般提供）に到達し、エンタープライズの本番運用に耐える設計が標準で利用できるようになりました。詳細はFoundry Agent Service GA発表ブログで公開されています。

本セクションでは、GAで使える機能・マルチエージェント設計・対応リージョンを整理します。

2026年3月GAで使えるエンタープライズ機能

Foundry Agent ServiceのGAリリースで特に重要な機能は、Responses API互換とprivate networkingの2点です。

機能	概要
Responses API互換	OpenAI Responses APIとワイヤ互換のランタイム。既存のOpenAI SDKコードを最小限の変更でFoundryに移行可能
BYO VNet・私設網接続	自社VNetを持ち込み、エージェント通信がパブリックインターネットを経由しない
マルチモデル対応	OpenAI（Azure OpenAI）・Anthropic Claude・DeepSeek・xAI Grok・Meta Llama・LangChain・LangGraphに対応
MCP認証拡張	Key-based・Entra Agent Identity・Managed Identity・OAuth Identity Passthroughの4方式
Voice Live Prompt Agents（GA）	リアルタイム音声対話（speech-to-speech）の最速導入経路
Voice Live Hosted Voice Agents（プレビュー）	フルマネージドの音声エージェント運行（意味的VAD・ノイズ抑制・割り込み対応）
Hosted Agents（プレビュー・2026年7月初旬GA予定）	マネージドランタイム・サンドボックス・状態保存・耐久ファイルシステムを内包したエージェント実行環境
Evaluations GA	標準・カスタム評価器を本番運用に連続適用。Azure Monitor連携

表のなかで実務上のインパクトが大きいのがResponses API互換です。これは、すでにOpenAI APIで開発を進めているチームが、Foundryのエンタープライズセキュリティ層（VNet・MCP認証・監視）を後付けで取り入れられることを意味します。

つまり、「OpenAIで作って、企業要件のためにFoundryに乗せ換える」というシナリオがコード変更を最小化したまま成立します。

実際の運用画面では、エージェント一覧から個別エージェントの設定・ツール接続まで、ポータル内で完結できます。

エージェント設定画面では、モデル選定・システムプロンプト・接続ツール（MCPサーバー、Azure AI Search、Fabric IQ等）をGUIで設定できます。

マルチエージェントワークフローとVoice Live

Foundry Agent Serviceは単一エージェントだけでなく、複数エージェントが協調するマルチエージェント設計をネイティブにサポートします。

ワークフロー設計は3つの方法があります。

• Foundryポータルのビジュアルエディタ
  複数のエージェントをノードとしてキャンバスに配置し、データの流れを線で結ぶGUI。技術者でなくても全体像を把握しやすい
  
  

• VS Code拡張＋コード
  プログラマブルにマルチエージェントを設計したい場合、VS Code拡張からPython/TypeScriptで定義できる
  
  

• A2Aエンドポイント（プレビュー）
  Foundryエージェントが他エージェントから呼び出される受信エンドポイント。エージェント間の協調を疎結合に組める

Voice Liveはリアルタイム音声インターフェイスを統合する機能で、カスタマーサポート・コールセンター・音声アシスタント等のユースケースで活用されます。

ここで重要なのは、Voice Liveが2層構造で提供されているという点です。リアルタイム音声を最速で導入したい場合のPrompt AgentsはGAになっており、運用に乗せる設計が確立しています。一方、フルマネージドでオーケストレーションまで任せられるHosted Voice Agentsは現時点でパブリックプレビューで、本番運用に組み込む前に提供状態・SLA・制限事項を確認する必要があります。

意味的な音声活動検出・発話終了検知・ノイズ抑制・割り込み（barge-in）対応がフルマネージドで提供されるため、自前で音声処理パイプラインを組まずに済む点はどちらの層でも共通です。

対応リージョン——Japan Eastを含む6リージョン以上で利用可能

ホスト型エージェントは、East US・North Central US・Sweden Central・Southeast Asia・Japan East を含む6リージョン以上で利用可能になっています。

日本企業にとってHosted AgentsをJapan Eastに配置できる点は実務上の大きな安心材料です。ただし、これでデータ所在地が国内に固定されるわけではありません。Foundryではモデル推論はデプロイメント種別（Global／Data Zone／Regional）によって処理リージョンが変わるため、Hosted AgentsをJapan Eastに置いても、内部で呼び出すモデルの推論が他リージョンで処理される可能性があります。

加えて、Foundry IQが参照するデータソースや外部ツール接続も、それぞれ独立したリージョンに存在する場合があります。国内完結の運用要件がある場合は、Hosted Agentsの配置先・モデルのRegional deployment可否・データソースのリージョンを個別に確認する必要があります。詳細は公式の提供リージョン一覧で確認してください。

【関連記事】
Microsoft Foundry Agent Serviceとは？使い方・料金を解説

---

Foundry IQ：エージェントの知識基盤

エージェントを実用レベルで動かすには、「自社の文書・データに基づいて回答する」というRAG（Retrieval-Augmented Generation：検索拡張生成）の仕組みが不可欠です。

Microsoft FoundryではFoundry IQがこの役割を担い、2026年6月2日のBuild 2026でGAに到達しました。詳細はFoundry IQ公式ブログで公開されています。

本セクションでは、Foundry IQの統合グラウンディング設計、対応データソース、CoreとServerlessの使い分けを整理します。

統合グラウンディングAPI——複数データソースを1つのエンドポイントで束ねる

Foundry IQの最大の特徴は、複数のデータソースを1つの取得（retrieval）エンドポイントで束ねる点です。

従来のRAG実装では、SharePoint用にコネクタを書き、OneLake用に別のコネクタを書き、Webデータ用にまた別のクロウラーを設計する……という個別接続が必要でした。Foundry IQは、これらを単一のSLA保証付きAPIに統合します。

実装の流れは次のとおりです。

• 自社の対象データソース（SharePoint、OneLake、Azure Blob、Webサイト等）をFoundry IQに登録する
• ナレッジベース（Knowledge Base）として束ねる
• エージェントから Foundry IQ の grounding API を呼ぶだけで、複数ソース横断のRAGが成立する
  
  

このとき、エージェントが直接データソースを叩くわけではなく、Foundry IQがユーザー権限・データ分類に基づくフィルタリングを自動で適用します。つまり「Aさんが見られないSharePointドキュメントはエージェント経由でも回答に含まれない」という基本的なアクセス制御が、特別な実装なしで実現します。

加えてGAでは、エージェント取得参照・出力／アクティビティログ、Foundry IQ MCPサーバー（マルチエージェント互換）、ドキュメントレベルのセキュリティ、クロスソースランキングが標準で利用できます。

GA対応データソースとプレビュー段階のデータソース

Foundry IQはGA時点ですべてのデータソース接続をフルサポートしているわけではありません。

以下の表で、データソースの提供状況を整理しました。

データソース	状態	主な用途
Azure Blob Storage	GA	一般ドキュメント・PDF・テキスト
Search indexes	GA	既存のAzure AI Search資産との統合
Web content	GA	外部Webサイトのクロウル
OneLake	GA	Microsoft Fabric統合データ
Work IQ（メール・会議・Teamsメッセージ）	プレビュー	Microsoft 365資産との連携
Fabric IQ（データエージェント・オントロジー）	プレビュー	データウェアハウスとの連携
File Search	プレビュー	直接アップロードしたファイル
Azure SQL	プレビュー	リレーショナルデータ
MCP Server接続	プレビュー	外部システムとのMCP統合

本番運用に乗せる場合、プレビュー段階のデータソースはSLA非対象になることに注意が必要です。Work IQやAzure SQLはまだプレビューなので、GA待ちが前提のシナリオでは別の経路（直接Microsoft Graph・Azure Data Factory経由等）で接続するか、プレビューのまま試験的に進めるかを判断します。

【関連記事】
Foundry IQとは？仕組みや使い方、料金体系を解説

Foundry IQ Core（GA）とServerless（Developer Tier・プレビュー）の使い分け

Foundry IQには、本番運用向けのCoreと検証向けの**Serverless（Developer Tier）**の2形態があります。

• Foundry IQ Core: 2026年6月Build 2026でGA。SLA保証付き、Azure AI Foundry本体に含まれる
• Foundry IQ Serverless（Developer Tier）: プレビュー提供。検証・小規模利用向けの軽量プラン
  
  

実務的には、**「PoC段階はServerless（Developer Tier）で検証→本番運用でCoreのGA版へ移行」**という流れが現実的な使い分けになります。

Foundry IQ Serverlessの具体的な料金（コンピュート単価・ストレージ・インデックス上限）は、後述の「Microsoft Foundryの料金体系」セクションで他の課金モデルとあわせて整理しています。

---

モデルカタログとModel Router——11,000以上のモデルから最適な1つを選ぶ

Microsoft Foundryの大きな価値の1つが、主要なフロンティアモデルから国内特化モデル、軽量SLMまでを1つのカタログから扱える点です。

公式のFoundry Modelsカタログでは11,000以上のモデルが登録されており、UI上で性能・コスト・ライセンス条件を比較してデプロイできます。

本セクションでは、主要モデルラインアップ、Model Routerの動的振り分け、Foundry Localによるオンデバイス実行を整理します。

主要モデルラインアップ——OpenAI・Anthropic・Google・Microsoft純正

カタログ全部を網羅するのは現実的でないため、2026年6月時点で代表的なモデル群を整理します。

ベンダー	代表モデル	主な用途
OpenAI	GPT-5.5・GPT-5.4 pro/mini/nano・GPT-4o	汎用高性能推論・コーディング
Anthropic	Claude Opus 4.7・Sonnet 4.6・Haiku 4.5	エージェント運用・複雑なツール呼び出し
Google DeepMind	Gemma 4	マルチモーダル入力・256K長文
Microsoft純正（MAI）	MAI-Image-2.5-Flash／MAI-Image-2.5／MAI-Image-2e／MAI-Image-2／MAI-Voice-1／MAI-Transcribe-1（画像系はプレビュー）	画像生成・音声合成・音声認識
Meta	Llama 3.3 70B	オープン重み・カスタマイズ前提
DeepSeek・xAI（Grok）	DeepSeek-V3.2・grok-4	コスト効率・思考過程の透明化

カタログの全体画面・個別モデルの詳細画面・デプロイ画面はそれぞれ独立したビューで提供されており、ベンチマーク比較・価格比較を見ながらデプロイ判断できます。

マルチベンダー対応の意味は、単に選択肢が広いという話ではありません。同じFoundryポータルから複数のベンダーのモデルを呼び出せるため、ベンダーロックインを避けつつエンタープライズ統制を一元化するという、企業AI導入の難所を解決します。

Model Router——Quality／Cost／Balancedで動的にモデルを選ぶ

11,000以上のモデルから1つを選ぶのは、開発者にとっても運用者にとっても判断コストが高い作業です。Microsoft FoundryはModel Routerでこの判断を自動化します。

Model Routerは、プロンプトの内容をリアルタイムに分析し、用途・コスト・品質のバランスに基づいて最適なモデルへ動的に振り分けます。動作モードは3つです。

• Quality
  品質最優先。高度な推論が必要な処理に向くフロンティアモデル（GPT-5.5、Claude Opus 4.7等）を優先選択
  
  

• Cost
  コスト最優先。軽量モデル（Haiku 4.5、GPT-5.4-mini、Llama系等）を優先選択
  
  

• Balanced
  標準。品質とコストの均衡を取る（デフォルト）

Model Routerは現時点でEast US 2とSweden Centralの2リージョンにデプロイ可能で、GPT-5.5・GPT-5.2・GPT-4o・GPT-4o-mini などGPT系を中心に対応が進んでいます。Claude Opus 4.7・Claude Sonnet 4.5・Claude Haiku 4.5・DeepSeek-V3.2・grok-4などのClaude／DeepSeek／xAI系モデルへのRouter対応はプレビュー注記付きで、Claude系は別途モデルデプロイが必要な点にも注意が必要です。対応モデル・対応リージョンは継続拡張中のため、利用前に公式のModel Routerドキュメントで最新状態を確認することを推奨します。

これは「最新フロンティアモデルが出たら自分の実装を書き換える」というオペレーションを、Foundry側がルーティングロジックで吸収してくれることを意味します。

Foundry Local——エッジ・オフラインでもFoundryのワークロードを実行する

クラウドだけがMicrosoft Foundryの実行環境ではありません。Foundry Localは、macOSとWindows上でAIモデルをオンデバイス実行できるランタイムです。

ONNX Runtimeをベースにしており、CLIから利用可能なモデル一覧を閲覧してダウンロード・実行できます。

実務的に活躍する場面は次のような状況です。

• ネットワーク制約のある工場・現場端末でのAI推論
• 機密データを外部に送れない研究開発環境
• レイテンシ要件が厳しいリアルタイム処理
• 移動・出張中のオフラインでもAIアシスタントを使いたいケース
  
  

加えてBuild 2026では、Foundry Local on Azure Localとして、データセンター内に閉じた環境でFoundryのワークロードを実行する「ソブリンAI」の構成も発表されています。これにより、政府・防衛・医療など、データの国外送出が許されない領域でもFoundryを活用する選択肢が生まれました。

---

Microsoft Foundryの料金体系

Microsoft Foundryは、利用するAzureサービス（Azure OpenAI、Foundry Tools、AI Search等）の組み合わせで料金が決まる従量課金型のサービスです。

ここで重要なのは、Microsoft Foundry自体には追加料金が発生しない点です（公式コスト管理ドキュメント）。Foundryポータルを使うこと自体は無料で、デプロイしたモデルや実行したエージェントごとに、それぞれのサービスの単価が積み上がっていく構造になっています。

2つの基本課金モデル——PAYGとPTU

Foundry上でモデルを動かす場合、基本となる課金モデルは2つあります。

課金モデル	概要	向いている用途
Pay-as-you-go（PAYG／Serverless API）	使った分のトークンに対して課金。事前コミットなし	試作・PoC・トラフィック変動の大きい本番
Provisioned Throughput Units（PTU）	固定キャパシティを時間単位で予約。レイテンシ・スループットを保証	安定したトラフィックの本番・SLA要件のある業務

多くの企業が最初はPAYGで始めて、トラフィックが見えてきたタイミングでPTUに切り替える流れが現実的です。PTUは予約キャパシティの分だけ常時課金されるため、利用量に対して過剰だと割高になります。

逆にトラフィックが多いケースでは、PTUのほうがトークン単価ベースで安く、レイテンシも安定するため、本番運用での主流になります。

主要モデルの単価例（2026年6月時点）

代表的なモデルの単価を確認しておきます。Azure OpenAI系の単価は公式pricingページで随時更新されており、本稿執筆時点（2026年6月）の代表例は以下のとおりです。

モデル	入力（100万トークン）	出力（100万トークン）
GPT-5.5	$5.00	$30.00
GPT-4o	$2.50	$10.00
Llama 3.3 70B	$0.59	$0.79

Microsoft自社モデル（MAI系）は機能ごとに料金体系が異なります。MAI-Transcribe-1（音声認識）は$0.36/時間、MAI-Image-2（画像生成）は入力$5/100万トークン・画像出力$33/100万トークンといったように、音声系は時間単価、画像系はトークン単価で課金される構造です（Microsoft公式発表 より）。Claude系のFoundry経由単価は、Anthropic公式単価に近い水準ですが、為替・サブスクライセンス・購入ルートで変動するため、利用前にFoundryポータルのpricingで確認することを推奨します。

これらの単価で重要なのは、「単価の安さ」だけではなく、「自社のユースケースで何トークン消費するか」を実測しないと、最終的なコストはわからないということです。プロンプト設計・コンテキスト長・繰り返し呼び出し回数で月額は10倍以上ぶれます。

Foundry IQ Serverless（Developer Tier）の料金

Foundry IQ Coreは Azure AI Foundry本体に含まれる形でGAしていますが、検証や小規模利用向けに**Foundry IQ Serverless（Developer Tier）**がプレビュー提供されています。料金体系は以下のとおりです。

項目	価格
コンピュート使用	$0.24/CU/時間
インデックス済みストレージ	約$0.29/GB/月
インデックスあたりストレージ上限	1 GB
1サービスあたりの最大インデックス数	30

課金開始は2026年後半を予定しており、現時点では実際の請求は発生しません（公式ブログより）。検証段階の組織にとっては、当面のあいだ実費負担なしでFoundry IQ Serverlessを試せる状態が続きます。

ファインチューンモデルの料金

ファインチューンモデルの料金は、トレーニング＋ホスティング＋推論の3要素で課金されます。

• トレーニング: モデル・データ量に応じてトークン単位または時間単価
• ホスティング: デプロイされている時間に対する時間単価（呼び出されていなくても課金される）
• 推論: 呼び出しごとの入力／出力トークン単価

特に注意したいのがホスティング料金です。ファインチューンモデルは「使っていなくても、デプロイされている限り課金が続く」という性質があり、不要なファインチューン版を残しておくと予想外のコストが積み上がります。

コスト最適化——プロジェクト別アトリビューションとアラート

Foundryには、コスト管理を効率化する仕組みが標準で備わっています。

• プロジェクト別コストアトリビューション（プレビュー）
  Foundryプロジェクトに自動付与されるprojectタグで、Cost Managementから部門・チーム単位の支出を分析可能
  
  

• エージェント単位のコスト推定
  Operate画面で各エージェントの推定月額コストが表示される
  
  

• モデル単位のコスト監視
  Buildタブのモニタリングでモデル別のトークン消費・コストを追跡
  
  

• Azureバジェット連携
  Azure Cost Managementでバジェットを設定し、閾値超過時にアラート発火

実務では、開発・検証・本番の3つのプロジェクトを分け、各々に独立した予算アラートを設定する運用が多くなります。「PoCで作ったエージェントを止め忘れて月末に高額請求」というのは、Foundryに限らずクラウドAIで頻発する事故で、初期のうちからバジェット設定を入れておくと安心です。

---

Microsoft Foundryの始め方・使い方

ここからは、Microsoft Foundryを実際に使い始めるための手順を整理します。

Foundryは複数機能の集合体ですが、最初のエージェントを動かすまでのフローは大きく4ステップに集約できます。

前提条件——Azureサブスクリプションと最小限のRBAC

Microsoft Foundryを使うために最低限必要な準備は、以下の3つです。

• Azureサブスクリプション
  有効なAzureサブスクリプションが必要。新規利用者は無料アカウントから始められる
  
  

• Foundryロール
  プロジェクト作成にはFoundry Owner／Foundry Account Owner／Foundry Project Manager／Owner／Contributorのいずれか（公式のHosted agent permissionsでは、データプレーンを伴うエージェント作成・利用にFoundry User以上が必要と整理）。Build 2026のブランド改名前は「Azure AI Owner／User」と呼ばれていた
  
  

• Cost Management Reader（任意）
  コスト管理ビューを利用する場合に追加で割り当てる

初期セットアップでは、まずMicrosoft Foundryポータルにアクセスし、Microsoftアカウントでサインインします。

サインイン後、利用者情報（プロフィール）を入力する画面に遷移します。組織内利用の場合、ここでテナント情報・部署を入れておくと、後の運用統制でフィルタとして活用できます。

Microsoft Foundryポータルでプロジェクトを作る

初期セットアップが終わると、Microsoft Foundryポータルのトップ画面に到達します。

Foundryでは、すべての作業をプロジェクトという単位で管理します。プロジェクトはAzureリソースグループに近い概念で、関連するモデル・エージェント・ナレッジ・評価データを1つのスコープにまとめる役割を果たします。

新規プロジェクトの作成画面では、プロジェクト名・リージョン・親リソースグループを指定します。日本国内のデータ所在地要件がある場合はJapan Eastを選んでおくのが第一歩ですが、Azure Foundryの推論処理はデプロイメント種別（Global／Data Zone／Regional）によって実際の処理リージョンが変わるため、モデルごとのRegional deployment可否を公式の提供リージョン一覧で必ず確認してから選択する必要があります。

プロジェクト作成後のダッシュボードでは、AI Hubの状況・モデル・エージェント・データ・接続情報を1画面で俯瞰できます。

AIサービスのセットアップとモデルデプロイの基本フロー

プロジェクトを作ったら、次は使うAIサービス・モデルをセットアップします。Foundryのセットアップは「使うサービス／モデルをカタログから選ぶ→構成を決める→デプロイする」の3ステップで完結します。

ポータル左ペインの「AIサービス」セクションから、利用したいサービス（Azure OpenAI、Speech、Content Understanding 等）を選択します。

選んだサービスの構成画面で、デプロイメント名・スループット枠（PAYG／PTU）・コンテンツフィルタを設定します。

デプロイ完了後は、ポータル内のプレイグラウンドで動作確認できます。プレイグラウンドはチャット形式・補完形式・テストプロンプト記録など、用途別のテストフォーマットが用意されています。

最初の検証フローでは、まずプレイグラウンドで応答を確認→APIキー／エンドポイントを取得→社内アプリ・エージェントに組み込むという順序が、最も詰まりにくいパスです。

最初のAIエージェントを構築する

モデルが使えるようになったら、Foundry Agent Serviceでエージェントを作ります。

ポータルから「Agents」を開き、新規エージェントを作成します。設定項目は次の4つに集約されます。

• 使用モデル
  GPT-5.5、Claude Opus 4.7、Gemma 4等のFoundryカタログ上のモデルから選択。GPT系を中心にModel Router経由の動的振り分けも選べる（Claude／DeepSeek／xAI系のRouter対応はプレビュー）
  
  

• システムプロンプト
  エージェントの役割・トーン・回答ポリシーを定義
  
  

• 接続ツール
  MCPサーバー、Foundry IQナレッジベース、Azure AI Search、Fabric Data Agent等を接続
  
  

• ガードレール
  Content Safety・Guided Guardrails・カスタム評価器の組み合わせ

これらを設定して保存すると、すぐにエージェントとしてポータル内・API経由で呼び出せます。ノーコード／ローコードのドラッグ&ドロップ画面でも同じ設定が可能です。

実装で詰まりやすいのが、ツール接続のMCP認証選択です。デフォルトのKey-based認証はテスト用途には便利ですが、本番運用では Entra Agent Identity か Managed Identity を選び、シークレットを Key Vault に持たせるのが標準的な設計になります。

評価ダッシュボードでは、エージェントの応答品質・トークン消費・レイテンシを継続的に観測できます。

---

Microsoft Foundryのセキュリティと責任あるAI

エンタープライズでAI基盤を選ぶ際に最も重く問われるのが、セキュリティ・コンプライアンス・責任あるAIへの対応です。

Microsoft Foundryは、ネットワーク分離・ID統制・データ保護・有害コンテンツ抑制を1つのプラットフォームで一貫した形で提供する点を強みにしています。

本セクションでは、ネットワーク・ID・データ・コンテンツの4つの観点で、Microsoft Foundryの統制機能を整理します。

ネットワーク分離——BYO VNet・Private Endpoint・パブリック非経由

Foundryは、エージェントやモデルAPIの通信をパブリックインターネットに出さない構成を標準でサポートします。

• BYO VNet（持ち込みVNet）
  自社の仮想ネットワークをFoundry Agent Serviceに持ち込み、その中でエージェントを動かせる
  
  

• Private Endpoint
  モデルAPIや評価エンドポイントをプライベートIPで露出。パブリックエンドポイントを閉じる構成が可能
  
  

• エージェントトラフィックの完全私設網化
  Foundry Agent Service GAで「no public egress」がうたわれており、外部にトラフィックが出ない設計

これは、データ漏洩リスクを最小化したい金融・医療・公共領域のシステムにとって決定的な要件で、Foundryをエンタープライズ向けと位置づける根拠の1つです。

ID統制——Foundry RBACとMCP認証の組み合わせ

ID統制では、Foundry RBACロール（旧Azure AIロール）と、エージェントが呼び出すツールへのMCP認証を組み合わせて使います。

役割	主な権限
Foundry Owner	Foundryリソースのすべての操作（旧Azure AI Owner）
Foundry Account Owner	アカウント全体のRBAC管理（旧Azure AI Account Owner）
Foundry Project Manager	プロジェクト単位の管理（旧Azure AI Project Manager）
Foundry User	プロジェクト内のリソース閲覧・利用（旧Azure AI User）
Cost Management Reader	コスト管理データの閲覧

MCP認証では先述の4方式（Key-based、Entra Agent Identity、Managed Identity、OAuth Identity Passthrough）から、ツールごとに選択できます。

実務的に推奨されるのは、本番環境でManaged IdentityまたはEntra Agent Identityを使い、APIキーを排除する設計です。Key-basedは開発時のプロトタイプ用と割り切ります。

データ保護——Microsoft Purview連携と顧客管理キー

Foundryは、Microsoft Purview（旧Microsoft 365コンプライアンス）との統合を進めており、データ分類・機密度ラベルに基づくアクセス制御をエージェントの問い合わせに反映させる方向で機能が整備されつつあります。Build 2026時点では、感度ラベル監査（sensitivity-label governance）・SharePoint権限同期（permission sync）はパブリックプレビュー段階のため、本番運用に組み込む前に提供状態と適用範囲を確認する必要があります。

将来的にFoundry IQ経由でSharePoint・OneLake等のデータをエージェントに接続する際、Purviewでラベリングされた「機密」「社外秘」のドキュメントへのアクセス制御が、特別な実装なしで適用される設計が進んでいます（現時点ではプレビュー）。

加えてBuild 2026ではお客様管理キー（Customer-Managed Key, CMK）暗号化周りのアップデートが進んでおり、ストレージ・モデル成果物・トレースログを顧客管理キーで暗号化する構成が選択肢として広がっています。ただしcross-tenant CMKなど一部の高度な構成はパブリックプレビュー段階のため、本番運用での採用時は公式の最新状態を確認することが必須です。

CMKを含むエンタープライズ暗号化機能は、データ所在地・規制要件が厳しい組織にとってFoundryを採用する大きな後押しになりますが、「クラウドプロバイダーから完全に独立して暗号化を握る」を実現するには、提供段階・対象データ範囲・運用ルールを公式docsで個別に確認する必要があります。

コンテンツ安全性と責任あるAI

最後に、生成AIに固有の有害コンテンツリスクへの対策です。FoundryはAzure AI Content Safetyを標準で組み込んでおり、入出力のテキスト・画像にフィルタを適用できます。

加えて2026年5月の更新で、「Guided Guardrails」というエージェントのガイド付きガードレールセットアップ（プレビュー）が追加され、企業独自の禁止トピック・トーン・回答ポリシーをコードを書かずに設定できるようになっています。

Foundryのデフォルト構成では、Azure OpenAI Service同様にユーザーが投入したデータをOpenAI／Microsoftがモデル学習に使うことはないと明記されています（公式FAQ）。

これはOpenAIの本家APIと同じ設計思想ですが、Azure基盤上で動く分、データ所在地・契約面の統制を組み合わせやすい点が企業利用での優位になります。

---

Microsoft Foundryと他社サービスの違い

エンタープライズAI基盤の選択肢として、Microsoft Foundry以外にも**Amazon BedrockとGoogle Vertex AI**が主要な比較対象になります。

3社とも「マルチモデルカタログ＋エージェント＋RAG基盤＋運用統制」を提供しており、機能セットは収束しつつあります。実務での選択は機能差以上に、既存のIT環境・データ資産・業務システムとの整合性で決まります。

Amazon Bedrock・Google Vertex AIとの機能比較

以下の表で、3つのプラットフォームの設計思想と主要機能を整理しました。

観点	Microsoft Foundry	Amazon Bedrock	Google Vertex AI
主要モデル	GPT-5.5・Claude Opus 4.7・Gemma 4・MAI系・11,000+	Claude・Llama・Titan・Cohere	Gemini・Claude・Gemma
エージェント基盤	Foundry Agent Service（GA）	Bedrock Agents	Vertex AI Agent Builder
RAG基盤	Foundry IQ（GA）	Bedrock Knowledge Bases	Vertex AI Search
主な接続強み	Microsoft 365・SharePoint・Teams・GitHub	AWS全般・S3・Lambda・既存AWSデータ	Google Workspace・BigQuery・Drive
エンタープライズ統制	Foundry RBAC・Purview・Entra ID	IAM・KMS・CloudTrail	IAM・Cloud Audit Logs
主な差別化	業務系（Copilot・Office）との連携	AWS既存ワークロードとの一体化	データ分析（BigQuery）との連携

機能の網羅性ではどのプラットフォームも遜色ありませんが、それぞれが「強い領域」を持つという点に注目してください。

SIerとしての使い分け——ケース別推奨

AI総合研究所はSIerとして、企業のAI基盤選定を多数支援してきた経験から、3社の使い分けについてケース別の判断軸を提示します。

自社の状況	第一候補	理由
Microsoft 365・SharePoint・Teamsを業務インフラとして使っている	Microsoft Foundry	Work IQでM365資産を即時にエージェント知識として活用でき、SSO・コンプライアンス統制の重複設定が不要
AWS上に基幹ワークロードがあり、AWS環境を出さない方針	Amazon Bedrock	既存のIAM・VPC統制・S3データレイクと一体化でき、移動コストが最小
BigQuery・Google Workspaceで業務とデータを統合している	Google Vertex AI	Vertex AI SearchがBigQueryとシームレスに連携し、データ分析→エージェント化の経路が最短
マルチクラウド前提で特定ベンダーに依存したくない	3社の用途別併用	エージェント運用＝Foundry／データ分析＝Vertex／既存AWS連携＝Bedrock のように、強みを使い分ける

もう1つ実務的に意識したいのが、**「現場の業務システムと、最初に統合される必要のあるツール」**です。たとえば営業現場で多用されているSalesforce・kintone・SAPなどがある場合、それらとの接続をどう実装するかが、プラットフォーム選定の隠れた変数になります。

実際の支援現場では、Microsoft 365が業務インフラの組織にとって、Microsoft Foundry以外の選択肢はかえって統合コストを増やす傾向があります。逆にAWS基盤に深く投資している組織がFoundryに移ると、IAMとEntra IDの二重管理が発生して運用負担が増えるケースをよく見ます。

導入判断で見落とされやすい3つの観点

3社を比較したうえでFoundryを選ぶ場合でも、判断時に見落とされやすい3つの観点を押さえておく必要があります。

プレビュー機能とGA機能の境界

Foundryは新機能の発表ペースが速く、ブログでアナウンスされた機能がプレビューかGAかが分かりにくいことがあります。プレビュー機能はSLA非対象・予告なき仕様変更・本番運用非推奨というのが原則で、本番ワークロードに組み込む際は公式の「What's new」ページで状態を確認することが必須です。

対応リージョンとモデル可用性の不一致

モデルカタログ全体としては11,000以上のモデルがありますが、特定リージョンで利用可能なモデルはその一部です。Japan Eastで使えるモデルとEast USで使えるモデルは異なるため、データ所在地の制約と使いたいモデルが両立するかを、デプロイ前にリージョン別の提供状況で確認します。

マルチクラウド設計の余地

Microsoft Foundryに乗せても、エージェントが呼び出すバックエンドAPIや外部ツールは、引き続き他のクラウド（AWS Lambda、Google Cloud Functions等）に置けます。「Foundryを選ぶ＝完全Azure依存」ではなく、MCP経由でマルチクラウド構成を組める設計の余地は残されています。

これらを最初の選定フェーズで意識しておくと、運用フェーズで「想定外の制約」に直面しにくくなります。

---

Microsoft Foundryの活用事例

Microsoft Foundryのエンタープライズ活用は、すでに国際的な大手企業で本格的に進んでいます。

ここでは、Microsoftが公開している代表的な事例2件と、Forrester社が実施した経済効果分析を取り上げ、それぞれの導入背景と成果を整理します。

Accenture——責任あるAIで生成AIソリューションを高速展開

コンサルティング大手のAccentureは、Microsoft Foundry（旧Azure AI Foundry）を活用し、再現可能・スケーラブル・高セキュリティな生成AIソリューションを構築しました。

Accentureが重視したのは、自社内および顧客提供の生成AIに対して、責任あるAIの統制を組み込みやすい設計である点です。Foundryのコンテンツ安全機能と評価機能を組み合わせ、デプロイ前の評価ループを自動化することで、市場投入までの時間を短縮しています。

コンサルティングファームのように「クライアントごとに用途が異なる多数のAIソリューション」を扱う組織では、共通基盤の上で個別カスタマイズを許す設計が必要になります。Foundryのプロジェクト単位の隔離設計が、その要件にフィットした事例です。

ASOS——AIパーソナルスタイリングの対話体験を構築

英国のオンラインファッション小売大手ASOSは、Azure AI Foundry（旧Azure AI Studio）を活用して自然言語で対話できるパーソナルスタイリング体験を検証しました。

公式事例で確認できる構成は、Azure OpenAI ServiceとAzure AI prompt flowを組み合わせ、顧客の好み・トレンド・商品カタログに基づくスタイリング提案を提供するというものです。Foundryの統合プラットフォーム上でモデル選定・プロンプト設計・評価ループを1つのワークフローに乗せたことで、PoCから検証までの時間を短縮できたと公表されています。

小売・EC領域では、顧客の自然言語入力（「カジュアルなオフィスコーデが欲しい」等）から、商品カタログとのマッチングまで、対話と業務データを行き来する処理が必要です。Foundryのモデル＋prompt flow＋評価が一つの環境に揃っている点が、こうした検証主体の用途で活きた事例といえます。

Forrester TEI調査——導入による経済効果が定量化

2026年2月、Microsoftの委託によりForrester Consultingが実施した「Total Economic Impact（TEI）調査」では、Microsoft Foundryの導入企業に対する経済効果が定量的に分析されました。

調査の主要な観点（3年間試算）は次のとおりです。

• 開発生産性の向上による工数削減
• インフラ統合によるTCO削減
• AI運用コストの可視化と最適化
• セキュリティ・ガバナンス整備の時間短縮
  
  

これらの数値は委託調査である点を踏まえて読む必要がありますが、Foundryのような「複数AIサービスを束ねるプラットフォーム」が、個別サービスを別々に契約・運用する場合と比べて、運用統制コスト・開発のリードタイム・ガバナンス整備時間の合計で大きな差を生むという構造を示しています。

---

Microsoft Foundryを業務に定着させるためのパートナー選び

Microsoft Foundryは強力な統合基盤ですが、ツールを契約しただけでは社内に定着しません。

実際の現場では、「Foundryでエージェントは作ったが、現場業務に乗らない」「PoCは成功したが全社展開に至らない」「セキュリティ要件と業務要件の擦り合わせで詰まる」といった論点が、導入後すぐに浮上します。

これらはFoundryの機能不足ではなく、自社業務とAI基盤を接続するデザインが抜けていることが原因です。

AI総合研究所では、Microsoft FoundryやAIエージェントを業務に定着させるための支援を「AI Agent Hub」として提供しています。Foundryで作るエージェントの社内展開設計、現場業務との接続、運用統制、現場メンバー育成まで一気通貫でサポートしています。

---

まとめ

本記事では、Microsoft Foundry（旧Azure AI Foundry）について、Microsoft IQファミリーの中での位置づけ、主要機能（Agent Service・Foundry IQ・モデルカタログ・Model Router・Foundry Local）、始め方と使い方、セキュリティ設計、料金体系、Bedrock・Vertex AIとの違い、活用事例まで、2026年6月時点の最新情報で解説しました。要点を改めて整理します。

• Microsoft FoundryはBuild 2026でブランドが整理され、モデル・エージェント・ナレッジ・評価・デプロイを束ねる統合プラットフォームとして再定義された。Microsoft IQファミリーのなかで、開発者向けのナレッジ層としてFoundry IQを担う
  
  

• Foundry Agent Service（2026年3月GA）はResponses API互換・BYO VNet・MCP認証拡張など、本番運用に耐える設計を備え、Foundry IQ（2026年6月GA）が複数データソース横断のRAGを統合する
  
  

• モデルカタログは11,000以上、Model Routerが用途・コスト・品質で動的振り分けを行い、Foundry Localでエッジ・オフライン環境にも展開可能
  
  

• 料金はPAYGとPTUの2つの基本モデル。Foundry自体は追加課金なしで、利用したサービスごとに従量課金。コスト管理はプロジェクト単位アトリビューションとAzureバジェットで統制できる
  
  

• Bedrock・Vertex AIとの選定軸はMicrosoft 365資産・既存Azure基盤・業務システムとの連携性で決まる。M365中心の組織はFoundryを第一候補に置く合理性が高い

Microsoft FoundryはAI導入を「特定モデルの選定」から「組織のAIファクトリーをどう設計するか」に視点を引き上げるプラットフォームです。まずはFoundryポータルで1つプロジェクトを作り、最初のエージェントを動かしてみるところから始めるのが、検討の最も早い第一歩になります。