Azure AI Foundryでエージェントを作るチームにとって、Bring Your Own Model to Foundry Agent Serviceの要点は「Foundry上でエージェントを動かしながら、モデルへの通信は自社のAI Gateway経由にできる」ことです。つまり、Azure API Managementや社内・サードパーティのモデルゲートウェイを使い、モデルエンドポイント、認証、監査、ルーティングを自社側で管理しつつ、Foundry Agent Serviceのエージェント機能を利用できます。なお、Microsoftの現行ドキュメントではAzure AI FoundryからMicrosoft Foundryへの名称整理が進んでいるため、本記事では日本語圏で検索されやすい「Azure AI Foundry」と、公式表記の「Microsoft Foundry」を併記します。(Microsoft Learn)
Azure AI FoundryのBYOMで何が変わるのか
Bring Your Own Model to Foundry Agent Serviceは、Foundry Agent Serviceから外部のAIモデルゲートウェイ配下にあるモデルを利用するための機能です。公式ドキュメントでは、Azure API Managementや非Azureの管理型AIモデルゲートウェイの背後にあるモデルへ接続でき、Foundryのエージェント機能を使いながらモデルエンドポイントの制御を維持できると説明されています。(Microsoft Learn)
従来のAIエージェント開発では、エージェント基盤、モデル選定、認証、ログ、レート制限、データ取り扱いを同じチームがまとめて設計しがちでした。BYOMを使うと、エージェントの開発・実行はFoundry側、モデルアクセスの統制はゲートウェイ側、という役割分担を作りやすくなります。
| 観点 | これまで課題になりやすかった点 | BYOMで整理しやすくなる点 |
|---|---|---|
| モデル接続 | エージェントごとにモデル接続や認証を個別実装しやすい | ゲートウェイ経由でモデル接続を集約しやすい |
| セキュリティ | モデルエンドポイントをどこまで公開するか迷いやすい | モデルを直接公開せず、ゲートウェイ配下で利用できる |
| ガバナンス | ログ、レート制限、アクセス制御が分散しやすい | 既存のAPI ManagementやAI Gatewayのポリシーを活用しやすい |
| 開発 | モデル変更時にエージェント側の修正が大きくなりやすい | 接続名とモデル名を使ったルーティングで管理しやすい |
| 監査 | どのエージェントがどのモデルを呼んだか追いづらい | ゲートウェイログとFoundry側の実行確認を組み合わせられる |
特に重要なのは、BYOMが「好きなモデルを無条件に安全化する機能」ではない点です。公式ドキュメントでは、BYOMモデルはFoundryに持ち込むサードパーティモデルを指し、Azure Direct Modelsは含まれないとされています。また、責任あるAIの軽減策、データ処理要件、データ保持・保存場所、組織のAzureコンプライアンス境界外にデータが流れる可能性の確認は利用者側の責任とされています。(Microsoft Learn)
対象になる構成と対象外になりやすい構成
BYOMの対象は、Azure API Managementまたはその他のAIモデルゲートウェイの背後にあるモデルです。公式手順では、OpenAI互換のChat Completions APIを実装するモデルを追加できると説明されています。(Microsoft Learn)
実務では、次のように判断すると分かりやすいです。
| 利用したい構成 | 向いている接続タイプ | 判断基準 |
|---|---|---|
| 既にAzure API Managementでモデルルーティングを管理している | API Management接続 | APIMの標準的なエンドポイント、認証、ポリシーを活用したい場合 |
| OpenAI、MuleSoft、独自プロキシ、社内AI Gatewayなどを使っている | Model Gateway接続 | 静的または動的なモデル検出を使いたい場合 |
| Azure Direct Modelsをそのまま使いたい | BYOMではなく通常のFoundryモデル利用 | BYOMモデルの定義にはAzure Direct Modelsが含まれない |
| OpenAI互換のChat Completions APIを実装していない独自API | そのままでは不向き | ゲートウェイ側で互換APIに変換できるか確認が必要 |
API Management接続は、Azure API Managementの標準規則に沿った既定値を使える構成です。一方、Model Gateway接続は、OpenAI、MuleSoft、カスタムゲートウェイなどを使う場合に選び、静的モデル検出と動的モデル検出の両方に対応します。(Microsoft Learn)
管理者が最初に確認すべき設定
BYOMは開発者だけで完結する設定ではありません。プロジェクト権限、リソースグループ権限、ゲートウェイ認証、ネットワーク到達性、データ処理方針まで含めて管理者が先に確認する必要があります。
権限とツールの前提条件
公式ドキュメントでは、Azureサブスクリプション、Microsoft Foundryプロジェクト、AI Gatewayの資格情報が前提として挙げられています。CLIで接続を管理する場合は、Azure CLI 2.67以降、Python 3.10以降、azure-ai-projects SDKパッケージ2.0.0以降が必要です。(Microsoft Learn)
| 確認項目 | 必要な内容 | 見落としやすいポイント |
|---|---|---|
| Foundryプロジェクト権限 | Foundry Userまたは同等以上の権限 | ドキュメントや画面で旧ロール名が残る場合がある |
| リソースグループ権限 | 接続デプロイ用にContributor相当が必要 | 開発者にプロジェクト権限だけ付けても接続をデプロイできない場合がある |
| ゲートウェイ資格情報 | APIMサブスクリプションキー、APIキー、OAuth 2.0資格情報など | キーのローテーション手順を事前に決めておく |
| SDK・CLI | Azure CLI、Python、azure-ai-projectsのバージョン確認 | 古いSDKサンプルを使うと新しいFoundry構成と合わないことがある |
Microsoftのドキュメントでは、FoundryのRBACロール名がAzure AI UserなどからFoundry Userなどへ整理されており、移行期間中は旧名称が表示される可能性があるとも説明されています。権限を確認するときは、表示名だけでなくロールIDや実際の操作権限も確認すると安全です。(Microsoft Learn)
認証方式の選び方
API Management接続では、APIキーまたはマネージドIDを利用できます。マネージドIDを使う場合は、Foundryプロジェクト側でシステム割り当てまたはユーザー割り当てのマネージドIDを有効化し、API Management側でMicrosoft Entra IDトークンを検証するポリシーを設定します。(Microsoft Learn)
その他のソース、つまりセルフホステッド、非Azureホステッド、カスタムソリューションに接続する場合は、APIキーまたはOAuth 2.0を使います。OAuth 2.0では、クライアントID、クライアントシークレット、トークンURL、スコープなどを設定します。(Microsoft Learn)
実務上の判断基準は次の通りです。
| 認証方式 | 向いているケース | 注意点 |
|---|---|---|
| APIキー | 検証環境、単純なゲートウェイ認証、既存APIMサブスクリプションキーを使う場合 | キー漏えい対策、ローテーション、環境ごとの分離が必須 |
| マネージドID | Azure内でAPIMとFoundryを統合し、資格情報の直接管理を減らしたい場合 | APIM側のトークン検証ポリシー、audience、クライアントID設定が必要 |
| OAuth 2.0 | 非AzureのAI GatewayやIDプロバイダーと統合する場合 | トークン期限、スコープ、シークレット管理、監査ログの確認が必要 |
開発者が確認すべき実装ポイント
開発者にとって最も重要なのは、標準的なエージェントとBYOM接続のモデル指定方法が異なる点です。公式ドキュメントでは、モデルデプロイ名を<connection-name>/<model-name>形式で指定することが、標準エージェントとの主な違いだと説明されています。model not foundエラーが出る場合も、この形式を確認するよう案内されています。(Microsoft Learn)
FOUNDRY_PROJECT_ENDPOINT=https://<your-ai-services-account>.services.ai.azure.com/api/projects/<project-name>
FOUNDRY_MODEL_DEPLOYMENT_NAME=<connection-name>/<model-name>たとえば、接続名がmy-apim-connection、モデル名がgpt-4oなら、指定値は次のようになります。
my-apim-connection/gpt-4oこの形式を環境変数や設定ファイルに切り出しておくと、開発環境、ステージング、本番環境で接続先を切り替えやすくなります。反対に、コード中にモデル名を直書きすると、ゲートウェイ名の変更やモデル承認リストの更新時に修正漏れが起きやすくなります。
URLパスの設定はゲートウェイ仕様に合わせる
BYOMの設定では、ゲートウェイがAzure OpenAI風のパスを使うか、OpenAI風のパスを使うかを確認する必要があります。公式手順では、ゲートウェイが/deployments/{deploymentName}/chat/completionsのようにデプロイ名をURLパスに含める場合は「Include deployment name in URL path」を有効にし、/chat/completionsのようにデプロイ名を含めない場合は無効のままにすると説明されています。(Microsoft Learn)
ここは失敗しやすいポイントです。ゲートウェイ側がヘッダーやリクエスト本文でモデルを振り分ける設計なのに、Foundry側でデプロイ名をURLパスに含めると、404、認証失敗、想定外モデルへのルーティングが起きる可能性があります。逆に、ゲートウェイ側がデプロイ名入りのパスを前提にしているのに設定を無効にすると、モデル解決ができません。
管理者と開発者で分担すべき確認リスト
BYOM導入では、管理者と開発者の確認範囲を分けないと、障害時に「Foundryの問題なのか、ゲートウェイの問題なのか、モデルの問題なのか」が切り分けにくくなります。
| 担当 | 確認すること | 完了の目安 |
|---|---|---|
| 管理者 | Foundryプロジェクト、RBAC、接続作成権限 | 接続作成者と運用者の権限が明確になっている |
| 管理者 | APIMまたはModel Gatewayの認証方式 | APIキー、マネージドID、OAuth 2.0のどれを使うか決まっている |
| 管理者 | データ処理・保持・地理的境界 | BYOMモデルへ送信されるデータの扱いをレビュー済み |
| 管理者 | ネットワーク到達性 | Agent Serviceからゲートウェイへ到達できる |
| 開発者 | モデル指定形式 | <connection-name>/<model-name>で指定できている |
| 開発者 | テストプロンプト | Foundry側で応答を受け取れる |
| 開発者 | ゲートウェイログ | Agent Serviceからのリクエストが記録されている |
| 開発者・管理者 | 障害時の切り分け | 401、404、timeout、model not foundの確認手順がある |
展開時に注意すべきネットワークとサポート範囲
公式ドキュメントでは、サポートされる構成として、Agent SDKのプロンプトエージェントのみがこの機能をサポートするとされています。また、Code Interpreter、Functions、File Search、OpenAPI、Foundry IQ、SharePoint Grounding、Fabric Data Agent、MCP、Browser Automationなどのツールがサポート対象として挙げられています。(Microsoft Learn)
ネットワークについては、API Managementとセルフホステッドゲートウェイの両方でパブリックネットワークがサポートされています。完全なネットワーク分離を行う場合、API ManagementをAI Gatewayとして使う構成ではFoundryとAPI Managementを一緒にデプロイするテンプレートが案内され、セルフホステッドゲートウェイではAgent Serviceが使う仮想ネットワーク内からゲートウェイエンドポイントへ到達できる必要があります。(Microsoft Learn)
ここでの実務上の注意点は、疎通確認を「開発者のPCからゲートウェイにアクセスできるか」だけで判断しないことです。必要なのは、Agent Serviceからゲートウェイへ到達できることです。社内ネットワーク、Private Link、VNet、APIMの受信制限、ID検証ポリシーを入れている場合は、Foundry側からの実リクエストで確認してください。
デプロイ後の検証手順
公式ドキュメントでは、デプロイ後に接続状態、テストプロンプト、ゲートウェイログを確認する流れが示されています。接続がInactiveの場合はゲートウェイエンドポイントURLと資格情報を確認し、API Managementの場合はAzureポータルのAPI Management分析、その他のゲートウェイではリクエストログを確認します。(Microsoft Learn)
| 症状 | 主な原因 | 確認する場所 |
|---|---|---|
| 接続がInactiveになる | URL誤り、資格情報不正、ゲートウェイ到達不可 | Foundryの接続済みリソース、ゲートウェイ設定 |
model not foundが返る | モデル名の形式誤り、接続名とモデル名の不一致 | FOUNDRY_MODEL_DEPLOYMENT_NAME |
| タイムアウトする | Agent Serviceからゲートウェイへ到達できない | ネットワーク、APIM受信制限、VNet、Firewall |
| 認証エラーになる | APIキー、OAuth 2.0、マネージドID設定の不一致 | APIMポリシー、IDプロバイダー、シークレット |
| 想定外のモデルが呼ばれる | ゲートウェイ側ルーティング設定の誤り | ゲートウェイログ、ヘッダー、URLパス、モデルマッピング |
検証では、単に「応答が返る」だけでなく、次の3点まで見ることをおすすめします。
1つ目は、ゲートウェイログにFoundry Agent Serviceからのリクエストが残っていることです。2つ目は、リクエストが想定したモデルデプロイにルーティングされていることです。3つ目は、失敗時にFoundry側、ゲートウェイ側、モデル側のどこで止まっているかを切り分けられることです。
BYOMを使うべきケース、使わない方がよいケース
BYOMは、エンタープライズ環境で特に効果を発揮します。たとえば、すでにAzure API ManagementでAPI統制をしている組織、AI Gatewayでレート制限や監査を行っている組織、モデルの承認リストを中央管理したい組織には向いています。
| 判断軸 | BYOMが向いているケース | 慎重に判断すべきケース |
|---|---|---|
| ガバナンス | モデルアクセスをゲートウェイで統制したい | 小規模検証で統制要件がほとんどない |
| セキュリティ | モデルエンドポイントを直接公開したくない | ゲートウェイの認証・ログ設計が未整備 |
| モデル選択 | 複数モデルや外部モデルを承認制で使いたい | 利用モデルのライセンスやデータ処理を確認していない |
| 開発運用 | エージェントとモデル基盤の責任分界を分けたい | 開発者だけで全設定を管理している |
| ネットワーク | VNetやAPIMを含む本番設計を行う | Agent Serviceからゲートウェイへの到達性を検証できない |
特に、サードパーティモデルや非Azureゲートウェイを使う場合は、データ保持、ログ保存、学習利用、保存リージョン、障害時の責任範囲を事前に確認してください。BYOMは接続の柔軟性を高めますが、コンプライアンス判断を自動化するものではありません。
移行・展開で失敗しないための進め方
最初から本番の全エージェントをBYOMへ切り替えるより、次の順番で進めると安全です。
| ステップ | 実施内容 | 成功条件 |
|---|---|---|
| 事前整理 | 使うゲートウェイ、認証方式、対象モデルを決める | 接続タイプと責任者が明確 |
| 最小構成の接続 | 1モデルだけをFoundryに接続する | 接続がActiveになる |
| 開発者検証 | <connection-name>/<model-name>でプロンプトエージェントを動かす | テストプロンプトで応答が返る |
| ログ確認 | ゲートウェイ側でリクエストを確認する | 想定モデルに正しくルーティングされている |
| セキュリティ確認 | データ処理、RAI軽減策、認証、ネットワークをレビューする | 本番利用可否を判断できる |
| 段階展開 | 対象エージェントを限定して展開する | エラー率、レイテンシ、ログが監視できる |
本番展開前には、少なくとも「誰が接続を作るのか」「誰がゲートウェイ認証を管理するのか」「モデル名の変更を誰が通知するのか」「障害時にどのログを先に見るのか」を決めておきましょう。ここが曖昧なまま展開すると、エージェントの品質問題が発生したときに、プロンプト、モデル、ゲートウェイ、ネットワークのどこを直すべきか分からなくなります。
まず取るべき次のアクション
Azure AI FoundryでBring Your Own Model to Foundry Agent Serviceを検討するなら、最初にやるべきことは、モデル接続を作ることではありません。まず、現在のモデルアクセス経路を棚卸ししてください。
既にAzure API Managementを使っているなら、APIM接続を前提に、認証方式、URLパス、デプロイ名、ログ確認方法を整理します。APIM以外のAI Gatewayを使っているなら、Model Gateway接続を前提に、OpenAI互換のChat Completions API、APIキーまたはOAuth 2.0、モデル検出方式を確認します。そのうえで、1つのプロンプトエージェントと1つのモデルだけで疎通確認し、Foundry側の応答とゲートウェイ側ログの両方を見てから対象を広げるのが安全です。
BYOMは、Azure AI Foundryを「モデルを直接呼ぶ場所」から「エージェントを運用し、モデルアクセスは組織のゲートウェイで統制する場所」へ近づける機能です。導入効果を出すには、開発スピードだけでなく、認証、監査、データ処理、ネットワーク、障害切り分けまで含めて設計することが重要です。
コメント