azure.mgmt.securityinsight.models.MicrosoftSecurityIncidentCreationAlertRuleTemplateProperties class は、Microsoft Sentinel（Azure Security Insights）で「Microsoft Security のアラートからインシデントを作成するルールテンプレート」の条件や状態を扱う Python SDK のモデルです。結論から言うと、管理者は どの Microsoft 製品のアラートを、どの重大度・表示名条件でインシデント化するか を確認し、開発者は SDK 2.x プレビュー利用時にテンプレート情報が properties 配下へ移る点 を重点的に確認する必要があります。
2026年6月2日の公式ドキュメント更新では、対象クラスのソース履歴に同日の CI Update が確認でき、公式リファレンス上でも MicrosoftSecurityIncidentCreation rule template properties として、テンプレートの状態、必須データコネクタ、製品・重大度・アラート名フィルターなどが整理されています。これは単なるクラス名の確認ではなく、Microsoft Sentinel のインシデント作成ルールを自動展開・監査している環境では、設定ミスや重複インシデントを防ぐための確認ポイントになります。(GitHub)
MicrosoftSecurityIncidentCreationAlertRuleTemplateProperties classとは
MicrosoftSecurityIncidentCreationAlertRuleTemplateProperties は、Microsoft Sentinel の「Microsoft Security インシデント作成ルールテンプレート」に含まれるプロパティを表すモデルです。ルールそのものを実行するクラスではなく、テンプレートがどの製品・どの重大度・どのアラート名を対象にインシデントを作成する想定なのかを読み取るための情報を持ちます。
公式リファレンスでは、主な変数として alert_rules_created_by_template_count、last_updated_date_utc、created_date_utc、description、display_name、required_data_connectors、status、display_names_filter、display_names_exclude_filter、product_filter、severities_filter が示されています。特に status は "Installed"、"Available"、"NotAvailable" の既知値を持つため、テンプレートを使える状態かどうかを判断する材料になります。(Microsoft Learn)
実務では、このクラスを次のような用途で使います。
| 利用シーン | 具体的に確認すること |
|---|---|
| Sentinel ルールの棚卸し | どのテンプレートからアクティブルールが作成されているか |
| インシデント増加の原因調査 | severities_filter や display_names_filter が広すぎないか |
| IaC・自動展開の検証 | Python SDK のプロパティ名と REST API の JSON 名が対応しているか |
| Defender ポータル移行前の確認 | Sentinel 側のインシデント作成ルールが今後も必要か |
| SOC 運用のノイズ削減 | 不要なアラート名や低重大度アラートを除外できているか |
2026年6月2日の更新で見るべき変更点
今回のポイントは、脆弱性修正のような緊急セキュリティパッチではなく、Microsoft Sentinel のインシデント作成ルールテンプレートを SDK/API 経由で扱う際の確認項目です。
対象クラス単体では、サービスの挙動変更や破壊的変更が明示されているわけではありません。一方で、同時期の azure-mgmt-securityinsight 2.0.0b3 はプレビュー版として公開されており、Python 3.10 以上が必要、クライアント名の変更、モデル構造の変更など、開発者に影響する変更が含まれています。PyPI では 2.0.0b3 が 2026年5月29日リリースとして表示され、リリース履歴では 2.0.0b3 の変更として SecurityInsights から SecurityInsightsMgmtClient へのリネームや、複数モデルのインスタンス変数が properties 配下へ移動したことが示されています。(PyPI)
| 確認項目 | 変更・注意点 | 対応 |
|---|---|---|
| 公式リファレンス | 対象クラスのドキュメントソースに 2026年6月2日の更新履歴あり | 自社ドキュメントや型定義メモを更新する |
| SDK バージョン | 2.0.0b3 はプレビュー版で Python 3.10 以上が必要 | 本番導入前に検証環境で固定バージョンを指定する |
| クライアント名 | SecurityInsights から SecurityInsightsMgmtClient へ変更 | import 文と生成コードを確認する |
| モデル構造 | MicrosoftSecurityIncidentCreationAlertRuleTemplate の主要値が properties 配下へ移動 | template.product_filter ではなく template.properties.product_filter のような参照に修正する |
| Sentinel 運用 | Defender XDR 統合や Defender ポータル移行の有無で適用すべきルールが変わる | 既存のインシデント作成ルールを棚卸しする |
プロパティ別に見る影響範囲
Python SDK のプロパティ名は snake_case、REST API の JSON プロパティ名は camelCase です。ARM テンプレート、Bicep、Terraform、Python スクリプトを併用している環境では、ここを混同すると設定差分の検出や自動展開でミスが起きます。REST API では Microsoft Security Incident Creation Alert Rule Template として properties.productFilter、properties.severitiesFilter、properties.displayNamesFilter などが定義されています。(Microsoft Learn)
| Python SDK のプロパティ | REST API 側の主な対応 | 管理・開発での見方 |
|---|---|---|
alert_rules_created_by_template_count | properties.alertRulesCreatedByTemplateCount | そのテンプレートから作成済みのルール数を把握する |
created_date_utc | properties.createdDateUTC | テンプレートが追加された時期を確認する |
last_updated_date_utc | properties.lastUpdatedDateUTC | テンプレート更新後に既存ルールの見直しが必要か判断する |
description | properties.description | ルールの目的を説明文から確認する |
display_name | properties.displayName | ポータル上の表示名や運用台帳と突き合わせる |
required_data_connectors | properties.requiredDataConnectors | 必要なデータコネクタが有効か確認する |
status | properties.status | Installed、Available、NotAvailable の状態を確認する |
display_names_filter | properties.displayNamesFilter | インシデント化するアラート名を限定する |
display_names_exclude_filter | properties.displayNamesExcludeFilter | インシデント化しないアラート名を除外する |
product_filter | properties.productFilter | 対象の Microsoft セキュリティ製品を指定する |
severities_filter | properties.severitiesFilter | High / Medium など重大度で対象を絞る |
注意したいのは、product_filter の既知値に旧製品名が含まれる点です。公式リファレンスでは "Microsoft Cloud App Security"、"Azure Security Center"、"Azure Advanced Threat Protection"、"Azure Active Directory Identity Protection"、"Azure Security Center for IoT"、"Office 365 Advanced Threat Protection"、"Microsoft Defender Advanced Threat Protection" などが挙げられています。現在のポータル表示名と API 上の値が必ずしも同じ表現とは限らないため、UI の新名称をそのままコードに書かず、実際に返ってきた値を基準にしてください。(Microsoft Learn)
管理者が確認すべき設定ポイント
必須データコネクタが有効か確認する
required_data_connectors は、そのテンプレートを正しく動かすために必要なデータソースを示します。Microsoft Sentinel では、Microsoft セキュリティ製品を接続しても、アラートが自動で Sentinel インシデントになるとは限りません。公式ドキュメントでは、接続された Microsoft セキュリティソリューションのアラートは SecurityAlert テーブルに取り込まれ、その後、インシデント作成を構成できると説明されています。(Microsoft Learn)
確認すべき流れは次の通りです。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| データコネクタ確認 | 対象製品のコネクタが接続済みか | Sentinel の Content hub / Data connectors で有効 |
| テンプレート状態確認 | status が Available または Installed か | NotAvailable の場合は前提条件不足を疑う |
| アラート流入確認 | SecurityAlert テーブルに対象製品のアラートがあるか | ProductName、AlertSeverity、AlertName で確認 |
| ルール作成確認 | テンプレートからアクティブルールが作成されているか | Analytics の Active rules と照合 |
| インシデント確認 | 期待した重大度・名前のアラートだけがインシデント化されているか | Incident queue と SecurityAlert を突き合わせる |
フィルター条件の重複を避ける
severities_filter と display_names_filter は便利ですが、広く設定しすぎると SOC のノイズが増えます。たとえば、Microsoft Defender for Identity の High だけをインシデント化するつもりが、Medium も含めてしまうと、調査対象が一気に増える可能性があります。
一方で、絞り込みすぎると重要なアラートを取りこぼします。特に display_names_filter はアラート名に依存するため、製品側でアラート名が変わった場合にヒットしなくなるリスクがあります。Microsoft Sentinel の SecurityAlert スキーマでは、AlertName、DisplayName、AlertSeverity、ProductName などの列が定義されていますが、アラートは複数のソースから来るため、すべてのフィールドがすべてのプロバイダーで使われるとは限らないと説明されています。(Microsoft Learn)
展開前には、次のような KQL で実データを確認してからフィルターを決めると安全です。
SecurityAlert
| where TimeGenerated > ago(14d)
| summarize Alerts=count() by ProductName, AlertSeverity, AlertName
| order by Alerts desc除外フィルターを使う場合は、次の観点でレビューしてください。
| 確認観点 | 失敗しやすい例 | 対応 |
|---|---|---|
| アラート名の完全一致 | 表記ゆれや名称変更で対象外になる | 直近 14〜30 日の AlertName を確認する |
| 重大度の範囲 | High のみ想定なのに Medium も含める | severities_filter を明示する |
| 製品名 | UI の新名称を API 値として使う | product_filter は実際の返却値を採用する |
| 複数ルール | 同じ製品・同じ重大度を複数ルールで処理する | フィルターが相互排他的か確認する |
| 除外条件 | display_names_exclude_filter で重要アラートまで除外する | 除外後の件数を KQL で検証する |
Microsoft Sentinel では、フィルターが互いに重複しない場合に限り、同じ Microsoft セキュリティサービス種別に対して複数の Microsoft Security analytics rule を作成しても重複インシデントを作らない、と説明されています。つまり、複数ルールを使うなら「High 用」「Medium 用」のように条件が明確に分かれている必要があります。(Microsoft Learn)
Defender XDR 統合・Defender ポータル移行の有無を確認する
特に重要なのが、Microsoft Defender XDR incident integration を有効にしている環境、または Microsoft Sentinel を Microsoft Defender portal にオンボードしている環境です。公式ドキュメントでは、このような環境では Microsoft Defender XDR が Microsoft サービス由来のアラートからインシデントを作成するため、Sentinel 側の「Microsoft security alerts から自動でインシデントを作る」手順は適用されないと説明されています。(Microsoft Learn)
また、Microsoft Sentinel の Azure portal サポートは 2027年3月31日以降終了し、Defender portal での利用に移行する予定であることも公式ドキュメントで案内されています。移行計画がある場合は、既存の Microsoft Security incident creation rule をそのまま残すのではなく、Defender XDR 側のインシデント生成や scheduled analytics rules への置き換えが必要かを確認してください。(Microsoft Learn)
開発者が確認すべき移行ポイント
SDK 2.x プレビューを本番へ直接上げない
azure-mgmt-securityinsight 2.0.0b3 はプレビュー版です。PyPI のメタ情報では Python 3.10 以上が必要とされ、リリース履歴には hybrid models、メソッド変更、モデル構造変更などの breaking changes が記載されています。既存環境が Python 3.8 や 3.9 の場合、単純なパッケージ更新で動かなくなる可能性があります。(PyPI)
まずは現在のバージョンを確認します。
python -m pip show azure-mgmt-securityinsight
python --version検証環境で 2.0.0b3 を試す場合は、依存関係を明示的に固定します。
python -m pip install "azure-mgmt-securityinsight==2.0.0b3"
python -m pip install azure-identity本番では、requirements.txt や pyproject.toml にバージョン範囲を曖昧に書かないことが重要です。特に >=1.0.0 のような指定は、CI/CD のタイミングによってプレビュー版や将来の破壊的変更を拾うリスクがあります。
properties 配下の参照に直す
2.0.0b3 のリリース履歴では、MicrosoftSecurityIncidentCreationAlertRuleTemplate の alert_rules_created_by_template_count、last_updated_date_utc、created_date_utc、description、display_name、required_data_connectors、status、display_names_filter、display_names_exclude_filter、product_filter、severities_filter が、MicrosoftSecurityIncidentCreationAlertRuleTemplateProperties 型の properties 配下へ移動したとされています。(PyPI)
そのため、既存コードに次のような参照がある場合は注意が必要です。
# 旧構造を前提にした参照例
product = template.product_filter
severities = template.severities_filter2.x プレビューの構造では、次のように properties を経由する想定でコードを見直します。
# 2.x プレビューでの参照イメージ
props = template.properties
product = props.product_filter
severities = props.severities_filter
included_names = props.display_names_filter
excluded_names = props.display_names_exclude_filter
status = props.status単純な置換で終わらせず、properties が None になる可能性や、各フィルターが未設定の場合の扱いもテストしてください。たとえば severities_filter is None を「すべての重大度」とみなすのか、「未設定なのでエラー」とみなすのかは、自社のデプロイポリシーとして明確にしておくべきです。
REST API・IaC・Python のプロパティ名を混同しない
Python SDK では display_names_filter、REST API や ARM JSON では displayNamesFilter のように表記が変わります。REST API では Microsoft Security Incident Creation Alert Rule Template の kind が Microsoft Security Incident Creation とされ、properties.displayNamesFilter、properties.displayNamesExcludeFilter、properties.productFilter、properties.severitiesFilter などが定義されています。(Microsoft Learn)
IaC と Python SDK を併用する場合は、次のルールで整理するとレビューしやすくなります。
| 利用場所 | 使う表記 | 例 |
|---|---|---|
| Python SDK | snake_case | product_filter |
| REST API / ARM / Bicep | camelCase | productFilter |
| Sentinel ポータル | 表示名 | Microsoft security service、Filter by severity など |
| Log Analytics / KQL | テーブル列名 | ProductName、AlertSeverity、AlertName |
コードレビューでは、「Python のプロパティ名をそのまま ARM JSON に入れていないか」「REST API の camelCase を Python モデルに渡していないか」を確認してください。
展開前に確認すべきチェックリスト
| チェック項目 | OK の基準 |
|---|---|
| SDK バージョン | azure-mgmt-securityinsight の固定バージョンが明記されている |
| Python バージョン | 2.0.0b3 を使う場合は Python 3.10 以上 |
| クライアント名 | SecurityInsightsMgmtClient への変更を反映済み |
| モデル参照 | template.properties.product_filter など新構造に対応済み |
| 必須コネクタ | required_data_connectors に対応するコネクタが有効 |
| テンプレート状態 | status が想定どおりで、NotAvailable を無視していない |
| 製品名 | product_filter は実際の API 値を使っている |
| 重大度 | severities_filter が SOC の運用基準と一致している |
| アラート名 | display_names_filter / display_names_exclude_filter を KQL で検証済み |
| 重複ルール | 同一製品に複数ルールを作る場合、条件が相互排他的 |
| Defender 移行 | Defender XDR 統合や Defender portal オンボードの有無を確認済み |
| 自動化ルール | インシデント作成条件の変更が playbook や automation rule に与える影響を確認済み |
| ロールバック | 旧 SDK バージョン・旧ルール設定へ戻す手順がある |
Automation rule を利用している環境では、インシデント作成条件の変更が後続処理に影響します。Microsoft Sentinel の automation rules は、インシデント作成・更新やアラート作成をトリガーに実行されるため、どのアラートをインシデント化するかを変えると、担当者割り当て、タグ付け、playbook 実行、ノイズ抑制などの自動処理も変わります。(Microsoft Learn)
よくある失敗と回避策
旧製品名を「間違い」と判断して書き換える
product_filter の既知値には、現在のブランド名と異なる旧名称が含まれることがあります。これは API 互換性のために残っている値である可能性があるため、ポータル表示に合わせて独自に書き換えないでください。実際のテンプレートや SecurityAlert テーブルの ProductName を確認し、コードでは返却値に合わせるのが安全です。
display_names_filter だけで精密に制御しようとする
アラート名フィルターは便利ですが、名称変更・ローカライズ・製品側の検知ロジック変更に弱い設定です。基本は product_filter と severities_filter で大枠を決め、どうしても必要な場合だけ display_names_filter や display_names_exclude_filter を使う方が運用しやすくなります。
SDK のプレビュー版を CI で自動取得する
pip install azure-mgmt-securityinsight --pre や広すぎる依存指定を CI で使うと、検証していない SDK が入る可能性があります。特に 2.x 系では client 名やモデル構造の変更があるため、IaC 生成、監査スクリプト、棚卸しバッチがまとめて失敗するリスクがあります。
Sentinel 側と Defender XDR 側で二重に考える
Defender XDR incident integration や Defender portal へのオンボードが進んでいる環境では、Microsoft サービス由来のインシデント生成の責任分界が変わります。Sentinel の Microsoft Security incident creation rule を増やす前に、「どの製品のアラートをどちらがインシデント化するのか」を運用設計として確認してください。
まず実施すべきアクション
まず、対象ワークスペースで Microsoft Security incident creation rule template を棚卸しし、product_filter、severities_filter、display_names_filter、display_names_exclude_filter の現在値を一覧化してください。次に、SecurityAlert テーブルで直近のアラート実績を確認し、フィルター条件が実データと一致しているかを検証します。
開発者は、azure-mgmt-securityinsight の導入バージョン、Python バージョン、SecurityInsightsMgmtClient への移行、properties 配下の参照変更を確認します。管理者は、必要なデータコネクタ、Defender XDR 統合、Defender portal への移行計画、automation rule / playbook への影響を確認します。
このクラスは単体でセキュリティを強化する機能ではありません。しかし、Microsoft Sentinel のインシデント生成条件をコードで安全に管理するうえでは重要なモデルです。特に 2026年時点で SDK 2.x プレビューや Defender portal 移行が絡む環境では、「テンプレートのプロパティを正しく読む」「フィルター条件を実データで検証する」「依存バージョンを固定する」の3点を優先して対応してください。
コメント