結論から言うと、2026年5月20日に更新された「Microsoft Defender documentation update: Update application scripts and content of zip.」は、Microsoft Defender Antivirusの定義ファイル更新や端末側エージェント更新ではありません。実体は、Microsoft Sentinelで使う ESET Protect Platformデータコネクタ のAzure FunctionsアプリケーションスクリプトとZIPパッケージの更新です。ESETからMicrosoft Sentinelへ検出データを取り込む方式が、従来の「タイムスタンプで絞り込む方式」から「delta tokenを使う方式」へ変更された点が、管理者にとって最も重要です。(GitHub)
ESET PROTECT PlatformとMicrosoft Sentinelを連携していない環境では、基本的に直接対応は不要です。一方で、ESETの検出ログやインシデントをSentinelに取り込んでいる環境では、データ欠損・重複・Function Appの二重稼働・取り込みコストを確認しながら、計画的に再デプロイする必要があります。
Microsoft Defender documentation updateで何が変わったのか
今回の更新は、Azure/Azure-SentinelリポジトリのPull Request #14149としてマージされた変更です。対象ファイルは、ESET Protect Platformソリューション配下の FunctionAppESETProtectPlatform.zip、main_sentinel.py、utils_sentinel.py の3点です。GitHub上では2026年5月20日にマージされ、最終的に31件のチェックが通過しています。(GitHub)
公式の変更理由は、ESETからMicrosoft Sentinelへデータを取り込むアプリケーションで、タイムスタンプによるフィルタリングではなく delta token を使うためです。PRの説明では、テスト完了は「Yes」とされています。(GitHub)
| 確認項目 | 変更内容 | 管理者が見るべきポイント |
|---|---|---|
| 対象コンポーネント | ESET Protect PlatformのMicrosoft Sentinelデータコネクタ | Defender本体ではなく、Sentinel連携コネクタの更新 |
| 変更されたファイル | Function App用ZIP、main_sentinel.py、utils_sentinel.py | カスタム修正済み環境では差分確認が必要 |
| データ取得方式 | タイムスタンプフィルタからdelta token利用へ | 初回実行後の重複・欠損・取得遅延を確認 |
| バージョン | コード上のConfigが 3.2.0 から 3.3.0 へ変更 | 現行デプロイとの差分確認に使える |
| 状態管理 | LastDetectionTime... 系から LastData... 系の管理へ変更 | Azure Table Storage上の状態管理を確認 |
| 検証状況 | 最終的に31 checks passedでマージ | ただし本番適用前の自社環境検証は必須 |
この更新を「Microsoft Defenderのセキュリティ更新」として見る場合、実務上は Microsoft Defenderポータル上でMicrosoft Sentinelを運用する組織向けの連携コンテンツ更新 と捉えるのが正確です。Microsoft SentinelはMicrosoft Defenderポータルで一般提供されており、2027年3月31日以降はAzureポータルでのMicrosoft Sentinelサポートが終了し、Defenderポータルでの利用に一本化される予定です。(Microsoft Learn)
影響範囲：最初に自社が該当するか判断する
今回の更新で影響を受けるのは、主にESET PROTECT Platform、ESET Inspect、ESET Cloud Office Securityなどの検出・インシデント情報をMicrosoft Sentinelへ取り込んでいる環境です。ESETの公式説明では、この連携はAzure FunctionsとAzure MonitorのLogs Ingestion APIを使い、ESET側の公開APIから検出ログやインシデントログをMicrosoft Sentinelへ送る構成です。(ESETヘルプ)
| 利用状況 | 影響 | 推奨対応 |
|---|---|---|
| ESET Protect Platformデータコネクタを使っている | 大 | 再デプロイ前後でログ取り込みを検証する |
| Azure Functions版のESETコネクタをカスタム改修している | 大 | 公式差分を取り込み、独自修正との競合を確認する |
| Microsoft Sentinelは使っているがESET連携はない | 小 | 対応不要。ただしContent Hub更新は定期確認する |
| Microsoft Defender for Endpointのみ利用 | 直接影響なし | 端末側ポリシーやDefender Antivirus設定の変更は不要 |
| AzureポータルでSentinelを運用している | 間接影響あり | Defenderポータル移行計画とあわせて運用手順を見直す |
Microsoft Learnのデータコネクタ一覧では、ESET Protect PlatformコネクタはAzure Functionsを使うコネクタとして掲載され、Log Analyticsテーブルは IntegrationTable_CL と IntegrationTableIncidents_CL が示されています。また、Azure Functions作成権限、Microsoft Entra IDへのアプリ登録権限、Monitoring Metrics Publisherロール割り当て権限が前提条件として挙げられています。(Microsoft Learn)
delta token化で運用上何が変わるのか
delta tokenは、前回どこまでデータを取得したかをAPI側のトークンで管理するための「続きから取得するためのしおり」のようなものです。従来のように「この時刻以降のデータを取得する」と指定する方式では、遅延到着したイベント、時刻の丸め、タイムゾーン、API応答順序などの影響で、ログの重複や取りこぼしが発生しやすくなります。
今回の変更は、そうした時刻ベースの取り込み管理を減らし、ESET APIから返されるdelta tokenを次回取得に使う方向へ寄せるものです。コード差分でも、レスポンス内の nextDeltaToken を前提にした判定や、次回取得用トークンに相当する値を保存する処理が追加されています。(GitHub)
ただし、delta token化は「何もしなくても絶対に安全」という意味ではありません。特に本番環境では、次の3点を必ず確認してください。
| 確認ポイント | 理由 | 見落とすと起きること |
|---|---|---|
| アップデート直後の初回実行 | 状態管理の方式が変わるため | 一時的な重複、想定外の再取得、取り込み遅延 |
| Azure Table Storageの状態値 | 次回取得位置を保持するため | Function App再起動後に同じ範囲を再取得する可能性 |
| Log Analyticsの取り込み量 | 取り込み方式変更で件数が変わる場合があるため | Sentinelコストやアラート件数の急増 |
特にSOC運用では、「ログが入っているか」だけでなく、「いつもの量で、いつもの遅延範囲で、検出ルールが期待どおり発火するか」まで確認することが重要です。
管理者が確認すべき設定
ESET公式ドキュメントでは、最新バージョンへ更新するには、既存のデータコネクタを変更する形でアプリを再デプロイすると説明されています。更新時は、初回セットアップ時と同じProject detailsとInstance detailsを指定する必要があります。(ESETヘルプ)
| 設定・リソース | 確認内容 | 実務上の注意点 |
|---|---|---|
| Microsoft Sentinelワークスペース | 対象のLog Analytics workspaceが正しいか | 別ワークスペースへ再デプロイすると監視ルールが外れる |
| Resource group | 初回構築時と同じリソースグループか | ESET公式手順ではワークスペースと同じResource groupが前提 |
| Function App名 | 既存Function Appを更新するか、新規作成するか | 新しい名前で作る場合、旧Function App停止を忘れると二重取り込みになる |
| Application Run Interval | 実行間隔がSOC要件とコストに合うか | 短すぎるとFunctions実行回数や取り込み負荷が増える |
| Microsoft Entra IDアプリ | Client ID、Tenant ID、Secret、Object IDを確認 | Secret期限切れや権限不足は取り込み停止の原因になる |
| Monitoring Metrics Publisherロール | 登録アプリへ割り当て済みか | DCR経由のログ取り込みで権限不足が起きる可能性 |
| DCE/DCR | Data Collection EndpointとData Collection Rule名 | 誤ったDCRを使うと別テーブルや別フローへ送られる |
| Log Analyticsテーブル | IntegrationTable_CL、IntegrationTableIncidents_CL | KQL、分析ルール、Workbook、パーサーの参照先を確認 |
| ESET APIユーザー | ESET Connect APIユーザーの権限 | 権限不足だと一部製品の検出だけ欠落する |
ESETの更新手順では、異なるApplication Nameを使う場合、同じ検出データを両方のFunction Appが取得してしまうため、以前作成したFunction Appを停止することが推奨されています。これは今回の更新で最も起きやすい運用ミスです。(ESETヘルプ)
移行・展開の進め方
本番環境では、いきなり再デプロイするのではなく、次の順序で進めると安全です。
事前確認
まず、現在の構成を記録します。Function App名、実行間隔、App settings、Storage account、DCR、DCE、Log Analyticsワークスペース、ESET APIユーザー、Microsoft Entra IDアプリのClient IDとSecret期限を一覧化してください。
あわせて、更新前24時間から72時間程度のログ件数を取得しておくと、更新後の異常に気づきやすくなります。基準値がないと、delta token化による改善なのか、単なる重複取り込みなのか判断しにくくなります。
再デプロイ
ESET Protect PlatformデータコネクタページからARMテンプレートで再デプロイします。Microsoft Learnでは、Azure Functionsベースのコネクタは、Sentinelのデータコネクタページから「Deploy to Azure」を使ってFunction Appを展開する流れが説明されています。Azure Functionsを使う取り込みは追加コストが発生する可能性があるため、実行間隔と取り込み量の監視もセットで行うべきです。(Microsoft Learn)
更新直後の確認
更新直後は、Function AppのInvocations、Log Analyticsの取り込み件数、Microsoft Sentinelのインシデント・分析ルールの動作を確認します。ESET公式ドキュメントでも、統合の確認方法として、Microsoft SentinelのLogsでデプロイ時に作成されたテーブルを選び、ESET PROTECT Platformから取得された検出データを確認する流れが示されています。(ESETヘルプ)
展開後に使える確認KQL
更新後は、まずログが継続して入っているかを確認します。
IntegrationTable_CL
| extend IngestedAt = ingestion_time()
| where IngestedAt > ago(24h)
| summarize Rows = count() by bin(IngestedAt, 30m)
| order by IngestedAt ascインシデントログも取り込んでいる場合は、別テーブルも確認します。
IntegrationTableIncidents_CL
| extend IngestedAt = ingestion_time()
| where IngestedAt > ago(24h)
| summarize Rows = count() by bin(IngestedAt, 30m)
| order by IngestedAt asc更新前後の件数差を見たい場合は、更新時刻を基準に比較します。以下の datetime() は自社の更新時刻に置き換えてください。
let UpdateTime = datetime(2026-05-20T00:00:00Z);
IntegrationTable_CL
| extend IngestedAt = ingestion_time()
| where IngestedAt between (UpdateTime - 12h .. UpdateTime + 12h)
| summarize Rows = count() by Period = iff(IngestedAt < UpdateTime, "Before", "After"), bin(IngestedAt, 1h)
| order by IngestedAt asc重複確認は、環境ごとに一意キーの列名が異なる場合があります。ESETのパーサーではASIMに合わせて EventOriginalUid などの列が使われるため、パーサー利用環境では次のような考え方で確認できます。(ESETヘルプ)
ESETProtectPlatform
| where TimeGenerated > ago(24h)
| summarize Count = count() by EventOriginalUid
| where Count > 1
| order by Count desc上記の関数名や列名が使えない場合は、Workspace FunctionsにあるESETのパーシング関数名、または実際のテーブル列に合わせて置き換えてください。重要なのは、更新後の数時間だけで判断せず、通常の業務時間帯、夜間、週末バッチが含まれる期間まで観察することです。
開発者・カスタム運用環境での注意点
公式ZIPをそのまま使っている場合は、再デプロイ手順に従えばよいケースが多いです。しかし、Function Appコードを独自に修正している環境では、今回の差分を手作業で取り込む前に、次の点を確認してください。
| 確認対象 | 変更の意味 |
|---|---|
Config("MS-Sentinel", "3.3.0") | コネクタアプリ側のバージョンが更新されている |
DataSource enumの利用 | 文字列ベースのデータソース判定から型を使う実装へ寄っている |
nextDeltaToken 判定 | 旧方式の時刻フィルタ前提の処理を残すと整合性が崩れる可能性がある |
LastData...NPT 系の状態保存 | 次回取得位置の保存先が変わるため、Storage Tableの扱いを確認する |
_send_data_to_destination の引数 | 呼び出し元とのシグネチャ不一致に注意する |
| インシデント処理 | 検出ログとインシデントログで状態管理の扱いが同一とは限らない |
GitHubの差分ページでは、対象Pythonファイルにhiddenまたはbidirectional Unicode textに関する警告も表示されています。公式コードを読むだけなら大きな問題にならないこともありますが、コードをコピーして社内リポジトリへ取り込む場合は、不可視文字を表示できるエディタで確認してからコミットするのが安全です。(GitHub)
失敗しやすいポイント
旧Function Appを止めずに新Function Appを作る
最も多い失敗は、既存Function Appを残したまま新しいFunction Appを作り、同じESETデータを二重に取り込んでしまうパターンです。Application Nameを変える場合は、旧Function Appを停止するか、切り戻し用として短時間だけ残す場合でもTimer Triggerを無効化しておくべきです。
「ログがある」だけで正常と判断する
ログが入っていても、同じ検出が重複していたり、インシデントだけ入っていなかったり、特定のESET製品だけ欠落している可能性があります。ESET PROTECT、ESET Inspect、ESET Cloud Office Securityを複数使っている場合は、製品別に件数を確認してください。
既存の分析ルールやWorkbookを見直さない
取り込み先テーブルが同じでも、パーサーやKQLが前提にしている列、時刻、イベントIDが変わると、アラートの出方が変わることがあります。特に TimeGenerated だけでなく、ESET側のイベント時刻、ASIMパーサーの時刻列、ingestion_time() の違いを意識してください。
コストを確認しない
ESETとMicrosoftのドキュメントはいずれも、Azure Functionsを使ったSentinel取り込みで追加コストが発生する可能性に触れています。更新後に取り込み件数が増えた場合、それが正常な欠損解消なのか、重複取り込みなのかを切り分ける必要があります。(ESETヘルプ)
Defenderポータル移行もあわせて確認する
今回の更新そのものはESETコネクタの変更ですが、運用画面としてはMicrosoft Defenderポータルへの移行も無視できません。Microsoft SentinelのContent hubはDefenderポータルでは Microsoft Sentinel > Content management > Content hub、Data connectorsは Microsoft Sentinel > Configuration > Data connectors に配置されます。(Microsoft Learn)
Azureポータルで手順書を作っている組織は、今回のようなコネクタ更新を機に、次の運用ドキュメントをDefenderポータル前提へ更新しておくと、将来の移行負荷を減らせます。
- データコネクタの更新手順
- Function Appの確認手順
- Log Analyticsでの検証KQL
- インシデント調査時の画面遷移
- Content hubでのソリューション更新確認
- 障害時の一次切り分けフロー
管理者が次に取るべき行動
ESET Protect PlatformとMicrosoft Sentinelを連携している場合は、まず現在のFunction App、Storage Table、DCR、Log Analyticsテーブル、ESET APIユーザーを棚卸ししてください。そのうえで、メンテナンス時間を決め、同じProject detailsとInstance detailsで再デプロイし、旧Function Appの二重稼働を防ぎます。
展開後は、IntegrationTable_CL と IntegrationTableIncidents_CL の取り込み件数、Function Appの実行ログ、分析ルールの発火状況を最低24時間は確認してください。カスタムコードを使っている環境では、delta token、状態保存、DataSource型の変更を中心に差分をレビューする必要があります。
今回のMicrosoft Defender documentation updateは、端末のDefender設定を変える更新ではなく、Sentinelに入るESETデータの取得品質に関わる更新です。対応の優先度は、ESET連携をSOC監視やインシデント対応に使っているほど高くなります。まずは自社が該当するかを確認し、該当する場合は「再デプロイ」「重複防止」「取り込み検証」の3点を確実に実施しましょう。
コメント