Microsoft Fabric の Monitoring hub（監視ハブ）は、Fabric 内で実行されるジョブの状態、履歴、エラー詳細、スケジュール失敗通知を確認するための運用画面です。今回の結論は、2026年7月1日のドキュメント更新は主に用語整理であり、管理者が即時対応すべき強制的な設定変更や移行期限が示されたものではありません。ただし、監視ハブは Fabric 運用の一次確認画面として重要度が高く、特に「失敗したジョブの調査」「30日間の履歴確認」「スケジュール失敗通知」「Dataflow Gen1 非対応」「Spark notebook の Stopped 表示」の5点は、管理者が実務で確認しておくべきポイントです。GitHub の履歴では、2026年7月1日に monitoring-hub.md を含む管理系ドキュメントへ [SCOPED] Terminology review | Admin のコミットが入っており、該当ファイルは6行の表現修正が行われています。(GitHub)
Microsoft Fabric Monitoring hubとは
Microsoft Fabric Monitoring hub は、Fabric のジョブ実行状況を一元的に確認するためのハブです。Fabric のナビゲーションから「Monitor」を開くと、実行中・成功・失敗といったジョブ状態、開始時刻、実行時間、エラー詳細などを確認できます。公式ドキュメントでは、監視ハブを使って「現在のジョブ状態」「どこで失敗したか」「過去30日以内に同じジョブが失敗しているか」「失敗通知が設定されているスケジュール済みアイテムはどれか」を確認できると説明されています。(Microsoft Learn)
重要なのは、Monitoring hub が「すべての Fabric アクティビティを管理者だけが見る画面」ではない点です。どの Fabric ユーザーでも監視ハブを開けますが、表示されるのは自分が閲覧権限を持つ Fabric アイテムのアクティビティに限られます。つまり、グローバル組織で運用チームが一元監視したい場合は、Monitoring hub の使い方だけでなく、ワークスペース権限やアイテム権限の設計もセットで確認する必要があります。(Microsoft Learn)
2026年7月1日の更新ポイント
2026年7月1日の GitHub コミットでは、monitoring-hub.md に対して主に表記・用語の修正が行われています。具体的には、冒頭の説明が「Microsoft Fabric Monitor feature」から「Fabric Monitor feature」へ整理され、Spark Notebook の表記が「Spark notebook」に修正され、関連リンク名も「Job scheduler in Microsoft Fabric」から「Job scheduler in Fabric」に変更されています。(GitHub)
このため、2026年7月1日の更新を「監視ハブに新しい必須設定が追加された」「既存ジョブの監視方式が変わった」「移行期限が設定された」と読むのは適切ではありません。公開ページ側の Last updated 表示は 2026年3月20日で、7月1日の変更は GitHub 上のドキュメント整理として確認できます。実務上は、機能変更よりも「現在の公式仕様をもとに、監視ハブを運用手順へどう組み込むか」を見直すのが正しい対応です。(Microsoft Learn)
| 確認項目 | 管理者の判断 |
|---|---|
| 機能変更 | 2026年7月1日の差分は主に用語整理。UIや権限の強制変更として扱う必要は低い |
| 設定変更 | Monitoring hub を開くための新しいテナント設定変更は示されていない |
| 移行期限 | 指定ドキュメント内では新たな移行期限は示されていない |
| 実務上の重点 | 失敗通知、履歴確認、非対応アイテム、権限設計を確認する |
| グローバル運用 | 通知先、言語、UTC時刻、ワークスペース単位の監視ルールを整備する |
影響範囲：誰が確認すべきか
Monitoring hub の影響範囲は、Fabric 管理者だけに限られません。データエンジニア、ワークスペース管理者、運用監視チーム、サポート担当者まで関係します。
| 対象者 | 確認すべきポイント |
|---|---|
| Fabric 管理者 | 監視ハブの利用ルール、ワークスペース権限、通知先グループの設計 |
| Capacity 管理者 | ジョブ失敗が容量不足やスロットリングに関係していないか |
| ワークスペース管理者 | Pipeline、Notebook、Dataflow Gen2 などの失敗履歴と通知設定 |
| データエンジニア | 個別ジョブのエラー詳細、再実行結果、30日間の傾向 |
| ヘルプデスク・運用チーム | 障害連絡時に Activity ID、Request ID、実行時刻を確認する手順 |
| グローバル拠点の管理者 | 通知メールの言語、UTC時刻、B2B ゲストを含む通知先設計 |
Fabric 管理者と Power Platform 管理者は Fabric 管理タスク全体にアクセスでき、Capacity 管理者は担当容量に対してワークスペース割り当てや容量権限、ワークロード設定を管理できます。Monitoring hub の調査だけでは容量不足やスロットリングの根本原因まで見えない場合があるため、容量観点の調査では Microsoft Fabric Capacity Metrics app も併用するのが実務的です。(Microsoft Learn)
Monitoring hubで確認できる主なアクティビティ
Monitoring hub の Activities ページでは、ワークスペースをまたいでアクティブなジョブや最近完了したジョブを確認できます。公式ドキュメントでは、Activities ページに表示される Fabric アイテムとして、Copy Job、Dataflow Gen2、Dataflow Gen2 CI/CD、Datamart、Data Build Tool（dbt）Job、Digital Twin Builder Flow、Experiment、Graph model、Lakehouse、Map、Notebook、Pipeline、Semantic model、Snowflake database、Spark job definition、User data function などが挙げられています。(Microsoft Learn)
一方で、Dataflow Gen1 は Monitoring hub のテーブルに表示されません。既存環境で Dataflow Gen1 を多用している場合、「Fabric 全体を Monitoring hub で見れば十分」と判断すると監視漏れが起きます。Dataflow Gen1 の監視が必要な組織では、別の更新履歴確認方法を残すか、将来的に Dataflow Gen2 へ寄せる運用方針を検討する必要があります。(Microsoft Learn)
Activitiesページで見るべき項目
Activities ページでは、過去30日間の Fabric アクティビティが最大100件表示され、開始時刻の新しいものから並びます。また、テーブルには Fabric アイテムごとに最大100件のアクティビティが表示されます。実行頻度が高いジョブでは、メイン画面だけではすべての実行履歴を追い切れないことがあります。(Microsoft Learn)
実務では、次のように使い分けると調査が速くなります。
| 調査したいこと | 操作の目安 |
|---|---|
| 直近の失敗ジョブを探す | Status = Failed、Start time = Last 24 hours、Location = <workspace> で絞り込む |
| 特定ジョブの繰り返し失敗を調べる | 対象アクティビティの Historical runs を開く |
| エラー内容を確認する | 詳細ペインで状態、開始時刻、期間、エラー詳細を見る |
| 表示を運用向けに整える | Column Options で列を追加・削除・並べ替える |
| ワークスペース単位で調査する | Location フィルターで対象ワークスペースを指定する |
キーワード検索にも注意が必要です。Monitoring hub のキーワード検索は、データベース内のすべてのアクティビティを横断検索するものではなく、読み込まれているデータだけを検索します。見つからない場合は、検索語を変えるだけでなく、期間やワークスペースのフィルター条件を見直す必要があります。(Microsoft Learn)
Historical runsで30日間の傾向を見る
メインの Activities ページには、過去30日間の最新100件のみが表示されるため、頻繁に実行されるジョブではすべての実行が見えない場合があります。この場合は、対象アクティビティの「その他のオプション」から Historical runs を開くことで、そのアクティビティの最大30日分の履歴を確認できます。(Microsoft Learn)
たとえば、毎時実行される Dataflow Gen2 が断続的に失敗している場合、メイン画面だけを見ると「直近は成功しているから問題ない」と誤判断しがちです。Historical runs で30日分を確認すれば、特定時間帯だけ失敗しているのか、週次処理と重なったタイミングで失敗しているのか、最近になって失敗率が上がっているのかを判断しやすくなります。
Schedule failures（Preview）で失敗通知を一元管理する
Monitoring hub の重要な要素が、Schedule failures（スケジュール エラー）ページです。この機能はプレビューであり、一般提供前に変更される可能性があります。Schedule failures ページでは、失敗通知が設定されているスケジュール済みアイテムを一覧し、新規設定、受信者の編集、通知設定の削除を一元的に行えます。ジョブスケジューラ側で設定した通知と Schedule failures 側で設定した通知は同じ基盤設定であり、どちらで変更しても反映されます。(Microsoft Learn)
通知の受信者には、Microsoft Entra テナント内のユーザーまたはグループを指定できます。B2B ゲストユーザーも含められますが、直接外部メールアドレスを指定することはできません。グローバル企業では、個人メールアドレスを都度指定するよりも、地域別・サービス別の Entra グループを作成して通知先にする運用が安全です。(Microsoft Learn)
| 項目 | 内容 |
|---|---|
| 機能状態 | Preview。一般提供前に仕様が変わる可能性あり |
| 管理対象 | スケジュール済みアイテムの失敗通知 |
| 設定場所 | Monitoring hub の Schedule failures、または各アイテムのジョブスケジューラ |
| 通知先 | Microsoft Entra テナント内のユーザーまたはグループ、B2B ゲスト |
| 非対応 | 直接外部メールアドレス |
| 編集権限 | ワークスペースの Contributor 以上、またはアイテムへの Write 権限 |
| 注意点 | 通知はスケジュール実行の失敗のみ。手動実行の失敗は対象外 |
Schedule failures ページでは、Semantic model はまだサポートされていません。また、失敗通知はスケジュールされた実行にのみ適用され、手動実行や他の方法で開始された実行では通知がトリガーされません。Semantic model の更新監視や手動実行の失敗検知を別途運用している組織では、この制限を手順書に明記しておく必要があります。(Microsoft Learn)
設定変更は必要か
今回の Monitoring hub ドキュメント更新に関して、管理者がすぐにテナント全体の設定を変更しなければならない、という内容は確認できません。Monitoring hub は Fabric の Monitor から利用する運用機能であり、今回の7月1日差分も用語整理が中心です。
ただし、次の設定・権限は実務上見直す価値があります。
| 確認項目 | 見直す理由 |
|---|---|
| ワークスペース権限 | Monitoring hub で見えるアクティビティはユーザーの閲覧権限に依存するため |
| Contributor / Write 権限 | Schedule failures の通知設定を編集できるユーザーを制御するため |
| Entra グループ | 通知先を個人依存にしないため |
| スケジュール設定 | 失敗通知はスケジュール実行にのみ適用されるため |
| Dataflow Gen1 の利用状況 | Monitoring hub に表示されないため |
| Capacity Metrics app | ジョブ失敗の背景に容量過負荷やスロットリングがないか確認するため |
ジョブスケジューラ側にも運用上の制限があります。たとえば、各ユーザーのジョブ送信・取得要求には制限があり、Fabric では各アイテムに対して同時実行ジョブ数の上限があります。また、ユーザーが90日間連続して Fabric にログインしない場合、スケジュールが期限切れになります。退職者や異動者が所有しているスケジュールが残っている組織では、ジョブ所有者とスケジュールの棚卸しが重要です。(Microsoft Learn)
移行期限はあるか
指定ドキュメントの範囲では、Monitoring hub の更新に伴う新しい移行期限は示されていません。したがって、2026年7月1日の更新を理由に「いつまでに設定を切り替える必要がある」と案内するのは避けるべきです。
ただし、Dataflow Gen1 が Monitoring hub に表示されない点は、移行期限とは別に運用リスクです。今後、Fabric を中心にデータ統合・変換・監視を標準化する場合は、Dataflow Gen1 を残す業務と Dataflow Gen2 へ寄せる業務を分けて整理すると判断しやすくなります。
| 利用状況 | 推奨対応 |
|---|---|
| Dataflow Gen1 をほとんど使っていない | 新規作成は Dataflow Gen2 を優先し、Monitoring hub で監視できる構成に寄せる |
| Dataflow Gen1 が一部残っている | 対象ワークスペース、所有者、更新頻度、障害時連絡先を棚卸しする |
| Dataflow Gen1 が基幹業務に使われている | Monitoring hub 以外の監視手順を残しつつ、移行可否を個別評価する |
| 監視を一元化したい | Pipeline、Notebook、Dataflow Gen2 など Monitoring hub に表示されるアイテム中心に運用設計する |
Spark notebookのStopped表示に注意する
Spark notebook ジョブで jobType が NotebookInteractiveRun の場合、終了した notebook は Monitoring hub 上で Stopped と表示されます。これは一時的な UI のみの変更とされており、Stopped 状態ではフィルターできません。また、Monitoring hub のテーブル、Public Job Status API、ジョブイベントの間で状態が一致しない可能性があります。(Microsoft Learn)
この点は、運用チームが API と UI の結果を突き合わせる場面で問題になりやすいポイントです。たとえば、UI では Stopped と見えているのに、API 側では別の状態として返る可能性があります。障害調査では、Monitoring hub の表示だけで結論を出さず、詳細ペイン、ジョブイベント、必要に応じて関連 API の結果を合わせて確認する運用にしておくと安全です。
グローバル運用で押さえるべきポイント
グローバル向けに Microsoft Fabric を運用している場合、Monitoring hub の使い方は「画面を開いて確認する」だけでは不十分です。時差、通知言語、外部ユーザー、ワークスペース命名、権限分掌まで含めて設計する必要があります。
| 観点 | 実務上の対応 |
|---|---|
| 時刻 | 通知メールには実行時刻が UTC で含まれるため、インシデント記録も UTC と現地時刻を併記する |
| 言語 | 通知は受信者の Fabric アカウントの表示言語で送信され、フォールバックとして英語が使われる |
| 通知先 | 個人ではなく、地域別・業務別の Entra グループを使う |
| B2B ゲスト | 外部運用パートナーを入れる場合は、直接外部メールではなく B2B ゲストとして設計する |
| 権限 | 閲覧だけの担当者と通知設定を編集できる担当者を分ける |
| 手順書 | 日本語UIと英語UIの表記を併記する。例：Monitor / 監視、Activities / アクティビティ、Schedule failures / スケジュール エラー |
通知メールには、アイテム名と種類、Submitter、エラー詳細、UTC の実行時刻、Monitoring hub の詳細リンク、Activity ID、Request ID、タイムスタンプなどが含まれます。サポートチケットや社内インシデント管理に連携する場合は、これらの項目をテンプレート化しておくと、原因調査の初動が速くなります。(Microsoft Learn)
管理者が実施すべき確認手順
Monitoring hub の更新を受けて、管理者は次の順序で確認すると効率的です。
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 重要ワークスペースを洗い出す | 基幹レポート、ETL、外部連携、日次処理を優先する |
| 2 | Monitor から Activities を開く | 直近の失敗、実行中、長時間実行ジョブを確認する |
| 3 | Status = Failed、Start time = Last 24 hours で絞る | 日次監視で検知すべき失敗が見えているか確認する |
| 4 | Historical runs を開く | 断続的な失敗や性能劣化がないか30日単位で見る |
| 5 | Schedule failures を確認する | 失敗通知の受信者が最新の運用体制と一致しているか見る |
| 6 | Dataflow Gen1 を棚卸しする | Monitoring hub に出ない処理の監視漏れを防ぐ |
| 7 | Capacity Metrics app と照合する | 容量過負荷、スロットリング、ピーク時間帯の影響を確認する |
| 8 | 運用手順書を更新する | UI表記、通知先、エスカレーション条件、Activity ID の記録方法を明記する |
特に重要なのは、失敗通知の受信者です。退職者、異動者、個人アカウント、外部メールアドレスに依存した通知設計は、障害時の見落としにつながります。通知先は Entra グループへ寄せ、グループの所有者とメンバー更新ルールを定めておくと、長期運用に耐えやすくなります。
よくある誤解と対策
| 誤解 | 実際の注意点 |
|---|---|
| Monitoring hub を見ればすべての履歴が見える | メイン画面は最大100件。頻繁に実行されるジョブは Historical runs を使う |
| キーワード検索で全履歴を探せる | 検索対象は読み込まれたデータのみ。フィルター条件も見直す |
| 失敗通知はすべての失敗で送られる | 通知対象はスケジュール実行の失敗。手動実行は対象外 |
| 外部メールアドレスへ直接通知できる | 直接外部メールは非対応。Entra ユーザー、グループ、B2B ゲストを使う |
| Semantic model も Schedule failures で管理できる | Schedule failures ページではまだ Semantic model はサポートされていない |
| Dataflow Gen1 も一覧に出る | Dataflow Gen1 は Monitoring hub のテーブルに表示されない |
| UIの状態とAPIの状態は必ず一致する | Spark notebook の一部状態では不一致の可能性がある |
まとめ：まず失敗通知と監視漏れを点検する
Microsoft Fabric の Monitoring hub は、Fabric アクティビティの状態確認、履歴調査、エラー診断、スケジュール失敗通知の確認に欠かせない運用画面です。2026年7月1日の更新自体は主にドキュメント上の用語整理であり、強制的な設定変更や移行期限が追加されたものではありません。
管理者が次に取るべき行動は明確です。まず、重要ワークスペースの Activities を確認し、失敗ジョブをフィルターで抽出します。次に、Historical runs で30日間の傾向を見ます。そのうえで、Schedule failures の通知先を Entra グループ中心に整理し、Dataflow Gen1 や Semantic model など Monitoring hub だけでは監視しきれない対象を別途管理します。グローバル運用では、UTC時刻、通知言語、B2B ゲスト、権限分掌を手順書に落とし込むことが、監視漏れを防ぐ一番現実的な対策です。
コメント