Databricks 2026年5月4日のリリースノート解説: Runtime 18.2 GA、Lakeflow Pipelines Editor、List Dashboards API

Databricks は 2026年5月4日の公式リリースノートで、Databricks Runtime 18.2 の GA、Lakeflow Pipelines Editor の GA、そして List Dashboards API の sort order 変更を案内しました。基盤 runtime、ETL 開発体験、BI metadata API の3つが同日に動いているため、platform team と BI / data engineering team の両方が確認したい更新です。

要点

• Databricks Runtime 18.2 と Databricks Runtime 18.2 for Machine Learning が GA になった
• Lakeflow Pipelines Editor が GA になり、Genie Code を使った pipeline 開発・デバッグ体験が正式化された
• 2026年5月4日に List Dashboards API の返却順が変わる
• これまでの title alphabetic order ではなく、last modified date の reverse chronological order になる
• 旧バージョンの next_page_token は新バージョンで無効になる
• Runtime 更新、Lakeflow 開発体験、dashboard inventory 自動化をそれぞれ別の観点で検証したい

今回のリリースノートで語られていること

2026年5月4日の May 2026 リリースノートでは、まず Databricks Runtime 18.2 が GA として示されています。Runtime は Spark、ML、ライブラリ、互換性、性能、セキュリティ修正の土台になるため、単に「新しい runtime が出た」と読むより、既存 job、notebook、ML workload、cluster policy の検証対象が増えたと捉えるべきです。特に ML 版 runtime を使うチームでは、依存ライブラリ、model training / serving 周辺、GPU や feature engineering の互換性を staging で確認する必要があります。

同じ日付で、Lakeflow Pipelines Editor も GA になりました。Databricks はこの editor を、Genie Code を中心にした agent-first な pipeline 開発体験として説明しています。コードと Genie Code chat、pipeline graph、metrics を横に見ながら、production pipeline を作成、更新、debug できるという位置づけです。Lakeflow を使うチームにとっては、ETL / ELT 開発が notebook や job 定義の編集だけでなく、AI 支援と lineage / metrics を見ながら反復する workflow に寄っていくことを意味します。GA になったことで、PoC だけでなく標準開発手順、レビュー、運用引き継ぎの中に入れるかを検討しやすくなります。

一方、What's coming? では List Dashboards API の sort order 変更が 2026年5月4日に有効になると案内されています。Dashboard 一覧の返却順は、dashboard title の alphabetical order から、last modified date の新しい順へ変わります。実務上の影響は2つあります。1つ目は、返却順に依存した処理です。もし現在の処理が 名前順で返る ことを前提に差分検知や比較をしている場合、5月4日以降は結果順が変わります。2つ目は pagination token です。Databricks は、以前の API version で生成された next_page_token を新しい version に渡すと error になると説明しています。BI asset catalog、監査、同期処理、社内ポータル連携で token を保存している場合、切り替え前後の token をそのまま使い回さない設計が必要です。

対象になりそうなユーザー・チーム

• Databricks Runtime の標準版・ML 版を運用している platform team
• Lakeflow Pipelines を使う data engineering team
• Databricks SQL / Lakeview dashboards を API 経由で棚卸ししているチーム
• BI asset catalog、監査、migration、metadata sync を自動化している platform team
• next_page_token を保存して継続同期する batch / workflow を持つチーム
• Dashboard 更新順をもとに運用や governance を組みたい管理者

実務で確認したいポイント

まず、Databricks Runtime 18.2 を既存 job や ML workload に当てたときの互換性を staging で確認します。cluster policy や default runtime の変更予定がある場合は、依存 library、init script、ML package、UDF、streaming workload の差分を見ます。

次に、Lakeflow Pipelines Editor を本番 pipeline 開発に使う場合の review flow を決めます。Genie Code が作る変更をどう code review し、誰が pipeline graph と metrics を確認し、既存 CI/CD や Git 運用とどう合わせるかを整理します。

最後に、List Dashboards API を使う code path を探します。特に next_page_token を DB や state file に保存している処理、結果順に依存して差分を取る処理、名前順を前提に UI 表示や report を作る処理を確認します。

次に、5月4日以降の初回同期では古い token を破棄し、token なしで最初から取得する設計にしておくと安全です。必要なら、client 側で dashboard title による sort を明示的に行い、API の既定順変更に引きずられないようにします。

結局、この更新をどう見るべきか

これは単一機能の小さな更新ではなく、Databricks の開発・運用面が同時に進んだ日付です。Runtime 18.2 は実行基盤、Lakeflow Pipelines Editor は開発体験、List Dashboards API は BI metadata automation に効きます。特に API の並び順変更は dashboard 利用者向けの見た目ではなく、metadata を API で扱うチーム向けの breaking change なので、pagination state と sort 前提を早めに見直すべきです。