Azure Databricksの「Configure private connectivity to Azure resources」は、サーバーレスコンピュートからAzure Storage、Azure SQL、Key VaultなどのAzureリソースへ、Private Link経由でプライベート接続するための設定手順です。今回確認すべき要点は、Network Connectivity Configuration（NCC）を作成し、ワークスペースに関連付け、接続先リソースごとにPrivate Endpoint Ruleを作成・承認することです。特に、サーバーレスSQLウェアハウス、ジョブ、ノートブック、Lakeflow Spark Declarative Pipelines、モデルサービングを使う環境では、接続方式・権限・リージョン・コスト・既存ファイアウォール設定を見直す必要があります。(Microsoft Learn)
なお、Microsoft Learn上では対象ページ「Configure private connectivity to Azure resources」の最終更新日は2026年7月1日、関連する「Serverless compute plane networking」およびNSP構成ページは2026年7月2日と表示されています。本記事では、2026年7月2日時点で公開されている公式情報をもとに、グローバル環境の管理者が確認すべき変更点と実務上の対応を整理します。(Microsoft Learn)
Azure DatabricksのPrivate Connectivity更新で押さえるべき結論
今回のポイントは、Azure DatabricksのサーバーレスコンピュートからAzureリソースへ接続する際に、従来の「公開IP許可リスト」や「ストレージ側のファイアウォール設定」だけで考えるのではなく、NCCを中心にプライベート接続を管理する設計を明確に理解することです。
Azure Databricksでは、サーバーレスコンピュートのネットワーク接続をNCCで管理します。アカウント管理者がNCCを作成し、同じリージョンの1つまたは複数のワークスペースに関連付けます。そのうえで、接続先のAzureリソースごとにPrivate Endpoint Ruleを追加し、リソース所有者がAzure側で接続要求を承認すると、サーバーレスコンピュートから対象リソースへプライベートエンドポイント経由でアクセスできるようになります。(Microsoft Learn)
管理者が最初に確認すべきことは、次の4点です。
| 確認項目 | 実務で見るべきポイント |
|---|---|
| 利用プラン | Azure DatabricksアカウントとワークスペースがPremiumプランか |
| 権限 | Azure Databricksのアカウント管理者権限があるか |
| リージョン | NCCとワークスペースが同じAzureリージョンか |
| 接続先 | Azure Storage、Azure SQL、Key Vaultなど、対象リソースごとにPrivate Endpoint Ruleを作成しているか |
単に「Private Linkを有効化する」という作業ではありません。接続先リソース、サブリソースID、ワークスペースの関連付け、Azure側の承認、サーバーレスコンピュートの再起動までを一連の変更として扱う必要があります。
今回の対象は「サーバーレスからAzureリソースへのアウトバウンド接続」
Azure DatabricksのPrivate Linkには複数の種類があります。今回の「Configure private connectivity to Azure resources」が扱うのは、ユーザーがAzure Databricksワークスペースへ入る通信ではなく、Azure Databricksのサーバーレスコンピュートから、顧客管理のAzureリソースへ出ていく通信です。
Azure DatabricksのPrivate Linkは、大きく分けると次のように整理できます。
| 種類 | 主な目的 | 今回の対象か |
|---|---|---|
| Inbound / front-end | ユーザー、REST API、Databricks Connectなどからワークスペースへの接続をプライベート化 | いいえ |
| Outbound / serverless | サーバーレスコンピュートからAzure StorageやAzure SQLなどへプライベート接続 | はい |
| Classic compute / back-end | クラシックコンピュートからDatabricks制御プレーンへの接続をプライベート化 | いいえ |
公式ドキュメントでは、Outbound Private Linkは「Azure Databricksサーバーレスコンピュートから顧客のAzureリソースへの接続」を保護するものと説明されています。Azure StorageやAzure SQLなどへパブリックインターネットを経由せずにアクセスしたい場合、この構成が検討対象になります。(Microsoft Learn)
ここを誤解すると、設計ミスが起きます。たとえば「ワークスペースへのログインをPrivate Link化したから、サーバーレスからストレージへの通信もプライベート化された」と判断するのは危険です。ユーザー接続のプライベート化と、サーバーレスからデータソースへのプライベート化は別の設計要素です。
影響範囲：どのワークロードが関係するのか
今回の設定が関係するのは、Azure Databricksのサーバーレスコンピュートを使ってAzureリソースへアクセスするワークロードです。公式情報では、NCC private endpointsはSQL warehouses、jobs、notebooks、Lakeflow Spark Declarative Pipelines、model serving endpointsでサポートされています。(Microsoft Learn)
影響を受けやすいのは、次のような環境です。
| 利用シーン | 確認すべきこと |
|---|---|
| Serverless SQL WarehouseからADLS Gen2を参照している | Storageアカウント向けにdfsやblobのPrivate Endpoint Ruleが必要か |
| サーバーレスNotebookでUnity Catalog上のデータを処理している | モデル保存、ログ出力、外部ロケーションの接続先がPrivate Link経由で到達できるか |
| Model Servingでモデルアーティファクトを読み込む | Azure Blob Storage向けのPrivate Endpoint Ruleが必要か |
| Azure SQL DatabaseやKey Vaultに接続している | 対象サービスがサポート対象か、サブリソースIDが正しいか |
| 複数ワークスペースを同じ部門・リージョンで運用している | 1つのNCCを共有する設計が適切か |
特に注意したいのは、クラシックコンピュートとの混在です。公式ドキュメントでは、Azureリソース側を「Private Endpointからの接続のみ許可」にした場合、クラシックDatabricksコンピュートからそのリソースへ接続する通信もPrivate Endpointを使う必要があると説明されています。(Microsoft Learn)
つまり、サーバーレス向けのセキュリティ強化を進めた結果、既存のクラシッククラスターやジョブが接続できなくなる可能性があります。変更前に、どのワークロードがサーバーレスで、どれがクラシックコンピュートなのかを棚卸ししておくべきです。
NCCとは何か：ワークスペース単位ではなくアカウント・リージョン単位で考える
NCCは、Network Connectivity Configurationの略です。Azure Databricksのサーバーレスネットワーク接続を管理するための、アカウントレベルかつリージョン単位の構成です。アカウント管理者がNCCを作成し、同じリージョンのワークスペースに関連付けます。(Microsoft Learn)
実務上のポイントは、NCCを「ワークスペースごとの設定」としてではなく、部門・環境・リージョン単位の接続ポリシーとして設計することです。
たとえば、次のように分けると管理しやすくなります。
| NCCの分け方 | 向いているケース |
|---|---|
| 事業部ごと | 接続先データソースや承認者が部門ごとに異なる |
| 環境ごと | 本番、検証、開発で接続先を分離したい |
| 接続方式ごと | Private Link利用とファイアウォール許可方式を分けたい |
| リージョンごと | ワークスペースとAzureリソースのリージョンを明確に分離したい |
公式ドキュメントでも、同じビジネスユニットとリージョンのワークスペースでNCCを共有することが推奨されています。一方で、Private Linkを使うワークスペースとファイアウォール有効化を使うワークスペースでは、用途に応じて別のNCCを使う考え方が示されています。(Microsoft Learn)
設定変更の流れ：管理者が実際に行う作業
Configure private connectivity to Azure resourcesの基本的な設定は、次の順序で進めます。
| 手順 | 作業 | 失敗しやすいポイント |
|---|---|---|
| 1 | NCCを作成する | ワークスペースと異なるリージョンで作成してしまう |
| 2 | NCCをワークスペースに関連付ける | 反映待ちとサーバーレス再起動を忘れる |
| 3 | Private Endpoint Ruleを作成する | リソースIDやサブリソースIDを誤る |
| 4 | Azureリソース側で接続要求を承認する | Databricks側だけ設定して完了したと思い込む |
| 5 | 必要に応じてPublic network accessを無効化する | 既存ジョブや外部サービスの接続断を見落とす |
| 6 | サーバーレスリソースを再起動し、接続テストする | 反映前にテストして誤判定する |
NCCをワークスペースに関連付けた後は、変更反映まで10分程度待ち、実行中のサーバーレスサービスを再起動する手順が示されています。また、Private Endpoint Ruleを作成した後は、Azureリソース側で承認し、Databricks側のステータスがESTABLISHEDになることを確認します。(Microsoft Learn)
実務では、設定作業を1人で完結できないケースが多くあります。Azure Databricksのアカウント管理者、Azureリソースの所有者、ネットワーク管理者、セキュリティ担当者が関係するため、作業前に承認フローを決めておくことが重要です。
Private Endpoint Ruleで確認すべきサブリソースID
Private Endpoint Ruleは、接続先Azureリソースごとに作成します。その際に重要になるのが、Azure subresource IDです。Azure Storageの場合、オブジェクトストレージアクセスではblobまたはdfs、Azure Static Website Hostingではwebを指定します。(Microsoft Learn)
たとえば、ADLS Gen2を使うデータ分析基盤では、dfsだけでなくblobが必要になる場面があります。モデルサービングでは、モデルアーティファクトのダウンロードにAzure Blob Storageパスを使うため、blob向けのPrivate Endpoint作成が必要です。一方、サーバーレスNotebookからUnity Catalogにモデルをログする場合はdfsも必要になるとされています。(Microsoft Learn)
よくある確認漏れは次の通りです。
| 対象 | 見落としやすい点 |
|---|---|
| ADLS Gen2 | dfsだけ指定し、blob経由の処理を見落とす |
| Model Serving | モデルアーティファクト取得用のBlob接続を忘れる |
| Key Vault | データ本体ではなくシークレット参照経路を見落とす |
| Azure SQL | SQL側のPrivate Endpoint承認とDNS確認を後回しにする |
| App Gateway v2 | Account Console UIではなくREST APIが必要な点を見落とす |
Azure App Gateway v2にPrivate Linkを構成する場合は、Azure DatabricksのAccount Console UIではなく、Network Connectivity Configurations REST APIを使う必要があります。App Gateway v2では、resource ID、group ID、domain namesといった追加パラメーターが必要です。(Microsoft Learn)
サポート対象リソース：Azure Storageだけではない
Private connectivity from serverless computeは、Azure Storageだけでなく複数のAzureサービスに対応しています。公式情報では、Azure AI Search、Azure AI Services、Azure API Management、Azure App Gateway v2、Azure App Service、Azure Cache for Redis、Azure Database for MySQL、Azure Database for PostgreSQL、Azure Event Grid、Azure Event Hub、Azure Key Vault、Azure SQL Database、Azure SQL Managed Instance、Azure Service Bus、Standard Load Balancer背後のリソースなどが対象として示されています。(Microsoft Learn)
ただし、すべてのリソースで同じように設定できるわけではありません。App Gateway v2のようにREST APIが必要なものもあります。Azure Chinaではサポート状況やリージョン制約が異なり、Azure AI Searchがサポートされないなどの差分もあります。(Microsoft Learn)
グローバル企業で複数クラウドリージョンやAzure Chinaを含む構成を管理している場合は、「本社の設計をそのまま全リージョンへ横展開する」のではなく、リージョンごとのサポート対象と制限を確認する必要があります。
移行期限：今回のPrivate Link設定自体に一律の期限は示されていない
今回の「Configure private connectivity to Azure resources」そのものについて、すべての利用者に対する一律の移行期限が示されているわけではありません。したがって、Private Link化は「特定日までに必ず移行」というより、セキュリティ要件、ファイアウォール設計、サーバーレス利用状況に応じて計画的に進める変更と考えるのが現実的です。
ただし、関連するサーバーレスネットワーク設定には期限付きの注意点があります。既存のAzure StorageアカウントでAzure DatabricksサーバーレスのサブネットIDを許可リストに入れている場合、2026年6月9日までにNetwork Security Perimeterへオンボードし、AzureDatabricksServerlessサービス タグを許可する必要があるとされています。(Microsoft Learn)
また、サーバーレスのアウトバウンドIP許可リストについては、2026年5月25日までに新しいJSON公開方式へ移行する必要があると説明されています。期限後に移行が不完全な場合、ワークロードに影響が出る可能性があります。(Microsoft Learn)
2026年7月時点では、これらの期限はすでに過去の日付です。まだ旧方式のサブネットID許可や古いIPリストを使っている環境では、Private Link、NSP、公開アウトバウンドIPのどれを使うべきかを早急に整理する必要があります。
Private LinkとNSP・サービス タグの使い分け
Azure DatabricksサーバーレスからAzureリソースへ接続する方法は、Private Linkだけではありません。Azure Storageなどでは、Network Security Perimeter（NSP）とAzureDatabricksServerlessサービス タグを使う構成もあります。
使い分けは次のように考えると分かりやすくなります。
| 接続方式 | 向いているケース | 注意点 |
|---|---|---|
| Private Link / Private Endpoint Rule | パブリック経路を避け、接続先を明確に限定したい | Private Endpoint Rule、承認、コスト、DNS確認が必要 |
| NSP + Service Tag | 同一リージョンのAzure Storageに対するサーバーレス接続を簡素化したい | NSPはPublic Preview扱いの情報が含まれるため採用判断が必要 |
| アウトバウンドIP許可 | Private Link非対応の接続先や一部リソースを許可リストで扱う | IP更新の自動化が必要で、静的コピーは破綻しやすい |
公式ドキュメントでは、Azure Storageアカウントに対するNSPでは、リージョン別のAzureDatabricksServerless.[region]サービス タグを使うことが推奨されています。グローバルタグを許可すると対象範囲が広くなるため、セキュリティ面ではリージョン別タグを優先するのが実務的です。(Microsoft Learn)
一方で、専用のプライベート接続が必要な場合は、IP許可リストではなくOutbound Private Linkを使う考え方が示されています。機密データ、規制対応、社内セキュリティ基準で「公開経路を避ける」ことが求められる場合は、Private Linkを優先して検討すべきです。(Microsoft Learn)
コスト面で見落としやすいポイント
Private Linkはセキュリティを高める一方で、コスト確認が必要です。公式ドキュメントでは、サーバーレスワークロードが顧客リソースへ接続する場合や、パフォーマンス集約型サービスがクロスリージョンでクライアントへデータを返す場合に、Azure Databricksのネットワーク関連コストが発生することが示されています。(Microsoft Learn)
特に注意したいのは、使われていないPrivate Endpoint Ruleです。Private Endpoint Ruleは接続状態にかかわらず、存在している時間に対してAzure側で課金されると説明されています。不要なルールは削除しなければ、REJECTEDやDISCONNECTEDのままでもコストが残る可能性があります。(Microsoft Learn)
コスト管理では、次の運用を入れておくと安全です。
| 運用項目 | 実施内容 |
|---|---|
| 月次棚卸し | NCCごとにPrivate Endpoint Ruleの一覧と状態を確認 |
| 未承認ルールの確認 | PENDINGが長期間残っていないか確認 |
| 不要ルール削除 | 使わなくなった接続先のPrivate Endpoint Ruleを削除 |
| クロスリージョン確認 | ワークスペースとリソースのリージョン差によるデータ転送を確認 |
| タグ付け | 用途、部門、所有者、環境をNCC管理台帳に記録 |
セキュリティ強化のためにPrivate Linkを導入したものの、不要な接続定義が残り続けると、コストだけでなくアクセス経路の棚卸しも難しくなります。
管理者が変更前に作るべきチェックリスト
本番環境で設定する前に、次のチェックリストを使うと作業漏れを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| 対象ワークスペース | サーバーレスSQL、Notebook、Jobs、Model Servingの利用有無 |
| コンピュート種別 | サーバーレスとクラシックの混在状況 |
| 接続先リソース | Storage、SQL、Key Vault、Event Hubなどの一覧 |
| リソースID | Azure PortalのJSON Viewなどで正しいResource IDを取得 |
| サブリソースID | Storageならblob、dfsなど用途に応じて確認 |
| リージョン | NCC、ワークスペース、Azureリソースのリージョン |
| 権限 | Databricksアカウント管理者、Azureリソース承認者 |
| 承認フロー | Private Endpoint接続要求を誰が承認するか |
| 既存ファイアウォール | Public network access無効化による影響 |
| テスト方法 | SQL WarehouseやNotebookから実データに対して接続確認 |
| ロールバック | 失敗時にPublic accessや既存ルールを戻せるか |
特に重要なのは、Public network accessを無効化するタイミングです。Private EndpointがESTABLISHEDになり、サーバーレスワークロードの接続テストが成功してから制限を強化するのが安全です。設定途中で先に公開アクセスを閉じると、既存ジョブやBI連携が失敗する可能性があります。
設定後の確認：ESTABLISHEDだけで終わらせない
Private Endpoint Ruleのステータスには、PENDING、ESTABLISHED、REJECTED、DISCONNECTED、EXPIREDがあります。PENDINGはリソース側の承認待ち、ESTABLISHEDはリソース側で確立済みの状態です。REJECTED、DISCONNECTED、PENDINGの状態が続くと、Private Endpoint Ruleは14日後に期限切れになると説明されています。(Microsoft Learn)
また、Private Endpoint Ruleの変更は多くの場合10分以内にサーバーレスコンピュートへ反映されますが、完全適用まで最大24時間かかる場合があります。(Microsoft Learn)
そのため、確認は次の3段階で行うべきです。
| 段階 | 確認内容 |
|---|---|
| Databricks側 | Private Endpoint RuleがESTABLISHEDになっている |
| Azure側 | Private endpoint connectionsで承認済みになっている |
| ワークロード側 | SQL Warehouse、Notebook、Jobなどから実際にクエリや読み書きが成功する |
ステータス確認だけでは不十分です。実際のワークロードで、読み取り、書き込み、モデル取得、シークレット参照など、業務で使う操作をテストしてください。
よくある失敗と回避策
NCCとワークスペースのリージョンが一致していない
NCCは同じリージョンのワークスペースに関連付ける必要があります。ワークスペース更新画面で作成したNCCが見えない場合、まずリージョン不一致を疑うべきです。(Microsoft Learn)
回避策は、命名規則にリージョンを含めることです。たとえば、ncc-prod-eastus2-dataのようにしておくと、誤関連付けを減らせます。
Azure側の承認を忘れる
Databricks側でPrivate Endpoint Ruleを作成しても、Azureリソース側で承認されるまで有効になりません。承認作業はAzure Portalの対象リソース側で行います。(Microsoft Learn)
回避策は、作業チケットに「Databricks側作成」と「Azure側承認」を別タスクとして記載することです。
サーバーレスサービスを再起動していない
NCCをワークスペースへ関連付けた後は、実行中のサーバーレスサービスを再起動する必要があります。反映待ちをせずにテストすると、設定が失敗しているように見えることがあります。(Microsoft Learn)
回避策は、メンテナンス時間を設け、変更後にSQL Warehouseや関連ジョブを再起動してから接続確認することです。
クラシックコンピュートの影響を見落とす
リソース側でPrivate Endpoint接続のみを許可すると、クラシックDatabricksコンピュートからの接続もPrivate Endpoint対応が必要になる場合があります。(Microsoft Learn)
回避策は、対象データソースへアクセスしているクラスター、ジョブ、外部BIツールを事前に洗い出すことです。
App Gateway v2をUIで設定しようとする
Azure App Gateway v2向けのPrivate Link設定では、Account Console UIではなくREST APIが必要です。resource ID、group ID、domain namesなどの追加情報も必要になります。(Microsoft Learn)
回避策は、App Gateway v2を対象に含める場合だけ、APIベースの変更手順を別途用意することです。
グローバル企業での運用設計ポイント
グローバル環境では、単一リージョンの手順をそのまま全社展開すると失敗しやすくなります。NCCはリージョン単位で考える必要があり、Azure Chinaではサポートリージョンやサービス対応に差分があります。たとえばAzure Chinaでは、NCCはChina North 3リージョンのみ対応とされ、Azure ChinaではPrivate Endpointがサーバーレスコンピュートの唯一のサポート接続方式として説明されています。(Microsoft Learn)
グローバル運用では、次のような管理台帳を用意すると実務に落とし込みやすくなります。
| 管理項目 | 記録例 |
|---|---|
| リージョン | East US 2、West Europe、Japan East、China North 3 |
| ワークスペース | 本番分析、検証分析、部門別ワークスペース |
| NCC名 | リージョン・環境・用途が分かる名称 |
| 接続先リソース | Storage、SQL、Key Vaultなど |
| Private Endpoint Rule | Resource ID、subresource ID、状態 |
| 所有者 | Databricks管理者、Azureリソース管理者 |
| 承認日 | Azure側で接続承認した日付 |
| テスト結果 | SQL、Notebook、Job、Model Servingの確認結果 |
| 削除予定 | 一時的な検証ルールの撤去期限 |
この台帳がないと、数カ月後に「どのPrivate Endpoint Ruleがどのジョブのために必要なのか」が分からなくなります。セキュリティ強化と同時に、運用の見える化も進めるべきです。
管理者が次に取るべき行動
Azure Databricksでサーバーレスコンピュートを使っている管理者は、まず対象ワークロードと接続先Azureリソースを棚卸ししてください。そのうえで、Private Linkが必要な接続、NSPとサービス タグで十分な接続、アウトバウンドIP許可が残る接続を分けて整理します。
次に、NCCをリージョン・環境・部門単位でどう分けるかを決めます。NCC作成後は、ワークスペースへの関連付け、Private Endpoint Ruleの作成、Azure側承認、サーバーレスサービスの再起動、実ワークロードでの接続確認までを一連の変更作業として実施します。
今回の更新ポイントは、単なる設定手順の追加ではなく、Azure Databricksサーバーレスのネットワーク管理を「ワークスペース単位の場当たり設定」から「NCCを軸にしたリージョン単位の接続管理」へ移すことにあります。機密データを扱う環境ほど、早い段階で接続方式を標準化し、不要な公開経路や古い許可リストを残さない運用へ移行することが重要です。
コメント