第1回 問題集（全般）

正解: C. C. Contributor

正解の根拠・詳細解説

ContributorロールはアイテムやレポートのコンテンツをCRUDできるが、ワークスペース自体の設定（メンバー管理やワークスペース設定）は変更できない。Adminはワークスペース管理権限を持ち、Viewerは閲覧のみ。

正解: C. C. DAXフィルター式を使ったRLSロール

正解の根拠・詳細解説

RLSはDAXのフィルター式（例：[Region] = USERPRINCIPALNAME()）を使ってロールを定義し、ユーザーごとに表示される行を制限する機能。列やテーブル単位の制限はOLS/オブジェクトレベルセキュリティで行う。

正解: B. B. 列レベルセキュリティ（CLS）

正解の根拠・詳細解説

列レベルセキュリティ（CLS）はOneLakeのデータアクセス制御の一つで、特定のカラムへのアクセスを制限する。行を制限するのはRLS、テーブル/ファイル全体の制限はOLS/ファイルレベルセキュリティ。

正解: A. A. センシティビティラベル

正解の根拠・詳細解説

センシティビティラベル（Microsoft Purview Information Protection）は、データの機密度を分類し、保護ポリシー（暗号化・アクセス制限など）を適用する仕組み。

正解: B. B. Certified（証明済み）エンドースメント

正解の根拠・詳細解説

エンドースメントには「Promoted（推奨）」と「Certified（証明済み）」があり、Certifiedは管理者やレビュー担当者がデータ品質を保証したアイテムに付与する、より権威性の高いマークである。

正解: B. B. .pbip

正解の根拠・詳細解説

.pbip（Power BI Project）形式は、レポートとセマンティックモデルをテキストベースのファイル（TMDL/JSON）に分解して保存するため、Gitなどのバージョン管理システムとの統合に適している。

正解: A. A. インパクト分析（影響関係の確認）

正解の根拠・詳細解説

Fabricではレイクハウス・ウェアハウス・データフロー・セマンティックモデル間の依存関係を可視化するインパクト分析機能があり、変更前にダウンストリームへの影響を確認できる。

正解: A. A. デプロイメントパイプライン

正解の根拠・詳細解説

デプロイメントパイプラインは開発・テスト・本番のステージを定義し、ステージ間でアイテムをコピー・比較・デプロイするためのライフサイクル管理機能。

正解: B. B. XMLAエンドポイント

正解の根拠・詳細解説

XMLAエンドポイントを使うと、SSMS（SQL Server Management Studio）やAnalysis Services関連の管理ツールから、Power BI Premium/Fabricのセマンティックモデルに対して直接管理操作（オブジェクトの作成・更新、パーティション処理など）が行える。

正解: B. B. .pbids

正解の根拠・詳細解説

.pbids（Power BI Data Source）ファイルは、データソースへの接続情報（サーバー名・データベース名など）のみを保存し、複数のレポート作成者が同じ接続設定を簡単に再利用できるようにするファイル形式。

正解: A. A. .pbit

正解の根拠・詳細解説

.pbit（Power BI Template）はレポートのレイアウト・ビジュアル・クエリ構造を保存し、データを含まないテンプレートファイル。配布先で異なるデータソースに接続して同じ構造のレポートを作成できる。

正解: A. A. 共有セマンティックモデル（Shared Semantic Model）

正解の根拠・詳細解説

共有セマンティックモデルを使うことで、複数のレポート作成者やワークスペースが同一のモデルをライブ接続で参照でき、モデルの一元管理とレポートの分離を両立できる。

正解: D. D. Viewer

正解の根拠・詳細解説

Viewerロールはワークスペース内のコンテンツを閲覧する権限のみを持ち、編集・作成・共有はできない。

正解: A. A. Admin

正解の根拠・詳細解説

Adminロールはワークスペースの全権限（メンバー管理・ワークスペース設定変更・容量の割り当てなど）を持つ最上位ロール。

正解: B. B. レイクハウスのファイルシステム（OneLake内のファイル/ディレクトリ）へのアクセスを制限する

正解の根拠・詳細解説

ファイルレベルセキュリティは、レイクハウスのファイルエクスプローラー領域（Files）にあるファイルやディレクトリへのアクセスを、ユーザー/グループ単位で制限する機能。

正解: B. B. テーブルやカラムといったオブジェクト全体へのアクセス

正解の根拠・詳細解説

OLS（Object-Level Security）は、特定のテーブルやカラムそのものをユーザーから完全に見えなくする（メタデータレベルで非表示にする）仕組みで、行単位の制御であるRLSとは異なる。

正解: B. B. ダウンストリームのレポートでのエラーやデータ不整合

正解の根拠・詳細解説

依存関係を事前に確認（インパクト分析）せずにスキーマを変更すると、列名の変更や削除によって、それを参照するセマンティックモデルやレポートでクエリエラーやデータ不整合が発生するリスクが高い。

正解: B. B. JSON/TMDLなどのテキストベースファイル群

正解の根拠・詳細解説

.pbip形式では、レポート定義（report.json等）とセマンティックモデル定義（TMDL形式）がフォルダ構成のテキストファイル群として保存されるため、差分管理やコードレビューがしやすくなる。

正解: B. B. 各ステージ間の差分（変更内容）の比較

正解の根拠・詳細解説

デプロイメントパイプラインには各ステージ間でアイテムの差分を比較する機能があり、意図しない変更が本番にデプロイされないよう事前確認することが推奨される。

正解: A. A. インパクト分析（Lineage view含む）

正解の根拠・詳細解説

インパクト分析（系列/Lineageビュー）では、データソースからレイクハウス・ウェアハウス・データフロー・セマンティックモデル・レポートまでの依存関係をグラフで可視化できる。

正解: B. B. Gitと統合した.pbip形式でブランチ運用する

正解の根拠・詳細解説

.pbip形式はテキストベースのため、Gitでのブランチ運用・プルリクエストによるレビュー・差分管理が可能になり、コンフリクトの検出と解決がしやすくなる。

正解: B. B. モデルのクエリと閲覧のみ

正解の根拠・詳細解説

XMLAエンドポイントには読み取り専用と読み書き可能のモードがあり、読み取り専用モードではSSMS等からモデルへの接続・クエリ実行・メタデータの閲覧のみが可能で、書き込み操作は許可されない。

正解: B. B. レポートのレイアウトやビジュアル構成を再利用させる目的

正解の根拠・詳細解説

.pbitはデータを含まないテンプレートファイルであり、主な目的はレポートのデザイン・構造・クエリパターンを他の作成者に再利用してもらうことにある。

正解: A. A. Promotedはコンテンツ所有者自身が設定でき、Certifiedは管理者やレビュー担当者のみが設定できる

正解の根拠・詳細解説

Promotedはアイテムの所有者や編集権限を持つユーザーが「これは推奨品質」として自己申告的に付与できるのに対し、Certifiedは組織が指定した認定レビュー担当者のみが付与できる、より厳格な信頼の印。

正解: B. B. ワークスペースロール（Admin/Member/Contributor/Viewer）

正解の根拠・詳細解説

ワークスペースレベルのアクセス制御はワークスペースロール（Admin/Member/Contributor/Viewer）を基本単位として構成し、ユーザーやグループに適切なロールを割り当てることがアクセス管理の出発点となる。

正解: B. B. CLS（列レベルセキュリティ）を該当列に適用

正解の根拠・詳細解説

特定の列（電話番号）を非表示にしたい場合は列レベルセキュリティ（CLS）を該当カラムに適用するのが最も直接的な方法。行全体やテーブル全体の制限とは異なるアプローチが必要。

正解: B. B. 変更内容の事前比較やロールバックの仕組みがないため、意図しない変更が本番に反映されるリスクが高い

正解の根拠・詳細解説

デプロイメントパイプラインを経由しない直接デプロイは、変更差分の事前確認やステージング検証のプロセスをスキップするため、本番環境への意図しない影響やトラブルのリスクが高まる。

正解: B. B. 変更履歴の追跡とチーム間でのコードレビューの実現

正解の根拠・詳細解説

Gitとの統合により、Fabricアイテムの変更履歴をコミット単位で追跡し、プルリクエストを通じたチームレビューやブランチ戦略による安全な変更管理が可能になる。

正解: B. B. デプロイメントパイプラインの開発ステージで編集させ、本番へはパイプライン経由でデプロイする

正解の根拠・詳細解説

デプロイメントパイプラインを使えば、開発ステージで自由に編集・テストを行い、検証済みの内容のみをパイプライン経由で本番にデプロイする運用が可能になり、本番への直接編集を防げる。

正解: B. B. データソースやスキーマを変更する前

正解の根拠・詳細解説

インパクト分析は、データソースやスキーマの変更がダウンストリームのレポートやモデルにどう影響するかを事前に把握するための機能なので、変更前に実施するのが最も効果的。

正解: A. A. デプロイメントルール（パラメータの環境別上書き）

正解の根拠・詳細解説

デプロイメントパイプラインの「デプロイメントルール」機能を使うと、ステージごとに異なる接続文字列やパラメータ値を設定し、デプロイ時に自動的に上書きできる。

正解: A. A. センシティビティラベルとそれに基づく保護ポリシー

正解の根拠・詳細解説

センシティビティラベルを適切なデータに付与し、外部共有やダウンロードを制限する保護ポリシーと組み合わせることで、機密データの意図しない流出リスクを軽減できる。

正解: B. B. 変更管理・バージョン管理・環境間デプロイを体系的に行い、品質と再現性を確保すること

正解の根拠・詳細解説

分析開発ライフサイクル管理とは、レポートやセマンティックモデル、パイプラインといった分析成果物を、ソフトウェア開発と同じ規律で扱う考え方です。Fabricではワークスペースをgit（Azure DevOpsやGitHub）に接続してバージョン管理でき、Power BIプロジェクト（.pbip）形式で保存するとモデルやレポートの定義がテキストファイルとして表現されるため、差分の確認やレビュー、マージが可能になります。さらにデプロイメントパイプラインを使うと開発・テスト・本番のステージ間で成果物を昇格でき、デプロイ規則によって環境ごとの接続先を切り替えられます。系列（リネージ）ビューやインパクト分析を使えば、あるモデルへの変更がどのレポートに影響するかを事前に把握できます。これらが目指すのは変更の追跡可能性と再現性、そして品質の確保であり、DAXクエリの実行速度や容量コストの最適化はパフォーマンスチューニングという別の観点の課題です。

正解: A. A. OneLakeカタログ

正解の根拠・詳細解説

OneLakeカタログは、組織内のFabricアイテムが保持するデータ資産を検索・発見し、ガバナンス情報（オーナー、エンドースメント状態など）を確認できる機能。

正解: A. A. Real-Time hub

正解の根拠・詳細解説

Real-Time hubは、組織内で利用可能なリアルタイムデータストリーム（イベントハブ、IoTデバイス等）を検出し、Eventstreamなどに接続してリアルタイム処理を開始するための中心的なハブ機能。

正解: B. B. ウェアハウス（Warehouse）

正解の根拠・詳細解説

Fabricのウェアハウスは、SQL ServerライクなT-SQLエクスペリエンスを提供し、構造化データのクエリ・更新・トランザクション処理に最適化されたデータストア。

正解: A. A. レイクハウス

正解の根拠・詳細解説

レイクハウスはOneLake上にファイル（非構造化/半構造化）とDeltaテーブル（構造化）を統合して保存し、SparkやSQLエンドポイントから同じデータにアクセスできるストレージアーキテクチャ。

正解: A. A. KQLデータベース（Eventhouse内）

正解の根拠・詳細解説

KQLデータベースはEventhouse内に作成され、高速に到着するログ・テレメトリ・IoTデータの取り込みと、Kusto Query Language（KQL）による時系列分析に最適化されている。

正解: A. A. EventhouseのデータをDirect Lakeモードでセマンティックモデルから直接参照できるようにする

正解の根拠・詳細解説

OneLake統合を有効にすると、EventhouseのKQLデータベースのデータがOneLake上のDeltaLake形式でも公開され、セマンティックモデルがDirect Lakeモードで直接そのデータを参照できるようになる。

正解: A. A. データ接続（Data connection / 接続資格情報）

正解の根拠・詳細解説

データを取り込むには、まずデータソースへの接続（接続文字列・認証情報を含むデータ接続）を作成する必要がある。

正解: A. A. OneLakeカタログでの検索

正解の根拠・詳細解説

OneLakeカタログは組織全体のデータ資産を検索・発見するためのカタログ機能であり、他部署が公開したデータセットを見つける際の最初の入り口となる。

正解: B. B. 元のテーブルを変更せずに、特定のクエリロジックを再利用可能な形で定義する

正解の根拠・詳細解説

ビューは元のテーブルのデータを物理的にコピーせず、SELECTクエリのロジックを名前付きオブジェクトとして保存し、再利用可能にする仕組み。

正解: B. B. 複雑な処理ロジックをカプセル化し、再利用・呼び出しを容易にする

正解の根拠・詳細解説

ストアドプロシージャは複数のSQL文や処理ロジックを1つの呼び出し可能なオブジェクトにまとめることができ、コードの再利用性と保守性を高める。

正解: A. A. スタースキーマ

正解の根拠・詳細解説

スタースキーマは、中心となるファクトテーブル（トランザクションデータ）と、それを取り囲む複数のディメンションテーブル（属性データ）で構成するデータモデリング手法で、分析クエリの性能と理解しやすさに優れる。

正解: B. B. 結合（JOIN）の回数を減らし、クエリパフォーマンスと分析のしやすさを向上させるため

正解の根拠・詳細解説

非正規化は複数テーブルの結合を減らすことでクエリの複雑さとパフォーマンスコストを下げ、分析用途でのデータ取得を高速化・簡素化する目的で行われる。

正解: B. B. LEFT OUTER JOIN

正解の根拠・詳細解説

LEFT OUTER JOINは左側のテーブルの全行を保持し、右側に一致するデータがない場合はNULLで埋めて結合する。INNER JOINは一致する行のみを返す。

正解: A. A. DISTINCT

正解の根拠・詳細解説

DISTINCTキーワードは、SELECT結果から重複する行を除去し、一意な行のみを返す。

正解: A. A. ISNULL()またはCOALESCE()

正解の根拠・詳細解説

ISNULL()やCOALESCE()関数は、指定した列の値がNULLの場合に代替値（例：「不明」）を返すために使用される。

正解: A. A. データ型の変換（CASTやCONVERTなど）

正解の根拠・詳細解説

CASTやCONVERTといった型変換関数を使って、文字列型の列を数値型などに明示的に変換することで、正しい集計やソート処理が可能になる。

正解: A. A. フィルタリング（WHERE句など）

正解の根拠・詳細解説

フィルタリングはWHERE句（SQLの場合）などを使って指定の条件に合致する行のみを絞り込む処理。

正解: A. A. GROUP BY と SUM() の組み合わせ

正解の根拠・詳細解説

GROUP BYで地域・月ごとにグループ化し、SUM()で各グループの売上を合計することで、地域別・月別の集計結果を得られる。

正解: A. A. SQLコードを書かずにドラッグ&ドロップ操作でクエリを構築できる

正解の根拠・詳細解説

Visual Query Editorは、SQLやコードを直接記述せずに、テーブルの選択・フィルタ・結合などをGUI操作（ドラッグ&ドロップ等）で行い、クエリを視覚的に構築できる機能。

正解: A. A. where Timestamp > ago(1h)

正解の根拠・詳細解説

KQL（Kusto Query Language）では、`where`演算子と`ago()`関数を組み合わせて、現在時刻から指定した時間範囲内のデータを絞り込むのが典型的なパターン。

正解: A. A. CALCULATE(SUM([Sales]), ALL(Table))

正解の根拠・詳細解説

ALL()関数は指定したテーブルや列に対するすべてのフィルターを除去する。CALCULATE()と組み合わせることで、現在のフィルターコンテキストを無視した集計が可能になる。

正解: A. A. 列の削除、列名の変更、データ型の変換などのステップを記録する

正解の根拠・詳細解説

Power Queryでは、列の削除・名前変更・型変換・フィルタなどの操作を一連の「ステップ」として記録し、データ変換のロジックを再現可能な形で保存する。

正解: A. A. 上司と部下のように、同一テーブル内の階層関係を扱う場合

正解の根拠・詳細解説

SELF JOINは、従業員テーブルにおける「上司ID」と「従業員ID」のように、同一テーブル内のレコード間の関係（階層構造など）を扱う際によく使われる。

正解: A. A. Eventstream

正解の根拠・詳細解説

Eventstreamは、イベントハブやIoT Hub、Kafkaなどのリアルタイムデータソースからのストリーミングデータを取り込み、Eventhouse（KQLデータベース）やレイクハウスなどの宛先にルーティングするFabricのアイテム。

正解: A. A. UNION（またはUNION ALL）

正解の根拠・詳細解説

UNION/UNION ALLは複数のSELECT文の結果を縦方向（行として）結合する演算子。JOINは横方向（列として）の結合を行う。

正解: A. A. JOIN（結合）

正解の根拠・詳細解説

Power Queryの「マージ」操作はキー列を基準に2つのテーブルを結合する機能で、SQLのJOINに相当する。

正解: A. A. データのエンリッチ（列の追加）

正解の根拠・詳細解説

既存の列から導出した新しい列（年・月など）を追加する操作は、データを「エンリッチ」する代表的な手法。

正解: A. A. レイクハウスのDeltaテーブルに対してT-SQLで読み取りクエリを実行する

正解の根拠・詳細解説

レイクハウスのSQLエンドポイントは、レイクハウス内のDeltaテーブルに対してT-SQLによる読み取り専用クエリを実行できるようにする自動生成されたエンドポイント。

正解: A. A. SAMEPERIODLASTYEAR()

正解の根拠・詳細解説

SAMEPERIODLASTYEAR()は、現在の日付コンテキストに対応する「前年の同じ期間」のデータを返す時間インテリジェンス関数で、前年同月比の計算によく使われる。

正解: A. A. RELATED()

正解の根拠・詳細解説

RELATED()関数は、多対一のリレーションシップを通じて、関連するテーブルの列の値を現在の行コンテキストに取り込むために使用する。

正解: A. A. summarize count() by bin(Timestamp, 1h)

正解の根拠・詳細解説

KQLのsummarize演算子とbin()関数を組み合わせることで、タイムスタンプを指定の時間幅（1時間など）に丸めてグループ化し、集計を行う典型的なパターンになる。

正解: B. B. nullと空文字列は異なる値として区別されるため、明示的に両方の条件をチェックする必要がある

正解の根拠・詳細解説

Power Query（M言語）ではnullと空文字列は異なる値として区別されるため、欠損データの処理では両方のケースを明示的に考慮する必要がある。

正解: A. A. SparkのDataFrame APIを使ったノートブック処理

正解の根拠・詳細解説

複雑な変換処理や大規模データの分散処理にはSpark（PySparkやScala等）のDataFrame APIを使ったノートブックでの処理が適している。

正解: B. B. 分析で必要とされる詳細度（例：1行=1注文 vs 1行=1注文明細）に合わせること

正解の根拠・詳細解説

ファクトテーブルの粒度は、ビジネス要件としてどのレベルの詳細度（注文単位、注文明細単位など）で分析したいかに合わせて設計することが最も重要。

正解: A. A. project

正解の根拠・詳細解説

project演算子は出力する列を選択（射影）するために使用し、不要な列を除外して必要な列だけを表示する。

正解: A. A. extend

正解の根拠・詳細解説

extend演算子は既存の列を基にした計算結果を新しい列として追加するために使用する。

正解: A. A. join

正解の根拠・詳細解説

KQLのjoin演算子は、SQLのJOINと同様に、共通のキー列を基準に2つのテーブルを結合する。

正解: A. A. CTE（WITH句を使った共通テーブル式）

正解の根拠・詳細解説

CTE（Common Table Expression、WITH句）は、サブクエリの結果に一時的な名前を付けて、メインクエリから複数回参照できるようにする構文。

正解: A. A. タイムトラベル（Delta Lakeのバージョン管理）

正解の根拠・詳細解説

Delta Lake形式は変更ログ（トランザクションログ）を保持しており、「タイムトラベル」機能を使って過去の特定バージョンやタイムスタンプの状態のデータを参照できる。

正解: A. A. テキストのフォーマット変換

正解の根拠・詳細解説

大文字/小文字の統一はテキスト変換（フォーマット変換）の一種で、データの一貫性を高めるためにクリーニング処理の一環として行われる。

正解: A. A. summarize count() by ColumnName

正解の根拠・詳細解説

summarize count() by ColumnNameを使うと、列の各値ごとの出現回数を集計でき、値の分布を確認するのに役立つ。

正解: A. A. 複数のDML操作を一つの単位として扱い、整合性を保証できる

正解の根拠・詳細解説

トランザクションサポートにより、複数のINSERT/UPDATE/DELETE操作を1つの論理単位として扱い、すべて成功するか全て失敗（ロールバック）するかの整合性（ACID特性）を保証できる。

正解: A. A. データクリーニング（名寄せ・標準化）

正解の根拠・詳細解説

表記揺れの統一はデータクリーニング（名寄せ・標準化）の代表的な作業で、分析の正確性を確保するために重要な前処理。

正解: B. B. 後続のステップが前提とする列やデータ型が変わり、エラーが発生する可能性がある

正解の根拠・詳細解説

Power Queryのステップは順番に適用されるため、順序を変更すると、後続のステップが前提としていた列名やデータ型が変化し、エラーや意図しない結果につながる可能性がある。

正解: A. A. 指定したフィルター条件を適用した上で式を評価する

正解の根拠・詳細解説

CALCULATE関数は、指定したフィルター引数に基づいて現在のフィルターコンテキストを変更し、その新しいコンテキストの下で第一引数の式を評価する、DAXの中核的な関数。

正解: A. A. render

正解の根拠・詳細解説

render演算子は、クエリ結果を折れ線グラフや円グラフなどの形式で可視化するために使用する。

正解: A. A. マテリアライズドビュー（または事前集計テーブル）

正解の根拠・詳細解説

マテリアライズドビュー（または事前に計算した集計テーブル）は、クエリ結果を物理的に保存しておくことで、毎回の再計算を避け、クエリパフォーマンスを向上させる手法。

正解: A. A. 列方向に広がったデータ（例：月ごとの列）を、行方向の縦長データに変換したい場合

正解の根拠・詳細解説

ピボット解除は、各月が個別の列になっているような「横長（wide）」データを、1行=1レコードの「縦長（long）」形式に変換する操作で、分析やモデリングに適した形式にするために使われる。

正解: A. A. take（またはlimit）

正解の根拠・詳細解説

take（limitの別名）演算子は、結果セットから指定した件数だけのレコードを取得するために使用する。

正解: A. A. クエリのパフォーマンス分析（実行計画の確認）

正解の根拠・詳細解説

実行計画（クエリプラン）を確認することで、どの処理ステップが時間を要しているかを分析し、インデックスの追加やクエリの書き換えなどパフォーマンス改善の手がかりを得られる。

正解: A. A. CONCAT()または + 演算子

正解の根拠・詳細解説

CONCAT()関数や文字列結合演算子（+や||など、DBMSにより異なる）を使うことで、複数の列の値を1つの文字列として連結できる。

正解: A. A. エラーの保持・削除（Keep/Remove Errors）

正解の根拠・詳細解説

Power Queryには変換中にエラーとなった行を保持（確認用）または削除するための専用機能があり、データ品質の問題を特定・対処するのに役立つ。

正解: A. A. ウェアハウス

正解の根拠・詳細解説

ウェアハウスはT-SQLによる完全なDML（INSERT/UPDATE/DELETE）とトランザクション処理をサポートし、構造化データのSQL中心の処理に適している。一方レイクハウスはSpark処理や半構造化データの取り扱いに強みがある。

正解: A. A. 統計的な範囲（最大・最小・標準偏差など）に基づくクエリでの絞り込み

正解の根拠・詳細解説

外れ値の検出は、まずデータの分布を統計量で把握するところから始めます。平均と標準偏差を求めて平均±3σの範囲から外れる値を抽出する方法や、四分位数を用いてQ1−1.5×IQRより小さい値・Q3+1.5×IQRより大きい値を候補とする四分位範囲法が代表的で、最大値・最小値・件数の確認も基本的な手掛かりになります。Fabricではノートブック、SQL分析エンドポイント、KQLクエリセットのいずれでも同じ集計をそのまま記述でき、集計結果を条件にした絞り込みで該当行を特定できます。実務で重要なのは、外れ値が必ずしも誤りとは限らない点です。入力ミスや単位の取り違え、センサー障害である場合もあれば、実際に起きた重要な事象を示している場合もあるため、機械的に除去せず原因を確認してから扱いを決めます。行レベルセキュリティやセンシティビティラベル、ワークスペースロールはアクセス制御やガバナンスのための機能であり、値の分布を分析する手段ではありません。

正解: A. A. Import（インポートモード）

正解の根拠・詳細解説

Importモードはデータをセマンティックモデル内のVertiPaqエンジンに完全に取り込んで保持するため、最も高速なクエリパフォーマンスが得られるが、データの鮮度はリフレッシュ頻度に依存する。

正解: B. B. DirectQuery

正解の根拠・詳細解説

DirectQueryモードはデータをインポートせず、レポートの操作ごとに元のデータソースへリアルタイムにクエリを発行する。データの鮮度は高いが、パフォーマンスはデータソース側の性能に依存する。

正解: A. A. Direct Lake

正解の根拠・詳細解説

Direct Lakeモードは、OneLake上のDeltaParquetファイルを直接読み込むことで、Importに近い高速性を保ちながら、データの物理的なコピー（インポート処理）を不要にする、Fabric特有のストレージモード。

正解: A. A. 複合モデル（Composite Model）

正解の根拠・詳細解説

複合モデル（Composite Model）は、Import・DirectQuery・Direct Lakeなど異なるストレージモードのテーブルを1つのセマンティックモデル内に混在させる構成。

正解: A. A. ブリッジテーブル（中間テーブル）を介した多対多リレーションシップ

正解の根拠・詳細解説

複数のファクトテーブルが同じディメンションを共有し、かつ多対多の関係になる場合は、ブリッジテーブルを介して多対多リレーションシップを設計するのが一般的なアプローチ。

正解: A. A. イテレーター関数（SUMX、AVERAGEXなど）

正解の根拠・詳細解説

SUMXやAVERAGEX、FILTERXなどの「Xで終わる」イテレーター関数は、テーブルの各行に対して式を評価し、その結果を集計する反復処理を行う。

正解: A. A. 指定した範囲（ウィンドウ）内の行に対して相対的な計算（移動平均など）を行う

正解の根拠・詳細解説

ウィンドウ関数は、現在の行を基準に前後の範囲（ウィンドウ）を定義し、その範囲内のデータに対する計算（移動平均や累積合計など）を行うために使用される。

正解: A. A. セマンティックモデルのメタデータ（テーブル定義やビューの情報など）を取得する

正解の根拠・詳細解説

INFO関数群は、モデル自体のメタデータ（テーブル、列、メジャー、ビューなどの定義情報）をクエリ可能なテーブルとして返す、モデルの自己分析や監査に使われる機能。

正解: A. A. 計算グループ（Calculation Groups）

正解の根拠・詳細解説

計算グループは、「前年同月比」「累計」のような共通の計算ロジック（計算アイテム）を一度定義し、複数のメジャーに対して再利用可能にする機能。

正解: A. A. フィールドパラメーター（Field Parameters）

正解の根拠・詳細解説

フィールドパラメーターを使うと、利用者がスライサーやドロップダウンで分析対象のフィールド（メジャーや列）を動的に切り替えられるレポートを作成できる。

正解: A. A. 動的書式文字列（Dynamic Format Strings）

正解の根拠・詳細解説

動的書式文字列を使うと、DAX式の結果に応じてメジャーの表示形式（小数桁数や単位表示など）を動的に変更できる。

正解: A. A. 大規模セマンティックモデルストレージ形式（Large semantic model storage format）

正解の根拠・詳細解説

大規模セマンティックモデルストレージ形式を有効にすると、Premium/Fabric容量上で、より大きなモデルサイズの保存と効率的なメモリ管理が可能になる。

正解: A. A. データの一部を高速化（Import）しつつ、一部は最新データをリアルタイムに参照（DirectQuery）するバランスを取ること

正解の根拠・詳細解説

複合モデルは、頻繁に変わらないマスターデータはImportで高速化し、リアルタイム性が必要なトランザクションデータはDirectQueryで参照するなど、パフォーマンスと鮮度のバランスを取るために設計される。

正解: A. A. 1対多（ディメンション側が1、ファクト側が多）

正解の根拠・詳細解説

標準的なスタースキーマでは、ディメンションテーブルの主キー（1）に対してファクトテーブルの外部キー（多）が対応する1対多のリレーションシップを構築するのが基本形。

正解: A. A. VAR … RETURN

正解の根拠・詳細解説

VARキーワードを使うと、DAX式内で中間結果を変数として一度だけ計算・保存し、RETURN句で最終結果を返すことができ、可読性とパフォーマンスの両方を改善できる。

正解: A. A. DAXのパフォーマンスとメモリ効率が向上し、保守性も高まる

正解の根拠・詳細解説

スタースキーマは、ディメンションの再利用性・保守性に優れ、VertiPaqエンジンの圧縮効率やDAXパフォーマンスの観点でも、1つの巨大なフラットテーブルより優れていることが一般的に推奨される。

正解: A. A. フォールバック（DirectQueryへの自動切り替え）

正解の根拠・詳細解説

Direct Lakeモードでは、データの読み込みに問題がある場合、DirectQueryモードへ自動的に「フォールバック」してクエリを継続させる挙動がある（設定により制御可能）。

正解: A. A. FILTER関数は全行をスキャンするコストが高くなりやすいため、より直接的なブールフィルター式やKEEPFILTERSを使う方が効率的

正解の根拠・詳細解説

FILTER関数はテーブル全体をスキャンしてフィルター条件を評価するため、大規模テーブルではコストが高くなりやすい。可能な場合は直接的なブールフィルター式やKEEPFILTERSを使うことで、パフォーマンスを改善できることが多い。

正解: A. A. パフォーマンスアナライザー（Performance Analyzer）でクエリの実行時間を計測する

正解の根拠・詳細解説

Power BI Desktopのパフォーマンスアナライザーを使うことで、各ビジュアルのDAXクエリ実行時間やビジュアル描画時間を計測し、ボトルネックとなっている箇所を特定できる。

正解: A. A. データへのアクセス経路（OneLakeのDeltaファイルを直接読むか、SQLエンドポイントを経由するか）が異なる

正解の根拠・詳細解説

Direct Lake on OneLakeはOneLake上のDeltaテーブルを直接読み込み、Direct Lake on SQL endpointはウェアハウス/レイクハウスのSQLエンドポイントが提供するメタデータ・セキュリティ層を経由してアクセスする、という経路の違いがある。

正解: A. A. 毎回全データを再取得するのではなく、変更があった一部のデータのみを更新し、リフレッシュ時間とリソース消費を削減する

正解の根拠・詳細解説

増分更新は、過去の確定済みデータは再取得せず、直近の変更があった範囲（パーティション）のみを更新することで、リフレッシュ処理の時間とリソース消費を大幅に削減する機能。

正解: A. A. DAX Studio

正解の根拠・詳細解説

DAX Studio（コミュニティが開発しMicrosoftも参照する代表的な無償ツール）は、DAXクエリの実行計画やパフォーマンスメトリクスを詳細に分析するために広く使われている。

正解: A. A. OneLake上のDeltaテーブルが更新されると、再インポート処理なしで最新データが反映される（またはモデルの再フレーム処理で反映）

正解の根拠・詳細解説

Direct LakeモードではOneLake上のDeltaテーブルの更新内容が、フレーム処理（reframing）によってモデルに反映される。Importのような完全な再インポート処理は不要で、DirectQueryのようにクエリ毎に問い合わせるわけでもない。

正解: A. A. ストレージモード（DualモードかSingleモードか）の整合性

正解の根拠・詳細解説

複合モデルでは、テーブルのストレージモード（特にDualモード）の設定によってクエリの実行方法が変わるため、リレーションシップの整合性やパフォーマンスへの影響を理解して設定する必要がある。

正解: A. A. フィルターコンテキストの評価範囲と、不要に大きなテーブルスキャンが発生していないか

正解の根拠・詳細解説

DAXパフォーマンスの問題は多くの場合、フィルターコンテキストが意図せず広範囲になっていたり、大きなテーブルを毎回スキャンするような非効率な式が原因であることが多いため、まずこの点を調査するのが基本。

正解: A. A. カーディナリティ（一意な値の数）が高い列を減らし、必要な列のみをモデルに含める

正解の根拠・詳細解説

VertiPaqエンジンは列ごとに圧縮を行うため、カーディナリティの高い列（IDや高精度の数値など）が多いとモデルサイズが大きくなりやすい。不要な列を削除し、カーディナリティを管理することがモデル最適化の基本。

正解: A. A. 変数（VAR）を使った中間結果の再利用や、メジャーの式自体の見直し

正解の根拠・詳細解説

変数（VAR）を使って一度計算した中間結果を再利用することで、同じ計算が複数回実行される非効率を避け、パフォーマンスを改善できる。

正解: A. A. フォールバック動作の設定（Direct Lakeの動作設定）

正解の根拠・詳細解説

Direct Lakeモードには、データ読み込みに問題が生じた場合にDirectQueryへフォールバックするかどうかを制御する設定項目があり、要件に応じて有効・無効を選択できる。

正解: A. A. ビジュアルの種類や数を見直し、複雑なカスタムビジュアルや過剰な数のビジュアルを減らす

正解の根拠・詳細解説

クエリ自体は速いがビジュアルの描画（レンダリング）に時間がかかっている場合は、ビジュアルの種類・数・複雑さ（多数のカスタムビジュアルなど）を見直すことが効果的な改善策となる。

正解: A. A. メジャーの命名規則の統一とディスプレイフォルダーによる整理、計算グループによる重複ロジックの削減

正解の根拠・詳細解説

ディスプレイフォルダーでメジャーをカテゴリ別に整理し、命名規則を統一し、さらに計算グループで重複するロジックを集約することで、大規模モデルの保守性を高めることができる。

正解: A. A. SUMXはテーブルの各行に対して式を評価してから合計するのに対し、SUMは単一の列の値をそのまま合計する

正解の根拠・詳細解説

SUMは単一列の値を単純に合計するのに対し、SUMXはテーブルを反復しながら指定した式（複数列の演算を含む）を各行で評価し、その結果を合計するイテレーター関数である。

正解: A. A. 可能な変換処理をデータソース側（SQLサーバー等）にプッシュダウンして実行させることで、データ転送量と処理負荷を減らせる

正解の根拠・詳細解説

クエリフォールディングが有効な場合、Power Queryのフィルタや集計などの変換処理が可能な範囲でデータソース（SQLサーバー等）側のクエリに変換されて実行されるため、Fabric側への無駄なデータ転送や処理負荷を削減できる。

正解: A. A. クエリの実行時間、リフレッシュ時間、メモリ使用量などのメトリクス

正解の根拠・詳細解説

セマンティックモデルの性能問題は、利用者から見るとレポートの応答遅延やデータ更新の失敗として表面化する。その原因を切り分けるには、負荷と資源消費を定量的に表す指標を継続的に記録しておく必要がある。クエリの実行時間はDAXの書き方やモデル設計（リレーションシップの粒度、双方向フィルターの多用など）の影響を受け、リフレッシュ時間はソースからの取り込み量や増分更新の設定状況を反映する。メモリ使用量はインポートモードのモデルがキャパシティの上限に収まっているかを示し、上限に近づくとモデルの退避や更新失敗、キャパシティのスロットリングにつながる。これらを時系列で追うことで、劣化の兆候を利用者からの問い合わせより先に検知でき、増分更新の導入や集計テーブルの追加、キャパシティのスケールアップといった対策を先手で打てる。一方、ワークスペースの作成日、センシティビティラベルの数、エンドースメントの有無は、ガバナンスや情報保護の観点では意味を持つメタデータだが、実行性能とは直接関係しないため監視指標にはならない。