MENU

Azure AI Foundry評価と通常API呼び出しの料金比較とコスト最適化ガイド

Azure

Azure AI Foundry の「評価」機能を試してみたら、思ったより課金が膨らんで驚いた――そんな声をよく耳にします。本記事では、評価と通常API呼び出しで何が違うのかを料金の観点から分解し、ざっくりとしたコスト見積もりの方法と、PoCや本番運用で想定外のコスト増を防ぐための具体的な設計・運用Tipsをまとめます。

目次

Azure AI Foundryの料金モデルを整理する

まずは前提として、Azure AI Foundry（Microsoft Foundry）は基本的に「従量課金（トークン課金）＋オプション機能」の組み合わせで料金が決まります。モデル自体の推論は、OpenAI や Llama、Phi などのモデルごとに 1,000トークン単位の単価が決まっており、サーバーレス／プロビジョンドスループットのどちらでも利用できます。

加えて、評価・安全性チェック・観測（observability）など、周辺機能にも課金メーターが存在します。特にSafety Evaluations（安全評価）用トークンは、通常のモデルトークンとは別メーターでカウントされ、価格も別に設定されています。

つまり、「評価」と「通常API呼び出し」の一番大きな違いは、

  • 呼び出すモデルの回数が増える
  • 一部で Safety Evaluations トークン という別メーターが追加で動く

という点にあります。

評価と通常API呼び出しの課金の違い

通常のAPI呼び出し（単発推論）のイメージ

通常API呼び出し（たとえば chat.completions や Foundry の「Playground」上の1回の実行）は、ざっくり次のような構造です。

  • ユーザーのプロンプト＋システムメッセージなど → 入力トークン
  • モデルから返ってくるテキスト → 出力トークン
  • これらに対して、モデルごとの単価（1,000トークンあたり）で課金

また、エージェントや一部の機能では、入力と出力に対して自動的なコンテンツセーフティ／安全評価が走るため、請求明細上に 「Safety Evaluation Input Tokens」 のような項目が現れることがあります。

ただし通常の「1回のチャット」レベルであれば、

  • モデル呼び出し：1〜数回
  • Safety Evaluations：1回のやりとりに対して自動実行（無効化可能なケースもあり）

程度なので、設計さえシンプルならコストは比較的読みやすい状態です。

評価ジョブの内部で何が起きているか

一方、Azure AI Foundry の「評価」機能を使うと、1件のテストケースであっても内部では複数のモデル呼び出しが行われます。公式ドキュメントでは、評価指標として次の3カテゴリが紹介されています。

  • AI quality (AI assisted)：LLMを「採点者」として使う指標（Groundedness, Relevance, Coherence など）
  • AI quality (NLP)：ROUGE, BLEU, F1 などの数学ベース指標（LLMは不要）
  • Risk and safety metrics：暴力・差別・性的表現・自傷などの有害コンテンツ／安全性評価

評価ジョブを走らせると、1レコード（1テストケース）につき、典型的には次のような流れになります。

  1. テストデータの1行をターゲットモデル（またはエージェント）に投げる（通常の推論）
  2. 得られた応答を、AI quality (AI assisted) evaluator で採点する（LLMによる追加入力・出力）
  3. 必要に応じて、AI quality (NLP) evaluator で統計的スコアを計算（トークン課金はほぼ発生せず）
  4. Risk and safety evaluator を有効にしている場合、Foundry が用意した GPT-4 系のモデルで安全性チェック（Safety Evaluations トークン）

さらに、テストデータ生成（Synthetic Dataset Generation）や adversarial simulator を使っていると、評価前段階の「テストデータ生成」の時点でも LLM 呼び出しが追加で行われます。

評価ジョブと通常APIのざっくり比較

項目通常API呼び出し評価ジョブ
モデル呼び出し回数通常1リクエストあたり1回（＋安全フィルタ）1テストケースで生成＋複数の評価モデル呼び出し
AI-assisted Quality評価通常は手動で実装しない限りなし有効化するとLLMジャッジが毎件実行される
Risk & Safety評価エージェントなど一部で自動実行（オプション）評価に組み込むと Safety Evaluations トークンで別途課金
課金メーターモデルの入力/出力トークン＋一部セーフティトークンターゲットモデル＋LLMジャッジモデル＋Safety Evaluations など複数
コストの読みやすさ比較的シンプル評価設計によって大きく変動しやすい

このため、同じデータセットを「通常APIで1回ずつ叩いてログだけ見る」のと、「Foundry の評価機能でAI-assisted評価＋Safety評価込みで回す」のでは、後者のほうがトークン総量が増えやすく、結果として請求額も増えやすい構造になっています。

AI-assisted評価とSafety Evaluationsの料金の中身

AI-assisted Quality評価：LLMジャッジ分がそのまま課金

Azure AI Foundry Blog では、Intent Resolution / Tool Call Accuracy / Task Adherence などの品質評価メトリクスは「追加料金なし」としつつも、内部的には Azure OpenAI モデルをジャッジとして呼び出すため、そのトークン分は通常のモデル課金として請求されることが明示されています。

つまり、

  • 本番で使いたいモデル A（たとえば GPT-4o）で回答を生成
  • ジャッジ用モデル B（安価な GPT-4o mini など）で「Groundedness」「Relevance」などを採点

といった構成にすると、1件のテストケースに対して少なくとも「モデルA＋モデルB」の2系統のトークン課金が発生することになります。

Risk & Safety Evaluations：専用トークンメーターと単価

コード脆弱性（Code Vulnerability）や Ungrounded Attributes などの新しい安全評価メトリクスについては、Safety Evaluations という専用メーターでの課金がアナウンスされています。公式ブログでは、2025年4月時点で次のような価格例が示されています。

  • 入力トークン：Azure Machine Learning – Safety Evaluations Input tokens 約 $0.02 / 1,000 トークン
  • 出力トークン：Azure Machine Learning – Safety Evaluations Output tokens 約 $0.06 / 1,000 トークン

これらは通常のLLMトークンとは別メーターで請求され、明細上も「Safety Evaluation Input Tokens」のような名前で現れます。

さらに、Foundry の安全評価サービスは GPT-4 系モデルを使ってアドバーサリアルな攻撃のシミュレーションやラベリングを行うため、そもそものトークン単価がやや高めに設定されている点にも注意が必要です。

まとめ：なぜ「評価は高くなりやすい」のか

以上を踏まえて整理すると、

  • ターゲットモデルの推論トークン（通常APIと同じ）
  • AI-assisted Qualityのジャッジ用LLMトークン（モデルBなど）
  • Risk & Safety Evaluations 用の Safety Evaluations トークン

のように、1テストケースで複数種類のトークンが積み上がる構造になっているため、「評価は通常APIより高くなりやすい」という結論になります。

コストをざっくり見積もる手順

ステップ1：小さなサンプルで「実測」する

最も確実でシンプルなのは、いきなり本番データ全量を流さずに、まずは 20〜50件程度のテストデータで評価ジョブを1回回し、そのときのトークン消費を実測する方法です。

  • 評価対象：本番で想定しているモデル／エージェント構成
  • 評価指標：Groundedness / Relevance / Coherence など、使う予定の指標のみ
  • Risk & Safety：本当に必要なものだけをON

実行後は、

  • 評価結果画面のメトリクス／ログ
  • Observability／Cost Management のメトリクス

などから、対象期間のトークン消費と金額を確認します。

ステップ2：1件あたりの平均トークンを算出

サンプル実行で得られた数値から、1件あたりの平均トークンを概算します。ここではざっくり以下の3種類に分解しておくと後々便利です。

  • Tgen：ターゲットモデル（本番想定モデル）の平均トークン（入力＋出力）
  • Tjudge：AI-assisted Quality ジャッジ用モデルの平均トークン
  • Tsafety：Safety Evaluations トークンの平均（入力＋出力）

サンプルN件分のトークンを集計できる場合、イメージは次のようになります。

平均トークン（ターゲット）   Tgen  ≒  Σ tokens_gen / N
平均トークン（ジャッジ）     Tjudge ≒  Σ tokens_judge / N
平均トークン（Safety）       Tsafety ≒ Σ tokens_safety / N

ステップ3：本番想定件数でスケールさせる

あとは、想定する評価件数を掛け合わせれば概算が出せます。

概算トータルトークン
  ≒ サンプル数 × (Tgen + Tjudge + Tsafety)

概算コスト
  ≒ 概算トータルトークン（モデル別に分解）
     × それぞれの1,000トークン単価

より厳密にやるなら、モデルごと・メーターごとに分解して計算します。

評価総コスト ≒
  件数 × Tgen × 単価_ターゲットモデル
+ 件数 × Tjudge × 単価_ジャッジモデル
+ 件数 × Tsafety × 単価_SafetyEvaluations

単価自体は Azure の Foundry Models pricing / OpenAI pricing ページ、および Safety Evaluations の価格表から取得できます。

ステップ4：Azure Pricing Calculator と Cost Management を組み合わせる

より運用寄りに考えるなら、Azure Pricing Calculator と Cost Management を使って「見積り」と「実績監視」をセットで行うのがおすすめです。Microsoft の公式ドキュメントでも、Foundry のコスト管理手順として以下が案内されています。

  • Pricing Calculator で Azure OpenAI / Content Safety / Azure AI Search など関連リソースを見積もる
  • 実際の利用が始まったら Cost Management でメーター別のトレンドを確認
  • 予算（Budget）とアラートを設定し、急増時にメールなどで通知

評価ジョブのために一時的に大量トラフィックを流す場合も、事前に Budget を設定しておけば、「予算の 80% に到達したら通知」のような形でブレーキをかけやすくなります。

コスト増の主因を分解する

主因1：テストケース×指標数 × モデル数で実行回数が膨らむ

評価ジョブの費用が膨らむ最大要因は、単純に 実行回数の多さ です。

要素説明コストへの影響
テストケース数評価対象データの行数行数に比例してトークンも比例
評価指標の数Groundedness / Relevance / Coherence / Safety …AI-assisted 指標が多いほどLLM呼び出しが増加
モデル数ターゲットモデル＋ジャッジモデル＋Safety Evaluationsそれぞれ別メーターで課金

たとえば、

  • テストケース：10,000件
  • ターゲットモデル呼び出し：1回
  • AI-assisted Quality 指標：3種類（1メトリクス＝1回のLLM呼び出しと仮定）
  • Safety Evaluations：1回

とすると、1件あたり 1（生成）＋3（品質）＋1（安全）＝5回 分のLLM呼び出しが発生し、トークン量も単純に「通常の約5倍ペース」で増えていきます。

主因2：プロンプト長と max_tokens の設定

もうひとつ見落としがちなのが、評価時のプロンプト設定です。

  • 長大なシステムプロンプトをそのまま評価にも使っている
  • max_tokens をデフォルトのまま大きく設定している
  • ジャッジモデルの「採点理由（reasoning）」をやたら詳細に要求している

といった設定だと、1件あたりのトークン消費が雪だるま式に増えていきます。特にジャッジ用プロンプトは「採点対象の応答＋質問＋評価基準＋出力フォーマット」を詰め込むことが多く、元の生成よりも入力トークンが長くなるケースすらあります。

主因3：Safety Evaluations の単価の高さ

前述のとおり、Safety Evaluations トークンは通常のLLMトークンとは別料金で、入力・出力それぞれに単価が設定されています。2025年4月時点の公式ブログの例では、入力約 $0.02、出力約 $0.06/1,000トークンと案内されており、一般的なLLMトークンと比べるとやや高めです。

そのため、

  • 安全評価を全件に対してフルで走らせる
  • しかもテストデータが長文（RAGの回答など）

といったケースでは、Safety Evaluations だけでかなりの金額になることがあります。

コストを抑えるための具体策

1. 小さく始めて、実測値から設計を見直す

いきなり本番規模で評価を回さず、次のような段階的アプローチを強くおすすめします。

  1. まず 20〜50件で評価を実行
  2. 1件あたりの Tgen / Tjudge / Tsafety を計算
  3. 概算コストを算出し、「このお金を払う価値がある評価か？」を検討
  4. 必要であれば評価指標やモデル構成を見直してから件数を増やす

このサイクルを2〜3回回すだけで、「思ったより高かった…」という事故はかなり減らせます。

2. 評価指標を絞り込む

評価指標は多ければ多いほど安心感がありますが、LLMベースの指標はすべてトークン課金に直結します。おすすめは、

  • ビジネス上の重要度が高い指標だけをAI-assistedにする
  • その他は ROUGE / BLEU などの NLP 指標（トークンを消費しない）で代替する
  • どうしても迷う指標は、最初は OFF にしておき、必要になったタイミングで追加

という「ミニマムセットから始める」方針です。公式ドキュメントのメトリクス定義と入力要件を眺めながら、どの指標が本当に必要かを棚卸しすると、だいたい半分くらいには絞り込めます。

3. 本番モデルとジャッジモデルを分ける

「評価も本番と同じ GPT-4o でジャッジしたほうが精度が高そう」という気持ちは理解できますが、コスト面ではあまり賢い選択ではありません。Azure 公式ブログでも、評価用LLMは Azure OpenAI Service で任意のモデルを指定できることが示されています。

よくある構成パターンは次の通りです。

  • ターゲットモデル：GPT-4o / 強めのモデル（生成品質重視）
  • ジャッジモデル：GPT-4o mini / GPT-3.5 系など、安価モデル

採点用プロンプトを工夫すれば、多少モデルを落としても評価の相対的傾向は十分に把握できます。まずは安価モデルで回し、必要なら一部サンプルだけを高価モデルで再評価する二段構えにするのが現実的です。

4. Safety Evaluations を「本当に必要な範囲」に限定する

Safety Evaluations は非常に有用ですが、そのぶんトークン単価が高いので、次のような切り分けが有効です。

  • 開発初期の赤チーム的なテスト（攻撃的プロンプトを大量に投げる）にはフルで使う
  • 日常的な回帰テストや軽い品質チェックでは、安全指標を OFF または一部だけ ON にする
  • 本番トラフィックに対する 連続評価（continuous evaluation） はサンプリング率を下げる

一部のUIでは「Risk and Safety」チェックを無効化することで Safety Evaluation トークンを抑えられるオプションも案内されています。

5. プロンプトと max_tokens を明示的にチューニングする

評価用のプロンプトは、「とりあえず Playground で動いたプロンプト」をそのまま流用してしまいがちですが、評価では次のような調整を入れるだけでコストがかなり変わります。

  • 不要な説明文やコメントを削り、評価に必要な条件だけを残す
  • 「1000文字以上で詳しく書いてください」のような指示を避ける
  • ジャッジモデルの出力フォーマットを「スコア＋短い理由」に絞る
  • max_tokens を現実的な上限に下げる（例：512 → 128〜256 など）

特に「理由の説明」を大量に生成させると、Safety Evaluations と合わせて出力トークンが一気に増えるので、まずはコンパクトな出力に寄せてから必要に応じて広げていくのが安全です。

6. 評価を自前スクリプト＋Evaluation SDKで制御する案

Foundry のUIから評価ジョブを実行すると非常に楽ですが、「どの指標をどの順番で回すか」「どこで止めるか」を細かく制御したければ、Azure AI Evaluation SDK を使って自前のスクリプトで評価フローを組む方法もあります。

  • 必要な evaluator だけをまとめて実行
  • 行数が多すぎる場合、途中で中断して結果を保存
  • 一部はローカルで実行しつつ、LLM呼び出しだけ Azure に飛ばす

といった制御がしやすくなり、「意図せず1万件分の評価を最後まで回してしまった」という事故も避けられます。トークン課金そのものは変わりませんが、どこまで回すかを自分で決められるのが大きなメリットです。

想定外のコスト急増を抑える仕組みづくり

1. Azure Cost Management で予算アラートを設定する

Microsoft のコスト管理ドキュメントでは、Foundry を含むAIワークロードの費用管理として、Cost Management の 予算（Budgets） と アラート の活用が基本として紹介されています。

  • Foundry プロジェクト用のリソースグループに対して、月次の予算を設定
  • 50% / 80% / 100% などの達成時にメール通知
  • Safety Evaluations や Azure OpenAI を個別に監視するため、メーター別フィルタを利用

特に PoC 期間中は、Safety Evaluations を含む Foundry 関連メーターに対して短い期間（1〜3日）の予算アラートを設定しておくと安心です。

2. Observability と連続評価の設定を慎重に

Foundry には、エージェントやアプリケーションの本番トラフィックに対して、連続評価（continuous evaluation） を行う機能があります。品質や安全性を継続的にモニタリングできる一方、サンプリング率の設定を誤ると、思わぬトラフィック量に評価がかかってしまいます。

  • 最初は小さいサンプリング率（例：1〜5%）から始める
  • Safety Evaluations を連続評価に含めるかどうかを慎重に決める
  • 連続評価とバッチ評価で指標を分け、「重い評価」はバッチ側に寄せる

「全トラフィックを常にフル評価する」構成は、よほど予算に余裕があるケースを除き避けたほうがよいでしょう。

3. Playground / エージェントの利用を制限する

Microsoft のリファレンスアーキテクチャでは、「本番サブスクリプションでのPlayground利用は制限したほうがよい」と明示されています。

Playground やエージェントのGUIは便利ですが、

  • ユーザーが気軽に大量のリクエストを投げられる
  • Safety Evaluations を含む各種機能が自動で ON になっていることがある

といった理由で、意図しないコスト増の温床にもなります。「本番環境では API 経由のみ」「Playground は検証用サブスクリプションでのみ使用」といったガバナンスルールを明文化しておくと安心です。

よくある落とし穴と回避策

落とし穴何が起きるか回避策
全量データ＋多指標でいきなり評価1ジョブで数百万〜数千万トークンを消費し、請求が跳ね上がる必ず小さなサンプルから実測し、段階的に件数を増やす
プロンプトと max_tokens をデフォルトのまま不要に長いプロンプト／出力でトークンが無駄に増加評価用に短いプロンプトを別途設計し、max_tokens を現実的な値に調整
Safety Evaluations を常時フルONSafety Evaluations トークンの単価が高く、評価コストの大半を占める赤チーム的テストと日常評価を分け、必要な場面だけフルONにする
コスト監視・予算アラートを設定していない評価ジョブを長時間回しても気づかず、月末に請求額を見て驚くCost Management でプロジェクト単位の Budget とアラートを必ず設定
Playground で自由に評価実験開発者が好きなだけトラフィックを流し、Safety Evaluations も動くPlayground 利用を検証サブスクリプションに限定し、本番環境はAPI経由に統一

最小実行プラン（これだけやれば安全に始められる）

最後に、「これから Azure AI Foundry の評価を本格的に使い始める」チームに向けて、現実的なスタートプランをまとめます。

  1. 20〜50件のテストデータで評価を1回実行
    本番に近いプロンプト／モデル／評価指標で小さく回し、トークン消費を実測します。
  2. 評価指標を断捨離
    Groundedness / Relevance など、ビジネス上重要な指標だけを残し、それ以外は最初は OFF。
  3. モデル構成を最適化
    生成＝本命モデル、ジャッジ＝廉価モデル、Safety Evaluations は必要最低限に。
  4. プロンプトと max_tokens を評価向けに再設計
    プロンプトを短くし、max_tokens を絞り、採点理由も短めにする。
  5. Cost Management で予算アラートを設定
    Foundry プロジェクト用に専用の Budget を作り、短いサイクル（週次など）で監視。
  6. Playground 利用ルールと権限を整備
    「本番サブスクリプションでは Playground を使わない」などのルールを明文化。

ここまで整えておけば、「評価を使ったらコストが読めなくなる」という状況から、「評価によるメリットとコストをトレードオフで設計できる」状態に一気に近づきます。

まとめ

  • Azure AI Foundry の評価機能は、1テストケースにつき複数のLLM呼び出し＋Safety Evaluations が走るため、通常API呼び出しに比べてコストが増えやすい構造になっています。
  • AI-assisted Quality評価は追加料金こそかからないものの、ジャッジ用LLMのトークンが通常のモデル課金として積み上がります。
  • Risk & Safety Evaluations は、Safety Evaluations トークンとして別メーターで課金され、トークン単価も一般的なLLMより高めに設定されています。
  • 実行前に小規模サンプルでトークンを実測し、簡単な式で概算することで、おおまかな費用感をつかむことができます。
  • 評価指標の取捨選択・モデルの使い分け・プロンプト／max_tokens の調整・Safety Evaluations の適用範囲の限定によって、コストを大きく抑えつつ十分な評価品質を得ることができます。
  • 最終的には、Azure Pricing Calculator＋Cost Management＋予算アラートと Observability の仕組みを組み合わせることで、評価ジョブによる想定外のコストスパイクを防ぎつつ、安全で高品質な生成AIアプリケーションを継続的に運用できます。

「評価は高いから怖いから使わない」ではなく、「何に対していくら払っているのか」を分解してしまえば、評価機能はコストに見合う価値のある強力な武器になります。まずは小さなデータセットから、評価とコストのバランスを意識した設計を試してみてください。

Azure
評価 コスト最適化 LLM Azure AI Foundry Azure OpenAI

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次