Azure Databricksのサーバーレスコンピューティングは、クラスタを自分でプロビジョニングせずにノートブックやジョブを実行できるマネージドサービスです。ただし「サーバーレス」と呼ばれる機能はワークロードごとに分かれており、構成の入口も課金も別々です。加えてネットワーク許可の方式が2026年に切り替わり、以前の手順書が使えなくなっています。この記事では対象となるワークロードの区別、ストレージ接続の現行方式、コストの見方までを公式ドキュメントの記述で整理します。サーバーレスという方式そのものの仕組みはサーバーレスとは？仕組み・メリットとコンテナとの使い分けを解説で扱っています。
まとめ：押さえるべき4点
先に要点を挙げます。
- 対象は3つ：サーバーレスコンピューティングとして構成するのはノートブック、ワークフロー（ジョブ）、Lakeflowパイプラインです。サーバーレスSQLウェアハウスやモデルサービングは同じ基盤で動きますが、別に構成・管理されます。
- Unity Catalogが必須：有効化されたワークスペースであれば既定で使え、手動の有効化手順はありません。逆にUnity Catalogに対応していないレガシワークスペースはアクセスできません。
- ネットワーク許可の方式が変わった：同一リージョンのAzure Storageはネットワークセキュリティ境界（NSP）とサービスタグ、それ以外は公開された送信IPを使います。NCCからコピーした安定IPなどのレガシIPリストは2026年5月25日で使用停止です。
- コストは事後に見る：料金の見積もりは代表的なワークロードを実行してから
system.billing.usageを分析する方法が推奨されています。課金の反映には最大24時間の遅延があります。
サーバーレスコンピューティングの対象になるワークロード
混乱の元は、Azure Databricksに「サーバーレス」と名の付く機能が複数あることです。公式ドキュメントが「サーバーレスコンピューティング」として扱うのは次の3つです。
| ワークロード | 構成の入口 | 用途 |
|---|---|---|
| サーバーレスノートブック | ノートブックのコンピューティング選択 | 対話的な分析・開発 |
| サーバーレスジョブ | ジョブのコンピューティング設定 | 定期実行・バッチ処理 |
| サーバーレスLakeflowパイプライン | パイプライン設定 | 宣言的なETL |
一方、サーバーレスSQLウェアハウス、モデルサービング、AI機能もサーバーレス基盤の上で動きますが、これらは独自の構成パスを持ち、上の3つとは別に管理されます。「サーバーレスを有効にしたのにSQLウェアハウスの設定が見当たらない」という混乱は、この区別が原因です。
利用の要件は2つだけ
必要なのは、ワークスペースでUnity Catalogが有効になっていること、そしてサーバーレスがサポートされているリージョンにあることです。この2つを満たしていれば既定で利用可能で、有効化の手続きはありません。逆に、Unity Catalogに移行していないレガシワークスペースはサーバーレスコンピューティングを使えません。この場合はまずUnity Catalogへのアップグレードが前提になります。
ランタイムはバージョンレス
サーバーレスコンピューティングは「バージョンレス製品」と位置づけられており、ランタイムはDatabricksが自動でアップグレードします。ワークロードは常に最新のランタイムで実行されるため、Databricks Runtimeの版を固定して長期運用する、という運用はできません。ライブラリの互換性を版で固定したい要件があるなら、クラシックコンピュートを選ぶ判断になります。
ストレージへの接続｜NSPとサービスタグ
ファイアウォールで保護されたリソースにサーバーレスから接続する場合、方式はリソースの種類で分かれます。
ワークスペースと同一リージョンのAzure Storageでは、ストレージアカウントをネットワークセキュリティ境界（NSP）に関連付け、受信規則でサービスタグAzureDatabricksServerlessを許可します。推奨されているのはリージョン付きのタグ（例：AzureDatabricksServerless.EastUS2）で、グローバルタグを許可すると全リージョンのDatabricksからのアクセスを通してしまいます。
注意が必要なのは移行期限です。サーバーレスのサブネットIDを許可リストに持っていた既存のストレージアカウントは、2026年6月9日までにNSPへ参加し、サービスタグを許可する必要がありました。この期限は既に過ぎています。旧方式のまま残っている環境があれば、接続の可否を確認してください。
「境界で保護」にすると壊れる
設定でつまずきやすい点があります。リソースをNSPに関連付けたあと、Azureポータルは境界内のリソースに対して「境界で保護」を推奨してきますが、この設定にしてはいけません。公式ドキュメントは、パブリックネットワークアクセスを「選択したネットワークから有効」のままにするよう明記しています。
「境界で保護」にすると、サーバーレスコンピューティングは外部ロケーションへ到達できなくなり、PERMISSION_DENIEDや「Request for user delegation key is not authorized」といったエラーで失敗します。アクセスモードも移行モードを無期限で維持することが推奨されており、強制モードはほとんどのケースで推奨されていません。強制モードはDatabricks以外のサービスにも影響するためです。
東日本ワークスペースはタグが1つでは足りない
リージョン付きのサービスタグを使う場合、ワークスペースのリージョンだけでは不足することがあります。公式ドキュメントは東日本のワークスペースには西日本にセカンダリの成果物ストレージがあると明記しており、この場合はセカンダリリージョンのサービスタグも追加する必要があります。国内リージョンを使う環境では、ここが見落としやすい落とし穴です。
NCCと送信IP｜2026年に方式が切り替わった
同一リージョンのストレージ以外のリソース（他リージョンのストレージ、データベース、外部API）へは、サーバーレスがパブリックIPで到達します。そのため、リソース側のファイアウォールにDatabricksの送信IPを許可リスト登録する必要があります。
ここが2026年に変わった部分です。2026年2月中旬以降、送信IPはパブリックエンドポイントでJSON形式（ip-ranges.json）で公開される方式になりました。そしてパブリックプレビューの安定IPや、アカウントコンソールのネットワーク接続構成（NCC）からコピーしたレガシIPリストは、2026年5月25日で使用停止になっています。NCCから安定IPをコピーする手順を書いた記事や社内手順書は、この時点で使えません。
許可リストの更新は自動化が前提
送信IPは固定ではありません。公式は次のように運用条件を示しています。
- IPの更新は30日に1回程度発行される。
- 新しいIPは発行の60日後にアクティブになる。
- 新しいリージョンも定期的に追加される。
つまり一度コピーして貼るだけの運用では、いずれ接続が切れます。公式が示す手順は、定期的にip-ranges.jsonを取得し、timestampSecondsを保存済みのコピーと比較して変更を検知し、自分のplatformとregionに該当するipv4Prefixesでファイアウォールを更新する、というものです。フィルタ条件はserviceがDatabricks、typeがoutbound、platformがazure、そしてregionがワークスペースのリージョンと一致するエントリです。
なお、専用のプライベート接続が必要なら、IP許可の代わりにアウトバウンドPrivate Link接続を使う選択肢があります。
コストの見方｜見積もりより実測が推奨されている
サーバーレスのコスト把握について、公式が推奨しているのは事前の理論計算ではありません。代表的なワークロードあるいは特定のワークロードを実際に実行してベンチマークし、その後に課金システムテーブルを分析するという順序です。
分析先はsystem.billing.usageシステムテーブルで、ワークロード単位のDBU使用量を確認できます。ここで注意すべきは反映の遅延です。ワークロードを実行してから使用状況がテーブルに反映されるまで、最大24時間かかることがあります。実行直後に数字が出ないからといって課金されていないわけではありません。
身に覚えのない課金レコードの正体
サーバーレスジョブを実行していないのに、サーバーレスジョブの課金レコードが現れることがあります。これは異常ではありません。データ品質の監視と予測最適化がサーバーレス基盤で動作し、サーバーレスジョブSKUで課金されるためです。これらの機能はノートブックやジョブのサーバーレスコンピューティングとは別に管理されているため、こちらを止めても課金は止まりません。原因を追う際は、まずこの2機能の有効状態を確認してください。
実装前に確認すべき制限
採用判断に直結する制限があります。
- カスタムデータソースには接続できない。サポートされるのはLakehouse Federationを使うソースのみです。独自コネクタで外部システムへ直接つなぐ設計は成立しません。
- 認証が必要なリポジトリには事前署名URLが要る。プライベートリポジトリの利用自体は可能ですが、セキュリティ上の理由で事前に署名されたURLが必要になります。
- ランタイムの版を固定できない。バージョンレス製品のため自動でアップグレードされます。
- ファイアウォール設定はクラシックコンピュートにも影響する。サーバーレス向けに許可リストを変更すると、クラシックコンピュートからの接続にも影響が出るため、両方の経路を同時に確認する必要があります。
ライブラリの管理については、ジョブタスクごとに個別インストールするのではなく、環境（environment）を利用する方法が推奨されています。ローカル環境から実行したい場合はDatabricks Connectを使います。
よくある質問
Azure Databricksのサーバーレスコンピューティングにはどんな種類がありますか？
サーバーレスコンピューティングとして構成するのは、ノートブック、ワークフロー（ジョブ）、Lakeflowパイプラインの3つです。サーバーレスSQLウェアハウスやモデルサービング、AI機能も同じサーバーレス基盤で動作しますが、これらは別に構成・管理される機能で、上の3つとは設定の入口が異なります。
サーバーレスを使うのに有効化の手続きは必要ですか？
不要です。ワークスペースでUnity Catalogが有効になっており、サーバーレスがサポートされているリージョンにあれば、既定で利用できます。逆にUnity Catalogに対応していないレガシワークスペースは利用できないため、その場合はUnity Catalogへのアップグレードが先になります。
NCCからコピーした安定IPは今も使えますか？
使えません。2026年5月25日でレガシIPリストは使用停止になりました。現在の方法は、Databricksが公開するip-ranges.jsonを取得し、service・type・platform・regionで絞り込んだipv4Prefixesをファイアウォールに登録する方式です。IPは30日に1回程度更新され、新しいIPは発行の60日後に有効になるため、許可リストの更新は自動化してください。
ストレージへの接続でNSPを「境界で保護」にしてもよいですか？
してはいけません。公式ドキュメントは、リソースのパブリックネットワークアクセスを「選択したネットワークから有効」のままにするよう明記しています。「境界で保護」にすると、サーバーレスコンピューティングが外部ロケーションへ到達できず、PERMISSION_DENIEDなどのエラーで失敗します。アクセスモードも移行モードの維持が推奨されています。
サーバーレスのコストはどう見積もればよいですか？
公式が推奨しているのは、代表的なワークロードを実際に実行してベンチマークし、system.billing.usageシステムテーブルでDBU使用量を分析する方法です。事前の理論値ではなく実測を前提としています。課金の反映には最大24時間の遅延があるため、実行直後に数字が出ないことを異常と判断しないでください。
