Azure AI Foundryのモデルカタログで「目的に合うモデルが多すぎて選びにくい」と感じている開発者や管理者にとって、今回のDomain filterは実務上かなり分かりやすい改善です。結論から言うと、既存アプリの即時移行が必要な更新ではなく、モデル選定を速く、漏れなく、説明しやすくするための絞り込み機能です。
2026年6月4日に公開または更新された公式情報では、Microsoft Foundry model catalogにドメインフィルターがPublic Previewとして追加されました。1,900以上あるモデルの中から、ロボティクス、生物医学、材料探索、コーディングなど、特定の業界・用途向けに学習されたモデルを探しやすくするのが主な目的です。(マイクロソフト Azure)
ただし、Public Previewは本番利用前提のGA機能ではありません。Azure Updates上の「In preview」は、すべてのAzure顧客が非本番用途やテスト用途で利用できる状態と説明されています。管理者は「便利になったから本番のモデル選定ルールを即変更する」のではなく、検証環境でモデル候補の探索・評価プロセスに組み込むところから始めるのが安全です。(マイクロソフト Azure)
Azure AI FoundryのAI/Copilot更新で何が変わるのか
今回の変更点は、Azure AI Foundry、現在のMicrosoft Foundryにおけるモデルカタログの探索機能です。モデルの推論APIそのものや、すでにデプロイ済みのエンドポイントを自動的に変更する発表ではありません。
Microsoft Foundry Modelsは、生成AIアプリ、Copilot、AIエージェントなどを構築するために、Microsoft、OpenAI、Meta、Mistral、Cohere、NVIDIA、Hugging Faceなどのモデルを探し、比較し、デプロイするためのカタログです。公式ドキュメントでは、モデルカタログはキーワード検索、各種フィルター、リーダーボード、ベンチマーク、モデルカードを使って候補を比較できる場所として説明されています。(Microsoft Learn)
今回追加されたDomain filterは、その中でも「どの分野に向いたモデルか」という観点で候補を絞るためのものです。たとえば、一般的なチャットモデルを広く探すのではなく、「材料探索向けのモデルをまず見たい」「生物医学分野の文献処理に使えそうなモデルを探したい」といった入口を作れます。
| 観点 | これまでの探し方 | Domain filter追加後の変化 | 実務上の意味 |
|---|---|---|---|
| モデル探索 | キーワード、Collection、Industry、Capabilities、Inference tasksなどで絞り込み | 特定ドメインやユースケースに近いモデルを探しやすくなる | 候補モデルの洗い出し時間を短縮しやすい |
| Copilot開発 | 汎用モデルから試し、必要に応じて専門モデルを探す | 最初から用途に近い専門モデルを候補に入れやすい | PoCの初期精度を上げやすい |
| 管理・ガバナンス | 開発者ごとにモデル探索の観点がばらつきやすい | ドメイン単位で候補選定の理由を説明しやすい | レビューや承認の観点を標準化しやすい |
| 既存デプロイ | 既存モデルをそのまま使用 | 自動変更は想定しない | 既存アプリの緊急対応は基本不要 |
| 本番展開 | モデル評価、コスト、リージョン、ライセンス確認が必要 | 確認項目は引き続き必要 | フィルターだけで採用判断しない |
ポイントは、Domain filterが「正解のモデルを自動で選ぶ機能」ではないことです。あくまで、1,900以上のモデル群から候補を絞るための入口です。最終的には、自社のデータ、プロンプト、RAG構成、評価指標、コスト条件で検証する必要があります。
影響範囲はモデル選定プロセスが中心
今回のAzure AI Foundry更新で直接影響を受けるのは、主にモデルを探す人です。具体的には、生成AIアプリの開発者、Copilotやエージェントを設計するアーキテクト、モデル利用を承認するプラットフォーム管理者、AIガバナンス担当者が対象になります。
開発者への影響
開発者にとってのメリットは、候補モデルの初期選定が速くなることです。
たとえば、社内ナレッジ検索用の一般的なRAGアプリであれば、汎用的な大規模言語モデルを比較するだけでも十分な場合があります。一方で、研究開発、医療・ライフサイエンス、ロボティクス、材料探索、コード生成のような用途では、汎用モデルだけで試すと「それなりに答えるが専門性が足りない」という問題が起きやすくなります。
Domain filterを使えば、最初から用途に近いモデルを候補に含められます。これにより、PoCの初期段階で「モデルの選び方が悪かったのか」「プロンプトやデータ設計が悪かったのか」を切り分けやすくなります。
管理者への影響
管理者にとっては、モデル利用の統制を考えやすくなる点が重要です。
Azure AI Foundryのモデルカタログには、Microsoftが提供するモデルだけでなく、パートナーやコミュニティ由来のモデルも含まれます。モデル提供元によって、サポート、ライセンス、利用条件、デプロイ方式、料金、対応リージョンが異なる場合があります。公式ドキュメントでも、モデルカードには詳細情報、ベンチマーク、既存デプロイ、ライセンス情報などが表示されると説明されています。(Microsoft Learn)
そのため管理者は、Domain filterを「開発者が自由に専門モデルを探せる便利機能」としてだけ見るのではなく、モデル採用時のチェック項目を標準化するきっかけとして扱うべきです。
既存アプリへの影響
既存のAzure AI Foundryモデルデプロイ、既存のCopilot、既存のRAGアプリが今回の更新だけで自動的に変わるわけではありません。モデルカタログ上の探索機能が追加される更新であり、既存エンドポイントの応答品質、料金、API仕様、モデルバージョンが一斉に変更される種類の告知ではありません。
ただし、社内の開発手順書やモデル選定テンプレートに「モデルカタログの画面キャプチャ」「絞り込み条件」「推奨モデル探索手順」を載せている場合は、更新しておく価値があります。特に複数チームでAzure AI Foundryを使っている組織では、Domain filterを標準手順に含めることで、モデル選定のばらつきを減らせます。
Domain filterで探すべきモデルの例
Domain filterは、専門性が成果に直結する用途で特に役立ちます。反対に、一般的なFAQ、社内文書検索、議事録要約などでは、ドメインフィルターよりも、モデルのコスト、応答速度、日本語品質、RAGとの相性を優先した方がよい場合もあります。
| ドメイン例 | 想定シーン | 確認すべきポイント |
|---|---|---|
| Robotics | ロボット操作ログの分析、タスク計画、制御関連ドキュメントの理解 | 実機制御に直結させず、シミュレーションや人間レビューを挟む |
| Biomedical sciences | 論文要約、研究補助、医療・生命科学文書の分類 | 臨床判断に使う場合は規制、責任範囲、個人情報管理を別途確認する |
| Materials discovery | 材料候補の探索、実験記録の整理、論文からの物性情報抽出 | 出力を事実として扱わず、原典確認と専門家レビューを必須にする |
| Coding | コード生成、レビュー、テストケース作成、移行補助 | セキュリティ、依存関係、実行結果をCIで検証する |
実務では、Domain filterで候補を絞ったあとに、次のような観点でさらに削り込みます。
| 確認項目 | 見るべき内容 | 判断基準の例 |
|---|---|---|
| タスク適合性 | チャット、要約、分類、コード生成、マルチモーダルなど | 自社の入力・出力形式に合うか |
| 日本語対応 | 日本語プロンプト、日本語ドキュメント、日本語固有表現 | 業務データで評価して違和感が少ないか |
| デプロイ方式 | serverless deployments、managed computeなど | 運用負荷、ネットワーク要件、コストに合うか |
| リージョン | 対象リージョンで利用できるか | データ所在、レイテンシ、社内規定を満たすか |
| ライセンス | 利用条件、商用利用、提供元の条件 | 社内利用・顧客提供に問題がないか |
| コスト | トークン課金、予約容量、VM時間課金など | 想定利用量で予算内に収まるか |
| 安全性 | Content Safety、評価、監視、ログ | 有害出力や誤回答に対する運用策があるか |
開発者が取るべきモデル選定手順
Domain filterを有効に使うには、「フィルターで見つけたモデルをすぐ採用する」のではなく、候補選定から検証までを一連の流れにします。
まずユースケースをドメインの言葉で定義する
最初に、「AIで何をしたいか」をドメイン名に落とし込みます。
悪い例は、「高性能なモデルを探す」「Copilotに良さそうなモデルを探す」といった曖昧な指定です。これでは、Domain filterを使っても候補が広すぎます。
良い例は、次のような定義です。
| 悪い定義 | 良い定義 |
|---|---|
| 研究開発で使うAI | 材料探索の論文から候補材料と物性値を抽出する |
| 医療系Copilot | 生物医学論文を日本語で要約し、根拠文献を提示する |
| 開発支援AI | Pythonコードのレビューと単体テスト案を生成する |
| ロボットAI | 作業手順書からロボット動作の候補手順を生成する |
この粒度まで絞ると、モデル選定後の評価データも作りやすくなります。
Domain filterと既存フィルターを組み合わせる
Domain filterだけでなく、既存のCollection、Industry、Capabilities、Inference tasksなども併用します。モデルカタログは、キーワード検索や各種フィルターでモデルを探索し、ベンチマークやモデルカードで比較する仕組みを備えています。(Microsoft Learn)
たとえば、コーディング支援なら「Coding」系のドメインで候補を絞ったあと、推論能力、ツール呼び出し、コンテキスト長、デプロイ方式、ライセンスを確認します。生物医学系なら、対象タスクが要約なのか、分類なのか、画像やゲノムなど別形式のデータを扱うのかで候補が変わります。
モデルカードで採用可否を確認する
候補が数件に絞れたら、モデルカードを確認します。少なくとも次の項目は見ておくべきです。
| 確認項目 | 理由 |
|---|---|
| モデルの説明 | 想定用途と自社ユースケースが近いか判断する |
| バージョン情報 | 後から再現できるようにする |
| 対応データ形式 | テキスト、画像、音声、コードなどの入力条件を確認する |
| ベンチマーク | 公開指標上の強み・弱みを把握する |
| ライセンス | 商用利用や再配布、顧客向け提供の可否を確認する |
| 既存デプロイ | 組織内ですでに使っているモデルか確認する |
特にライセンスは見落とされがちです。専門モデルは便利ですが、提供元や利用条件がモデルごとに異なる場合があります。開発者がPoCで使えたとしても、顧客向けサービスや社内全社展開に使えるとは限りません。
自社データで評価する
Domain filterで見つかったモデルは、あくまで「候補」です。最終判断には、自社の業務データや代表的なプロンプトで評価する必要があります。
Microsoft Foundryの観測性機能では、モデル選定、事前評価、本番後監視という段階で、品質、安全性、信頼性を評価する考え方が示されています。モデル選定では、公開ベンチマークや自社データを使った比較が重要です。(Microsoft Learn)
評価では、最低でも次の観点を確認します。
| 評価観点 | 具体例 |
|---|---|
| 正確性 | 専門用語、数値、引用、コードの内容が正しいか |
| 根拠性 | RAG利用時に根拠文書に沿って回答しているか |
| 再現性 | 同じ条件で大きく回答がぶれないか |
| 安全性 | 有害出力、機密情報漏えい、過度な断定がないか |
| コスト | 想定トークン数、同時実行数、月額費用が許容範囲か |
| レイテンシ | 業務画面やチャットUIで待てる応答時間か |
管理者が確認すべき設定とガバナンス
管理者が見るべきポイントは、「Domain filterを使えるか」だけではありません。専門モデルの利用範囲、誰がデプロイできるか、どのリージョンで使うか、監査ログをどう残すかまで含めて確認する必要があります。
| 確認領域 | 管理者が行うこと | 注意点 |
|---|---|---|
| 利用ポリシー | Public Preview機能をどの環境で許可するか決める | 本番利用前提で承認しない |
| 権限管理 | モデル閲覧、デプロイ、キー管理、評価実行の権限を分ける | 開発者全員にデプロイ権限を渡さない |
| モデル提供元 | Microsoft提供か、パートナー・コミュニティ由来か確認する | サポート範囲や利用条件が異なる |
| デプロイ方式 | serverless deploymentsかmanaged computeか確認する | 課金、運用負荷、ネットワーク要件が変わる |
| リージョン | 利用可能リージョンとデータ所在地を確認する | モデルごとに利用条件が異なる場合がある |
| ライセンス | モデルカードのLicense情報を確認する | PoC利用と商用利用を分けて判断する |
| セキュリティ | Content Safety、ネットワーク分離、ログを確認する | 専門モデルでも安全策は不要にならない |
| 監視 | Application Insightsや評価結果を確認する | 本番後の品質劣化やコスト増を検知する |
Microsoft Foundry Modelsでは、managed computeとserverless deploymentsというデプロイ方式があり、モデルごとに利用可能な方式や機能が異なります。serverless deploymentsでは、標準的な従量課金や予約容量、グローバル、データゾーン、リージョナルなどの選択肢があり、料金やライセンス条件はデプロイ時に確認する必要があります。(Microsoft Learn)
また、モデルの利用可能地域にも注意が必要です。公式ドキュメントでは、従量課金が利用できる国・地域、モデルが利用可能なAzureリージョン、プロジェクトリソースのリージョンが関係することが説明されています。(Microsoft Learn)
移行・展開時に気を付けるポイント
今回のDomain filter追加に伴い、既存アプリを急いで移行する必要は基本的にありません。対応すべきなのは、主にモデル選定と検証の運用手順です。
既存のモデル選定ルールを更新する
社内でAzure AI Foundryを使っている場合は、モデル選定時のチェックリストに「Domain filterで専門モデル候補を確認する」という項目を追加します。
ただし、すべての案件で専門モデルを優先する必要はありません。たとえば、社内FAQや文書要約のように汎用モデルで十分な精度が出る用途では、専門モデルよりもコスト、応答速度、安定性、サポートの方が重要になることがあります。
プレビュー機能として検証環境で扱う
Public Previewの機能は、仕様やUI、利用可能範囲が今後変わる可能性があります。検証環境で使う分には有効ですが、社内標準や顧客向け本番サービスの前提にする場合は、GA状況、サポート範囲、公式ドキュメントの更新を確認してから判断すべきです。
特に、画面操作を前提にした手順書やトレーニング資料は、プレビュー中にUIが変わる可能性を考慮して「画面名を厳密に固定しすぎない」書き方にしておくと運用しやすくなります。
Content Safetyと監視を省略しない
専門ドメイン向けモデルを使っても、誤回答や有害出力のリスクがなくなるわけではありません。公式ドキュメントでは、serverless APIでデプロイされた言語モデルにAzure AI Content Safetyの既定構成が適用される一方、モデルタイプや利用APIによっては別途実装が必要になる場合があると説明されています。(Microsoft Learn)
また、Microsoft Foundryの監視機能は、Azure Monitor Application Insightsと連携し、トークン消費、レイテンシ、エラー率、品質スコアなどを確認できると説明されています。専門モデルを本番候補にする場合は、評価だけでなく、本番後の監視設計までセットで考えるべきです。(Microsoft Learn)
失敗しやすい判断と回避策
Domain filterは便利ですが、使い方を誤るとモデル選定の失敗につながります。
| 失敗しやすい判断 | なぜ危険か | 回避策 |
|---|---|---|
| ドメインが一致したら最適モデルだと考える | 学習領域と自社タスクの相性は別問題 | 自社データで評価する |
| 専門モデルなら日本語も強いと考える | 専門性と日本語品質は一致しない | 日本語プロンプトと日本語文書で検証する |
| Public Previewを本番前提で組み込む | 仕様や提供範囲が変わる可能性がある | 非本番で検証し、GA状況を確認する |
| ライセンスを後回しにする | 商用利用や再配布で問題化しやすい | モデルカードのLicenseを初期段階で確認する |
| コストを評価後に見る | 高性能でも運用費が合わない場合がある | 候補選定時に料金と利用量を概算する |
| Content Safetyを不要と判断する | 専門モデルでも有害出力や誤回答は起こる | 安全性評価と監視を設計に含める |
まず何をすべきか
Azure AI FoundryのDomain filterは、モデルカタログの情報量が増えた現在の実務に合った更新です。特に、Copilot、RAG、AIエージェント、研究開発支援、コード生成などで「どのモデルを選べばよいか」を説明する必要があるチームに向いています。
最初に行うべきことは、既存アプリの移行ではありません。まず、検証環境でモデルカタログを開き、自社の主要ユースケースに対応するドメインで候補モデルを洗い出します。次に、モデルカード、ライセンス、デプロイ方式、リージョン、コストを確認し、代表的な業務データで評価します。
管理者は、Public Previewの利用範囲、モデル採用時の承認フロー、評価結果の保存方法を決めておくとよいでしょう。開発者は、Domain filterを「モデル探索の近道」として使いながら、最終判断は必ず自社データで行う。この進め方が、今回のAzure AI Foundry更新を安全かつ実用的に活かす最短ルートです。
コメント