Azure DatabricksのLakeflow Connectは、SaaS、データベース、クラウドストレージ、メッセージバス、ファイルなどからデータを取り込むための機能群です。
2026年6月11日時点で押さえるべきポイントは、既存環境に強制的な移行が発生する更新ではなく、Lakeflow Connectが「Azure Databricksのデータ取り込み全体を扱う仕組み」として整理されたことです。管理者は、利用するコネクタの提供状態、Unity Catalogの権限、ネットワーク、増分取り込み方式、料金を確認してください。(Microsoft Learn)
Azure DatabricksのLakeflow Connectとは
Lakeflow Connectは、外部システムのデータをAzure Databricksへ取り込むための統合サービスです。対象には次のようなデータソースが含まれます。
- SalesforceなどのSaaS
- SQL Serverなどのデータベース
- クラウドオブジェクトストレージ
- Kafkaなどのメッセージバス
- ローカルファイルやアップロード済みファイル
特徴は、すべてを同じ方法で取り込むのではなく、要件に応じて管理レベルを選べることです。
| 方式 | 向いているケース |
|---|---|
| フルマネージドコネクタ | 対応済みのSaaSやデータベースを、少ない運用負担で取り込みたい |
| コミュニティコネクタ | マネージドコネクタがないデータソースに接続したい |
| 標準コネクタ | ストレージやメッセージバスから柔軟に取り込みたい |
| カスタムパイプライン | 独自の認証、変換、エラー処理が必要 |
| DIYによる独自実装 | PythonやJava、外部ライブラリを使って完全に制御したい |
Azure Databricksは、まず最も管理された方式を検討し、要件を満たさない場合にカスタマイズ性の高い方式へ移る考え方を推奨しています。(Microsoft Learn)
Azureの新機能・変更点：Lakeflow Connectの位置づけが明確化
今回の公式情報で重要なのは、Lakeflow Connectが単一のコネクタ名ではなく、データ取り込みに関する複数の選択肢をまとめた枠組みとして示された点です。
| 確認ポイント | 2026年6月時点の整理 | 利用者への影響 |
|---|---|---|
| 対象範囲 | SaaS、データベース、ファイル、ストレージ、ストリーミングをカバー | 既存の取り込み処理を共通基盤へまとめやすくなる |
| ガバナンス | 取り込み先をUnity Catalogで管理 | 権限やデータ所有者の設計が必要 |
| 実行管理 | Lakeflow Jobsによるスケジュール実行に対応 | 個別のジョブ管理を減らせる |
| 取り込み方式 | 増分読み取り・増分書き込みを活用 | 全件取得を繰り返す処理より効率化しやすい |
| デプロイ | UI、API、SDK、CLI、Declarative Automation Bundlesに対応 | 手動設定だけでなくCI/CDへ組み込める |
| 監視 | イベントログ、パイプライン状態、データ品質、課金情報を確認可能 | 障害監視とコスト監視を一体化できる |
フルマネージドコネクタでは、認証、CDC、再試行、スキーマ変更への対応などが自動化されます。障害時には自動再試行が行われ、可能な場合は前回の取り込み位置から処理を再開します。(Microsoft Learn)
Query-based connectorsも選択肢になる
Query-based connectorsは、CDCやデータベースの変更ログを使わず、タイムスタンプや連番などのカーソル列を基準に差分を取得する方式です。
取り込みゲートウェイやステージング領域を必要とせず、指定したスケジュールでソースデータベースを直接検索します。ただし、ソース側へのクエリ負荷や、実行間に発生した中間状態を取得できない点には注意が必要です。(Microsoft Learn)
なお、2026年5月29日のリリースノートでは一般提供と案内されていますが、2026年6月11日更新の詳細ページにはPublic Previewの表記が残っています。公式ページ間で提供状態の表記が一致していないため、本番導入時はワークスペース上の表示とサポート条件を確認してください。(Microsoft Learn)
誰に影響するのか
Azure Databricksの管理者
最も影響が大きいのは、ワークスペース、Unity Catalog、ネットワーク、予算を管理する担当者です。
特に確認が必要なのは、次の項目です。
- 対象リージョンでサーバーレスコンピューティングを利用できるか
- Unity Catalogの接続、カタログ、スキーマに必要な権限があるか
- Private Link、VNet、ExpressRouteなどの接続経路を確保できるか
- データ取り込みによるDBU消費を追跡できるか
- BetaやPublic Preview機能を本番環境で許可するか
データエンジニア
Azure Data Factory、ノートブック、独自スクリプト、外部ETL製品でデータを取り込んでいる担当者は、既存処理をLakeflow Connectへ置き換えられるか検討できます。
ただし、単純に「マネージドだから移行する」のではなく、次の点を比較してください。
- 対応するテーブルやオブジェクト
- 削除データの検出方法
- スキーマ変更時の動作
- 履歴を保持する必要性
- 取り込み遅延
- ソースシステムへの負荷
- 現在のETL製品を含めた総コスト
一般ユーザーやデータ分析担当者
一般ユーザーが直接コネクタを設定するケースは多くありません。ただし、取り込まれたデータがUnity Catalogで管理されるため、権限を与えられたデータの検索や再利用がしやすくなります。
一方、取り込み頻度が低いと分析対象のデータが古くなります。利用者は、テーブルの更新時刻やデータ品質を確認してから分析に使う必要があります。
どの取り込み方式を選ぶべきか
次の基準で判断すると、過剰なカスタム実装を避けやすくなります。
| 要件 | 選択候補 |
|---|---|
| 対応済みのSaaSやデータベースを安定運用したい | フルマネージドコネクタ |
| CDCを有効化できないが、更新日時や連番列がある | Query-based connector |
| 対応コネクタがなく、BetaやSLAなしを許容できる | コミュニティコネクタ |
| Kafkaやクラウドストレージから柔軟に取り込みたい | 標準コネクタ |
| 独自の変換や制御が必要 | Lakeflow Spark Declarative Pipelines |
| Structured Streaming固有の機能が必要 | Structured Streaming API |
| データをAzure Databricksへコピーしたくない | Lakehouse Federation |
コミュニティコネクタはDatabricksのSLA対象ではなく、将来の互換性も保証されません。基幹データに使用する場合は、ソースコードの確認、障害時の保守担当、代替手段を決めておく必要があります。(Microsoft Learn)
設定前に確認する手順
データソースと鮮度要件を整理する
最初に、取り込むデータと必要な更新間隔を明確にします。
「毎日更新されればよい顧客マスター」と「数分以内に反映したい注文データ」では、適切な取り込み方式が異なります。
コネクタの提供状態を確認する
コネクタごとに、一般提供、Public Preview、Betaなどの状態が異なります。概要ページだけでなく、利用予定のコネクタ固有ページを確認してください。
Azure Databricksの機能は段階的に展開されるため、公開日から1週間以上経過するまでワークスペースに反映されない場合もあります。(Microsoft Learn)
認証と権限を準備する
次の権限を担当者ごとに整理します。
- ソースシステムを読み取るサービスアカウント
- Unity Catalog接続を作成する権限
- 取り込み先カタログとスキーマを使用する権限
- テーブルやパイプラインを作成する権限
- 課金情報やシステムテーブルを参照する権限
個人アカウントをパイプラインの認証に使うと、異動や退職、パスワード変更で停止しやすくなります。原則として、運用専用のサービスプリンシパルやサービスアカウントを検討してください。
ネットワーク経路を確認する
SaaSコネクタは外部APIへ接続します。データベースコネクタでは、Private Link、VNetピアリング、ExpressRouteなどが必要になる場合があります。
「認証情報は正しいのに接続できない」というトラブルは、DNS、ファイアウォール、送信制御、許可IPの不足でも発生します。認証テストとネットワークテストを分けて実施すると原因を特定しやすくなります。(Microsoft Learn)
増分取り込みの条件を決める
次の動作は、稼働前にテストしてください。
- 新規行が取り込まれるか
- 更新された行が反映されるか
- 削除された行を検出できるか
- カーソル列が重複した場合に欠損しないか
- 列追加や型変更にどう対応するか
- SCD Type 1とType 2のどちらを使うか
特にQuery-based connectorsでは、適切なカーソル列が必要です。更新されない作成日時をカーソルにすると、既存行の変更を取得できません。
更新や移行は必要か
今回の概要ページには、既存パイプラインの自動変換、強制移行、サービス終了期限は記載されていません。そのため、ドキュメントが更新されたことだけを理由に、既存のAzure Data Factoryやノートブック処理をすぐ停止する必要はありません。(Microsoft Learn)
Lakeflow Connectへ移行する場合は、次の順序が安全です。
- 既存処理とは別のカタログまたはスキーマに出力する
- 初回の全件取り込みを完了させる
- 件数、主キー、合計値、更新日時を旧環境と比較する
- 更新、削除、スキーマ変更をテストする
- 下流の参照先を段階的に切り替える
- ロールバック期間を設けて旧処理を停止する
マネージド取り込みでは、最初の実行で選択したデータを全件取得し、その後は可能な範囲で変更分のみを取り込みます。初回ロードが完了する前に参照先を切り替えると、データ不足が発生するため注意してください。(Microsoft Learn)
料金と期限で確認すべきこと
Lakeflow Connectの料金は、コネクタの本数だけでは判断できません。データ量、実行頻度、初回ロード、変更量、パイプラインの維持処理がDBU消費に影響します。
Azure Databricksでは、ワークスペースごとに1日100 DBUのLakeflow Connect無料枠が案内されています。無料枠を超えると標準料金が適用されます。(Databricks)
| 費用項目 | 確認内容 |
|---|---|
| パイプライン処理 | 取り込みで消費したDBU |
| メンテナンス処理 | メタデータ管理や変更追跡に使われるDBU |
| データ保存 | 取り込み先テーブルが使用するストレージ |
| ソース側 | API利用料、データベース負荷、外向き通信料 |
| ネットワーク | Private Linkやデータ転送に関する費用 |
| 初回ロード | 全件取得による一時的な使用量増加 |
課金情報は、system.billing.usageテーブルでbilling_origin_product = 'LAKEFLOW_CONNECT'を条件に確認できます。処理が動いていない時間にも、パイプラインの維持や変更追跡に関する料金が発生する場合があります。(Microsoft Learn)
また、公式料金ページでは、50％のプロモーションが2026年6月30日までと案内されています。これは移行期限ではなく料金上の期限です。リージョン、契約、Azure Databricksのプランによって実際の請求条件が異なる可能性があるため、見積もり時はAzureの契約価格も確認してください。(Databricks)
Lakeflow Connect導入時の注意点
データは複製される
インジェストでは、ソースシステムのデータをAzure Databricksへコピーします。そのため、保存容量が増え、更新間隔によってはソースとの間に差が生じます。
データを複製せずに検索したい場合は、Lakehouse Federationを検討してください。(Microsoft Learn)
外部サービスの変更に影響される
SaaSやデータベース側のAPI、認証方式、仕様が変更されると、コネクタが動作しなくなる可能性があります。Databricksが制御できない外部サービスの変更によって、コネクタの保守や提供が終了する可能性も公式ドキュメントに明記されています。(Microsoft Learn)
Query-based connectorsはソース負荷を確認する
Query-based connectorsはソーステーブルを直接検索します。大きなテーブルに適切なインデックスがない場合、取り込み処理が業務データベースへ負荷を与える可能性があります。
本番導入前に、実行計画、読み取り行数、CPU使用率、ロック、実行時間を確認してください。
まず行うべき対応
Azure Databricksを利用している組織は、最初に現在のデータ取り込み処理を一覧化してください。そのうえで、対応するマネージドコネクタの有無と提供状態を確認します。
導入する場合は、重要度の低い1テーブルで初回ロードと増分更新を試し、データ品質とDBU消費を測定するのが安全です。問題がなければ、Declarative Automation Bundlesなどを使って設定をコード化し、開発、検証、本番環境へ段階的に展開してください。
コメント