Azure AI FoundryでAIモデルを選ぶとき、「精度が高いモデルを選べばよいのか」「安全性やコスト、応答速度もどう比較すればよいのか」で迷うケースは多いはずです。
2026年5月19日時点で確認すべき「Model benchmarks and leaderboards in Microsoft Foundry – Microsoft Foundry」の要点は、Foundryポータル上のモデルリーダーボードを使い、モデルカタログ内のAIモデルを品質・安全性・コスト・パフォーマンスのベンチマークで比較しやすくなることです。これはモデル選定の初期調査を効率化する機能ですが、プレビュー機能であり、本番導入の最終判断は自社データでの評価と運用設計まで含めて行う必要があります。Microsoft Learnでも、プレビュー機能はSLAなしで提供され、運用環境のワークロードには推奨されないと説明されています。(Microsoft Learn)
なお、現在の公式ドキュメントでは「Azure AI Foundry」から「Microsoft Foundry」への名称変更が進んでいます。Microsoftは、Azure AI Studio / Azure AI Foundryが現在のMicrosoft Foundryに発展したと説明しており、同じ流れのプラットフォームとして理解すると混乱しにくくなります。(Microsoft Learn)
Azure AI FoundryのModel benchmarks and leaderboardsは何が変わるのか
Azure AI Foundry、現在のMicrosoft FoundryにおけるModel benchmarks and leaderboardsは、Foundryモデルカタログ内のモデルを、業界標準のベンチマークをもとに比較するための機能です。従来のように「有名なモデルだから」「最新モデルだから」といった印象だけで選ぶのではなく、用途に応じて複数の指標を見ながら候補を絞り込めます。
公式情報では、モデルリーダーボードはテキスト言語モデル、つまりLLMとSLM、および埋め込みモデルのベンチマークに対応しています。適したモデルを見つけた後は、モデルカタログ内の詳細ベンチマーク結果を開き、デプロイ、プレイグラウンドでの試用、自社データでの評価につなげられます。(Microsoft Learn)
実務上の変化は、次の3点です。
| 変更点 | 何が便利になるか | 注意点 |
|---|---|---|
| モデル選定をリーダーボードで開始できる | 品質、安全性、コスト、スループットなどを同じ画面で比較しやすい | すべてのモデルにベンチマークがあるわけではない |
| シナリオ別に比較できる | コーディング、数学、質問応答など、用途に近い指標から選べる | 総合スコアだけで判断すると用途に合わないことがある |
| 詳細結果から評価・展開に進める | 候補モデルをプレイグラウンドや評価フローに接続しやすい | 本番利用前には自社データでの評価が必須 |
特に重要なのは、リーダーボードが「最強モデルを1つ決める表」ではなく、用途に合うモデルを短時間で絞り込むための比較画面だという点です。生成AIアプリでは、最高品質のモデルが必ずしも最適とは限りません。問い合わせ対応なら安全性とレイテンシ、社内検索なら埋め込み品質と根拠性、コード生成ならコーディング系ベンチマークを重視する必要があります。
対象者と影響範囲
この更新の影響を受けるのは、Azure AI Foundryでモデルを選定・検証・展開する管理者、開発者、AIアプリの運用担当者です。特に、複数のモデル候補を比較してPoCや本番構成を決めるチームでは、モデル選定プロセスを見直すきっかけになります。
| 対象者 | 影響 | 確認すべきこと |
|---|---|---|
| アプリ開発者 | モデル選定の初期比較がしやすくなる | 品質だけでなく、レイテンシ、スループット、機能サポートも確認する |
| Azure管理者 | Foundryプロジェクトへのアクセス権やポータル利用が前提になる | 有効なAzureサブスクリプション、Foundryプロジェクト、適切なロールを確認する |
| セキュリティ担当者 | 安全性ベンチマークをモデル選定に組み込める | ベンチマーク結果を過信せず、Guardrailsや社内ポリシーと組み合わせる |
| FinOps担当者 | コスト比較の材料が増える | 実際の入力・出力トークン比率、推論トークン、価格変更を前提に再計算する |
| AI評価担当者 | 公開ベンチマークと自社評価を分けて扱える | リーダーボードで候補を絞り、自社データで最終評価する |
モデルリーダーボードを利用するには、Foundryプロジェクト、Foundryポータルへのアクセス、少なくともFoundryプロジェクトのReaderロールが必要とされています。無料または試用版のAzureサブスクリプションでは利用できない条件もあるため、検証環境を作る段階で権限とサブスクリプション種別を確認しておくと、導入時の手戻りを避けられます。(Microsoft Learn)
比較できるベンチマークの種類
Model benchmarks and leaderboardsでは、言語モデルと埋め込みモデルに対して複数の観点で評価結果を確認できます。ここで重要なのは、指標ごとに「高いほうがよい」「低いほうがよい」が異なることです。
| ベンチマーク | 主な見方 | 実務での使いどころ |
|---|---|---|
| 品質ベンチマーク | 品質インデックスは0〜1で、高いほどよい | 汎用チャット、推論、質問応答、コーディングなどの候補選定 |
| 安全性ベンチマーク | 攻撃成功率は低いほどよい。毒性検出のF1スコアは高いほどよい | 顧客向けチャット、公開サービス、社外利用されるAIアプリ |
| パフォーマンスベンチマーク | レイテンシは低いほどよく、スループットは高いほどよい | リアルタイム応答、チャットUI、バッチ処理 |
| コストベンチマーク | ベンチマーク実行あたりのコストを比較 | モデル候補の費用感の比較、PoC後の概算 |
| シナリオ別ランキング | コーディング、数学、推論、質問応答など用途別に見る | 総合スコアではなく、実際のアプリ用途に近い評価で選ぶ |
| 埋め込みモデルの品質 | 情報検索、クラスタリング、要約などの評価を見る | RAG、社内文書検索、ナレッジ検索 |
品質ベンチマークでは、推論、知識、質問応答、数学、コーディングなどの標準データセットに基づき、exact_match、pass@1、arena_hardなどの指標を平均して品質インデックスを計算します。値は0〜1で、高いほど性能が高いと解釈されます。(Microsoft Learn)
安全性ベンチマークでは、HarmBench、ToxiGen、WMDPなどのデータセットが使われます。HarmBenchの攻撃成功率は低いほどよい一方、ToxiGenのF1スコアは高いほどよい指標です。WMDPはバイオセキュリティ、サイバーセキュリティ、化学セキュリティなどの機密領域の知識を測るため、スコアが高いことは安全性の観点ではリスクとして扱う必要があります。(Microsoft Learn)
パフォーマンスベンチマークでは、レイテンシ、P50、P90、P95、P99、TTFT、GTPS、TTPSなどが確認できます。公式情報では、パフォーマンス指標は14日間、1日24回の試行をもとに集計され、既定では米国東部または米国東部2リージョン、合成データ、単一同時要求などの条件が使われます。実運用ではリージョン、同時実行数、プロンプト長、ストリーミング有無が変わるため、数値をそのまま本番性能として扱わないことが重要です。(Microsoft Learn)
管理者が確認すべき設定
管理者がまず確認すべきなのは、ポータル利用権限、プロジェクト構成、ロール、コスト確認権限です。モデルリーダーボードを見るだけならReaderロールが出発点になりますが、モデルのデプロイ、エージェント利用、評価、監視まで進める場合は追加のロールが必要になります。
特にFoundryでは、Azure Resource ManagerのコントロールプレーンとFoundryのデータプレーンが分かれています。OwnerやContributorはAzureリソース管理では強い権限を持ちますが、エージェント作成やモデル推論などのデータプレーン操作にはFoundry User、Foundry Project Manager、Foundry Ownerなどのロールが必要になるケースがあります。(Microsoft Learn)
管理者は次の項目を確認しておくと安全です。
| 確認項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| Foundryプロジェクト | 対象プロジェクトが新しいFoundryポータルで利用できるか | リーダーボードや比較画面にアクセスできない |
| ロール割り当て | Reader、Foundry User、Foundry Project Managerなどの付与範囲 | 閲覧はできてもデプロイや評価ができない |
| サブスクリプション | 有効な支払い方法があるAzureサブスクリプションか | 検証環境を作れない、機能が利用できない |
| コスト表示 | 課金情報を確認できる担当者がいるか | モデル選定後に費用面で再検討が必要になる |
| ポータルの種類 | FoundryとFoundry classicを混同していないか | ドキュメントや画面手順が合わず、作業が止まる |
名称変更にも注意が必要です。Microsoftは、Azure AI Studio / Azure AI FoundryからMicrosoft Foundryへ進化したと説明していますが、AzureリソースタイプはMicrosoft.CognitiveServices/accountsのままです。ドキュメントやポータル上で旧名称と新名称が混在する可能性があるため、運用手順書では「Azure AI Foundry（Microsoft Foundry）」のように併記しておくと、チーム内の認識違いを減らせます。(Microsoft Learn)
開発者がモデル選定で見るべきポイント
開発者は、リーダーボードを「上位モデルを選ぶ画面」ではなく、「要件に合わないモデルを早めに除外する画面」として使うと効果的です。
たとえば社内FAQチャットを作る場合、品質インデックスが高いモデルだけを選ぶのでは不十分です。回答の根拠性、RAGで使う埋め込みモデルの品質、ユーザーが待てる応答時間、問い合わせ数に対するスループット、ガードレールとの組み合わせまで確認する必要があります。
| ユースケース | 優先すべき指標 | 補足 |
|---|---|---|
| 社内FAQ・RAG | 埋め込み品質、質問応答、根拠性、レイテンシ | 検索精度が低いと、生成モデルが強くても回答品質は上がりにくい |
| 顧客向けチャット | 安全性、TTFT、P95/P99レイテンシ、コスト | 有害出力対策と応答速度の両方が重要 |
| コード生成支援 | コーディング系シナリオ、品質、コンテキスト長、機能サポート | 関数呼び出しや構造化出力が必要かも確認する |
| バッチ要約 | コスト、スループット、品質 | リアルタイム性より総処理コストを重視しやすい |
| 機密領域を扱うAI | 安全性、WMDP、Guardrails、監査ログ | ベンチマークだけで許可判断しない |
Foundryポータルでは、モデルリーダーボード、トレードオフチャート、シナリオ別リーダーボード、最大3モデルの横並び比較を使ってモデルを比較できます。横並び比較では、パフォーマンスベンチマーク、モデル詳細、対応エンドポイント、機能サポートなどを確認できます。(Microsoft Learn)
開発者が特に見落としやすいのは、モデルのベンチマークスコアとアプリ全体の品質は一致しないという点です。RAGアプリなら検索インデックス、チャンク設計、プロンプト、引用の出し方、ガードレール、キャッシュ、UIの待ち時間も品質に影響します。リーダーボードで候補を3つ程度に絞ったら、必ず自社データで評価してください。
実務で使えるモデル選定の手順
モデルリーダーボードを使う場合は、次の流れで進めると判断がぶれにくくなります。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | ユースケースを決める | チャット、RAG、コード生成、要約、分類などを明確にする |
| 2 | シナリオ別リーダーボードを見る | 用途に近いベンチマークを優先する |
| 3 | 品質・安全性・性能・コストを比較する | 1つの指標だけで決めない |
| 4 | 2〜3モデルを横並び比較する | 機能サポート、エンドポイント、コンテキスト長も確認する |
| 5 | プレイグラウンドまたは検証環境で試す | 実際のプロンプトと入力データで動作を見る |
| 6 | 自社データで評価する | 正答率、拒否すべき応答、コスト、遅延を測る |
| 7 | 本番展開前に運用設計を確認する | 監視、ガードレール、ログ、権限、予算アラートを確認する |
特にトレードオフチャートは、品質とコスト、品質と安全性、品質とスループットのように、競合しやすい条件を視覚的に比較するのに役立ちます。公式手順でも、モデルリーダーボードページで比較対象の指標を切り替え、モデルを追加・削除しながら確認できると説明されています。(Microsoft Learn)
移行・展開で注意すべきポイント
Model benchmarks and leaderboards自体は、主にモデル選定を支援する機能です。ただし、Azure AI FoundryからMicrosoft Foundryへの移行や、新しいFoundryポータルでの開発を進めるチームでは、周辺の移行ポイントも同時に確認しておく必要があります。
Microsoftの移行ドキュメントでは、Azure AI Studio / Azure AI FoundryからMicrosoft Foundryへの名称・構成変更に加え、SDKやAPIの変更も案内されています。たとえば、azure-ai-inferenceパッケージは2026年5月30日に廃止予定とされ、Assistants APIは2026年8月26日に終了予定とされています。現在のFoundry体験では、openaiパッケージやazure-ai-projects 2.x、Responses APIへの移行が重要になります。(Microsoft Learn)
展開時は、次の点を確認してください。
| 注意点 | 確認内容 |
|---|---|
| モデルがデプロイ可能か | リーダーボードに出ていても、対象リージョンやエンドポイントで使えるとは限らない |
| Benchmarksタブがあるか | すべてのモデルにベンチマーク結果が公開されているわけではない |
| 対応機能 | 関数呼び出し、構造化出力、Vision、コンテキスト長などを確認する |
| リージョンとレート制限 | 実運用リージョン、TPM/RPM、同時実行数を確認する |
| SDKとサンプルコード | 新旧ポータルやSDKバージョンの不一致を避ける |
| ガードレール | ベンチマーク時の条件と本番時の安全設定を分けて考える |
公式のトラブルシューティングでも、モデルがリーダーボードに表示されない、Benchmarksタブがない、ベンチマークスコアが自社結果と異なる、3モデルを超えて横並び比較できない、といったケースが挙げられています。ベンチマークが古く見える場合は、モデル詳細ページで評価日を確認することも推奨されています。(Microsoft Learn)
安全性ベンチマークを過信しない
安全性スコアは非常に重要ですが、これだけで本番利用の可否を決めるのは危険です。Microsoft Learnでも、安全性は複数の側面を持つ複雑なテーマであり、単一のオープンソースベンチマークだけで全シナリオの安全性を表すことはできないと説明されています。(Microsoft Learn)
また、HarmBenchやToxiGenのベンチマークはFoundry Guardrailsがオフの状態で実行される説明があり、WMDPでは既定のFoundry Guardrailsがオンの状態で実行される説明があります。つまり、ベンチマークの安全性スコアは、実際の本番環境で設定するガードレール、プロンプト制御、監査、人間のレビュー体制と同じ条件ではありません。(Microsoft Learn)
顧客向けのAIアプリでは、次のように多層で考えるのが現実的です。
| レイヤー | 対策例 |
|---|---|
| モデル選定 | 安全性ベンチマーク、WMDP、毒性検出などを確認する |
| 入出力制御 | システムプロンプト、禁止事項、出力フォーマットを設計する |
| Guardrails | 有害コンテンツ、著作権、機密情報、脱獄対策を設定する |
| 評価 | 自社の禁止質問、攻撃的プロンプト、誤回答パターンでテストする |
| 運用 | ログ監視、アラート、ユーザーフィードバック、定期再評価を行う |
特に、医療、金融、法律、セキュリティ、採用、人事評価など、判断ミスの影響が大きい領域では、ベンチマーク上位モデルであっても人間の確認フローを組み込むべきです。
コストとパフォーマンスの見方
コストベンチマークは、モデル間の費用感を比較するうえで便利です。ただし、実際の請求額を正確に予測するものではありません。公式情報では、コストベンチマークは品質ベンチマークデータセットで各モデルを実行する実際のコストを測定し、入力、推論、出力トークン数、推論作業構成、データセットの複雑さなどをもとに計算するとされています。(Microsoft Learn)
一方で、ベンチマークの制限事項として、実際のコストはワークロードによって異なり、価格変更の影響も受けるとされています。パフォーマンスについても、固定された入力・出力トークン比率、単一リージョン、合成ワークロードで収集されるため、本番環境では同時実行数、リージョン、デプロイ構成によって変わります。(Microsoft Learn)
開発チームは、次のような簡易見積もりを作ると判断しやすくなります。
| 見積もり項目 | 例 |
|---|---|
| 1リクエストあたりの平均入力トークン | 1,500トークン |
| 1リクエストあたりの平均出力トークン | 400トークン |
| 1日あたりのリクエスト数 | 20,000件 |
| ピーク時の同時実行数 | 50 |
| 許容TTFT | 2秒以内 |
| 許容P95レイテンシ | 8秒以内 |
| 月間予算 | 例：30万円以内 |
この表をもとに、リーダーボード上の候補モデルを実際のワークロードでテストすれば、「品質は高いが遅すぎる」「安いが安全性評価が弱い」「スループットは良いが機能サポートが不足する」といった判断がしやすくなります。
よくある失敗と回避策
Model benchmarks and leaderboardsを使うとモデル選定は楽になりますが、使い方を誤ると逆に判断を間違えます。
| 失敗しやすいポイント | なぜ問題か | 回避策 |
|---|---|---|
| 品質インデックスだけで選ぶ | コスト、速度、安全性が要件に合わない可能性がある | 用途別に重視指標を決める |
| 総合ランキングだけを見る | コーディングやRAGなど特定用途では最適でないことがある | シナリオ別ランキングを見る |
| 安全性スコアを過信する | 実環境のプロンプトやガードレール条件とは異なる | 自社の危険プロンプトで評価する |
| コストベンチマークを請求額と同一視する | 実際のトークン量や価格変更で変わる | 実ワークロードで試算する |
| すべてのモデルが比較対象だと思う | リーダーボードは選定されたモデルが対象 | Benchmarksタブの有無を確認する |
| プレビュー機能を本番判断の唯一の根拠にする | SLAなし、機能制限の可能性がある | PoC、評価、運用設計を分ける |
| 新旧ポータルやSDKを混同する | 手順やAPIが合わず実装エラーになる | FoundryとFoundry classic、SDKバージョンを確認する |
モデルリーダーボードは、モデル選定を「勘」から「比較」に変える便利な機能です。ただし、最終的な成功を決めるのは、リーダーボードの順位ではなく、実際のアプリ要件に合わせて評価・展開・監視まで設計できているかです。
まず何をすべきか
Azure AI Foundryでモデル選定を進めている場合、まずFoundryポータルで対象プロジェクトを開き、モデルカタログのリーダーボードを確認してください。次に、用途に近いシナリオランキングを見て、候補モデルを2〜3個に絞ります。その後、横並び比較で品質、安全性、コスト、スループット、対応エンドポイント、機能サポートを確認し、自社データで評価します。
管理者は、Foundryプロジェクトのロール、サブスクリプション、ポータルの種類、SDK移行方針、デプロイ先リージョンを確認してください。開発者は、リーダーボードの上位モデルをそのまま採用するのではなく、アプリの実データ、実プロンプト、実トラフィックを使って検証することが重要です。
Model benchmarks and leaderboardsは、Azure AI Foundryにおけるモデル選定の入口として有効です。品質、安全性、コスト、パフォーマンスの4軸を使い、候補を絞る。そこから自社データで評価し、ガードレール、監視、コスト管理まで確認してから展開する。この流れを標準化することで、モデル選定の属人化を減らし、より安全で説明しやすいAIアプリ開発につなげられます。
コメント