Microsoft Foundry Models overview (classic)は、Azure AI FoundryでAIモデルを探し、比較し、デプロイするためのモデルカタログの全体像を整理した公式ドキュメントです。結論から言うと、今回確認すべきポイントは「どのモデルを使うか」だけではありません。classicポータルを使い続けるべきか、新しいFoundryポータルへ移るべきか、モデルの提供元・課金・データ処理・ネットワーク分離・廃止予定まで含めて、運用設計を見直す必要があります。Microsoftの公式情報では、Azure AI Studio / Azure AI Foundryは現在のMicrosoft Foundryへ整理され、ポータル、API、SDK、リソースモデルの考え方も段階的に変わっています。(Microsoft Learn)
特に、既存のAzure AI Foundry環境でhub-based project、managed compute、Hugging Faceモデル、prompt flow、Azure OpenAIリソースを扱っている管理者・開発者は、Microsoft Foundry Models overview (classic)を「概要記事」として流し読みせず、移行判断と本番展開前チェックリストとして読むべきです。classicポータルは引き続き複数のリソース種別やhub-based projectを扱う場面で使われ、新しいFoundryポータルは主にFoundry project中心の体験として整理されています。(Microsoft Learn)
Microsoft Foundry Models overview (classic)で押さえるべき結論
Microsoft Foundry Modelsは、Microsoft、OpenAI、DeepSeek、Hugging Face、Metaなどのモデルを探索し、評価し、デプロイするためのモデルカタログです。公式ドキュメントでは、Foundryが1,900以上のモデルを提供し、基盤モデル、推論モデル、小規模言語モデル、マルチモーダルモデル、業界特化モデルなどを扱うと説明されています。(Microsoft Learn)
ただし実務上は、「モデル数が多い」ことよりも、次の5点を確認することが重要です。
| 確認項目 | 実務で見るべきポイント |
|---|---|
| ポータル | classicポータルで作業するのか、新しいFoundryポータルへ移るのか |
| プロジェクト種別 | Foundry projectか、hub-based projectか |
| モデルの提供元 | Models sold by Azureか、partners and communityモデルか |
| デプロイ方式 | managed computeか、serverless deploymentか |
| 運用リスク | データ処理、Content Safety、ネットワーク分離、モデル廃止、SDK移行 |
つまり、Microsoft Foundry Models overview (classic)は「どのAIモデルがあるか」を知るためだけの記事ではありません。Azure AI Foundry環境で、どのポータルを使い、どのモデルを選び、どの方式で安全に展開するかを判断するための入口です。
何が変わるのか：classicポータル前提の運用は棚卸しが必要
大きな変化は、Azure AI Foundryの名称や画面だけではなく、リソースモデル、API、SDK、エージェント開発の考え方まで整理されている点です。Microsoftの移行ガイドでは、Azure AI Studio / Azure AI FoundryがMicrosoft Foundryへ、Assistants APIがResponses APIへ、複数エンドポイント構成が単一のproject endpoint中心へ移行していることが示されています。(Microsoft Learn)
| 観点 | classic側での考え方 | 新しい確認ポイント |
|---|---|---|
| ブランド | Azure AI Studio / Azure AI Foundry | Microsoft Foundryとして整理 |
| ポータル | Foundry classic portal | New Foundry toggleで新旧を切り替え |
| リソース | Hub、Azure OpenAI、Azure AI Servicesなどを組み合わせる | Foundry resourceとFoundry project中心 |
| API | Assistants API、月次api-versionなど | Responses API、v1 stable routes |
| SDK | azure-ai-inference、azure-ai-generative、azure-ai-mlなど複数 | azure-ai-projects 2.xや標準OpenAI()クライアント中心 |
ここで注意したいのは、classicポータルが単純に不要になるわけではないことです。Microsoftのclassicポータル説明では、hub-based project、Foundry project、Azure OpenAIリソースを扱えるとされ、prompt flowやmanaged computeのモデルデプロイなど、classic側で必要になる機能もあります。(Microsoft Learn)
一方で、新しいエージェント機能やモデル中心の新機能はFoundry project側に重点が移っています。新しい機能を使いたい場合は、既存のhub-based projectをそのまま使い続けるのではなく、Foundry projectへの移行可否を確認する必要があります。(Microsoft Learn)
影響を受ける対象者
Microsoft Foundry Models overview (classic)の更新内容は、Azure AI Foundryを触る開発者だけでなく、管理者、セキュリティ担当、コスト管理担当にも影響します。
| 対象者 | 影響する作業 |
|---|---|
| Azure管理者 | ポータル切り替え、リソース種別、RBAC、Marketplace購読、クォータ管理 |
| 開発者 | モデル選定、APIエンドポイント、SDK、デプロイ名、推論コードの更新 |
| データサイエンティスト | モデル比較、ベンチマーク、fine-tuning、RAG、評価 |
| セキュリティ担当 | Content Safety、データ処理、ネットワーク分離、private endpoint |
| アーキテクト | managed computeとserverlessの使い分け、リージョン、SLA、移行計画 |
| コスト管理担当 | VMコア時間、token課金、Provisioned、Marketplace課金の整理 |
特に本番環境では、「とりあえずモデルをデプロイして試す」段階と、「社内システム・顧客向けサービスに組み込む」段階で確認項目が変わります。検証環境では速度やモデル性能を優先できますが、本番ではデータ処理場所、課金方式、可用性、フィルタリング、廃止リスクを先に決めるべきです。
モデルは2種類に分けて考える
Microsoft Foundry Models overview (classic)では、モデルカタログのモデルを大きく2つに分けています。1つはMicrosoftがホストし販売する「Models sold by Azure」、もう1つは外部パートナーやコミュニティが提供する「Models from partners and community」です。(Microsoft Learn)
| 分類 | 特徴 | 向いている用途 | 注意点 |
|---|---|---|---|
| Models sold by Azure | Microsoftの製品条項のもとでホスト・販売され、Azureとの統合やMicrosoftサポートが前提 | 企業システム、本番AIアプリ、SLAやサポートを重視する用途 | 対象モデル、リージョン、デプロイ種別を事前確認する |
| Models from partners and community | Anthropic、Hugging Faceなど、外部提供元やコミュニティのモデルが中心 | 特化型モデル、最新研究モデル、用途別の試行 | ライセンス、サポート窓口、Marketplace購読、デプロイ方式がモデルごとに異なる |
管理者が最初に確認すべきなのは、「そのモデルが誰から提供され、誰がサポートし、どの条件で使えるのか」です。モデルカードの説明、ライセンス、ベンチマーク、サポート条件を確認せずに本番採用すると、後から法務・調達・セキュリティレビューで差し戻される可能性があります。
たとえば、Azure OpenAI系のモデルを企業アプリに使う場合は、MicrosoftサポートやAzure統合を重視してModels sold by Azureを優先する判断が自然です。一方、特定業務に強いオープンモデルや研究系モデルを短期間で試したい場合は、partners and communityモデルが候補になります。ただし、外部モデルはMarketplace購読や提供元の条件確認が必要になるため、PoC段階から購読権限と利用規約を確認しておくべきです。(Microsoft Learn)
モデルカタログで確認すべき項目
モデルカタログは、モデル名を検索するだけの一覧ではありません。公式ドキュメントでは、Collection、Industry、Capabilities、Inference tasksなどのフィルターを使い、モデルカードでQuick facts、Details、Benchmarks、Deployments、Licenseなどを確認できると説明されています。(Microsoft Learn)
実務では、モデルカードを次の順番で確認すると失敗しにくくなります。
| 順番 | 確認項目 | 判断基準 |
|---|---|---|
| 1 | 対応タスク | チャット、埋め込み、画像、推論、tool callingなど、用途に合うか |
| 2 | 入出力形式 | テキストのみか、画像入力・マルチモーダルに対応するか |
| 3 | ベンチマーク | 自社タスクに近い評価指標があるか |
| 4 | ライセンス | 商用利用、再配布、業界規制に問題がないか |
| 5 | デプロイ方式 | managed computeかserverlessか、希望リージョンで使えるか |
| 6 | 既存デプロイ | 同じモデルの重複デプロイや不要なエンドポイントがないか |
性能ランキングだけでモデルを選ぶのは危険です。たとえば、社内FAQのRAG用途では、最高性能モデルよりも、低遅延・低コスト・安定したリージョン提供・埋め込みモデルとの相性のほうが重要になる場合があります。反対に、契約書レビューや複雑な調査支援では、多少コストが高くても推論能力や長文処理に強いモデルを選ぶ価値があります。
managed computeとserverless deploymentの違い
Microsoft Foundry Models overview (classic)で特に重要なのが、デプロイ方式の違いです。モデルカタログでは、managed computeとserverless deploymentという2つの主要なデプロイオプションが説明されています。managed computeは専用VM上にモデルウェイトを展開し、VMコア時間に基づいて課金されます。serverless deploymentはMicrosoftがホスト・管理するAPIとしてモデルにアクセスし、通常は入力・出力トークンなどに基づいて課金されます。(Microsoft Learn)
| 比較項目 | managed compute | serverless deployment |
|---|---|---|
| インフラ | 専用VMにモデルをデプロイ | Microsoft管理基盤上のAPIを利用 |
| 課金 | VMコア時間が中心 | token課金や予約容量など |
| 向いている用途 | モデルウェイト、実行環境、ネットワークを細かく制御したい場合 | すばやくAPIとして使い、運用負荷を下げたい場合 |
| クォータ | 対象VMのクォータが必要 | モデル・リージョン・TPMなどのクォータ確認が必要 |
| Content Safety | Azure AI Content Safety APIを別途組み込む | 言語モデルでは統合フィルターが利用される場合がある |
| 注意点 | VMコスト、スケール、保守設計が必要 | リージョン、データ処理場所、Marketplace条件を確認 |
Hugging Faceモデルなどmanaged computeにデプロイするモデルを扱う場合、公式ドキュメントではhub-based projectをFoundry classic portalで使う必要があるとされています。これは、新しいポータルに移行した後も、すべてのワークロードが同じ画面で扱えるとは限らないことを意味します。(Microsoft Learn)
serverless deploymentではデプロイ種別を必ず確認する
serverless deploymentでは、単に「サーバーレスだから簡単」と考えるのは不十分です。Microsoft Foundry Modelsのデプロイ種別では、データ処理場所、課金方式、性能特性が変わります。公式ドキュメントでは、Global Standard、Global Provisioned、Global Batch、Data Zone Standard、Data Zone Provisioned、Standard、Regional Provisioned、Developerなどの種別が整理されています。(Microsoft Learn)
| 要件 | 選びやすいデプロイ種別 | 判断の目安 |
|---|---|---|
| まず検証したい | Global Standard、Standard | pay-per-tokenで始めやすい |
| 高スループットが必要 | Provisioned系 | 予約容量でレイテンシばらつきを抑えやすい |
| 非同期の大量処理 | Batch系 | 即時応答が不要な大規模処理向き |
| EU/USのデータゾーン要件 | Data Zone系 | 指定データゾーン内で処理したい場合 |
| 単一リージョン要件 | Standard、Regional Provisioned | リージョン制約が強い場合 |
| fine-tuned model評価 | Developer | 評価用途向け。SLA条件に注意 |
データ所在地に関する要件がある場合は、特にGlobal、Data Zone、Regionalの違いを確認してください。公式ドキュメントでは、保存データは指定されたAzure geographyに残る一方、推論データの処理場所はデプロイ種別によって異なると説明されています。Globalでは任意のAzureリージョン、Data ZoneではMicrosoft指定のUSまたはEUデータゾーン、Standard/Regionalではデプロイリージョンで処理されます。(Microsoft Learn)
金融、医療、公共、個人情報を扱う業務では、「Azureだから大丈夫」ではなく、「どのデプロイ種別で、どの地域で処理されるか」を設計書に明記することが重要です。
管理者が確認すべき設定
ポータルとプロジェクト種別を確認する
最初に確認するのは、対象ワークロードがFoundry projectなのか、hub-based projectなのかです。Microsoftのclassicポータル説明では、一般的にはFoundry projectを使うことが推奨される一方、Foundry projectで利用できない機能が必要な場合はhub-based projectを使うとされています。(Microsoft Learn)
確認手順としては、Foundryポータルのパンくず、All resources、Management centerで、親リソースがFoundryなのかHubなのかを見ます。新しいFoundryポータルでプロジェクトが見えない場合、プロジェクトが消えたのではなく、hub-based projectが新ポータルで表示対象外になっている可能性があります。(Microsoft Learn)
権限とMarketplace購読を確認する
モデルをデプロイするには、Foundry resourceに対する十分な権限が必要です。新しいFoundryポータルでモデルを展開する公式手順では、Cognitive Services Contributor相当の権限、Foundry project、そしてpartners and communityモデルの場合はAzure Marketplaceの購読権限が前提として示されています。(Microsoft Learn)
よくある失敗は、開発者にはモデルを選ぶ権限があるものの、Marketplaceの条件に同意できずデプロイで止まるケースです。社内でPoCを進める前に、次の権限を確認しておくと手戻りを減らせます。
| 確認項目 | 見る場所 | 失敗例 |
|---|---|---|
| Foundry resourceへの権限 | Azure RBAC | デプロイ作成ボタンが使えない |
| Marketplace購読権限 | Azure Marketplace / 管理ポリシー | 外部モデルの利用条件に同意できない |
| クォータ | Foundryポータル / Azure portal | デプロイ作成時にquota exceeded |
| プロジェクト作成権限 | Management center | 移行先プロジェクトを作れない |
| キー・Entra認証 | エンドポイント詳細 | アプリからAPI接続できない |
クォータと課金単位を確認する
Foundry Modelsは、モデルやリージョンごとにクォータが異なります。新しいFoundryポータルのデプロイ手順では、モデルのデプロイと推論でTPMなどのクォータを消費し、クォータ上限に達した場合は追加申請または既存デプロイからの再割り当てが必要とされています。(Microsoft Learn)
本番化前には、次の3つを別々に見積もるべきです。
| コスト要素 | 例 |
|---|---|
| 推論コスト | 入力token、出力token、batch、Provisioned |
| インフラコスト | managed computeのVMコア時間、関連リソース |
| 周辺サービス | Azure AI Content Safety、Azure AI Search、Storage、Key Vault、監視ログ |
特にRAG構成では、LLMのtoken費用だけでなく、検索サービス、インデックス作成、埋め込み生成、ログ保存の費用も発生します。見積もり時は「1回の質問あたりの平均入力token」「検索で追加されるコンテキスト量」「出力token上限」「同時実行数」を使って、月間コストを試算してください。
ネットワーク分離とpublic network accessを確認する
serverless deploymentのエンドポイントは、プロジェクトが属するFoundry hubのpublic network access設定に従うと説明されています。セキュリティを高めるには、Foundry hubのpublic network accessを無効化し、private endpointを使ってクライアントからエンドポイントへの通信を保護する構成が検討されます。設定変更は反映に最大5分かかる場合があります。(Microsoft Learn)
ただし、2024年7月11日より前に作成されたprivate endpointやserverless deploymentには制限があります。既存の構成がhubのネットワーク設定に追従しない場合は、新しいprivate endpointやserverless deploymentの作り直しが必要になることがあります。また、public network accessを無効化したprivate hubでは、serverless deploymentに対するAzure OpenAI On Your Dataが利用できない制限も示されています。(Microsoft Learn)
この点は、移行時に見落とされやすい項目です。ネットワーク設定だけを変更して「保護された」と判断せず、実際にアプリケーションから接続テストを行い、不要なパブリック経路が残っていないか確認してください。
Content Safetyと責任あるAIの設定を確認する
serverless APIでデプロイされた言語モデルでは、Azure AI Content Safetyのテキストモデレーションフィルターが既定構成として実装される場合があります。一方で、embeddingモデルや時系列モデルなど、content filteringが利用できないモデル種別もあります。また、Model Inference API以外のAPIでserverless APIのモデルを使う場合、Content Safetyは別途実装しない限り有効にならないと説明されています。(Microsoft Learn)
つまり、本番環境では「Foundryを使っているから安全対策済み」と考えるのではなく、次の点を確認する必要があります。
| 確認項目 | 実務上の判断 |
|---|---|
| フィルター対象 | 使用モデルがContent Safety統合の対象か |
| フィルター設定 | 既定値のままで業務要件を満たすか |
| API経路 | Model Inference API以外を使う場合に別途安全対策があるか |
| ログ | ブロック、検出、誤検知の監視方法があるか |
| 例外対応 | 業務上必要な出力が過剰にブロックされた場合の運用手順があるか |
社内チャットボット、問い合わせ自動応答、顧客向け生成AIでは、ブロック率や誤検知率をリリース前に測定してください。安全フィルターを強くしすぎると業務回答が止まり、弱すぎると有害出力のリスクが高まります。
データ処理とプライバシーを確認する
classicポータルのデータ、プライバシー、セキュリティに関する公式情報では、モデル利用時に処理されるデータとして、プロンプト、生成コンテンツ、RAGで追加されるコンテンツ、fine-tuning用にアップロードされたデータなどが挙げられています。serverless API deploymentでは、Microsoftがホスティング基盤とAPIエンドポイントを管理し、プロンプトや出力をモデル提供元と共有せず、Microsoftモデル、モデル提供元モデル、第三者モデルのトレーニングや改善に使わないと説明されています。(Microsoft Learn)
ただし、これは利用者側の責任がなくなるという意味ではありません。公式概要でも、利用者は法令遵守、モデルカードや関連ドキュメントの確認、用途に適したモデル選定、Acceptable Use Policyや行動規範に沿うための適切な対策に責任を持つとされています。(Microsoft Learn)
社内データを使う場合は、少なくとも次の観点をレビューしてください。
| 観点 | 確認内容 |
|---|---|
| 入力データ | 個人情報、機密情報、顧客データが含まれるか |
| RAG | 検索で追加される文書の権限管理が適切か |
| fine-tuning | 学習データの保管、暗号化、削除手順が決まっているか |
| ログ | プロンプトや出力をどこまで保存するか |
| 監査 | 誰が、いつ、どのモデルを使ったか追跡できるか |
開発者が確認すべき実装・移行ポイント
デプロイ名とAPIの使い方を確認する
Foundry Modelsをデプロイした後、推論時にはデプロイ名をmodelパラメーターとして使う場合があります。公式のデプロイ手順でも、デプロイ名がリクエストを特定のデプロイへルーティングするために使われると説明されています。(Microsoft Learn)
開発者は、モデル名とデプロイ名を混同しないようにしてください。たとえば、同じモデルを「検証用」「本番用」「低コスト用」で複数デプロイしている場合、アプリ側のmodel指定がどのデプロイを指しているかを環境変数や設定ファイルで明確に分ける必要があります。
悪い例は、コードにデプロイ名を直書きすることです。モデルの置き換えやリージョン移行のたびにコード変更が必要になります。本番では、次のように環境別に管理するのが安全です。
| 環境 | 設定例 |
|---|---|
| 開発 | FOUNDRY_MODEL_DEPLOYMENT=chat-dev |
| ステージング | FOUNDRY_MODEL_DEPLOYMENT=chat-stg |
| 本番 | FOUNDRY_MODEL_DEPLOYMENT=chat-prod |
SDKのバージョン不一致に注意する
classicから新しいFoundry体験へ移る場合、SDKの世代差がエラー原因になりやすいです。移行ガイドでは、azure-ai-inferenceが2026年5月30日にretire予定であること、Assistants APIが2026年8月26日にsunset予定であること、azure-ai-projects 2.xや標準OpenAI()クライアントへの移行が示されています。(Microsoft Learn)
特に次の症状が出た場合は、コードの問題だけでなく、ポータル体験とSDKの組み合わせを疑ってください。
| 症状 | よくある原因 |
|---|---|
ModuleNotFoundError | サンプルコードとインストール済みSDKが一致していない |
| 認証エラー | API key前提のコードをEntra認証構成に流用している |
404またはMethodNotAllowed | Assistants API向けコードをResponses API側へ送っている |
| エンドポイント接続失敗 | 古い複数エンドポイント形式を使い続けている |
| 新ポータルでAgentが使えない | リソースのリージョンがResponses API非対応 |
移行作業では、まずサンプルコードを最新版に置き換えるのではなく、現在のプロジェクトがclassic向けなのか新ポータル向けなのかを決めてからSDKを選ぶべきです。
RAGとfine-tuningはモデルごとの差を確認する
Microsoft Foundry Modelsでは、すべてのモデルが同じようにRAGやfine-tuningに対応するわけではありません。公式概要では、serverless deployment経由でデプロイされたモデルを使って、ベクターインデックスやRAG、fine-tuningを利用できる場合があると説明されていますが、対象はモデルごとに異なります。(Microsoft Learn)
実務では、次のように目的別に確認しましょう。
| 目的 | 確認すること |
|---|---|
| 社内文書検索 | 埋め込みモデル、検索サービス、権限継承、引用表示 |
| FAQ自動応答 | RAGの検索品質、回答の根拠、プロンプトテンプレート |
| 業務特化回答 | fine-tuning対応、学習データ形式、評価データ |
| 大量文書処理 | Batch系デプロイ、処理時間、コスト |
| マルチモーダル | 画像入力、出力形式、API対応 |
RAGで十分な用途にfine-tuningを使うと、コストと運用負荷が増えます。逆に、定型出力や専門用語の扱いをモデルの振る舞いとして安定させたい場合は、fine-tuningが候補になります。どちらを選ぶかは、データを「検索で補う」のか、「モデルの振る舞いとして学習させる」のかで判断すると分かりやすいです。
モデル廃止とライフサイクル管理は本番前に必ず見る
AIモデルは更新が速く、古いモデルがLegacy、Deprecated、Retiredへ進むことがあります。Microsoftのmanaged compute向けモデル廃止情報では、モデルのステージとしてPreview、Generally available、Legacy、Deprecated、Retiredが定義され、Retiredになると既存デプロイの利用でも404エラーが返ると説明されています。(Microsoft Learn)
本番アプリで避けるべきなのは、モデル廃止をリリース後に知ることです。最低限、次の運用を入れてください。
| 運用項目 | 内容 |
|---|---|
| モデル台帳 | モデル名、バージョン、デプロイ名、リージョン、用途を記録 |
| 廃止確認 | 月1回、公式のdeprecation / retirement情報を確認 |
| 代替モデル検証 | Legacy段階で候補モデルをデプロイして品質・レイテンシ・コストを比較 |
| 切り替え手順 | アプリ設定の変更だけでデプロイ名を切り替えられるようにする |
| 旧デプロイ削除 | 移行完了後に古いデプロイを削除し、誤利用と課金を防ぐ |
モデル更新は、単なるバージョンアップではありません。出力品質、トークン消費、レイテンシ、プロンプトへの反応、安全フィルターとの相性が変わる可能性があります。代替モデルのテストでは、ベンチマーク値だけでなく、自社の実データに近いテストケースを使って比較してください。
hub-based projectからFoundry projectへ移行する場合の注意点
hub-based projectを利用している場合、新しいFoundry projectへ移行することで最新機能を使いやすくなります。ただし、公式の移行情報では、移行で引き継がれるものと引き継がれないものが明確に分かれています。model deployments、data files、fine-tuned models、Assistants、vector storesは移行対象として示される一方、Preview Agent state、open-source model deployments、hub project accessは移行対象外とされています。(Microsoft Learn)
| 移行で確認するもの | 確認内容 |
|---|---|
| モデルデプロイ | 移行先で同じモデル・リージョン・クォータが使えるか |
| データファイル | 参照先、権限、保存場所が変わらないか |
| fine-tuned models | 移行後に推論・再評価できるか |
| Assistants / Agents | 状態やスレッドを再作成する必要があるか |
| Vector stores | RAGの検索品質が変わらないか |
| open-source model deployments | Foundry projectで未対応のものがないか |
移行は一括で進めるより、用途単位で進めるのが安全です。たとえば「社内FAQ」「営業支援」「契約書レビュー」のようにアプリ単位で分け、各アプリについてモデル、データ、API、権限、監視を確認してから次へ進めます。
よくある失敗と回避策
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
| 新ポータルでhub-based projectが見えない | プロジェクトが消えたと誤認する | classicポータルへ切り替え、プロジェクト種別を確認する |
| モデル提供元を確認しない | ライセンスやサポート条件で差し戻される | モデルカード、License、Marketplace条件を確認する |
| Global deploymentを安易に選ぶ | データ処理場所の説明が曖昧になる | Global、Data Zone、Regionalの違いを設計書に記載する |
| Content Safetyを過信する | API経路によってフィルターが効かない | 使用APIとモデル種別ごとに安全対策を確認する |
| 古いprivate endpoint構成をそのまま使う | network設定が期待通り反映されない | 2024年7月11日前後の構成制限を確認し、必要なら作り直す |
| SDKだけ先に更新する | APIエラーや認証エラーが増える | ポータル体験、API、SDKをセットで移行する |
| モデル廃止を監視しない | Retired後に本番で404が発生する | モデル台帳と廃止確認の運用を入れる |
| クォータを見積もらない | リリース直前にデプロイできない | リージョン・モデル別のTPMやVMクォータを先に確認する |
実務での確認手順
Azure AI Foundry環境でMicrosoft Foundry Models overview (classic)を踏まえて対応するなら、次の順番で進めると効率的です。
| 手順 | 作業 | 成果物 |
|---|---|---|
| 1 | 既存プロジェクトを棚卸しする | Foundry project / hub-based project一覧 |
| 2 | 既存デプロイを一覧化する | モデル名、デプロイ名、リージョン、用途、課金方式 |
| 3 | モデル提供元を分類する | Models sold by Azure / partners and community |
| 4 | デプロイ方式を確認する | managed compute / serverless / deployment type |
| 5 | セキュリティ設定を確認する | Content Safety、network、private endpoint、RBAC |
| 6 | データ処理を整理する | 入力データ、RAG、fine-tuning、ログ、保存場所 |
| 7 | 移行要否を判断する | classic継続、新ポータル移行、段階移行 |
| 8 | 代替モデルを検証する | 品質、コスト、レイテンシ、安全性の比較結果 |
| 9 | 本番切り替え手順を作る | ロールバック手順、設定変更手順、監視項目 |
この順番にすると、「新しいポータルを使うべきか」から考えるのではなく、「どのワークロードに、どの機能が必要か」から判断できます。結果として、classicを残す理由と新ポータルへ移す理由が明確になります。
まず取るべきアクション
Microsoft Foundry Models overview (classic)を読んだ後、最初にやるべきことは新しいモデルを試すことではなく、現在の利用状況を可視化することです。既存のAzure AI Foundry環境で、どのプロジェクトがclassic依存なのか、どのモデルが本番で使われているのか、どのデプロイがmanaged computeまたはserverlessなのかを一覧化してください。
そのうえで、次の判断を行います。
| 判断 | 取るべき行動 |
|---|---|
| managed computeやprompt flowが必要 | classicポータル継続を前提に運用設計する |
| 新しいAgent機能やResponses APIを使いたい | Foundry projectと新ポータルへの移行を検討する |
| 外部モデルを使う | Marketplace購読、ライセンス、サポート条件を確認する |
| 本番アプリに使う | Content Safety、ネットワーク、データ処理、監視を設計する |
| 長期運用する | モデル廃止、SDK retire、API sunsetの予定を管理する |
Microsoft Foundry Models overview (classic)は、Azure AI Foundryのモデルカタログを理解するための概要であると同時に、classic環境を安全に運用し、新しいMicrosoft Foundry体験へ移るための判断材料です。管理者は権限・ネットワーク・課金・データ処理を、開発者はモデルカード・デプロイ名・API・SDKを確認し、移行はプロジェクト単位ではなくアプリケーション単位で段階的に進めるのが現実的です。
コメント