公開2026.09.03更新2026.09.27 Azure

Azure Data Lakeとは｜ADLS Gen2の階層型名前空間とRBAC・ACL設計、Synapse/Databricks連携と採用判断を実装者目線で解説

Azure でデータ基盤を組むとき、「Azure Data Lake」という名前のサービスをポータルで探しても見つかりません。独立したサービスではなく、Azure Blob Storage の上に用意された分析向けの機能セットだからです。この構造を知らずに作り始めると、階層型名前空間を有効にし忘れたアカウントへ数十テラバイトを取り込み、後戻りできない状態で気づくことになります。

この記事では、ADLS Gen2 の実体、階層型名前空間を有効にする判断、Azure RBAC と POSIX ACL による権限設計、Synapse や Databricks からの読み書き、費用を抑えるレイアウトの決め方を、設計時に踏む順番で整理します。仕様は Microsoft Learn の記載を2026年9月時点で確認しました。

まとめ｜Azure Data Lakeは階層型名前空間を有効にしたBlob Storageの姿

実体はストレージアカウントの機能セット：専用サービスでもアカウント種別でもなく、階層型名前空間（HNS）を有効にすると解除される Blob Storage の機能群です。
Gen1 は提供終了済み：Gen1 は廃止されリソースへアクセスできず、現在「Azure Data Lake」と呼ばれるものは実質的に Gen2 を指します。
HNS は一方向：有効化した後にフラット名前空間へ戻す手段はなく、取り込み前に決め切る前提になります。
権限は RBAC と ACL の二層：アカウントとコンテナーは Azure RBAC、ディレクトリとファイルは POSIX ACL が受け持ち、ACL エントリは32が上限です。
アクセス経路は ABFS：Synapse も Databricks も、ABFS ドライバー経由で dfs エンドポイントを叩く同じ入口を使います。
分かれ目は分析用途かどうか：ディレクトリを走査する分析処理なら効果が出る一方、バックアップや画像配信では通常の Blob Storage で足ります。

Azure Data Lakeとは｜Blob Storage上の分析向け機能セット

Azure Data Lake Storage は、Azure Blob Storage をベースに構築された、ビッグデータ分析専用の一連の機能です。Gen1 で開発されたファイルシステムセマンティクスやファイルレベルのセキュリティを、Blob Storage の低コストな階層化ストレージと組み合わせたもの、と Microsoft Learn は説明しています。「データレイクという製品を契約する」のではなく「ストレージアカウントに分析向けの性質を足す」という理解が、実装上は正確です。

専用サービスではなくストレージアカウントの機能として提供される

Azure ポータルで作成するリソースは、あくまで Azure Storage アカウントです。作成時に階層型名前空間を有効にすると、ディレクトリ構造、POSIX ACL、ABFS 経由のアクセスといった Data Lake Storage の機能が使えるようになります。既存アカウントを後からアップグレードする経路もありますが、これも別サービスへの移行ではなく同じアカウントの設定変更として扱われました。

この構造には副作用もあります。診断ログやアクセス層といった Blob Storage 側の機能はそのまま使える一方、HNS を有効にしたアカウントでは一部の機能や Azure サービスがまだ対応していない場合があるためです。設計時には機能サポート表と既知の問題を突き合わせ、依存するサービスが対応済みかを確認しておきます。ストレージ側の基礎的な仕組みはAzure Blob Storageとは？仕組み・Blobの種類とアクセス層・S3との違いを実装者目線で解説で整理しています。

Gen1は提供終了しGen2がAzure Data Lakeの実体になった

Gen1 はすでに廃止され、リソースにはアクセスできない状態です。Gen1 と Gen2 は別サービスで、インプレースアップグレードの経路はありませんでした。Gen1 時代のコードには adl: 形式の URI が残っている場合があり、移行では abfss: 形式へ置き換える作業が発生します。

Gen1 前提で書かれた情報は読み替えが要ります。特に権限周りは差が大きく、Gen1 のデータ層が ACL のみだったのに対し、Gen2 のデータ層は ACL と Azure RBAC の両方で承認されました。古い設計書をそのまま流用すると、RBAC 側で意図せず広い権限が付いたまま気づかない事故につながります。

階層型名前空間を有効にする判断｜アトミックなディレクトリ操作と非可逆性

階層型名前空間は、オブジェクトストレージの価格帯を保ったままファイルシステム相当の操作性を得るための機能です。有効にすると、アカウント内のオブジェクトがディレクトリと入れ子のサブディレクトリの階層として整理されます。この一点が分析ワークロードの処理時間に効いてきます。

ディレクトリの名前変更や削除が単一のメタデータ操作で完結する理由

フラットな名前空間のオブジェクトストレージでは、ディレクトリは名前に埋め込まれたスラッシュの規約にすぎません。そのため「ディレクトリの名前変更」は、同じ接頭辞を持つ数百万のオブジェクトを個別に処理する作業になります。階層型名前空間では、親ディレクトリという単一エントリの更新で完結します。

Hive や Spark は、出力をいったん一時的な場所へ書き、ジョブ終了時にその場所を名前変更する動作をとります。階層型名前空間がない環境では、この名前変更が分析処理そのものより時間を要する場合があると Microsoft Learn は指摘しました。多くのワークロードでは計算リソースが総コストの85%超を占めるため、待機時間のわずかな短縮でも総保有コストの差として跳ね返ります。

階層型名前空間は一度有効化するとフラット名前空間には戻せない

アカウントで階層型名前空間を有効にした後、フラット名前空間へ戻すことはできません。これは設計上もっとも取り返しがつかない選択です。判断は、そのアカウントに載せるワークロードの性質から逆算します。ディレクトリを単位に走査・移動する処理があるなら有効化し、オブジェクトを単体で読み書きするだけなら見送る、という切り分けが実務では扱いやすくなります。

迷う場合は、用途ごとにストレージアカウントを分ける方針が現実的です。分析用は HNS 有効、配信やバックアップ用は無効と分けておけば、後から片方の判断だけを変えられます。1つのアカウントへ全用途を詰め込むと、この逃げ道がなくなります。

階層型名前空間の恩恵が出にくいワークロードをあらかじめ切り分ける

Microsoft Learn は、恩恵を受けにくい例としてバックアップ、画像ストレージ、オブジェクトの整理情報が別データベース側に保持されているアプリケーションを挙げています。いずれもディレクトリ単位の操作が発生せず、キーを指定して単体のオブジェクトを取り出す使い方だからです。フラット名前空間と階層型名前空間では保存料金・トランザクション料金・容量予約料金に差があるため、計算リソースの削減幅がその差を超えるかどうかで総コストは決まります。

アクセス制御の設計｜Azure RBACとPOSIX ACLの使い分けと落とし穴

Azure Data Lake Storage のアクセス制御モデルは、Azure RBAC と POSIX に似た ACL の両方をサポートします。この二層構造を粒度で切り分けられるかどうかで、運用開始後の権限管理の手間が大きく変わります。

Azure RBACは粗い粒度、ACLは細かい粒度を受け持つ

項目	Azure RBAC	POSIX ACL
スコープ	アカウント・コンテナー	ディレクトリ・ファイル
上限	4,000（サブスクリプション）	32エントリ（実質28）
継承	上位スコープから継承	既定ACLで新規子項目へ
主な用途	データ読み取り者の付与	ゾーン単位の読み書き分離

実装では、コンテナー全体への広い読み取りを RBAC で与え、内側のゾーンごとの書き込みを ACL で絞る形が扱いやすくなります。ACL 割り当てには Microsoft Entra のセキュリティグループを使い、個々のユーザーを直接書かないのが Microsoft Learn の推奨です。人の入れ替わりのたびに階層全体へ ACL を再適用する作業を避けられます。

実行ビットはコンテナー直下からパス上の全ディレクトリに必要になる

ACL だけで権限を付与する場合、目的のファイルに読み取りを与えるだけでは足りません。コンテナーのルートフォルダーと、そのファイルに至る階層のすべてのフォルダーに実行（x）権限が要ります。ディレクトリにおける実行権限は「子項目をスキャンする」ための許可であり、ファイルに対しては意味を持ちません。

実務でよく起きるのは、深い階層のディレクトリにだけ r-x を付けて「読めるはず」と考え、403 で止まるパターンです。中間ディレクトリの –x が抜けています。ディレクトリの一覧表示には読み取りと実行、子項目の作成には書き込みと実行が要る、という対応も押さえると切り分けが速くなります。

既定ACLを設定する前に作られた子項目へは権限が反映されない

ACL には、オブジェクトへのアクセスを制御するアクセス ACL と、子項目のテンプレートになる既定 ACL の2種類があります。既定 ACL はディレクトリにのみ存在し、ファイルにはありません。そして継承は「設定後に作られた子項目」にだけ効きます。

つまり、データを取り込んだ後に既定 ACL を設定しても、すでに存在するファイルの権限は変わりません。既存の子項目へ反映するには、目的の階層に対して ACL を再帰的に更新する操作が別途要ります。ゾーンのディレクトリを作った直後、取り込みを始める前に既定 ACL を当てる順番を運用手順へ組み込むと、後追いの再帰処理を避けられます。

ACLは32エントリ上限のためセキュリティグループで割り当てる

ACL エントリの上限は、ファイルごと・ディレクトリごとに32（実質28）です。アクセス ACL と既定 ACL はそれぞれ独立して32の上限を持ちます。ユーザー単位で書いていくと、部署が増えるだけで上限に達します。

加えて Microsoft Entra ID 側には、セキュリティプリンシパルのグループメンバーシップを200未満に抑える推奨があります。グループ要求を含む JWT の制約によるもので、超えると想定外の挙動が出る可能性があると案内されました。書き込み用と参照用のように役割でグループを切り、サービスプリンシパルやマネージド ID もそこへ入れる設計なら、二つの上限から距離を取れます。

SynapseとDatabricksからの利用設計｜abfssと認証・ゾーン構成

Azure Data Lake Storage は、HDFS をデータアクセス層として使うフレームワーク全般と連携する前提で設計されています。Spark も Presto も、HDFS の代わりに ABFS 経由で同じデータを読みます。ここを共通の入口にすると、エンジンを増やしても構成が散らかりません。

ABFSドライバー経由でSparkから直接読み書きする構成にする

Hadoop ディストリビューションに含まれる Azure Blob File System（ABFS）ドライバーが、Blob Storage 上のデータへの直接アクセスを担います。対応する REST API のエンドポイントは dfs.core.windows.net です。Spark からは、コンテナー名とアカウント名を含む abfss スキームのパスを指定します。

df = spark.read.format("delta").load(
  "abfss://[email protected]/sales/orders"
)

Databricks 側でマウントを使う構成も残っていますが、パスを直接指定する書き方のほうが権限を追跡しやすくなります。マウントはワークスペース単位の設定として残り続け、誰がどの資格情報でどこを見ているのか読み取りにくいためです。エンジン側の詳細はAzure Databricksとは？料金・Azure連携・Databricks本体との違いと導入判断【2026年7月時点】とAzure Synapse Analyticsとは？SQL・Spark・パイプラインの仕組みと料金・Fabric移行と採用判断を実装者目線で解説で扱っています。

認証はマネージドIDかサービスプリンシパルへ寄せて鍵を持たない

ストレージアカウントのアクセスキーを Spark の設定へ直接書く方法は動きますが、ACL による承認が効かなくなります。共有キー承認を使う要求には呼び出し元に紐づく ID が存在せず、ACL が適用されないためです。SAS トークンも、ユーザー委任 SAS の場合を除いて同じ扱いになります。

したがって、ディレクトリ単位の権限分離を機能させたいなら、マネージド ID かサービスプリンシパルでの認証に寄せます。ACL にサービスプリンシパルを書く場合、アプリ登録側のオブジェクト ID ではなく、テナント内のサービスプリンシパルのオブジェクト ID を使う点も間違えやすい箇所です。両者は別の GUID になります。

rawとcuratedのゾーン設計とACLの当て方を先に決める

取り込み直後の生データ、整形済みデータ、集計済みデータをコンテナーやトップレベルのディレクトリで分ける構成が一般的です。この境界に権限の境界を重ねれば、ACL の当て先はディレクトリ数本で済みます。日付やテーブル単位で権限を切ると、エントリ数と再帰処理の量が一気に増えました。

取り込みパイプラインを組む際は、書き込み側のサービスをそのゾーンの書き込みグループへ、参照側は読み取りグループへ入れます。Azure Data Factoryとは？仕組み・パイプラインとコンポーネント・料金と採用判断を実装者目線で解説で扱ったパイプライン側の設計と合わせて決めると、権限とデータの流れが一致します。

ストレージコストとファイル配置｜アクセス層とライフサイクル管理

Azure Data Lake Storage の価格は Azure Blob Storage のレベルで設定されます。ライフサイクル管理ポリシーやオブジェクトレベルの階層化といった Blob Storage の機能がそのまま使えるため、費用の抑え方も Blob Storage の作法に従います。

アクセス層とライフサイクル管理でストレージ費用の増加を抑える

生データのゾーンは、取り込みから一定期間を過ぎたら下位のアクセス層へ移す運用が向いています。ライフサイクル管理ポリシーで日数条件を書けば、個別のジョブを組まずに階層を落とせます。ここで効くのが前述のゾーン設計で、生データと集計済みデータが同じディレクトリに混在していると、ポリシーの条件を書き分けられません。

小さなファイルを大量に作らないレイアウトも、費用と速度の両方に効きます。トランザクション課金は要求数に比例し、Spark 側の読み取りもファイル数が増えるほど遅くなるためです。取り込み時に日付でパーティションを切り、1ファイルあたりの大きさをまとめる方針を先に決めておきます。DWH との費用構造の違いはデータウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説と合わせて見ると整理しやすくなります。

Fabric OneLakeとの関係｜ショートカットで参照する構成の考え方

Microsoft Fabric の OneLake は、ドメインやクラウドをまたいでデータを統合する仮想的なデータレイクとして位置づけられています。押さえておきたいのは、既存の ADLS Gen2 を OneLake へ移す必要が必ずしもない点です。ショートカットを使えば、データをコピーせずに既存の場所を参照できます。

ショートカットは OneLake 内のフォルダーとして見え、シンボリックリンクのように振る舞います。削除してもターゲットのデータは影響を受けません。ADLS と S3 のショートカットはクラウド接続を通じて承認を委任する仕組みで、接続への権限を持つユーザーだけが作成できます。移行判断は既存の分析エンジンをどうするかに引きずられるため、Synapse や Databricks を使い続けるなら ADLS Gen2 を主とし、Fabric 側からショートカットで参照する構成が素直でしょう。テーブル形式まで含めた設計はデータレイクハウスとは？データレイク・DWHとの違いとアーキテクチャを実装視点で解説で扱った論点と重なります。

導入判断｜Azure Data Lakeを採用する条件と見送るべき場面の切り分け

Azure Data Lakeを採用してよい条件を3つに絞る

採用してよいのは、次の3つが同時に成り立つときだと考えています。第一に、分析エンジン（Spark、Synapse、Databricks など）がストレージを直接読む構成であること。第二に、ディレクトリ単位でデータを移動・整理する処理が定常的に走ること。第三に、部門や役割で見える範囲を分ける要件があること。この3つが揃うなら、アトミックなディレクトリ操作と POSIX ACL の細かい粒度が、そのまま設計の道具になります。

逆に、1つ目だけが成り立つ状態、つまり「分析基盤を作るから」という理由では判断材料として足りません。ディレクトリ操作が発生せず権限も全員一律でよいなら、HNS を有効にしない Blob Storage で要件は満たせます。概念そのものの整理はデータレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説に譲り、ここでは Azure 上の実装判断に絞りました。

見送るべき場面と代わりに選ぶストレージ構成の考え方を整理する

見送る判断が正しい場面もはっきりしています。バックアップの保管先、画像や動画の配信元、アプリケーションが ID を指定して単体のオブジェクトを取り出すだけの用途では、HNS の恩恵がありません。フラット名前空間のまま使い、費用面で有利な構成を選びます。NFS 3.0 を扱う要件にも注意が要り、ACL で NFS 3.0 要求を承認することはできません。

また、構造化データを対話的に集計する用途が主で、ファイルを直接読む処理がほとんどないなら、DWH 側を主にする構成のほうが運用は軽くなります。両者を組み合わせる手順はデータレイクハウス実装の手順6ステップ｜アーキテクチャ選定と移行判断を実務視点で解説で整理しました。ゾーン設計や権限の当て方まで自社要件へ落とし込む段階では、データ分析基盤構築・MLOps構築支援のように設計から運用までを通して見る支援も選択肢に入ります。

よくある質問

Azure Data Lake Storage Gen1はまだ使えますか？

Gen1 は廃止され、リソースへのアクセスはできません。Gen1 と Gen2 は別サービスで、インプレースでのアップグレード経路も用意されていませんでした。コードやノートブックに adl: 形式の URI が残っている場合は、abfss: 形式へ置き換えます。

階層型名前空間を後から無効にすることはできますか？

できません。フラット名前空間へ戻す手段は提供されておらず、アカウント作成時点で決め切る前提です。迷う場合は用途ごとにアカウントを分け、分析用だけを HNS 有効にする構成を検討してください。

ACLとAzure RBACはどちらを先に評価しますか？

Azure RBAC のロール割り当てが先に評価され、そこで許可されなかった場合に ACL が確認されます。ACL 内の評価順は、スーパーユーザー、所有ユーザー、名前付きユーザー、所有グループと名前付きグループ、その他のすべてのユーザーの順です。複数に該当する場合、最初に一致した ID の権限が適用されました。

ACLエントリの上限に達した場合はどうすればよいですか？

上限はファイルごと・ディレクトリごとに32（実質28）で、アクセス ACL と既定 ACL がそれぞれこの上限を持ちます。個別のユーザーやサービスプリンシパルを直接書かず、Microsoft Entra のセキュリティグループを割り当てる方式へ切り替えるのが基本的な回避策です。権限の変更はグループのメンバー追加・削除で行います。