Microsoft Foundry / Azure OpenAIのエージェント活用で、「自社管理のAIゲートウェイ配下にあるモデルを、Foundry Agent Serviceから使いたい」と考えている管理者・プロダクト担当者にとって、2026年4月更新の注目点は Bring Your Own Model to Foundry Agent Service です。結論から言うと、Azure API Managementや非AzureのAIモデルゲートウェイの背後にあるモデルを、Foundryのプロンプトエージェントから利用しやすくなりました。モデルのエンドポイントを自社管理のままにしつつ、Foundry Agent Serviceのエージェント機能を使える点が大きな価値です。MicrosoftDocsの履歴では、2026年4月23日に該当ドキュメントのms.dateが04/23/2026へ更新され、見出しと本文からpreview表記が外されています。(GitHub)
Microsoft Foundry / Azure OpenAIの2026年4月更新で何が重要なのか
今回の更新で押さえるべきポイントは、「モデルをFoundry内に閉じ込める」のではなく、「既存のAIゲートウェイを経由してFoundry Agent Serviceから使う」設計が現実的になったことです。
Microsoftの公式ブログでは、Bring Your Own Model、つまりBYOM for Foundry Agent Serviceについて、Azure API ManagementまたはサードパーティのAIモデルゲートウェイの背後にあるモデルを、Foundry Agent Serviceのプロンプトエージェントに接続できる機能として紹介されています。公開日は2026年4月27日で、同記事では一般提供開始として説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
実務上は、次のような組織に特に関係します。
| 立場 | これまでの悩み | 今回の更新で見直せること |
|---|---|---|
| IT管理者 | AIモデルへのアクセス制御、ログ、ネットワーク境界をどう維持するか | Azure API Managementや既存ゲートウェイを活用し、認証・監査・ルーティングを集約しやすくなる |
| プロダクトオーナー | 特定モデルに依存せず、用途別にモデルを切り替えたい | 複数モデルを接続し、エージェント側で利用モデルを選びやすくなる |
| Microsoftエコシステム利用企業 | Azure OpenAI中心の構成に、外部モデルや自社管理モデルをどう組み込むか | OpenAI互換のChat Completions APIを実装するモデルを、ゲートウェイ経由で接続する選択肢が広がる |
ここで重要なのは、BYOMが「Azure OpenAIの置き換え」ではないことです。Azure OpenAIを使い続ける構成もあります。一方で、複数のAIモデル、社内承認済みモデル、外部プロバイダーのモデルを扱う企業では、ゲートウェイを中心にした統制モデルが作りやすくなります。
Bring Your Own Model to Foundry Agent Serviceとは
Bring Your Own Model to Foundry Agent Serviceは、Azure API Managementや非AzureのAIモデルゲートウェイの背後にあるモデルを、Foundry Agent Serviceから利用するための機能です。Microsoft Learnでは、この機能により、組織がモデルエンドポイントの管理を維持したまま、Foundryのエージェント機能を利用できると説明されています。(Microsoft Learn)
イメージとしては、次のような構成です。
ユーザー / アプリ
↓
Foundry Agent Service
↓
AI gateway
↓
Azure API Management / 他社AIモデルゲートウェイ / 自社ゲートウェイ
↓
モデルエンドポイントFoundry Agent Serviceが直接すべてのモデルを管理するのではなく、エージェントからのモデル要求をゲートウェイに流します。ゲートウェイ側では、認証、レート制限、ログ、ルーティング、セキュリティポリシーなどを適用できます。
BYOMでできること
BYOMの価値は、単に「外部モデルを呼べる」ことではありません。企業利用では、次の点が重要です。
| できること | 実務での意味 |
|---|---|
| 既存のAIゲートウェイ配下のモデルを利用する | すでに整備した認証、監査、ルーティングの仕組みを再利用できる |
| Azure API ManagementをAIモデルアクセスの入口にする | Microsoft Entra ID、サブスクリプションキー、ポリシー、ログなどを組み合わせやすい |
| 非AzureのAIモデルゲートウェイも接続候補にできる | OpenAI互換APIを実装したモデルや、社内管理のモデル基盤を組み込みやすい |
| 複数モデルを1つの接続に登録する | 用途別、地域別、コスト別にモデルを分けて運用しやすい |
| エージェント側ではモデル選択として扱える | プロダクトチームがインフラ詳細を意識しすぎずに検証できる |
Microsoft公式ブログでも、BYOMは既存のエンタープライズゲートウェイを通じたルーティング、ゲートウェイ層でのコンプライアンス・ガバナンス適用、Chat Completions API互換モデルの利用を可能にするものとして説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
今回の更新ポイントを実務目線で整理
2026年4月23日のドキュメント更新では、BYOMに関する扱いがpreviewから一般提供に向けた内容へ整理されたことが大きなポイントです。GitHub上のMicrosoftDocs履歴では、ms.dateが04/14/2026から04/23/2026へ変更され、見出しの(preview)と本文中のpreview表記が削除されています。(GitHub)
Preview前提の検証から、本番導入の設計対象へ移った
Preview機能は、検証には使えても、本番運用ではリスク評価が必要でした。今回の更新により、少なくともドキュメント上は「試験的に触る機能」から「エンタープライズ導入を検討する機能」へ位置づけが変わったと見てよいでしょう。
ただし、本番投入時は次の観点を必ず確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 対象エージェント | 現時点で対象にしているAgent SDKのprompt agentsで利用するか |
| 対象モデル | OpenAI互換のChat Completions APIを実装しているか |
| ゲートウェイ | Azure API Managementか、非Azure・自社管理のAIモデルゲートウェイか |
| 認証 | API key、Managed Identity、OAuth 2.0のどれを使うか |
| データ管理 | 入力データがどの地域・どのプロバイダーに流れるか |
| 責任範囲 | Microsoft管理のモデルではない場合のライセンス、データ保持、責任あるAI対策を誰が担うか |
Microsoft Learnでは、BYOMモデルはAzure Direct Modelsを含まず、Foundryに持ち込むサードパーティモデルを指すと説明されています。また、BYOMモデルを使う場合は、ライセンス、責任あるAIの緩和策、データ取り扱い要件への適合を利用者側が確認する必要があるとされています。(Microsoft Learn)
接続方式は大きく2つ：Azure API Managementか、その他のモデルゲートウェイか
BYOMの接続方式を考えるときは、最初に「Azure API Managementを使うのか」「それ以外のゲートウェイを使うのか」を分けると判断しやすくなります。
| 接続先 | 向いているケース | 主な認証方式 | 判断基準 |
|---|---|---|---|
| Azure API Management | すでにAzure上でAPI管理、認証、ポリシー、ログを統制している | API key、Managed Identity | Microsoft Entra IDやAzure運用基盤と合わせて管理したい場合 |
| Other source / Model Gateway | OpenAI、MuleSoft、自社ゲートウェイ、非AzureのAI基盤を使う | API key、OAuth 2.0 | モデル基盤がAzure外にある、または独自のモデルカタログを持つ場合 |
Azure CLIで作成する場合、Agent ServiceはAPI Management connectionsとModel Gateway connectionsの2種類をサポートします。API ManagementはAzure API Managementを使ったモデルルーティングに向き、Model GatewayはOpenAI、MuleSoft、カスタムゲートウェイなどで静的または動的なモデル検出を使う場合に向くと説明されています。(GitHub)
導入前に必要な前提条件
Microsoft FoundryでBYOMを試す前に、環境と権限を確認します。ここを曖昧にしたまま進めると、接続は作れたのにエージェントから呼べない、認証で失敗する、ログで追跡できないといったトラブルが起きやすくなります。
必須の前提条件
Microsoft Learnでは、前提条件としてAzureサブスクリプション、Microsoft Foundryプロジェクト、AIゲートウェイ用のアクセス資格情報が挙げられています。コマンドラインで管理する場合は、Azure CLI 2.67以降、Python 3.10以降、azure-ai-projects SDKパッケージ2.0.0以降も必要です。(Microsoft Learn)
| 項目 | 内容 |
|---|---|
| Azureサブスクリプション | Foundryリソースや関連リソースを作成・管理するために必要 |
| Microsoft Foundryプロジェクト | エージェントや接続を管理する単位 |
| AIゲートウェイの資格情報 | API Managementのサブスクリプションキー、API key、OAuth 2.0クライアント情報など |
| 権限 | Foundry projectではAzure AI User以上、接続デプロイ先のResource groupではContributorが必要 |
| SDK/CLI | 自動化する場合はAzure CLI、Python、azure-ai-projectsのバージョン確認が必要 |
IT管理者は、検証前に「誰が接続を作成できるか」「誰がモデルをエージェントに割り当てられるか」「ゲートウェイの資格情報を誰が管理するか」を決めておきましょう。
Foundryポータルでの基本的な設定手順
ポータルから設定する場合の流れは、比較的シンプルです。ただし、モデル接続、認証、モデル名、URLパスの指定を間違えると、後段のエージェント作成でつまずきます。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | Microsoft Foundryにサインイン | 対象プロジェクトと親リソースを間違えない |
| 2 | Operate > Admin consoleを開く | 管理者向けの設定画面で作業する |
| 3 | All projectsから対象プロジェクトのParent resourceを選択 | プロジェクト単体ではなく親リソース側の設定を確認する |
| 4 | Admin-connected modelsタブでAddを選択 | ここで外部モデル接続を追加する |
| 5 | Connection Typeを選ぶ | Azure API ManagementまたはOther sourceを選ぶ |
| 6 | 認証方式を設定 | API key、Managed Identity、OAuth 2.0の情報を正確に入力する |
| 7 | Model configurationでモデルを追加 | Deployment name、Model name、Display nameを整理して登録する |
| 8 | AdvancedでAPI versionやURLパスを調整 | Azure OpenAI形式のパスか、OpenAI形式のパスかを確認する |
| 9 | 接続を保存し、Active状態を確認 | InactiveならURL、認証、ネットワーク到達性を確認する |
Microsoft Learnでは、Azure API Managementを選ぶ場合は既存のAPI Managementリソースとモデルデプロイを選択し、モデルはOpenAI互換のchat completions APIを実装している必要があると説明されています。Other sourceを選ぶ場合は、セルフホスト、非Azureホスト、カスタムソリューション向けにBase URLや認証情報を設定します。(GitHub)
URLパス設計で失敗しやすいポイント
BYOM導入で見落としやすいのが、モデル呼び出し時のURLパスです。
Azure OpenAI風のルートでは、次のようにデプロイ名がパスに含まれます。
/deployments/{deploymentName}/chat/completions一方、OpenAI風のルートでは、次のようにデプロイ名をパスに含めない構成もあります。
/chat/completionsFoundryの接続設定では、ゲートウェイがAzure OpenAIスタイルのパスを公開している場合に、deployment nameをURL pathに含める設定を有効化できます。ゲートウェイ側が別のルーティング方式を使っている場合は、この設定を無効のままにする判断も必要です。(GitHub)
実務では、次のように確認すると安全です。
| 確認する場所 | チェック内容 |
|---|---|
| ゲートウェイのAPI定義 | /deployments/{deploymentName}/chat/completions形式か、/chat/completions形式か |
| FoundryのAdvanced設定 | Include deployment name in URL pathを有効にすべきか |
| モデル名の対応表 | Foundry側のDeployment nameとゲートウェイ側のモデル識別子が対応しているか |
| ログ | Foundryから実際に届いたリクエストパスが想定通りか |
ここを間違えると、認証は通っているのにモデルが見つからない、またはゲートウェイで404になることがあります。
エージェントからモデルを使うときのポイント
接続を作成したら、次はプロンプトエージェントでそのモデルを使います。標準的なモデル指定と異なる点は、モデルデプロイ名の形式です。
Microsoft Learnでは、モデルデプロイ名として次の形式を使う点が重要だと説明されています。(GitHub)
<connection-name>/<model-name>たとえば、接続名がmy-apim-connection、モデル名がgpt-4oなら、次のように指定します。
my-apim-connection/gpt-4oこの形式を間違えると、model not foundエラーの原因になります。エージェント開発チームとインフラチームが別組織の場合は、接続名とモデル名の命名規則を先に決めておくことをおすすめします。
命名規則の例
| 用途 | 接続名の例 | モデル名の例 | 完成形 |
|---|---|---|---|
| 本番APIM経由 | prod-apim-ai | gpt-4o | prod-apim-ai/gpt-4o |
| 検証環境 | dev-model-gateway | small-chat | dev-model-gateway/small-chat |
| 地域別ルーティング | eu-ai-gateway | approved-chat | eu-ai-gateway/approved-chat |
プロダクト側にはDisplay nameで分かりやすく見せ、SDKや運用手順ではDeployment nameを厳密に扱う、という分担が現実的です。
認証方式の選び方
BYOMでは、認証方式の選択がセキュリティ設計に直結します。簡単さだけでAPI keyを選ぶと、後からローテーションや監査の負担が増えることがあります。
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| API key | 検証環境、単純なゲートウェイ認証、既存APIキー運用がある場合 | キーの保管、ローテーション、漏えい時の停止手順を明確にする |
| Managed Identity | Azure API ManagementとFoundryをAzure上で統合管理したい場合 | FoundryプロジェクトのManaged Identity有効化とAPIM側のトークン検証設定が必要 |
| OAuth 2.0 | 非Azureゲートウェイ、外部IdP、クライアント資格情報フローを使う場合 | client secret、scope、token URLの管理が必要 |
Azure API ManagementでManaged Identity認証を使う場合、Foundryプロジェクトリソースでシステム割り当てまたはユーザー割り当てManaged Identityを有効化し、API Managementのinbound policyでvalidate-azure-ad-tokenを使ってトークンを検証する流れが示されています。(GitHub)
本番環境では、可能な限り人が直接扱う長期固定キーを減らし、IDベースの認証や短期トークンを使える構成を検討しましょう。
管理者が必ず確認すべきガバナンス項目
BYOMは便利ですが、モデルを持ち込む分だけ責任範囲が広がります。特にIT adminsやセキュリティ担当者は、次の項目を導入前チェックリストに入れてください。
| 項目 | 確認内容 | 見落とした場合のリスク |
|---|---|---|
| データ保存場所 | プロンプト、添付データ、応答がどの地域・事業者に渡るか | 組織のデータ所在地要件に違反する可能性 |
| ライセンス | BYOMモデルの利用条件、商用利用可否、再配布条件 | 契約違反や利用停止リスク |
| 責任あるAI | コンテンツフィルター、メタプロンプト、安全策をどこで実装するか | 有害出力や不適切応答への対策不足 |
| 監査ログ | Foundry、ゲートウェイ、モデルプロバイダーのどこでログを残すか | 障害調査や説明責任を果たせない |
| レート制限 | 部門別、アプリ別、ユーザー別の制限をどう設定するか | コスト急増やサービス劣化 |
| ネットワーク | パブリック接続か、ネットワーク分離か | 意図しない露出や到達性トラブル |
Microsoft Learnでは、BYOMモデル利用時には責任あるAIの緩和策、データ取り扱い要件、第三者のデータ保持・データ所在地の実務を利用者側が確認する必要があると明記されています。(Microsoft Learn)
サポートされる構成と制限を確認する
導入判断では、「何でも接続できる」と考えないことが大切です。Microsoft Learnでは、BYOM機能はAgent SDKのprompt agentsでサポートされると説明されています。また、サポートされるagent toolsとしてCode Interpreter、Functions、File Search、OpenAPI、Foundry IQ、SharePoint Grounding、Fabric Data Agent、MCP、Browser Automationが挙げられています。(GitHub)
ネットワーク面では、API Managementとセルフホストゲートウェイの両方でパブリックネットワークがサポートされています。フルネットワーク分離を行う場合、API ManagementをAI gatewayとして使う構成ではFoundryとAPI Managementを合わせてデプロイするテンプレートが案内され、セルフホストゲートウェイではAgent Serviceが使う仮想ネットワーク内からゲートウェイエンドポイントに到達できる必要があります。(GitHub)
導入前に、次のように判断すると失敗しにくくなります。
| 判断 | BYOMが向いている | まだ慎重に検討すべき |
|---|---|---|
| モデルAPI | OpenAI互換のChat Completions APIを実装している | 独自APIで互換性が低い |
| 運用体制 | ゲートウェイ運用、ログ監査、認証管理の担当がいる | モデル提供元任せで責任分界が曖昧 |
| エージェント用途 | prompt agentを中心に構築する | 未対応のエージェント種別や独自ワークフローが中心 |
| セキュリティ | APIMやIdPで制御を統一したい | データ越境や第三者モデル利用の承認が未整備 |
| 変更管理 | モデル名、接続名、バージョンを管理できる | 検証環境と本番環境の命名が混在している |
よくあるトラブルと対処法
BYOM導入で多いトラブルは、モデル自体の性能ではなく、接続、認証、名前、ネットワークに起因します。
| 症状 | 主な原因 | 対処 |
|---|---|---|
| ConnectionがInactiveになる | ゲートウェイURLが間違っている、資格情報が無効 | endpoint URL、API key、OAuth設定、APIMの設定を確認 |
model not foundが返る | モデル名の指定形式が誤っている | <connection-name>/<model-name>形式で指定する |
| 認証エラーになる | API key、Managed Identity、OAuth設定の不一致 | APIMのサブスクリプションキー、OAuth scope、token URL、Managed Identityのclient IDを確認 |
| タイムアウトする | Agent Serviceからゲートウェイに到達できない | ネットワーク到達性、VNet、Private Link相当の設計、ゲートウェイのログを確認 |
| 404やルーティング失敗になる | URLパス形式が合っていない | deployment nameをURL pathに含めるかどうかを確認 |
| 応答は返るが監査できない | ログ設計が不十分 | Foundry、APIM、外部ゲートウェイのログを相関できるID設計を行う |
Microsoft Learnのトラブルシュートでも、Inactive状態ではゲートウェイURLと認証情報、model not foundではFOUNDRY_MODEL_DEPLOYMENT_NAMEの形式、タイムアウトではAgent Serviceネットワークからの到達性、認証失敗ではAPI keyやOAuth 2.0設定の確認が案内されています。(GitHub)
Azure OpenAI利用企業にとっての実務的な意味
Azure OpenAIをすでに使っている企業にとって、BYOMは「Azure OpenAIをやめるための機能」ではありません。むしろ、Azure OpenAIを含む複数モデル戦略を管理しやすくするための選択肢です。
たとえば、次のような使い方が考えられます。
| シナリオ | BYOMの使い方 |
|---|---|
| 部門ごとに利用可能モデルを制御したい | APIM側で部門別のサブスクリプション、レート制限、ログを管理する |
| Azure OpenAIと外部モデルを比較したい | ゲートウェイ配下に複数モデルを登録し、Foundry Agent Service側で検証する |
| 地域別にモデルアクセスを分けたい | EU、米国、日本などのゲートウェイを分け、接続名で管理する |
| 社内承認済みモデルだけを使わせたい | ゲートウェイ側でモデルカタログを制限し、Foundry側には承認済みDeploymentだけを表示する |
| プロダクトごとにコスト上限を設けたい | APIMやゲートウェイでレート制限、クォータ、ログ集計を行う |
プロダクトオーナーにとっては、モデル選定の自由度が上がります。一方で、IT管理者にとっては、モデル利用を「無秩序な外部API呼び出し」ではなく「統制されたゲートウェイ経由のアクセス」として設計できる点が重要です。
導入時のおすすめ手順
本番導入を急ぐ前に、次の順序で小さく検証するのが安全です。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 事前整理 | 対象モデル、ゲートウェイ、認証方式、データ分類を決める | 利用可能モデルと責任者が明確になっている |
| 接続検証 | Foundryにモデル接続を追加する | 接続がActiveになり、ゲートウェイログにリクエストが出る |
| エージェント検証 | prompt agentからBYOMモデルを呼び出す | 期待する応答が返り、model not foundなどが出ない |
| ガバナンス検証 | ログ、レート制限、監査、データ境界を確認する | セキュリティレビューに耐えられる |
| 限定公開 | 特定チーム・特定ユースケースで利用する | コスト、品質、障害対応手順を確認できる |
| 本番展開 | 命名規則、運用手順、変更管理を標準化する | 複数チームが同じルールで利用できる |
最初の検証では、複雑なツール連携を増やしすぎない方がよいでしょう。まずは単純なプロンプトエージェントでモデル接続、認証、ログ、ルーティングを確認し、その後にFile Search、Functions、OpenAPIなどのツール連携へ広げる方が原因切り分けが簡単です。
導入判断のチェックリスト
最後に、Microsoft Foundry / Azure OpenAI環境でBYOMを検討する際のチェックリストをまとめます。
- OpenAI互換のChat Completions APIを実装したモデルを用意している
- Azure API ManagementまたはAIモデルゲートウェイを運用できる
- Foundry projectの権限とResource groupの権限を整理している
- API key、Managed Identity、OAuth 2.0のどれを使うか決めている
- モデル接続名とモデル名の命名規則を決めている
- URLパスにdeployment nameを含めるか確認している
- ゲートウェイログでFoundryからのリクエストを追跡できる
- BYOMモデルのライセンス、データ保持、データ所在地を確認している
- 責任あるAI対策をFoundry側、ゲートウェイ側、アプリ側のどこで実装するか決めている
- prompt agentを中心にしたユースケースから始める計画になっている
まとめ：BYOMは「モデルの自由度」と「企業統制」を両立するための更新
Bring Your Own Model to Foundry Agent Serviceの2026年4月更新は、Microsoft Foundry / Azure OpenAI周辺のエージェント活用において重要な転換点です。Azure API Managementや非AzureのAIモデルゲートウェイを経由してモデルを接続できることで、企業はモデルエンドポイントを自社管理のまま維持しながら、Foundry Agent Serviceのエージェント機能を使いやすくなります。
一方で、BYOMは責任範囲も広げます。特に、サードパーティモデルのライセンス、データ所在地、ログ、認証、責任あるAI対策は、Microsoft任せにせず自社で設計する必要があります。
次に取るべき行動は明確です。まず、既存のAIゲートウェイと利用予定モデルがOpenAI互換のChat Completions APIに対応しているかを確認してください。そのうえで、検証用のFoundryプロジェクトに1つのモデル接続を作成し、prompt agentから<connection-name>/<model-name>形式で呼び出せるかを確認します。接続、認証、ログ、データ管理が問題なく確認できた段階で、部門別・用途別のモデル展開へ進めるのが安全です。
コメント