Fabric Warehouse SQL Audit Logs が一般提供（GA）になり、Microsoft Fabric の Data Warehouse と SQL analytics endpoint で、SQL レベルの監査証跡を残せるようになりました。結論から言うと、「誰が、いつ、どの T-SQL を実行し、権限やスキーマをどう変えたか」を追いやすくなったのが最大の変化です。監査やインシデント調査の実務ではかなり強い武器になります。いっぽうで、機能は既定でオフであり、SQL analytics endpoint では Lakehouse runtime 経由の DML が拾えないなど、過信するとハマる制約もあります。(Microsoft Learn)
この記事では、Fabric Warehouse SQL Audit Logs が GA で何を変えるのかを、何を記録できるか、調査はどこまで速くなるか、導入時にどこで失敗しやすいかまで実務目線で整理します。公開情報をそのままなぞるだけではなく、運用で迷いやすい判断基準まで落とし込みます。(Microsoft Learn)
Fabric Warehouse SQL Audit Logs が GA で何が変わったか
2026年3月の Microsoft Fabric の新機能情報では、Warehouse SQL Audit Logs が GA とされ、対象は Fabric Data Warehouse と SQL analytics endpoint です。新機能の説明では、イベント時刻、実行したユーザーまたはプロセス、実行された T-SQL などを含む包括的で改変されない監査記録を提供すると案内されています。(Microsoft Learn)
ただし、ここで押さえたいのは、Fabric 全体の監査と SQL レベルの監査は役割が違うことです。Fabric アイテム単位の操作追跡は Microsoft Purview 側の監査導線が中心で、Warehouse や SQL analytics endpoint の中で起きた SQL 操作の追跡は SQL Audit Logs が担当します。両者を混同しないだけで、調査の初動がかなり速くなります。(Microsoft Learn)
| 見たいもの | まず見るべき監査 |
|---|---|
| ワークスペース共有、アイテム作成・削除、Fabric アイテムへの操作 | Microsoft Purview / Fabric の user audit logs が基本です。Fabric アイテムに対して誰が何をしたかを追う導線として案内されています。 (Microsoft Learn) |
| Warehouse / SQL analytics endpoint 内の SQL 操作 | SQL Audit Logs が中心です。認証、権限変更、スキーマ変更、実行された T-SQL の追跡に向きます。 (Microsoft Learn) |
SQL Audit Logs で何を記録できるか
SQL Audit Logs の価値は、単なる「クエリ履歴」ではなく、認証、権限、スキーマ、実行内容、接続元までまとめて追えることにあります。Fabric portal では分かりやすい名前でイベントを選べ、必要に応じて個別の audit action も指定できます。(Microsoft Learn)
| 観点 | 記録できる代表内容 | 実務での使いどころ |
|---|---|---|
| 認証・接続 | User Logged In、User Failed To Log In、User Logged Out。返却列には client_ip、host_name、application_name も含まれます。 | 不審なログイン、接続元の洗い出し、アプリ経由か手動接続かの切り分けに向きます。 (Microsoft Learn) |
| 権限変更 | Object Permission Was Changed、Role Member Was Changed、User Was Changed。返却列では target_database_principal_name も確認できます。 | 「昨日まで見えていたテーブルが急に見えない」の原因が権限変更かどうかを追いやすくなります。 (Microsoft Learn) |
| スキーマ・オブジェクト変更 | Object Was Changed、Schema Was Changed、Object Owner Changed。CREATE、ALTER、DROP 系の変化を追えます。 | テーブル定義の変更、オブジェクト削除、所有者変更の監査に有効です。 (Microsoft Learn) |
| 実行された SQL | Batch Was Started、Batch Was Completed、statement、event_time。 | いつ、どの SQL バッチが実行されたかを時系列で追うときに役立ちます。 (Microsoft Learn) |
| 実行結果の手掛かり | duration_milliseconds、response_rows、affected_rows。 | 重いバッチや想定外の大量更新の痕跡を探す初動調査で使えます。 (Microsoft Learn) |
| オブジェクト単位の詳細監査 | SELECT、INSERT、UPDATE、DELETE、EXECUTE などの個別 audit action を設定できます。 | 重要テーブルや重要プロシージャだけ、粒度を上げて監査したいときに向きます。 (Microsoft Learn) |
ここで大事なのは、「何でも全部自動で記録される」わけではなく、どのイベントや action group を取るかは自分で設計するという点です。逆に言えば、コンプライアンス要件に合わせて監査粒度をかなり細かく調整できます。(Microsoft Learn)
監査と調査はどこまで楽になるか
SQL Audit Logs の実務的な強みは、ログが増えること自体ではなく、「原因候補を短時間で絞れること」です。特に sys.fn_get_audit_file_v2 は時間範囲で効率よく絞り込めるので、障害発生の直前だけを見る運用と相性がいいです。(Microsoft Learn)
誰がテーブル定義を変えたかを追いやすい
たとえば、朝になったらレポートが急に失敗し始めた場合、まず疑うのは ALTER TABLE や DROP VIEW などの DDL です。Object Was Changed や Schema Was Changed と、event_time、session_server_principal_name、statement を見れば、いつ・誰が・どの SQL を実行したかをかなり直接的に追えます。変更管理票と突き合わせる運用もしやすくなります。(Microsoft Learn)
権限事故の初動が速くなる
「特定ユーザーだけ FactSales を読めなくなった」という事故では、テーブル側を見る前に、Object Permission Was Changed、Role Member Was Changed、User Was Changed と target_database_principal_name を確認するのが早道です。単なるアプリ障害ではなく、GRANT / REVOKE / DENY やロールメンバー変更が原因かどうかを切り分けやすくなります。(Microsoft Learn)
不審アクセスか設定ミスかを見分けやすい
ログイン失敗が増えたとき、User Failed To Log In だけでは判断しきれません。client_ip、host_name、application_name を合わせて見ると、想定内の ETL ツールか、未知のクライアントかが見えやすくなります。セキュリティインシデントなのか、接続文字列の誤設定なのかを早めに切り分けられるのは大きいです。(Microsoft Learn)
重い SQL の痕跡も拾いやすい
SQL Audit Logs は純粋な性能監視ツールではありませんが、duration_milliseconds、application_name、statement が取れるので、「障害直前に重かった SQL は何か」を探す初動には十分使えます。しかも sys.fn_get_audit_file_v2 はファイルレベルとレコードレベルの二段階で時間絞り込みを行うため、短い時間窓の調査と相性がいいです。(Microsoft Learn)
SQL analytics endpoint で見落としやすい制限
SQL analytics endpoint でも SQL Audit Logs の恩恵はありますが、Lakehouse 側の書き込み監査をそのまま期待するとズレます。公式ドキュメントでは、SQL analytics endpoint の監査には制限があり、Lakehouse テーブルのデータ操作は SQL analytics endpoint ではなく Lakehouse runtime 経由で行われるため、INSERT、UPDATE、DELETE、MERGE などの DML は記録されないと明記されています。(Microsoft Learn)
さらに、SQL analytics endpoint では監査フォルダーへの直接アクセスも現時点でサポートされていません。基になる .XEL ファイルを直接参照・ダウンロードするのではなく、sys.fn_get_audit_file_v2 で問い合わせる前提です。(Microsoft Learn)
つまり、SQL analytics endpoint の SQL Audit Logs は、読み取りや権限変更、SQL 実行の追跡には強い一方で、Lakehouse 更新の全履歴を単独で担うものではありません。Lakehouse 中心の更新監査まで求めるなら、Fabric アイテム監査やジョブ実行履歴など、別の監査導線と組み合わせる設計のほうが現実的です。これは公式の制限事項と Fabric 全体の監査導線から見た実務上の判断です。(Microsoft Learn)
設定前に決めるべき3つの判断基準
何を証明したいのか
監査で失敗しやすいのは、「とりあえず全部取る」ことです。証明したいものが曖昧だと、ログは増えるのに調査は速くなりません。最初の設計は、次のように切るのが現実的です。(Microsoft Learn)
- アクセス監査が主目的なら、ログイン成功・失敗、ログアウト、
Batch Was Completedを優先します。誰が入って何を実行したかの流れが見えやすくなります。 (Microsoft Learn) - 権限事故の追跡が主目的なら、
Object Permission Was Changed、Role Member Was Changed、User Was Changedを優先します。 (Microsoft Learn) - DDL の変更管理が主目的なら、
Object Was ChangedとSchema Was Changedを優先します。 (Microsoft Learn) - 重要テーブルだけ厳格に追いたいなら、オブジェクト単位の
SELECT、INSERT、UPDATE、DELETE、EXECUTEを追加します。すべてのテーブルに同じ粒度をかける必要はありません。 (Microsoft Learn)
どれだけ保持するのか
機能自体は既定でオフですが、設定画面では全アクション有効・保持期間9年が初期値として案内されています。さらに、保存コストは記録する action group やイベント数に応じて増えると明記されています。コンプライアンスで本当に必要な粒度だけを残す、という逆算が大切です。(Microsoft Learn)
特に Warehouse では、監査ログは OneLake 上の Warehouse アイテム内に保存されます。Warehouse を削除すると、その監査ログも一緒に消えます。 保持義務があるなら、削除前に .XEL を別の保存先へ退避する前提で考えるべきです。(Microsoft Learn)
誰に読ませるのか
設定・照会には Fabric アイテムの Audit 権限が必要です。いっぽうで、T-SQL からの照会だけなら VIEW DATABASE SECURITY AUDIT を付与する方法もあります。この権限はログ照会だけを許可し、監査設定の変更やファイルアクセスを与えないと説明されています。監査担当者に広い運用権限を持たせたくないときに使いやすい設計です。(Microsoft Learn)
また Warehouse では、Workspace Admin / Member / Contributor に加え、Read All を持つ Viewer でも Audit フォルダーにアクセスできるとされています。監査ログはそれ自体が機微情報になり得るので、Read All の付与先は見直したほうが安全です。(Microsoft Learn)
最短で有効化して確認する手順
- アクティブ容量または trial capacity がある Fabric ワークスペースと、対象の Warehouse を用意します。設定・照会には
Audit権限が必要です。(Microsoft Learn) - Fabric ワークスペースで Warehouse の Settings を開き、
SQL audit logsページに進み、Save events to SQL audit logsを有効化します。(Microsoft Learn) Events to recordで必要な event category または action group だけを選び、保持期間を設定します。最初から全部盛りにせず、監査要件に必要なものから始めるほうが安全です。(Microsoft Learn)- 複数の Warehouse で設定を揃えたいなら、REST API でも構成できます。運用標準化を考えるなら、ポータル設定だけで終わらせないほうが管理しやすいです。(Microsoft Learn)
Warehouse での確認は、まず sys.fn_get_audit_file_v2 で直近のイベントを引くのが実用的です。公式のパス形式に沿うと、たとえば次のように書けます。(Microsoft Learn)
SELECT TOP (100)
event_time,
session_server_principal_name,
database_principal_name,
object_name,
statement,
client_ip,
application_name,
duration_milliseconds,
affected_rows
FROM sys.fn_get_audit_file_v2(
'https://onelake.blob.fabric.microsoft.com/{workspaceId}/{warehouseId}/Audit/sqldbauditlogs/',
DEFAULT,
DEFAULT,
'2026-04-01T00:00:00Z',
'2026-04-05T00:00:00Z'
)
ORDER BY event_time DESC;この関数で見ておきたい列は、event_time、session_server_principal_name、object_name、statement、client_ip、application_name、duration_milliseconds、affected_rows です。sys.fn_get_audit_file_v2 は時間範囲で効率よく絞り込めるので、障害直前だけを抜き出す運用と相性がいいです。なお、Warehouse の SQL Audit は default workspace ではサポートされていません。(Microsoft Learn)
もうひとつ注意したいのが succeeded 列の解釈です。公式では、ログインイベント以外では 「操作そのものの成功・失敗」ではなく、permission check の成功・失敗を返す と説明されています。succeeded = 1 だけを見て「処理が完全に成功した」と断定しないほうが安全です。(Microsoft Learn)
Fabric を選ぶ理由は「監査が基盤の中で完結しやすい」こと
SQL 監査機能そのものは珍しくありません。Fabric で効くのは、監査ログの保存先、分析基盤、ガバナンス導線が同じエコシステムに寄っていることです。Fabric は shared compute / shared storage モデルで動く SaaS 型の分析基盤で、OneLake を共通データレイクとして使います。SQL Audit Logs も OneLake に保存され、Warehouse なら .XEL を SSMS で扱え、T-SQL でも読めます。(Microsoft Learn)
さらに Fabric 全体では Microsoft Purview を使った監査・ガバナンス導線があり、Fabric アイテム監査と SQL レベル監査を役割分担できます。つまり、「Fabric 上の操作」と「Warehouse / SQL analytics endpoint 内の操作」を別々の製品に飛ばさずに追いやすいわけです。データ基盤運用の現場では、この“監査の置き場所が散らばりにくい”こと自体が強みになります。(Microsoft Learn)
もちろん、これだけで万能とは言えません。高負荷や高ネットワーク負荷の期間には、選択したすべてのイベントが必ず記録されるとは限らないと公式に注意書きがあります。法令対応で「1件も漏れてはいけない」水準を求めるなら、この点を前提に追加統制まで設計する必要があります。(Microsoft Learn)
まとめ：最初の一歩は「全部ON」ではなく「必要なイベントから」
Fabric Warehouse SQL Audit Logs の GA で、Fabric Data Warehouse と SQL analytics endpoint の監査はかなり実務的になりました。認証、権限変更、スキーマ変更、実行された T-SQL、接続元情報まで追えるため、コンプライアンス対応にも、障害調査にも効きます。いっぽうで、既定でオフ、保持設計が必要、Warehouse 削除でログも消える、SQL analytics endpoint では Lakehouse DML を拾えない、といった注意点は導入前に押さえておくべきです。(Microsoft Learn)
最初にやることは3つで十分です。
- まず 1 つの Warehouse で SQL Audit Logs を有効化する
- ログイン、権限変更、オブジェクト変更、
Batch Was Completedから取り始める sys.fn_get_audit_file_v2で直近1週間を確認し、保持期間と退避方針を決める
この順番なら、ログだけ増えて誰も読まない状態を避けつつ、Fabric の監査を現実的な運用に乗せやすくなります。
コメント