Microsoft Foundry

なぜ Azure AI Foundry（Microsoft Foundry）を選ぶのか？

現在の Microsoft のドキュメントでは「Microsoft Foundry」と表記されていますが、多くの開発者や購入者は依然として旧名称である「Azure AI Foundry」で検索しています。製品の本質的なコンセプトは同じです。個別のモデル API、ベクトルツール、評価スクリプト、デプロイ環境をバラバラに組み合わせるのではなく、エンタープライズ水準のガバナンスを備えた AI アプリおよびエージェント構築のための Microsoft クラウドプラットフォームを提供することにあります。

Foundry を選択する最大の理由は、Microsoft エコシステムとの親和性です。すでに Azure、Entra ID、Microsoft 365、GitHub、Visual Studio Code、Azure Monitor、Azure ネットワーク、および Microsoft のセキュリティ制御を利用している組織にとって、Foundry は既存の運用モデルに自然に馴染む AI 開発パスを提供します。

これは AI コードエディタの代わりになるものではありません。AI アプリケーションの背後にあるプラットフォームとして機能します。チームがモデルを探索し、エンドポイントをデプロイし、エージェントを調整し、ツールを接続し、エンタープライズデータに基づいて回答を生成（グラウンディング）し、評価を実行し、品質を監視し、本番環境への展開前にガバナンスポリシーを適用するための場所です。

主なワークフロー

標準的なワークフローは、Foundry ポータルまたはカタログでのモデル探索から始まります。開発者は候補となるモデルを比較し、プレイグラウンドでプロンプトをテストし、モデルをデプロイした後、Azure SDK、REST API、または対応している場合は OpenAI 互換パターンを介してアプリケーションコードから呼び出します。

アプリが成長するにつれ、ワークフローは単一のモデル呼び出しを超えて拡張されます。プライベートデータに対する検索機能の追加、エージェントツールの定義、アクショングループの構築、エージェントの挙動のトレース、評価の実行、安全性制御の設定、そして本番環境での品質やトークン使用量の監視などを行います。プロンプトのテストからライフサイクル管理への移行こそが、Foundry が価値を発揮する領域です。

コーディングエージェントのワークフローにおいて、Microsoft は MCP（Model Context Protocol）と VS Code の統合も推進しています。Foundry MCP Server を使用すると、対応するクライアントが自然言語ツールを介して Foundry リソースを操作できるようになり、Foundry Toolkit for Visual Studio Code は、開発者がローカル環境や Microsoft AI スタック内でモデルを扱うのを支援します。これにより Foundry が IDE になるわけではありませんが、開発環境内での利便性が大幅に向上します。

向いている用途

Foundry は、エンタープライズ向け Copilot、カスタマーサポートエージェント、社内ナレッジアシスタント、ドキュメント検索、営業支援、コードおよびデータアシスタント、規制対応ワークフローの自動化、コールセンターの要約、マルチモーダル分析、ビジネスデータに基づく RAG アプリケーションに適しています。

また、個別の統合を都度交渉することなく、複数のモデルプロバイダーを比較したい場合にも有用です。OpenAI、Anthropic、Meta、Mistral、DeepSeek、xAI、Hugging Face、Microsoft などのモデル群を、共通の Azure ガバナンスモデルの下で評価・利用できます。

Foundry Local は、プライバシー、低遅延、オフライン動作、またはクラウド推論コストの削減のために、デバイス上での AI 実行が必要なアプリという新たなユースケースに対応します。これにより、クラウド型のエンタープライズエージェントだけでなく、ローカル AI 機能を必要とする Windows アプリやクロスプラットフォームアプリにも適したプラットフォームとなっています。

他の選択肢との比較

Amazon Bedrock との比較では、多くの場合クラウド戦略が決め手となります。AWS ネイティブなチームは、IAM、VPC、CloudWatch などのインフラとの親和性から Bedrock を好むでしょう。Microsoft ネイティブなチームは、Azure、Entra ID、Microsoft 365、GitHub、VS Code、および Azure のガバナンスと整合する Foundry を選ぶのが自然です。

Google Vertex AI と比較すると、Foundry は Microsoft の生産性ツールや Azure/OpenAI の提携関係とより密接に関連しています。一方、Vertex AI は Google Cloud、Gemini、BigQuery などの Google プラットフォームをすでに活用しているチームに適しています。

OpenAI API や Anthropic API と比較した場合、Foundry はクラウドガバナンスとモデル管理のレイヤーを追加します。プロバイダー直結の API はシンプルで、最新機能をいち早く利用できる可能性がありますが、調達、監査可能性、プライベートネットワーク、ポリシー、エンタープライズ制御が重要な場合は Foundry がより魅力的です。

Hugging Face Inference Endpoints、Fireworks AI、Together AI と比較すると、Foundry はより広範で重厚なプラットフォームです。これらのプラットフォームは、オープンモデルの推論実験や特化型のモデルサービングにおいては高速な場合があります。AI システムをエンタープライズ向けの Azure アーキテクチャとガバナンスに適合させる必要がある場合は、Foundry が優れています。

推奨される構成

最適な Foundry のセットアップは、まずタスクごとにワークロードを分離することから始めます。一つのモデルですべてのユースケースに対応しようとしないでください。抽出、チャット、推論、コーディング、埋め込み、再ランク付け（Reranking）、画像生成、要約、バックグラウンドのバッチ処理など、それぞれに最適なモデルとデプロイの選択肢があるはずです。

RAG においては、検索の品質を最優先の課題として扱うべきです。データの権限、チャンク化、メタデータ、インデックス作成、引用、コネクタの選択、評価データセットは、類似したモデル間の切り替えよりも重要な場合が多いです。

エージェント開発では、まず限定的なツールと観察可能なワークフローから着手してください。ツールの権限、認証、承認ステップ、ロールバック計画は、モデルの外部で設計する必要があります。MCP ツールは強力ですが、実際のシステムを AI 駆動のアクションにさらすことになるため、他の本番環境への統合と同様に厳格に管理されるべきです。

コスト管理のために、導入前に利用状況をモデル化してください。トークン消費、モデルルーティング、プロビジョニング済み容量、ツール呼び出し、ベクトル検索、ホスト型エージェントの計算リソース、評価ジョブ、モニタリングはすべて課金対象となります。Azure のコスト管理機能を使用し、プロジェクトごとの所有権を明確にすることが初期段階から重要です。

移行時の注意点

Azure OpenAI のみのアプリから Foundry への移行は、ID 管理、請求、モデルアクセスパターンがすでに Azure 向けになっているため、他のクラウドからの移行よりも比較的スムーズです。大きな変化は運用面であり、以前は独自に構築していた評価、エージェント、RAG ツール、プロンプト管理、ガバナンスワークフローをプラットフォーム機能として取り入れることになります。

OpenAI や Anthropic の API から直接移行する場合は、注意深い再テストが必要です。モデル名が同じでも、クラウドプラットフォームを経由するとリクエスト形式、モデルバージョン、可用性、ストリーミングの挙動、クォータ、レイ延、コンテンツフィルタリング、および回答の特性が異なる場合があります。

Amazon Bedrock や Vertex AI からの移行は、単なるモデルの入れ替えではありません。IAM や Google Cloud の制御を Azure RBAC や Entra ID にマッピングし、監視の再構築、ネットワークの確認、データコネクタの移植、評価パイプラインの更新、すべてのエージェントツールの動作確認を行う必要があります。

セルフホストのオープンソースモデルから Foundry への移行は、インフラの負担を軽減できますが、推論サーバーの低レベルな制御権は減少する可能性があります。切り替え前に、現在のプロンプトテンプレート、バッチ処理、キャッシュ、GPU の前提条件、モデルバージョン、セーフティフィルタ、およびアプリが依存しているカスタムランタイムの挙動をドキュメント化しておいてください。