Azureデータ保存先はADLSかSynapse Dedicated SQL Poolか？Medallionとメタデータ駆動パイプラインで失敗しない設計

仮想化ツール上に大量のビューがあり、Azure移行で「ADLSに残すべきか」「Synapse Dedicated SQL Poolに全部入れるべきか」で迷うケースは多いです。本記事では、ADLS Gen2＋Medallionを正本にしたレイクハウス設計と、メタデータ駆動でパイプライン数を増やさない実践手順を解説します。

結論：データの正本はADLS Gen2、Dedicated SQL Poolは「ホットな一部」に限定する

データ保存先の議論は、突き詰めると「何を正本（Single Source of Truth）にするか」と「どこで高速に提供するか」を分けて考えるのが最短です。おすすめは、ADLS Gen2（データレイク）にBronze/Silver/Goldを集約し、Goldのうち高頻度・高同時接続でSLAが厳しいものだけをSynapse Dedicated SQL Poolに物理化する構成です。

これにより、データの整合性・ガバナンス・拡張性はレイク側で一元化しつつ、必要なところだけDWの強み（同時接続、安定した低レイテンシ、ワークロード分離）を活かせます。「全部Dedicatedに入れる」か「全部ADLSだけで完結」かの二択にしないのがポイントです。

ADLS（レイクハウス）とDedicated SQL Poolの違いを整理する

まずは役割の違いを短く整理します。Dedicated SQL Poolは“分析用の専用コンピュートを常時確保する”設計になりやすく、レイクは“安価なストレージに正本を置き、必要なときだけ計算する”設計に向きます。迷ったら、次の比較表で自社の優先度と照らし合わせてください。

観点	ADLS Gen2（Delta/Parquet）＋Serverless/Spark	Synapse Dedicated SQL Pool
正本（Single Source of Truth）	得意。ファイルを中心に一元管理しやすい	可能だが、用途ごとのコピーが増えるとサイロ化しやすい
コスト構造	ストレージは安価。計算は必要時に起動しやすい	専用コンピュート中心。常時稼働だと読みやすい反面、止めないと膨らむ
スキーマ変更への強さ	Deltaなら変更に追随しやすい（運用ルールは必須）	変更は可能だが、派生テーブルが多いほど影響範囲が拡大
高同時接続・安定した低レイテンシ	ワークロード次第。サーバレスは“毎回同じ高負荷”には不向きになりやすい	得意。BIの同時接続や定型レポートで強い
将来のツール選択（エンジン非依存）	得意。Spark/SQL/BIなど複数エンジンから同じデータを参照できる	エンジンは固定。外部連携はできるが“中”に寄せると移行コストが出る
ガバナンス・リネージ	Purviewなどでレイク中心に統制しやすい	DW内統制は強いが、レイクや他マートが増えると全体最適が難しくなる

「ビューを全部Dedicatedに物理化」しないほうがよい理由

仮想化ツールのビューは、業務の変化に合わせて増えたり形を変えたりしがちです。ビューが何百もある状況で、同じ粒度・同じ優先度でDedicated SQL Poolへ“全部テーブル化”すると、次のような痛みが出やすくなります。

• 増えるのはデータだけではなく“保守対象”：ビュー定義の変更や依存関係の修正が、物理テーブル群とETLに連鎖しやすい
• コストが“常設前提”に寄る：DWUを確保したままの運用になりやすく、使われないデータにもコストがかかる
• サイロ化の起点になる：利用部署ごとにDW内に派生テーブルを作り始めると、同じ意味のデータが複数存在して整合性が崩れる
• ガバナンスが複雑化：レイク・DW・マートの複数箇所で権限設計や監査対応が必要になり、運用コストが増える

Dedicated SQL Poolは強力ですが、“何でも入れる器”ではなく、“性能が必要な提供層”として使うと失敗しにくくなります。

推奨アーキテクチャ：ADLS＋Medallion（Bronze/Silver/Gold）を中心に据える

Medallionアーキテクチャは「生→整形→提供」を段階分離できるため、移行期の混乱を抑えやすいのが利点です。特にビューが多い場合、いきなりGold（業務ビュー相当）を量産する前に、Silverで標準化・再利用可能な形に整えると、後で楽になります。

レイヤ	役割	推奨フォーマット	更新方式	主な利用者
Bronze	取り込みの原本。ソースに近い形で履歴も含めて保存	Delta（または規約を固めたParquet）	フル/増分/CDCいずれも可（まずは取り込みを優先）	データ基盤チーム、監査対応
Silver	クレンジング・標準化・型統一・重複排除・参照結合	Delta	MERGE（アップサート）やSCDで整合性を担保	分析チーム、下流マート作成者
Gold	業務ロジック・集計・データマート。BI/レポート向け	Delta（正本）＋必要に応じてDWへ配信	集計・スナップショット・キューブ化など	BI利用者、業務部門

Goldを「提供インターフェース」と捉え、Goldの正本はレイクに置きつつ、提供手段を複数持つのが現実解です。たとえば、探索的な参照はSynapse serverless SQLやDatabricks SQLで、厳しいSLAのダッシュボードはDedicated SQL Poolで、という切り分けができます。

レイクのディレクトリ設計（例）

ビューが多いほど、置き場所と命名のブレが事故に直結します。最初に“フォルダ階層・命名規約・所有チーム”を決め、後から例外を増やさない運用が重要です。

abfss://lake@<storage-account>.dfs.core.windows.net/
  bronze/
    <source-system>/
      <entity>/ingest_date=YYYY-MM-DD/...
  silver/
    <domain>/
      <entity>/...
  gold/
    <domain>/
      <data-product>/...
  _ops/
    logs/
    checkpoints/
    dq_rules/

Goldの公開方法は「外部参照→必要なら物理化」の順で考える

ADLSに正本を置いた場合、Goldをどう公開するかで使い勝手が決まります。最初からDedicatedにロードするより、外部参照で始めて、SLAが厳しいものだけ物理化すると、コストと運用のバランスが取りやすくなります。

公開手段	向いているケース	メリット	注意点
Synapse serverless SQL（外部テーブル/ビュー）	まずは広く公開したい、利用が読めない	準備が速い。従量課金でスモールスタートしやすい	頻繁に重いクエリが走るとコストが読みにくいことがある
Databricks SQL（SQL Warehouse）	レイク中心でSQL提供したい、Spark処理と近い	Deltaとの親和性が高い。権限・監査も統合しやすい	運用ポリシー（起動/停止、サイズ）を決めないとコストが膨らむ
Synapse Dedicated SQL Pool（物理テーブル/MV）	高同時接続・低レイテンシの定型BI、安定SLAが必須	同時接続に強く、ワークロード分離もしやすい	二重管理になりやすいので“載せるものを絞る”運用が必須

Dedicated SQL Poolを使うべきデータの見極め方

Dedicated SQL Poolを候補にすべきなのは「性能要件が明確で、利用パターンが安定し、投資に見合う」データセットです。ビューが多いほど、温度差（ホット/ウォーム/コールド）が必ず出ます。温度分類を先にやると、不要な物理化を避けられます。

チェック項目	Dedicated SQL Pool向き	レイク＋Serverless/Databricks向き
同時接続数	多い（例：朝の時間帯に多数のBIユーザー）	少ない（アナリスト中心、断続的）
レイテンシSLA	秒未満〜数秒など厳しい	数十秒でも許容、またはバッチで可
クエリの安定性	定型・繰り返しが多い	探索的・変動が大きい
データ量/スキャン量	毎回大量にスキャンしがちで、キャッシュやMVが効く	必要列だけ参照、フィルタでスキャンが絞れる
提供形態	社内標準のDWH接続、RLSなどがDW側で必須	外部テーブルやレイクハウスで十分

特に重要なのは「Dedicatedは“選抜制”」にすることです。GoldのすべてをDedicatedに複製すると、結局は二重管理になります。まずはレイク提供（serverless/Databricks）でSLAを測定し、満たせないものだけDedicatedに昇格させる流れが、コスト最適にもつながります。

Dedicated SQL Poolのコストを膨らませない運用

• 自動ポーズ/再開（または運用ルール）を前提にする：夜間や休日に止められるなら、まず止める運用から始める
• データはGoldからの配信に限定する：Dedicatedを“正本”にしないことで、データの二重更新を避ける
• ワークロード管理を設計する：BIとバッチが取り合って遅くならないように、優先度やリソース配分を決める

パイプラインが増えすぎる問題は「メタデータ駆動＋テンプレート化」で潰す

ビューが何百件ある場合に最も危険なのが、「1ビュー＝1パイプライン」という作り方です。作った瞬間は分かりやすいのですが、運用開始後に改修・例外・権限・スケジュールが積み上がり、保守が破綻しやすくなります。

解決策はシンプルで、処理の“本数”ではなく“定義情報（メタデータ）”を増やす設計に変えます。実装としては、コントロールテーブル（メタデータ管理テーブル）を用意し、ADF/Synapse Pipelinesのテンプレートがそれを読み込んでループ実行します。

コントロールテーブルに入れる項目例

項目	例	使いどころ
dataset_id	sales_order	命名の基準。ログや監視のキー
source_type	sql_view / api / file	取り込み方式の切り替え
source_query_or_object	dbo.vw_sales_order	ソース指定（ビュー名やSQL）
load_mode	full / incremental / cdc	更新方式の分岐
watermark_column	updated_at	増分抽出の基準
primary_key	order_id	Delta MERGEのキー
target_layer	bronze/silver/gold	出力先パス・テーブル名の決定
target_path	abfss://lake@…/gold/sales_order/	書き込み先を統一
partition_columns	order_date	性能・コスト最適化
transform_logic_id	nb_gold_sales_order_v2	Notebook/SQLテンプレートの指定
schedule_group	hourly / daily / weekly	スケジュールを束ねる

テンプレートパイプラインの考え方

実際のパイプラインは「オーケストレーション用」を少数にし、そこでコントロールテーブルを読み込んで対象データセットを列挙します。各データセットの処理は、パラメータ付きのNotebookやデータフロー、あるいはCopy Activityのテンプレートで共通化します。

（例）オーケストレーションの流れ
1) コントロールテーブルから schedule_group=hourly の行を取得
2) ForEachで dataset_id ごとに処理を起動
3) load_mode に応じて Copy / Notebook / SQL を分岐
4) 実行結果（件数・遅延・エラー）を運用ログへ書き込み

この形にすると、「増えるのはパイプラインではなくメタデータ行」になります。ビューが500件に増えても、運用するパイプラインが数本のままなので、監視・改修・権限設計が破綻しにくくなります。

運用ログ（Observability）をテンプレートに組み込む

メタデータ駆動の真価は、実行結果を揃った形で集められる点です。最低でも次の項目はログとして残し、運用ダッシュボード化するとトラブル対応が速くなります。

• dataset_id、実行ID、開始/終了時刻、所要時間
• 読み取り件数/書き込み件数、スキップ件数（増分で0件だった等）
• Watermarkの前回値/更新後値
• エラーコード、失敗ステップ、再実行回数
• 公開側（serverless/Dedicated/Databricks）での遅延・同時接続の指標

ビュー移行を成功させるための“棚卸し”と再設計のコツ

仮想化ツール上のビューは、長年の運用で「似たビュー」「実は使われていないビュー」「同じ計算を別名で持っているビュー」が混在しがちです。Azure移行は、整理する最大のチャンスでもあります。

ビューを3種類に仕分ける

• 再現（Lift）：そのまま必要。既存レポート互換が優先
• 再設計（Refactor）：下流が同じでも、ロジックをSilver/Goldに分割して再利用性を高める
• 廃止（Retire）：参照がほぼない、または要件が既に変わっている

「全部再現」が最も早そうに見えて、後でコストと保守負債になります。特に再設計のポイントは、共通ロジックをSilverへ寄せて“共有部品化”することです。例えば、顧客マスタの名寄せ、タイムゾーンの統一、取引の状態遷移などは、複数ビューで重複しやすい代表例です。

温度分類は“感覚”ではなく数字でやる

ホット/ウォーム/コールドは、できるだけ客観指標で決めます。例としては、Power BIの更新頻度、クエリログの実行回数、ピーク時同時接続、スキャン量、締め処理の依存度などです。温度が決まると、Dedicatedへ載せる候補が一気に絞れます。

増分ロードとCDCを前提にしたレイク設計

ビューが多い移行では、最初はフルロードで間に合わせたくなります。しかし運用に入ると、データ量が増えてフルロードが破綻します。早い段階で、最低限の増分戦略を型として用意しておくと、後戻りを減らせます。

代表的なロードパターン

パターン	適用条件	実装の要点	よくある落とし穴
フルロード	小規模、更新頻度が低い、初回取り込み	スナップショットとして保存し、差分比較できるようにする	“ずっとフル”にしてしまいコストが増大
増分（Watermark）	更新日時・連番など増分キーがある	前回値を管理し、取り込み後にWatermarkを更新	更新日時の欠損・タイムゾーンずれで漏れや二重が起きる
CDC（変更データキャプチャ）	削除・更新も厳密に追いたい	変更ログをBronzeへ、Silverで状態を再構成	下流での“論理削除”扱いが統一されず、指標が揺れる

Delta Lakeを使う場合、Silver/GoldでのアップサートはMERGEで型を作りやすいです。重要なのは、各データセットに「主キー（または自然キーの組み合わせ）」と「遅延到着データをどう扱うか（再計算ウィンドウ）」を決め、コントロールテーブルに持たせることです。

レイクの性能とコストは「ファイル設計」で8割決まる

ADLS＋Delta/Parquetが“遅い”と言われる原因の多くは、エンジンではなくファイル設計（パーティションとファイルサイズ）にあります。特にビューの数が多いと、小さいファイルが大量に生まれやすいので、最初から運用ルールを決めておくのが安全です。

パーティション設計の実務ポイント

• 日付は強いが切りすぎない：order_dateで日次パーティションは定番。ただしデータ量が少ないテーブルで日次にすると小ファイル化しやすい
• 低選択性の列で細分化しない：性別やフラグなどで分けると、ほぼ全パーティションを読むことになる
• “よく絞る列”と“よく結合する列”を分離して考える：パーティションは絞り込み向け、結合最適化はZ-Orderや統計など別手段で補う

ファイルサイズの目安と小ファイル対策

一般的には、1ファイルが極端に小さい（数MB〜数十MB）状態が大量に発生すると、クエリが遅くなりがちです。目安としては100MB〜1GB程度のファイルを狙い、定期的にコンパクション（DeltaのOPTIMIZE相当）で集約する運用が有効です。

「取り込みは細かく、提供はまとまって」という設計にすると安定します。例えばBronzeは取り込み単位のまま保持し、Silver/Goldで定期的に整列・集約して提供する、といった形です。

Dedicated SQL Poolへ載せる場合の設計ポイント

選抜されたホットデータをDedicated SQL Poolへ載せるなら、DW側の設計も“テンプレ化”して属人性を減らすのがコツです。よく効くポイントだけ押さえておくと、性能事故を避けやすくなります。

• 配布（Distribution）を決める：大きい事実テーブルはハッシュ分散、結合に使う小さめ次元はレプリケートなど、結合パターンに合わせる
• 列指向を前提にモデリングする：多くの分析は集計中心なので、列指向（カラムナ）と相性の良いスター型を基本にする
• マテリアライズドビュー/集計テーブルで“高頻度クエリ”を固定化：ダッシュボードの主要指標を先に計算しておく
• 取り込みはGoldからの配信にする：レイクが正本なら、DWは“提供用キャッシュ”として割り切れる

DW側へ載せるデータ量が増えるほど、正本（レイク）との二重管理が増えるため、Dedicatedへ載せるのは「最小限」が鉄則です。

ガバナンスとコンプライアンスは「ADLS中心」に設計する

ビューが多い環境ほど、後から権限・分類・監査を付け足すのが難しくなります。だからこそ、移行初期からガバナンスを“仕組み化”しておくのがおすすめです。

• Microsoft Purview：データカタログ、分類（PII/機微情報）、リネージ（どのソースからどのレイヤへ）を可視化
• ADLSのRBAC＋ACL：コンテナ/フォルダ/テーブル単位のアクセス制御を標準化し、「レイクに集約したポリシー」を下流へ展開
• 実行基盤はマネージドIDを基本：ADF/Synapse/Databricksの実行主体を統一し、秘密情報の配布を減らす
• Databricksを使うならUnity Catalog：テーブル/列レベルの権限、監査ログ、データ共有の統制がしやすい

重要なのは「どこに何があるか分からない」状態を作らないことです。メタデータ駆動パイプラインは、運用ログとPurviewのリネージを組み合わせることで、監査対応の強い基盤になります。

移行をスムーズにする実践ステップ

最後に、ビューが大量にある前提で、失敗しにくい進め方をまとめます。ポイントは“いきなり全量”ではなく、“型を固めて横展開”です。

棚卸しで集めるべき情報

• ビュー名、出力カラム、行数/サイズの概算
• 元ソース（どのテーブル/どのシステムに依存しているか）
• 更新頻度（ほぼリアルタイム/日次/週次）
• 利用者（部門、レポート名、SLA、ピーク時間帯）
• 機微情報の有無（PII、契約情報、社外秘など）

最初のパイロットは「代表的な5〜10ビュー」で十分

まずは代表的なパターンを含む少数のビューで、Bronze→Silver→Goldの流れ、増分、監視、再実行、権限、公開方法（serverless/Databricks/Dedicated）まで一通り通します。ここでテンプレートの粒度とコントロールテーブルの項目を固めると、残りの大量ビューは“登録作業”になります。

メタデータ登録を半自動化してスピードを出す

ビュー一覧（スキーマ・依存関係）をCSVやテーブルに落とし、規約に沿ってtarget_pathやpartition_columnsを自動生成できるようにします。人手をかけるのは、温度分類・主キー設計・機微情報分類など「判断が必要な部分」に集中させます。

SLA測定→Dedicated昇格の順にする

Goldをまずレイクで公開し、実クエリのレイテンシとコスト（スキャン量）を測定します。ここでSLAを満たせないものだけDedicatedへ載せ、MVや集計で最適化します。最初からDedicated前提で設計すると、必要以上にDW側へ寄ってしまいがちです。

よくある失敗パターンと回避策

失敗パターン	起きる問題	回避策
ビューの数だけパイプラインを作る	監視・改修・例外対応が爆発し、運用が回らなくなる	メタデータ駆動＋テンプレート化で“パイプラインは少数”に固定
Goldをいきなり量産する	ロジックの重複が増え、修正が雪だるま式に広がる	共通処理はSilverへ寄せ、Goldは業務単位に絞る
小ファイルが増殖する	クエリが遅くなり、コストも上がる	コンパクション運用、パーティションの再設計、出力粒度の見直し
Dedicatedに“とりあえず全部”載せる	二重管理とコスト増。変更影響が読めなくなる	温度分類→SLA測定→必要なものだけ昇格
権限設計を後回しにする	後から整備しようとしても影響範囲が広すぎる	ADLS中心にRBAC/ACL、Purview分類を早期導入

まとめ：スケールする移行は「正本の統一」と「テンプレート運用」で決まる

• ADLS Gen2（できればDelta）＋Medallionをデータの正本にして、サイロ化を防ぐ
• Synapse Dedicated SQL PoolはホットなGoldの一部に限定し、提供層として使う
• ビューの数に比例して運用が増えないよう、メタデータ駆動＋パラメータ化でパイプラインをスケールさせる

この方針で進めると、移行直後のスピードと、数年後の運用・拡張コストの両方をバランス良く最適化できます。