Azure AI Foundryでエージェントやナレッジツールを使う場合、「接続」は外部リソースを使うための単なるリンクではありません。Azure AI Search、Azure Storage、Azure OpenAI、Application Insights、Key Vaultなどを、認証・権限・ネットワーク・シークレット管理と結び付ける重要な設定です。
2026年5月中旬に更新された Microsoft Learn の「Add a new connection to your project – Microsoft Foundry」では、Foundryプロジェクトに新しい接続を追加する手順に加え、作成できる接続タイプ、Bicepなどコード展開が必要な接続、RBACロール名の変更、Key Vaultとネットワーク分離の制約が整理されています。特に管理者と開発者は、「UIで追加できる接続か」「本番利用できる機能か」「権限とPrivate Endpointが足りているか」を事前に確認する必要があります。(Microsoft Learn)
結論として、Azure AI Foundryの接続追加で失敗しやすいのは、接続作成そのものではなく、その前後にあるRBAC、Key Vault、ネットワーク、IaC展開の設計です。新しい接続を追加する前に、利用目的、認証方式、接続先リソースの権限、プレビュー機能の扱い、開発環境から本番環境への再現方法を確認しておきましょう。
Azure AI Foundryの「接続」とは何か
Azure AI Foundryにおける接続とは、FoundryプロジェクトからMicrosoftや外部のリソースを認証して利用するための設定です。公式ドキュメントでは、Standard Agentの構築やAgent knowledge toolsの利用などで接続が必要になると説明されています。(Microsoft Learn)
たとえば、社内文書を検索して回答するエージェントを作る場合、Azure AI Foundryだけでは完結しません。検索インデックスにはAzure AI Search、ファイル保存にはAzure Storage、会話やスレッドの永続化にはAzure Cosmos DB、実行状況の確認にはApplication Insightsといった外部リソースが関わります。これらをFoundryプロジェクトから安全に使えるようにするのが「接続」です。
実務では、接続を次のように捉えると分かりやすくなります。
| 観点 | 接続で管理すること | 確認すべきポイント |
|---|---|---|
| 認証 | APIキー、Microsoft Entra ID、サービスプリンシパルなど | 本番でキー認証に頼りすぎていないか |
| 権限 | Foundryユーザー、管理者、マネージドIDのアクセス範囲 | 最小権限になっているか |
| シークレット | 接続情報やキーの保管 | Key Vaultの制約を理解しているか |
| ネットワーク | 接続先リソースへの到達性 | Private EndpointやVNet設計が足りているか |
| 展開 | UI、Bicep、Terraformなど | 開発・検証・本番で再現できるか |
接続は「あとで追加すればよい設定」と考えがちですが、実際にはアーキテクチャ設計に近い要素です。特に本番環境では、誰が追加できるか、どの認証方式を使うか、接続先リソースをどのサブスクリプションに置くかまで含めて決める必要があります。
今回の公式情報で押さえるべき変更点と確認ポイント
今回の公式情報で最も重要なのは、接続追加の操作手順だけではありません。FoundryのUI、RBACロール名、接続タイプ、Key Vault、ネットワーク分離に関する実務上の注意点が明確になっている点です。
| 確認項目 | 内容 | 影響を受ける人 |
|---|---|---|
| 新しいFoundry UIでの操作 | Microsoft FoundryポータルでNew Foundryを有効にし、Operate > Adminから接続を追加する流れ | 管理者、開発者 |
| RBACロール名の変更 | Foundry User、Foundry Ownerなどの名称へ変更。旧称が一部に残る可能性がある | 管理者、IaC担当者 |
| 一部接続はコード展開が必要 | Cosmos DB、Serverless Model、Databricks、SharePoint、Fabric、APIMなどはコードによる作成が必要なものがある | 開発者、DevOps担当者 |
| プレビュー機能の扱い | プレビュー項目はSLAなしで、本番ワークロードには推奨されない | 管理者、プロダクト責任者 |
| Key Vault制約 | BYO Key Vault利用時は接続数や削除、シークレット移行に制約がある | セキュリティ担当者、管理者 |
| ネットワーク分離 | エンドツーエンドの分離には接続先リソース側にもPrivate Endpointが必要 | ネットワーク担当者 |
| サブスクリプション制約 | FoundryやAzure OpenAIのモデル展開ではクロスサブスクリプション接続がサポートされない | アーキテクト、管理者 |
Foundry RBACロールは最近名称変更され、Foundry User、Foundry Owner、Foundry Account Owner、Foundry Project Managerは、以前のAzure AI User、Azure AI Owner、Azure AI Account Owner、Azure AI Project Managerに相当します。ロールIDと中核的な権限は変わらない一方、移行期間中は旧称が表示される場合があります。(Microsoft Learn)
このため、IaCや自動化スクリプトでロール名を直接参照している場合は注意が必要です。公式のRBACドキュメントでは、名称変更の展開中に問題を避けるため、コードではロール名ではなくロール定義IDを使うことが推奨されています。(Microsoft Learn)
影響を受ける対象者
Azure AI Foundryの接続追加は、開発者だけの作業ではありません。運用に入るほど、複数の担当者に影響します。
管理者が受ける影響
管理者は、誰が接続を追加できるかを管理する必要があります。接続追加には、Foundry User、Foundry Owner、Azure Contributor以上のロールが必要です。プロジェクト単位で権限を与えるのか、Foundryリソース単位で権限を与えるのかを整理しておかないと、開発者が接続を作れない、または必要以上に広い権限を持つ状態になります。(Microsoft Learn)
また、APIキー認証を使う場合は特に注意が必要です。FoundryのRBACドキュメントでは、キー認証を使うとロール制約なしにフルアクセスを与えることになるため、より細かいアクセス制御にはMicrosoft Entra ID認証が推奨されています。(Microsoft Learn)
開発者が受ける影響
開発者は、使いたい機能に必要な接続が事前に用意されているかを確認する必要があります。たとえばStandard Agentを構築する場合、Azure AI Search、Azure Storage、Azure Cosmos DBなどの接続が関係します。Azure Cosmos DB接続はプレビュー扱いで、接続作成はコード経由のみとされています。(Microsoft Learn)
また、Databricks接続はJobs、Genie、Otherという接続タイプをサポートしますが、利用はFoundry SDK経由で、FunctionToolとしてエージェントに統合されます。Foundry Playgroundでの利用は現時点ではサポートされていないため、検証時に「UIでは動かない」と誤解しないようにしましょう。(Microsoft Learn)
セキュリティ・ネットワーク担当者が受ける影響
ネットワーク分離を有効にしている環境では、Foundry側だけでなく接続先リソース側のPrivate Endpoint設計が重要になります。公式ドキュメントでは、たとえばAzure StorageアカウントでパブリックネットワークアクセスをDisabledにしている場合、Foundryからアクセスするために仮想ネットワーク内にPrivate Endpointを展開する必要があると説明されています。(Microsoft Learn)
Foundryのネットワーク分離は、Foundryリソースへのインバウンドアクセス、Foundryリソースから他のAzureサービスへのアウトバウンドアクセス、Agentクライアントから依存先へのアウトバウンドアクセスという複数の観点で考える必要があります。(Microsoft Learn)
追加できる接続タイプと選び方
公式ドキュメントでは、Azure AI Search、Azure Storage、Azure Cosmos DB、Azure OpenAI、Application Insights、Azure Key Vault、OpenAI、Serp、API key、Custom key、Grounding with Bing Search、Azure Databricks、SharePoint、Microsoft Fabric、Azure APIM、Model Gatewayなど、複数の接続タイプが整理されています。(Microsoft Learn)
実務では、接続タイプを機能名だけで選ぶのではなく、「何を実現したいか」から逆算するのが安全です。
| 実現したいこと | 主な接続タイプ | 判断基準 |
|---|---|---|
| Standard Agentを構築したい | Azure AI Search、Azure Storage、Azure Cosmos DB | 必須リソースとプレビュー扱いの有無を確認する |
| Azure上のOpenAIモデルを使いたい | Azure OpenAI | モデル展開、権限、サブスクリプション制約を確認する |
| 外部のOpenAIモデルを使いたい | OpenAI | APIキー管理と利用ポリシーを確認する |
| 実行状況を監視したい | Application Insights | 監視対象、ログ保管、権限を確認する |
| シークレットを自社管理したい | Azure Key Vault | BYO Key Vaultの制約を先に確認する |
| 最新Web情報でグラウンディングしたい | Grounding with Bing Search、Serp | 利用条件、データの扱い、社内ポリシーを確認する |
| 社内文書や業務データを使いたい | SharePoint、Databricks、Fabric | プレビュー状態とコード展開の要否を確認する |
| AIモデル呼び出しを統制したい | Azure APIM、Model Gateway | ガバナンス要件と展開方法を確認する |
Azure OpenAI接続は、Azureのセキュリティとエンタープライズ機能を使いながら、GPT-5、GPT-4o、GPT-image-1、Embeddingsなどのモデルにアクセスするための接続として説明されています。モデル名や提供状況はリージョンや時期によって変わる可能性があるため、実際の展開前には対象リージョンとモデル一覧を確認してください。(Microsoft Learn)
Azure AI Foundryで新しい接続を追加する手順
Azure AI Foundryで新しい接続を追加する基本手順は、Foundryポータルから実行できます。ただし、すべての接続がUIだけで作成できるわけではありません。一部の接続はBicepなどコードによる展開が必要です。(Microsoft Learn)
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前確認 | Foundryプロジェクトを作成し、開ける状態にする | 対象プロジェクトが正しいか |
| 権限確認 | 接続追加に必要なロールを確認する | Foundry User、Foundry Owner、Azure Contributor以上があるか |
| ポータル操作 | Microsoft Foundryにサインインし、New Foundryを有効にする | 旧UIを見ていないか |
| 管理画面へ移動 | Operate > Adminを開き、対象プロジェクトを選ぶ | リソース単位とプロジェクト単位を混同していないか |
| 接続追加 | Add connectionからサービスを選ぶ | 接続タイプがUI作成に対応しているか |
| 認証方式選択 | 接続先リソースと認証方式を選ぶ | Entra ID利用時のAzure RBAC権限が足りているか |
| 確認 | connected resourcesに接続が表示されるか確認する | 作成後に実際のエージェントやツールで利用できるか |
接続タイプによって対応する認証方式は異なります。Microsoft Entra IDを使う場合、開発者やマネージドIDに適切なAzureロールベースの権限が必要になることがあります。(Microsoft Learn)
Bicepで接続を作る場合は、インフラ展開後にFoundryプロジェクトへ戻り、connected resourcesに新しい接続が表示されるかを確認します。UIで見えることと、実際にエージェントやツールから使えることは別なので、作成後の動作確認まで手順に含めてください。(Microsoft Learn)
管理者が確認すべき設定
RBACロール名の変更を移行計画に入れる
今回の情報で見落としやすいのが、RBACロール名の変更です。管理画面では新しいFoundryロール名が表示されても、別の画面、CLI、テンプレート、社内手順書では旧称が残っている可能性があります。
特に次のような環境では、ロール名の棚卸しをおすすめします。
| 確認対象 | 見直す内容 |
|---|---|
| Azure PortalのIAM設定 | 旧称と新称が混在していないか |
| Bicep、Terraform、CLI | ロール名を文字列で指定していないか |
| 社内手順書 | Azure AI Userなど旧称のままになっていないか |
| 権限申請フロー | 申請者が選ぶロール名が最新か |
| 監査ログ・棚卸し資料 | 旧称を見て誤判定しないか |
Foundryの権限管理では、Foundryリソースが管理・セキュリティ・監視の境界になり、Foundryプロジェクトが開発作業やAPI、ツール利用のためのサブスコープになります。誰にどのスコープで権限を与えるかを、プロジェクト作成前に決めておくと運用が安定します。(Microsoft Learn)
Key Vaultは後付け前提で考えない
Azure AI Foundryでは、Key Vault接続を作成しない場合、接続情報は管理されたAzure Key Vaultに保存されます。自社でシークレットを管理したい場合は、接続としてAzure Key Vaultを持ち込めます。ただし、BYO Key Vaultには重要な制約があります。(Microsoft Learn)
| 制約 | 実務上の注意点 |
|---|---|
| Foundryリソースごとに同時に使えるKey Vault接続は1つ | 複数チームで別々のKey Vaultを使いたい場合は設計を分ける |
| Key Vault接続の削除には条件がある | 他の接続が残っていると削除できない場合がある |
| シークレット移行はサポートされない | Key Vaultを後から付ける場合、接続の再作成が必要 |
| 元のKey Vaultを削除するとFoundryリソースが壊れる可能性がある | インフラ削除時に依存関係を必ず確認する |
| BYO Key Vault内のシークレット削除で他サービス接続が壊れる可能性がある | シークレット削除は変更管理の対象にする |
最も避けたいのは、PoCで接続を多数作った後に「本番では自社Key Vaultに切り替える」と決めるパターンです。公式情報ではシークレット移行がサポートされないとされているため、Key Vault方針は初期設計で決めるべきです。(Microsoft Learn)
ネットワーク分離は接続先リソースまで含めて設計する
FoundryリソースにPrivate Endpointを作っただけでは、すべての接続先に安全に到達できるとは限りません。Azure Storage、Azure Cosmos DB、Azure AI Search、Azure OpenAI、Application Insightsなど、それぞれの接続先リソースにも適切なPrivate EndpointやPrivate Link構成が必要になる場合があります。(Microsoft Learn)
特に、次のような構成では事前検証が必須です。
| 構成 | 起こりやすい問題 | 対策 |
|---|---|---|
| StorageのPublic network accessをDisabledにしている | Foundryからファイルにアクセスできない | Storage側のPrivate Endpointを用意する |
| SearchやCosmos DBを別VNetに配置している | エージェント構築時に接続できない | VNet、DNS、Private Linkの到達性を確認する |
| Azure OpenAIを別サブスクリプションに置いている | モデル展開用の接続で使えない | モデル展開用途では同一サブスクリプション設計を検討する |
| 開発環境だけPublic accessを許可している | 本番移行時に動かない | 検証段階から本番に近いネットワーク条件でテストする |
公式ドキュメントでは、FoundryとAzure OpenAIのモデル展開に使うクロスサブスクリプション接続はサポートされないとされています。複数サブスクリプションでリソースを分離している企業では、モデル展開用リソースの配置を見直してください。(Microsoft Learn)
開発者が確認すべき移行・展開上の注意点
UI作成とコード展開を混在させすぎない
PoCではUIから接続を追加してすぐ試すのが便利です。しかし、本番環境では「誰が、いつ、どの設定で作った接続か」が分からなくなると、再現性や監査性に問題が出ます。
Azure AI FoundryのTerraformドキュメントでは、Foundryリソース、プロジェクト、デプロイ、接続の自動化にTerraformを利用できると説明されています。また、AzAPI Providerはプレビュー機能を含むFoundryのコントロールプレーン構成にアクセスできる一方、AzureRM Providerは中核的な管理機能に限定されるとされています。(Microsoft Learn)
開発・検証・本番を分ける場合は、次の方針が現実的です。
| 環境 | おすすめの運用 |
|---|---|
| 個人検証 | UIで接続を追加し、動作確認を優先する |
| チーム開発 | UIで作った設定を棚卸しし、テンプレート化する |
| 検証環境 | BicepまたはTerraformで再現できるようにする |
| 本番環境 | 接続、権限、ネットワーク、Key Vaultをコード管理する |
Terraformのstateファイルには機密値が含まれる可能性があるため、チーム利用ではセキュアなバックエンドとアクセス制御が必要です。接続をIaC化する場合は、コード管理だけでなくstate管理もセキュリティ設計に含めてください。(Microsoft Learn)
プレビュー接続を本番前提で使わない
公式ドキュメントでは、プレビューと示された項目はSLAなしで提供され、本番ワークロードには推奨されないと明記されています。Azure Cosmos DB、Serverless Model、Azure Databricks、SharePoint、Microsoft Fabric、Grounding with Bing Custom Search、Azure APIM、Model Gatewayなど、一部の接続タイプにはプレビュー表示があります。(Microsoft Learn)
プレビュー機能を使う場合は、次のような判断基準を用意しておくと安全です。
| 判断項目 | 本番採用前の確認 |
|---|---|
| SLA | 障害時の責任範囲をチームで合意しているか |
| 代替手段 | 機能が変更・停止した場合の回避策があるか |
| データ扱い | 機密データを投入してよいか社内承認があるか |
| 展開方法 | UIではなくコード展開が必要か |
| テスト範囲 | Playground非対応など、検証方法の制限を把握しているか |
プレビュー機能は価値がありますが、「使える」と「本番運用できる」は別です。特に顧客向けサービスや社内基幹業務に組み込む場合は、プレビュー機能を本番経路から切り離すか、明確なリスク承認を取るべきです。
接続作成後は「表示されたか」ではなく「使えるか」を確認する
connected resourcesに接続が表示されても、アプリケーションやエージェントから利用できるとは限りません。認証方式、RBAC、接続先リソースのネットワーク、マネージドIDの権限が不足していると、作成後の実行時に失敗します。
接続作成後は、最低限次の動作確認を行いましょう。
| 確認内容 | 具体例 |
|---|---|
| リソース到達性 | Search、Storage、Cosmos DBにFoundryからアクセスできるか |
| 権限 | プロジェクトのマネージドIDに必要なロールがあるか |
| 認証方式 | Entra ID認証とキー認証のどちらで動いているか |
| 実行テスト | エージェント、ツール、SDKから実際に呼び出せるか |
| ログ確認 | Application Insightsなどで失敗理由を追跡できるか |
特にEntra ID認証を使う場合、接続を作ったユーザーの権限だけでなく、プロジェクトやFoundryリソースのマネージドIDに必要なロールが付与されているかを確認してください。
失敗しやすいポイントと対策
Azure AI Foundryの接続追加でよくある失敗は、操作ミスよりも設計漏れです。以下の表をチェックリストとして使うと、導入時のトラブルを減らせます。
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| Add connectionが表示されない、実行できない | 権限不足 | Foundry User、Foundry Owner、Azure Contributor以上の権限を確認する |
| 接続は作れたがエージェントが動かない | 接続先リソースへの権限不足 | ユーザーとマネージドIDの両方のRBACを確認する |
| 本番移行時に接続が再現できない | UI操作だけで作成していた | BicepやTerraformで展開できる形にする |
| Key Vault切り替えで接続を失う | シークレット移行がサポートされない | BYO Key Vault方針を初期設計で決める |
| プライベート環境で接続できない | 接続先リソース側のPrivate Endpoint不足 | Foundry側だけでなくSearch、Storage、OpenAI側も確認する |
| 旧ロール名で自動化が失敗する | RBACロール名変更の影響 | 可能な限りロール定義IDを使う |
| プレビュー機能を本番投入してしまう | SLAや制約の確認不足 | 本番採用前にリスク承認と代替策を用意する |
| Databricks接続をPlaygroundで試して失敗する | Playground非対応 | SDK経由でFunctionToolとして検証する |
接続追加は、エージェント開発の序盤で行う作業に見えます。しかし、実際には運用、監査、セキュリティ、ネットワーク、IaCまで関わるため、早い段階でチーム横断の確認項目に入れるべきです。
実務でのおすすめ進め方
Azure AI Foundryで新しい接続を追加する場合は、いきなり本番リソースに接続するのではなく、次の順序で進めると安全です。
| フェーズ | やること | 成果物 |
|---|---|---|
| 要件整理 | 何のために接続するかを決める | 接続先リソース一覧 |
| 権限設計 | 誰が作成し、誰が利用するかを決める | RBAC設計表 |
| セキュリティ設計 | 認証方式とKey Vault方針を決める | 認証・シークレット管理方針 |
| ネットワーク設計 | Private EndpointやDNSを確認する | ネットワーク構成図 |
| 検証 | UIまたはコードで接続を作成する | 検証ログ、接続一覧 |
| IaC化 | BicepやTerraformで再現する | テンプレート、実行手順 |
| 本番展開 | 権限、接続、監視を含めて展開する | 本番チェックリスト |
小規模な検証ではUIからの追加で十分です。一方、複数人で開発するプロジェクトや本番展開を前提にする場合は、接続を「設定」ではなく「管理対象のインフラ」として扱ってください。
まず確認すべきチェックリスト
Azure AI Foundryの「Add a new connection to your project – Microsoft Foundry」に対応するうえで、管理者と開発者が最初に確認すべき項目は次の通りです。
| チェック項目 | 確認済み |
|---|---|
| 接続を追加する対象プロジェクトが正しい | |
| 接続追加に必要なロールが付与されている | |
| Foundry RBACロール名の変更を手順書に反映した | |
| UIで作成できる接続か、コード展開が必要な接続かを確認した | |
| プレビュー接続を本番利用しない、またはリスク承認を取った | |
| Key VaultをBYOにするか初期段階で決めた | |
| 接続先リソースに必要なPrivate Endpointを確認した | |
| モデル展開でクロスサブスクリプション接続を使っていない | |
| 接続作成後にエージェントやSDKから実行確認した | |
| 本番展開用にBicepまたはTerraformで再現できる |
Azure AI Foundryの接続追加は、画面上では数ステップで完了します。しかし、実務で重要なのは「接続を作ること」ではなく、「安全に使い続けられる接続を設計すること」です。まずは対象プロジェクトの接続一覧を棚卸しし、RBAC、Key Vault、ネットワーク、IaC化の4点を確認してください。ここまで整理できれば、新しいエージェントやナレッジツールを追加するときも、環境差分や権限不足でつまずきにくくなります。
コメント