Microsoft Sentinel と Microsoft Defender XDR を統合しようとした際に、Defender XDR コネクタで「One or more of your workspaces are onboarded to USX…」と表示され、Incidents/Alerts の設定が無効になるケースがあります。本記事では原因の考え方、切り分け、最短で復旧させる実務手順をまとめます。
現象：Defender XDR コネクタで Incidents/Alerts がグレーアウトする
Microsoft Sentinel（旧称 Azure Sentinel）と Microsoft Defender XDR（以下、Defender XDR）を連携させ、Sentinel 側にインシデントやアラートを取り込みたいのに、Microsoft Defender XDR Connector（Defender XDR コネクタ）の設定画面で次のようなメッセージが出て、Incidents / Alerts の設定が無効（変更できない）になることがあります。
One or more of your workspaces are onboarded to USX.
Incidents and alerts configuration is disabled.特に、公式手順に沿ってワークスペースのオンボード／オフボードや削除を何度か繰り返した後に発生しやすく、画面上は「このテナントには他のワークスペースは無いはず」「古い情報は削除したつもり」という状態でもブロックされ続けるのが厄介なポイントです。
この記事で扱う前提
- Sentinel のワークスペースを作り直した、移行した、削除した等の経緯がある
- Defender XDR コネクタでインシデント／アラートを取り込もうとしたが、設定が無効になっている
- 前提条件の確認や一般的なトラブルシューティングを試しても改善しない
「USX にオンボード済み」メッセージの意味を噛み砕く
このメッセージは、Defender XDR 側が「このテナントには USX という内部状態（統合運用の管理プレーン）にオンボードされたワークスペースが存在する」と判断していることを示します。USX オンボードが検出されると、Defender XDR コネクタのうちインシデント／アラートを送る設定が意図的に無効になります。
理由はシンプルで、同じインシデント／アラートが二重に流れたり、異なる経路で相互に競合したりすると、SOC 運用で「どれが正なのか」判断が崩れるためです。つまりこのメッセージは、“何かの経路で既に接続済み（または接続済みの残骸がある）”というサインです。
よくある誤解
- 誤解：「USX と表示されるなら、別のワークスペースが今もどこかに存在するはず」
- 実際：削除済みワークスペースへの内部的な関連付け（ゴースト接続）が残っているだけでも同じ表示になります
ユーザー側でできる切り分けチェックリスト
最終的に Microsoft 側の対応が必要になるケースでも、まずは「本当に自分で潰せる要因が残っていないか」を短時間で確認しておくと、サポートへの連絡がスムーズになります。以下は現場で効果が高い順に整理したチェックリストです。
| チェック項目 | 見る場所（例） | 判断ポイント | ユーザー側でできる対処 |
|---|---|---|---|
| 複数ワークスペースの存在 | Azure ポータル（全サブスクリプション横断で検索） | 同一テナントに Log Analytics ワークスペースが複数残っていないか | 不要なワークスペース／検証用を含めて棚卸し |
| Sentinel が有効なワークスペースの残存 | Sentinel の有効化状況（ワークスペース一覧） | 「使っていないが Sentinel が有効」なワークスペースがないか | 不要なら Sentinel を無効化（または運用設計に沿って統廃合） |
| Defender XDR 側の統合設定の残存 | Defender ポータルの設定画面 | 統合対象ワークスペースが表示されていないか／解除済みになっているか | 解除できる項目があれば解除し、反映を待つ |
| 権限不足・条件未達 | ロール割り当て、前提条件一覧 | コネクタ設定時に権限不足エラーが出ていないか | 最低限のロール（例：Sentinel 管理、セキュリティ管理）を再点検 |
| ブラウザやキャッシュの影響 | 同一操作を別プロファイル／別ブラウザで再現 | 同じテナントで必ず再現するか（環境依存か） | シークレット／別ブラウザで再試行（あくまで切り分け） |
ここで重要なのは、上のチェックで「本当にワークスペースは 1 つで、解除も済んでいるはず」と確認できても、メッセージが消えない場合があることです。その場合は、ユーザー側では見えないバックエンドの紐づけが原因になっている可能性が一気に高まります。
まず実施すべきこと：HAR とテナント ID を準備する
この事象は、画面上の設定だけでは原因が追いにくく、サポートへ投げる際に最短で原因特定→修復につなげるための「証跡セット」を先に揃えるのが効果的です。結論から言うと、ブラウザの HAR（ネットワークトレース）とテナント IDが最優先です。
なぜ HAR が必要なのか
- この画面はバックエンド API と通信して状態を判定しており、どの API で何が返ってきているかが原因特定の近道
- サポート／エンジニアリング側は、HAR から相関 IDや呼び出し先、失敗したリクエストの種類を辿れる
- 「再現します」「直りません」だけだと往復が増えがちだが、HAR があると最初の回答が具体化しやすい
HAR の採取手順（Edge / Chrome の例）
- 対象画面を開いた状態で開発者ツール（F12）を開く
- Network（ネットワーク）タブを開き、Preserve log（ログ保持）を有効にする
- 必要に応じて「Disable cache（キャッシュ無効）」をオンにする（切り分け目的）
- Defender XDR コネクタの画面で問題を再現させる（メッセージが出るまで）
- ネットワーク一覧を右クリックし「Save all as HAR with content」等で HAR を保存する
注意：HAR には要求ヘッダーやトークン等が含まれることがあります。サポートへ共有する前に、社内ルールに従って取り扱い、必要に応じて機微情報をマスキングしてください。
サポートに渡すと強い情報セット
| 情報 | 例 | 目的 |
|---|---|---|
| テナント ID | GUID | Microsoft 側がバックエンド状態（USX オンボード情報等）を照会するため |
| 対象ワークスペースのリソース ID | /subscriptions/…/resourceGroups/…/providers/Microsoft.OperationalInsights/workspaces/… | どのワークスペースでブロックが起きているかを特定するため |
| 発生日時（タイムゾーン込み） | YYYY-MM-DD HH:MM | ログ照合範囲を狭め、調査時間を短縮するため |
| 画面のスクリーンショット | エラーメッセージが見える状態 | 症状の確認と、UI/設定箇所の誤認防止 |
| HAR | ファイル一式 | API 失敗箇所・相関 ID・レスポンス内容の確認 |
この 5 点が揃うと、メールだけで解決に近づく場合もありますし、必要なら Teams セッションで「どこを見ているか」を共有して短時間で収束できます。
原因：削除済みワークスペースへの“ゴースト接続”が残っている
今回の核心はここです。画面上はワークスペースを削除していたり、統合設定を解除していたりしても、Defender XDR がバックエンドで保持している過去の関連付け情報が消えきらず、「削除済みのワークスペースに内部的に紐づいたまま」になることがあります。
この状態だと Defender XDR は「このテナントには USX にオンボード済みワークスペースが存在する」と判定し続けるため、Sentinel 側で新しくコネクタを設定しようとしても、Incidents / Alerts の設定が最初から無効化されます。ユーザーから見ると「存在しないはずのワークスペースがある扱い」になるため、原因が見えにくいわけです。
なぜ起きやすいのか（実務的な背景）
- オンボード／オフボードの処理は複数システムに跨り、非同期で反映されることがある
- Azure 側で先にワークスペースを削除してしまうと、Defender XDR 側の解除処理が追従できず、紐づけだけが残ることがある
- 検証で何度もやり直すほど、途中状態（解除待ち／反映待ち）が増え、整合性が崩れやすい
解決策：Microsoft 側でバックエンドの紐づけを修正してもらう
結論として、このタイプの問題はユーザー側操作だけでは直らないことがあります。最終的に、Microsoft（エンジニアリング）側でバックエンドの関連付け／設定を修正し、ゴースト状態をクリアすることで復旧します。
サポート依頼時に伝えるべき要点（コピペ用）
チケット本文には次の要点が入っていると、一次切り分けを飛ばして担当チームに届きやすくなります。
- 症状：Defender XDR コネクタで
One or more of your workspaces are onboarded to USX. Incidents and alerts configuration is disabled.が出て Incidents/Alerts が無効 - 背景：ワークスペースのオンボード／オフボード、削除、再作成を複数回実施した
- 依頼：USX オンボード状態（削除済みワークスペース含む）の残骸がないか、バックエンドの関連付けを調査しクリアしてほしい
- 添付：テナント ID、対象ワークスペースのリソース ID、発生日時、スクショ、HAR
復旧後に行う確認（運用視点）
| 確認項目 | 確認方法 | OK の状態 |
|---|---|---|
| コネクタの設定が有効化できる | Sentinel のデータ コネクタ画面で Incidents/Alerts が操作できるか | グレーアウトが解除され、保存できる |
| インシデントが流入する | Sentinel のインシデント一覧を監視 | Defender XDR 起点のインシデントが作成される |
| 重複の有無 | 同一事象で複数経路から来ていないか | インシデントが二重化しない |
| 運用ルールの整合 | ルール／自動化／SOAR の動作確認 | 期待どおりの優先度・担当割当・通知が行われる |
サポート側で修正後、反映に一定時間かかることがあります。復旧確認は「操作できるようになったか」だけでなく、運用に耐える形で正しく流入しているか（重複や欠落がないか）まで確認するのが安全です。
再発防止：ワークスペース移行／削除時の安全な順序
再発を防ぐ最大のポイントは、Azure 側でリソースを消す前に、Defender XDR 側での解除を先に完了させることです。特に移行（新ワークスペースへ乗り換え）では、「早く片付けたい」気持ちで古いワークスペースを先に削除しがちですが、それがゴースト接続の温床になります。
| 推奨順序 | 作業 | 目的 | 実務メモ |
|---|---|---|---|
| 1 | Defender XDR 側で統合（オンボード）解除／コネクタ解除を完了 | バックエンドの紐づけを先に外す | 解除後は反映待ちが発生することがあるため、余裕を持った計画にする |
| 2 | Sentinel 側でデータ コネクタや関連設定を整理 | 二重取り込みや残設定を防ぐ | 切替タイミングを決め、監視者・通知先も同時に更新 |
| 3 | 移行先ワークスペースで統合設定を新規に実施 | 新しい接続を正しい状態で確立 | まずは検証用でインシデントが入ることを確認し、その後に本番切替 |
| 4 | 最終的に Azure 側で古いワークスペース（必要なら RG も）を削除 | リソース棚卸しとコスト最適化 | 削除は最後。削除前にログ保持・監査要件・エクスポート要否を確認 |
移行プロジェクトでおすすめの運用ルール
- 「解除→確認→削除」をチェックリスト化し、担当者レビューを挟む
- 検証目的でオンボード／オフボードを繰り返す場合でも、反映完了を確認してから次の操作へ進む
- 切替当日は、インシデントの入口が「コネクタ」なのか「USX」なのかを運用メンバー全員に共有する
- 変更履歴（いつ、誰が、どのワークスペースを、どの設定で）を残す。後からのサポート依頼が圧倒的に早くなる
よくある質問
本当にサポート依頼が必須ですか？
「別ブラウザで試す」「権限を見直す」「他のワークスペースがないか棚卸しする」などで解決するケースもあります。ただし、今回のように削除済みワークスペースのゴースト接続が原因の場合、ユーザー側で触れる UI や API では修復できないことがあり、結果としてサポートが最短になります。
ワークスペースを同じ名前で作り直せば直りますか？
名前が同じでも、内部的には別リソースとして扱われます。ゴースト接続は「過去のリソース ID の紐づけ」が問題なので、名前を合わせただけでは根本原因が残る可能性があります。
「USX にオンボード済み」なら、どこかで既に取り込みが動いているのでは？
理屈としては「既に別経路で統合されている」可能性もありますが、今回のパターンでは実際には取り込みが動いていないのにブロックだけされていることがあります。まずは Sentinel 側でインシデントが作成されているか、Defender XDR 側で統合対象の表示があるかを確認し、「動いていないのにブロック」ならゴーストの疑いが濃厚です。
サポートに出すとき、どの製品の窓口が良いですか？
原因が「Defender XDR 側のオンボード状態（USX）に起因」しているため、Defender XDR と Sentinel の両方に跨る事象として扱われることが多いです。実務上は、現象が出ている画面（Defender XDR コネクタ）と、取り込み先（Sentinel）を明記し、担当チーム間でエスカレーションしてもらうのが現実的です。
まとめ：最短で復旧するための現場アクション
- このメッセージは「USX にオンボード済みワークスペースがある」という Defender XDR 側の判定で、Incidents/Alerts の設定が無効になる
- 本当にワークスペースが 1 つでも、削除済みワークスペースのゴースト紐づけで同じ症状が起きる
- まずは HAR とテナント ID を揃えてサポートに提示し、バックエンドの関連付けを調査・修正してもらう
- 再発防止は「Defender XDR 側の解除を先に完了してから Azure 側リソースを削除」が鉄則
Sentinel と Defender XDR の統合は、正しく繋がるとインシデント対応の速度と精度が上がります。一方で、ワークスペースの移行や削除を伴うと、目に見えないバックエンド状態が残りやすい領域です。焦って手順を飛ばさず、証跡（HAR）を取ってからサポートに繋げるのが、結果として最も早い解決策になります。
コメント