はじめに
前回の記事では、OneLake のショートカットが
「データをコピーせず、他のストレージを参照できる仕組み」であることを整理しました。
OneLake の大きな特徴のひとつは、利用者が データの実体がどこにあるかを意識せずに扱える 点です。
Notebook から参照する場合も Files/... という統一的なパスでアクセスできるため、
ADLS・S3・OneLake 上のどこにデータが存在していても、同じように扱うことができます。
これは Fabric が提供する抽象化の大きなメリットです。
一方で、Notebook で 書き込み操作を行う立場（データ管理者・Notebook 実行者） の場合、
ショートカットの裏側にある実体ストレージによって更新先が変わるケースがあります。
この仕組みを理解していないと、意図しないストレージを書き換えるリスクにつながります。
そこで本記事では、まず Notebook とショートカットの関係を整理し、
そのうえで、
- OneLake 上のファイルの読み込み
- 加工
- Delta として保存
という基本の流れを確認します。
1. Notebook（Spark）で利用するパスの基本
Spark Notebook では、次のような 相対パス を使うのが基本です。
Files/folder-01/sample_sales.csv
ここでの Files は、「Notebook にアタッチしている Lakehouse の Files」を指します。
ショートカット配下のファイルであっても、Spark からは同じ書き方で操作できます。
利用者視点では、この統一的な見え方のおかげで
データの実体の在り処を意識せずに扱える というメリットがあります。
ただし Files は外部ストレージを含む参照領域である一方、
Tables は Lakehouse 内部の Delta 格納専用領域であり、
実体ストレージとして性質が異なる点には注意が必要です。
2. ショートカットは設定されている Credential で参照先にアクセスする
ショートカットには、参照先ストレージへの 接続（Connection） を設定します。
Connection は、接続先の URL などの設定（Connection settings）と、
認証に使う Credential（資格情報） で構成されます。
Notebook からショートカット経由で操作する場合、
この Connection に設定された Credential が認証に利用されます。
重要なのは次の点です。
ユーザー自身の権限とは別に、ショートカットの Credential が利用される
たとえば：
- ユーザー自身は ADLS の権限を持っていない
- しかしショートカットの Credential が ADLS にアクセスできる
- → Notebook からは普通に読み取れる
また Credential は作成後に更新でき、
実行時には常に最新の設定が利用されます。
3. 権限の“食い違い”が起きる理由
Notebook から OneLake を操作する際は、次の 2 つが 独立して判定 されます。
■ ユーザー → Lakehouse のアクセス権
Fabric / Workspace / Lakehouse で付与される権限。
■ Lakehouse → ショートカット先ストレージのアクセス権
ショートカットに設定された Credential。
そのためコード上では区別がつかず、
- 自分の権限で読めているのか
- Credential 経由で読めているのか
Notebook のコードだけでは判断できません。
4. Notebook 操作には “Spark の追加権限” が必要
セクション 2・3 では、ショートカットの Credential という権限軸を整理しました。
ここでは それとは別に、Notebook（Spark）の実行自体に必要な権限について触れます。
つまり、Notebook から OneLake を操作する際には、
- ショートカットの Credential（参照先ストレージへのアクセス）
- Spark の追加権限（Notebook 実行そのものの許可）
という 2 つの独立した権限軸 が関わります。
Lakehouse を共有しただけでは、Notebook での処理が許可されるとは限りません。
Lakehouse には 「追加のアクセス許可」 があり、Notebook を扱うには次が必要です。
- すべての Apache Spark を読み取る
- レイクハウスで Apache Spark ジョブを実行する
特に後者は、Delta 書き込みを含む Notebook 実行に必須です。
そのため、よくある状態として：
- Lakehouse の内容は閲覧できる
- SQL Endpoint のテーブルも読める
- しかし Spark の追加権限が無い
- → Notebook が動かない（Delta を書き込めない）
といった状況が起こります。
5. Notebook（Spark）で CSV を読み込む
Spark での基本的な読み込みは次のとおりです。
df = spark.read.csv("Files/folder-01/sample_sales.csv", header=True, inferSchema=True)
display(df)
ショートカット配下のファイルもこの書き方で読み込めます。
利用者視点では「どこにあるファイルか意識せずに扱える」のが利点です。
一方で実行時には Credential が利用されていることも理解しておく必要があります。
6. Delta として保存する（Spark）
Delta テーブルとして保存する最小の例は次のとおりです。
df.write.format("delta").mode("overwrite").save("Tables/sales_delta")
Tables/ 直下に任意の名前で保存すると、
Lakehouse 上で Managed Table として自動認識され、
Power BI や SQL Endpoint から利用できるようになります。
なお、Delta の保存方法には .save() のほかに saveAsTable() があります。
df.write.format("delta").mode("overwrite").saveAsTable("sales_delta")
両者の違いを整理すると次のようになります。
-
.save("Tables/sales_delta")は パス指定で Delta ファイルを書き出す方法です。
Tables/配下に書き込んだ場合、Lakehouse が検出して Managed Table として登録します。 -
.saveAsTable("sales_delta")は Metastore にテーブルを登録する 方法です。
パスの指定は不要で、Lakehouse のデフォルト Metastore に直接登録されます。
実務上は saveAsTable() のほうが意図が明確になりやすく、
テーブル名の管理も Metastore 側に統一できるため、扱いやすい場面が多いです。
.save() はパスの自由度が高い反面、命名やフォルダ構造の管理が利用者側に委ねられます。
7. ショートカット配下に書き込むとどうなるか
ショートカット配下への書き込みは、ショートカット先のストレージへ反映されます。
df.write.format("delta").mode("overwrite").save("Files/external/sales_delta")
Files/external が ADLS のショートカットだった場合：
- Notebook 実行者が ADLS 権限を持っていなくても
- Credential が Write 権限を持っていれば
- → ADLS 側に Delta が書き込まれる
Notebook 上のパスでは内部構造が分からないため、
更新先の誤認につながりやすい点が特徴です。
なお、ショートカット経由で外部ストレージに Delta を直接書き込むことは
技術的には可能ですが、推奨構成ではありません。
Delta の ACID 管理・Schema Enforcement・Time Travel など、
Lakehouse 内部でのみ保証される特性があるため、
更新系処理は Lakehouse（Tables）に統一する運用が望まれます。
8. 事故を避けるための運用上の考慮点
Fabric の抽象化により、利用者は実体を意識せずに扱えます。
一方で、更新系の処理を行う立場では、内部の仕組みを理解していないと誤更新のリスクがあります。
一般に取られる運用としては次のようなものがあります。
■ ショートカットの Credential は read-only にする
誤った書き込みが外部署や基幹システムのデータレイクに影響を与えるため、
write を許可すべきではありません。
■ Delta や更新処理は Lakehouse（Tables）に限定する
Schema Enforcement・Time Travel などの特性が保証され、
データ管理の一貫性が確保できるためです。
■ ショートカットの多段構造は避ける
ここで言う「多段構造」とは、たとえばショートカット先の Lakehouse が
さらに別のショートカットを含んでいるようなケースを指します。
こうした構成では、Credential の適用範囲や最終的な更新先が把握しづらくなり、
管理者でも意図しない書き込みを検知できなくなるリスクが高まります。
9. 補足（Python Notebook を使う場合）
Python カーネルでは、Lakehouse が
/lakehouse/default/
としてマウントされます。（default は論理名）
pandas を使う場合は次の形式になります。
/lakehouse/default/Files/...
Spark の Files/... とは書き方が異なります。
10. まとめ
- Spark Notebook では
"Files/..."が基本 - ショートカットは Credential によって実体ストレージにアクセスする
- ユーザー権限とショートカット Credential は 別々に働く
- Notebook 操作には Spark の追加権限 が関係する
- 書き込み操作ではショートカット先が更新される場合がある
- 利用者は抽象化の恩恵を受けられるが、更新系は内部理解が必要
Fabric の抽象化は非常に強力ですが、
Notebook を扱う際には、その裏側の仕組みも押さえておくことで、
安全かつ意図したデータ運用につながります。
Fabric を活用する際の参考としてお役立ていただければ幸いです。
最後に
テンダでは、「こんなプロジェクトに挑戦したい」「こんなチームで働きたい」「理想のチームを創りたい」と願う仲間を求めています。
カジュアル面談も随時受付中です。ぜひ一度お話ししましょう