Azure Synapse Analyticsは、エンタープライズのデータウェアハウジングとビッグデータ分析をひとつにまとめたMicrosoft Azureの分析サービスです。実装で最初に押さえるべきは、これが単一の製品というより、T-SQLで動く「Synapse SQL」、Apache Sparkによるビッグデータ処理、Azure Data Factory由来の「組み込みパイプライン」、そしてそれらを束ねる「Synapse Studio」という複数のエンジンを1枚のワークスペースに載せた統合基盤だという点です。この記事では、定義から専用SQLプールとサーバーレスSQLプールの違い、データレイクのParquetやCSVをT-SQLで直接読む手順、処理量に上限を掛けるコスト管理と専用プールの一時停止、東日本リージョンの単価、次世代のMicrosoft Fabricとの関係、そして「どんなシステムで採用し、どこでは見送るか」の判断基準までを、2026年10月時点の公式ドキュメントに基づいて実装者目線で整理します。
まとめ：Azure Synapse Analyticsの要点と採用判断の分岐
Azure Synapse Analyticsは、SQLによるデータウェアハウジング、Sparkによるビッグデータ処理、ETL/ELTのパイプライン、Power BIやAzure Machine Learningとの連携までを1つのワークスペースに統合したエンタープライズ分析サービスです。中核はSynapse SQLで、予測可能な性能とコストを確保する専用SQLプールと、使った分だけ払うサーバーレスSQLプールの2つのリソースモデルを持ちます。データレイク上のParquetやCSVをSQLとSparkのどちらからでも直接クエリでき、組み込みパイプラインはAzure Data Factoryと同じエンジンなので、ワークスペースを離れずに大規模なETLを組めます。
ただし2026年10月時点で、Microsoftの投資先はMicrosoft Fabricへ移っています。Synapse内のData Explorer（プレビュー）は2025年10月7日に廃止され、公式ドキュメントはFabricへの移行を推奨しています。サービス全体の廃止告知は出ていないため稼働中の資産は使い続けられますが、新規に組むならFabricと並べて比較するのが前提です。
採用が合理的なのは、Azure中心の環境で既存のSynapse資産があるか、DWHとSpark、データ統合を1つの基盤にまとめたい場合です。最初の一歩はサーバーレスSQLプールでデータレイクを直接クエリすることで、事前のプール作成は要りません。自社の分析基盤にどの構成を組むべきか迷う段階なら、設計から相談できる開発会社に早めに当たると手戻りを防げます。
Azure Synapse Analyticsの全体像と構成要素
Synapse Analyticsは、これまで別々のサービスとして扱われてきたDWH・ビッグデータ・データ統合を、1つのワークスペースに集約した点に特徴があります。実装の全体像は、どのエンジンが何を担い、どう組み合わせられるかを押さえると読み解けます。
エンタープライズ分析サービスとしてのAzure Synapseの位置づけ
Synapseは、データウェアハウスやビッグデータのシステム全体から分析情報を引き出すまでの時間を縮めることを狙った分析サービスです。公式の概要ページでは、エンタープライズDWHで使うSQL、ビッグデータ向けのSpark、ログや時系列の分析に向くData Explorer、データ統合とETL/ELTのためのPipelines、そしてPower BIやCosmosDB、Azure Machine Learningといった他のAzureサービスとの連携を組み合わせたものと説明されています。つまり「収集・整形・格納・分析」の各工程を、個別サービスを繋ぎ込むのではなく1つの製品の中で完結させられるのが位置づけの核です。データを整えて分析に使える形へ運ぶという発想の前提は、ETLとELTの違いやツール選定を解説した記事で概念を確認しておくと、この後の構成要素の話がつながりやすくなります。
Synapse SQL：専用SQLプールとサーバーレスSQLプール
Synapse SQLは、T-SQLの分散クエリシステムで、Synapseの中核を担うエンジンです。ここには性格の異なる2つのリソースモデルがあり、実装ではこの選択が料金と性能を大きく左右します。専用SQLプールは、処理能力をあらかじめ確保しておく方式で、SQLテーブルに格納したデータに対して予測可能な性能とコストを得たい定常的なワークロードに向きます。これは従来「SQL Data Warehouse」と呼ばれていたエンタープライズDWHの実体です。データウェアハウス（DWH）の仕組みと選び方を解説した記事で扱うような分析基盤を、Azure上のマネージドなプールとして持つ形になります。もう一方のサーバーレスSQLプールは、常に使えるエンドポイントに対してクエリを投げ、処理したデータ量に応じて課金される方式で、計画外や突発的なワークロード、データレイクの中身をまず探索したい場面に向きます。事前のインフラ確保が不要な点は、小さく始める際の入り口になる持ち味です。
実装上の落とし穴が1つあります。データレイクのファイルを読むOPENROWSET関数は、サーバーレスSQLプール専用です。専用SQLプールでは使えないため、同じT-SQLを両方のプールで流用する前提で設計すると後で書き直しになります。
Apache Sparkプールとデータレイクを共通土台にする操作
SynapseにはApache Sparkが統合されており、データ準備・データエンジニアリング・ETL・機械学習といったビッグデータ処理を、クラスター管理の手間を抱えずに回せます。Sparkプールは迅速な起動と自動スケールを備えた構成です。Sparkバージョンのサポート表では、2026年10月時点で選べるランタイムはApache Spark 3.5系（2025年10月13日GA）で、Java 17・Python 3.11・Delta Lake 3.2を含みます。3.4系は2026年3月31日で支援が終わっており、3.4のまま残したプールは計画的な更新が必要です。そしてSynapseの持ち味は、SQLとSparkがデータレイクを共通の土台にできることにあります。データレイク内のファイルで定義したテーブルを、SparkからもSQLからも同じように扱え、Parquet・CSV・TSV・JSONを直接探索・分析できます。この格納先となるストレージの前提は、データレイクの仕組みを実装視点で解説した記事で押さえておくと、サーバーレスSQLでレイクを直接クエリする設計の勘所がつかめるはずです。SQLとSparkでエンジンを行き来しても同じデータを見られるため、用途ごとにデータを二重に持つ必要が減ります。
Synapse StudioとData Explorerによる統合エクスペリエンス
Synapse Studioは、ソリューションの構築・保守・セキュリティ保護を1つの画面で行うための統合環境です。取り込み・探索・準備・調整・可視化といった主要タスクを実行し、SQLとSparkを横断してリソースや使用状況、ユーザーを監視できます。ロールベースのアクセス制御でリソースへのアクセスを管理し、SQL・Spark・KQLのコードをエンタープライズのCI/CDプロセスと結び付けられる構造です。開発から運用監視までを1つのワークスペースに載せられるのが、Studioを軸にした実装の利点です。
注意したいのはData Explorerです。概要ページにはログや時系列の分析エンジンとして今も載っていますが、アーカイブ側のData Explorerのページには、プレビューのまま2025年10月7日に廃止され、その後はワークロードとデータが削除されると明記されています。移行先はMicrosoft FabricのEventhouseです。ログ分析やIoT分析をSynapse内で組む構成は、もう新規には選べません。
サーバーレスSQLプールでデータレイクのParquetとCSVを直接読む手順
Synapseを触り始めるとき、最初に動かすべきはサーバーレスSQLプールです。ワークスペースを作ると組み込みのエンドポイントがすでに用意されており、プールを作る操作もDWUの見積もりも要りません。ここではOPENROWSETのリファレンスの構文に沿って、Synapse StudioのSQLスクリプトやSSMSからそのまま流せる形で書きます。
OPENROWSETでParquetを読む最小のT-SQLとストレージ認証の前提
Parquetはファイル内に列の型情報を持つため、WITH句を省いても列名と型が推論されます。最小形は次の通りです。ストレージアカウント名とコンテナー名は自分の環境に置き換えてください。
-- サーバーレスSQLプールで実行する（専用SQLプールではOPENROWSETは使えない）
SELECT TOP 10 *
FROM OPENROWSET(
BULK 'https://mystorageaccount.dfs.core.windows.net/raw/sales/year=2026/*.parquet',
FORMAT = 'PARQUET'
) AS [r];
-- 必要な列だけを型付きで読む（Parquetの列名は大文字小文字を区別する）
SELECT [order_date], SUM([amount]) AS total_amount
FROM OPENROWSET(
BULK 'https://mystorageaccount.dfs.core.windows.net/raw/sales/year=2026/*.parquet',
FORMAT = 'PARQUET'
) WITH (
[order_date] DATE,
[amount] DECIMAL(18, 2)
) AS [r]
GROUP BY [order_date];2つ目のクエリが実務の基本形です。Parquetの列名は大文字小文字が区別され、綴りの大小がずれた列はNULLで返ります。エラーにならずに空の列が出る点は、集計値が合わないときに真っ先に疑う箇所です。
認証は、DATA_SOURCEを指定しない書き方だと呼び出し元の種類で決まります。Microsoft Entraでログインしたユーザーは自分のIDでストレージに到達するため、ストレージ側で「ストレージ BLOB データ閲覧者」などのロールが付いていないと読めません。ADLS Gen2の権限をRBACとACLのどちらで切るかは、ADLS Gen2の階層型名前空間とRBAC・ACL設計を解説した記事で整理しています。加えて、データベースユーザーにはADMINISTER BULK OPERATIONS権限が要ります。
CSVをPARSER_VERSION 2.0とHEADER_ROWで読むときの注意点
CSVはパーサーの版で挙動が変わります。既定の1.0は機能が多い一方、ヘッダー行を列名として使うHEADER_ROWは2.0でしか効きません。
SELECT TOP 100 *
FROM OPENROWSET(
BULK 'https://mystorageaccount.dfs.core.windows.net/raw/customers/*.csv',
FORMAT = 'CSV',
PARSER_VERSION = '2.0',
HEADER_ROW = TRUE,
FIELDTERMINATOR = ','
) AS [r];2.0には制約があります。列の最大長は8,000文字、行の最大サイズは8MB、DATE型で受け付ける形式はYYYY-MM-DDだけで、gzip圧縮（DATA_COMPRESSION）は使えません。基幹システムから出力された2026/10/01形式の日付は、文字列で受けてから変換する必要があります。スキーマを推論させると文字列がvarchar(8000)で取られて遅くなるため、本番のクエリではWITH句で型を明示します。
外部データソースとビューでSQLクエリを再利用できる形に固める手順
URLを毎回クエリに直書きすると、ストレージを移したときに全クエリの修正が要ります。サーバーレスSQLプールにユーザーデータベースを作り、外部データソースとビューで包んでおくと、Power BIやアプリ側からは普通のビューとして参照できます。
-- masterではなくユーザーデータベースを作って作業する
CREATE DATABASE lakehouse_db;
GO
USE lakehouse_db;
GO
-- ストレージのルートを1か所に定義する
CREATE EXTERNAL DATA SOURCE raw_lake
WITH (LOCATION = 'https://mystorageaccount.dfs.core.windows.net/raw');
GO
-- 相対パスでビューを作る（利用者はURLを知らなくてよい）
CREATE VIEW dbo.v_sales AS
SELECT *
FROM OPENROWSET(
BULK 'sales/year=*/*.parquet',
DATA_SOURCE = 'raw_lake',
FORMAT = 'PARQUET'
) AS [r];
GO
SELECT COUNT(*) FROM dbo.v_sales;ここで作るデータベースが持つのはメタデータだけで、データ本体はデータレイクに残ります。SAS トークンやマネージドIDで認証したいときは、データベーススコープの資格情報を作って外部データソースに紐づけます。FORMATには'DELTA'も指定できますが、サーバーレスSQLでのDelta Lake読み取りはリファレンス上プレビュー扱いです。テーブル形式の前提はDelta Lakeの仕組みを実装視点で解説した記事で確認できます。
Synapse Analyticsの料金の課金軸とデータ統合・Fabricとの関係
Synapseは複数のエンジンの集合体であるため、料金も「どのエンジンをどれだけ使うか」で決まります。課金軸と、周辺サービスとの守備範囲を押さえると、単独で使うか組み合わせるか、そして次世代へどう備えるかの判断がつきます。
専用SQLプール・サーバーレスSQL・Sparkプールの課金軸と東日本の単価
Synapseの料金は、リソースモデルごとに課金の考え方が分かれます。実測見積もりでは、この分解を知らないと桁がずれます。単価はAzure Retail Prices APIで東日本リージョンの従量課金を2026年10月1日に取得した値です。
| リソース | 主な課金の対象 | 東日本の単価 |
|---|---|---|
| 専用SQLプール | 確保したDWUと稼働時間 | 100DWUで1時間1.81米ドル |
| サーバーレスSQLプール | 処理したデータ量 | 1TBで6.0米ドル |
| Apache Sparkプール | vCore時間 | メモリ重視型1vCoreで1時間約0.155米ドル |
| 組み込みパイプライン | アクティビティ実行・データ移動・データフロー時間 | 実行回数と時間で別建て |
定常的に一定量を分析するなら、専用SQLプールを確保してDWUを固定する方が見積もりが立てやすくなります。逆に、まだクエリ量が読めない探索フェーズや散発的な集計なら、サーバーレスSQLプールで処理データ量に応じた従量に寄せる方が無駄が出ません。サーバーレスSQLのコスト管理のページによると、処理量はクエリごとにMB単位で切り上げられ、最低でも10MBが計上されます。処理量の対象は読み取るデータだけでなく、ノード間で転送する中間結果も含む範囲です。同じ5TBのデータでも、CSVを全列読むクエリと、1TBに圧縮したParquetから1列だけ読むクエリでは、処理量が5TB対0.2TBまで開きます。金額は円換算・為替・リージョンで変わるため、契約前に公式の価格ページで取り直してください。
サーバーレスSQLの処理量に日次と週次の上限を掛けるT-SQL
従量課金の怖さは、全件スキャンするクエリを誰かが繰り返し流したときに表れます。サーバーレスSQLプールには、処理量の予算をTB単位で日・週・月ごとに設定する仕組みがあります。
-- 日次1TB・週次2TB・月次5TBで打ち止めにする
EXEC sp_set_data_processed_limit @type = N'daily', @limit_tb = 1;
EXEC sp_set_data_processed_limit @type = N'weekly', @limit_tb = 2;
EXEC sp_set_data_processed_limit @type = N'monthly', @limit_tb = 5;
-- 設定値を確認する
SELECT * FROM sys.configurations WHERE name LIKE 'Data processed %';
-- 当日・当週・当月にここまで処理した量を確認する
SELECT * FROM sys.dm_external_data_processed;上限を超えても、実行中のクエリは止まりません。超過後に投げた新しいクエリが「SQL Serverless budget limit for a period is exceeded」のエラーで拒否される動作です。月次の上限だけだと月初に使い切ったとき全社のダッシュボードが止まるため、日次を小さく置いて早めに気づける形にしておくのが運用上の安全側です。
専用SQLプールをAzure CLIで夜間に一時停止して課金を止める手順
専用SQLプールは、確保している間ずっと計算料金がかかります。夜間や休日にクエリが来ない業務DWHなら、一時停止で計算料金を止められます。停止中もストレージの料金は引き続き課金の対象です。Azure CLIのaz synapse sql poolリファレンスにあるコマンドで、次のように書けます。
# 状態を確認する
az synapse sql pool show --name sqlpool --workspace-name my-synapse-ws \
--resource-group rg-analytics --query status -o tsv
# 夜間バッチの終了後に一時停止する
az synapse sql pool pause --name sqlpool --workspace-name my-synapse-ws \
--resource-group rg-analytics
# 始業前に再開する
az synapse sql pool resume --name sqlpool --workspace-name my-synapse-ws \
--resource-group rg-analytics
# 月末集計の前だけ性能レベルを上げる
az synapse sql pool update --name sqlpool --workspace-name my-synapse-ws \
--resource-group rg-analytics --performance-level DW200cこのコマンドをAzure AutomationやGitHub Actionsのスケジュール実行に載せると、平日10時間だけ動かす運用が組めます。100DWUを1日24時間回すと東日本の単価で月およそ1,300米ドル、平日10時間に絞れば約400米ドルまで下がる計算です。一時停止中はクエリを受け付けないため、Power BIの定時更新や外部システムからの接続時刻と、再開時刻の順番を必ず合わせてください。
組み込みパイプライン＝Azure Data Factoryと同じエンジン
Synapseには、Azure Data Factoryと同じデータ統合エンジンとエクスペリエンスが組み込まれています。そのため、Synapse Analyticsのワークスペースを離れることなく、多機能で大規模なETLパイプラインを作成できます。90を超えるデータソースからの取り込み、データフローアクティビティによるコードフリーのETL、ノートブックやSparkジョブ・ストアドプロシージャ・SQLスクリプトの調整までを、パイプラインとして組めます（2026年10月時点）。パイプラインの構成要素（アクティビティ・データセット・リンクされたサービス・統合ランタイム）やコピーアクティビティとマッピングデータフローの使い分けは、Azure Data Factoryの仕組みとコンポーネントを実装視点で解説した記事と共通です。単体のADFで組むか、DWHやSparkと同じワークスペースに統合されたSynapseのパイプラインとして組むかは、分析基盤全体をどこに寄せるかで決めます。
次世代版のMicrosoft Fabricへの移行と選定の位置づけ
Synapse Analyticsを検討するうえで外せないのが、Microsoft Fabricとの関係です。Microsoftは、データエンジニアリング・データウェアハウジング・リアルタイム分析といったSynapseのワークロードを1つのSaaSプラットフォームに束ねたMicrosoft Fabricを打ち出しています。Synapse SQLの各リファレンスの冒頭には、データウェアハウスを初めて使うならFabric Data Warehouseから始めるよう案内が入り、Sparkのサポート表でもFabric Runtime 2.0（Apache Spark 4.1・Delta Lake 4.2）への移行が推奨されています。Synapse Analytics全体を廃止する公式アナウンスは確認できず、稼働中のワークロードは継続して使えますが、新規プロジェクトでは単体Synapseで組む前に、Fabricを含めた全体像で設計する判断が現実的です。
専用SQLプールからの移行には、自動化されたFabric Migration Assistant for Data Warehouseが用意されています。ただし移行計画のガイドには型の差が並んでおり、moneyはdecimal(19,4)、nvarcharはvarchar、datetimeはdatetime2に変わります。datetimeoffsetは未対応のため、タイムゾーンのオフセットを別の列へ切り出す作業が必要です。日本語の名寄せや多言語データをnvarchar前提で組んだDWHほど、照合順序とあわせて検証の工数を厚めに見積もるべきです。
Azure Synapse Analyticsを採用すべき場面と見送る場面
ここからは判断です。Synapseは万能の分析基盤ではなく、統合による強みが効く用途と、そうでない用途がはっきり分かれます。要件から逆算し、条件付きで採否を言い切ります。
Azure Synapse Analyticsの採用が合理的になる条件
次のいずれかに該当するなら、Synapseが有力な候補になります。
- すでに専用SQLプールやSynapseパイプラインが稼働しており、移行よりも増設の方が安く済む
- Azure中心の環境で、DWH・Spark・データ統合を別サービスに分散させず1つのワークスペースにまとめたい
- データレイク上のファイルを、SQLとSparkの両方から同じデータとして扱い、二重管理を避けたい
- 定常的な分析は専用SQLプールで性能を固定し、探索的なクエリはサーバーレスで従量に寄せたい
- Fabricの容量課金（F SKU）を契約する前に、レイクの直接クエリだけを従量で試したい
いずれもエンジンをまたぐデータの共有と、Studioによる一元的な運用という統合の強みが効く領域です。特にサーバー管理を抱えずに大規模なSQL/Sparkを回したい場合、リソースモデルを使い分けて小さく始められる点が導入のハードルを下げます。
Azure Synapse Analyticsを選ぶべきでない場面と代替
一方で、次の要件にはSynapseを第一候補にしません。ここを混同すると設計が過剰になります。第一に、これからデータ基盤を新規に立ち上げるなら、単体Synapseを組む前に次世代のMicrosoft Fabricを比較し、後の移行を見越して選ぶべきです。第二に、データの移動と変換だけが目的で分析基盤としてのSQL/Sparkが要らないなら、統合基盤よりもAzure Data Factory単体で足ります。第三に、フルコードのSpark開発や機械学習の作り込みが中心なら、Azure Databricksの料金とAzure連携を解説した記事で扱うようなコード主体の環境に寄せる選択が向きます。第四に、扱うデータ量が小さく単一のリレーショナルDBで完結する規模なら、Synapseのような大規模分析基盤はコストと運用が過剰になり、Azure SQL Databaseなどで十分です。第五に、ログやIoTのストリームを準リアルタイムで分析したいなら、廃止済みのData Explorerの代わりにFabricのEventhouseを検討します。AWSが主環境なら、Amazon Redshift Serverlessの仕組みと料金を解説した記事が比較対象になります。
受託開発におけるデータ分析基盤の設計判断と外注先選定の実務的な勘所
実際のシステムでは、Synapse単体で完結させるのではなく、ストレージ（データレイク）・DWH・BI・場合によってはDatabricksを役割ごとに組み合わせる構成が普通です。定常分析を専用SQLプールに寄せるか、探索をサーバーレスで受けるか、変換をパイプラインのデータフローとSparkのどちらで組むか、そして新規ならFabricを選ぶかは、データ量・稼働パターン・月次コスト・将来の移行のトレードオフで決まり、運用開始後の作り替えには相応の手間が伴います。要件定義の段階でデータの流れ全体と将来像を固めておくほど、後の手戻りを避けられる設計です。外注先を選ぶときは、Synapseの画面操作の経験より、処理量の上限設定やプールの停止スケジュール、Fabricへの型変換まで見積もりに含めてくるかを見てください。Azure上のネットワークや権限設計から任せたい場合はAWS・Google Cloud・Azureのインフラ構築支援、収集・変換・DWH・可視化までを通して相談したい場合はデータ分析基盤の構築・運用の相談で、設計から実装・監視までを一貫して支援できます。
よくある質問
Azure Synapse Analyticsの実装検討でよく挙がる質問を、公式ドキュメントの仕様に沿って整理します。
専用SQLプールとサーバーレスSQLプールはどう使い分けますか？
専用SQLプールは処理能力を事前に確保する方式で、予測可能な性能とコストを得たい定常的なDWHワークロードに向きます。サーバーレスSQLプールは常時使えるエンドポイントに対して処理したデータ量で課金される方式で、計画外や突発的なクエリ、データレイクの探索に向きます。定常分析は専用、探索や散発クエリはサーバーレス、と用途で切り分けるのが基本です。専用プールは使わない時間帯に一時停止して課金を抑える運用も取れます。
Azure Synapse AnalyticsとAzure Data Factoryは何が違いますか？
Azure Data Factoryはデータの移動と変換を担うデータ統合サービスで、Synapseはそのデータ統合エンジンをDWHやSparkと同じワークスペースに統合した分析基盤です。Synapseの組み込みパイプラインはADFと同じエンジンとエクスペリエンスのため、パイプラインの組み方は共通です。データ統合だけが目的ならADF単体、分析まで一貫して同じ基盤で回したいならSynapse、と目的で選びます。
Azure Synapse AnalyticsとMicrosoft Fabricはどちらを選ぶべきですか？
既存のSynapseワークロードは継続して利用できますが、Microsoftは公式ドキュメントで、データウェアハウスを新しく始めるならFabric Data Warehouseからと案内しています（2026年10月時点）。したがって、これから組むなら単体SynapseとFabricを比較し、将来の移行を見越して選ぶのが無難です。稼働中の資産は慌てて作り替える必要はなく、Spark中心かSQLプール中心かで移行のしやすさを見ながら計画するのが現実的です。
データレイクのデータはそのままクエリできますか？
できます。SynapseはSQLとSparkがデータレイクを共通の土台にでき、レイク内のファイルで定義したテーブルをどちらのエンジンからも同じように扱える構造です。Parquet・CSV・TSV・JSONを直接探索・分析でき、事前にDWHへ取り込まなくてもサーバーレスSQLのOPENROWSETでその場でクエリを投げられます。取り込みの前段で中身を確かめたい探索フェーズでも、二重のデータ管理を避けやすい構造です。
料金はどの要素で決まりますか？
使うリソースごとに課金軸が分かれます。専用SQLプールは確保した計算能力の単位（DWU）と稼働時間、サーバーレスSQLプールはクエリで処理したデータ量（TB単位）、Sparkプールは計算時間（vCore時間）、組み込みパイプラインはアクティビティ実行やデータ移動・データフローの計算時間が主な軸です。定常分析はDWUの固定、探索は処理データ量の従量、と稼働パターンに合わせて設計すると見積もりが立てやすくなります（金額は時点・リージョン・規模で変動）。
関連記事
- Azure Data Factoryとは？仕組み・パイプラインとコンポーネント・料金と採用判断を実装者目線で解説：Synapseの組み込みパイプラインと同じエンジンであるADFの構成要素と課金軸を押さえられます。
- Azure Data Lakeとは｜ADLS Gen2の階層型名前空間とRBAC・ACL設計、Synapse/Databricks連携と採用判断を実装者目線で解説：サーバーレスSQLが読むストレージ側の権限設計がわかります。
- データウェアハウス（DWH）とは？仕組み・製品比較・選び方をわかりやすく解説：専用SQLプールが担うエンタープライズDWHの概念と選び方がわかります。
- データレイクとは？データウェアハウス・レイクハウスとの違いを実装視点で解説：SynapseがSQL/Sparkで直接クエリする格納先ストレージの前提を押さえられます。
- ETLとは？仕組み・ELTとの違い・ツール選定から導入判断まで解説：組み込みパイプラインが担うデータ統合の概念を、ツール選定の観点から確認できます。
