複数の Microsoft Sentinel ワークスペースを運用している組織では、分析ルールやハンティングクエリ、Workbooks の更新を各ワークスペースへ手作業で反映する負担が大きくなりがちです。2026年6月24日に更新された Microsoft Learn の「Manage multiple Microsoft Sentinel workspaces with workspace manager」は、この課題に対して、中央ワークスペースから複数の Sentinel ワークスペースへコンテンツを一括配布する方法を整理した公式ドキュメントです。結論から言うと、workspace manager は大規模 SOC、グローバル企業、MSSP にとって有効な集中管理機能ですが、現時点ではプレビューであり、Playbook や一部の削除操作には未対応です。導入前に、対象コンテンツ、権限、テナント構成、Defender ポータル移行計画を必ず確認する必要があります。(Microsoft Learn)
Microsoft Sentinel の workspace manager とは
Microsoft Sentinel の workspace manager は、1つの中央ワークスペースを「親」として設定し、複数のメンバーワークスペースへ Sentinel コンテンツをまとめて配布・管理するための機能です。
従来、複数の Sentinel ワークスペースを運用する場合、分析ルール、ハンティングクエリ、Workbooks などをワークスペースごとに作成・更新する必要がありました。環境が数個であれば手作業でも対応できますが、国・地域別、事業部別、顧客別にワークスペースが分かれている場合、設定差分や反映漏れが発生しやすくなります。
workspace manager は、この「同じ検知・運用コンテンツを複数環境へ安全に展開したい」というニーズに向いています。公式ドキュメントでは、グローバル企業や Managed Security Services Provider、いわゆる MSSP が効率的に大規模運用するための機能として位置付けられています。(Microsoft Learn)
ただし、すべての Sentinel リソースを完全に集中管理できるわけではありません。現時点でサポートされている主なアクティブコンテンツは、分析ルール、Automation rules、パーサー、保存済み検索、関数、ハンティングクエリ、Workbooks です。Automation rules は対象ですが、Playbooks は除外される点に注意が必要です。(Microsoft Learn)
2026年6月24日更新で確認すべきポイント
今回の公式情報は、新しい製品名を大きく発表するタイプの更新ではなく、workspace manager の構成方法、利用手順、制限事項を実務向けに整理した内容です。管理者が特に見るべきポイントは、次の4つです。
| 確認ポイント | 内容 | 実務上の意味 |
|---|---|---|
| 提供状態 | workspace manager はプレビュー | 本番標準化に使う場合は、変更リスクとプレビュー条項を考慮する |
| 対象コンテンツ | 分析ルール、Automation rules、関数、ハンティングクエリ、Workbooks など | まず「横展開したい検知・可視化コンテンツ」を棚卸しする |
| 対象外 | Playbooks、BYOS に保存された Workbooks、中央削除など | SOAR 自動化まで完全に一元化できると誤解しない |
| 管理単位 | 中央ワークスペース、メンバーワークスペース、グループ | 地域・事業部・顧客単位で配布範囲を設計する |
特に重要なのは、workspace manager が「中央ワークスペースで管理しているコンテンツをメンバーワークスペースへ発行する仕組み」であり、メンバーワークスペース側でローカルに作成されたコンテンツまで自動的に統制する機能ではない点です。既存環境に手作業で作られたルールが多い場合は、まず中央管理対象にするルールと、各ワークスペース固有で残すルールを分ける必要があります。(Microsoft Learn)
影響範囲：どの組織が対応を検討すべきか
workspace manager の影響が大きいのは、複数の Microsoft Sentinel ワークスペースを継続運用している組織です。単一ワークスペースだけで Sentinel を使っている場合、すぐに設定変更が必要になるケースは多くありません。
一方で、次のような環境では導入検討の優先度が高くなります。
| 対象組織・環境 | workspace manager が効く理由 |
|---|---|
| グローバル企業 | 国・地域ごとに分かれた Sentinel ワークスペースへ共通ルールを配布しやすい |
| 複数事業部を持つ企業 | 事業部別の運用を残しつつ、全社共通の検知ルールを標準化できる |
| MSSP | 顧客別ワークスペースへ共通のハンティングクエリや Workbooks を展開しやすい |
| M&A 後の統合環境 | 子会社ごとのワークスペースを残したまま、段階的に運用標準をそろえられる |
| SOC の検知ルール管理が属人化している組織 | 中央ワークスペースを正本として、設定差分を減らせる |
例えば、日本、米国、欧州で別々の Sentinel ワークスペースを使っている企業では、ランサムウェア対策用の分析ルールを各地域に手動で作成すると、条件式や抑制設定に差分が生まれやすくなります。workspace manager を使えば、中央ワークスペースで管理したコンテンツをグループ単位で発行できるため、共通ベースラインの維持がしやすくなります。
前提条件：導入前に確認する権限と構成
workspace manager を使うには、少なくとも2つの Microsoft Sentinel ワークスペースが必要です。1つは中央管理用のワークスペース、もう1つ以上は管理対象となるメンバーワークスペースです。また、中央ワークスペースと管理対象ワークスペースの両方で Microsoft Sentinel Contributor ロールが必要です。複数の Microsoft Entra テナントをまたいで管理する場合は、Azure Lighthouse の利用も前提になります。(Microsoft Learn)
導入前には、次のように役割を整理しておくと失敗を避けやすくなります。
| 項目 | 確認内容 |
|---|---|
| 中央ワークスペース | どのワークスペースを配布元にするか |
| メンバーワークスペース | どのワークスペースを配布先にするか |
| 権限 | 中央・メンバー双方に Microsoft Sentinel Contributor があるか |
| テナント | 同一テナント内か、複数 Microsoft Entra テナントをまたぐか |
| 配布対象 | 分析ルール、関数、ハンティングクエリ、Workbooks などのうち何を共通化するか |
| 例外管理 | 各地域・各顧客固有のルールをどう扱うか |
よくある失敗は、中央ワークスペースを「何となく既存の本番ワークスペース」にしてしまうことです。中央ワークスペースは配布元の正本になります。検証中のルールや一時的な Workbooks が混在していると、不要なコンテンツを配布対象に含めるリスクがあります。可能であれば、共通コンテンツ管理用として役割を明確にしたワークスペースを選ぶか、既存ワークスペースを使う場合でも命名規則と承認プロセスを整えておくべきです。
設定変更の流れ
workspace manager の基本的な設定は、中央ワークスペースの有効化、メンバーワークスペースの追加、グループ作成、コンテンツ選択、発行という順序で進みます。
中央ワークスペースで workspace manager を有効化する
最初に、管理元にする Microsoft Sentinel ワークスペースを決めます。Azure ポータルの対象ワークスペースで Settings に移動し、workspace manager の構成設定をオンにして、このワークスペースを親として設定します。有効化後は、Configuration 配下に Workspace manager のメニューが表示されます。(Microsoft Learn)
ここでの判断基準は、「どのワークスペースを運用標準の正本にするか」です。単に管理者がよく使うワークスペースではなく、共通ルールをレビューし、配布前に検証できる体制があるワークスペースを選ぶことが重要です。
メンバーワークスペースを追加する
次に、workspace manager から Add workspaces を選び、管理対象にするメンバーワークスペースを追加します。追加後は、Workspaces タブで対象ワークスペースを確認できます。複数テナントをまたぐ場合は、Azure Lighthouse の構成と権限委任が正しくできているかも確認してください。(Microsoft Learn)
この段階では、いきなり全ワークスペースを追加するよりも、まず検証用または影響の小さいワークスペースを選ぶのが現実的です。特に本番 SOC で既存ルールが多い場合、配布後の重複アラートやクエリ負荷を確認してから対象を広げる方が安全です。
グループを作成し、配布対象を決める
workspace manager では、ワークスペースをグループ化して管理できます。公式ドキュメントでは、ビジネスグループ、業種、地理的条件などに基づいてワークスペースを整理できると説明されています。(Microsoft Learn)
例えば、次のようなグループ設計が考えられます。
| グループ例 | 向いている配布内容 |
|---|---|
| Global-Baseline | 全社共通の検知ルール、標準 Workbooks |
| Japan-SOC | 日本拠点向けの法令・業務要件に合わせたルール |
| EMEA-SOC | 欧州地域向けの監査・検知コンテンツ |
| MSSP-Customer-Tier1 | 標準監視サービスの顧客向けコンテンツ |
| High-Risk-Assets | 重要システム専用の高感度検知ルール |
グループ作成時には、中央ワークスペースに存在するアクティブなコンテンツを選択します。「All content」を選ぶと、その時点で中央ワークスペースに展開済みのアクティブコンテンツがスナップショットとして追加されます。テンプレートそのものではなく、アクティブなコンテンツが対象になる点を理解しておく必要があります。(Microsoft Learn)
グループ定義を発行する
グループを作成しただけでは、コンテンツはまだメンバーワークスペースへ反映されません。対象グループを選択し、Publish content を実行して初めて、選択したコンテンツがメンバーワークスペースに配布されます。発行後は、Last publish status で進行中、成功、失敗を確認できます。(Microsoft Learn)
発行が失敗した場合は、失敗リンクから詳細を確認できます。公式ドキュメントでは、失敗要因として、グループ定義で参照していたコンテンツが削除されている、発行時点で権限が変わっている、メンバーワークスペースが削除されている、といった例が挙げられています。(Microsoft Learn)
運用設計で重要な3つのアーキテクチャ
workspace manager では、複数の構成パターンが想定されています。公式ドキュメントでは、Direct-link、Co-Management、N-Tier の3つが示されています。(Microsoft Learn)
| 構成 | 概要 | 向いているケース |
|---|---|---|
| Direct-link | 1つの中央ワークスペースが複数のメンバーワークスペースを管理 | 単一SOCが全社ワークスペースを管理するケース |
| Co-Management | 複数の中央ワークスペースが同じメンバーワークスペースを管理 | 社内SOCとMSSPが同じ環境を共同管理するケース |
| N-Tier | 中央ワークスペースが別の中央ワークスペースを管理 | 持株会社、地域統括、子会社のような階層管理 |
最もシンプルなのは Direct-link です。初めて導入する場合は、Direct-link で小さく始めるのがよいでしょう。
Co-Management は便利ですが、責任分界が曖昧だと危険です。例えば、社内SOCが全社共通ルールを配布し、MSSPが顧客別の追加ルールを配布するような場合、どちらがどのルールを管理するのかを明文化しておかないと、意図しない上書きや重複検知につながります。
N-Tier は大規模組織向けです。親会社が全社標準を配り、地域統括会社が地域固有のルールを追加し、各子会社が個別運用を行うような構成に向いています。ただし、階層が深くなるほどトラブルシューティングは難しくなります。発行元、発行対象、変更承認者を台帳化しておくことが欠かせません。
制限事項：導入前に必ず把握したい注意点
workspace manager は便利ですが、現時点ではプレビュー機能です。Azure のプレビュー機能には追加条件が適用され、一般提供機能と同じ前提で長期運用を設計するのは避けるべきです。(Microsoft Learn)
特に重要な制限事項は次の通りです。
| 制限事項 | 管理者が取るべき対応 |
|---|---|
| 1グループあたりの発行操作は最大2,000 | メンバーワークスペース数 × コンテンツ数を事前に計算する |
| Playbooks は未対応 | SOAR は別途、ARM/Bicep、Terraform、リポジトリ運用などで管理する |
| BYOS に保存された Workbooks は未対応 | 対象 Workbooks の保存方式を確認する |
| メンバーワークスペースでローカル作成されたコンテンツは管理対象外 | 中央管理対象とローカル運用対象を分ける |
| メンバーワークスペース上のコンテンツ削除を中央から実行できない | 廃止ルールの削除手順を別途用意する |
発行操作数の上限は、実務では見落としやすいポイントです。計算式は「メンバーワークスペース数 × コンテンツ数」です。例えば、50ワークスペースに50個のコンテンツを配布しようとすると、50 × 50 = 2,500 となり、上限を超えます。こうした場合は、地域別・用途別にグループを分ける必要があります。(Microsoft Learn)
Defender ポータル移行との関係
Microsoft Sentinel を取り巻く大きな流れとして、Azure ポータルから Microsoft Defender ポータルへの移行があります。Microsoft Learn では、Microsoft Sentinel は Defender ポータルで一般提供されており、Microsoft Defender XDR や E5 ライセンスを使っていない顧客でも Defender ポータル上で Sentinel を利用できると説明されています。さらに、2027年3月31日以降、Microsoft Sentinel は Azure ポータルではサポートされず、Defender ポータルのみで利用可能になる予定です。(Microsoft Learn)
ここで注意すべきなのは、workspace manager の扱いです。Microsoft Sentinel in the Microsoft Defender portal のナビゲーション比較では、Azure ポータルの Configuration にある Workspace manager は、Defender ポータル側では「Not available」と示されています。つまり、workspace manager を使う計画と、Defender ポータル移行計画は分けて考える必要があります。(Microsoft Learn)
実務上は、次のように整理すると分かりやすくなります。
| 論点 | 確認すべきこと |
|---|---|
| Azure ポータル運用 | workspace manager を使う場合、現時点で Azure ポータル側の機能として確認する |
| Defender ポータル移行 | 2027年3月31日以降のサポート方針を踏まえ、移行計画を立てる |
| マルチテナント管理 | Defender ポータルでは Microsoft Defender multitenant management の利用も検討する |
| 機能差分 | Workspace manager、インシデント管理、Advanced hunting、RBAC の差分を確認する |
Defender ポータルでは、Microsoft Defender multitenant management により、複数テナントのインシデント、アラート、ケース、Advanced hunting を統合的に扱えます。各テナントでは、1つのプライマリワークスペースと複数のセカンダリワークスペースを接続できます。ただし、セカンダリワークスペースを別テナントからクエリする場合など、シナリオによって Azure Lighthouse が必要になります。(Microsoft Learn)
移行期限と管理者が今すぐ確認すべきこと
workspace manager 自体について、公式ドキュメント上で「この日までに移行が必須」といった個別の移行期限は示されていません。一方で、Microsoft Sentinel 全体としては、Azure ポータルから Defender ポータルへの移行期限が重要です。Microsoft Learn では、2027年3月31日以降、Azure ポータルでの Microsoft Sentinel はサポートされず、Defender ポータルのみで提供されるとされています。(Microsoft Learn)
そのため、管理者は「workspace manager を導入するか」だけでなく、「2027年3月31日以降の Sentinel 運用をどのポータル・どの管理方式で行うか」まで含めて確認する必要があります。
今すぐ確認すべき項目は次の通りです。
| 優先度 | 確認項目 | 具体的なアクション |
|---|---|---|
| 高 | Sentinel ワークスペース数 | 全テナント・全サブスクリプションの Sentinel 有効ワークスペースを棚卸しする |
| 高 | Azure ポータル依存 | Workspace manager、運用手順書、教育資料が Azure ポータル前提になっていないか確認する |
| 高 | 権限 | Microsoft Sentinel Contributor、Azure Lighthouse、Defender 側 RBAC を確認する |
| 中 | 共通コンテンツ | 全社標準化したい分析ルール、関数、Workbooks を洗い出す |
| 中 | ローカル例外 | 各国・各事業部・各顧客固有の検知ルールを分類する |
| 中 | 発行上限 | グループごとの発行操作数が2,000を超えないか計算する |
| 中 | SOAR | Playbooks が workspace manager の対象外であることを踏まえ、別管理方式を決める |
| 低 | 命名規則 | グループ名、ルール名、Workbook 名、関数名の標準を整備する |
実務でのおすすめ導入ステップ
workspace manager は、最初から全社展開するよりも、対象を絞って検証しながら広げる方が安全です。
小さなグループで検証する
まずは検証用または一部部門のワークスペースを使い、少数の分析ルールやハンティングクエリを配布します。この段階では、ルールの発行そのものだけでなく、アラート件数、クエリ実行負荷、インシデント生成の影響も確認します。
共通ルールと個別ルールを分ける
次に、中央管理すべきコンテンツと、各ワークスペースに残すべきコンテンツを分けます。全社共通の検知ロジックは workspace manager に向いていますが、地域固有のログソース、顧客固有の例外、検証中のルールまで中央配布すると、管理が複雑になります。
判断に迷う場合は、次の基準を使うと整理しやすくなります。
| ルール種別 | 管理方式の目安 |
|---|---|
| 全社共通の重大脅威検知 | workspace manager で中央配布 |
| 地域ごとの法令・監査要件 | 地域別グループで配布 |
| 顧客固有の監視要件 | MSSP 顧客グループまたはローカル管理 |
| 検証中の検知ルール | 中央配布せず検証環境で管理 |
| Playbook を含む自動対応 | workspace manager ではなく別の IaC やリポジトリ管理を検討 |
変更管理をルール化する
workspace manager を使うと一括配布が簡単になるため、逆に誤った変更も広範囲へ広がりやすくなります。中央ワークスペースに追加されたコンテンツを誰がレビューし、いつ発行し、失敗時に誰が戻すのかを決めておく必要があります。
最低限、次の運用ルールは用意しておきたいところです。
| 運用ルール | 内容 |
|---|---|
| 変更申請 | 新規ルール、更新、削除予定をチケット化する |
| 技術レビュー | KQL、エンティティマッピング、抑制条件、MITRE ATT&CK タグを確認する |
| 検証 | 代表ワークスペースでアラート件数と誤検知を確認する |
| 発行 | グループ単位で段階的に Publish content を実行する |
| 監視 | Last publish status と失敗詳細を確認する |
| 廃止 | 中央から削除できない対象は、別手順でメンバーワークスペース側を整理する |
よくある誤解と回避策
「複数ワークスペースのすべてを自動管理できる」と考えてしまう
workspace manager が管理するのは、中央ワークスペースから発行したコンテンツです。メンバーワークスペースでローカル作成されたコンテンツまで自動的に差分管理するわけではありません。既存環境では、まずローカルルールを棚卸しし、中央管理へ寄せるものと残すものを決める必要があります。
Playbook も一緒に配布できると思い込む
公式ドキュメントでは、分析ルールや Automation rules に付随する Playbooks は現時点でサポート対象外とされています。SOAR を含む完全な運用標準化を目指す場合は、workspace manager だけでなく、Microsoft Sentinel repositories、ARM/Bicep、Terraform、Azure DevOps、GitHub などを組み合わせた管理方式も検討してください。(Microsoft Learn)
発行上限を後から知る
発行操作数の上限は、ワークスペース数が増えるほどすぐに問題になります。10ワークスペース × 20コンテンツなら200ですが、100ワークスペース × 30コンテンツなら3,000です。上限に近づく場合は、事業部別、地域別、重要度別にグループを分ける設計が必要です。(Microsoft Learn)
Defender ポータル移行と混同する
workspace manager は複数 Sentinel ワークスペースのコンテンツ配布に関する機能です。一方、Defender ポータル移行は、Microsoft Sentinel 全体の利用ポータルと運用体験に関する変更です。2027年3月31日以降の Azure ポータル非サポートを踏まえると、短期的には workspace manager の活用可否を判断しつつ、中長期では Defender ポータルでのマルチワークスペース・マルチテナント運用へ移行計画を立てる必要があります。(Microsoft Learn)
管理者向けチェックリスト
最後に、管理者が実際に確認すべき項目をチェックリストとして整理します。
| チェック | 確認項目 |
|---|---|
| □ | Sentinel ワークスペースが2つ以上あるか |
| □ | 中央ワークスペースにする候補を決めたか |
| □ | 中央・メンバー双方で Microsoft Sentinel Contributor 権限があるか |
| □ | 複数テナント管理で Azure Lighthouse が必要か確認したか |
| □ | 配布対象の分析ルール、関数、ハンティングクエリ、Workbooks を棚卸ししたか |
| □ | Playbooks が workspace manager 対象外であることを運用担当者に共有したか |
| □ | グループごとの発行操作数が2,000を超えないか計算したか |
| □ | 発行失敗時の確認手順を用意したか |
| □ | Defender ポータル移行期限である2027年3月31日を踏まえた運用計画を作ったか |
| □ | Azure ポータル前提の手順書や教育資料を見直したか |
Microsoft Sentinel の workspace manager は、複数ワークスペース運用の標準化に役立つ機能です。特に、同じ検知ルールやハンティングクエリを複数環境へ展開している組織では、設定差分と運用負荷を減らせます。一方で、プレビュー機能であること、Playbooks や中央削除に未対応であること、Defender ポータルへの移行期限が別途存在することを見落としてはいけません。まずはワークスペースとコンテンツを棚卸しし、小さなグループで検証したうえで、全社または顧客単位の標準運用へ広げるのが現実的な進め方です。
コメント