Microsoft Defender XDRのAdvanced HuntingでAADSignInEventsBetaまたはAADSpnSignInEventsBetaを使用している場合は、2026年10月19日までに新しいEntra ID表への移行準備が必要です。
置換先は、それぞれEntraIdSignInEventsとEntraIdSpnSignInEventsです。新しい表はすでに利用できるため、廃止日を待たずにクエリの動作確認を始められます。
Microsoft Defender内に保存されたクエリやカスタム検出は自動移行される予定です。一方、API、PowerShell、Azure Functions、SIEM連携など、Defender外で表名を直接参照している処理は自動では書き換わりません。さらに、一部の列やデータ型には違いがあるため、単純な表名置換だけで終わらせず、検索結果やアラート件数まで確認することが重要です。(Microsoft Learn)
AADSignInEventsBeta廃止とEntra ID表への移行概要
今回の変更では、ユーザーのサインインを記録する表と、サービスプリンシパルやマネージドIDのサインインを記録する表が、それぞれEntra IDの名称に統一されます。
| 用途 | 廃止される表 | 移行先の表 |
|---|---|---|
| ユーザーの対話型・非対話型サインイン | AADSignInEventsBeta | EntraIdSignInEvents |
| サービスプリンシパル・マネージドIDのサインイン | AADSpnSignInEventsBeta | EntraIdSpnSignInEvents |
| 旧表の廃止予定日 | 2026年10月19日 | 新表はすでに利用可能 |
EntraIdSignInEventsは、ユーザーによる対話型および非対話型サインインを調査するための表です。EntraIdSpnSignInEventsは、サービスプリンシパルとマネージドIDによるサインインを調査するために使用します。旧表と新表は2026年10月19日まで併存するため、現在は新旧クエリの結果を比較できる移行期間です。(Microsoft Learn)
自動移行されるクエリと手動対応が必要なクエリ
「Microsoftが自動移行する」と聞くと、すべての処理が自動的に修正されるように見えます。しかし、実際にはクエリの保存場所によって対応が分かれます。
| クエリや処理の保存場所 | 対応 |
|---|---|
| Microsoft Defenderに保存したAdvanced Huntingクエリ | 自動移行の対象 |
| Microsoft Defenderのカスタム検出ルール | 自動移行の対象 |
| Advanced Hunting APIから送信するKQL | 手動更新が必要 |
| PowerShellやPython内に記述したKQL | 手動更新が必要 |
| Azure FunctionsやAutomation Runbook | 手動更新が必要 |
| SIEM、SOAR、外部監視製品の連携設定 | 依存関係の確認と手動更新が必要 |
| GitHubやAzure DevOpsなどのリポジトリ | 手動更新が必要 |
| Wiki、手順書、運用テンプレートに保存したKQL | 手動更新が必要 |
Microsoftのスキーマ変更に関する説明では、Defender内に保存されたクエリやカスタム検出には名称変更が自動適用される一方、APIで実行するクエリやDefender外に保存されたクエリは更新が必要とされています。(Microsoft Learn)
したがって、移行作業ではDefenderポータルだけを見るのではなく、クエリを呼び出している外部コードや運用ツールまで棚卸しする必要があります。
EntraIdSignInEventsへの移行手順
旧表名を利用している場所を洗い出す
最初に、次の2つの文字列が使われている場所を検索します。
AADSignInEventsBeta
AADSpnSignInEventsBeta確認対象には、次のようなものがあります。
- Advanced Huntingの保存済みクエリ
- カスタム検出ルール
- Advanced Hunting APIを呼び出すプログラム
- PowerShell、Python、C#などのスクリプト
- Azure Functions、Logic Apps、Automation Runbook
- SIEMやSOARの検索ルール
- ダッシュボードやレポート
- GitHub、Azure DevOpsなどのソースコード
- 社内Wikiや手順書に掲載しているサンプルKQL
ローカルフォルダーやリポジトリをPowerShellで検索する場合は、次のように実行できます。
Get-ChildItem -Path . -Recurse -File -ErrorAction SilentlyContinue |
Select-String -Pattern 'AADSignInEventsBeta|AADSpnSignInEventsBeta' |
Select-Object Path, LineNumber, Line検索結果は、単に「修正するクエリ」の一覧として扱うのではなく、次のように分類すると移行漏れを防げます。
| 分類 | 例 | 対応方針 |
|---|---|---|
| Defender内の保存済みクエリ | Advanced Hunting、カスタム検出 | 自動移行後に結果を確認 |
| 外部から実行するクエリ | API、スクリプト、Runbook | 手動で表名とスキーマを修正 |
| 結果を加工する処理 | CSV出力、JSON解析、ダッシュボード | 出力列やデータ型を確認 |
| 文書内のクエリ | Wiki、設計書、手順書 | 新表名へ更新 |
表名を新しい名称へ置き換える
基本となる置換は次のとおりです。
AADSignInEventsBeta
↓
EntraIdSignInEventsAADSpnSignInEventsBeta
↓
EntraIdSpnSignInEvents共通する列だけを使用している単純なクエリであれば、表名を置き換えるだけで動作する可能性が高いでしょう。
ただし、AADSignInEventsBetaからEntraIdSignInEventsへの移行には、列の有無やデータ型の違いがあります。外部コードでは必ず次のスキーマ確認まで行ってください。
AADSignInEventsBetaとEntraIdSignInEventsの主な違い
EntraIdSignInEventsは単なる名称変更ではありません。旧表の主要な列を引き継ぎながら、新しい調査用の列が追加され、一部の列は削除または変更されています。
| 確認項目 | AADSignInEventsBeta | EntraIdSignInEvents | 移行時の対応 |
|---|---|---|---|
| デバイスID | AadDeviceIdとEntraIdDeviceId | EntraIdDeviceId | AadDeviceId参照を置換 |
TokenIssuerType | int | string | 数値で比較している条件を見直す |
| リスク詳細 | RiskDetailsあり | RiskDetailsなし | 新しいリスク列を使って条件を再設計 |
| サインイン時のリスク | なし | RiskLevelDuringSignIn | 必要に応じて検出条件に追加 |
| リスクイベント | なし | RiskEventTypes | リスク種別の調査に利用可能 |
| TLSクライアント識別 | なし | GatewayJA4 | JA4を使った調査が可能 |
| トークン識別 | なし | UniqueTokenId | トークン要求との関連付けに利用可能 |
| Global Secure Access経由 | なし | IsSignInThroughGlobalSecureAccess | GSA経由のサインイン判定が可能 |
| 時刻列 | Timestamp | TimestampとTimeGenerated | 既存KQLはTimestampを継続利用可能 |
| テナント・データソース情報 | 一部なし | TenantId、Type、SourceSystem | 外部連携時の出力列増加に注意 |
特に注意したいのが、TokenIssuerTypeのデータ型変更です。旧表では整数、新表では文字列として定義されています。そのため、次のような数値比較を外部クエリで使用している場合は、条件の見直しが必要です。
AADSignInEventsBeta
| where TokenIssuerType == 0新表で実際に格納されている値を確認してから、文字列による条件に変更します。
EntraIdSignInEvents
| where Timestamp > ago(7d)
| summarize SignInCount = count() by TokenIssuerType
| order by SignInCount descまた、旧表のRiskDetailsを直接参照しているクエリは、そのままでは移行できません。新表のRiskLevelDuringSignInやRiskEventTypesなどを確認し、元のクエリが何を検出しようとしていたのかに合わせて再設計します。
EntraIdSignInEvents
| where Timestamp > ago(7d)
| project
Timestamp,
AccountUpn,
IPAddress,
RiskLevelAggregated,
RiskLevelDuringSignIn,
RiskEventTypes,
RiskState
| take 100公式スキーマ上、EntraIdSignInEventsには旧表にない複数の列が追加されています。また、AadDeviceIdやRiskDetailsの扱い、TokenIssuerTypeのデータ型が異なります。(Microsoft Learn)
projectアクションを明示して外部連携を安定させる
外部のスクリプトやダッシュボードでは、クエリ結果の列数や列順を前提にしていることがあります。
新表には追加列があるため、すべての列をそのまま返すクエリは、移行後に出力スキーマが変わります。CSVの列位置やJSONのフィールド構成を固定的に処理している場合、表名を変更しただけでも連携が失敗する可能性があります。
外部連携用のクエリでは、必要な列をprojectで明示するのが安全です。
EntraIdSignInEvents
| where Timestamp > ago(1d)
| project
Timestamp,
AccountUpn,
Application,
ResourceDisplayName,
IPAddress,
ErrorCode,
CorrelationId列の順番まで固定されるため、CSV出力や後続の解析処理を安定させやすくなります。
AADSpnSignInEventsBetaからEntraIdSpnSignInEventsへの移行ポイント
サービスプリンシパルとマネージドIDのサインインを扱うEntraIdSpnSignInEventsでは、旧表の主要な列が維持され、新しい調査用の列が追加されています。
主な追加列は次のとおりです。
| 追加列 | 用途 |
|---|---|
IsConfidentialClient | Confidential Clientによるサインインかを判定 |
GatewayJA4 | TLS Client Helloから生成されたJA4フィンガープリント |
SessionId | サインインセッションの識別 |
UserAgent | 使用されたクライアントやエージェントの確認 |
UniqueTokenId | サインインとトークン要求の関連付け |
TenantId | 組織のEntra IDテナント識別 |
TimeGenerated | レコード生成日時 |
旧表の基本的な列だけを使用しているクエリであれば、表名の置換で移行しやすい構成です。ただし、出力列が増えるため、外部連携ではprojectによる列の固定を推奨します。(Microsoft Learn)
KQLの移行例
ユーザーのサインイン失敗を調査するクエリ
旧表を使用したクエリは次のようになります。
AADSignInEventsBeta
| where Timestamp > ago(7d)
| where ErrorCode != 0
| summarize
FailureCount = count(),
LastSeen = max(Timestamp)
by AccountUpn, IPAddress
| where FailureCount >= 5
| order by FailureCount desc移行後は、表名をEntraIdSignInEventsへ変更します。
EntraIdSignInEvents
| where Timestamp > ago(7d)
| where ErrorCode != 0
| summarize
FailureCount = count(),
LastSeen = max(Timestamp)
by AccountUpn, IPAddress
| where FailureCount >= 5
| order by FailureCount descこの例で使用しているTimestamp、ErrorCode、AccountUpn、IPAddressは新表にも存在するため、基本的には表名の置換で対応できます。
サービスプリンシパルのサインイン失敗を確認するクエリ
EntraIdSpnSignInEvents
| where Timestamp > ago(7d)
| where ErrorCode != 0
| summarize
FailureCount = count(),
LastSeen = max(Timestamp),
Resources = make_set(ResourceDisplayName, 20)
by ServicePrincipalId,
ServicePrincipalName,
IPAddress,
IsManagedIdentity
| order by FailureCount descこのクエリでは、失敗したサインインをサービスプリンシパル単位で集計できます。ServicePrincipalIdを含めることで、表示名が同じサービスプリンシパルが存在する場合でも識別しやすくなります。
新旧表の件数を比較するクエリ
旧表と新表が併存している期間は、同じ時間範囲で結果件数を比較できます。
let StartTime = ago(24h);
union withsource=SourceTable
(
AADSignInEventsBeta
| where Timestamp >= StartTime
| project Timestamp, AccountObjectId, AccountUpn, ErrorCode
),
(
EntraIdSignInEvents
| where Timestamp >= StartTime
| project Timestamp, AccountObjectId, AccountUpn, ErrorCode
)
| summarize
Records = count(),
Accounts = dcount(AccountObjectId),
Failures = countif(ErrorCode != 0)
by SourceTable比較する項目は、単純な総件数だけでは不十分です。少なくとも次の数値を確認します。
- 全サインイン件数
- 一意のユーザー数
- 失敗件数
- 高リスクと判定された件数
- 特定の国やIPアドレスからの件数
- カスタム検出が生成したアラート件数
件数に大きな差がある場合は、列のデータ型、フィルター条件、対象期間、joinやprojectの処理を順番に確認します。
カスタム検出は自動移行後も動作確認が必要
Microsoftは、旧表を使用するカスタム検出について、手動変更は不要と案内しています。2026年10月19日に、対応するEntra ID表へ自動移行される予定です。(Microsoft Learn)
ただし、自動移行は「移行後の検出内容が運用上も完全に同じである」ことを保証する確認作業の代わりにはなりません。
移行後は、次の項目を確認してください。
| 確認項目 | 確認内容 |
|---|---|
| クエリの実行状態 | 構文エラーや列参照エラーがないか |
| アラート件数 | 移行前と比べて急増・急減していないか |
| 対象エンティティ | ユーザー、IPアドレス、アプリが正しく関連付けられているか |
| アラート詳細 | カスタム詳細や動的タイトルに必要な値が表示されるか |
| 自動対応 | デバイス隔離やユーザー無効化などのアクションが想定どおりか |
| 通知・連携 | SIEM、メール、チケットシステムへの通知が継続しているか |
特に、アラート件数がゼロになった場合は、表名だけでなく、旧表固有の列や数値型のフィルターを使用していないか確認します。
移行で失敗しやすいポイント
Defenderポータルだけを確認して終える
保存済みクエリやカスタム検出が自動移行されても、外部のAPIクライアントやスクリプトは別です。
クエリを呼び出すコードだけでなく、設定ファイル、環境変数、JSONテンプレート、TerraformやBicepなどのデプロイ定義も検索してください。
表名だけを一括置換する
単純な表名置換で動くクエリは多いものの、TokenIssuerType、AadDeviceId、RiskDetailsなどに依存している場合は追加修正が必要です。
一括置換後は、少なくとも次の文字列を再検索します。
AadDeviceId
RiskDetails
TokenIssuerTypeTokenIssuerTypeを数値のまま比較する
旧表のTokenIssuerTypeは整数、新表では文字列です。
数値比較を残したまま移行すると、型の不一致でエラーになるか、想定した結果を取得できない可能性があります。まずsummaryで実際の値を列挙し、その後にフィルターを書き換えます。
projectを使用せず、すべての列を外部へ渡す
新表には追加列があります。
列数や列順に依存するCSV処理、Power BI、PythonのDataFrame処理、固定スキーマのデータベース登録などでは、必要な列をprojectで明示してください。
廃止日直前まで旧表を使い続ける
2026年10月19日まで待つと、問題が起きた際に新旧表を比較できる期間がほとんど残りません。
新しい表はすでに利用可能です。現在のうちに外部クエリを新表へ切り替え、旧表は比較確認のためだけに残す進め方が安全です。
新しいEntra ID表にデータが表示されない場合
EntraIdSignInEventsとEntraIdSpnSignInEventsのデータを収集・表示するには、Microsoft Entra ID P2ライセンスが必要とされています。新表にデータが出ない場合は、まず対象テナントのライセンス条件を確認してください。(Microsoft Learn)
そのうえで、次の順番で切り分けます。
- 同じ時間範囲で旧表にデータがあるか確認する
- クエリの時間条件を広げる
where句を外して新表のレコード自体が存在するか確認する- 使用している列が新表に存在するか確認する
- API実行時は、送信しているKQLが新表名になっているか確認する
- 外部処理でレスポンスの列やデータ型を固定していないか確認する
最初から複雑な検出クエリを実行するのではなく、次の最小クエリでデータの有無を確認すると切り分けやすくなります。
EntraIdSignInEvents
| where Timestamp > ago(24h)
| take 10サービスプリンシパルの場合は、次のクエリを使用します。
EntraIdSpnSignInEvents
| where Timestamp > ago(24h)
| take 102026年10月19日までに行う移行チェックリスト
- [ ]
AADSignInEventsBetaを使用している場所を検索した - [ ]
AADSpnSignInEventsBetaを使用している場所を検索した - [ ] Defender外に保存されたKQLを洗い出した
- [ ] API、スクリプト、Runbookの表名を変更した
- [ ]
AadDeviceIdをEntraIdDeviceIdへ変更した - [ ]
RiskDetailsを使用する処理を見直した - [ ]
TokenIssuerTypeの数値比較を見直した - [ ] 外部連携用クエリで出力列を明示した
- [ ] 新旧表の結果件数を比較した
- [ ] カスタム検出のアラート件数を確認した
- [ ] ダッシュボード、CSV、JSON解析の動作を確認した
- [ ] 運用手順書やサンプルKQLを更新した
AADサインイン表の移行は表名置換とスキーマ確認をセットで行う
AADSignInEventsBetaとAADSpnSignInEventsBetaは、2026年10月19日にそれぞれEntraIdSignInEventsとEntraIdSpnSignInEventsへ置き換えられる予定です。
Defender内の保存済みクエリとカスタム検出は自動移行されますが、API、スクリプト、外部連携、リポジトリ内のKQLは手動対応が必要です。
まず旧表名を組織内で横断検索し、外部管理しているクエリを新表へ変更してください。その後、TokenIssuerTypeのデータ型、AadDeviceId、RiskDetails、追加された出力列を確認し、新旧表の件数とカスタム検出のアラート数を比較します。
新しい表はすでに利用できます。旧表と比較できる移行期間を活用し、2026年10月19日より前に本番クエリの切り替えを完了させるのが安全です。
コメント