第1回 問題集（全般）

正解: A. A. Spark workspace settings

正解の根拠・詳細解説

Spark ワークスペース設定（Spark settings）は、そのワークスペース内で実行されるすべての Spark ジョブ（ノートブック・Spark ジョブ定義）に共通する実行環境を定義する場所です。①プール：既定のスターター プールを使うか、ノード サイズ（Small/Medium/Large など）と自動スケールの上下限ノード数を指定したカスタム プールを使うかを選択、②ジョブ設定：セッション タイムアウト（アイドル セッションを自動終了するまでの時間）や高コンカレンシー モードの有効化、③環境：既定の Environment（Spark ランタイム バージョンや適用するライブラリ）を指定。誤答の Domain 設定はワークスペースを業務領域にグループ化するガバナンス機能、OneLake 設定はストレージ側の挙動であり、いずれも Spark の計算リソースとは無関係です。実務上、セッション タイムアウトを長く取りすぎるとアイドル セッションが容量（CU）を消費し続けるため、スロットリングの原因になりやすい点に注意します。

正解: A. A. ワークスペースを業務領域・部門単位でグループ化し、ガバナンスを適用しやすくする

正解の根拠・詳細解説

ドメイン（Domain）は、Fabric のテナント全体を「営業」「財務」「製造」といった業務領域・部門単位に区切り、複数のワークスペースをその配下にまとめる論理的なグルーピング機能です。目的は主にガバナンスとデータ メッシュ的な運用にあります。①ドメイン管理者へ権限を委譲し、テナント管理者を経由せずに領域内のガバナンスを回せる、②ドメイン単位で既定の機密ラベルやエンドースメントの方針を適用できる、③OneLake データ ハブでドメインによる絞り込みができ、利用者が目的のデータ資産を発見しやすくなる。誤答にある Spark の計算リソース管理は容量（Capacity）とワークスペース設定の役割、OneLake の保存場所変更はドメインの管轄外です。ドメインはあくまで組織構造を映す論理レイヤーであり、データの物理配置を変えるものではない点を押さえておきましょう。

正解: A. A. ワークスペースのOneLake用リージョンやキャッシュ設定

正解の根拠・詳細解説

OneLake ワークスペース設定は、そのワークスペースが OneLake 上のデータをどう扱うかを構成する場所です。代表的な項目が OneLake のキャッシュ（ショートカット経由で外部ストレージを参照する際に、読み取ったデータをキャッシュして繰り返しアクセスのレイテンシと外部トランザクション コストを下げる機能）の有効/無効です。データの物理的な配置はワークスペースが紐づく容量（Capacity）のリージョンに従うため、OneLake の地理的な所在もワークスペース／容量の単位で決まります。誤答のパスワード ポリシーや条件付きアクセスは Microsoft Entra ID 側のテナント機能、Power BI のライセンス種別は Microsoft 365 管理センターでのライセンス割り当ての話であり、いずれも Fabric ワークスペース設定では構成しません。ID とデータ プレーンの設定は所管が分かれる、という切り分けが重要です。

正解: A. A. Dataflowの実行に使用するステージングの既定動作

正解の根拠・詳細解説

Dataflow Gen2 のワークスペース設定では、そのワークスペースで作成される Dataflow の既定動作、とりわけステージング（staging）の扱いを構成します。Dataflow Gen2 は既定で、取り込んだデータをいったんワークスペース内のステージング用 Lakehouse/Warehouse に書き出し、そこを起点に変換を実行します。これにより Power Query の折りたたみ（query folding）が効かない変換でも SQL エンジン側で処理を押し下げられ、大規模データや複数の出力先へ書き込むケースで有利になります。逆に小規模データや単純なパススルーではステージングが余分な書き込みとなり、かえって遅く、容量（CU）も消費します。誤答の SQL 分析エンドポイントの同期、Git のブランチ保護、Eventhouse の保持期間は、それぞれ Lakehouse・Git プロバイダー・Eventhouse 側で管理する設定であり、Dataflow の設定項目ではありません。

正解: A. A. Git（Azure DevOpsまたはGitHub）

正解の根拠・詳細解説

Fabric のワークスペースは Git 統合をサポートし、接続先として Azure DevOps（Azure Repos）と GitHub を利用できます。ワークスペースを特定のリポジトリとブランチに接続すると、ノートブック、パイプライン、セマンティック モデル、レポートなどの対応アイテムがソース定義としてリポジトリにシリアライズされ、コミット（ワークスペース→Git）と更新（Git→ワークスペース）で双方向に同期できます。これにより変更履歴の追跡、ブランチを切った並行開発、プル リクエストによるレビューが可能になります。誤答の Jira・Slack・Trello は課題管理やチャットのツールであり、ソース管理システムではないため接続先になりません。実務では、開発者ごとに個人用ワークスペースをフィーチャー ブランチへ接続し、マージ後の共有ワークスペースからデプロイ パイプラインで上位ステージへ昇格させる構成がよく採られます。

正解: A. A. ウェアハウスのスキーマ定義をコードとして管理し、デプロイを自動化する

正解の根拠・詳細解説

データベース プロジェクトは、Warehouse（およびミラー化されたデータベースなど）のスキーマ定義を宣言的なコードとして扱う仕組みで、SQL Database Project（SDK スタイルの .sqlproj）と同じ考え方に基づきます。テーブル、ビュー、ストアド プロシージャなどの定義をファイルとしてエクスポートし、Git で版管理したうえで、ビルド成果物を対象データベースへ発行することで、あるべき姿と現状の差分を自動的に反映できます。これにより手作業の DDL 実行に頼らない、再現性のある CI/CD が実現します。誤答のレポート テンプレート保存やノートブック実行履歴の保管はそれぞれ別機能の役割です。実務上は、データベース プロジェクトでスキーマを、デプロイ パイプラインでアイテム全体の昇格を、と役割を分けて併用するのが定石です。

正解: A. A. 開発（Development）→テスト（Test）→本番（Production）

正解の根拠・詳細解説

Fabric のデプロイ パイプラインは、ワークスペースをステージに割り当てて内容を段階的に昇格させる仕組みで、既定では開発（Development）→テスト（Test）→本番（Production）の 3 ステージ構成が用意されています。各ステージにはそれぞれ別のワークスペースを紐づけ、下位ステージから上位ステージへデプロイすることで、検証を経ていない変更が直接本番へ入ることを防ぎます。ステージ数は要件に応じて増減でき、ステージ間で参照先データソースや接続を切り替えたい場合はデプロイメント ルールを設定します。誤答の「設計→実装→廃止」などはソフトウェアやシステムのライフサイクル一般を表す語であって、パイプラインのステージ構成ではありません。実務では、下位ステージほど頻繁に変更が入るため、本番ステージのワークスペースは Admin 権限を絞って直接編集をさせない運用が推奨されます。

正解: A. A. Admin・Member・Contributor・Viewer

正解の根拠・詳細解説

Fabric ワークスペースのアクセス制御は Admin・Member・Contributor・Viewer の 4 ロールで構成され、権限は上位が下位を包含します。①Admin：ワークスペースの削除・更新、ユーザーへのロール割り当てを含むすべての操作、②Member：アイテムの共有と、自分より下位のロール（Contributor/Viewer）の追加が可能、③Contributor：アイテムの作成・編集・削除はできるがワークスペースの権限管理はできない、④Viewer：アイテムの閲覧のみで、レポートの表示やセマンティック モデルの参照はできても編集はできない。誤答の Owner/Editor/Guest は他サービスの用語、Global Admin などは Microsoft Entra ID のディレクトリ ロールであり、ワークスペース ロールとは階層が異なります。実務では、ワークスペース ロールは個人ではなく Entra ID のセキュリティ グループに割り当てると、異動時の棚卸しが容易になります。

正解: A. A. 特定のレポートやセマンティックモデル単位で個別に共有・権限設定する

正解の根拠・詳細解説

アイテムレベルのアクセス制御は、ワークスペース ロールとは独立して、レポート・セマンティック モデル・Lakehouse・Warehouse といった個々のアイテム単位で権限を付与する仕組みです。ワークスペース ロールを与えるとその中のすべてのアイテムに一律の権限が及ぶのに対し、アイテムレベル共有なら「このレポートだけ閲覧させたい」という限定的な公開ができ、最小権限の原則に沿った設計が可能になります。共有相手はワークスペースのメンバーである必要がなく、テナント内の任意のユーザーやグループを指定できます。誤答のテナント管理者権限の付与や Entra ID のグループ管理は、Fabric 管理ポータルや Entra ID 側の管轄です。実務上の注意点として、レポートだけを共有しても背後のセマンティック モデルへの読み取り権限がなければ表示できないため、依存アイテムの権限も併せて確認する必要があります。

正解: A. A. ユーザーの属性に応じて、テーブルの特定の行のみを表示させる

正解の根拠・詳細解説

行レベル セキュリティ（RLS）は、同一のテーブル・同一のレポートを参照させながら、ユーザーの属性に応じて返す「行」を絞り込む仕組みです。Warehouse や SQL 分析エンドポイントではセキュリティ ポリシーと述語関数を定義し、多くの場合 USER_NAME() や現在のユーザー ID をキーに、部門や担当地域のマッピング テーブルと突き合わせて可視行を決定します。セマンティック モデル側でもロールと DAX フィルター式で同等の制御が可能です。これにより「営業部員は自分の担当地域の売上だけを見る」といった要件を、レポートやテーブルを人数分作らずに一つの資産で満たせます。誤答の列の暗号化は列レベル セキュリティや動的データ マスキングの領域であり、RLS が制御するのはあくまで行の可視性です。RLS は参照経路ごとに適用状況が異なり得るため、直接クエリ経路とレポート経路の双方で検証することが重要です。

正解: A. A. 給与額など特定の列だけを一部ユーザーから隠したい

正解の根拠・詳細解説

列レベル セキュリティ（CLS）は、テーブル内の特定の列に対する参照権限を個別に制御する仕組みで、給与額・マイナンバー・原価といった機密性の高い属性だけを一部ユーザーから遮断したいケースに適します。Warehouse では GRANT/DENY を列に対して発行することで実現し、権限のないユーザーがその列を含むクエリを実行するとエラーとなり、結果を取得できません。誤答の「テーブル全体を非表示にしたい」はオブジェクトレベル セキュリティ（OLS）の領域、ワークスペースへのアクセス制限はワークスペース ロールの領域です。似た機能である動的データ マスキングは、列を隠すのではなく値を伏せ字にして返す点が異なり、クエリ自体は成功します。「エラーにして存在ごと拒否したいのか、閲覧はさせつつ値だけ伏せたいのか」で CLS とマスキングを使い分けるのが実務上の判断軸になります。

正解: A. A. 特定のテーブルやカラムといったオブジェクト自体への存在を非表示にする

正解の根拠・詳細解説

オブジェクトレベル セキュリティ（OLS）は、テーブルや列といったオブジェクトそのものを、権限のないユーザーからはメタデータ上も存在しないかのように隠す仕組みです。セマンティック モデルでロールに対して OLS を定義すると、対象ユーザーにはフィールド一覧にそのテーブル／列が表示されず、参照しようとしてもオブジェクトが見つからないものとして扱われます。RLS が「テーブルは見えるが行が絞られる」制御であるのに対し、OLS は「オブジェクトの存在自体を伏せる」制御である点が本質的な違いです。これは、列名や表名それ自体が機密を示唆してしまう場合（例：特定の買収案件を示すテーブル名）に有効です。誤答の行データの値の書き換えは動的データ マスキングに近い挙動、ファイル サイズやネットワーク帯域の制限はセキュリティ機能ではありません。OLS を適用したモデルでは、隠したオブジェクトに依存するビジュアルがエラー表示になり得るため、レポート側の設計と併せて検証します。

正解: A. A. OneLake内のLakehouseのフォルダー構造

正解の根拠・詳細解説

フォルダー／ファイル レベルのアクセス制御は、OneLake 上に置かれた Lakehouse のフォルダー構造（Files 領域や Tables 領域配下のディレクトリ）に対して適用されます。OneLake は Azure Data Lake Storage Gen2 と同じ階層型名前空間と API を提供するため、ディレクトリ単位で権限を与える発想が成り立ち、OneLake のデータ アクセス ロールを用いて特定フォルダーだけを読める役割を定義できます。これにより、同じ Lakehouse の中で bronze 層は限られたエンジニアだけ、gold 層は分析者にも開放する、といった medallion アーキテクチャに沿った段階的な公開が可能になります。誤答の Power BI レポートのページ、Dataflow Gen2 のクエリ エディター、Eventstream のトポロジ図はいずれもファイル システム的な階層を持つ対象ではなく、この種の制御の適用先になりません。

正解: A. A. 権限のないユーザーに対し、実データの一部をマスク表示する

正解の根拠・詳細解説

動的データ マスキング（DDM）は、テーブルに格納された元の値は一切変更せず、クエリ結果を返す時点で権限のないユーザーに対してのみ値を伏せ字化して表示する機能です。列にマスキング規則（既定値、メール アドレス用、ランダム、部分マスク）を定義しておくと、UNMASK 権限を持たないユーザーには a****@example.com のような加工済みの値が返り、権限を持つユーザーには実データが返ります。あくまで表示層での制御であるため、ストレージ上のデータは平文のままで、バックアップやエクスポート経路では保護されない点に注意が必要です。誤答のデータの削除・複製・圧縮形式の変更はいずれもマスキングとは無関係です。実務では、マスクされた列に対する WHERE 句の絞り込みを繰り返すことで値を推測できてしまう場合があるため、機密度が高い列は列レベル セキュリティで参照自体を遮断する方が確実です。

正解: A. A. データの機密度を分類し、取り扱いポリシーを適用する

正解の根拠・詳細解説

機密ラベル（センシティビティ ラベル）は Microsoft Purview Information Protection で定義されるラベルを Fabric のアイテムに適用する機能で、「一般」「社外秘」「極秘」といった機密度の分類と、それに紐づく保護ポリシーの適用を目的とします。Fabric ではラベルが継承・伝播するのが大きな特徴で、Lakehouse やセマンティック モデルに付けたラベルが、そこから作られる下流のレポートや、Excel・PowerPoint などへエクスポートしたファイルにも引き継がれます。エクスポート先のファイルには暗号化や利用権限の制限が適用され、Fabric の外に出た後もデータが保護されます。誤答のバックアップ頻度やクエリ速度の改善は機密ラベルの役割ではありません。実務では、ラベルの自動付与と必須化をテナント設定で組み合わせ、分類漏れのアイテムが下流に広がらないようにするのが定石です。

正解: A. A. 品質が保証された信頼できるアイテムであることを利用者に知らせる

正解の根拠・詳細解説

エンドースメント（推奨/認定）は、組織内に多数存在するアイテムの中から、品質が担保され安心して使えるものを利用者に示すためのラベル付け機能です。Promoted（推奨）はアイテムの作成者や編集権限を持つメンバーが自ら付与でき、「このデータは使える状態にある」という緩やかな推薦を意味します。Certified（認定）はテナント管理者が指定した承認者だけが付与でき、正式なレビューを経た信頼できるデータであることを示します。エンドースされたアイテムは OneLake データ ハブや検索結果でバッジ付きで上位に現れるため、利用者が似た名前の非公式なコピーではなく正規のデータ資産に辿り着けます。誤答の削除防止や所有者変更、アーカイブはエンドースメントの効果ではありません。エンドースはあくまで信頼性の可視化であって、アクセス権限を変更するものではない点に注意してください。

正解: A. A. 誰がいつどのアイテムにどんな操作を行ったかの履歴

正解の根拠・詳細解説

Fabric の監査ログは Microsoft Purview のコンプライアンス ポータル（統合監査ログ）に集約され、「誰が・いつ・どのアイテムに・どの操作を行ったか」というユーザー アクティビティの履歴を記録します。ワークスペースやアイテムの作成・削除、レポートの表示、共有や権限変更、Dataflow の更新といったコントロール プレーンおよびアクセスの操作が対象で、必要に応じて管理 API で抽出し長期保管や SIEM への連携も行えます。重要なのは、記録されるのは操作のメタデータであって、クエリが返したデータの中身そのものではないという点です。誤答にある Spark クラスターの CPU 使用率は容量メトリクス アプリなどの監視機能の領域、パケット キャプチャはネットワーク層の話であり、いずれも監査ログの守備範囲ではありません。監査ログは内部統制の証跡やインシデントの事後調査に用いるものと理解しておきましょう。

正解: A. A. Lakehouse内のデータへのアクセスをロール・フォルダー単位で制御する

正解の根拠・詳細解説

OneLake セキュリティ（OneLake のデータ アクセス ロール）は、Lakehouse 内のデータに対してロールを定義し、そのロールに読み取りを許可するフォルダーやテーブルを指定することで、アイテム全体ではなくデータの一部だけへアクセスを絞り込む仕組みです。ワークスペース ロールでは Lakehouse 全体に一律の権限が及んでしまうのに対し、この仕組みならば同じ Lakehouse の中で公開範囲を階層的に分けられます。さらに、ここで定義した権限は OneLake を経由するアクセス全般に効くため、Spark ノートブックからの読み取りでも SQL 分析エンドポイント経由でも一貫した制御が期待できます。誤答の VM のファイアウォール、DNS レコード、証明書の更新はいずれも Fabric のデータ プレーンとは無関係なインフラ管理の領域です。実務では、bronze/silver/gold の各層に対応するロールを設計し、利用者には gold 層だけを見せる構成がよく採られます。

正解: A. A. ノーコードの変換ならDataflow Gen2、オーケストレーションならパイプライン、複雑なコード処理ならノートブック

正解の根拠・詳細解説

Fabric には変換とオーケストレーションの手段が複数あり、要件で使い分けます。①Dataflow Gen2：Power Query（M）ベースのノーコード／ローコード変換で、GUI でステップを積み上げるためデータ アナリストでも扱いやすく、多様なコネクタから取り込んで Lakehouse や Warehouse へ出力する用途に向きます。②Data pipeline：Copy activity やノートブック実行、Dataflow 実行などのアクティビティを並べ、依存関係・条件分岐・ループ・リトライ・スケジュールを定義するオーケストレーション基盤で、変換ロジックそのものを書く場所ではありません。③Notebook：PySpark や Spark SQL でコードを書くため、複雑なビジネス ロジック、大規模データの分散処理、機械学習との連携に適します。実務では「パイプラインが全体の流れを制御し、その中でノートブックや Dataflow が個々の処理を担う」という組み合わせが最も一般的です。

正解: A. A. スケジュールは時刻指定、イベントベースはファイル到着など特定イベント発生時に実行される

正解の根拠・詳細解説

Fabric のパイプラインやジョブは、スケジュール ベースとイベント ベースの二つの起動方式を持ちます。スケジュール ベースは「毎日 3 時」「1 時間ごと」のように時刻や間隔を指定して定期実行するもので、日次バッチのように処理タイミングが予測できるワークロードに適します。イベント ベースは Fabric の Real-Time Intelligence 基盤（Activator／Data Activator）と連携し、Azure Blob Storage や OneLake へのファイル到着といったイベントを購読して、発生を検知した時点でパイプラインを起動します。これにより、データがいつ来るか分からない不定期な連携でも、無駄なポーリングをせずに到着直後の処理を実現できます。誤答のとおり両者は排他ではなく、日次スケジュールを基本にしつつファイル到着でも起動する、といった併用も可能です。実務では、イベント駆動は同時到着による多重起動が起こり得るため、冪等な処理設計が重要になります。

正解: A. A. 実行時に異なる値（例:対象日付）を渡し、汎用的な処理を実現する

正解の根拠・詳細解説

パラメーターは、処理そのものと処理対象を切り離すための仕組みです。ノートブックではパラメーター セルを指定し、パイプラインのノートブック アクティビティから値を渡すことで、同一のコードを処理対象日・テーブル名・環境名などを変えて再利用できます。これにより、テーブルごとにノートブックを複製するのではなく、テーブル一覧をループで回して一つのノートブックを繰り返し呼び出す、といった構成が可能になり、保守対象が激減します。また、過去日を指定して再実行できるため、障害時のバックフィルや再処理も容易です。誤答のパスワードの暗号化は資格情報の管理機能（接続やキー コンテナー）の役割であり、パラメーターの目的ではありません。実務上の注意点として、パラメーターに接続文字列やシークレットを直接渡すのは避け、機密情報は接続定義や Azure Key Vault 側で管理するのが原則です。

正解: A. A. 実行時の値に応じて動的にアクティビティの設定を変更できる

正解の根拠・詳細解説

動的式（dynamic expressions）は、パイプラインのアクティビティのプロパティを実行時に評価される式として記述する機能です。@pipeline().parameters による実行時パラメーターの参照、@activity('前段の名前').output による直前のアクティビティ出力の参照、@utcnow() や関数を組み合わせた文字列生成などを用いて、コピー先のパス、ファイル名、クエリ条件などを実行のたびに変化させられます。これにより、日付でパーティション分割された出力先へ書き込む、ルックアップで取得したテーブル一覧を ForEach で回す、といった汎用的なメタデータ駆動のパイプラインを構築できます。誤答の UI デザイン変更や認証の省略、課金体系の変更は動的式とは無関係です。実務では、式が複雑化すると可読性とデバッグ性が落ちるため、共通部分はパラメーターや変数に切り出しておくのが定石です。

正解: A. A. 開発→テスト→本番への変更を一貫した手順で安全に反映できる

正解の根拠・詳細解説

デプロイ パイプラインの最大の利点は、開発・テスト・本番の各ワークスペース間で、アイテムを手作業のエクスポート／インポートに頼らず、一貫した手順で昇格させられることにあります。ステージ間の差分比較で何が変わるかを事前に確認でき、選択したアイテムだけを昇格させることも、依存関係を含めて一括で反映することもできます。さらにデプロイメント ルールにより、本番ステージでは参照先のデータソースやパラメーターを本番用へ自動的に差し替えられるため、「テスト用の接続先を向いたまま本番に出てしまう」という典型的な事故を防げます。誤答のストレージ コスト削減やクエリ速度の向上は、デプロイ パイプラインがもたらす効果ではありません。実務では、Git 統合でソースの版管理を、デプロイ パイプラインで環境間の昇格を担わせる二層構成が推奨されます。

正解: A. A. Git統合によるコミット履歴

正解の根拠・詳細解説

変更の追跡という観点で最も直接的に役立つのが Git 統合です。ワークスペースを Azure DevOps または GitHub のリポジトリに接続すると、ノートブックやパイプラインなどのアイテム定義がファイルとしてシリアライズされ、コミット履歴として「誰が・いつ・どの行を・なぜ（コミット メッセージ）」変更したかが残ります。差分表示により変更内容を行単位で確認でき、問題があれば以前のコミットへ戻すことも、ブランチとプル リクエストでレビューを挟むこともできます。誤答の OneLake キャッシュ設定と Spark プールのオートスケールは性能・コストに関わる設定、機密ラベルはデータの分類と保護の機能であり、いずれも変更履歴を記録しません。なお、監査ログも「誰が操作したか」を記録しますが、記録されるのは操作イベントであって変更内容の差分ではないため、開発上の変更追跡には Git が適します。

正解: A. A. 関連するワークスペース群

正解の根拠・詳細解説

ドメインには、業務的な関連性の高いワークスペース群を割り当てます。たとえば「販売」ドメインに受注分析・店舗 KPI・需要予測といったワークスペースをまとめることで、それらに共通のガバナンス方針（既定の機密ラベル、エンドースメントの承認者、データ ハブ上での分類など）をドメイン単位で適用でき、テナント管理者に集中しがちな管理業務をドメイン管理者へ委譲できます。一つのワークスペースが所属できるドメインは一つであるため、組織構造やデータの所有者に沿った切り分けを設計することが重要です。誤答の個々のユーザーのパスワードは Microsoft Entra ID、テナントのライセンス数は Microsoft 365 管理センター、課金の支払い方法は Azure サブスクリプション側で管理する事項であり、ドメインの割り当て対象ではありません。ドメインはデータ メッシュにおける「ドメイン所有」の考え方を Fabric 上で表現する仕組みだと捉えると理解しやすくなります。

正解: A. A. 機密データへの不審なアクセスを事後調査する

正解の根拠・詳細解説

監査ログは「誰が・いつ・どのアイテムに・どんな操作をしたか」というアクティビティの証跡を記録するため、事後調査（フォレンジック）の用途に直結します。たとえば、機密ラベルの付いたセマンティック モデルに対して普段アクセスしないユーザーが短時間に大量の参照を行った、退職予定者がレポートを外部ユーザーに共有した、といった不審な挙動を、操作イベントの記録から時系列で追跡できます。Microsoft Purview のコンプライアンス ポータルで検索できるほか、管理 API 経由で抽出して SIEM に取り込み、アラート ルールを組むことも可能です。誤答のレポート デザインの自動生成や Spark コードの自動修正は監査ログの機能ではなく、通知メールの自動送信も監査ログ単体ではなく別の仕組みとの連携が必要です。監査ログは検知そのものより、記録を残し後から追える状態を作ることに意義がある機能だと理解しましょう。

正解: A. A. 最小権限の原則に基づき、必要な操作のみ許可するロールを割り当てる

正解の根拠・詳細解説

推奨されるのは最小権限の原則（least privilege）に基づく設計です。Fabric のワークスペース ロールは Admin・Member・Contributor・Viewer の 4 種類で権限が段階的に広がるため、レポートを見るだけの利用者には Viewer、アイテムを作る開発者には Contributor、権限管理まで担う責任者だけに Admin、というように業務上必要な最小限のロールを割り当てます。全員に Admin を与えると、誤ってワークスペースやアイテムを削除する事故のリスクが跳ね上がり、監査上も操作者の責任範囲が曖昧になります。逆にロールを使わず個別共有だけで管理すると、権限の付与状況が分散して棚卸しが困難になります。実務では、ユーザー個人ではなく Microsoft Entra ID のセキュリティ グループに対してロールを割り当て、入退社や異動はグループのメンバーシップ変更だけで完結させる運用が定石です。

正解: A. A. ステージ間でアイテムの内容に違いがあるかを確認し、誤反映を防ぐ

正解の根拠・詳細解説

デプロイ パイプラインの差分比較は、隣接するステージのワークスペース間でアイテムの内容が一致しているか、変更があるならどのアイテムかを事前に可視化する機能です。各アイテムには「同一」「異なる」「対象ステージに存在しない」といった状態が表示され、デプロイの前にこれから何が上書きされ何が新規作成されるのかを確認できます。これにより、本番でのみ行われた緊急修正を開発ステージからの一括デプロイで意図せず上書きしてしまう、といった事故を防げます。デプロイ時には差分のあるアイテムだけを選択して部分的に昇格させることも可能です。誤答のストレージ使用量の計算やクエリ実行計画の可視化、ログイン履歴の比較はいずれも別機能の役割です。実務では、差分の内容を確認したうえでデプロイ ノートに残し、変更管理の記録とする運用が有効です。

正解: A. A. データソースに対して直接クエリが実行され、パフォーマンスやリソース消費の特性が変わる

正解の根拠・詳細解説

Dataflow Gen2 は既定でステージングを使用し、ソースから取得したデータをいったんワークスペース内のステージング用ストレージに書き出したうえで、そこを起点に変換と最終出力先への書き込みを行います。ステージングを無効化すると、この中間層を経ずにソースへ直接クエリを発行して処理する形になるため、実行方式そのものが変わります。結果として、中間書き込みが減って軽量なワークロードでは高速化する一方、Power Query の折りたたみが効かない変換では変換処理をエンジンが引き受けられず、データ量が大きい場合にメモリ消費や実行時間が増え、ソース システムへの負荷も高まる可能性があります。誤答のとおり、無効化しても常にエラーになるわけでも、暗号化が解除されるわけでも、Power BI との連携が切れるわけでもありません。実務では、小規模・単純な取り込みでは無効化、大規模や複数出力先では有効のまま、と使い分けます。

正解: A. A. アイテムの作成・編集はできるが、ワークスペースの権限管理はできない

正解の根拠・詳細解説

Contributor は、ワークスペース内でアイテムの作成・編集・削除ができる開発者向けのロールですが、ワークスペースそのものの管理権限は持ちません。具体的には、ノートブックやパイプライン、Lakehouse などのアイテムを自由に作成・更新でき、レポートの発行やデータの更新も行えますが、ワークスペースへのユーザー追加やロール変更、ワークスペースの削除はできません。それらは Admin の権限であり、アイテムの共有や下位ロールの追加は Member の権限に含まれます。誤答のテナント設定の変更に至っては Fabric 管理者（テナント管理者）の領域で、ワークスペース ロールとは階層が異なります。実務では、開発者には Contributor を既定として与え、権限管理を伴う Admin は運用責任者に限定することで、最小権限の原則と作業効率を両立させます。

正解: A. A. 参照元データへのアクセス権限はショートカット元の設定に依存する

正解の根拠・詳細解説

OneLake ショートカットは、他の Lakehouse や Azure Data Lake Storage Gen2、Amazon S3 などにあるデータを、コピーせずに参照だけで自分の Lakehouse に現れるようにする仕組みです。実データは参照先に置かれたままなので、そのデータを実際に読めるかどうかは参照先側の権限設定と、ショートカット作成時に構成した接続の資格情報に依存します。したがって、ショートカットを作っただけでアクセスが自動的に許可されるわけではなく、逆に参照先の権限が広すぎると意図しない範囲まで見えてしまうリスクもあります。誤答のとおり、ショートカットが独自の暗号化キーを持つことも、作成時に元データが複製されることもありません。実務では、外部ストレージへのショートカットは接続に紐づく資格情報の管理が要となるため、誰がその接続を使えるかを含めて設計・棚卸しすることが重要です。

正解: A. A. データの機密度を分類し、それに応じたアクセス制御方針を設計する

正解の根拠・詳細解説

セキュリティと利便性の両立で最初に行うべきは、データの機密度を分類することです。何が機密で何が公開して差し支えないかが定まらないまま制御を設計すると、すべてを一律に厳しくして利活用を阻害するか、逆に一律に緩めて漏えいリスクを抱えるかのどちらかに陥ります。分類が済めば、公開データは広く共有し、社外秘のテーブルには列レベル セキュリティや動的データ マスキング、部門ごとの可視範囲には行レベル セキュリティ、というように、機密度に見合った制御を選択的に適用できます。Fabric では Microsoft Purview の機密ラベルによって分類を実装でき、ラベルが下流のアイテムやエクスポート ファイルに継承されるため、分類が保護に直結します。誤答の全データ公開、監査ログの無効化、ロール管理の放棄はいずれも統制を失わせる誤った選択です。分類、方針設計、実装、監査というサイクルで運用することが基本になります。

正解: A. A. ドメイン内のワークスペースに対するガバナンスポリシーの適用と監督

正解の根拠・詳細解説

ドメイン管理者は、自分が担当するドメインに割り当てられたワークスペース群に対して、ガバナンスの適用と監督を担う役割です。具体的には、ドメインへのワークスペースの割り当てや解除、ドメイン単位での既定の機密ラベルやエンドースメント方針の設定、データ ハブ上でのドメイン表示に関する構成などを行い、テナント管理者に集中しがちな管理業務を業務領域ごとに分担します。これにより、業務内容を最もよく理解している部門側の担当者が、自領域のデータ資産の品質と統制に責任を持つ、というデータ メッシュ的な運用が可能になります。誤答の Spark コードのデバッグやレポートのデザイン作成は開発者・アナリストの作業であり、管理者ロールの職責ではありません。実務では、ドメイン管理者に加えてドメイン共同作成者を置き、ワークスペースの割り当てだけを委譲するといった段階的な権限設計も行われます。

正解: A. A. デプロイメントルール（Deployment rules）

正解の根拠・詳細解説

各ステージで参照先データソースなどを切り替える機能はデプロイメント ルール（Deployment rules）です。デプロイ パイプラインの対象ステージに対して規則を定義しておくと、下位ステージからデプロイした際に、セマンティック モデルのデータソース接続やパラメーターの値が、そのステージ用に設定した値へ自動的に置き換えられます。これにより、開発ワークスペースの内容をそのまま本番へ昇格させても、接続先だけは本番のデータベースを向いた状態になり、「テスト用 DB を参照したまま本番稼働してしまう」という典型的な事故を防げます。誤答のデータ マスキング、機密ラベル、RLS はいずれもデータの保護・可視制御に関する機能で、デプロイ時の構成差し替えとは目的が異なります。実務では、ルールは上位ステージ側に設定し、デプロイのたびに手作業で接続を直す運用をなくすことが重要です。

正解: A. A. ワークスペースメンバー以外の特定ユーザーにも、個別アイテムへのアクセスを許可する

正解の根拠・詳細解説

アイテムレベル共有を使うと、ワークスペースのロールを付与することなく、特定のレポート・セマンティック モデル・Lakehouse などの単一アイテムに限定してアクセスを許可できます。ワークスペースの Viewer ロールを与えるとそのワークスペース内のすべてのアイテムが見えてしまいますが、アイテムレベル共有ならば見せたい一つだけを対象にでき、最小権限の原則に沿います。共有相手はテナント内の任意のユーザーやセキュリティ グループを指定でき、共有時に「基になるデータのビルド権限を付与するか」「再共有を許可するか」といった追加の権限も個別に選べます。誤答のテナント間移行、物理ストレージ容量の変更、課金プランの変更はいずれも共有機能とは無関係です。実務上の落とし穴として、レポートだけを共有しても背後のセマンティック モデルへの権限がなければ表示できないため、依存関係を含めた権限確認が欠かせません。

正解: A. A. 本番運用に必要な十分なリソースを計画的に割り当てる必要があるため

正解の根拠・詳細解説

Fabric capacity（F SKU）はワークスペースに紐づく計算リソースの単位で、そこで実行される Spark ジョブ、Dataflow、SQL クエリ、レポートのレンダリングなどが消費する CU（Capacity Unit）の上限を決めます。したがって、開発・テスト・本番の各ワークスペースをどの容量に配置するかは、ライフサイクル管理の設計に直結します。本番ワークスペースには安定運用に足る容量を計画的に割り当てる必要があり、逆に開発の重い試行錯誤が本番と同じ容量を圧迫すると、スロットリングによって本番のレポートまで遅くなります。このため、本番と非本番で容量を分ける構成が推奨されます。誤答のとおり、容量はセキュリティや課金と無関係ではなく、むしろ課金の基礎であり、性能面の SLA を左右します。実務では容量メトリクス アプリで CU 消費とスロットリングの発生状況を継続的に監視します。

正解: A. A. パイプライン内でアクティビティの実行順序・成功/失敗条件を設定する

正解の根拠・詳細解説

Fabric のオーケストレーションでは、Data pipeline のキャンバス上でアクティビティ同士を線でつなぎ、実行順序と依存条件を明示的に定義します。接続には「成功時（Success）」「失敗時（Failure）」「完了時（Completion）」「スキップ時（Skipped）」の 4 種類があり、これらを使い分けることで、前段が成功したときだけ次へ進む、失敗したときは通知アクティビティを走らせる、といった分岐を表現できます。さらに If Condition や Switch、ForEach、Until といった制御アクティビティを組み合わせれば、条件分岐や反復を含む複雑なフローも構築できます。誤答のとおり、実行順序はワークスペースの作成順やログイン順で決まるものでも、ランダムに決まるものでもありません。実務では、失敗経路を必ず定義して障害を検知できるようにし、各アクティビティにリトライを設定して一時的な障害に耐えるよう設計します。

正解: A. A. Certifiedは管理者など承認された人物のみが付与できる、より公式な認定である

正解の根拠・詳細解説

エンドースメントには Promoted（推奨）と Certified（認定）の 2 段階があり、付与できる人と意味合いが異なります。Promoted はアイテムに対して書き込み権限を持つ作成者やメンバーが自分で付与できる緩やかな推薦で、「共有に値する状態になった」という程度の意味を持ちます。一方 Certified は、テナント管理者が定めた承認者（特定のセキュリティ グループなど）だけが付与でき、組織として正式にレビューし品質を保証したことを示す上位の認定です。つまり Certified の方が権威が強く、誰でも付けられるわけではありません。誤答のとおり両者に違いがないわけでも、Promoted が上位でもありません。実務では、Certified を付与する基準（データ品質の検証、ドキュメントの整備、所有者の明確化など）をあらかじめ社内で定義し、認定プロセスを形骸化させないことが重要です。

正解: A. A. 本番環境のアクセス権限設定とデプロイメントルールの内容

正解の根拠・詳細解説

本番ワークスペースへデプロイする前には、まず本番側のアクセス権限が適切に設定されているか（開発者に不要な Admin が残っていないか、閲覧者に必要な権限が付いているか）と、デプロイメント ルールの内容が正しいかを確認します。特にデプロイメント ルールの設定漏れは重大で、規則が定義されていなければ開発ステージの接続情報がそのまま本番へ持ち込まれ、本番のレポートがテスト用データベースを参照してしまう事故につながります。あわせて、差分比較で何が上書きされるかを確認し、本番でのみ行われた修正を意図せず消してしまわないかも点検すべきです。誤答の開発者の好み、ワークスペースの作成日、UI のテーマ カラーは運用リスクに影響しない項目です。実務では、これらの確認項目をチェックリスト化し、デプロイ前レビューとして定型化しておくのが有効です。

正解: A. A. 公開済みのコンテンツを閲覧する（編集はできない）

正解の根拠・詳細解説

Fabricのワークスペースロールは管理者（Admin）、メンバー（Member）、共同作成者（Contributor）、閲覧者（Viewer）の4種類で、上位のロールほど広い権限を持ちます。Viewerはこの中で最も権限が狭く、ワークスペース内の公開済みコンテンツを閲覧・利用することはできますが、アイテムの新規作成や編集、削除はできません。ワークスペースへのユーザー追加や権限変更は管理者の役割であり、アイテムを作成・編集するには共同作成者以上の権限が、デプロイパイプラインによる昇格にもそれ相応の権限が必要です。実運用では、レポートを参照するだけの業務部門ユーザーにViewerを割り当て、必要に応じて行レベルセキュリティを組み合わせて見えるデータの範囲を絞り込む設計が一般的です。最小権限の原則に沿って、編集の必要がない利用者に共同作成者以上を与えないことが、誤操作や意図しない変更を防ぐうえで重要になります。

正解: A. A. フルロードは毎回全データを取得し、増分ロードは変更分のみ取得する

正解の根拠・詳細解説

フル ロードはソースの全データを毎回取得して対象を洗い替えする方式、増分ロードは前回の処理時点以降に発生した新規・更新（場合により削除）分だけを取得して反映する方式です。増分ロードを実装するには、最終更新日時列や単調増加する ID を用いた高水位マーク（ウォーターマーク）を保持し、次回はその値より新しい行だけを抽出します。Fabric では、パイプラインの Lookup アクティビティで前回値を読み出し、Copy activity のクエリに動的式で埋め込む構成や、ソースが Azure SQL Database ならチェンジ データ キャプチャ、ミラーリングを使う構成が採られます。誤答のとおり、フル ロードが常に高速ということはなく、データ量が小さいうちはむしろ単純で確実です。増分ロードはストリーミング専用でもなく、バッチ処理の代表的な最適化手法です。更新行の反映には Delta Lake の MERGE を使うのが定石です。

正解: A. A. ファクトテーブルとディメンションテーブルに正規化・分割する

正解の根拠・詳細解説

ディメンショナル モデリング（スター スキーマ）では、売上明細のように事象を記録するトランザクション データを数値の指標と外部キーからなるファクト テーブルに、商品・顧客・店舗・日付といった説明属性をディメンション テーブルに整理します。ファクトは行数が多く縦に長い一方でカラム数は少なく、ディメンションは行数が少なくカラムが多い、という非対称な構造になり、BI ツールからの集計クエリが単純な結合で済むため分析性能と可読性が向上します。誤答の「すべてを 1 つのフラットテーブルに統合」は、非正規化の極端な形であり、属性の更新が全行に波及するうえ再利用性を損ないます。実務では、ディメンションの属性変更履歴をどう扱うか（緩やかに変化するディメンション、SCD Type 1/2）と、サロゲート キーの採番方針を設計時に決めておくことが重要です。

正解: A. A. ウィンドウ処理によるリアルタイム集計の単位

正解の根拠・詳細解説

ストリーミング データの処理では、終わりのないデータの流れをどの単位で区切って集計するか、というウィンドウ処理の設計が中核になります。代表的なものに、重ならない固定長で区切るタンブリング ウィンドウ、一定間隔でずらしながら重複を許すホッピング／スライディング ウィンドウ、無操作期間で区切るセッション ウィンドウがあり、求める指標（1 分あたりの件数か、直近 5 分の移動平均か）に応じて選択します。あわせて、イベントの発生時刻（イベント タイム）と到着時刻（処理タイム）のどちらを基準にするか、遅れて到着したイベントをどこまで受け入れるかも決める必要があります。誤答のバッチ スケジュール時刻やファイル圧縮形式はバッチ処理側の関心事、レポートの配色は分析結果の見せ方の話であり、ストリーム処理の設計要素ではありません。

正解: A. A. 非構造化・半構造化データと構造化データを統合的に扱える

正解の根拠・詳細解説

Lakehouse は、データ レイクの柔軟性とデータ ウェアハウスの構造化された分析能力を統合したストアです。OneLake 上に Files 領域と Tables 領域を持ち、Files には CSV・JSON・画像・ログといった非構造化／半構造化のファイルをそのまま置け、Tables には Delta Lake 形式のテーブルとして構造化データを管理できます。取り込んだ生ファイルを Spark ノートブックで変換して Delta テーブル化する、という一連の流れを同じ基盤の中で完結できるのが強みで、medallion アーキテクチャ（bronze/silver/gold）の実装先として自然に適合します。さらに SQL 分析エンドポイントを通じて T-SQL による読み取りクエリも可能です。誤答の「構造化データのみ厳密なスキーマで管理」は Warehouse の性格に近く、OLTP 特化やレポート専用キャッシュという説明も当てはまりません。

正解: A. A. T-SQLによる本格的なリレーショナル分析クエリが必要な場合

正解の根拠・詳細解説

Fabric の Warehouse は、フル機能の T-SQL をサポートするリレーショナル分析基盤で、マルチテーブルにまたがる ACID トランザクション、T-SQL による INSERT/UPDATE/DELETE の書き込み、ストアド プロシージャやビューの利用が可能です。SQL Server の経験を持つエンジニアがそのままのスキルで開発でき、既存の SQL 資産や BI ツールとの親和性も高いため、整形済みデータに対する本格的な分析クエリやサービング層の用途に適します。Lakehouse の SQL 分析エンドポイントは読み取り専用であり、T-SQL による書き込みができない点が大きな違いです。誤答の非構造化ファイルの保存は Lakehouse の Files 領域、リアルタイム イベント処理は Eventstream と Eventhouse、機械学習の学習は Spark ノートブックの領域です。なお、Warehouse のデータも実体は OneLake 上の Delta 形式で保持され、他のエンジンから参照できます。

正解: A. A. データを複製せずに別の場所にあるデータを参照する

正解の根拠・詳細解説

OneLake ショートカットは、実データをコピーせずに、他の場所にあるデータへの参照（ポインタ）を自分の Lakehouse や Warehouse の中に作る機能です。参照先には同一 OneLake 内の別 Lakehouse のテーブルやフォルダーのほか、Azure Data Lake Storage Gen2、Amazon S3、Google Cloud Storage、Dataverse などの外部ストレージも指定できます。コピーを作らないため、ストレージの二重持ちと同期ジョブの運用が不要になり、参照先が更新されれば即座に最新のデータが見える、という「single copy」の考え方を実現します。誤答の暗号化、削除、スキーマの自動生成はショートカットの目的ではありません。実務上の注意点として、アクセスできるかどうかは参照先の権限と接続の資格情報に依存すること、外部ストレージへのショートカットではネットワーク越しの読み取りとなるためキャッシュの活用が性能上重要になることが挙げられます。

正解: A. A. 外部データベースの変更をほぼリアルタイムでOneLakeに反映できる

正解の根拠・詳細解説

ミラーリング（Mirroring）は、Azure SQL Database、Azure Cosmos DB、Snowflake などの外部データベースの変更をほぼリアルタイムで OneLake に複製し、Delta 形式のテーブルとして分析できるようにする機能です。内部的には変更データ キャプチャの仕組みで差分を継続的に取り込むため、利用者が ETL パイプラインを組んだりスケジュールを管理したりする必要がなく、初期構成後は自動で同期が維持されます。複製先は読み取り用であり、ソース側の運用系ワークロードに分析クエリの負荷をかけずに済む点も利点です。誤答の暗号化、実行計画の最適化、ユーザー権限の一元管理はミラーリングの提供価値ではありません。実務では、ソース DB を直接コピーする従来型の日次バッチを置き換える手段として検討され、ミラー化されたテーブルにショートカットを張って Lakehouse の medallion 層と組み合わせる構成が採られます。

正解: A. A. Copy data アクティビティ

正解の根拠・詳細解説

Data pipeline におけるデータ取り込みの基本要素が Copy data アクティビティです。ソースとシンクの組み合わせを指定するだけで、オンプレミスや各種クラウドのデータベース、REST API、ファイル ストレージなど多様なコネクタから Lakehouse や Warehouse へ大量データを効率的に転送でき、内部的には並列コピーやステージング経由の一括読み込みによってスループットを確保します。マッピングやフォールト トレランス（不正行のスキップ）、増分抽出のためのクエリ指定にも対応します。誤答に挙がっている「レポート公開」「ユーザー作成」「課金確認」といったアクティビティは存在せず、パイプラインで扱えるのは Copy data、Notebook、Dataflow、Stored procedure、Lookup、ForEach、If Condition などのデータ処理・制御系アクティビティです。Copy data はあくまで転送に特化しており、複雑な変換はノートブックや Dataflow に任せるのが設計上の定石です。

正解: A. A. 大規模データに対する分散処理での複雑な変換ロジック

正解の根拠・詳細解説

PySpark は Spark の分散処理エンジンを Python から扱う API で、データを複数のエグゼキューターに分割して並列処理するため、単一マシンのメモリに収まらない大規模データセットに対する複雑な変換に適しています。DataFrame API による結合・集計・ウィンドウ関数に加え、UDF による独自ロジックの適用、機械学習ライブラリとの連携も可能で、GUI ツールでは表現しきれない条件分岐や再帰的な処理も記述できます。Fabric では Lakehouse に紐づけたノートブックから直接 Delta テーブルを読み書きでき、MERGE による更新反映も行えます。誤答のとおり、小規模データの単純な四則演算に PySpark を使うのは、Spark セッションの起動オーバーヘッドと容量（CU）消費に見合わず、Dataflow Gen2 や T-SQL の方が効率的です。処理の規模と複雑さに応じてツールを選ぶ判断が問われます。

正解: A. A. Warehouse内でリレーショナルなSQLベースの変換を行いたい場合

正解の根拠・詳細解説

T-SQL による変換は、Fabric の Warehouse でデータが既にリレーショナルなテーブルとして整形されている場合に最も効果を発揮します。CREATE TABLE AS SELECT やストアド プロシージャ、MERGE などを用いた集計・結合・非正規化を、SQL Server の経験がそのまま活かせる構文で記述でき、既存の SQL 資産や SQL に習熟したチームとの親和性が高いのが利点です。Warehouse ではマルチテーブルのトランザクションもサポートされるため、複数テーブルの一括更新を整合性を保って行えます。誤答の非構造化ファイルの処理は Spark ノートブック、リアルタイム ストリームの処理は Eventstream や KQL、機械学習の学習は Spark と ML ライブラリの領域です。なお、Lakehouse の SQL 分析エンドポイントでも T-SQL は使えますが読み取り専用であり、T-SQL で書き込む変換を行いたい場合は Warehouse を選択する必要があります。

正解: A. A. Real-Time Intelligenceにおけるログ・イベントデータの分析

正解の根拠・詳細解説

KQL（Kusto Query Language）は、Fabric の Real-Time Intelligence における Eventhouse／KQL データベースで使われるクエリ言語で、ログ・テレメトリ・時系列データの高速な探索と分析に最適化されています。パイプ演算子でテーブルを順に絞り込み変換していく読み書きしやすい構文を持ち、summarize による時間ビン単位の集計、時系列専用の演算子、全文検索やパターン抽出などを簡潔に表現できます。列指向で圧縮された取り込み構造と時間ベースのインデックスにより、大量のイベントに対しても短時間で応答するのが特徴です。誤答のリレーショナル結合処理全般は T-SQL が主戦場であり、レポートのデザインや Spark プールのスケーリング設定は KQL とは無関係です。実務では、Eventstream で取り込んだイベントを Eventhouse に着地させ、KQL クエリセットで分析し、Activator でしきい値超過時にアラートを出す、という流れがよく使われます。

正解: A. A. 結合（JOIN）処理を減らし、クエリパフォーマンスを向上させる

正解の根拠・詳細解説

非正規化は、正規化によって分割されたテーブルをあらかじめ結合しフラットな形にまとめることで、クエリ実行時の JOIN 回数を減らし参照性能を高める手法です。分析ワークロードでは同じ結合が繰り返し実行されるため、その結果を事前に materialize しておくことで応答時間を安定させられます。スター スキーマにおけるディメンションが階層を畳み込んだ形（スノーフレークではなくスター）を取るのも、この考え方に基づきます。誤答のとおり、非正規化は重複を排除するのではなく、むしろ属性値の重複を意図的に許容する手法であり、その結果ストレージ使用量は増えることが多く、更新時に同じ値を複数箇所で直す必要が生じる（更新異常）というトレードオフを伴います。セキュリティの強化とも無関係です。書き込みが多い OLTP では正規化、読み取り中心の分析層では非正規化、という使い分けが基本です。

正解: A. A. 日次の売上データを月次合計に変換する

正解の根拠・詳細解説

集約（Aggregate）は、細かい粒度のデータを SUM・AVG・COUNT・MIN／MAX などの集計関数でより粗い粒度にまとめる処理を指します。日次の売上明細を月次合計に変換する、というのはまさにこの典型で、行数が大幅に減るためレポートの応答が速くなり、利用者が求める意思決定の粒度にも合致します。medallion アーキテクチャでは、silver 層のクレンジング済み明細データから、用途別に集約した gold 層のテーブルを作るのが定番の流れです。誤答のレコードの複製、カラム名の変更、ファイル形式の変換はいずれも集約ではなく、それぞれ複製・リネーム・フォーマット変換にすぎません。実務上の注意点として、集約テーブルだけを残して明細を捨ててしまうと後からドリルダウンや再集計ができなくなるため、明細層を保持したうえで集約層を派生させる設計が推奨されます。

正解: A. A. 一意キーに基づいて重複レコードを検出し除去する

正解の根拠・詳細解説

重複データの処理では、まず何をもって同一レコードとみなすかというビジネス キー（主キーや複合的な一意キー）を定義し、それに基づいて重複を検出したうえで除去または統合します。Spark であれば dropDuplicates や、ウィンドウ関数の row_number() でキーごとに最新のレコードだけを残す方法が一般的で、Delta Lake の MERGE を使えばキー一致時は更新、不一致時は挿入という upsert によって重複の発生自体を防げます。重複が生じる典型的な原因は、パイプラインのリトライによる二重取り込みや、ソース側の再送であるため、処理を冪等に設計することが根本的な対策になります。誤答のとおり、全レコードの複製や重複の放置は問題を悪化させ、カラム名の変更は無関係です。どのレコードを残すか（最新の更新日時か、最初に到着したものか）の判断基準を業務要件として明確にしておくことが重要です。

正解: A. A. 既定値での補完、除外、または前後の値からの補間

正解の根拠・詳細解説

欠損データへの対処は一つではなく、業務要件とデータの意味に応じて選択します。①既定値での補完：数値なら 0、区分値なら「不明」といった値で埋め、集計時にエラーを起こさないようにする、②除外：欠損があると分析が成り立たない必須項目については、その行を除外するか別のエラー テーブルへ隔離する、③補間：時系列データであれば前方フィル・後方フィルや線形補間で前後の値から推定する。重要なのは、欠損が「値が本当に存在しない」のか「取得に失敗した」のかで意味が異なる点で、後者を 0 で埋めると集計値を誤らせます。誤答のとおり、常にエラーで停止するのはバッチ運用として現実的でなく、常に無視するのも品質を損ないます。実務では、欠損率をデータ品質のメトリクスとして監視し、しきい値を超えたら上流に問題があるとみなして検知する仕組みを併せて用意します。

正解: A. A. ウォーターマークやウィンドウの遅延許容設定を用いて再集計を可能にする

正解の根拠・詳細解説

遅延到着データとは、ネットワークの遅延やデバイスの一時的な切断などにより、イベントの発生時刻から大きく遅れて到着するレコードを指します。イベント タイム基準で集計している場合、既に確定させたウィンドウに属するデータが後から届くため、ウォーターマークによって「この時刻より前のイベントはもう来ないとみなす」境界を定め、それまでの遅延は許容してウィンドウの状態を保持し、到着時点で再集計する設計が採られます。ウォーターマークを長く取れば取りこぼしは減りますが、保持すべき状態が増えてメモリ消費が膨らむというトレードオフがあります。誤答のとおり、遅延データを常に破棄するのは集計値の欠落を招き、別スキーマでの管理も一般的な解ではありません。実務では、ストリーム側は近似値を素早く出し、後続のバッチ処理で確定値に補正する（ラムダ的な）構成も広く使われます。

正解: A. A. ストリーミングデータソースを取り込み、変換してさまざまな宛先にルーティングする

正解の根拠・詳細解説

Eventstream は Fabric の Real-Time Intelligence における取り込みとルーティングの中核で、Azure Event Hubs、IoT Hub、Kafka、CDC ソース、カスタム アプリなどからのストリーミング データをノーコードのキャンバス上で受け取り、フィルター・集計・結合・列の管理といった変換を適用したうえで、Eventhouse（KQL データベース）、Lakehouse、Activator、カスタム エンドポイントなど複数の宛先へ同時にルーティングできます。一つのストリームを分岐させ、生データは Lakehouse に長期保管しつつ、集計結果は Eventhouse でリアルタイム分析する、といった構成をコードなしで組めるのが利点です。誤答の静的 CSV のバッチ処理は Data pipeline や Dataflow の領域、レポートのスケジュール管理や権限設定は無関係です。実務では、まず Eventstream で着地させてから、分析要件に応じて下流の処理を足していく設計が扱いやすいです。

正解: A. A. コードベースで複雑なストリーミング変換ロジックを実装したい場合

正解の根拠・詳細解説

Spark Structured Streaming は、ノートブック上で PySpark や Scala を用いてストリーム処理を記述する方式で、バッチと同じ DataFrame API でストリームを扱える点が特徴です。ノーコードの Eventstream では表現しきれない複雑な変換、たとえば外部の参照データとの結合による動的なエンリッチメント、独自のビジネス ロジックを含む状態管理、機械学習モデルを用いたリアルタイム スコアリングなどをコードで自由に実装できます。Delta Lake と組み合わせれば、チェックポイントによる正確な再開と、書き込み先テーブルの ACID 保証も得られます。誤答の静的テーブルの単純な参照にストリーミングは不要であり、ノーコードで完結させたい場合はむしろ Eventstream が適します。実務では、要件が単純なうちは Eventstream、ロジックが込み入ってきたら Structured Streaming、という順で選択するのが現実的です。

正解: A. A. 高速な時系列ログ分析とアラート検知

正解の根拠・詳細解説

KQL と Eventhouse を用いた Real-Time Intelligence は、高速な取り込みと低レイテンシのクエリを両立する設計になっており、大量のログ・テレメトリを取り込みながら、直近のデータに対して秒単位で分析結果を返せます。時系列専用の演算子や時間ビンによる集計、異常検知・予測の関数が言語に組み込まれているため、エラー率の急増やしきい値超過といった条件を簡潔に表現でき、Activator と組み合わせれば条件成立時に通知やパイプライン起動といったアクションへつなげられます。誤答の長期保存された静的レポートの作成であれば Warehouse やセマンティック モデルの方が適し、Power Apps のフォーム作成や Power Automate のフロー設計は Fabric の分析機能とは別領域です。実務では、Eventhouse に保持期間ポリシーを設定してホットな期間だけを高速層に置き、古いデータは OneLake 側に逃がすコスト設計が重要になります。

正解: A. A. 一定時間範囲ごとにストリームデータを集計する

正解の根拠・詳細解説

ウィンドウイング関数は、終わりのないストリームを一定の時間範囲や条件で区切り、その範囲ごとに集計を行うための仕組みです。主な種類として、①タンブリング ウィンドウ：重複せず隙間もない固定長の区間（例：1 分ごとの件数）、②ホッピング ウィンドウ：固定長の区間を一定間隔でずらすため区間同士が重なる、③スライディング ウィンドウ：イベントの発生を起点に直近の一定期間を対象とする、④セッション ウィンドウ：一定時間イベントが途切れたところで区切る、があり、求める指標の性質に応じて選択します。誤答の列名変更、ファイル圧縮、ユーザー認証はいずれも集計とは無関係です。実務では、ウィンドウの基準をイベント発生時刻（イベント タイム）にするか到着時刻にするかで結果が変わるため、遅延到着への対応（ウォーターマーク）と併せて設計する必要があります。

正解: A. A. クエリアクセラレーションはショートカット参照先データへのアクセスを高速化できる機能

正解の根拠・詳細解説

OneLake ショートカットは実データを複製せず参照するため、参照先が外部ストレージの場合はネットワーク越しの読み取りとなり、繰り返しアクセスするとレイテンシとトランザクション コストが積み上がります。これを緩和するのがクエリ アクセラレーション（およびキャッシュ）で、ショートカット経由で読み取ったデータをキャッシュ層に保持したり、参照先データに対してインデックス化された高速なクエリ経路を提供したりすることで、参照先を変えずにアクセスを高速化します。つまり両者は無関係でも排他でもなく、ショートカットの弱点である読み取り性能を補完する組み合わせです。誤答のとおり、クエリ アクセラレーションはセキュリティ機能ではなく（アクセス制御は参照先の権限と接続の資格情報に依存します）、ショートカットが常にクエリを遅くするわけでもありません。設計上は、頻繁に参照するホットなデータほど高速化の効果が大きくなります。

正解: A. A. 既存のADLS上のデータをコピーせずそのまま分析対象にしたい場合

正解の根拠・詳細解説

Azure Data Lake Storage Gen2 に既に大量のデータが蓄積されており、それをそのまま Fabric の分析対象にしたい、というケースがショートカットの典型的な適用場面です。データを Fabric 側へコピーすると、ストレージを二重に持つコストに加え、コピー ジョブの実行と失敗時の再実行、両者の乖離をどう検知するかといった同期の運用負担が発生します。ショートカットならば参照だけで済むため、単一の実体を保ったまま（single copy）Spark ノートブックからも SQL 分析エンドポイントからも参照でき、上流の更新も即座に反映されます。誤答のとおり、常に Fabric 内へ複製したい場合はショートカットではなく Copy activity やミラーリングを選ぶことになり、ストリーミング専用の機能でもありません。実務では、外部参照は権限が参照先に依存する点と、読み取り性能をキャッシュで補う点を設計時に確認します。

正解: A. A. ノーコード/ローコードのGUIで変換ロジックを構築したい場合

正解の根拠・詳細解説

Dataflow Gen2 は Power Query（M 言語）を基盤としたノーコード／ローコードの変換ツールで、GUI 上で列の分割・型変換・結合・グループ化といったステップを積み上げるだけで変換ロジックを構築でき、各ステップのプレビューを見ながら試行錯誤できます。コードを書かずに済むため、データ アナリストや Excel/Power BI の経験者がそのまま扱える点が最大の選定理由です。豊富なコネクタで多様なソースから取り込み、Lakehouse や Warehouse へ出力先を指定できます。誤答のとおり、大規模データの分散処理をコードで細かく制御したい場合は Spark ノートブック（PySpark）が適し、ストリーミング処理は Eventstream や Structured Streaming の領域、権限管理はそもそも変換ツールの役割ではありません。実務では、変換ロジックが複雑化して M の可読性が落ちてきたらノートブックへ移行する、という判断がしばしば行われます。

正解: A. A. ForEachアクティビティなどで複数ソースを反復処理する

正解の根拠・詳細解説

複数のソース（多数のテーブルやファイル）を同じロジックで取り込む場合、ソースごとにアクティビティを並べるのではなく、メタデータ駆動の設計にするのが定石です。まず Lookup アクティビティで対象一覧（テーブル名、抽出条件、出力先などを記した構成テーブルやファイル）を取得し、その配列を ForEach アクティビティに渡して反復し、内部の Copy data アクティビティのプロパティを動的式でパラメーター化します。こうすればソースが増えても構成テーブルに 1 行足すだけで済み、パイプライン本体の改修が不要になります。誤答のとおり、すべてを 1 アクティビティで処理することはできず、ソースごとにワークスペースを作る必要もありません。実務では、ForEach の並列実行数（batch count）が高すぎるとソース側や容量に負荷が集中するため、適切に制限をかけることが重要です。

正解: A. A. ACIDトランザクションとタイムトラベル機能をサポートする

正解の根拠・詳細解説

Delta Lake は Parquet ファイル群に加えてトランザクション ログ（_delta_log）を持つオープンなテーブル形式で、Fabric の Lakehouse テーブルおよび Warehouse の実体として採用されています。ログに操作の履歴を追記していく構造により、①ACID トランザクション：書き込みの途中結果が読み手に見えず、失敗時も中途半端な状態が残らない、②タイムトラベル：過去のバージョン番号やタイムスタンプを指定して以前の状態を参照・復元できる、③スキーマ エボリューション：列の追加などスキーマ変更を制御しながら許容できる、④MERGE による upsert や DELETE といった更新操作、が可能になります。誤答のとおり CSV 固定でも、スキーマ変更を一切許さないわけでも、圧縮を持たないわけでもありません（Parquet ベースで列指向圧縮が効きます）。誤って上書きしたテーブルをタイムトラベルで復旧できる点は、実務で頻繁に助けられる特性です。

正解: A. A. ビジネス要件として許容できるデータの遅延（レイテンシ）

正解の根拠・詳細解説

バッチ処理とリアルタイム処理の選択基準は、第一にビジネス側が許容できるデータの鮮度・遅延（レイテンシ）です。翌朝までに前日分が揃っていればよい経営レポートであれば日次バッチで十分ですが、不正取引の検知や設備異常のアラートのように数秒以内の反応が価値を生む用途では、Eventstream と Eventhouse によるリアルタイム処理が必要になります。あわせて、データの到着パターン（定期的か不定期か）、処理の複雑さ、そしてコストも判断材料になります。リアルタイム基盤は常時稼働するため容量（CU）の消費が継続し、要件がないのに採用すると運用負担と費用が増えるからです。誤答のファイル形式やユーザー数、ワークスペース名は選択基準になりません。実務では「そのデータが 1 時間遅れたら誰がどう困るか」を業務側に確認することが、適切な設計への近道です。

正解: A. A. フィルタリング・集約・データの加工（変換）

正解の根拠・詳細解説

Eventstream はノーコードのストリーム処理エンジンとして、取り込みと宛先への配信の間にイベント プロセッサーを挟み、キャンバス上で変換を定義できます。利用できる代表的な処理には、条件に合致するイベントだけを通すフィルター、時間ウィンドウ単位の集約、参照データとの結合（Join）、列の追加・削除・リネームといったフィールドの管理、値の展開（Expand）などがあり、これらを組み合わせて宛先ごとに異なる形へ整形できます。誤答のレポートのデザイン編集、ライセンス割り当て、課金プランの変更はいずれもストリーム処理とは無関係の管理機能です。実務では、生データはそのまま Lakehouse に長期保管しつつ、フィルター・集約したストリームを Eventhouse や Activator へ流すという分岐構成を組むことで、監査用の原本と分析用の軽量データを同時に得られます。

正解: A. A. SQL analytics endpoint（SQLエンドポイント）

正解の根拠・詳細解説

Lakehouse を作成すると SQL 分析エンドポイント（SQL analytics endpoint）が自動的に生成され、Tables 領域の Delta テーブルに対して T-SQL でクエリを実行できます。これにより、Spark を知らない SQL 中心の分析者や、SQL 接続しかサポートしない BI／レポーティング ツールからも、同じデータをコピーせずに参照できます。重要な制約として、このエンドポイントは読み取り専用であり、T-SQL による INSERT/UPDATE/DELETE はできません（ビューやストアド プロシージャの作成は可能です）。T-SQL で書き込みたい場合は Warehouse を使う必要があります。また、Spark 側でテーブルを書き換えた直後は、エンドポイントのメタデータ同期に若干の遅れが生じ得る点も実務上の注意点です。誤答の Power Automate コネクタ、Eventstream トポロジ、OneLake セキュリティ ポリシーは、いずれも T-SQL クエリの実行手段ではありません。

正解: A. A. 並列処理の効率を高め、クエリ性能を向上させる

正解の根拠・詳細解説

パーティショニングは、テーブルのデータを日付や地域などの列の値ごとに別のディレクトリへ分割して格納する設計です。適切に設計すると、クエリの WHERE 句がパーティション列を条件に含むときにパーティション プルーニングが働き、関係のないディレクトリを一切読まずに済むため、スキャン量が劇的に減って性能が向上します。また、Spark は分割された単位で並列に処理するため、タスクを複数のエグゼキューターへ均等に割り当てやすくなります。誤答のとおり、パーティショニングはデータ量そのものを減らすわけでも、セキュリティを強化するものでもありません。実務上最大の落とし穴は過剰なパーティショニングで、粒度を細かくしすぎると小さなファイルが大量に生成され（small file problem）、メタデータの処理負荷でかえって遅くなります。Delta Lake では OPTIMIZE によるファイル結合や V-Order／Z-Order と併せて最適化するのが定石です。

正解: A. A. 同じパイプラインを異なる対象（テーブル名・日付など）に再利用できる

正解の根拠・詳細解説

パイプラインにパラメーターを設けると、処理ロジックと処理対象を分離でき、同じパイプラインをテーブル名・対象日付・環境名などの入力値を変えて再利用できます。これにより、対象が増えるたびにパイプラインを複製する必要がなくなり、ロジックの修正も 1 か所で済むため保守性が大きく向上します。さらに、パラメーターに過去日を渡して再実行すればバックフィルや障害時の再処理が容易になり、ForEach と組み合わせればメタデータ駆動で多数のテーブルを 1 本のパイプラインで処理できます。誤答のとおり、パラメーターは見た目を変えるものではなく、1 つしか設定できないという制約もありません。実務上の注意点として、接続文字列やシークレットをパラメーターで平文のまま渡すのは避け、機密情報は接続定義や Azure Key Vault 側で管理する必要があります。

正解: A. A. スキーマの統一とデータ型の整合性

正解の根拠・詳細解説

CSV・JSON・Parquet など異なる形式のデータを統合する際に最も重要なのは、スキーマの統一とデータ型の整合性です。CSV は型情報を持たずすべて文字列として読まれがちで、JSON は入れ子構造やレコードごとに異なるフィールドを持ち得る一方、Parquet はスキーマと型を内包します。これらをそのまま結合すると、同じ意味の列が別名になっていたり、日付が文字列と日付型で混在したり、数値の精度が食い違ったりして、集計結果の誤りや実行時エラーを招きます。したがって、取り込み時に列名の正規化、明示的な型キャスト、日付やタイムゾーンの表現の統一、JSON のフラット化を行い、共通のスキーマへ寄せる処理を挟みます。誤答のファイル名の長さやフォルダーの色、レポートのテーマは統合の可否に影響しません。medallion アーキテクチャでは、この統一を silver 層で行うのが定石です。

正解: A. A. Azure SQL DatabaseやCosmos DBなどの運用データベース

正解の根拠・詳細解説

ミラーリングの対象となるのは、変更を継続的に捕捉できる運用系のデータベースです。Fabric では Azure SQL Database、Azure SQL Managed Instance、Azure Cosmos DB、Azure Database for PostgreSQL、Snowflake などがミラー化の対象としてサポートされ、ソース側の挿入・更新・削除がほぼリアルタイムに OneLake へ Delta 形式で複製されます。これが成り立つのは、これらのシステムが変更データ キャプチャに相当する仕組みを備えているためです。誤答の PDF、メール本文、音声ファイルは非構造化のコンテンツであり、行単位の変更を追跡する対象ではないため、ミラーリングではなく Lakehouse の Files 領域へのファイル取り込みやショートカットで扱います。実務上の利点は、分析側のクエリ負荷を運用 DB にかけずに済むこと、そして自前の ETL パイプラインとスケジュール管理が不要になることです。

正解: A. A. where演算子による時間範囲指定

正解の根拠・詳細解説

KQL では、時系列データの絞り込みに where 演算子を用い、TimeGenerated や Timestamp といった時刻列に対して範囲条件を指定するのが基本形です。ago() や now()、datetime リテラルと組み合わせて直近の期間を表現し、テーブル名に続けてパイプでつなぐ形で記述します。Eventhouse は時間ベースのパーティション（エクステント）でデータを保持しているため、時刻での絞り込みを先頭に置くと読むべき範囲が限定され、応答が大きく速くなります。その後 summarize で時間ビンごとに集計し、必要に応じて order by や render で可視化する、というのが典型的な流れです。誤答の「SELECT * のみ」は SQL の構文であって KQL の書き方ではなく、KQL は join も集計（summarize）も当然サポートしているため、それらを禁止するという記述も誤りです。実務では、時間フィルターを最初に書くことがコストと性能の両面で効きます。

正解: A. A. データ型の検証・異常値の検出・整合性チェック

正解の根拠・詳細解説

変換ステップに組み込むべき品質チェックには、①データ型の検証：文字列として入ってきた値が想定どおり数値や日付に変換できるか、変換できない行をどう扱うか、②異常値・範囲の検出：数量が負になっていないか、日付が未来になっていないか、統計的な外れ値がないか、③整合性チェック：主キーの一意性、ディメンションとの参照整合性（存在しない顧客 ID を含む明細がないか）、必須項目の欠損率、があります。これらを検出したうえで、除外・隔離（quarantine テーブルへ退避）・既定値での補完のいずれを適用するかを業務要件に沿って決めます。誤答のレポートのデザイン変更、認証設定、課金確認はデータ品質管理ではありません。実務では、medallion アーキテクチャの bronze から silver への変換時にこれらの検証を集中させ、品質メトリクスを記録して継続的に監視する構成が推奨されます。

正解: A. A. 1つの統合ストアでリアルタイムデータと履歴データを横断分析できる

正解の根拠・詳細解説

Lakehouse をストリーミングとバッチの共通の着地点にすると、リアルタイムに流れ込むイベントと、過去から蓄積された履歴データを同じ OneLake 上のテーブルとして横断的に分析できます。Delta Lake が ACID トランザクションを保証するため、ストリーミングの書き込みとバッチの読み取り・書き込みが同時に走っても整合性が崩れず、「直近 1 時間の実測値を過去 3 年の同時期と比較する」といった分析を、二つの基盤をまたぐ複雑な結合なしに実現できます。データを一箇所に集約することで、権限設計やガバナンス、スキーマ管理も一元化できます。誤答のとおり、処理速度が必ず倍になるわけでも、ストレージ コストがゼロになるわけでも、セキュリティ設定が不要になるわけでもありません。実務では、ストリーミング書き込みが生む小さなファイルが増えるため、OPTIMIZE による定期的なコンパクションが必要になります。

正解: A. A. スキーマの自動検出・マッピングの仕組みを取り込みパイプラインに組み込む

正解の根拠・詳細解説

スキーマ ドリフトとは、ソース側で列が追加・削除・改名されたり、データ型が変わったりして、取り込み処理が前提としていたスキーマとずれる現象です。これを放置すると、パイプラインが実行時エラーで停止するか、新しい列が黙って取り込まれず気づかないうちにデータが欠落します。対策としては、Copy activity のスキーマ マッピングを固定せず動的に扱う、Delta Lake のスキーマ エボリューション（mergeSchema）で新規列の追加を許容する、取り込み時にソースのスキーマを検出して期待値と突き合わせ、差分を検出したら通知する、といった仕組みをパイプラインに組み込みます。誤答のとおり、変更を常に無視するのはデータ欠落を招き、完全手動化や「発生しない前提」は現実の運用に耐えません。実務では、列の追加は自動許容、型変更や削除は人間の確認を挟む、という段階的な方針がよく採られます。

正解: A. A. 並列化と分割（パーティション単位の並列コピー）で処理時間を短縮する

正解の根拠・詳細解説

履歴データの初回ロード（historical load）は数億〜数十億行に及ぶことがあり、単純に一括で流すと実行時間が長引くだけでなく、途中で失敗したときに最初からやり直しになるリスクがあります。そこで、日付範囲や主キーの範囲などでソース データを論理的に分割し、パーティション単位で並列にコピーする戦略が一般的です。Fabric では、対象範囲の一覧を Lookup で取得し ForEach で並列度を制御しながら Copy data を繰り返す構成や、Copy activity 自体の並列コピー設定を用いる方法があります。分割しておけば、失敗したパーティションだけを再実行でき、冪等性も確保しやすくなります。誤答のとおり、単一スレッド固定は非効率で、初回ロードを省略することも、ストリーミングだけで履歴を投入することも現実的ではありません。実務では、ソース DB への負荷と Fabric 容量の消費を見ながら並列度を調整することが要点です。

正解: A. A. データの種類（時系列/リレーショナル/大規模分散）と処理要件に応じて選択する

正解の根拠・詳細解説

Fabric には複数の処理言語があり、データの性質と処理要件で使い分けます。①KQL：Eventhouse に取り込まれたログ・テレメトリなど時系列データの高速な探索、時間ビン集計、異常検知に最適、②T-SQL：Warehouse や SQL 分析エンドポイントで、整形済みのリレーショナル データに対する結合・集計・サービング層の構築に適し、既存の SQL スキルと BI ツールの資産を活かせる、③PySpark：Lakehouse のノートブックで、非構造化・半構造化データの処理、単一マシンに収まらない大規模データの分散変換、機械学習との連携など、コードによる柔軟性が必要な場面に適する。誤答のとおり、どれか一つに統一すべきという原則はなく、選択に基準がないわけでもありません。実務では同一のプロジェクト内でも層ごとに言語が異なるのが普通で、bronze への取り込みは Spark、gold のサービングは T-SQL、といった併用が一般的です。

正解: A. A. 増分（Incremental）パターン

正解の根拠・詳細解説

処理対象を前回実行時点以降の変更分に限定する設計は増分（Incremental）パターンと呼ばれます。実装には、①高水位マーク（ウォーターマーク）方式：最終更新日時列や単調増加する ID の前回値を管理テーブルに保持し、次回はそれより大きい行だけを抽出する、②変更データ キャプチャ（CDC）方式：ソース DB が持つ変更ログを利用して、挿入・更新・削除を含む差分を正確に取得する、があります。取得した差分は Delta Lake の MERGE で upsert して反映するのが一般的です。フル パターンと比べ、転送量・処理時間・ソースへの負荷を大幅に削減できる一方、削除の検知が漏れやすい、ウォーターマークの更新タイミングを誤ると取りこぼしや重複が生じる、といった実装上の難しさがあります。処理を冪等に設計し、必要に応じて定期的なフル リロードで整合性を突き合わせる運用が推奨されます。

正解: A. A. 不要な全件再取得を避け、増分ロードや適切なスケジュール頻度を設計する

正解の根拠・詳細解説

Fabricの課金は容量（Capacity）単位のCU消費に基づくため、取り込みパイプラインの設計はそのままコストに直結します。まず見直すべきは全件取得か増分取得かで、更新日時などのウォーターマーク列や変更データキャプチャを使って前回以降に変化した行だけを取り込めば、読み取り量・書き込み量・実行時間のすべてを削減できます。次にスケジュール頻度です。業務が求めるデータ鮮度を確認しないまま高頻度で回すと、変化のないデータのために何度も計算資源を消費することになります。加えて、コピー中心の処理に過大なSparkプールを割り当てない、変換をソース側やクエリに押し込む、パーティション設計やファイルサイズの最適化で小さなファイルの大量生成を避けるといった工夫も効果があります。毎分の全件取得は必要性が明確でない限り無駄が大きく、真に低遅延が求められるならEventstreamなどのストリーミング機能の利用を検討するほうが適切です。

正解: A. A. Monitoring hub（モニタリングハブ）

正解の根拠・詳細解説

モニタリング ハブ（Monitoring hub）は、Fabric の左側ナビゲーションから開く横断的な実行監視画面で、自分がアクセスできるすべてのワークスペースにわたって、Data pipeline、ノートブック、Spark ジョブ定義、Dataflow Gen2、セマンティック モデルの更新といった各種アイテムの実行履歴を一覧できます。ステータス（成功・失敗・実行中・キャンセル）、開始時刻、所要時間、実行者、送信元アイテムでフィルターや並べ替えができ、個々の実行をドリルダウンすればアクティビティ単位の入出力やエラー メッセージまで辿れます。誤答の Power BI ギャラリーはコンテンツの一覧表示、OneLake セキュリティ設定は権限管理、Git リポジトリ画面はソース管理であり、いずれも実行監視の画面ではありません。実務では、まずモニタリング ハブで失敗した実行を特定し、そこから該当アイテムの詳細ログへ進むのが定石のトラブルシューティング手順です。

正解: A. A. 実行成功/失敗の状況やエラー詳細を把握する

正解の根拠・詳細解説

Dataflow Gen2 の実行履歴（更新履歴）を確認する目的は、実行がいつ開始・終了し、成功したか失敗したか、失敗したならどのクエリのどのステップでどんなエラーが起きたかを把握して、トラブルシューティングにつなげることにあります。エラーの詳細には、ソースへの認証失敗、データ型変換の失敗、参照していた列が存在しないといった原因が示されるため、修正すべき箇所を特定できます。あわせて所要時間の推移を見れば、データ量の増加や折りたたみが効かなくなったことによる性能劣化の兆候も検知でき、ステージングの有無やロジックの見直しといった改善につなげられます。誤答のレポートの配色、ライセンス変更、課金プランの変更はいずれも実行履歴とは無関係の操作です。実務では、失敗時にアラートを設定して通知を受け取り、履歴で原因を特定する、という組み合わせが基本になります。

正解: A. A. リフレッシュの成功/失敗状況と所要時間

正解の根拠・詳細解説

セマンティック モデルのリフレッシュ監視では、まず各リフレッシュが正常に完了したか失敗したか、失敗ならどのテーブル・パーティションでどんなエラーが起きたかを確認します。加えて重要なのが所要時間の推移で、データ量の増加や変換の非効率化によって処理時間が延びていくと、やがてスケジュールの間隔やタイムアウトの上限に達して失敗に転じます。所要時間を継続的に監視していれば、その前に増分更新の導入やモデルの軽量化といった対策を打てます。また、リフレッシュは容量（CU）を消費するため、複数モデルの更新時刻が重なるとスロットリングを招く点にも注意が必要です。誤答のレポート閲覧者数は利用状況の指標であってリフレッシュの健全性を示さず、ワークスペースの作成日やパスワード変更履歴は無関係です。実務では、更新時刻をずらして負荷を平準化する運用がよく採られます。

正解: A. A. 特定の条件（失敗・閾値超過など）が発生した際に自動的に通知を受け取る

正解の根拠・詳細解説

Fabric のアラートは、パイプラインやジョブの失敗、あるいはデータの値がしきい値を超えたといった条件の成立を検知して、メールや Microsoft Teams への通知を自動的に送る仕組みです。Real-Time Intelligence の Activator（Data Activator）を使えば、Eventstream や Power BI のビジュアルを監視対象として「在庫が 10 を下回ったら」「エラー率が 5% を超えたら」といったルールを定義し、通知だけでなくパイプラインの起動といったアクションにつなげることもできます。これにより、人が画面を見張らなくても異常に気づける運用が実現します。誤答のレポート デザインの自動生成、権限の自動変更、データの自動削除はアラートの目的ではありません。実務上の注意点は、しきい値を厳しくしすぎるとアラート疲れを招き重要な通知が埋もれることで、通知先と発報条件は運用開始後に調整していく前提で設計します。

正解: A. A. 失敗したアクティビティのエラーメッセージと実行ログ

正解の根拠・詳細解説

パイプラインの障害調査では、まず失敗したアクティビティを特定し、そのエラー メッセージと実行ログを読むのが基本です。モニタリング ハブや該当パイプラインの実行履歴から個々の実行をドリルダウンすると、アクティビティ単位のステータス、入力パラメーター、出力、エラー コードと詳細メッセージが確認できます。ここには認証の失敗、ソースへの接続タイムアウト、型変換エラー、参照先オブジェクトの不在といった具体的な原因が示されるため、推測に頼らず問題箇所を絞り込めます。入力の値を確認すれば、動的式が意図した値に評価されていたかも検証できます。誤答のワークスペース作成者名、課金状況、UI テーマは障害原因とは無関係です。実務では、原因が一時的な障害（ネットワークやスロットリング）であればリトライ設定で吸収し、恒常的な原因であればロジックや構成を修正する、と切り分けます。

正解: A. A. ソースのスキーマ変更やデータ型の不一致

正解の根拠・詳細解説

Dataflow Gen2 のエラーで典型的なのは、データの整合性と接続に関する問題です。①ソース側のスキーマ変更：参照していた列が改名・削除されるとステップが解決できずエラーになる、②データ型の不一致：文字列として入ってきた値を数値や日付に変換できない行が混ざる、③認証・接続エラー：資格情報の期限切れ、パスワード変更、ゲートウェイの停止、権限不足、④出力先の問題：書き込み先テーブルのスキーマとの不整合。誤答はいずれも「常に」と断定している点が誤りで、物理的なネットワーク障害やライセンス期限切れ、ユーザーの誤操作が原因になることもあり得ますが、典型例とは言えません。実務では、上流の変更が下流を壊す構図が繰り返されるため、スキーマ変更を許容する設計や、変更発生時に通知を受け取る仕組みを併せて用意することが有効です。

正解: A. A. セル単位の実行結果とスタックトレースを確認する

正解の根拠・詳細解説

ノートブックのデバッグは、セル単位で実行結果を確認できるという対話的な特性を活かすのが基本です。どのセルで失敗したかを特定し、出力されたスタック トレースを末尾から遡って、例外の型（KeyError、AnalysisException など）と発生箇所を読み取ります。Spark の場合は、Python 側の例外の下に Java／Scala 側のトレースが続くため、実際の原因は途中の Caused by 以降に書かれていることが多い点に注意します。原因箇所を絞ったら、該当セルの手前で DataFrame のスキーマや件数、サンプル行を表示して前提を確認し、必要なら Spark UI で実行されたステージやシャッフルの状況を見ます。誤答のワークスペース再作成、プール サイズを常に最大化、ログの無視はいずれも原因究明を伴わない対処であり、根本解決になりません。ノートブックはセルを小さく保つほど原因の切り分けが容易になります。

正解: A. A. データの取り込みパイプラインの状態とKQLクエリのエラーメッセージ

正解の根拠・詳細解説

Eventhouse のトラブルシューティングでは、問題が「データが入っていない」のか「クエリが誤っている」のかを切り分けます。前者であれば、Eventstream など上流の取り込み経路の状態、取り込みの失敗記録、マッピング（受信 JSON とテーブル列の対応）の不備、スキーマ不一致による拒否を確認します。後者であれば、実行した KQL のエラー メッセージを読み、列名の誤りや型の不一致、時間フィルターの範囲が保持期間外を指していないかなどを検証します。まず単純なクエリで件数と最新のタイムスタンプを確認し、データの有無を切り分けるのが実務上の定石です。誤答のレポートのテーマ カラー、ライセンス種別、課金プラン名はいずれも障害原因の判断材料になりません。取り込みは成功しているのに結果が空、というケースでは保持期間ポリシーによる自動削除も疑うべき候補になります。

正解: A. A. ソースとの接続エラーや変換ロジックの設定ミス

正解の根拠・詳細解説

Eventstream のエラーで典型的なのは、①ソースとの接続エラー：Event Hubs や IoT Hub、Kafka などへの接続で、資格情報・共有アクセス キーの誤りや期限切れ、ネットワーク／ファイアウォールによる遮断、コンシューマー グループの競合が原因となるもの、②変換ロジックの設定ミス：イベント プロセッサーで参照している列名がスキーマに存在しない、型が想定と異なる、集約のウィンドウ設定が不適切、③宛先側の問題：出力先のスキーマ不一致や権限不足、です。誤答のレポートのフォント サイズ、パスワード忘れ、命名規則違反はストリームの動作を妨げる要因ではありません。実務では、まずソース側にイベントが実際に流れているか（プレビュー機能で受信データを確認）、次に変換後のスキーマが宛先の期待と一致しているかを順に検証するのが、原因を素早く絞る手順です。

正解: A. A. エラーメッセージの構文・参照エラー内容を確認し、クエリを修正する

正解の根拠・詳細解説

T-SQL のエラー解決は、エラー メッセージが原因をかなり具体的に示すため、まずそれを正確に読むことから始めます。構文エラーであれば誤りの近辺の行番号が示され、オブジェクト参照エラーであれば「無効なオブジェクト名」「無効な列名」といった形で、存在しないテーブル・列・スキーマ名が指摘されます。スキーマ修飾の漏れ、綴りの誤り、権限不足による見えないオブジェクト、データ型変換の失敗、集計と GROUP BY の不整合などが典型的な原因で、いずれもクエリ側の修正で解決します。誤答のとおり、テーブルを削除して再作成するのはデータを失う危険があり、エラーを無視した再実行やデータベースの再起動は原因の解消になりません。実務では、大きなクエリは CTE や部分クエリに分解して段階的に実行し、どの部分が失敗しているかを切り分けると効率的です。

正解: A. A. 参照先のアクセス権限不足や参照パスの誤り

正解の根拠・詳細解説

OneLake ショートカットのエラーで最も多いのは、参照先へのアクセス権限不足とパスの誤りです。ショートカットは実データを複製せず参照するだけなので、参照先ストレージ（ADLS Gen2、S3、他ワークスペースの Lakehouse など）に対する読み取り権限が、ショートカット作成時に構成した接続の資格情報に付与されていなければ、作成はできても読み取り時に失敗します。資格情報の期限切れ、キーのローテーション、サービス プリンシパルへのロール割り当て漏れが典型です。パスについても、コンテナー名やディレクトリ階層の指定を誤ると、空のフォルダーとして見えたりエラーになったりします。誤答のレポートのデザインやワークスペースの命名は無関係で、ライセンス不足も一般的な原因ではありません。実務では、参照先の権限は Fabric 側ではなく参照先システム側で管理される点を意識して切り分けます。

正解: A. A. 小さなファイルを統合し、クエリ性能を向上させる

正解の根拠・詳細解説

OPTIMIZE は Delta テーブルに対して実行するメンテナンス コマンドで、多数の小さな Parquet ファイルを読み込んでより大きなファイルへ書き直すコンパクション（bin-packing）を行います。ストリーミング書き込みや頻繁な少量の追記を繰り返すと、1 ファイルあたり数 KB の断片が大量に生成され、クエリのたびにファイルのオープンとメタデータの解決が積み重なって著しく遅くなります（small file problem）。ファイルを適切なサイズに統合すれば、スキャン効率が上がり並列処理も均等になります。あわせて Z-Order を指定すれば、よく絞り込みに使う列でデータを共局在させ、データ スキッピングの効きを高められます。誤答の暗号化・テーブル削除・権限変更は OPTIMIZE の機能ではありません。実務では、OPTIMIZE 後に古いファイルが残るため、保持期間を考慮した VACUUM と組み合わせて定期実行します。

正解: A. A. 不要になった古いファイルを削除し、ストレージを節約する

正解の根拠・詳細解説

VACUUM は、Delta テーブルの最新バージョンから参照されなくなった古いデータ ファイルを物理的に削除し、ストレージ使用量を削減するコマンドです。Delta Lake は更新や削除の際に既存ファイルを書き換えず、新しいファイルを書いてトランザクション ログで参照を切り替えるため、OPTIMIZE や MERGE を繰り返すと不要ファイルが蓄積していきます。VACUUM はこれを保持期間（リテンション）より古いものに限って掃除します。重要なトレードオフとして、削除されたファイルはタイムトラベルの対象外になるため、保持期間を短くしすぎると過去バージョンへの復元ができなくなり、実行中の長時間クエリが参照中のファイルを消してしまう危険もあります。誤答の行の複製、結果のキャッシュ、権限変更は VACUUM の目的ではありません。実務では、既定の保持期間を安易に短縮しないことが鉄則です。

正解: A. A. Parquetファイルの書き込み時にデータを最適化し、読み取り性能を向上させる

正解の根拠・詳細解説

V-Order は Fabric 独自の Parquet 書き込み最適化で、書き込み時に特別な並べ替え、行グループの分散、辞書エンコードや圧縮の適用を行い、読み取り側が高速にスキャンできる形にデータを配置します。オープンな Parquet 仕様に準拠したままの最適化であるため、Spark や外部エンジンからも通常の Parquet として読める互換性を保ちます。特に効果が大きいのが Power BI の Direct Lake モードで、セマンティック モデルが OneLake 上の Delta テーブルを直接読み込むため、V-Order によってメモリへの読み込みとクエリの応答が改善されます。誤答の暗号化、認証、帯域制限はいずれも V-Order とは無関係です。実務上のトレードオフとして、V-Order は書き込み時に追加の処理コストを要するため、書き込みが極端に多く読み取りが少ないワークロードでは無効化を検討する余地があります。

正解: A. A. 並列実行や適切なバッチサイズの調整

正解の根拠・詳細解説

パイプラインの性能最適化では、まず処理を直列に並べる必要が本当にあるかを見直し、依存関係のないアクティビティは並列に実行します。ForEach アクティビティは既定で順次実行にも並列実行にも設定でき、並列度（batch count）を上げれば多数のテーブルやパーティションを同時に処理できます。あわせて、Copy activity の並列コピー設定やバッチ サイズを調整し、1 回あたりの転送単位を適正化することでスループットが改善します。誤答のとおり、常に直列にする、常に最小リソースを割り当てる、監視を無効化する、はいずれも性能を損なうか問題の把握を困難にします。実務上の注意点として、並列度を上げすぎるとソース システムへの接続が飽和したり、Fabric 容量の CU を一気に消費してスロットリングを招いたりするため、監視しながら段階的に調整するのが正しい進め方です。

正解: A. A. 統計情報の更新やインデックス・パーティショニングの活用

正解の根拠・詳細解説

Warehouse のクエリ最適化では、まずオプティマイザーが正しい実行計画を選べる状態を整えることが重要です。統計情報は列の値の分布を示すメタデータで、これが古いままだと行数の見積もりを誤り、不適切な結合方式やデータ移動が選ばれて性能が大きく劣化します。データを大量に投入・更新した後は統計を最新化することが有効です。あわせて、テーブルの分割（パーティショニング）や、よく絞り込む列でのデータの共局在によって、読むべきデータ量そのものを減らします。さらに、SELECT * を避けて必要な列だけを取得する、早い段階で述語を適用して行を絞る、といったクエリの書き方も効きます。誤答のキャッシュなしの全再計算、毎回のテーブル再作成、並列実行の禁止はいずれも性能を悪化させる誤った選択です。実行計画を確認してボトルネックを特定する習慣が実務では有効です。

正解: A. A. 不要な変換ステップの削減とスケーリング設定の見直し

正解の根拠・詳細解説

Eventstream の最適化では二つの観点が中心になります。一つは処理そのものの軽量化で、イベント プロセッサーに不要な変換ステップが積み重なると 1 イベントあたりの処理コストが増え、スループットの低下と遅延の増加を招きます。フィルターはできるだけ前段に置いて処理対象そのものを減らし、宛先で不要な列は早めに落とす、といった整理が効きます。もう一つがスケーリングで、流入するイベント量に対して処理能力が不足すると、バックログが溜まり続けて遅延が拡大していくため、データ量の増加に合わせて設定を見直す必要があります。誤答の「常に変換を増やす」「スケーリングを無視する」「常に最小構成」はいずれも状況に応じた調整を放棄しており適切ではありません。実務では、流入レートと処理遅延を継続的に監視し、ピーク時に耐えられるかを基準に構成を決めます。

正解: A. A. データの保持期間設定とキャッシュポリシーの調整

正解の根拠・詳細解説

Eventhouse（KQL データベース）の最適化では、保持期間ポリシーとキャッシュ ポリシーの調整が中心になります。保持期間は、データをどれだけの期間データベースに残すかを定め、これを過ぎたデータは自動的に削除されるため、不要に長く保持するとストレージ コストが膨らみます。キャッシュ（ホット キャッシュ）ポリシーは、そのうちどれだけの期間分を高速な SSD 層に載せておくかを定めるもので、ホット キャッシュに載っているデータへのクエリは大幅に速くなる一方、キャッシュ量を増やすほどリソース消費とコストが増えます。したがって「直近 30 日はホットで高速に、それ以前は保持のみ」といった形で、アクセス頻度に応じてバランスを取るのが基本です。誤答の保持期間の無制限化、インデックスの無効化、並列実行の禁止はいずれもコストや性能を悪化させます。

正解: A. A. 適切なパーティション数とキャッシュの活用

正解の根拠・詳細解説

Spark ジョブの最適化で効果が大きいのは、パーティション数の適正化とキャッシュの活用です。パーティションが少なすぎるとエグゼキューターが遊んで並列度を活かせず、多すぎるとタスクのスケジューリング オーバーヘッドと小さなファイルの生成が問題になるため、データ量とクラスターのコア数に見合った数へ repartition や coalesce で調整します。また、同じ DataFrame を複数回参照する場合は、Spark の遅延評価により毎回はじめから再計算されてしまうため、cache や persist で中間結果を保持すると無駄な再計算を避けられます。さらに、シャッフルを伴う結合では、小さい側をブロードキャストして大規模なデータ移動を避ける手法も有効です。誤答の 1 パーティション固定、キャッシュの一律無効化、ノード サイズの一律最小化はいずれも分散処理の利点を捨てる選択です。

正解: A. A. クエリの実行時間とリソース消費量（CPU・メモリ）

正解の根拠・詳細解説

クエリ性能の監視では、まず実行時間と消費リソース（CPU・メモリ、Fabric では CU の消費量）を確認し、どのクエリが全体のボトルネックになっているかを特定します。実行時間だけを見ると、稀にしか走らない重いクエリより、軽いが極めて高頻度なクエリの方が総消費量では上回っている、という状況を見落とすため、単位時間あたりの総リソース消費でも並べ替えて評価することが重要です。あわせて、待機の内訳（データ移動、シャッフル、I/O、同時実行によるキューイング）を見れば、チューニングすべき対象がクエリの書き方なのか、データの配置なのか、容量の割り当てなのかを切り分けられます。誤答の閲覧者の年齢、パスワードの長さ、ワークスペース名の文字数はいずれも性能指標ではありません。Fabric では容量メトリクス アプリで CU 消費とスロットリングの発生状況を継続的に追うのが実務の基本です。

正解: A. A. 一時的なエラー（ネットワーク断など）から自動的に回復する

正解の根拠・詳細解説

パイプラインの各アクティビティにはリトライ回数とリトライ間隔を設定でき、失敗した場合に自動で再試行させられます。これが有効なのは、ネットワークの瞬断、ソース システムの一時的な過負荷、接続数の上限到達、スロットリングによる拒否といった、時間をおけば解消する一過性の障害です。こうした障害に対してリトライを設定しておけば、夜間バッチが単発の通信エラーで止まり翌朝まで気づかない、という事態を避けられます。誤答のとおり、リトライはエラーを無視する機能ではなく、規定回数を試して失敗すればアクティビティは正しく失敗として記録されます。実務上重要なのは、再試行しても回復しない恒久的な原因（認証情報の失効、スキーマの不整合、ロジックの誤り）に対してはリトライが無意味であること、そして再実行しても副作用が重複しないよう処理を冪等に設計しておく必要があることです。

正解: A. A. クエリオプティマイザが非効率な実行計画を選択し、性能が低下する

正解の根拠・詳細解説

統計情報は、テーブルの行数や列値の分布（ヒストグラム）を要約したメタデータで、クエリ オプティマイザーはこれを基に「この述語で何行に絞られるか」を見積もり、結合の順序や方式、データの分散方法を決定します。統計が古いまま大量のデータが投入・削除されると見積もりが実態から乖離し、たとえば数百万行返る結合を数行と誤って見積もった結果、不適切な結合方式や過剰なデータ移動を選んでしまい、クエリが極端に遅くなります。対策は、大きなデータ変更の後に統計を最新化することです。誤答のとおり、統計が古いだけでデータが自動削除されたり、権限が変わったり、レポートが表示できなくなったりはしません（遅くなるだけで結果自体は正しい）。実務では、性能劣化の原因調査で実行計画を見た際、見積もり行数と実行時行数が大きく食い違っていれば統計の陳腐化を疑います。

正解: A. A. 特定のパーティションのみをスキャンすることでクエリを高速化できる

正解の根拠・詳細解説

パーティショニングの最大の利点はパーティション プルーニングです。日付などの列でデータを分割して格納しておくと、WHERE 句にその列の条件が含まれるクエリでは、条件に該当するパーティションのみを読み取り、残りは物理的に一切スキャンしません。数年分のデータを持つテーブルに対して直近 1 か月だけを集計する、というよくある分析で、読み取り量とコストが劇的に減ります。加えて、Spark では分割単位で並列処理でき、パーティション単位での再処理や削除も容易になります。誤答のとおり、パーティショニングによってデータが重複することもストレージが倍になることもなく、セキュリティ リスクが増えるわけでもありません。実務上の注意は粒度で、カーディナリティの高い列（顧客 ID など）で分割すると小さなファイルが大量発生して逆効果になるため、日付など適度な粒度の列を選ぶのが定石です。

正解: A. A. スロットリングやパフォーマンス低下の兆候を早期に検知する

正解の根拠・詳細解説

Fabric capacity は、そこに紐づくワークスペースのすべてのワークロード（Spark ジョブ、Dataflow、SQL クエリ、レポートのレンダリング、リアルタイム処理）が消費する CU の上限を定めます。消費が上限を超えると、Fabric は平滑化（スムージング）で一時的な超過を吸収しますが、超過が続くとスロットリングが発生し、クエリの遅延やジョブの拒否といった形で利用者に影響が及びます。使用率を継続的に監視していれば、こうした兆候を早期に検知し、原因となっているアイテムの特定、実行時刻の分散、クエリの改善、あるいは容量のスケール アップといった対策を、業務が止まる前に打てます。誤答のレポート デザインの自動修正、ライセンスの自動更新、ワークスペース名の自動変更はいずれも監視の目的ではありません。実務では、開発と本番の容量を分けて相互干渉を避けることも重要な設計判断です。

正解: A. A. Fabric capacityの消費状況を可視化し、ボトルネックを特定する

正解の根拠・詳細解説

Microsoft Fabric Capacity Metrics アプリは、容量の消費状況を可視化するための公式アプリで、時系列の CU 消費量、スロットリングや平滑化の発生状況、そしてどのワークスペース・どのアイテム・どの操作が消費の大部分を占めているかをドリルダウンして確認できます。これにより「特定のノートブックが夜間に大量の CU を消費している」「あるセマンティック モデルの更新が集中してピークを作っている」といったボトルネックを具体的に特定でき、実行時刻の分散、処理の効率化、容量サイズの見直しといった対策につなげられます。誤答のレポートのデザイン変更、ライセンス種別の変更、ワークスペースの削除は管理操作であり、このアプリの役割ではありません。実務では、容量を増やす前にまずこのアプリで消費の内訳を確認し、非効率な処理の改善で解決できないかを検討するのが、コスト面で正しい順序です。

正解: A. A. 不要なデータ読み込みの削減とキャッシュの活用

正解の根拠・詳細解説

ノートブックの実行時間短縮で効果が大きいのは、読み込むデータ量そのものを減らすことと、再計算を避けることです。前者は、必要な列だけを選択する、パーティション列やフィルターを読み込み時点で適用してプルーニングを効かせる、といった工夫で実現できます。後者については、Spark が遅延評価であるため、同じ DataFrame を複数のアクションで参照するとそのたびに元から計算し直される点が落とし穴になり、cache や persist で中間結果を保持することで無駄をなくせます。誤答のとおり、毎回すべてのセルを再実行するのは非効率であり、常に最大サイズのプールを使うのは容量（CU）の浪費で、データ量が小さければ速くもなりません。並列実行の禁止に至っては Spark の利点を捨てる選択です。実務では、まずどのセルが時間を消費しているかを計測し、原因に応じた手を打つ順序が重要です。

正解: A. A. 依存関係を明確にした上で、失敗時の代替フロー（条件分岐）を設計する

正解の根拠・詳細解説

パイプラインでは、あるアクティビティが失敗すると、それに依存する後続のアクティビティが実行されないまま処理全体が停止し、影響が下流へ波及します。これに備えるには、まず依存関係を明確に設計したうえで、失敗時の経路を用意します。アクティビティ間の接続には成功時・失敗時・完了時・スキップ時の 4 種類があり、失敗時の経路に通知アクティビティや代替処理、クリーンアップ処理をつなげておけば、障害を確実に検知でき、中途半端な状態を残さずに済みます。加えて、一時的な障害はリトライで吸収し、部分的な失敗を許容してよい処理は完了時の経路で先へ進める、といった使い分けも有効です。誤答の依存関係を設定しない、全て並列にする、監視を無効化する、はいずれも問題を見えなくするだけです。実務では、再実行時に副作用が重複しないよう冪等な処理として設計しておくことも欠かせません。

正解: A. A. 監査ログをEventhouseやLog Analyticsへエクスポートして分析する

正解の根拠・詳細解説

Fabric の監査ログやアクティビティ ログは、コンプライアンス ポータル上では一定期間しか遡れないため、長期の傾向分析や社内の保管要件に応えるにはエクスポートが必要です。管理 API や PowerShell で取得したログを Eventhouse（KQL データベース）に取り込めば、KQL による高速な時系列分析やダッシュボード化ができ、Azure Monitor の Log Analytics へ送る構成であれば既存の運用監視基盤と統合できます。これにより、利用状況の推移、特定ユーザーやアイテムへのアクセス傾向、異常なアクセス パターンの検出といった分析が可能になります。誤答のとおり、Fabric でログが保存できないということはなく、テーマ カラーの変更や権限の一括削除はログ活用とは無関係です。実務では、ログ取得を定期パイプラインとして自動化し、保持期間ポリシーを設定してコストを抑える構成が現実的です。

正解: A. A. 頻繁に実行される重いクエリと不要なフルスキャンの有無

正解の根拠・詳細解説

Warehouse のリソース消費（コスト）最適化では、消費の内訳を把握することが出発点になります。着目すべきは、①頻繁に実行される重いクエリ：1 回あたりは中程度でも、実行回数が多ければ総消費量では最大の要因になり得る、②不要なフル テーブル スキャン：述語が適切に効かない書き方、SELECT * による全列読み取り、パーティション列を条件に含まないクエリなどが原因で、読む必要のないデータまで走査している、の二点です。これらを特定したうえで、クエリの書き換え、パーティショニングやデータの共局在の見直し、集約テーブルの事前作成といった改善を行います。誤答のレポートの配色、ユーザーの氏名、ワークスペースの作成日はコストと無関係です。実務では、容量メトリクス アプリで消費上位の操作を洗い出し、上位のいくつかを改善するだけで全体が大きく改善することが少なくありません。

正解: A. A. ノード間のデータ移動が多く、処理コストが高くなる傾向がある

正解の根拠・詳細解説

シャッフルは、結合、集約（groupBy）、repartition、ソートなどの際に、同じキーのデータを同じパーティションへ集めるためにノード間でデータを再分配する処理です。ディスクへの書き出しとネットワーク越しの転送を伴うため、Spark のジョブの中で最もコストが高くなりやすく、性能のボトルネックの主因となります。特にキーの偏り（データ スキュー）があると、一部のタスクだけに大量のデータが集中して全体の完了を引き延ばします。対策としては、結合する片方が十分小さければブロードキャスト結合でシャッフルそのものを回避する、事前に適切なパーティション分割を行う、不要な repartition を避ける、といった手法があります。誤答のとおり、シャッフルが常に速度を向上させることはなく、メモリ消費がゼロになることも、ネットワークを使わないこともありません。実行計画で Exchange を確認するのが調査の第一歩です。

正解: A. A. データ検証ルールとアラートを組み込んだ品質チェックパイプライン

正解の根拠・詳細解説

データ品質の問題は、静かに誤った分析結果を生み続けるため、検知の仕組みを処理そのものに組み込むことが重要です。具体的には、変換パイプラインの中に検証ステップを設け、①必須項目の欠損率、②値の範囲や区分値の妥当性、③主キーの一意性と参照整合性、④件数の急激な増減、といったルールでチェックし、結果をメトリクスとして記録します。しきい値を超えた場合はアラートで通知し、必要に応じて不正データを隔離テーブルへ退避したうえで処理を継続するか、下流への伝播を止める判断を行います。誤答のとおり、監視をしない方針や人手の目視確認のみへの依存は、データ量が増えるほど破綻します。実務では、medallion アーキテクチャの bronze から silver への変換時に検証を集中させ、品質メトリクスの推移をダッシュボード化して継続的に監視する構成が推奨されます。

正解: A. A. 過剰にプロビジョニングされたCapacityサイズと非効率なクエリ・処理

正解の根拠・詳細解説

Fabric のコスト最適化では、①容量サイズの適正化：実際の CU 使用率に対して過大な F SKU を割り当てていないか、逆にスロットリングが頻発していないかを容量メトリクス アプリで確認し、必要に応じてスケール調整や、使わない時間帯の一時停止（Azure 側の容量の一時停止）を検討する、②非効率な処理の改善：不要なフル スキャンを招くクエリ、過剰なパーティショニング、必要のない高頻度スケジュール、アイドル状態で放置される Spark セッションなど、CU を浪費している要因を洗い出して改善する、の二点が優先されます。順序としては、容量を増やす前にまず消費の内訳を確認し、改善で解決できないかを検討するのが定石です。誤答のレポートのフォント、プロフィール画像、ワークスペースの説明文はコストに影響しません。開発と本番で容量を分け、開発側は小さめの SKU にするのも有効な打ち手です。

正解: A. A. 各アクティビティの実行時間を個別に確認し、ボトルネックとなる箇所を特定する

正解の根拠・詳細解説

パイプラインの実行時間が想定より長い場合は、まず全体を漠然と眺めるのではなく、モニタリング ハブや実行履歴から各アクティビティの所要時間を個別に確認し、どこが最も時間を消費しているかを特定します。ボトルネックが Copy activity にあるのか、ノートブックの Spark 処理にあるのか、あるいは前段の待機やセッションの起動時間にあるのかで、打つべき手は全く異なります。Copy であれば並列コピーやバッチ サイズ、ソース側のクエリ効率、Spark であればパーティション設計やシャッフルの見直し、ForEach であれば並列度の調整、が対象になります。誤答のとおり、パイプラインの削除・再作成や監視の無効化は原因究明を伴わず、リソースを一律 2 倍にする対処はコストだけが増えて根本原因が残ります。計測して原因を特定してから手を打つ、という順序が最も重要です。

正解: A. A. データソースへの接続設定や認証情報の有効性

正解の根拠・詳細解説

セマンティック モデルのリフレッシュ失敗で最も多い原因は、データソースへの接続と認証にまつわる問題です。具体的には、保存された資格情報の有効期限切れ、アカウントのパスワード変更、OAuth トークンの失効、サービス プリンシパルの権限剥奪、オンプレミス データ ゲートウェイの停止やバージョン不整合、ファイアウォールによる接続拒否などが挙げられます。したがって、まず接続設定と資格情報の有効性を確認するのが調査の第一歩です。次点の原因としては、ソース側のスキーマ変更による列の不整合、データ量の増加によるタイムアウトやメモリ超過、容量のスロットリングがあります。誤答の配色設定、プロフィール写真、ワークスペースの作成日はいずれも失敗の要因になりません。実務では、資格情報の有効期限をあらかじめ把握し、期限前に更新する運用を組み込むことで、この種の障害の多くを予防できます。

正解: A. A. 特定の閾値を超えたセンサー値を検知した際に通知する

正解の根拠・詳細解説

Real-Time Intelligence におけるアラートの典型例が、IoT センサーの値がしきい値を超えた際の通知です。Eventstream で取り込んだテレメトリを Activator（Data Activator）に接続し、「温度が 80 度を超えた状態が 5 分続いたら」といった条件をノーコードで定義すると、条件成立時に Microsoft Teams やメールへの通知を送ったり、Fabric のパイプラインを起動して是正処理を走らせたりできます。人がダッシュボードを見張らなくても異常を検知できる点が、リアルタイム基盤を導入する価値そのものです。誤答のレポート デザインやライセンス、ワークスペース名を毎日変更する、といった操作はアラートの用途ではありません。実務上の注意点は、条件を敏感にしすぎるとノイズの多い通知が大量に発生してアラート疲れを招くため、継続時間の条件を加えるなどして発報を絞り込む設計が重要になることです。

正解: A. A. エラー発生時のログ・実行履歴・関連する変更履歴

正解の根拠・詳細解説

根本原因分析（RCA）では、単に失敗したという事実ではなく「なぜ失敗したか」を突き止める必要があるため、複数の情報源を突き合わせます。①エラー発生時の詳細ログ：どのアクティビティ・どのセル・どのクエリで、どんなエラー コードとメッセージが出たか、②実行履歴：いつから失敗し始めたか、以前は成功していたか、所要時間が徐々に伸びていなかったか、③関連する変更履歴：直前のデプロイ、Git のコミット、接続情報や権限の変更、上流ソースのスキーマ変更。特に「昨日まで動いていたものが今日壊れた」というケースでは、その間に加えられた変更が原因であることが圧倒的に多く、Git のコミット履歴やデプロイ パイプラインの記録が決定的な手がかりになります。誤答のユーザーの好きな色やテーマ名、作成者の出身地は当然ながら分析材料になりません。

正解: A. A. 定期的なパフォーマンスレビューとCapacity使用率の見直し

正解の根拠・詳細解説

Fabric の運用では、構成は一度決めれば終わりではなく、データ量・利用者・ワークロードの変化に合わせて継続的に見直す必要があります。推奨されるプラクティスは、①定期的なパフォーマンス レビュー：実行時間の推移、遅いクエリやジョブの上位、失敗率を定期的に確認し、劣化の兆候を早期に捉える、②容量使用率の見直し：容量メトリクス アプリで CU 消費とスロットリングの発生状況を追い、必要に応じてスケール調整や実行時刻の分散を行う、③あわせて Delta テーブルの OPTIMIZE や統計の更新といったメンテナンスを定期実行する、です。誤答のとおり、一度設定して見直さない、エラーが出てから初めて対応する、ドキュメントを作らない、という姿勢はいずれも障害の予兆を見逃し、属人化を招きます。運用は予防的な活動として計画に組み込むべきものだと理解しておきましょう。

正解: A. A. 非効率な結合やスキャン方法を特定し、チューニングの手がかりを得る

正解の根拠・詳細解説

クエリ実行プランは、オプティマイザーが選んだ処理手順（どのテーブルをどの順で読み、どの結合方式を使い、どこでデータを移動・集約するか）と、各ステップの見積もりコストを可視化したものです。これを確認する目的は、想定と異なる結合方式が選ばれていないか、述語が効かずにフル テーブル スキャンになっていないか、過剰なデータ移動やソートが発生していないかを見つけ、チューニングの手がかりを得ることにあります。特に、見積もり行数と実際の行数が大きく食い違っている箇所は、統計情報の陳腐化を示す典型的なサインで、統計の更新だけで劇的に改善することもあります。誤答のレポートのデザイン、権限、課金プランは実行プランとは無関係です。実務では、まず遅いクエリを特定し、その実行プランでボトルネックとなっているステップを見てから、クエリの書き換えやデータ配置の見直しに進む、という順序を取ります。

正解: A. A. Lineage（リネージ）ビューでデータの流れを可視化する

正解の根拠・詳細解説

リネージ（Lineage）ビューは、ワークスペース内のアイテム同士の依存関係をグラフとして可視化する機能で、データソースから Lakehouse・Warehouse、Dataflow やパイプライン、セマンティック モデル、レポートへと至るデータの流れを辿れます。これにより、①影響範囲の調査：あるテーブルのスキーマを変更したら、どのモデルとレポートが壊れるかを事前に把握できる、②原因の追跡：レポートの数値がおかしいときに、どの上流アイテムを疑えばよいかを遡れる、③不要資産の判断：どこからも参照されていないアイテムを見つけられる、といった運用が容易になります。誤答の依存関係をすべて削除する、ドキュメントを作らない、監視ツールを使わない、はいずれも状況を悪化させる選択です。実務では、変更前にリネージで下流を確認することが、予期せぬレポート破損を防ぐ最も確実な手順になります。

正解: A. A. メールやMicrosoft Teamsチャネル

正解の根拠・詳細解説

Fabricのアラートは、Real-Time Intelligenceのアクティベーター（Data Activator／Reflex）を中核とする仕組みで、データの値が定義した条件を満たしたときに人へ通知を届ける。監視対象はイベントストリームやKQLデータベースを流れるデータ、Power BIレポートのビジュアルなどで、「在庫が閾値を下回った」「センサー値が規定範囲を外れた」といった条件をオブジェクト単位で定義する。条件が成立すると、指定したメールアドレスへの通知や、Microsoft Teamsのチャネル・個人へのメッセージ送信という形で宛先に届く。いずれも組織が日常的に使う連絡経路であるため、異常の発生から担当者が気付いて対応を始めるまでの時間を短縮できる点が重要である。ダッシュボードを人が見張り続ける運用と違い、条件が成立したときにだけ通知が届くため、監視の手間を抑えつつ見落としも防げる。プリンターへの出力やレポートの背景色、ワークスペース名は通知の届け先という概念に該当せず、アラートの構成項目にはならない。