はじめに
こんにちは！横浜情報機器株式会社のロホマン シャヒンです。
社内でAI導入の話が出るたびに「どのサービスを使えばいいか分からない」「部署ごとに勝手に使い始めて管理できない」という話をよく聞きます。Microsoft Foundry（旧Azure AI Foundry）はそういった状況を整理するための基盤として、公式ドキュメントを改めて読み込んで、これは整理しておく価値があると感じました。
「AIを使える状態」にするだけでなく、「組織として管理できる状態」にする——Foundry の本質はここです。
1. Microsoft Foundryとは——最新の正式名称と全体像
まず名前の整理から。2025年後半以降、Microsoft は「Azure AI
Foundry」という名称を「Microsoft
Foundry」に統一しました。ポータルは引き続き
https://ai.azure.com
からアクセスでき、機能自体の変更はありません。ただ公式ドキュメントでは
“Microsoft Foundry” が正式名称です。
Microsoft Foundry は、エンタープライズ向け AI 開発・運用プラットフォームです。「AIアプリを作って、評価して、本番に出す」までの一連の流れを一つの環境で管理できます。
主なコンポーネントはこの構成です。
- Foundry Models（モデルカタログ）：OpenAI、DeepSeek、Meta、Hugging Face など 1,900以上のモデルを一覧から選んで使える
- Foundry Agent Service：コードなし（Prompt agents）からコンテナデプロイ（Hosted agents）まで幅広い AI エージェントを構築・運用できる
- ツールカタログ：1,400以上のツールを public/private カタログから接続できる
- 評価・可観測性：モデルの品質評価・トレース・モニタリングが組み込まれている
- Foundry Local：クラウドに出せないデータ向けに、ローカルでモデルを動かすオプション
プラットフォームの利用自体は無料です。費用はモデルのデプロイ単位で発生し、サービスごとに課金モデルが異なります。Microsoft は ROI 計算ツール（Total Economic Impact calculator）も公式で提供しています。
2. 1,900以上のモデルを一か所で管理できる
社内でAIを使い始めると「部署ごとに別のサービスを使っている」状態が生まれやすいです。A部門は OpenAI の API を直接呼んでいて、B部門は別のSaaSを契約していて、どこに何のデータが入っているか分からない——という状況、実際に起きています。
Foundry のモデルカタログなら、Microsoft が直接販売するモデル（Azure 上で企業向け SLA つき）と、パートナー・コミュニティのモデルを一か所から使えます。利用状況のログ・コスト・アクセス権限も一元管理できます。
モデルの切り替えが UI 上で完結するのは地味に便利でした。開発環境では Phi-4-mini を使って、本番は GPT-4o に切り替える運用がスクリプトを変えずにできます。
3. エンタープライズセキュリティが最初から設計に入っている
Foundry のセキュリティ設計で評価しているのは、「後付け」ではなく「最初から組み込まれている」点です。
① データはテナント内で処理される Azure OpenAI を Foundry 経由で呼び出す場合、入力データは Microsoft のトレーニングに使われません。テナント分離で他社のデータと混ざりません。
② プライベートエンドポイント（VNet 分離）に対応 インターネットを経由せず、Azure の閉じたネットワーク内でモデルにアクセスできます。HIPAA・PCI・FedRAMP などのコンプライアンス要件がある環境も想定された設計です。
③ マネージド ID でシークレットレス認証 API キーをコードに埋め込まなくていい。Entra ID 認証を使えば、RBAC による細かい権限制御ができます。
④ AIエージェントに個別の Entra ID を付与できる Foundry Agent Service では、エージェントごとに専用の Microsoft Entra ID を持たせられます。「このエージェントはどのリソースにアクセスできるか」を個別に制御できる仕組みです。
4. Responsible AIとガバナンスが組み込まれている
AIを企業で使うとき「誤った情報が出たときの責任は誰が持つか」という問いに答えられるか——経営層から必ず出てくる質問です。
Foundry には Content Safety フィルター・有害コンテンツ検出・出力の品質評価ツールが標準で含まれています。ガードレールポリシーという仕組みで、サブスクリプション全体に最低限のコンテンツフィルタリング設定を義務付けることもできます。
コンプライアンス違反が発生した場合、どのモデルデプロイがポリシーに違反しているかをポータルから確認・修正できます。これは稟議書に「Azure Policy による自動統制が可能」と書ける根拠になります。
5. AIエージェントを組織として構築・管理できる
Foundry Agent Service は、AI エージェントの作り方を2種類サポートしています。
Prompt agents：コードなし。ポータルで指示を書くだけでエージェントを作れます。
Hosted agents：自分のコードをコンテナ化して Foundry 上で動かします。LangGraph、OpenAI Agents SDK、Anthropic SDK、Agent Framework など、好みのフレームワークが使えます。Foundry がマネージドエンドポイント・スケーリング・Entra ID・可観測性を面倒みます。
エージェントには自動でバージョン管理が入り、ロールバックもできます。「昨日まで動いていたのに今日から挙動が変わった」という状況を追跡できる仕組みが最初から用意されています。
完成したエージェントは Microsoft 365・Teams・BizChat に公開することもできます。
6. Azure・M365 エコシステムとの統合が深い
すでに Azure を使っている企業にとって、Foundry の統合は「新しいツールを追加する」感覚があまりありません。
- Entra ID（旧 Azure AD）：既存の権限管理をそのまま Foundry のロールに適用できる
- Azure Monitor / Application Insights：AI アプリのトレース・ログを既存の監視基盤で見られる
- GitHub Actions / Azure DevOps：CI/CD パイプラインに AI の評価・デプロイを組み込める
- Microsoft 365 / Teams：エージェントを Teams や BizChat に直接デプロイできる
- VS Code 拡張：Microsoft Foundry for VS Code 拡張を使うと、エディタを離れずにモデルを呼び出せる
既存の Azure 環境に「AI の層を足す」イメージで、追加の学習コストが少ない点は、現場エンジニアにとって実際に効いてくる強みです。
7. Foundry Localでオフライン・閉域網にも対応
クラウドに出せないデータや、閉域網・オフライン環境での AI 利用が必要な場面もあります。そういった用途に Foundry Local が用意されています。
Foundry Local は winget 1 行でインストールでき、PC 上で OpenAI 互換のエンドポイントを起動します。Foundry のポータルや SDK と同じ設計思想なので、ローカルで開発してクラウドに移行する流れもスムーズです。
まとめ
Microsoft Foundry を企業が選ぶ理由は、単に「使えるモデルが多い」からだけではないと自分は思っています。
- 1,900以上のモデルを一元管理：部署横断の AI 利用を組織として統制できる
- セキュリティが設計に組み込まれている：プライベートエンドポイント・Entra ID・シークレットレス認証
- Responsible AI ガバナンス：ガードレールポリシーで稟議・コンプライアンス対応の根拠を作れる
- AIエージェントの構築・管理が体系化されている：バージョン管理・ロールバック・M365連携まで
- Azure・M365 エコシステムとの統合：既存インフラに追加する形で導入できる
- Foundry Local でオフライン対応も可能：クラウドと同じ文脈でローカル運用できる
「AI を使い始める」フェーズから「AI を組織として管理する」フェーズへ移行するとき、Foundry はその基盤として機能します。今まさにそのタイミングにいる企業には、検討する価値があると判断しています。
この記事が少しでも参考になったら、ぜひシェアしていただけると嬉しいです！