Microsoft Foundry BYOMとは？仕組み・接続手順・料金を徹底解説

Microsoft Foundry BYOM（旧 Azure AI Foundry / Bring Your Own Model）は、Azure API Management や他社AIゲートウェイの背後にあるモデルエンドポイントを、Foundry Agent Service のプロンプトエージェントから呼び出せるようにする機能です。
2026年4月27日に一般提供（GA）が開始され、Foundryのモデルカタログには載っていない自社運用モデルや他クラウドのモデルもAgent機能と組み合わせて使えるようになりました。

本記事では、通常のFoundry利用との違い、API Management連携とOther source（Model Gateway）という2つの接続方式、対応モデル候補と選び方、基本編・応用編の接続手順、料金とコスト試算、詰まりポイントまでを体系的に整理します。
BYOMの主な用途・制限事項・エンタープライズ展開時の考慮も含めて、2026年5月時点の公式情報をもとに解説します。

Microsoft Foundry BYOMとは？

Microsoft Foundry BYOM（旧 Azure AI Foundry / Bring Your Own Model）は、Microsoft FoundryのAgent Serviceから、Foundryの外側に存在するモデルエンドポイントを呼び出せるようにする接続機能です。Azure API Management や他社AIゲートウェイの背後にあるモデルを、Foundryのプロンプトエージェントから直接利用できます。なお、Microsoft Foundry は2026年に Azure AI Foundry / Azure AI Studio を統合してリブランドされた現行ブランドで、Foundry Agent Service・Foundry Models など主要サービス名にもこの表記が使われています。

2026年4月27日にBYOMの一般提供（GA）がMicrosoft公式ブログで発表されたことで、自社GPUで運用しているモデルや、AWS Bedrock・GCP Vertex AI といった他クラウドのモデル、OpenAI社・NVIDIA社の直契約APIまで、Foundryのエージェント基盤に組み込めるようになりました。

BYOM（Bring Your Own Model）の定義

公式ドキュメントによると、BYOMは「OpenAI互換のchat completions APIを実装するモデルエンドポイントを、AIゲートウェイ経由でFoundry Agent Serviceに接続する仕組み」と定義されています。

具体的には、次のような特性を持ちます。

• 接続先は OpenAI互換のchat completions APIを実装している必要がある
• 認証方式は接続種別に応じて、APIキー・Managed Identity・OAuth 2.0 のいずれか
• 対応するエージェント形式は プロンプトエージェントのみ
• ひとつのゲートウェイ接続に複数モデルを登録でき、それぞれが独立したデプロイ名を持つ

つまりBYOMは「Foundry内にモデルをデプロイする」のではなく、「Foundry外で動いているOpenAI互換エンドポイントを、エージェントから呼び出せるようにする」機能です。

通常のFoundry利用との違い

ここがBYOMで一番誤解されやすいポイントです。「Foundryでモデルを選んで使うこと」と「BYOMを使うこと」は別物で、Foundryのモデル提供は大きく3層に分かれています。

以下の表で、Foundryのモデル提供レイヤーと、それぞれのBYOM該当性を整理しました。

FoundryポータルのUIで「モデルをデプロイ」している場合は1段目か2段目に該当し、Microsoftが管理するエンドポイントを使っています。BYOMはこの2層から外れて、Foundry/Azureの外側にあるモデルをConnection経由でAgentから呼ぶことを指します。

通常Foundry利用との違いを一言でまとめると次のとおりです。

• 通常Foundry利用 Microsoftのモデルカタログから選んでFoundry内にデプロイし、そのデプロイをエージェントから使う
• BYOM Foundry外にすでにあるモデルエンドポイントを、Connection経由でFoundry Agentに繋ぐ

「Foundryのモデルカタログにない」「すでに自社や他社のAPIで動いている」「コンプライアンス上Foundry外のゲートウェイを通したい」といった条件があるときに、初めてBYOMが選択肢に入ります。

GA時点（2026年4月27日）の最新状況

BYOM機能は2026年4月27日にFoundry Agent Service向けに一般提供（GA）されました。GAに伴い、次の構成が正式サポート対象になっています。

• 接続種別：API Management と Other source（Model Gateway） の2方式
• 認証：APIキー・Managed Identity（API Management連携時）・OAuth 2.0クライアントクレデンシャル（Other source時）
• ルーティング：Azure OpenAI形式（/deployments/{name}/chat/completions）・OpenAI形式（/chat/completions）両対応
• 1接続あたり複数モデル登録可（モデルごとに独立したデプロイ名）

一方、Hosted Agents（フレームワークで構築したエージェントをコンテナでホストする方式）は2026年5月時点でもパブリックプレビュー段階で、BYOMはあくまでプロンプトエージェント専用の機能として位置づけられています。

BYOMの主な用途・想定シーン

BYOMは「Foundryに繋げるモデルがないと使えないが、繋げると一気に応用範囲が広がる」タイプの機能です。実務でBYOMが選ばれる典型的なシーンを4つに整理します。

自社GPU・オンプレモデルの活用

すでに自社でNVIDIA TritonサーバやvLLMを立てて、Llama・DeepSeek・自社ファインチューンモデルを運用しているケースは多くあります。これらのモデルを使いつつ、Foundryのエージェント機能（Code Interpreter、File Search、MCP等）を活用したい場合に、BYOMが選択肢になります。

このシーンの典型は次のようなものです。

• 既存GPUクラスタへの投資をそのまま活かして、UI層だけFoundryに寄せたい
• ファインチューンモデルをFoundryのモデルカタログにアップロードせず、自社管理下に留めたい
• 推論結果や入力データを自社ネットワーク内に閉じ込めたい

BYOMを使えば、自社モデルをそのままエージェントの推論基盤として組み込めるため、エージェント機能のためにモデルを別環境に複製する必要がなくなります。

マルチクラウド戦略（AWS Bedrock / GCP Vertex AI 連携）

AWS Bedrock や GCP Vertex AI でモデル契約・運用を進めている企業がFoundry Agent Serviceを使う場合、モデル基盤を移すよりもBYOMで繋ぐ方がコスト・契約面の摩擦が少なくなります。

• AWS Bedrock の Claude / Llama 系を、API Management経由でFoundry Agentから呼ぶ
• GCP Vertex AI の Gemini を、OpenAI互換アダプタ層を介してFoundryに繋ぐ
• 既存の課金契約・コミットメント割引（PTU・Reserved capacity）を活かす

マルチクラウド前提の組織では、Foundryを「エージェントオーケストレーション層」、各クラウドを「モデル提供層」と分けて設計する構成が現実的になります。

SaaSモデルの直契約活用

OpenAI社やAnthropic、Cohere、Together AI 等とすでに直契約しているケースも該当します。Azure OpenAI ServiceではなくOpenAI社直契約のGPT-4を使い続けたい、特定の最新モデルをいち早く使いたい、といった理由でBYOMを選ぶシーンです。

• Azure OpenAIに反映される前のOpenAI社の最新モデルを使いたい
• すでに購入済みのクレジットを消化したい
• 価格交渉や契約条件を直接ベンダーと結んでいる

BYOMの要件はOpenAI互換chat completions APIなので、OpenAI社・Cohere・Together AI 等のOpenAI互換APIを提供するSaaSはそのまま接続できます。一方でAnthropic（Claude Messages API）は仕様が異なるため、OpenAI互換アダプタ（LiteLLM等）やAPIMでの変換ポリシーを挟む構成が前提になります。詳しくはH2#4「BYOMでつなげるモデル候補と選び方」で整理します。

規制・コンプラ要件（VNet外に出せない・既存APIM経由強制）

金融・医療・公共領域では、社外APIへの直接アクセスが禁止されており、すべてのAPI呼び出しを社内のAPI Management（または同等のゲートウェイ）経由にすることが求められるケースがあります。

• 社内ポリシーでAPIM経由のみ許可（直接的なインターネット送信は不可）
• リクエスト・レスポンスのロギング・マスキング・レート制限を既存のゲートウェイで適用
• データの地理的境界（リージョン）を厳密に統制したい

BYOMはAPI Managementを正規の接続方式としてサポートしているため、こうした既存ガバナンス要件をそのまま満たしながら、Foundryのエージェント機能を導入できます。「社内ポリシーがあるからFoundryは導入できない」と判断していた組織でも、BYOMによって導入の道が開けるケースがあります。

BYOMの仕組みと2つの接続方式

BYOMで使える接続方式は2種類あります。それぞれ前提リソース・認証方式・想定読者が異なるため、最初に整理しておくと選択を間違えにくくなります。

以下の表で、2つの接続方式の特徴を比較しました。

接続の種類タブの画面

この比較から見えるのは、「APIMをすでに使っているか／これから使うか」が選択の分岐点になるということです。検証目的やAPIM未導入の組織はOther sourceから入るのが定石、既存APIM資産があるならAPI Management連携を選ぶ、という整理になります。

API Management連携

Azure API Managementをすでに運用している組織向けの接続方式です。Foundryから見ると、Connection作成時に「Azure API Management」を選び、対象のAPIMリソースとモデルデプロイを指定する形になります。

• 想定環境 APIMで複数モデルや複数バックエンドのルーティング・認証・レート制限を一元管理しているケース
• 強み 既存のAPIMポリシー（IP制限、ロギング、レスポンスマスキング等）をそのまま継承できる
• 弱み APIMリソース自体の構築・運用コストが乗る。プラン選択を誤ると月額コストが大きく跳ねる

ガバナンス要件が厳しいエンタープライズでは事実上の標準構成ですが、APIMの構築から始めるなら工数は決して小さくありません。

Other source（Model Gateway）

API Managementを使わず、エンドポイントURLと認証情報を直接Foundryに登録する方式です。FoundryポータルのUI上は「Other source」、CLI・Bicep上は「Model Gateway」と呼ばれていますが、機能としては同じものを指します。

• 想定環境 自社GPUで動かしているvLLM・Triton、SaaS API直契約、他クラウドのインターネット公開エンドポイント
• 強み Azureリソース要件がFoundryプロジェクトだけで済む。検証から本番まで最短経路
• 弱み 既存のAPIMポリシーは継承されない。ガバナンスは接続先側で担保する必要がある

「とりあえず動かしたい」「APIMを挟むほどのガバナンス要件はない」場合、こちらが第一選択になります。記事や検証用途で短時間で試したい場合もOther sourceが適しています。

接続方式ごとの認証オプション

認証方式は接続種別ごとにサポート範囲が異なります。「3種類の認証から選ぶ」というよりは、接続方式に応じて選べる認証が決まると理解した方が正確です。

以下の表で、接続方式と認証オプションの対応関係を整理しました。

API Management連携でManaged Identityを選ぶ場合は、Foundryプロジェクト側でマネージドIDを有効化したうえで、APIM側のinbound policyに validate-azure-ad-token を入れて検証する設定が必要になります。Other sourceのOAuth 2.0は、外部IDプロバイダ（Auth0、Okta等）でクライアントクレデンシャルフローを使うパターンに対応しています。

検証目的であればAPIキー認証が圧倒的に簡単で、本番運用でガバナンスを高めたい場合にManaged IdentityまたはOAuth 2.0へ切り替える、という二段階のアプローチが現実的です。

BYOMでつなげるモデル候補と選び方

BYOMの接続方式が決まっても、「裏側に何のモデルを置くか」で記事や検証の体験は大きく変わります。ここでは現実的な候補4つと、互換性に注意が必要なAnthropic等の扱い、そしてAI総研の実務観点でケース別の使い分けを整理します。

以下の表で、主要なBYOM候補モデルを比較しました。

この表で重要なのは、OpenAI互換chat completions APIを実装しているかが技術的な可否を決める点です。互換性がない場合は、間にOpenAI互換アダプタを挟む構成が必要になります。

OpenAI公式API

Foundryに繋ぐ「他社モデル」として最も自然な候補です。OpenAI社のchat completions APIはBYOMが要求する仕様そのものなので、Connection作成時の設定もシンプルです。

• 強み OpenAI社の最新モデル（GPT-5系）をAzure OpenAIへの反映を待たずに使える
• 弱み Azureリージョンの選択肢に縛られない代わりに、データの地理的境界は自社で管理する必要がある
• 検証コスト $5〜$10のクレジットチャージで記事用検証は十分カバーできる

「BYOMで何ができるかを読者に実感させたい」目的なら、OpenAI公式APIを裏に置くのが最も伝わりやすい構成です。

NVIDIA API Catalog

NVIDIA API CatalogはNVIDIAが提供する開発者向けのモデル試用基盤で、Llama 4・Mistral・DeepSeek-R1・Nemotron 等をOpenAI互換APIで叩けます。開発者向けの無料トライアル枠があるため、検証用途なら追加コストをほぼかけずに使えます。

• 強み 無料トライアル枠の範囲で Llama 4 / DeepSeek-R1 等の話題モデルを試せる
• 弱み 本番運用には別途Enterprise契約（NVIDIA AI Enterprise / NIM）が必要、無料枠はクレジット制で上限あり
• 典型ユースケース 「BYOMで他社モデルを試す」検証記事、PoC

記事内のハンズオンや、社内向けPoCで「コストをかけずにBYOMの効果を見たい」場合に向いています。本番に持っていく段階では、NIMをセルフホストするか、Enterpriseライセンスでの利用を検討します。

GitHub Models

GitHub Modelsは、GitHubアカウントだけで GPT-4o・Llama・Phi・Mistral・Cohere 等をOpenAI互換APIで利用できるサービスです。バックエンドはAzure AIインフラで稼働しており、無料の検証用APIアクセスが提供されています（2026年5月時点でPublic Preview、レート制限あり）。

• 強み GitHubアカウントだけで利用開始、Microsoft陣営完結、本番はMicrosoft Foundryへの移行パスが用意されている
• 弱み 無料利用はPublic Previewでレート制限が厳しめ、本番運用は有料利用への移行（Microsoft Foundryデプロイ等）が前提
• 典型ユースケース 個人開発・小規模検証、Microsoft陣営内でモデルを切り替えたい場合

「Microsoft陣営で完結させつつ、Foundry外のエンドポイントを試したい」場合の選択肢です。本番運用するならGitHub Modelsの無料枠ではなく、Microsoft Foundry側のモデルデプロイへ移行するのが正攻法です。

自前GPU・オンプレモデル

vLLM・NVIDIA Triton・NVIDIA Dynamo等で自社運用しているモデルをBYOMで繋ぐパターンです。OpenAI互換APIを実装している前提なら、エンドポイントURLと認証情報の登録だけで連携できます。

• 強み 自社データを外部に出さない、ファインチューンモデルをそのまま活用できる
• 弱み GPU運用・モデルアップデート・スケーリングを自社で担保する必要がある
• 典型ユースケース 規制業種、独自モデル運用、データ主権が厳しい組織

初期投資は重いものの、運用が回り始めると「Foundryのエージェント機能を活用しつつ、推論基盤は完全に自社管理」という構成が成立します。

Anthropic等の非OpenAI互換モデル

Claudeを含むAnthropicのMessages APIは、OpenAI chat completions APIと仕様が異なります。BYOMの要件はOpenAI互換chat completions APIの実装なので、Anthropicを直接繋ぐことは現状できません。

繋ぐ場合の選択肢は次のとおりです。

• OpenAI互換アダプタを自前で実装 LiteLLM等のOSSプロキシを挟む
• API Management内で変換ポリシーを記述 リクエスト/レスポンスをOpenAI形式に変換
• Bedrock経由で繋ぐ AWS Bedrock上のClaudeをBedrock側のOpenAI互換層経由で（Bedrockの仕様変更に依存）

つまりAnthropic等の非OpenAI互換モデルをBYOMする場合は、「変換レイヤーを自前で持つ前提」で設計する必要があります。記事の検証や初回導入では避けて、まずはOpenAI互換モデルから入るのが安全です。

ケース別の推奨

実務でBYOM導入を支援する際、組織の状況によって推奨が変わります。AI総研で関わってきたケースをもとに、3パターンに分けて整理します。

• 検証フェーズ・PoC
  NVIDIA API CatalogまたはGitHub Models＋Other source接続。無料枠の範囲で「BYOMで何ができるか」を体感できる
• SaaS直契約を活かしたい
  OpenAI公式API＋Other source接続。既存契約を活かせる、最新モデルにいち早くアクセスできる
• 規制業種・自社GPU運用
  自前GPU＋API Management連携＋Managed Identity認証。既存ガバナンスを継承しつつ、データを外に出さない構成

いずれのケースでも、最初からエンタープライズ構成（API Management連携＋Managed Identity）に飛び込まずに、Other source＋APIキーで疎通確認をしてから本番構成に上げる、二段階のアプローチが事故が少なく済みます。

BYOMの接続手順【基本編】Other source

ここからは実際の接続手順を見ていきます。基本編では、最も詰まりにくい構成として Other source（Model Gateway）＋APIキー認証 を扱います。Foundryプロジェクトとモデル側のAPIキーがあれば、Azureの追加リソースなしで接続できる構成です。

前提条件（Foundryプロジェクト・APIキー）

接続作業に入る前に、以下を準備しておきます。

• Azureサブスクリプション 個人または会社契約のもの
• Microsoft Foundryプロジェクト 事前に作成済みであること
• 裏側のモデルAPIキー OpenAI公式API、NVIDIA API Catalog、GitHub Models等のいずれか
• Foundryプロジェクトに対する「Azure AI User」以上のロール

権限が不足していると後続のConnection作成画面に到達できないので、事前にAzureポータルのIAMでロール割当を確認しておくのが安全です。

Foundryポータルでモデル接続を作成

Microsoft Foundryポータルにサインインしたら、次の手順でモデル接続を作成します。

1. 上部メニューから Operate > Admin console を選択
   
   Microsoft Foundryポータルのトップ画面
   
   

2. All projects タブで対象プロジェクトの Parent resource リンクを開く
   
   All projectsタブの画面
   
   

3. Admin-connected models タブを開き、Add をクリック
   
   Admin-connected modelsタブの画面
   
   

4. Connection Type で Other source を選択
   
   Connection Typeタブの画面
   
   

5. Connection name（接続の表示名）と Base URL（モデルエンドポイントのベースURL）を入力
   
   Connection nameとBase URLを入力した画面
   
   

6. Authentication タブで API key を選択し、API keyを入力（必要に応じてAPI keyのヘッダー名も指定）
   
   Authenticationの画面
   
   

7. **Model configuration ** タブで +Add Model をクリック、名前・表示名・バージョンを入力
   
   Model configuration タブでモデルの追加を選択した画面
   
   

8. Advanced* タブで必要に応じて APIバージョンVersion、URL path形式、Costom HTTP headersを設定
   
   Advancedタブの画面
   
   

9. Add で接続作成完了
   
   モデル接続を追加し一覧に表示された画面
   
   

接続が作成されると、Admin-connected models タブの一覧に表示され、Foundry内のモデルとして使えるようになります。

プロンプトエージェント作成と動作確認

接続が作成できたら、PythonのAgent SDKを使ってプロンプトエージェントを作成します。次の環境変数を事前に設定しておきます。

export FOUNDRY_PROJECT_ENDPOINT="https://<your-account>.services.ai.azure.com/api/projects/<project-name>"
export FOUNDRY_MODEL_DEPLOYMENT_NAME="<connection-name>/<model-name>"

続けて、エージェント作成と動作確認を行うPythonコードは次のとおりです。

import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project = AIProjectClient(
    endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
    credential=DefaultAzureCredential(),
)

agent = project.agents.create_version(
    agent_name="byom-test-agent",
    definition=PromptAgentDefinition(
        model=os.environ["FOUNDRY_MODEL_DEPLOYMENT_NAME"],
        instructions="あなたは丁寧な日本語アシスタントです。",
    ),
)

openai = project.get_openai_client()
conversation = openai.conversations.create()
response = openai.responses.create(
    conversation=conversation.id,
    input="こんにちは、自己紹介してください。",
    extra_body={"agent_reference": {"name": agent.name, "type": "agent_reference"}},
)
print(response.output_text)

このコードで応答テキストが返ってくれば、Foundry Agentから外部モデルへのルーティングが正しく動作している証拠になります。エラーが出る場合は、FOUNDRY_MODEL_DEPLOYMENT_NAME の形式（<connection-name>/<model-name>）が崩れていないかが最初の確認ポイントです。

deployment name 形式

BYOMでエージェントから呼び出すモデルのデプロイ名は、<connection-name>/<model-name> 形式で指定します。

• 接続名（connection-name） Foundry portalの「Admin-connected models」一覧で表示される接続名
• モデル名（model-name） Model configurationで登録した Deployment name

例えば接続名が「my-openai-conn」、Deployment nameが「gpt-4o」なら、my-openai-conn/gpt-4o が正しい形式です。この形式が崩れていると「model not found」エラーが返るため、具体的な切り分け手順はH2#8「詰まりポイント・トラブルシューティング」で扱います。

BYOMの接続手順【応用編】API Management連携

基本編で疎通確認ができたら、エンタープライズ要件向けにAPI Management連携を追加していきます。応用編は手順が長くなるため、本記事では設計のポイントと詰まりやすい工程に絞り、フル手順は公式How-toに委ねる構成にします。

APIM Consumption作成（プラン選択の罠）

API Managementには複数のSKUがあり、検証目的なら Consumption層一択です。Developer層を誤って選ぶと月額が一気に跳ね上がるため、ここは特に注意が必要です。

検証用途では Consumption層を選ぶのが基本です。サーバーレス課金で記事検証・小規模PoCなら月数百円〜のレンジに収まります。

ただしConsumption層にはVNet統合・Private Endpointが使えないという制約があります。社内ネットワーク要件で完全プライベート化が必要な場合は、Standard v2以上（要件に応じてPremium / Premium v2） を選ぶか、別途プライベートネットワーク向けBicepテンプレートを参照する必要があります。Basic v2 はVNet統合（Virtual network injection / Outbound VNet integration）・Private Endpoint関連の要件にいずれも対応しないため、フルプライベート構成では候補から外れます。SKU別の料金詳細はH2#9「料金とコスト試算」で整理します。

API Management作成時にConsumptionプランを選択する画面

APIをバックエンドとして連携

APIM Consumption リソースを作成したら、次の流れで Foundry と連携します。

1. APIMにバックエンドAPI（OpenAI互換chat completions エンドポイント）を登録
2. inbound policy でリクエスト変換・認証ヘッダー設定
3. APIMのGateway URLとサブスクリプションキーを取得
4. Foundryで Connection Type → Azure API Management を選び、対象APIMリソースとモデルデプロイを指定

BYOM側の正攻法のフル手順は公式How-toに集約されているため、APIMポリシーの記述例・Managed Identity の audience 設定・Bicepテンプレートはそちらを参照してください。なお、APIMの逆向きの利用（Foundry Project APIをAPIMで外部公開してクライアントに配信する）は別パターンの設計で、BYOMとは構成方向が逆になります。混在させると認証・経路の整理がブレやすいため、用途を切り分けて検討する必要があります。

API Managementでは、外部OpenAI互換エンドポイントをバックエンドとして登録することで、Microsoft Foundryや他システムから統一されたAPI管理基盤経由でモデルを利用できます。

inbound policyを利用することで、バックエンド接続先指定やAPIキー付与、Managed Identity認証をAPIM側で一元管理できます。

APIキー付与やManaged Identity認証を設定するinbound policy画面

Managed Identity認証の概要

検証段階を抜けて本番運用に持っていくときは、APIキーからManaged Identity認証への切り替えを検討します。Managed Identityにすることで、APIキーの管理・ローテーション・漏洩リスクから解放され、Azure RBACでアクセス制御を一元管理できます。

設定の概要は次のとおりです。

1. Foundryプロジェクトでマネージドアイデンティティを有効化（システム割り当て済みまたはユーザー割り当て済み）
   
   Microsoft Foundry親リソースでシステム割り当てマネージドIDを有効化した画面
   
   

2. マネージドIDの オブジェクトID を取得し、Microsoft Entra IDで対応する アプリケーション(クライアント)ID を確認

3. APIM側のinbound policyに validate-azure-ad-token ポリシーを追加し、audience と client-application-ids を設定
   
   Managed Identity認証のAPIMポリシー設定例
   
   

4. Foundry側のConnection設定で Authentication → Managed Identity を選び、APIM側で設定したaudience値を入力

この工程はAzure RBACとAPIM policyの両方の知識が必要になり、初学者がつまずきやすい箇所です。検証段階ではAPIキーのまま走らせ、本番移行のタイミングで集中的に切り替える進め方が現実的です。

BYOMで使えるエージェント機能と制限事項

BYOMで接続したモデルをAgentから使う際、利用できるエージェント機能と制限事項を事前に把握しておく必要があります。BYOMはあくまで「モデルの取り込み口」を増やす機能で、Agent Service自体の機能制限はそのまま継承されます。

対応ツール一覧

公式ドキュメントによれば、BYOMで接続したモデルでも次のエージェントツールが利用できます。

つまりBYOM接続したモデルでも、Foundry Agentが提供するエージェント機能の主要部分はそのまま使えるということです。Code Interpreter や File Search、MCPといった「BYOMで欲しい理由になりやすい機能」が揃っているのが、この機能を選ぶ大きな動機になります。

Prompt agentsのみ対応の制約

BYOMで使えるエージェント形式は プロンプトエージェント（Prompt agent）のみです。Foundry Agent Serviceには3種類のエージェント形式がありますが、Workflow agent（プレビュー）と Hosted agent（プレビュー）は対象外です。

• Prompt agent（GA） ✅ BYOM対応
• Workflow agent（プレビュー） ❌ BYOM非対応
• Hosted agent（プレビュー） ❌ BYOM非対応

複雑なオーケストレーションをWorkflow/Hostedで組み立てる構成を検討している場合、現時点ではBYOMとの併用は不可となるため、設計段階で気をつける必要があります。

リージョン可用性

BYOMで利用するモデルのリージョンは、次の3つの可用性に依存します。

• Foundry Agent Service自体の対応リージョン
• Azure OpenAI Responses APIの対応リージョン
• 裏側で利用するモデルそのものの可用性

Foundry Agent Service は Azure OpenAI Responses APIをベースに動くため、Foundryプロジェクトを作成するリージョンが Responses API対応リージョンである必要があります。BYOM側のモデルが特定のリージョンにしか存在しない場合は、ネットワーク的な近さやレイテンシも含めて検証しておくのが安全です。

ネットワーク分離・プライベート構成

BYOMはパブリックネットワーク・プライベートネットワーク両方をサポートしています。フルプライベート構成を組む場合の選択肢は次のとおりです。

• API Management連携をプライベートネットワークで構成 Microsoft公式のプライベートネットワーク用Bicepテンプレートを使い、FoundryとAPIMを同一VNetにデプロイ
• 自社GPUゲートウェイをVNet内に配置 Foundry Agent Serviceが利用するVNetからアクセスできるエンドポイントとして公開

「外部APIに直接出せない」「全リクエストをVNet内に閉じたい」要件がある場合、API Management連携＋プライベートネットワーク構成が事実上の標準解になります。Other source構成でもVNet内エンドポイントを指定できますが、APIMが提供するロギング・レート制限・認証集約のメリットは得られません。

BYOM時の責任範囲（コンテンツフィルター・データ地理境界）

公式ドキュメントに明記されているとおり、BYOMで接続するモデルは Microsoft Product Terms 上 Non-Microsoft Products として扱われます。これに伴い、以下の責任は接続側（顧客側）が負うことになります。

• 責任あるAIの実装 メタプロンプト・コンテンツフィルター・安全性システムの設定
• データハンドリング リテンション、地理的境界、第三者へのデータ流出防止
• ライセンス遵守 利用するモデルの利用規約・商用利用条件への準拠

つまりBYOMを使うと、Azure OpenAI Service標準で受けられる責任あるAIガードレールは適用されないため、自前で同等の仕組みを設計する必要があります。エンタープライズ導入時は、法務・セキュリティ部門との事前すり合わせが事実上必須になります。

BYOMの詰まりポイント・トラブルシューティング

BYOM導入時にハマりやすい4パターンと、それぞれの切り分け手順を整理します。基本編・応用編で記載した手順を進めていて詰まったときの参照用としても使えます。

接続がInactive表示になる場合

Foundry portalの Connected resources で接続のステータスが Inactive になるケースです。原因の8割は次の3つに集約されます。

• ゲートウェイのエンドポイントURLが疎通していない（DNS、ファイアウォール）
• 認証情報（APIキー、Managed Identity audience値）が誤っている
• 認証ヘッダー名のカスタム指定がモデル側と一致していない

切り分けは curl でゲートウェイURLに直接chat completions リクエストを投げてみる のが最短です。ターミナルから直叩きで応答が返るなら、Foundry Connection側の設定ミス。返ってこないならゲートウェイ側の問題、と切り分けられます。

model not foundエラー

Agent SDK実行時に 「model not found」 エラーが返るケースです。基本編でも触れた通り、FOUNDRY_MODEL_DEPLOYMENT_NAME の形式エラーが大半です。

確認ポイントは次のとおりです。

• 形式が <connection-name>/<model-name> になっているか
• Connection nameが Foundry portal の Admin-connected models 一覧と完全一致しているか（大文字小文字含めて）
• Model nameが Model configuration で登録した Deployment name と一致しているか

環境変数で渡している場合は、「echo $FOUNDRY_MODEL_DEPLOYMENT_NAME」 で実際の値を確認するところから始めると、コードの記述ミスかBYOM側の問題かを切り分けられます。

認証エラー

401 / 403 エラーが返る場合の対処です。認証方式によってチェック箇所が変わります。

• APIキー認証 APIキーの値が正しいか、API key header nameのカスタム指定が必要なゲートウェイか
• Managed Identity認証 APIM側の validate-azure-ad-token の audience と client-application-ids が正しいか、Foundry側のManaged IDが有効化されているか
• OAuth 2.0認証 Token URL endpoint・client ID・client secretの組み合わせが正しいか、scope設定が必要なIdPか

Managed Identity認証で詰まる場合、APIM側のinbound policy をいったん validate-azure-ad-token を外したシンプルな構成に戻して疎通確認し、ポリシーを少しずつ復元していく進め方が確実です。

タイムアウト・ネットワーク疎通

リクエストがタイムアウトする場合、ネットワーク設定が原因のことが多くあります。

• プライベートネットワーク構成 Foundry Agent Serviceが使うVNetからゲートウェイへ到達できるか、サブネットNSGが許可しているか
• APIM Consumption利用時 VNet統合が使えないため、ゲートウェイ側のIP制限を見直す
• モデル側の処理時間が長い APIM側のtimeout値を延長、あるいはストリーミング応答を使う

「公式ドキュメント通りに設定したのに動かない」場合、たいていの原因は 接続経路上のどこかでネットワーク疎通が切れている ことです。Application Insights のログや APIM のリクエストトレースを使って、どの段階でリクエストが止まっているかを確認するのが正攻法になります。

BYOMの料金とコスト試算

BYOMを実際に導入するときに気になるのが、月額がどの程度になるかという点です。Foundry Agent Service自体は追加料金がない一方で、APIMやモデル側で別途コストが発生するため、構成全体での試算が必要です。

Foundry Agent Service自体は追加料金なし

Foundry Agent Serviceの料金ページによると、Agent Service自体には追加課金がありません。代わりに、次の要素が別途課金対象になります。

• モデルトークン 利用するモデルごとの入出力トークン課金
• ツール実行 Microsoft Fabric、SharePoint、Bing Search、Azure AI Search 等の連携ツール
• Hosted Agentsのコンピュート（プレビュー） $0.0994/vCPU-時、$0.0118/GiB-時（2026年4月22日課金開始）
• メモリ機能 短期メモリ$0.25/1Kイベント、長期メモリ$0.25/1Kメモリ/月、メモリ取得$0.50/1K取得

BYOMで利用するモデルトークンは、Foundry経由ではなく接続先（OpenAI公式、NVIDIA、自社GPU等）の課金体系で精算される点に注意が必要です。Foundry側の請求書には「Agent Service部分は$0、ツール利用分は別途」という形で出てきます。

API Managementプラン別料金

API Management連携を選ぶ場合、APIMのプラン選択が月額の大半を決めます。Japan Eastリージョンでの参考価格は次のとおりです（2026年5月時点）。

Consumption層は記事検証や小規模PoCで圧倒的に有利です。コール数だけで上位プランへ切り替える明確な閾値はなく、SLA・固定容量・運用要件といったConsumption層の制約が課題になった時点でv2系（Basic v2など）への移行を検討するのが実務的な判断軸になります。さらにVNet統合・Private Endpointが必要な完全プライベート構成では Standard v2以上（要件に応じてPremium / Premium v2） が選択肢で、Basic v2は対応しないため候補に入りません。最新の正式な価格は、API Management公式料金ページで確認してください。

推奨構成での月額試算

実際の検証〜小規模本番での月額試算を3パターンで整理します。

パターン1：Other source ＋ NVIDIA API Catalog（最安検証構成）

記事検証や社内PoCに最適な構成です。BYOMの動作確認に必要なリソースだけで完結します。

パターン2：Other source ＋ OpenAI公式API（実用検証構成）

SaaS直契約モデルを使った実運用に近い構成で、月数百円のレンジで運用できます。

パターン3：API Management連携 ＋ 外部モデル（エンタープライズ準拠構成）

BYOMの本来の使い方に沿った構成です。Azure OpenAIは通常のFoundry利用（Direct Models側）で扱う領域なので、BYOMの裏側にはOpenAI公式・Bedrock・Vertex AI・自前GPU等のFoundry外モデルを据えるのが妥当です。本番運用に向けて、認証をManaged Identityに切り替え、ネットワーク要件に応じてSKUを上げていく起点としても使えます。

「数百円〜千円のレンジでBYOMを動かせる」というのが、検証段階での現実的なコスト感覚です。Developerプラン誤選択で月7,000円飛ばす事故を避けることが、実質的なコスト管理の中核になります。

BYOMで構築したエージェントを業務実装まで繋ぐなら

BYOMで外部モデルとFoundry Agentを接続できると、次に立ち上がる課題は「そのエージェントをどう社内業務に組み込み、どう運用統制するか」になります。モデル接続だけで止まると、PoCのまま塩漬けになるか、シャドーAIとして部署単位で乱立してガバナンスが効かなくなるパターンが目立ちます。

ここで効いてくるのが、自社のAzureテナント内で動く AI Agent Hub です。BYOMで繋いだ外部モデルや自社モデルを起点に、SAP・Salesforce・Dynamics 365等の業務システム連携、実行ログ・権限管理・セキュリティスキャンまで含めた運用基盤を、Azure Managed Applicationsとして自社テナント内で完結する形で構築できます。

• BYOMで繋いだエージェントを業務システムまで一気通貫で接続
  SAP Concur・freee会計・Dynamics 365・Salesforce等の連携を前提に、エージェントの推論結果をそのまま申請・承認・基幹データ更新につなげる設計を支援します。
  
  
• 実行ログ・権限・セキュリティを1つのダッシュボードで管理
  BYOMで接続した複数モデルや、別途Copilot Studio等で構築したAgentも含めて、どこで作ったAgentでも統合管理。シャドーAI乱立と監査対応の負荷を構造的に下げます。
  
  
• データは100%自社テナント内で完結
  Azure Managed Applicationsとして顧客テナント内に構築されるため、推論データ・業務データが外部SaaSに出ることはありません。BYOMの責任範囲（コンテンツフィルター・データ地理境界）と整合させやすい設計です。

AI総合研究所の専任チームが、BYOMによるモデル接続設計から業務実装・運用基盤の整備まで一気通貫で支援します。まずは無料の資料で、自社環境への適用イメージをご確認ください。

BYOMの先のエージェント運用基盤を整備

モデル接続から業務実装・運用設計まで一元化

BYOMで外部モデルとFoundry Agentを繋いだ次は、社内データ・業務システム連携・実行ログまで含めた基盤設計が必要です。AI Agent Hubの資料で、自社のAzureテナント内でエージェント運用を立ち上げる全体像をご確認ください。

▶ 無料で資料をダウンロード

まとめ

Microsoft Foundry BYOM（旧 Azure AI Foundry / Bring Your Own Model）は、Foundryのモデルカタログにないモデル、自社GPU運用モデル、他クラウドのモデル、SaaS直契約のモデルを、Foundry Agent Serviceのプロンプトエージェントから利用可能にする接続機能です。

本記事で扱った要点は次のとおりです。

• BYOMは「Foundry外のモデルをAgentに繋ぐ」機能で、通常のFoundry利用（Azureが直接販売するモデル・パートナー・コミュニティモデル）とは別軸
• 接続方式は API Management連携 と Other source（Model Gateway） の2種類。検証はOther source＋APIキーが最短
• 裏側のモデル候補は OpenAI公式 / NVIDIA API Catalog / GitHub Models / 自前GPU が現実的。Anthropic は変換層が前提
• APIM Consumptionプランなら月数百円で検証できる。Developerプラン誤選択は月7,000円超の事故になる
• BYOM時はコンテンツフィルター・データ地理境界・利用規約の責任を自社で持つ前提で設計する

導入の第一歩としては、Other source＋APIキーで疎通確認をしてから、要件に応じて API Management連携＋Managed Identity に段階的に上げていく進め方が、技術的な詰まりも組織的な調整も最小化できます。BYOMが選択肢に入る段階に来ているかどうかは、「Foundry標準のモデルでは足りない、Agent機能は欲しい」という条件が揃っているかが判断軸になります。