SharePointやOneDrive上のExcel、CSV、PDF、Office文書をAzure Databricksに取り込みたい場合、今回のポイントは「SharePoint上のファイルをDeltaテーブルへ取り込む方法が、より実務向けに整理・拡張されたこと」です。2026年6月6日に更新されたAzure Databricksのリリースノートでは、Lakeflow ConnectのマネージドSharePointコネクタが、CSV、JSON、XML、Excel、Parquet、Avro、ORCなどの構造化ファイル取り込み、ファイルメタデータ取り込み、ファイルフィルター、スキーマ進化、スキーマヒントに対応したと説明されています。(Microsoft Learn)
一方で、すぐに本番移行してよい機能ではありません。SharePointコネクタはBetaとして提供されており、Unity Catalog、Databricks Runtime、OAuth権限、プレビュー機能の有効化、SharePoint側のURL設計を事前に確認する必要があります。管理者は「誰の権限で、どのサイト・ライブラリ・フォルダまで読ませるか」を決め、開発者は「Auto Loader、spark.read、COPY INTO、マネージドコネクタのどれを使うか」を用途別に判断するのが重要です。(Microsoft Learn)
SharePoint / OneDriveの「Ingest files from SharePoint – Azure Databricks」は何が変わるのか
「Ingest files from SharePoint – Azure Databricks」は、SharePoint上の構造化、半構造化、非構造化ファイルをAzure Databricksへ取り込み、Deltaテーブルとして扱うための公式ガイドです。標準SharePointコネクタでは、Auto Loader、spark.read、SQLのread_files、COPY INTO、Lakeflow Spark Declarative Pipelinesを使って、SharePointファイルをバッチまたはストリーミングで読み込めます。(Microsoft Learn)
今回の更新で特に注目すべき点は、SharePoint連携が「単にPDFやOffice文書をバイナリとして持ってくる」だけではなく、CSVやExcelのような業務データをDeltaテーブル化し、AI検索、RAG、レポーティング、データ品質管理に使いやすくなったことです。Databricksのリリースノートでは、マネージドSharePointコネクタが従来の非構造化中心の取り込みから、統一されたマネージドファイルソースAPIへ広がったと位置付けられています。(Microsoft Learn)
実務上の影響は大きく、たとえば次のような使い方が現実的になります。
| 利用シーン | 取り込み対象 | Azure Databricks側の活用例 |
|---|---|---|
| 経理・営業部門のExcel集計を分析基盤に連携 | .xlsx、.xls | Deltaテーブル化、BI、監査用履歴管理 |
| SharePointに保存されたCSVログを継続取り込み | .csv | Auto LoaderやCOPY INTOで差分ロード |
| PDFやWord文書をAI検索に使う | PDF、DOCX、PPTX | バイナリ取り込み後に文書解析、RAG用データ化 |
| ファイル台帳を作る | ファイル名、サイズ、更新日時、作成者 | メタデータのみ取り込み、棚卸し・監査 |
| 複数部門のデータ収集を標準化 | サイト、ライブラリ、フォルダ | Unity Catalogで権限管理しながらDelta化 |
ここで注意したいのは、OneDriveという名前で見えているファイルでも、実体がSharePointサイトやMicrosoft 365グループのドキュメントライブラリにあるケースが多いことです。Microsoft Graphのファイルモデルでは、Microsoft 365のファイルは「drive」として扱われ、個人のOneDriveやSharePointドキュメントライブラリ上の共有ドライブに保存されます。Databricks側の機能名はSharePointコネクタなので、まずは対象ファイルのURLがSharePointサイト、ドキュメントライブラリ、フォルダ、ファイルのどれに該当するかを確認してください。(Microsoft Learn)
変更点の中心はマネージドSharePointコネクタの拡張
Azure Databricksには、SharePoint向けに大きく分けて2つの選択肢があります。1つはLakeflow ConnectのマネージドSharePointコネクタ、もう1つはSQLやPySparkで柔軟に実装する標準SharePointコネクタです。公式ドキュメントでは、多くの用途ではマネージドSharePointコネクタが推奨されていますが、複雑な変換や既存パイプラインへの組み込みが必要な場合は標準コネクタが候補になります。(Microsoft Learn)
| 観点 | マネージドSharePointコネクタ | 標準SharePointコネクタ |
|---|---|---|
| 向いている用途 | 定型的なSharePointファイル取り込みを低メンテナンスで運用したい場合 | PySpark、SQL、既存ジョブで細かく制御したい場合 |
| 実装の考え方 | Lakeflow Connectでパイプラインとして管理 | Auto Loader、spark.read、read_files、COPY INTOなどで実装 |
| 主なメリット | 差分取り込み、構造化ファイル、メタデータ取り込み、ファイルフィルターをまとめて扱いやすい | 変換処理、スキーマ制御、文書解析、既存ワークフロー連携の自由度が高い |
| 注意点 | Beta機能。運用頻度や制限を確認する必要がある | コード、スキーマ、チェックポイント、ジョブ監視を自分たちで設計する必要がある |
| 判断基準 | まず安定してDeltaテーブルへ同期したい | 取り込み時に複雑な加工やAI処理を組み込みたい |
マネージドSharePointコネクタのリファレンスでは、FILEでファイル内容とメタデータを取り込む方法、FILE_METADATAでメタデータだけを取り込む方法が示されています。対応形式にはBINARYFILE、CSV、JSON、XML、EXCEL、PARQUET、AVRO、ORCが含まれます。(Microsoft Learn)
対象になるファイルとURL範囲
標準SharePointコネクタでは、SharePointのサイト、サブサイト、ドキュメントライブラリ、フォルダ、単一ファイルを指定して取り込めます。Databricks Runtime 18.3以降では、テナントルート、ネストされたサブサイト、共有リンク、Microsoft 365 for the webで開いたファイルURLも対象として追加されています。(Microsoft Learn)
実装前に必ず確認すべきなのは、「ユーザーが見ている場所」と「Databricksに渡すURL」が一致しているかです。WindowsのエクスプローラーでOneDrive同期フォルダとして見えていても、Databricksに渡すのはローカルパスではなく、SharePointまたはMicrosoft 365上のURLです。
| 対象 | 確認するURL | 実務上の注意点 |
|---|---|---|
| SharePointサイト全体 | https://tenant.sharepoint.com/sites/site-name | 取り込み範囲が広くなりやすい。まずはフォルダ単位で検証する |
| ドキュメントライブラリ | Shared DocumentsやカスタムライブラリのURL | ライブラリ名にスペースや日本語がある場合、URLエンコードを確認する |
| フォルダ | 対象フォルダのパスまたは詳細ペインのPath | 業務部門がフォルダ構成を変更するとパイプラインに影響する可能性がある |
| 単一ファイル | プレビュー画面や詳細ペインから取得したURL | テストや固定帳票の取り込みに向く |
| 共有リンク | Copy linkで取得したリンク | Databricksは期限切れしない共有リンクを推奨しているが、組織の共有ポリシーと衝突しないか確認する |
SharePoint Listsや.aspxのサイトページは標準SharePointコネクタの対象外です。対象はドキュメントライブラリ内のファイルであり、SharePointのリストデータを取り込む機能とは分けて考える必要があります。(Microsoft Learn)
管理者が確認すべき設定
SharePoint / OneDrive連携をAzure Databricksに展開する場合、最初に動かすべきなのはコードではなく権限設計です。特に本番運用では、個人アカウントで接続を作成して他のユーザーに共有する設計は避けるべきです。Databricksの接続作成ドキュメントでも、個人アカウントで認証した接続を共有すると、そのユーザーの資格情報とデータへのアクセスを他ユーザーに許可することになるため、共有しないよう警告しています。(Microsoft Learn)
Unity Catalogと接続権限
SharePointファイル取り込みにはUnity Catalogが前提になります。標準SharePointコネクタでは、Unity Catalogが有効なワークスペース、SharePoint接続を作成または利用するための権限、Databricks Runtime 17.3 LTS以降、OAuth認証、SharePoint Beta機能の有効化が必要です。(Microsoft Learn)
管理者は次の点を確認してください。
| 確認項目 | 判断基準 |
|---|---|
| Unity Catalogが有効か | 接続情報やDeltaテーブルをガバナンス下で管理できる状態にする |
CREATE CONNECTION権限を誰に与えるか | 接続作成は管理者またはデータ基盤担当に限定する |
USE CONNECTION権限を誰に与えるか | 開発者やデータ利用者には必要最小限の接続利用権限を付与する |
| 接続名の命名規則 | sp-finance-prod、sp-marketing-devのように環境と用途が分かる名前にする |
| 本番・検証環境の分離 | Preview機能の検証は本番ワークスペースでいきなり行わない |
プレビュー機能の有効化
SharePointコネクタはBetaとして提供されており、ワークスペース管理者がPreviewsページから利用可否を制御できます。Databricksのプレビュー機能はGA前の機能であり、BetaやPrivate Previewには本番利用を前提としない制約や、予告なく変更・終了される可能性がある点が明記されています。(Microsoft Learn)
そのため、本番展開の前に以下を決めておくべきです。
| 項目 | 推奨される進め方 |
|---|---|
| 検証環境 | 開発または検証用ワークスペースでPreviewを有効化する |
| 本番利用判断 | SLA、サポート範囲、社内のプレビュー機能利用ルールを確認する |
| 変更監視 | Databricksのリリースノートと関連ドキュメントの更新を定期確認する |
| ロールバック | 既存の取り込み経路を一定期間残し、並行稼働で差分を比較する |
OAuth権限と認証方式
標準SharePointコネクタでは、OAuth認証でSites.Read.AllまたはSites.Selectedの権限スコープが必要です。Sites.Read.Allは広範囲の読み取り権限になるため、セキュリティ要件が厳しい組織ではSites.Selectedを優先して検討し、対象サイトを明示的に絞る設計が望ましいです。(Microsoft Learn)
Lakeflow Connectの接続作成では、OAuth U2MのDatabricks-managed方式、カスタム管理方式、OAuth M2M、手動リフレッシュトークン方式が説明されています。Databricks-managedのOAuth U2MはAzureアプリ登録が不要で、DatabricksがOAuth設定とトークン更新を管理するため、多くのユーザーに推奨されています。一方、完全自動の本番パイプラインでは、ユーザー操作なしで実行するOAuth M2Mが候補になります。(Microsoft Learn)
開発者が選ぶべき取り込み方式
開発者は「どのAPIが使えるか」ではなく、「ファイルの更新頻度、形式、再処理のしやすさ、後続処理」から方式を選ぶべきです。
| 方式 | 向いているケース | 注意点 |
|---|---|---|
| Auto Loader | 新しいファイルを継続的に取り込みたい | cloudFiles.schemaLocationやチェックポイント設計が必要 |
spark.read | 検証、単発バッチ、既存PySpark処理への組み込み | 差分管理は別途設計する |
SQL read_files | SQL中心のチームがテーブル作成したい | スキーマ進化や例外処理の方針を決める |
COPY INTO | Deltaテーブルへ冪等な差分ロードをしたい | ファイルパターン、スキーママージ、再実行時の挙動を確認する |
| Lakeflow Spark Declarative Pipelines | パイプラインとして継続管理したい | SharePointコネクタ利用時はPreviewチャンネル設定が必要 |
標準SharePointコネクタでは、Auto Loaderを使ってSharePoint上のCSVやJSONなどを差分取り込みできます。非構造化ファイルはbinaryFileとして読み込み、PDFやOffice文書をAI処理へ渡す前段のBronzeテーブルとして使うのが現実的です。(Microsoft Learn)
Auto Loaderで継続取り込みする例
SharePointフォルダに追加されるPDFを継続的に取り込む場合は、次のような設計になります。実際のパス、接続名、スキーマ保存場所は自社環境に合わせて変更してください。
df = (
spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "binaryFile")
.option("databricks.connection", "sp_marketing_conn")
.option("cloudFiles.schemaLocation", "dbfs:/schemas/sharepoint/marketing_pdf")
.option("pathGlobFilter", "*.pdf")
.load("https://contoso.sharepoint.com/sites/Marketing/Shared%20Documents")
)この方式は「新しいファイルを検知して処理する」用途に向いています。ただし、SharePoint側のファイル削除や移動をどのように扱うか、古いファイルを再処理する条件、スキーマ保存場所の権限管理は事前に決めておく必要があります。
COPY INTOでDeltaテーブルへ差分ロードする例
日次でSharePoint上のCSVをDeltaテーブルに取り込むなら、COPY INTOも候補になります。COPY INTOはファイルをDeltaテーブルへ冪等にロードする用途に向いています。(Microsoft Learn)
COPY INTO bronze.sharepoint_sales_csv
FROM 'https://contoso.sharepoint.com/sites/Sales/Shared%20Documents/data'
FILEFORMAT = CSV
PATTERN = '*.csv'
FORMAT_OPTIONS (
'databricks.connection' = 'sp_sales_conn',
'header' = 'true',
'inferSchema' = 'true'
)
COPY_OPTIONS (
'mergeSchema' = 'true'
);本番ではinferSchemaに頼りすぎず、重要な列はスキーマヒントや明示的な型定義で固定するのが安全です。業務部門がExcelやCSVの列名を変更した場合、気付かないうちに列が増えたり型が変わったりするためです。
Excelファイルを扱う場合の注意点
SharePoint / OneDrive上の業務データではExcelファイルが多く使われます。Azure DatabricksのExcel読み取り機能では、.xlsと.xlsxを直接読み取り、シートやセル範囲を指定できます。dataAddressで読み取るシートや範囲を指定し、headerRowsでヘッダー行の扱いを指定する形です。(Microsoft Learn)
ただし、Excelはデータ基盤では扱いにくい落とし穴が多い形式です。次の条件に当てはまる場合、取り込み前にファイル設計を見直してください。
| Excelの状態 | 起きやすい問題 | 対策 |
|---|---|---|
| 1シートに複数表がある | 不要なセルや空白行まで取り込む | dataAddressで必要範囲だけ指定する |
| 結合セルが多い | 結合セルの左上以外がNULLになり、集計で欠損扱いになる | 取り込み用シートを別に用意する |
| 複数ヘッダー行がある | 列名が正しく解釈されない | 1行ヘッダーの表形式に整える |
| パスワード付きファイル | 読み取り対象外になる | SharePoint側で別の保護方法を検討する |
マクロ前提の.xlsm | マクロ実行はサポートされない | 計算済み値を取り込み用ファイルに出力する |
| ストリーミングExcel | スキーマ進化が使えない | スキーマを固定し、列変更時は手動レビューする |
DatabricksのExcelドキュメントでは、パスワード保護ファイル、Strict OOXML、マクロ実行、ignoreCorruptFilesなどがサポート対象外として示されています。また、Auto LoaderでExcelをストリーミングすることは可能ですが、スキーマ進化はサポートされないため、schemaEvolutionModeを明示的に設定する必要があります。(Microsoft Learn)
非構造化ファイルはAI活用を前提に設計する
PDF、Word、PowerPointなどの非構造化ファイルを取り込む場合、標準SharePointコネクタではbinaryFile形式として内容がバイナリデータで保存されます。そのままでは検索や分析に使いにくいため、Databricksではai_parse_documentを使って、テキスト、表、レイアウト情報、メタデータを抽出し、AIパイプラインで扱える形に変換する方法が示されています。(Microsoft Learn)
設計としては、いきなり文書を分割・ベクトル化するのではなく、次の3層に分けると運用しやすくなります。
| レイヤー | 内容 | 目的 |
|---|---|---|
| Bronze | SharePointから取得したファイル本体とメタデータ | 原本に近い状態で保持し、再処理可能にする |
| Silver | ai_parse_documentなどで抽出した本文、表、ページ情報 | 検索、分類、要約に使いやすい形にする |
| Gold | RAG用チャンク、検索インデックス、業務別ビュー | アプリケーションや業務ユーザーが利用する |
この分け方にすると、文書解析ロジックを後から改善しても、SharePointからの再取得を最小限に抑えられます。特に社内規程、契約書、提案書、議事録などは、ファイルの原本性と解析結果を分離しておくと監査対応もしやすくなります。
メタデータ取り込みで監査と差分管理がしやすくなる
SharePointファイル連携では、ファイルの中身だけでなく「誰が、いつ、どこに置いたファイルか」が重要です。標準SharePointコネクタには_sharepoint_metadataという隠しメタデータ列があり、SharePoint固有のプロパティを取得できます。ただし、この機能はPrivate Previewで、Databricks Runtime 18以上が必要です。(Microsoft Learn)
取得できるメタデータには、アイテムID、サイトID、ドライブID、親フォルダ、Web URL、MIMEタイプ、作成者、最終更新者、作成日時、更新日時、ETag、CTagなどが含まれます。特に実務で重要なのは、ファイルの内容変更を追うctagと、メタデータ変更も含めて変化するetagです。(Microsoft Learn)
マネージドSharePointコネクタでは、ファイル内容をダウンロードせずにメタデータだけを取り込むFILE_METADATAも用意されています。ファイル台帳、監査、対象ファイルの棚卸し、取り込み前の影響調査では、いきなり全ファイルを取り込むより、メタデータのみのパイプラインから始める方が安全です。(Microsoft Learn)
制限事項と失敗しやすいポイント
SharePoint / OneDrive連携で失敗しやすいのは、「ファイルを読めること」と「本番運用できること」を混同するケースです。公式ドキュメントには、標準SharePointコネクタとマネージドSharePointコネクタの制限が複数示されています。(Microsoft Learn)
| 注意点 | 影響 | 対策 |
|---|---|---|
| 非構造化ファイルは100MB以下のみ内容取得 | 100MB超のPDFや動画は本文を取り込めない | メタデータだけ取得する、対象ファイルを分割・除外する |
| 複数サイトを1つのクエリで取り込めない | 全社横断の一括取り込みが難しい | サイトごとにクエリやパイプラインを分ける |
| SharePoint Listsは対象外 | リストデータをファイルと同じ方法で読めない | 別のGraph APIや連携方式を検討する |
.aspxページは対象外 | サイトページを文書として取り込めない | ページ内容が必要なら別方式で抽出する |
| SharePointへの書き戻しは非対応 | DatabricksからSharePointを更新できない | 出力はDelta、CSV、Power BIなど別の公開先に置く |
Auto LoaderのcleanSource非対応 | 取り込み後にSharePoint側を自動削除・アーカイブできない | SharePoint側のライフサイクル管理は別途設計する |
| ファイル単位ACLの取り込み非対応 | SharePoint上の細かい権限をDelta側に再現できない | Unity Catalog側で別途アクセス制御を設計する |
| 頻繁すぎるスケジュール | SharePointやパイプライン負荷、運用コストが増える | マネージドコネクタでは多くても1時間に1回程度を目安にする |
| 個人アカウント接続の共有 | 個人の資格情報・データアクセスを他者に渡すリスク | 本番はサービスアカウントやM2Mを検討する |
| 共有リンクの期限切れ | ある日突然パイプラインが失敗する | 可能ならサイト・ライブラリ・フォルダURLを使う |
特に、100MB制限はAI活用で見落としやすいポイントです。PDFやPowerPointは画像を多く含むと簡単に100MBを超えます。大量の提案書や設計書をRAGに使う場合は、事前にファイルサイズ分布を集計し、対象外ファイルの扱いを決めてから取り込みを始めてください。
移行・展開時の進め方
既存のPower Query、Power Automate、手動ダウンロード、独自スクリプトでSharePointファイルを集めている組織は、いきなりAzure Databricksへ全面移行するのではなく、段階的に置き換えるのが安全です。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 棚卸し | サイト、ライブラリ、フォルダ、ファイル形式、サイズ、更新頻度、所有者を一覧化 | 取り込み対象と除外対象が決まっている |
| 権限設計 | OAuth方式、Sites.Selectedの可否、接続共有範囲を決める | 管理者・開発者・利用者の責任範囲が明確 |
| 小規模検証 | 1サイトまたは1フォルダでDeltaテーブル化 | 件数、スキーマ、更新検知、エラー処理を確認 |
| 並行稼働 | 既存方式とDatabricks方式の結果を比較 | 差分件数、欠損、重複、型変換ミスが許容範囲 |
| 本番展開 | スケジュール、通知、監視、リトライ、コスト管理を設定 | 障害時の連絡先と復旧手順がある |
| 継続改善 | スキーマ変更、フォルダ変更、権限変更を運用に組み込む | 業務部門の変更がパイプライン停止につながりにくい |
実装時は、まずメタデータのみ取り込み、ファイル数、サイズ、更新頻度、拡張子を確認するのがおすすめです。そのうえで、構造化ファイルはDeltaテーブルへ、非構造化ファイルはBronzeテーブルから文書解析へ進めると、無駄な取り込みや権限トラブルを減らせます。
管理者・開発者向けチェックリスト
本番に近い環境で検証する前に、次の項目を確認してください。
| チェック項目 | 管理者 | 開発者 |
|---|---|---|
| SharePoint Beta機能を有効化している | ○ | |
| Unity Catalogが有効で、接続・テーブルの権限設計がある | ○ | ○ |
| OAuth方式を決めている | ○ | |
Sites.Read.AllではなくSites.Selectedで足りるか検討した | ○ | |
| 個人アカウント接続を共有しない運用になっている | ○ | |
| Databricks Runtime 17.3 LTS以降を使う | ○ | ○ |
| 追加URL形式が必要ならRuntime 18.3以降を確認する | ○ | |
| Excel取り込みではシート、範囲、ヘッダー行を明示する | ○ | |
| 100MB超の非構造化ファイルの扱いを決める | ○ | ○ |
| SharePoint Listsやサイトページを対象にしていない | ○ | ○ |
| ファイル単位ACLをDelta側に再現できない前提で設計する | ○ | ○ |
| スキーマ進化の方針を決める | ○ | |
| エラー通知、再実行、重複確認の方法を決める | ○ | ○ |
| 既存取り込み方式との比較期間を設ける | ○ | ○ |
まず何から始めるべきか
SharePoint / OneDrive上のファイルをAzure Databricksへ取り込むなら、最初の一歩はコードを書くことではありません。対象となるSharePointサイト、ドキュメントライブラリ、フォルダ、ファイル形式、更新頻度、権限を棚卸しし、「マネージドコネクタで十分か、標準コネクタで細かく制御すべきか」を決めることです。
多くの組織では、次の順番で進めると失敗しにくくなります。
- 対象フォルダのメタデータだけを取り込み、ファイル数・サイズ・拡張子・更新頻度を確認する
- CSVやExcelなどの構造化ファイルを小さなDeltaテーブルへ取り込む
- PDFやOffice文書はBronzeテーブルに保存し、必要に応じて
ai_parse_documentで解析する - Unity Catalogで接続、テーブル、利用者権限を整理する
- 既存の取り込み方式と並行稼働し、件数・スキーマ・更新結果を比較する
- スケジュール、通知、再実行手順、コスト監視を整えてから本番化する
今回の「Ingest files from SharePoint – Azure Databricks」は、SharePoint / OneDriveに散在する業務ファイルを、データ分析やAI活用に載せるための重要な選択肢です。ただしBeta機能である以上、機能の新しさよりも、権限、制限事項、ファイル設計、運用監視を先に固めることが成功の条件になります。
コメント