Azure Databricksの2026年4月更新で最初に確認すべきポイントは、Unity Catalogのガバナンス強化、Lakeflowによるデータ取り込み・変換の拡張、ExcelやPower BIなどBI連携への影響、AIエージェント運用の自動化です。特に、ABACのGA、Excel Add-inのプレビュー有効化必須化、Workspace base environmentsのGA、Supervisor AgentのSDK管理対応、Power BIコネクタのBI compatibility mode削除は、管理者・データエンジニア・分析責任者が早めに確認すべき変更です。
Microsoft Learnの「Azure Databricks platform release notes」では、2026年4月に多数のAzure Databricks platform improvementsが公開されています。なお、リリースは段階的に展開されるため、アカウントやワークスペースへの反映が初回リリースから1週間以上遅れる場合があります。グローバル環境でAzure Databricksを運用している場合は、「公式発表済み＝自社環境で即利用可能」と判断せず、対象リージョン、ワークスペース設定、プレビュー有効化状況を確認することが重要です。(Microsoft Learn)
Azure Databricks 2026年4月更新の全体像
2026年4月のAzure Databricks更新は、単発の新機能追加というより、データ基盤を“より統制しやすく、より現場で使いやすく、よりAI活用に接続しやすくする”ための更新群と捉えると理解しやすくなります。
| 領域 | 主な更新 | 実務での見方 |
|---|---|---|
| ガバナンス | ABACのGA、Governed tagsのGA、Data ClassificationのGA | Unity Catalog中心のアクセス制御・機密データ管理を本格運用しやすくなる |
| データエンジニアリング | Lakeflow Designer、Query-based connectors、パイプライン履歴保持60日 | ETL/ELTの設計、監視、トラブル調査の選択肢が増える |
| BI・現場分析 | Excel Add-inのプレビュー有効化必須化、Google Sheets connector GA、Power BI連携の変更 | セルフサービス分析の導入前に管理者設定と既存レポート影響を確認する必要がある |
| AI・ML | Supervisor Agent SDK/API、ai_parse_document GA、ai_prep_search、Vector Search評価 | RAG、ドキュメント解析、AIエージェント運用の実装が進めやすくなる |
| セキュリティ・運用 | Scoped PAT GA、CMKのModel Serving対応、Compute log delivery to volumes GA | 監査、暗号化、トークン権限管理をより細かく設計できる |
管理者が最優先で確認したい変更
ABACがGAに：Unity Catalogのアクセス制御設計を見直す
2026年4月のAzure Databricks更新で最も大きいガバナンス関連の変更は、Attribute-based access control（ABAC）のGAです。ABACはUnity Catalog上のデータ資産に付与されたgoverned tagsを使い、行フィルターや列マスクのポリシーを動的に適用するアクセス制御モデルです。ポリシーはカタログ、スキーマ、テーブルのレベルに適用でき、条件に一致するセキュリティ保護対象へ自動的に反映されます。(Microsoft Learn)
実務上のポイントは、ビューや関数経由でABAC保護テーブルを参照する場合の評価IDが変わることです。GAに伴い、ビューまたは関数の所有者ではなく、クエリを実行したセッションユーザーのIDで行フィルターや列マスクが評価されます。Microsoftのリリースノートでは、この変更はbreaking changeとして説明されています。影響を受ける可能性がある顧客には3カ月の猶予期間がある一方、通知対象外または新規顧客では新しい挙動が既定となります。(Microsoft Learn)
ABACを利用している、または今後利用する組織は、次の観点で確認すると失敗を避けやすくなります。
| 確認項目 | 見るべきポイント |
|---|---|
| ビュー・関数経由の参照 | 実行ユーザーの権限で期待どおりにマスク・フィルターされるか |
| タグ設計 | 個人情報、機密情報、部門別データなどのタグ体系が重複していないか |
| ポリシー適用範囲 | カタログ単位で広くかけるべきか、スキーマ・テーブル単位で限定すべきか |
| テストユーザー | 管理者、一般分析者、外部委託者など複数ロールで検証しているか |
| 監査 | 本番反映前後で想定外に見える・見えないデータがないか |
ABACは「テーブルごとに個別設定する」運用から、「タグとポリシーで横断的に管理する」運用へ移行するための機能です。便利な一方で、タグ設計が曖昧なまま導入すると、同じデータに複数の制御ルールが重なり、分析者から見た挙動が分かりにくくなります。まずは機密列の多いスキーマや、部門横断で使われるデータマートから小さく検証するのが現実的です。
Excel Add-inはプレビュー有効化が必須に
2026年4月24日の更新では、Azure Databricks Excel Add-inを利用するには、ワークスペース管理者がPreviewsページでExcel Connector previewを有効化する必要があると明記されました。すでにExcelからDatabricksデータを利用しようとしている組織では、ユーザー側のインストール手順だけでなく、ワークスペース側の設定確認が必要です。(Microsoft Learn)
Excel Add-inは、Azure DatabricksワークスペースとMicrosoft Excelを接続し、Unity Catalogで管理されたLakehouseデータをスプレッドシート上で扱うための機能です。Microsoft Learnでは、Excel for the web、WindowsのMicrosoft 365版Excel、Mac版Excelなどに対応し、SSO認証とUnity Catalogのガバナンスをサポートすると説明されています。利用にはUnity Catalogが有効なワークスペース、ワークスペースURL、稼働中のSQL warehouse、Unity Catalogテーブルへの読み取り権限などが必要です。(Microsoft Learn)
導入前には、次の順で確認するとスムーズです。
| 手順 | 確認内容 |
|---|---|
| 1 | ワークスペース管理者がExcel Connector previewを有効化する |
| 2 | 対象ユーザーがUnity Catalog上の必要なテーブルを読めるか確認する |
| 3 | Excelから接続するSQL warehouseを決める |
| 4 | Microsoft 365管理センター経由で全社配布するか、セルフサービス導入にするか決める |
| 5 | 認証エラーや「Need admin approval」が出た場合の問い合わせ先を決める |
Excel連携は分析部門にとって便利ですが、ガバナンスを飛び越えてデータを配布する手段にしてはいけません。特に、財務データ、人事データ、顧客データをExcelで扱う場合は、ワークスペース管理者、Microsoft 365管理者、データオーナーの3者で利用範囲を決めてから展開するべきです。
Power BIコネクタのBI compatibility mode削除に注意
Power BI利用組織では、BI compatibility modeの削除が見逃せません。Microsoftのリリースノートでは、Power BI Azure Databricks connectorからBI compatibility mode optionが削除され、このオプションを使っていたレポートは機能しなくなると説明されています。BI compatibility mode自体は他のBIツールでは引き続き利用可能とされていますが、Power BIでUnity Catalog metric viewsを参照していた場合は、既存レポートの棚卸しが必要です。(Microsoft Learn)
実務では、まずPower BIレポートのうちAzure Databricks connectorを使っているものを抽出し、metric views依存の有無を確認します。影響がある場合は、代替クエリ、別の接続方式、Databricks SQL側でのビュー設計見直しを検討してください。分析責任者にとっては「機能が消えた」というより、BI基盤の依存関係を明文化するタイミングと捉えるとよいでしょう。
データエンジニア向け：Lakeflowとデータ取り込みの更新
Lakeflow Spark Declarative Pipelinesの履歴保持が60日に延長
Lakeflow Spark Declarative Pipelinesでは、更新履歴の保持期間が30日から60日に延長されました。対象はパイプラインUIに表示される更新情報と、Pipelines REST APIから返される更新情報です。(Microsoft Learn)
この変更は地味に見えますが、運用現場では効果があります。月次処理、四半期処理、月またぎの障害調査では、30日では履歴が足りないことがあります。60日保持されることで、過去のパイプライン更新、失敗、復旧状況を追いやすくなります。
ただし、履歴が長く残るからといって、監査ログや運用レポートの設計を省略できるわけではありません。SLA管理、障害報告、監査証跡として使う場合は、別途ログ保管やチケット管理と紐づけておくと安全です。
Lakeflow Designerはノーコード型のデータ準備に有効
Lakeflow DesignerはPublic Previewとして公開され、ドラッグ＆ドロップのキャンバスと自然言語を使ってデータ変換ワークフローを作成できます。Microsoft Learnでは、Azure Databricks内で動作するvisual、no-code、AI-nativeなデータ準備・分析体験であり、Unity Catalogによってガバナンスされると説明されています。(Microsoft Learn)
向いているのは、次のようなケースです。
| 向いているケース | 理由 |
|---|---|
| 分析部門が簡単な前処理を自分で作りたい | ドラッグ＆ドロップで試せるため、SQLやPySparkに不慣れでも始めやすい |
| データエンジニアが要件を素早く可視化したい | 会話やレビューで変換ロジックを確認しやすい |
| PoCから本番化までの距離を縮めたい | Databricks内で作成し、Unity Catalogの統制下で扱える |
一方で、本番パイプラインへ組み込む場合は、生成されたワークフローの責任範囲、レビュー手順、変更管理を決めておく必要があります。「ノーコードだから管理不要」ではなく、「ノーコードでも本番データに触るなら管理対象」と考えるべきです。
Query-based connectorsはCDCが難しいDB取り込みの選択肢
Lakeflow Connectでは、Query-based connectorsがPublic Previewになりました。これはソースDBを直接クエリし、cursor columnを使って新規・更新行を取り込む方式です。Oracle、Teradata、SQL Server、MySQL、MariaDB、PostgreSQLなどが対象に含まれ、CDC構成やingestion gatewayが不要な点が特徴です。(Microsoft Learn)
CDC connectorとの違いは、次のように整理できます。
| 観点 | Query-based connectors | CDC database connectors |
|---|---|---|
| 取り込み方式 | ソーステーブルを直接クエリ | binlogなど変更イベントを利用 |
| 必要な列・構成 | 単調増加するタイムスタンプや整数のcursor columnが重要 | CDCやbinlogの利用設定が必要 |
| ソースDB負荷 | クエリが直接ソースに当たるため負荷設計が必要 | 変更ログ中心のため方式が異なる |
| 取り込み頻度 | スケジュール実行 | 継続的な変更取得に向く |
| 向いている用途 | CDCを使いにくいDB、日次・時間単位の同期 | 変更履歴を細かく追いたい基幹連携 |
注意点は、Query-based connectorsでは各実行時点の最新状態を取得するため、実行間に発生したすべての中間状態を保持する用途には向きません。また、ソースDBに直接クエリを実行するため、DBAと連携し、ピーク時間帯を避ける、対象列を絞る、cursor columnに適切なインデックスを用意するなどの配慮が必要です。
DBAs・プラットフォーム管理者向け：接続、SQL warehouse、運用設計
SSH reverse tunnelでオンプレミス接続の選択肢が増加
2026年4月更新では、Azure上のproxy VMを使ったSSH reverse tunnelにより、classic computeとserverless computeからオンプレミスリソースへ接続できるようになりました。ポイントは、オンプレミス側のinbound firewall accessを開けずに接続できることです。(Microsoft Learn)
これは、オンプレミスDBをすぐクラウド移行できない組織にとって有用です。ただし、ネットワーク設計を簡略化できる機能ではなく、むしろ責任分界点を明確にする必要があります。
確認すべき項目は次の通りです。
| 確認項目 | 実務上の注意点 |
|---|---|
| proxy VMの管理 | OS更新、監視、アクセス制御を誰が担当するか |
| 認証情報 | SSHキーや接続情報のローテーションをどう行うか |
| ネットワーク経路 | Databricks、Azure VNet、オンプレミス間の許可範囲を最小化しているか |
| 障害時対応 | トンネル切断時にジョブがどう失敗し、誰へ通知されるか |
| 監査 | 接続ログ、DBアクセスログ、Databricks側ログを突合できるか |
DBA視点では、「Databricksからつながるようになった」だけで本番投入するのではなく、ソースDBへの負荷、バックアップ時間帯、メンテナンス時間帯との衝突を確認することが重要です。
5X-Large SQL warehouseは大規模BI向けに検証価値あり
5X-Large SQL warehouse sizeがPublic Previewとして全リージョンで利用可能になりました。Microsoftのリリースノートでは、serverlessとpro SQL warehouses向けに512 workersを提供すると説明されています。(Microsoft Learn)
使いどころは、大量同時アクセスのダッシュボード、重い集計クエリ、グローバル部門が同時に参照するBI基盤などです。ただし、大きいwarehouseは万能ではありません。クエリの書き方、データレイアウト、キャッシュ、キューイング、コスト管理を見直さずにサイズだけ上げると、費用対効果が悪くなります。
検証時は、次の順で進めると判断しやすくなります。
| 検証項目 | 判断基準 |
|---|---|
| 同時実行数 | ピーク時に待ち時間が減るか |
| クエリ時間 | 代表クエリのp95、p99が改善するか |
| コスト | 1レポート表示あたり、1ユーザーあたりのコストが許容範囲か |
| 代替策 | データモデリング、パーティション、集計テーブルで改善できないか |
| 運用制御 | 利用できるユーザーや時間帯を制限できるか |
BI・分析リーダー向け：Excel、Google Sheets、Power BIをどう扱うか
Excel Add-inとGoogle Sheets connectorの拡充により、Azure Databricksは専門エンジニアだけでなく、業務部門の分析ユーザーにも近づいています。Databricks Connector for Google SheetsはGAとなり、Unity Catalogデータやmetric viewsの取り込み・クエリに使えるとされています。(Microsoft Learn)
ただし、スプレッドシート連携は便利な反面、データの持ち出し、再配布、古いデータの参照といったリスクもあります。分析責任者は、次のルールを先に決めるべきです。
| ルール | 例 |
|---|---|
| 利用対象 | 財務部門、営業企画、データ分析チームなどに限定する |
| 対象データ | 認証済みデータマート、metric views、公開可能な集計テーブルに限定する |
| 更新頻度 | 日次、週次、手動更新など業務要件に合わせる |
| 権限 | Unity Catalogの権限を前提にし、個別共有で迂回しない |
| 問い合わせ | Excel側、Databricks側、Microsoft 365側の一次対応窓口を分ける |
特にExcel Add-inは、導入時にMicrosoft 365管理者が関与する場合があります。現場主導で先に広げると、認証エラーや管理者承認の問題で止まりやすくなります。小規模なパイロットグループで接続、権限、パフォーマンス、問い合わせフローを確認してから広げるのが安全です。
AI・ML担当者向け：Supervisor AgentとRAG関連機能の広がり
Supervisor AgentをSDKで管理できるように
2026年4月24日の更新では、Databricks SDK for Pythonを使ってSupervisor Agentとそのtoolsを作成・管理できるようになりました。これはBetaの機能です。Supervisor Agentは、Genie Spaces、agent endpoints、Unity Catalog functions、MCP serversなどを連携させ、複雑なタスクを複数の専門エージェントで処理するための仕組みです。(Microsoft Learn)
SDK管理により、AIエージェントの作成やtool追加を手作業だけに頼らず、環境構築や検証フローに組み込みやすくなります。たとえば、開発・検証・本番の各ワークスペースで同じSupervisor Agent構成を再現する、ツールの説明文を標準化する、変更内容をコードレビューに乗せるといった運用が考えられます。
一方で、Microsoft Learn上では、SDKによるSupervisor Agent管理はBetaであり、Previewsページから制御できると説明されています。また、現時点の制約として、英語のみのサポート、単一supervisor system内のagent数上限、Enhanced Security and Compliance有効ワークスペース非対応などが記載されています。(Microsoft Learn)
本番業務に使う前に、以下を確認してください。
| 確認項目 | 理由 |
|---|---|
| 利用言語 | 日本語業務で使う場合、英語サポート制約の影響を確認する |
| 権限 | subagent、Genie Space、Unity Catalog function、MCP connectionごとの権限を確認する |
| Preview/Beta扱い | SLAやサポート範囲を本番要件と照合する |
| 監査 | 誰がどのagentに何を問い合わせたか追跡できるようにする |
| ガードレール | toolが扱うデータ範囲、外部接続、実行可能操作を制限する |
ai_parse_documentのGAでドキュメント解析が使いやすくなる
ai_parse_document関数はGAとなり、PDF、画像、Word文書、PowerPointファイルなどの非構造化ドキュメントから構造化コンテンツを解析できます。Microsoftのリリースノートでは、最大500ページ、100MBまでのドキュメント制限が示されています。(Microsoft Learn)
さらに、ai_prep_searchがBetaとして公開されました。これはai_parse_documentの構造化出力を、Vector SearchやRAGパイプラインで使いやすい検索用チャンクに変換するSQL関数です。ドキュメント解析から検索、回答生成までをDatabricks上でつなげたいチームにとって、実装の部品がそろいつつあります。(Microsoft Learn)
実務では、次のような流れで検証するとよいでしょう。
| ステップ | 内容 |
|---|---|
| 1 | 対象文書を分類する。契約書、仕様書、マニュアル、議事録など |
| 2 | ai_parse_documentで抽出品質を確認する |
| 3 | ai_prep_searchで検索向けチャンクに変換する |
| 4 | Vector Searchで検索品質を評価する |
| 5 | 誤回答しやすい文書、表、図、古い版の扱いをルール化する |
RAGでは、モデル性能だけでなく、元文書の版管理と検索品質が重要です。古いマニュアルと最新マニュアルが混在していると、どれだけ優れたモデルを使っても誤った回答が出やすくなります。Unity Catalogのタグ、ドキュメントの有効期限、部署別の参照権限を合わせて設計してください。
Workspace base environments GAはサーバーレスNotebook運用に効く
2026年4月24日の更新では、Workspace base environmentsがGAになりました。これは、ワークスペース管理者がserverless notebooks向けに事前構築・キャッシュされた環境を作成、管理できる機能です。(Microsoft Learn)
実務上の価値は、Python依存関係のばらつきを減らせることです。たとえば、分析チームごとに異なるバージョンのライブラリを入れてNotebookが再現できない、ジョブ実行時に依存関係のインストールで時間がかかる、といった問題を抑えやすくなります。Microsoft Learnでは、base environmentを選択するとキャッシュ済み環境が読み込まれ、notebooksやjobsの起動・実行性能の改善につながると説明されています。(Microsoft Learn)
ただし、制限もあります。base environmentsは全ワークスペースユーザーが利用可能であり、ワークスペースあたりの上限や、Lakeflow Spark Declarative Pipelinesではサポートされない点などが記載されています。標準環境を作る際は、「全員が使ってよい依存関係」だけを入れることが重要です。(Microsoft Learn)
おすすめの運用は、次のように用途別に環境を分けることです。
| 環境名の例 | 用途 |
|---|---|
| standard-analytics | pandas、numpy、可視化など一般分析向け |
| ml-basic | scikit-learn、MLflowなど基本的なML検証向け |
| data-eng | データ処理、検証、社内共通ライブラリ向け |
| restricted-prod | 本番ジョブに近い依存関係を固定する検証向け |
環境を増やしすぎると管理が難しくなるため、最初は2〜3種類に絞るのが現実的です。更新時は既存Notebookセッションの再起動が必要になる場合があるため、ライブラリ更新のタイミングも運用ルールに含めてください。
Preview、Beta、GAの違いを踏まえて採用判断する
Azure Databricksの2026年4月更新には、GA、Public Preview、Betaが混在しています。Microsoft Learnでは、PreviewはGA前の機能へ早期アクセスするためのもので、Betaは多くの顧客が利用できるものの既定ではOff、GAは正式サポートされ本番利用可能な段階として整理されています。また、Private PreviewやBetaには本番利用を意図しない制約、SLAや正式サポート対象外といった注意点があります。(Microsoft Learn)
採用判断は次のように分けると安全です。
| 状態 | 採用判断 |
|---|---|
| GA | 本番利用候補。ただし自社環境へのロールアウト状況と権限設計を確認する |
| Public Preview | PoCや限定部門で検証。重要業務では代替手段を用意する |
| Beta | 技術検証中心。本番依存は避け、仕様変更を前提に扱う |
特に、5X-Large SQL warehouse、Lakeflow Designer、Query-based connectors、Supervisor Agent SDK/API、ai_prep_searchなどは魅力的ですが、すべてを一度に本番へ入れる必要はありません。まずは、業務インパクトが大きく、失敗時の影響を制御しやすいテーマから検証するべきです。
役割別に見る次のアクション
データエンジニアがやるべきこと
データエンジニアは、Lakeflow、serverless notebooks、RAG関連の更新を中心に確認しましょう。最初に見るべきなのは、既存パイプラインの履歴確認、Query-based connectorsで代替できる取り込み元、Workspace base environmentsで標準化できるNotebook環境です。
特に、CDCを使えないデータソースがある場合は、Query-based connectorsのPoC価値があります。ただし、ソースDB負荷とcursor columnの設計をDBAと確認してから進めてください。
DBAs・プラットフォーム管理者がやるべきこと
DBAやプラットフォーム管理者は、ABAC、Power BI連携、Excel Add-in、SSH reverse tunnel、SQL warehouse sizingを優先的に確認しましょう。既存のデータアクセス経路が変わる可能性があるため、まずは「誰が、どのツールから、どのデータにアクセスしているか」を棚卸しすることが重要です。
Power BIのBI compatibility mode削除は、既存レポートの停止につながる可能性があります。Excel Add-inは利用前にワークスペース側のPreview有効化が必要です。この2点は、業務ユーザーから問い合わせが来る前に周知しておくべきです。
分析リーダーがやるべきこと
分析リーダーは、スプレッドシート連携とデータガバナンスのバランスを見直しましょう。ExcelやGoogle SheetsからDatabricksのデータにアクセスしやすくなる一方で、持ち出しや二次配布のリスクも増えます。
推奨される進め方は、全社展開ではなく、特定部門でのパイロットです。利用対象データ、更新頻度、権限、問い合わせフローを決め、問題がなければ段階的に展開します。
2026年4月更新は「統制されたセルフサービス化」がテーマ
Azure Databricksの2026年4月更新は、単に新機能が増えたというより、ガバナンスを保ちながら、より多くのユーザーがデータとAIを使えるようにする更新です。
まず確認すべきは、ABACのGAに伴うアクセス制御の挙動、Excel Add-inのプレビュー有効化、Power BIコネクタ変更による既存レポート影響です。次に、Workspace base environments、Lakeflowの履歴保持、Query-based connectorsを使って、データエンジニアリング運用を標準化します。そのうえで、Supervisor Agent、ai_parse_document、Vector Search関連機能を検証すると、AI活用をデータ基盤の上に安全に広げやすくなります。
Azure Databricksを本番利用している組織は、今回のリリースノートを「新機能一覧」として読むのではなく、権限、接続、BI、AI、運用標準の見直しチェックリストとして扱うのが最も実務的です。
コメント