ヘッドウォータース
🔐

Microsoft Foundry の AI モデル利用を、認証・RBAC・ログ・安全機能に絞って整理する

毎熊　星湾
に公開
Azure
rbac
Microsoft Entra
Azure OpenAI
Microsoft Foundry
tech

Microsoft Foundry を調べていると、Agent、APIM、MCP、周辺の統制機能まで話題が広がりがちです。

ただ、実際に最初に知りたいことはもっとシンプルで、「Foundry の AI モデルをどう認証して呼ぶのか」「どこまで権限を絞れるのか」「何がログとして追えるのか」「安全機能はどこまで built-in なのか」 だったりします。

そこで本記事では、2026-04-14 時点の Microsoft Learn をベースに、Microsoft Foundry の AI モデルを Entra 認証または API キーで利用する場合 に話を絞って整理します。

今回はあえて、

  • APIM との組み合わせ
  • Agent identity の深掘り
  • MCP / A2A 連携
  • Gateway 的な外部制御

は外し、純粋に Foundry 側で持っているモデル利用機能 を中心に見ます。

先に結論

先に要点だけまとめると、Microsoft Foundry の AI モデル利用は次のように整理できます。

  • 認証方式は Entra ID と API キーの 2 本立て
    • 本番運用は Entra ID が基本
    • API キーは PoC や単体疎通確認向け
  • RBAC は「Foundry のロール」と「推論用ロール」を分けて考えると分かりやすい
    • Foundry portal / project 利用は Azure AI User など
    • モデル推論の keyless access は Cognitive Services User が中心
  • Owner / Contributor でも推論できるとは限らない
    • 管理権限と推論権限は別物
  • ログは 2 層で見る
    • API レスポンス内の usage / content filter 結果
    • Azure Monitor 側の診断ログ・監視
  • AI Content Safety はモデルやデプロイ方式によって built-in の度合いが違う
    • serverless の言語モデルでは統合フィルタが入りやすい
    • managed compute では別途 Content Safety API を使う前提が残る
  • スループット設計は PTU が要点
    • Foundry / Azure OpenAI のスループット予約単位は PTU（Provisioned Throughput Units）
    • 高トラフィック・低ぶれ重視なら provisioned、可変負荷なら standard が基本
  • モデル差異はかなりある
    • Azure OpenAI 系は API と機能が最も揃っている
    • その他の Foundry Models は、デプロイ方式・サポート・安全機能の入り方がモデルごとに異なる

一言でいえば、「認証は Entra、権限は RBAC、運用監視はログ、安全対策は Content Safety、性能設計は PTU」 の 5 点を押さえると、Foundry のモデル利用はかなり見通しがよくなります。

認証の詳細

認証方式は 2 つ

Microsoft Foundry でモデルを利用する場合の認証方式は、基本的に次の 2 つです。

方式 向いている用途 特徴
Microsoft Entra ID 本番運用、社内アプリ、権限制御が必要な環境 OAuth 2.0、RBAC と連動、監査しやすい
API キー PoC、簡易接続、単体検証 実装は簡単だが、権限制御と監査は粗い

Microsoft Learn でも、本番用途は Microsoft Entra ID 推奨 という整理です。理由は単純で、API キーは「鍵を持っている主体」を細かく区別しにくく、最小権限や監査に弱いからです。

Entra ID 認証の実装要点

Entra ID でのトークン取得時に使うスコープは次です。

  • https://ai.azure.com/.default

また、トークンベース認証には custom subdomain が必要です。地味な要件ですが重要で、リージョナル endpoint のままだとトークン認証が成立しないため、見落とすと原因特定に時間を取られやすい箇所です。

実務的には、Entra ID 認証を成立させる前提は次の 3 点です。

  1. Foundry resource に custom subdomain がある
  2. 呼び出し主体に適切なロールが付与されている
  3. https://ai.azure.com/.default 向けトークンを正しく取得している

Entra ID で使う主体

Entra ID で使える主体は、典型的には次の 4 種類です。

  • ユーザー principal
  • Service Principal
  • System-assigned Managed Identity
  • User-assigned Managed Identity

アプリから Foundry を呼ぶなら、運用面では Managed Identity が第一候補 です。シークレットを環境変数に配置する必要が減り、ローテーション作業もほぼ Azure 側に寄せられます。

API キー認証の位置づけ

API キーは依然として使えます。

  • 言語や SDK に依存しにくい
  • 疎通確認が速い
  • すぐに始めやすい

一方で弱点も明確です。

  • 利用者単位の識別が難しい
  • 権限を細かく分けにくい
  • キーが漏れると基本的に resource 単位で広く効く
  • 監査上は「そのキーを知っていた誰か」になりやすい

そのため、API キーは初期の導入時には便利だが、本番運用の本命ではない と考えた方がよいです。

使い分けの実務感

ざっくり言うと、次の判断でほぼ困りません。

  • まず動かす → API キーでも可
  • アプリに組み込む → Entra ID に寄せる
  • 社内向け本番 → Entra ID 前提
  • 最小権限・監査が必要 → Entra ID 一択

RBAC

まず control plane と data plane を分けて考える

Foundry の権限設計は、control plane と data plane を分けるのが出発点です。

区分 何をする層か 例
Control plane リソースや構成を管理する project 作成、deployment 作成、キー操作、設定変更
Data plane 実際にモデルを使う chat completions、embeddings、fine-tuning 実行、content safety 呼び出し

ここが分かれるので、

  • リソース管理者
  • モデルを使う開発者
  • デプロイを作る人
  • 監視だけ見る人

を同一人物にしなくて済みます。

Foundry の built-in ロール

Foundry 側の代表ロールは、Role-based access control for Microsoft Foundry で整理されている次の 4 つです。

ロール 主な用途
Azure AI User 最小権限の利用者ロール。モデル利用や project 内作業の基点
Azure AI Project Manager project 作成・管理、開発リード向け
Azure AI Account Owner resource 側の高権限管理
Azure AI Owner control plane / data plane を広く扱う高権限

Foundry portal で project を使う、モデルを試す、既存 deployment を使う、といった文脈では Azure AI User が起点 です。

ただし「推論 API を Entra ID で叩くロール」は別軸で見る

ここが少しややこしいのですが、Foundry portal / project のロール と、推論 endpoint に対する keyless access のロール は、実務上は分けて理解した方が安全です。

Foundry Models の Entra ID 認証ドキュメント では、推論 API 呼び出し側の代表ロールは Cognitive Services User とされています。

つまり、モデル利用に関しては次のように読むと分かりやすいです。

観点 主に見るロール
Foundry portal / project 利用 Azure AI User などの Foundry ロール
モデル推論 endpoint の keyless access Cognitive Services User

カスタムロールも作れる

もし Cognitive Services User や Foundry built-in roles が強すぎる場合は、カスタムロールを作れます。

Foundry Models の keyless inference 用 docs では、少なくとも次の dataActions を含む例が示されています。

  • Microsoft.CognitiveServices/accounts/MaaS/*

このあたりまで来ると、

  • モデル推論だけ許可
  • 管理変更は禁止
  • 特定の resource scope のみ許可

といった設計が現実的になります。

Owner / Contributor では足りないことがある

ここはかなり重要です。

role assignment の実務ポイント

運用面で押さえたいポイントは次です。

  • 可能なら Microsoft Entra group に対してロール付与する
  • resource scope と project scope を混ぜずに設計する
  • role assignment の反映には数分かかることがある
  • Check access で実際に見える権限を確認する

大人数運用では、個人に直接付与するより グループ単位での運用 の方が管理コストを大きく下げられます。

ロギング

まず「Foundry 単体で見えるもの」と「Azure Monitor で追うもの」を分ける

モデル利用のログは、大きく 2 層で見ると整理しやすいです。

  1. 推論 API のレスポンスに含まれる情報
  2. Azure Monitor / 診断ログに送る運用ログ

Agent tracing のような span ベース tracing は現在の docs では主に Agent / Workflow 寄りの説明が中心なので、単純なモデル推論だけを見る場合は、レスポンス metadata と Azure Monitor を主役 と考えるのが自然です。

API レスポンスから見えるもの

Azure OpenAI 系モデルでは、レスポンスに次のような情報が含まれます。

  • usage.prompt_tokens
  • usage.completion_tokens
  • usage.total_tokens
  • 一部モデルでは reasoning_tokens
  • system_fingerprint
  • prompt_filter_results
  • content_filter_results

つまり、少なくとも

  • どれだけ token を使ったか
  • Content Safety / content filter がどう反応したか
  • backend fingerprint が変わったか

はレスポンスから把握できます。

user パラメータの意味

Azure OpenAI 系 API では user フィールドを渡せます。

これは認証そのものではありませんが、エンドユーザー識別子として abuse monitoring を助ける ためのものです。

そのため、

  • アプリ利用者 ID
  • 社内のユーザー識別子
  • セッション連携用の匿名 ID

などを入れる設計は有効です。ただし、直接的な個人情報をそのまま入れるかは社内ポリシー次第です。

Azure Monitor 側のログ

Microsoft の セキュリティ best practices では、Azure OpenAI / Foundry 系利用に対して diagnostic logs を Azure Monitor に送る ことが推奨されています。

追いたい観点は典型的に次です。

  • API request
  • token usage
  • content filtering results
  • errors

つまり、アプリ運用としては

  • レスポンス usage をアプリ側でも記録
  • Azure Monitor 側で診断ログを集約
  • 必要に応じて Log Analytics で分析

という二段構えが分かりやすいです。

どこまでが Foundry の built-in か

ここは期待値調整が必要です。

  • モデル応答単位の usage / content filter 結果 → built-in でかなり見える
  • 長期保存・横断分析・アラート → Azure Monitor 連携が主役
  • 細粒度の実行トレース → 現時点では Agent / Workflow 系が中心

そのため、モデル利用だけなら「Foundry 単体で全部が見える」というより、Foundry + Azure Monitor で完成 と理解した方が実態に近いです。

AI コンテンツセーフティーなどの監査

serverless の言語モデルには統合フィルタが入りやすい

Foundry Models overview と Guardrails docs を読むと、serverless API でデプロイした言語モデル には、Azure AI Content Safety ベースの既定フィルタが入る整理です。

対象として代表的に出てくるカテゴリは次です。

  • Hate
  • Self-harm
  • Sexual
  • Violence

しかも、入力と出力の両方に対して同期的に評価されます。

既定しきい値

classic docs ですが、Azure 直販モデルの guardrails 説明では次の既定値が示されています。

  • テキストモデル: medium 以上でフィルタ
  • 画像モデル: low 以上でフィルタ

このへんは「何も設定しないと無防備」ではなく、最初からある程度の安全弁が入っている と見るとよいです。

ただし、全部のモデルで同じではない

ここは重要です。

  • embedding models には統合 content filtering がない
  • time series models にも統合 content filtering がない
  • managed compute では、Azure AI Content Safety を別途使う前提が強い

つまり、Content Safety の入り方はモデル種別とデプロイ方式で変わる ということです。

Content Safety を別サービスとして使える

Azure AI Content Safety 自体は独立した Azure AI サービスなので、Foundry から使う場合でも次の機能を別途組み合わせられます。詳しくは Content moderation features を見ると一覧しやすいです。

  • Analyze text API
  • Analyze image API
  • Prompt Shields
  • Protected material text detection
  • Groundedness detection（preview）
  • Task adherence API
  • Custom categories（preview）

特に generative AI 文脈では、次の 2 つが目立ちます。

  • Prompt Shields: jailbreak / prompt injection 系の検知
  • Protected material: 既知テキストとの一致検知

Azure OpenAI 系のレスポンスではフィルタ結果も返る

Azure OpenAI の REST reference では、次のようなフィルタ結果が返る構造が定義されています。

  • prompt_filter_results
  • content_filter_results
  • jailbreak
  • profanity
  • protected_material_text
  • protected_material_code

また、ポリシー違反時には内部エラーコードとして次が返るケースがあります。

  • ResponsibleAIPolicyViolation

つまり、安全機能は「裏で動いているだけ」ではなく、API の応答にも反映される ということです。

チューニングや無効化はできるか

Azure 直販モデルの serverless deployment では、docs 上、content filtering を deployment ごとに切り替えられる説明があります。

  • 初回デプロイ時に設定
  • デプロイ詳細画面で後から変更

ただし、ここはモデルやポータルの世代差分もあるため、「すべてのモデルで自由自在に細かく制御できる」とまで考えない方が安全 です。

また、content filtering は無効化して終わりではなく、無効化した場合は自前で Azure AI Content Safety を組み込まないと、当然ながらリスクは上がります。

監査として何が残るか

安全機能の観点で追えるものは、実質的には次の 3 層です。

  1. レスポンス中の content filter 結果
  2. Azure Monitor 側の診断ログ
  3. Content Safety Studio / Content Safety API の監視情報

そのため、「監査」の意味を広く取るなら、Foundry 側だけで完結するというより、Foundry の推論 + Content Safety + Azure Monitor の合わせ技 で実現するイメージです。

PTU などの設定

「TPU」は、実質 PTU を指すと考えてよい

Foundry / Azure OpenAI の最新 docs では、スループット予約の単位は PTU（Provisioned Throughput Units） です。

ユーザー会話で「TPU」と言われることもありますが、Microsoft Learn 上の正式な用語は PTU です。

deployment type の基本整理

Foundry Models の deployment types には、代表的に次の種類があります。

種類 課金 主な用途
Global Standard Pay-per-token まず使う標準形
Global Provisioned Reserved PTU 高スループット・低ぶれ
Global Batch 割引バッチ 大量非同期処理
Data Zone Standard Pay-per-token US / EU data zone 要件
Data Zone Provisioned Reserved PTU data zone + 安定性能
Standard Pay-per-token 単一リージョン要件
Regional Provisioned Reserved PTU 単一リージョン + 安定性能
Developer Pay-per-token fine-tuned model の評価用

standard と provisioned の違い

ざっくり言うと次の差です。

観点 Standard Provisioned
課金 従量 PTU 予約
向く負荷 バースト・変動 継続高負荷
遅延のぶれ 比較的大きい 比較的小さい
SLA / 性能の期待 ベストエフォート寄り 予測しやすい

高トラフィックでレイテンシぶれを嫌うなら、Provisioned を検討する価値があります。

PTU の意味

Provisioned 系では、一定量の処理能力を PTU として予約 します。

重要なのは、PTU は単純な「1 PTU = 何 request/sec」の固定値ではないことです。docs でも、

  • モデルごと
  • バージョンごと
  • デプロイ種別ごと

に必要 PTU や得られる throughput が異なると説明されています。

つまり、PTU は CPU コア数のような完全な共通単位ではなく、モデル依存の正規化された容量指標 と考える方が正確です。

data residency と deployment type

デプロイ種別は性能だけでなく、どこで処理されるか にも効きます。

  • Global: Azure 全体で柔軟に処理
  • Data Zone: US か EU のゾーン内で処理
  • Standard / Regional Provisioned: 単一リージョン中心

なので、要件が

  • コスト優先
  • データ居住要件優先
  • レイテンシ安定性優先

のどれかで、選ぶ deployment type が変わります。

すべてのモデルがすべての deployment type を持つわけではない

これはかなり大事です。

  • モデルごとに対応 deployment type が違う
  • region ごとに availability が違う
  • preview / limited access の制約があるモデルもある

そのため、「Global Provisioned で使いたい」と思っても、そのモデルがその region / type に対応しているとは限らない です。

まず model card や region availability 表を見るのが先です。

モデルごとの差異

まず大きくは「Azure OpenAI 系」と「それ以外」で見る

Foundry Models overview では、モデルカタログは大きく次の 2 系統で見られます。

  • Azure OpenAI を含む Azure 直販モデル
  • partners / community モデル

ここでいう差異を、モデル利用の観点だけでまとめると次のようになります。

観点 Azure OpenAI 系 その他の Foundry Models
API surface かなり整理されている。Chat Completions / Responses / Embeddings / Audio / Images など モデルごとに差が大きい
認証 API キー / Entra ID の両方が明確にサポートされる API キー / Entra ID が基本だが、モデル・提供形態により対応差あり
deployment type Global / Data Zone / Provisioned / Batch など選択肢が多い provider が deployability を決めるケースが多い
built-in content filter Azure OpenAI の応答仕様まで含めて見えやすい serverless / managed compute / モデル種別で差が大きい
サポート Microsoft 側の統合度が高い provider / community 側に寄る部分がある

Azure OpenAI 系で特に差が出るところ

1. API がモデル系列ごとに違う

Azure OpenAI 系でも、全部が同じ API を使えるわけではありません。

たとえば:

  • chat 系 → Chat Completions / Responses API
  • embeddings 系 → Embeddings API
  • audio 系 → /audio 系 API
  • image 系 → images generation API
  • 一部 codex / reasoning 系 → Responses API 中心

つまり、「Azure OpenAI だから全部同じ呼び方」ではない です。

2. reasoning model はパラメータ差異がある

docs では、たとえば gpt-5.1-chat のような reasoning 系モデルでは、temperature のような従来パラメータがそのまま使えないケースが明記されています。

つまり、モデルを差し替えるときは

  • context length
  • max output
  • 対応 API
  • tools / structured outputs 対応
  • パラメータ互換性

を確認した方がよいです。

3. embeddings は移行コストがある

embeddings モデルは特に注意が必要です。

Learn でも、text-embedding-ada-002 から text-embedding-3-large へは既存のインデックスやベクトルデータをそのまま移行することはできず、全データを再 embedding する必要がある とされています。

ここは chat モデルより移行コストが見えづらいので要注意です。

4. data_sources など Azure OpenAI 専用機能がある

Azure OpenAI の REST reference では、data_sources は Azure OpenAI にのみ互換 とされています。

つまり、RAG や検索連携の API 形状まで含めると、AOAI 系だけが持つ便利機能 があります。

直販モデルでも provider によって差がある

Foundry Models sold directly by Azure には Azure OpenAI 以外にも、DeepSeek、Meta、Mistral、xAI などの一部モデルが含まれます。

ただし、

  • region availability
  • deployment type
  • preview / GA 状況
  • サポート API
  • 安全機能の入り方

は一律ではありません。

そのため、「Foundry にある = Azure OpenAI と同じ運用性」ではない と考えるべきです。

モデル選定時に最低限見るべき項目

モデル差異で最低限チェックしたいのは次です。

  • 認証方式（API キー / Entra ID）
  • 対応 deployment type
  • 利用可能 region
  • preview か GA か
  • Responses API / Chat Completions API の対応
  • multimodal 対応
  • tools / structured outputs 対応
  • content filtering の built-in 有無
  • context window / max output

これを見ないで「同じ GPT 系だからたぶん同じ」と進めると、だいたい後で小さく燃えます。

迷ったときのおすすめ構成

もし「Foundry で安全に AI モデルを使いたい」という前提なら、まずは次の形が無難です。

最小構成

  • 認証: Microsoft Entra ID
  • 権限: Cognitive Services User を基本に必要なら Foundry ロール追加
  • アプリ実行主体: Managed Identity
  • デプロイ種別: Global Standard または Standard
  • ログ: usage をアプリ側で記録 + Azure Monitor 診断ログ
  • 安全対策: serverless の built-in filter を前提にしつつ、必要なら Azure AI Content Safety を追加

こういうときは調整する

  • 安定スループット重視 → Provisioned / PTU
  • US / EU のデータ境界が必要 → Data Zone
  • 単一リージョン要件 → Standard / Regional Provisioned
  • 独自安全基準が強い → Azure AI Content Safety を別途併用
  • Azure OpenAI 固有機能を使いたい → AOAI 系モデルを優先

まとめ

Microsoft Foundry の AI モデル利用を、認証と運用の観点だけに絞ると、重要なのは次の 6 点です。

  1. 認証は Entra ID と API キーの 2 つだが、本番は Entra ID が基本
  2. RBAC は Foundry ロールと推論ロールを分けて考えると整理しやすい
  3. Owner / Contributor でも推論できるとは限らない
  4. ログは API レスポンス metadata と Azure Monitor の両方で見る
  5. Content Safety の built-in 具合はモデル種別と deployment type で違う
  6. 性能設計は PTU と deployment type の選択が本体

特に実務で効くのは、

  • 認証を Entra ID に寄せる
  • RBAC を最小権限で設計する
  • content filtering の入り方をモデルごとに確認する
  • PTU が必要な負荷かを早めに判断する

の 4 つです。

「Foundry は何でもできる」ではなく、どのモデルを、どの deployment type で、どの認証方式で、どの安全機能付きで使うのか を先に分解すると、かなり設計しやすくなります。

参考にした公式ドキュメント

ヘッドウォータース
ヘッドウォータース

株式会社ヘッドウォータースのテックブログです。 AIエージェント、生成AI、Azure、GitHub Copilot、IoT、XR系などData&AIとApp modernizeに関して幅広く投稿します！

Discussion