Power BIのDAXユーザー定義関数（UDF）とは？変更点・影響範囲・展開前の確認ポイント

Power BIで同じDAX式を何度もコピーしている場合、今回の「DAX user-defined functions（DAXユーザー定義関数、UDF）」はかなり実務的な変更です。結論から言うと、DAXロジックをFUNCTIONとしてセマンティックモデル内に定義し、メジャー、計算列、ビジュアル計算、別のUDFから再利用できるようになります。Microsoft Learnの対象はPower BIであり、Azure FunctionsのFunction Appやランタイム設定を変更する話ではありません。まず確認すべきなのは、利用中のPower BI Desktop／Power BI Serviceの対応状況、セマンティックモデルの互換性レベル、既存DAXの置き換え範囲、OLSなどのセキュリティ影響です。DAX UDFはDAXの保守性を上げる一方で、命名、型指定、展開手順を決めずに導入すると、関数の乱立や意図しない計算差異を招きます。(Microsoft Learn)

Power BIのDAX user-defined functionsとは

DAX user-defined functionsは、Power BIのセマンティックモデル内に独自のDAX関数を定義する機能です。これまでメジャーや計算列ごとに繰り返していた計算ロジックを、名前付きの関数としてまとめられます。

たとえば、税抜金額に税率を掛ける処理を複数のメジャーで使っている場合、従来は各メジャーに似たDAX式をコピーしていました。DAX UDFでは、次のように関数を定義し、必要な場所から呼び出せます。

DEFINE
    /// AddTax takes in amount and returns amount including tax
    FUNCTION AddTax =
        ( amount : NUMERIC, taxRate : NUMERIC = 0.1 ) =>
            amount * ( 1 + taxRate )

EVALUATE
{ AddTax ( 1000 ) }

この例では、AddTaxという関数を定義し、amountとtaxRateを受け取って税込金額を返します。公式ドキュメントでも、DAX UDFは再利用可能なパラメーター付きDAXロジックをモデルにまとめ、DAXコードの記述、保守、共有をしやすくする機能として説明されています。(Microsoft Learn)

今回の変更で何が変わるのか

今回のポイントは、単に「DAXで便利な書き方が増える」ことではありません。Power BIのセマンティックモデル設計に、再利用可能な関数という管理単位が加わることです。

変更点	実務上の意味
`FUNCTION`キーワードで独自関数を定義できる	共通計算ロジックを1か所に集約できる
メジャー、計算列、ビジュアル計算、別UDFから呼び出せる	モデル内の複数箇所で同じロジックを再利用しやすい
DAX query viewやTMDL viewで作成・管理できる	開発者がテストしながら定義し、スクリプトとして管理できる
Model explorerのFunctionsノードで確認できる	関数がモデルオブジェクトとして扱われ、棚卸ししやすい
型ヒント、既定値、型チェックを利用できる	想定外の値や型による計算ミスを減らしやすい
Power BI Projectでは`functions.tmdl`に格納される	Gitなどのソース管理、レビュー、差分確認に組み込みやすい

公式情報では、DAX UDFはDAX query view、TMDL view、Model explorerで定義・管理でき、Power BI Projectを使う場合はセマンティックモデルのdefinitionフォルダー内のfunctions.tmdlに含まれると説明されています。(Microsoft Learn)

Azure Functionsの変更ではなく、Power BIのセマンティックモデル機能として捉える

「対象サービス: Azure Functions」として情報を整理する場合でも、このトピックの実体はAzure FunctionsではなくPower BIです。Azure FunctionsのHTTPトリガー、Timerトリガー、ホスティングプラン、アプリ設定、Functionsランタイムを変更する必要はありません。

ただし、Azure Functionsを使ってPower BI関連の自動化をしている組織では、間接的な確認が必要です。たとえば、Azure FunctionsからPower BI REST APIを呼び出してデプロイ、更新、検証を自動化している場合、DAX UDFを含むPBIPやTMDLを扱う運用に変わる可能性があります。

確認すべき観点は次のとおりです。

確認対象	Azure Functions側で見るべきこと
PBIP／TMDLを扱うCI/CD	`functions.tmdl`を成果物に含めているか
デプロイ後の検証処理	UDFを使うメジャーや計算列の結果をテスト対象に含めているか
Power BI REST API連携	セマンティックモデル更新後のエラー取得・通知処理があるか
バージョン差異	開発環境と本番環境でPower BI機能対応に差がないか

つまり、Azure Functions自体の移行ではなく、Power BIモデルを自動展開する周辺処理に影響が出るかを確認する、という位置付けです。

影響を受ける対象者

DAX UDFの影響は、Power BIレポートを見るだけの利用者よりも、モデルを設計・運用する担当者に大きく出ます。

Power BI開発者・BIエンジニア

最も影響を受けるのは、DAXメジャーや計算列を作成している開発者です。共通ロジックをUDF化することで、重複したDAX式を減らせます。

特に効果が出やすいのは、次のようなケースです。

税率、割引率、粗利率などの計算ルールを複数メジャーで使っている
通貨換算、日付キー変換、ランク付けなどの補助ロジックが繰り返し登場する
レポートごとに似たDAXをコピーしており、修正漏れが起きやすい
Power BI Projectでセマンティックモデルをソース管理している

一方で、1回しか使わない式までUDF化すると、かえって追いにくいモデルになります。目安として、同じロジックが3か所以上に出てくる、または業務ルールとして今後も変更される可能性が高いものからUDF化すると現実的です。

Power BI管理者・Fabric管理者

管理者は、機能の有効化状況、対応バージョン、展開ルール、セキュリティの確認が必要です。DAX UDFはモデル内のオブジェクトとして扱われるため、誰が作成し、どのワークスペースに展開し、どのようにレビューするかを決めておく必要があります。

特に注意したいのは、Object-Level Security（OLS）との関係です。公式情報では、OLSは関数に自動的に転送されるわけではないため、セキュリティ対象オブジェクトを関数名や説明で露出しないよう推奨されています。(Microsoft Learn)

レポート利用者

レポート利用者にとって、画面上の操作が大きく変わるわけではありません。影響があるとすれば、計算ロジックが共通化されることで、レポート間の数値の一貫性が高まる点です。

ただし、UDFを修正すると、その関数を参照している複数のメジャーや計算列に影響が広がります。開発者が便利だからといって本番モデルのUDFを直接変更すると、利用者が見ている複数レポートの数値が同時に変わる可能性があります。

導入前に確認すべき設定と前提条件

DAX UDFを試す前に、まず環境面を確認します。公式のPower BI向けページでは、Power BI Desktopで試す手順として、File > Options and settings > OptionsからPreview featuresを開き、DAX user-defined functionsを選択してPower BI Desktopを再起動する流れが示されています。(Microsoft Learn)

ただし、機能の提供状態はPower BI DesktopやPower BI Serviceのリリース時期で変わる可能性があります。公式DAXページでは、DAX UDFにはデータベース互換性レベル1702以上が必要で、2026年6月リリース時点でPower BI DesktopとPower BI Serviceに一般提供される旨も記載されています。導入時点のドキュメントと利用中バージョンを必ず照合してください。(Microsoft Learn)

確認項目	見るべきポイント	対応の目安
Power BI Desktopのバージョン	DAX UDFに対応しているか	チーム内で同じ更新チャネルにそろえる
Preview機能の有効化	Preview扱いの環境では有効化が必要か	有効化後にDesktopを再起動する
Power BI Service	作成・編集・利用のどこまで対応するか	本番展開前に検証ワークスペースで確認する
互換性レベル	1702以上か	古いモデルはアップグレード影響を確認する
セマンティックモデル	テーブルを含むモデルか	テーブルなしモデルでは制限に注意する
ソース管理	PBIX中心か、PBIP中心か	PBIPなら`functions.tmdl`をレビュー対象に含める

DAX query viewとTMDL viewの使い分け

DAX UDFは主にDAX query viewとTMDL viewで扱います。どちらを使うかは、作業の目的で分けると判断しやすくなります。

作業	向いている画面	理由
関数を試作して結果をすぐ確認する	DAX query view	`EVALUATE`で動作確認しながら書ける
既存モデルに関数を追加する	DAX query view	`Update model`でモデルへ保存しやすい
複数関数をスクリプトとして管理する	TMDL view	定義をテキストで管理しやすい
Gitで差分レビューする	Power BI Project + TMDL	`functions.tmdl`として追跡しやすい
関数一覧を確認する	Model explorer	Functionsノードで棚卸ししやすい

初心者が最初に試すなら、DAX query viewで小さな関数を作り、EVALUATEで結果を見てからモデルへ保存する流れが安全です。チーム開発や本番展開を見据えるなら、TMDLとPower BI Projectを使い、関数定義をレビューできる状態にしておくと運用しやすくなります。

実務で使えるDAX UDFの活用例

DAX UDFが役立つのは、「何度も使うが、メジャーだけではきれいに共通化しづらい計算」です。

税計算を共通化する

たとえば、売上に標準税率を適用する計算を複数のメジャーで使っている場合、次のように関数化できます。

DEFINE
    /// 金額に税率を適用して税込金額を返す
    /// @param {NUMERIC} amount - 税抜金額
    /// @param {NUMERIC} [taxRate] - 税率。省略時は0.1
    /// @returns 税込金額
    FUNCTION AddTax =
        ( amount : NUMERIC, taxRate : NUMERIC = 0.1 ) =>
            amount * ( 1 + taxRate )

メジャー側では、次のように呼び出します。

Total Sales with Tax =
AddTax ( [Total Sales] )

ただし、税率は国、商品区分、取引日によって変わることがあります。日本の消費税でも標準税率と軽減税率を扱うモデルでは、単純に0.1を既定値にするだけでは不十分です。税率マスターや商品区分を参照する設計にするか、UDFの対象を「標準税率の簡易計算」に限定するなど、業務ルールの境界を明確にしてください。

通貨換算の補助ロジックをまとめる

複数レポートで通貨コード、日付キー、為替レートを扱っている場合、通貨換算の前処理をUDF化すると保守しやすくなります。

たとえば、日付をyyyymmdd形式のキーへ変換する処理、通貨コードから通貨キーを引く処理、平均レートと期末レートを切り替える処理などは、コピーされやすく、修正漏れも起きやすい部分です。

公式ドキュメントでも、型チェックやネストした関数を使った通貨換算の高度な例が示されています。複雑な業務ロジックほど、UDF化する前に入力値、戻り値、エラー時の扱いを決めておくことが重要です。(Microsoft Learn)

移行するなら、まず「重複DAXの棚卸し」から始める

既存モデルをDAX UDFへ移行する場合、いきなり全メジャーを置き換えるのは避けた方が安全です。UDFは共通化の効果が大きい反面、修正時の影響範囲も広くなります。

おすすめの進め方は次のとおりです。

手順	作業内容	成功のポイント
既存DAXを棚卸しする	似た式、同じ業務ルール、コピーされた計算を洗い出す	まずは3か所以上で使われるロジックに絞る
UDF候補を分類する	税、割引、通貨、日付、ランキングなどに分ける	業務ルール単位で名前を付ける
入力と戻り値を決める	パラメーター、型、既定値、BLANK時の動作を決める	型ヒントと説明コメントを書く
DAX query viewで試す	`EVALUATE`で期待値を確認する	単純値、BLANK、異常値を試す
小さく置き換える	一部メジャーだけUDF呼び出しに変更する	旧メジャーと新メジャーを並べて比較する
検証ワークスペースへ展開する	レポート、更新、権限を確認する	本番前に利用者影響を確認する
ソース管理へ反映する	PBIPなら`functions.tmdl`をレビュー対象にする	関数単位で変更履歴を追えるようにする

置き換え前後で数値が一致するかを見るだけでなく、フィルター、スライサー、行レベルの集計、ビジュアル計算で結果が変わらないかも確認してください。特にvalとexprの違いは、評価コンテキストに影響するため、DAXに慣れている開発者でも見落としやすいポイントです。

パラメーター設計で失敗しないための判断基準

DAX UDFでは、パラメーターに型ヒントを指定できます。公式情報では、スカラー、テーブル、参照などの型、Int64やStringなどのサブタイプ、valとexprのパラメーターモードが説明されています。(Microsoft Learn)

実務では、次の基準で設計すると失敗しにくくなります。

判断項目	推奨
数値計算	`NUMERIC`や`DECIMAL`など、意図に近い型を指定する
文字列コード	通貨コード、商品コードなどは`STRING`を明示する
日付	日付値か日付キーかを関数名と説明で分ける
省略可能な値	既定値を使う場合は、業務上安全な値か確認する
コンテキスト制御が必要な式	`expr`の利用を検討する
単純な値渡し	まずは既定の`val`で考える

よくある失敗は、便利にしようとして1つの関数に何でも受け取らせることです。たとえば、通貨キーも通貨コードも日付キーも日付値も受け取れる関数は柔軟ですが、仕様を知らない人には使いにくくなります。複数型を受け付ける場合は、ISINT64やISSTRINGなどの型チェックを入れ、関数説明に受け付ける形式を明記しましょう。

管理者が確認すべきセキュリティとガバナンス

DAX UDFは便利な共通部品ですが、ガバナンスなしに導入すると、モデル内に似た関数が増え続けます。管理者やリード開発者は、最低限次のルールを決めておくべきです。

項目	決めるべきルール
命名規則	業務領域や用途が分かる名前にする
説明コメント	`///`で目的、引数、戻り値を書く
レビュー	本番モデルに入れるUDFはレビュー必須にする
所有者	関数ごと、または業務領域ごとに保守担当を決める
変更管理	UDF変更時は参照メジャーの影響範囲を確認する
セキュリティ	OLS対象のオブジェクト名を関数名や説明に出さない
テスト	代表的なフィルター条件と異常値を含めて検証する

特にOLSは要注意です。公式ドキュメントでは、OLSが保護しているメジャーをUDFから参照しても、その保護が関数側に自動的に転送されるわけではないと説明されています。セキュリティ対象の列名、メジャー名、業務上秘匿したいロジックをUDFの名前や説明に含めない運用が必要です。(Microsoft Learn)

展開時に注意すべき制限事項

DAX UDFには、導入前に知っておくべき制限があります。公式ドキュメントでは、Service上でのUDF作成・モデリング、表示フォルダー、翻訳、再帰、関数オーバーロード、明示的な戻り値型などに関する制限が示されています。(Microsoft Learn)

制限・注意点	実務での影響
Service上での作成・モデリングに制限がある	DesktopやTMDLを前提に開発フローを組む
UDFを表示フォルダーに入れられない	関数名のプレフィックスや命名規則が重要になる
UDFと翻訳を組み合わせられない制限がある	多言語モデルでは導入可否を慎重に判断する
再帰・相互再帰はサポートされない	階層的な計算は別設計を検討する
関数オーバーロードはできない	引数違いの同名関数を作れない
明示的な戻り値型はサポートされない	戻り値はテストと説明で管理する
ビジュアル計算では参照できる対象が限られる	ビジュアルに存在しないモデルオブジェクトを渡せない
一部の参照型ヒントに既知の問題がある	必要に応じて`AnyRef`へのフォールバックを検討する
IntelliSenseに制限がある場面がある	ライブ接続、複合モデル、TMDL viewなどで過信しない

制限事項は、プレビュー期間やリリース更新で変わる可能性があります。運用ルールに「公式ドキュメント確認日」「検証したPower BI Desktopのバージョン」「本番投入した関数一覧」を残しておくと、後から原因調査しやすくなります。

本番導入前のチェックリスト

DAX UDFを本番モデルに入れる前に、次のチェックを行ってください。

チェック	確認内容
対応環境	Power BI Desktop、Power BI Service、互換性レベルが対応している
影響範囲	UDFを参照するメジャー、計算列、ビジュアル計算を一覧化した
命名	関数名が一意で、組み込みDAX関数や予約語と衝突しない
型	パラメーターに必要な型ヒントを設定した
既定値	省略可能パラメーターの既定値が業務上妥当
テスト	通常値、BLANK、異常値、フィルター条件で検証した
セキュリティ	OLS対象の名称や説明を不用意に露出していない
ソース管理	`functions.tmdl`をレビュー・差分管理できる
ロールバック	UDF化前のメジャーやPBIX／PBIPを戻せる
利用者通知	数値の定義が変わる場合、関係者へ説明済み

このチェックリストを満たしていない場合、まずは検証用ワークスペースで小さく試すのが安全です。特に、基幹レポートや経営指標に関わるモデルでは、1つのUDF変更が複数レポートへ広がる点を前提にしてください。

すぐに導入すべきケース、まだ待つべきケース

DAX UDFは便利ですが、すべてのPower BIモデルにすぐ入れるべき機能ではありません。導入効果と運用リスクを見て判断しましょう。

判断	向いているケース
すぐ検証すべき	同じDAXロジックが複数メジャーに散らばっている
すぐ検証すべき	PBIPやTMDLでソース管理している
すぐ検証すべき	DAXレビュー体制があり、共通関数の責任者を決められる
慎重に進めるべき	多言語モデルやOLSを多用している
慎重に進めるべき	チーム内のPower BI Desktopバージョンがばらばら
慎重に進めるべき	本番モデルを直接編集する運用になっている
まだ待つべき	UDF化するほど重複ロジックがない
まだ待つべき	検証ワークスペースやロールバック手順がない

実務上は、最初から全社標準にするよりも、1つのセマンティックモデルで「重複しているが影響範囲を把握しやすい計算」から試すのが現実的です。たとえば、税率計算、売上単価、粗利率、日付キー変換など、入力と出力が分かりやすい関数から始めると、チームにも説明しやすくなります。

次に取るべき行動

Power BIのDAX user-defined functionsは、DAXを「レポートごとの式」から「モデル内で再利用する部品」へ近づける変更です。特に、同じDAX式を何度もコピーしているモデルでは、保守性と一貫性の改善が期待できます。

まずやるべきことは、既存モデルの重複DAXを棚卸しすることです。次に、Power BI DesktopとPower BI Serviceの対応状況、互換性レベル、ソース管理方式、OLSを含むセキュリティ影響を確認します。そのうえで、検証用ワークスペースに小さなUDFを作成し、旧メジャーと新メジャーの結果を比較してください。

Azure Functionsを使った自動化がある場合も、Azure Functions本体の設定変更ではなく、Power BIモデルの展開・検証フローにfunctions.tmdlやUDF参照メジャーが含まれるかを確認するのがポイントです。DAX UDFは、便利な共通化機能であるほど、設計とレビューの質が結果に直結します。

この記事を書いた人

佐藤健司

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