Azure Analysis ServicesからAzure Data FactoryへDAX結果を取り込む方法｜直結不可の理由と回避策

AAS（Azure Analysis Services）のTabularモデルにDAX（EVALUATE/SUMMARIZECOLUMNS）を投げ、結果をAzure Data Factoryでそのまま取り込みたい。ところがADF/SynapseにはAAS用のリンクサービスが見当たりません。本記事では「なぜ直結できないのか」と「実務で使える回避策」を、具体的なクエリ例と設計ポイント付きで解説します。

やりたいことを具体化すると「DAXの結果セットをETLの入力にしたい」

今回の要望は、AASが持つセマンティック層（集計・計算ロジック・RLSなど）を活かしたまま、DAXで作った集計テーブルをデータパイプラインに流し込みたい、というものです。具体的には次のようなイメージになります。

項目	内容（例）	狙い
接続先	asazure://<region>.asazure.windows.net/<server>	AAS上のモデル（Tabular）へ接続
実行したいクエリ	EVALUATE SUMMARIZECOLUMNS(…)	DAXで集計・計算した結果セットを取得
取り込み先	ADFのCopy activityでADLS/SQL/Synapse等へ出力	後続のDWH/レイク処理・他システム連携に使う

ところが、AASは「データソース」ではなく「分析エンジン＋セマンティックモデル」なので、通常のRDBやストレージのように“テーブルをそのままコピーする”発想がそのまま当てはまりません。ここがハマりどころです。

結論：ADF / Synapse には AAS を直接ソースにする標準コネクタがない

先に結論をはっきりさせると、Azure Data Factory（およびSynapse Pipelines）には、Azure Analysis Servicesを「リンクされたサービス／Copyのソース」としてそのまま選べる標準コネクタが用意されていません。Microsoft Q&Aでも「Synapse/ADF内にAASの直接コネクタはない」と明言されています。

また、ADF/Synapseがサポートするコネクタ一覧（Copy activityの対応データストア）を見ても、Azure Analysis Servicesは並んでいません。つまり「AAS→ADF直結コピー」をコネクタ設定だけで実現するのは難しい、という整理になります。

「REST APIでAASを叩いてDAX結果を取る」は公式ルートでは解決しない

次に多い発想が「HTTPで叩けるなら、ADFのREST/HTTPコネクタでいけるのでは？」というものですが、ここにも壁があります。Microsoft Q&Aの回答では、分析サービスに“データ取得のためのREST API”はない（少なくともクエリ結果を返す用途ではない）という趣旨が書かれています。

誤解されやすい点として、Azure Analysis ServicesにはAzureリソースとしての管理用REST API（Azure Resource Manager経由）が存在します。ただし、これはサーバーの作成・更新・停止/再開など「管理操作」のためのAPIであり、DAXを実行して結果セットを返す“クエリAPI”とは別物です。

呼び方	目的	DAX結果の取得	ADFから扱いやすいか
管理REST（ARM）	サーバー/設定の管理、状態変更	不可	可能だが“データは取れない”
XMLA（Analysis Servicesのプロトコル）	モデル管理・クエリ実行（DAX/MDX）	可能（ただしXMLA形式）	そのままだと扱いにくい
Power BI REST API（Execute Queries）	Power BIのデータセットにDAXを実行	可能（JSON）	比較的扱いやすい（条件あり）

結局、ADFで扱いやすい形（テーブル/JSON/ファイル）にするには、どこかで「AASにクエリ→結果を整形」という変換層を置く必要が出てきます。ここからが現実的な回避策です。

回避策は大きく4パターン：要件別の選び方

「AASのDAX結果を取り出したい」と言っても、組織の制約（MFA必須、運用負荷をかけられない、Fabricは使える/使えない、既存ADF資産を活かしたい等）によって現実解が変わります。よく出てくる4パターンを比較すると次の通りです。

回避策	概要	強い条件	弱い条件	おすすめの使いどころ
リンクサーバー方式	SQL Server/SQL MIにAASへのリンクサーバーを作り、ADFはSQLをソースにする	ADF資産を活かせる／SQLで行指向の結果として扱える	運用コスト（サーバー管理）／認証設計が難しくなりがち	既存がADF中心で、最短で“動くもの”が必要
Microsoft Fabric（Dataflow Gen2）	FabricのPower QueryコネクタでAASに接続し、DAX/MDXを指定して取り込む	モダン認証に寄せやすい／変換も同じ画面で完結	Fabricの利用前提（環境・ライセンス・運用方針）	MFAや組織ポリシーでリンクサーバーが厳しい
中継API（Azure Functions等）	自作/サンプルを使い、HTTPでDAXを受けてAASに実行→JSONで返す	ADFのHTTP/RESTで取り込みやすい／自由度が高い	開発・保守が必要／大容量結果には工夫が要る	“どうしてもHTTPで完結したい”／小〜中規模の結果セット
Power BI REST API（Execute Queries）	対象をPower BIセマンティックモデルに寄せ、RESTでDAX実行	公式RESTでJSONが返る／セキュアに設計しやすい	AASやAASライブ接続のデータセットは対象外など制約あり	中長期でAASから移行/統合を進めたい

以降では、それぞれの「具体的にどう作るか」「どこで詰まりやすいか」を掘り下げます。

回避策：リンクサーバー方式（SQL Server / SQL MI 経由）

Microsoft Q&Aのスレッドや実務でも一番よく採用されるのが、SQL Server（オンプレ、IaaS、SQL Managed Instanceなど）にAASへのリンクサーバーを作り、ADFはそのSQL Serverをデータソースとして扱う構成です。

全体像：ADFは「SQLに対してSELECTするだけ」に寄せる

考え方はシンプルで、ADFが得意な“SQLから行セットをコピー”に寄せるために、SQL Server側でAASを「OPENQUERYできる先」として見せます。

レイヤー	役割	ポイント
SQL Server / SQL MI	AASへのリンクサーバー・DAX実行の入口	MSOLAPプロバイダ経由でDAXを実行し、行セット化
ADF（Copy activity）	SQLをソースにデータを取り込む	通常のSQLコネクタ運用にできる
出力先	ADLS / Azure SQL / Synapse等	後続の処理基盤に合わせて選択

リンクサーバー作成の実装例（T-SQL）

DataSharkXの記事では、MSOLAPプロバイダを使ってリンクサーバーを作る例が示されています。概念はそのままに、実務で再利用しやすい形にすると次のようになります。

-- 例：SQL Server上にAASへのリンクサーバーを作る（概念例）
EXEC master.dbo.sp_addlinkedserver
  @server     = N'AAS_LINK',
  @srvproduct = N'',
  @provider   = N'MSOLAP',
  @datasrc    = N'asazure://&lt;region&gt;.asazure.windows.net/&lt;server&gt;',
  @catalog    = N'&lt;model_database_name&gt;';

-- 認証は環境により変わる（SQLログイン/AD/サービスプリンシパル等）
EXEC master.dbo.sp_addlinkedsrvlogin
  @rmtsrvname = N'AAS_LINK',
  @useself    = N'False',
  @locallogin = NULL,
  @rmtuser    = N'&lt;user_or_spn&gt;',
  @rmtpassword= N'&lt;secret&gt;';

EXEC master.dbo.sp_serveroption @server=N'AAS_LINK', @optname=N'data access', @optvalue=N'true';
EXEC master.dbo.sp_serveroption @server=N'AAS_LINK', @optname=N'rpc out',     @optvalue=N'true';

注意点として、認証方式（特にAzure AD/MFA/サービスプリンシパル）や、SQL Serverが置かれる場所（オンプレの場合はSelf-hosted IRが必要など）で設計が大きく変わります。まずは「SQLからOPENQUERYでDAXが返る」状態を作るのが第一歩です。

OPENQUERYでDAX（EVALUATE）を実行する例

リンクサーバーができたら、SQL側はOPENQUERYでDAXを投げます。DataSharkXの記事でも同様のサンプルが紹介されています。

SELECT *
FROM OPENQUERY(
  AAS_LINK,
  'EVALUATE
   SUMMARIZECOLUMNS(
     ''Geography''[City],
     "SalesAmount", [Sales Amount]
   )'
);

実務でよくある落とし穴が「引用符の地獄」です。SQL文字列はシングルクォート、DAXのテーブル名もシングルクォートを使うため、ネストするときは ”（シングルクォート2個） でエスケープします。パラメータ化したい場合は、SQL側で文字列を組み立てる（またはストアドに逃がす）と事故が減ります。

ADF側：Copy activityのソースをSQL Serverにしてクエリを流す

ADFはAASではなくSQL Serverをソースにします。SourceのQueryにOPENQUERYを含むSELECTを書くか、ストアドプロシージャ化して「ストアドの実行」に寄せると運用が安定します。DataSharkXの記事でも、ADFのLinked ServiceはSQL Server（リンクサーバーを作った先）に張る流れになっています。

リンクサーバー方式のメリット・デメリット

観点	メリット	デメリット / 注意
導入スピード	ADFは既存のSQLコネクタで済む	SQL Server側の構築・設定がボトルネックになりやすい
認証	SQL側に集約できる	MFA必須のアカウント運用だと自動化が難しいケースがある
性能	AAS側で集計し、結果だけを返せる	結果セットが大きいとネットワーク/メモリが詰まりやすい
運用	ADF運用は従来通り	SQL Serverのパッチ/監視/DRを追加で抱える

運用設計のコツ：AASを“巨大CSV出力機”にしない

リンクサーバー方式は便利ですが、AASの強みは「集計・計算・セキュリティ」をモデル側に閉じ込められることです。逆に言うと、明細を何千万行も抜く用途には向きません。DAX側で返す行数を絞る（期間条件・粒度・TOPNなど）、「必要な結果だけを小さく取り出す」設計にするのが成功の近道です。

回避策：Microsoft Fabric の Dataflow Gen2 でAASを取り込む

リンクサーバーが組織ポリシー上難しい（特にMFA必須で“自動実行のための資格情報”を置きにくい）場合、スレッドでも挙がっている通り、Microsoft FabricのData Factory（Dataflow Gen2）側でAzure Analysis Servicesコネクタを使う案が現実的です。

Fabric側のAASコネクタは、Dataflow Gen2のソースとして利用でき、認証方式として組織アカウントやワークスペースIDなどが示されています。

ポイント：Power Queryの「MDX/DAXクエリ」をAdvanced optionsで指定できる

Dataflow Gen2の内部はPower Queryなので、Azure Analysis ServicesコネクタのAdvanced optionsとして「MDXまたはDAXステートメントを指定して実行できる」ことが大きいです。つまり、やりたかった EVALUATE SUMMARIZECOLUMNS(...) をそのまま入力して、結果をPower Queryで整形し、レイクやSQLに流せます。

実装イメージ：MコードでAASにDAXを渡す

DataSharkXのFabric例では、Power Queryの関数 AnalysisServices.Database に [Query=...] を渡してDAXを実行する形が示されています。概念例は次の通りです。

let
  Source =
    AnalysisServices.Database(
      "asazure://&lt;region&gt;.asazure.windows.net/&lt;server&gt;",
      "&lt;database&gt;",
      [Query = "EVALUATE SUMMARIZECOLUMNS('Dates'[Fiscal Year], \"Sold USD\", [Sold USD])"]
    ),
  AddedAuditDate = Table.AddColumn(Source, "AuditDate", each DateTime.LocalNow(), type datetime)
in
  AddedAuditDate

この方式の良いところは、(1) 接続、(2) DAX実行、(3) 変換、(4) 出力を同じ流れで完結できる点です。結果として「ADFでやりたいのはデータ移動だけ」という理想に近い運用になります。

Fabric方式のメリット・デメリット

観点	メリット	デメリット / 注意
認証・セキュリティ	組織アカウントなどに寄せやすい	テナント設定や運用ポリシーに依存
変換	Power Queryで前処理まで一気通貫	複雑な変換は管理がブラックボックス化しがち
運用	SQL Server運用が不要になりやすい	Fabricの監視/課金/運用設計が別途必要

回避策：Azure Functions等で“DAX実行→JSON返却”の中継APIを作る

「どうしてもADF側はHTTPで取り込みたい」「SQL Serverを増やせない」「Dataflowではなく自前APIで制御したい」という場合は、AASに対するDAX/MDX実行をHTTP化する中継APIを用意する方法があります。Microsoftが公開しているサンプルとして、AAS/Power BI PremiumのXMLAエンドポイントに対するHTTPプロキシ（/api/Query）が提供されています。

サンプルがやっていること：XMLAを“HTTPで包んでJSONにする”

このサンプルは、内部的にはXMLAエンドポイントに接続し、クライアントから受け取ったDAX/MDXを実行して結果をJSONで返す構成です。READMEには「/api/QueryがDAXをPOSTしてJSON結果を返す」こと、また「サービスプリンシパルを推奨する」ことが明記されています。

APIのURL例（サンプル準拠）

POST https://&lt;your-api-host&gt;/api/Query
POST https://&lt;your-api-host&gt;/api/&lt;database&gt;/Query
GET  https://&lt;your-api-host&gt;/api/Tables

認証は、基本認証（HTTPS）でサービスプリンシパルを渡す方式や、Bearerトークンを取って渡す方式が説明されています（Power BIの場合とAASの場合でResource IDが異なる点も含む）。

ADFでの取り込みパターン

Web activityでAPIを叩き、結果JSONをADLSに保存する
Copy activity（REST/HTTP）でそのままJSONをファイルに落とす
結果が大きい場合は「APIはストレージに出力して完了通知」→ADFはファイルを拾う（同期レスポンスで大容量を返さない）

中継API方式は自由度が高い反面、運用責任が自分たちに戻ってきます。特に、(1) タイムアウト、(2) 結果セットのサイズ、(3) 認証情報の保護、(4) 監査ログ、(5) エラーハンドリングを最初から設計に入れるのが重要です。

代替案：Power BI REST API（Execute Queries）でDAXを実行してJSONで取得する

もし「AASを叩きたい」ではなく「セマンティックモデルにDAXを投げて結果を取りたい」のであれば、Power BIのデータセット（セマンティックモデル）に寄せて、公式REST APIでDAXを実行する選択肢が出てきます。Power BI REST APIには executeQueries があり、DAXを実行してJSONで結果を返します。

URL例（公式）

POST https://api.powerbi.com/v1.0/myorg/datasets/{datasetId}/executeQueries

リクエスト例（EVALUATE）

{
  "queries": [
    { "query": "EVALUATE SUMMARIZECOLUMNS('Dates'[Fiscal Year], \"Sold USD\", [Sold USD])" }
  ],
  "serializerSettings": { "includeNulls": true }
}

制約は要チェック：AAS“そのもの”ではなくPower BIのデータセット向け

重要なのは、このAPIはPower BIのデータセットに対しての機能であり、ドキュメント上「AASでホストされているデータセット」や「AASへのライブ接続のデータセット」は対象外とされています。さらに、1回の呼び出しは1クエリ・1テーブル、行数/値数/サイズにも上限があります。

項目	概要
クエリ	1リクエスト=1クエリ、1クエリ=1テーブル
結果上限	最大100,000行または 1,000,000値（先に到達した方）、最大15MB
レート	ユーザーあたり毎分120リクエスト上限
前提	テナント設定（Dataset Execute Queries REST API）が有効、権限/スコープが必要

ADFからは、Web activityやRESTコネクタでこのAPIを呼び、返ってきたJSONをファイル/テーブルへロードする流れが組めます。中長期的にAASからPower BI Premium/Fabricへ寄せる計画があるなら、ETLもこの方向に寄せていくと“二度手間”になりにくいです。

補足：そもそもAASから“取り出す”べきかを再確認する

ここまで「どうやって取り出すか」を中心に書きましたが、実務では「何を取り出したいか」を先に詰めるほど、実装がシンプルになります。

明細データが欲しい：AASではなく、元データ（DWH/レイク/DB）から取り出す方が安全。AASは集計・計算に寄せる。
計算ロジック込みの集計結果が欲しい：DAXで作った結果セットを小さく取り出す（リンクサーバー/Fabric/API）。
他システム連携のための“配布用データ”が欲しい：AASのロジックを再利用するか、配布用のマートを別に作るかを検討（運用・監査の観点で重要）。

特に、AASを“配布用データマート”として使い始めると、モデル変更が下流に波及しやすくなります。クエリ仕様（返す列・型・粒度）を固定し、契約（インターフェース）として管理する意識があると、運用が破綻しにくいです。

よくある質問

ADFの「Generic ODBC」でAASに繋げられない？

AASのクライアント接続はMSOLAP/ADOMDなどの世界で、一般的なODBC経由でDAXを投げる設計とは相性がよくありません。結果として、SQL ServerにMSOLAPを入れてリンクサーバーにする、Power Queryコネクタを使う、HTTPプロキシで包む、といった回避策に収束しがちです。

「AASのREST API」があると聞いたが？

Azure Analysis Servicesには、サーバー更新（PATCH）などの管理REST APIが公開されています。ただし、これは管理操作向けであり、DAX実行結果を返す用途ではありません。

AASは今後どうなる？移行は必須？

Microsoftのガイダンスでは、現時点でAASを廃止する計画はない一方で、エンタープライズ向けモデリングへの投資はPower BI Premium側に重点を置く方針が示されています。また、AASからPower BI Premiumへモデルを移行するための機能（移行・リダイレクト等）も提供されています。将来の拡張性を考えるなら、短期の回避策と並行して「Power BI/Fabric側へ寄せるロードマップ」を持っておくと安心です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Analysis ServicesからAzure Data FactoryへDAX結果を取り込む方法｜直結不可の理由と回避策

やりたいことを具体化すると「DAXの結果セットをETLの入力にしたい」

結論：ADF / Synapse には AAS を直接ソースにする標準コネクタがない

「REST APIでAASを叩いてDAX結果を取る」は公式ルートでは解決しない

回避策は大きく4パターン：要件別の選び方

回避策：リンクサーバー方式（SQL Server / SQL MI 経由）

全体像：ADFは「SQLに対してSELECTするだけ」に寄せる

リンクサーバー作成の実装例（T-SQL）

OPENQUERYでDAX（EVALUATE）を実行する例

ADF側：Copy activityのソースをSQL Serverにしてクエリを流す

リンクサーバー方式のメリット・デメリット

運用設計のコツ：AASを“巨大CSV出力機”にしない

回避策：Microsoft Fabric の Dataflow Gen2 でAASを取り込む

ポイント：Power Queryの「MDX/DAXクエリ」をAdvanced optionsで指定できる

実装イメージ：MコードでAASにDAXを渡す

Fabric方式のメリット・デメリット

回避策：Azure Functions等で“DAX実行→JSON返却”の中継APIを作る

サンプルがやっていること：XMLAを“HTTPで包んでJSONにする”

APIのURL例（サンプル準拠）

ADFでの取り込みパターン

代替案：Power BI REST API（Execute Queries）でDAXを実行してJSONで取得する

URL例（公式）

リクエスト例（EVALUATE）

制約は要チェック：AAS“そのもの”ではなくPower BIのデータセット向け

補足：そもそもAASから“取り出す”べきかを再確認する

よくある質問

ADFの「Generic ODBC」でAASに繋げられない？

「AASのREST API」があると聞いたが？

AASは今後どうなる？移行は必須？

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Analysis ServicesからAzure Data FactoryへDAX結果を取り込む方法｜直結不可の理由と回避策

やりたいことを具体化すると「DAXの結果セットをETLの入力にしたい」

結論：ADF / Synapse には AAS を直接ソースにする標準コネクタがない

「REST APIでAASを叩いてDAX結果を取る」は公式ルートでは解決しない

回避策は大きく4パターン：要件別の選び方

回避策：リンクサーバー方式（SQL Server / SQL MI 経由）

全体像：ADFは「SQLに対してSELECTするだけ」に寄せる

リンクサーバー作成の実装例（T-SQL）

OPENQUERYでDAX（EVALUATE）を実行する例

ADF側：Copy activityのソースをSQL Serverにしてクエリを流す

リンクサーバー方式のメリット・デメリット

運用設計のコツ：AASを“巨大CSV出力機”にしない

回避策：Microsoft Fabric の Dataflow Gen2 でAASを取り込む

ポイント：Power Queryの「MDX/DAXクエリ」をAdvanced optionsで指定できる

実装イメージ：MコードでAASにDAXを渡す

Fabric方式のメリット・デメリット

回避策：Azure Functions等で“DAX実行→JSON返却”の中継APIを作る

サンプルがやっていること：XMLAを“HTTPで包んでJSONにする”

APIのURL例（サンプル準拠）

ADFでの取り込みパターン

代替案：Power BI REST API（Execute Queries）でDAXを実行してJSONで取得する

URL例（公式）

リクエスト例（EVALUATE）

制約は要チェック：AAS“そのもの”ではなくPower BIのデータセット向け

補足：そもそもAASから“取り出す”べきかを再確認する

よくある質問

ADFの「Generic ODBC」でAASに繋げられない？

「AASのREST API」があると聞いたが？

AASは今後どうなる？移行は必須？

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル