Microsoft Sentinel TAXIIコネクタで脅威インテリジェンスが二重取り込みされる原因と対策【ThreatIntelligenceIndicatorとThreatIntelIndicatorsの違いとコスト最適化】

Microsoft Sentinel の Threat Intelligence – TAXII コネクタを有効化すると、旧テーブル ThreatIntelligenceIndicator と新テーブル ThreatIntelIndicators の両方に同じ IoC が入り、「ログが二重課金されているのでは？」と不安になる方は多いと思います。本記事では、この現象の正体と、移行期間中・移行完了後に取るべき現実的なコスト最適化施策を、公式ドキュメントとコミュニティ情報を踏まえて整理します。

Microsoft Sentinel TAXII コネクタでの二重取り込みは「仕様」

まず結論から言うと、2025 年春〜夏にかけて発生している「ThreatIntelligenceIndicator と ThreatIntelIndicators の二重取り込み」は、バグではなく移行期間中の正式な仕様です。

新テーブル公開とデュアル取り込み開始

Microsoft は 2025 年 4 月 3 日に、STIX 準拠の新しい脅威インテリジェンステーブル ThreatIntelIndicators と ThreatIntelObjects をパブリックプレビューとして公開しました。

同時に、すべての脅威インテリジェンスを新テーブルへ取り込みつつ、従来の ThreatIntelligenceIndicator テーブルにも「同じデータを並行して取り込む」デュアル取り込みが開始されています。

公式ドキュメントでは、当初このデュアル取り込みは 2025 年 7 月 31 日までと案内されていましたが、後に Microsoft Sentinel Blog で 2025 年 8 月 31 日まで延長されたことが発表されました。

タイムラインをざっくり整理

Microsoft 公開情報に基づき、脅威インテリジェンス取り込みのタイムラインを整理すると次のようになります。

期間	新テーブル (`ThreatIntelIndicators` / `ThreatIntelObjects`)	旧テーブル (`ThreatIntelligenceIndicator`)	ポイント
〜 2025-04-02	なし	通常取り込み	旧テーブルのみ利用
2025-04-03 〜 2025-07-31	取り込み開始	同じデータを継続取り込み	デュアル取り込み開始（新旧どちらも増える）
2025-08-01 〜 2025-08-31	取り込み継続	デュアル取り込み継続（延長措置）	Microsoft Sentinel Blog による延長アナウンス
2025-09-01 以降	取り込み継続	既定では新規取り込み停止	旧テーブルは参照専用（ただし過去に「延長オプトイン」した環境は 2026-05-31 まで継続の可能性）
〜 2026-05-31	取り込み継続	延長オプトイン済みワークスペースのみ取り込み継続	この日付で旧テーブルのサポートおよび取り込みが完全終了

つまり、質問日が 2025-08-21 の場合、「新旧テーブルに同じ IoC が入る」のはまさにこの移行期間中であり、仕様どおりの動作ということになります。

なぜ TAXII ソリューションをアンインストールしても旧テーブルが増え続けるのか

「Content Hub から旧 Threat Intelligence – TAXII ソリューションをアンインストールしたのに、ThreatIntelligenceIndicator が増え続ける」という相談も多く寄せられています。この理由は大きく 3 つあります。

理由 1：取り込み先テーブルの決定は「コネクタ」ではなく「プラットフォーム側」

TAXII コネクタや Defender Threat Intelligence コネクタは、あくまで 脅威インテリジェンスを Sentinel に送る窓口です。「どのテーブルに書き込むか」は Microsoft Sentinel の内部ロジックが決めています。

2025 年の移行期間中は、すべての TI フィードがまず新テーブル (ThreatIntelIndicators / ThreatIntelObjects) に着地
その後、サービス側の処理で旧テーブル ThreatIntelligenceIndicator にも同じデータが複製される

そのため、Content Hub から旧 TAXII ソリューションを削除しても、「サービス側の複製ロジック」が生きている間は旧テーブルへの書き込みが止まりません。

理由 2：データは 7〜10 日ごとに再発行される

新しいテーブルに移行したタイミングで、Microsoft は脅威インテリジェンスの再発行サイクルも変更しています。従来は約 12 日サイクルだったものが、すべてのデータを 7〜10 日ごとに再発行する方式になりました。

この再発行は LastUpdateMethod == "LogARepublisher" という値で判別でき、再発行分も新旧テーブルの両方に記録されるため、短期間でレコード数と課金量が膨らみやすくなります。

理由 3：Microsoft 側のベースライン TI は完全停止できない

Microsoft Q&A では、「TAXII コネクタを削除したのに ThreatIntelIndicators / ThreatIntelligenceIndicator にデータが入り続ける」という質問に対し、次のような回答が示されています。

Threat Intelligence Ingestion Rules を使えば、条件に合致した TI オブジェクトを Delete 処理して取り込み前に破棄できる
ただし、Microsoft が提供する一部のベースライン TI については、「まったく取り込まない」ように完全停止することはできない
Defender など他製品からの同期は、それぞれの製品側（例：MDE の SIEM Integration 設定）で無効化する必要がある

つまり、「旧テーブルにだけ入らないようにするスイッチ」は存在せず、総取り込み量そのものを削るか、ソース側を止めるしかないという前提を押さえておく必要があります。

旧テーブルと新テーブルの違い（コスト観点）

次に「どちらのテーブルがどれくらいコストを食うのか」を押さえておきましょう。公式テーブルリファレンスから読み取れるポイントをまとめます。

項目	`ThreatIntelligenceIndicator` (旧テーブル)	`ThreatIntelIndicators` (新テーブル)	`ThreatIntelObjects` (新テーブル)
ステータス	レガシー。2026-05-31 に完全廃止予定	現行推奨テーブル	指標以外の STIX オブジェクト用
Basic Logs 対応	No（非対応）	Yes（対応）	Yes（対応）
STIX 対応	限定的（主に IoC）	STIX Indicator スキーマ対応	Threat Actor / Campaign 等の STIX オブジェクト
`Data` 列	なし	あり（フル STIX オブジェクト）	あり（フル STIX オブジェクト）
主な用途	従来の IoC ベース検出（カスタムルール・既存ワークブック等）	新規・更新系の検出/ハンティングのメインテーブル	Threat Actor、Campaign、Relationship 等のコンテキスト分析
特徴的な列	`ThreatType` / `IndicatorId` / `TrafficLightProtocolLevel` 等	`ObservableKey` / `ObservableValue` / `LastUpdateMethod` など	`StixType` / `Data.name` / `Data.id` など
コストの傾向	レコードは比較的軽量だが、Basic Logs 非対応のため「Analytics Logs 前提の料金」	`Data` 列やメタデータによりレコードサイズは大型化。STIX 再発行（7〜10 日）により取り込み量が増える傾向	オブジェクト数と再発行頻度に応じて増加

公式リファレンスでも、旧テーブルは Basic log = No、新テーブルは Basic log = Yes と明記されています。

旧テーブルへの取り込みを止める「本質的な」方法

「旧テーブルだけを止め、新テーブルだけに取り込みたい」という要望に対して、選択肢は実質次の 2 つに集約されます。

A. 移行期間が終わるまで待つ（8/31 以降の挙動に任せる）
B. そもそもの TI 取り込み量自体を削減する

環境側で「旧テーブルへの書き込みを完全に無効化するスイッチ」は提供されていないため、「どこから、どれだけの TI を入れるか」でコントロールする考え方が不可欠です。

移行期限後の挙動

既定では、2025-08-31 以降は旧テーブル ThreatIntelligenceIndicator への新規取り込みは停止し、テーブルは過去データの参照専用となります。

一方で、Microsoft Sentinel Blog では「希望する顧客はサポートリクエストにより 2026-05-31 までデュアル取り込みを延長できる」と案内されていましたが、その後の更新で 2025-08-31 をもって新規の延長オプトインを終了したことが追記されています。

つまり、

過去に延長オプトインを実施済みのワークスペース：2026-05-31 まで旧テーブル取り込みが継続する可能性あり
それ以外：2025-08-31 で旧テーブルへの新規取り込みは停止するはず

となります。2025-09-01 以降も旧テーブルに新規レコードが入り続ける場合は、

自組織が延長オプトインを申し込んでいないか（アカウントチームやサポート窓口に確認）
それでも説明が付かない場合は Microsoft サポートへ調査チケットを起票

という流れで確認するとよいでしょう。

いますぐできるコスト抑制策

移行期間中に「旧テーブルだけ」を止めることはできませんが、次の手順で総取り込み量と課金サイズを減らすことは可能です。

1. Threat Intelligence Ingestion Rules で不要な TI を「Delete」する

取り込み前にデータをふるいにかける仕組みが Threat Intelligence Ingestion Rules です。Defender ポータルの Threat intelligence 管理画面から設定できます。

場所：Defender ポータル → Threat intelligence → Intel management > Ingestion Rules
動作：STIX オブジェクトがワークスペースに保存される前に、ルール順に評価される
Delete アクション：条件に合致したオブジェクトを取り込みパイプラインから完全に除外（テーブルに記録されない）
反映まで：新規・変更ルールはおおむね 15 分以内に有効になる

よくある削減例：

信頼度 Confidence が 0〜20 の IoC をすべて Delete
特定の OSINT フィード（例：検証中のテストフィード）を一括 Delete
半年以上更新されていないオブジェクトで、かつ低信頼度のものを削除

これにより、

新テーブル ThreatIntelIndicators / ThreatIntelObjects
移行期間中の旧テーブル ThreatIntelligenceIndicator

の両方への取り込みがまとめて減るため、二重取り込みによるムダも同時に削ることができます。

注意点

Ingestion Rules は「取り込み前」に作用するため、すでに保存済みの過去データは削除されません
高価な商用 TI フィードを使っている場合、むやみに削りすぎると検出力が落ちる可能性があるので、まずはログ分析で「ノイズ元」を特定してからルールを作るのがおすすめです

2. Workspace 変換（DCR）で `Data` 列を落として課金サイズを圧縮

新テーブル側のコスト増の大きな要因が、STIX オブジェクト全文を保持する Data 列です。テーブルリファレンスでも ThreatIntelIndicators / ThreatIntelObjects に Data 列が存在し、フル STIX オブジェクトが記録されると説明されています。

多くの環境では、検出やハンティングで使うのは ObservableKey / ObservableValue などの「分解されたキー/値」の方であり、Data 列を直接参照するケースはそれほど多くありません。

そこで有効なのが、Log Analytics の Workspace 変換（Data Collection Rule: DCR） で Data 列を落としてしまう方法です。Microsoft 公式の STIX オブジェクト活用ドキュメントでも、次のような変換クエリ例が紹介されています。

// ThreatIntelIndicators / ThreatIntelObjects の Data 列を取り除く例
source
| project-away Data

ポイント：

変換は DCR（Data Collection Rule）の「ワークスペース変換」として設定
project-away Data により、課金サイズの大部分を占める STIX 本体をドロップ
Sentinel 有効なワークスペースでは、「フィルタリング目的の変換」に対しては追加の変換課金は発生しないと明示されています

さらに、STIX パターンがうまく解析できず、ObservableKey / ObservableValue が空のレコードを取り除く例も公式に示されています。

// ObservableKey/ObservableValue が空の行を取り除く例
source
| where (ObservableKey != "" and isnotempty(ObservableKey))
    or (ObservableValue != "" and isnotempty(ObservableValue))

これらを組み合わせることで、

検出に使えないゴミレコード
巨大な STIX 本体（Data 列）

を取り込み前にそぎ落とし、同じ「件数」でも課金バイト数を大きく削減できます。

3. 保持期間とログプランを見直す

旧テーブル：保持期間を最小限に

旧テーブル ThreatIntelligenceIndicator は Basic Logs 非対応であるため、取り込み料金は削れませんが、保持期間を短くすることでストレージ料金を抑えることは可能です。テーブルリファレンスでは Basic log = No と明記されています。

Defender / Sentinel ポータルでテーブルごとの保持期間を数日〜数週間程度に圧縮
過去分をどうしても残したい場合は、必要なものだけ外部にエクスポートしてから保持を削る

新テーブル：Basic Logs の活用は慎重に

ThreatIntelIndicators / ThreatIntelObjects は Basic Logs に対応しており、Azure Monitor のテーブル一覧でも「Supports basic log plan: Yes」となっています。

ただし Basic Logs は、

検索やエクスプローラ用途には使えるものの、
リアルタイム検出用の Analytics ルールからの利用に制約がある

という性質があります。そのため、

本番の検出に使う TI：Analytics Logs（既定）のまま維持する
過去長期保存したいが検出には使わない TI：Basic Logs へ移行を検討

といった「用途ごとの住み分け」が重要です。

4. Logic Apps・カスタム取り込みの「幽霊ジョブ」を止める

二重取り込みの陰に、「古いカスタム取り込みが生き残っていた」というパターンもよくあります。Microsoft Sentinel には、TAXII コネクタ以外にも次のようなインポート手段があります。

Threat Intelligence upload API（TIP 連携や自前スクリプト）
Threat Intelligence Platform data connector（旧 API ベースコネクタ・非推奨）
独自の Logic Apps / Functions / Automation からのアップロード

対策としては、

Sentinel の Data connectors 画面で TI 関連コネクタを棚卸し
Logic Apps / Automation / Functions で「ThreatIntel」や「tiIndicators」といったキーワードで検索
不用になったジョブや認証情報（Azure AD アプリ、PAT 等）を無効化

を順に実施すると、意図しない重複取り込みをかなり減らせます。

移行後に必ずやるべき 3 つのこと

1. クエリ・分析ルール・ワークブックを新テーブル前提に切り替える

公式ドキュメントでは、ThreatIntelligenceIndicator を参照しているコンテンツ（クエリ・Analytics ルール・ワークブック・Playbook）は、新テーブルに書き換えることが明確に推奨されています。

具体的には、次のような変更が必要になります。

KQL クエリ
- 旧：ThreatIntelligenceIndicator を参照
- 新：ThreatIntelIndicators / ThreatIntelObjects を参照
Analytics ルール
- Threat Intelligence マップ系ルールのクエリを新テーブルに対応
- 旧テーブルと新テーブルの両方を union しているルールは、移行完了後に整理
Workbooks
- 可視化パネルのクエリを新テーブルに差し替え

旧テーブルから新テーブルへのクエリ書き換え例

公式の STIX オブジェクト活用ガイドでは、ThreatIntelligenceIndicator の列を新テーブルにマッピングするサンプルが公開されています。以下は、その考え方を簡略化した例です。

// ThreatIntelIndicators から旧テーブル風の列を再現する一例
ThreatIntelIndicators
| extend NetworkIP =
    iff(ObservableKey == "ipv4-addr:value", ObservableValue, ""),
         DomainName =
    iff(ObservableKey == "domain-name:value", ObservableValue, ""),
         Url =
    iff(ObservableKey == "url:value", ObservableValue, "")
| project TimeGenerated, ThreatType = tostring(Data.indicator_types[0]),
          NetworkIP, DomainName, Url, Confidence, Tags, LastUpdateMethod

このように、ObservableKey / ObservableValue と Data 内のフィールドを組み合わせることで、旧テーブルとほぼ同等のクエリを新テーブル上で再現できます。

2. STIX オブジェクトを活用したハンティング・相関分析を作り直す

新テーブルの真価は、「IoC 単体」ではなく、Threat Actor や Campaign、Relationship などの STIX オブジェクトとの関連付けにあります。Microsoft の STIX オブジェクトガイドでは、Threat Actor と IoC を結びつけるサンプルクエリなどが紹介されています。

例えば、特定の IP アドレスに紐づく Threat Actor を洗い出すイメージのクエリは次のように書けます（概念イメージ）。

// 特定 IP に関連する Threat Actor を引き出すイメージ
let TARGET_IP = "203.0.113.10";
let IndicatorsWithThatIP =
    ThreatIntelIndicators
    | where ObservableKey == "ipv4-addr:value"
      and ObservableValue == TARGET_IP
    | extend TlId = tostring(Data.id)
    | summarize arg_max(TimeGenerated, *) by TlId;
let ThreatActors =
    ThreatIntelObjects
    | where StixType == "threat-actor"
    | extend TlId = tostring(Data.id),
             ThreatActorName = tostring(Data.name)
    | summarize arg_max(TimeGenerated, *) by TlId;
let Relationships =
    ThreatIntelObjects
    | where StixType == "relationship"
    | extend SourceRef = tostring(Data.source_ref),
             TargetRef = tostring(Data.target_ref)
    | summarize arg_max(TimeGenerated, *) by Id;
Relationships
| join kind=inner (IndicatorsWithThatIP) on $left.SourceRef == $right.TlId
| join kind=inner (ThreatActors)        on $left.TargetRef == $right.TlId
| project TARGET_IP = ObservableValue, ThreatActorName, TimeGenerated

こうした STIX オブジェクトベースのハンティングは、旧テーブルでは実現が難しかった領域です。二重取り込みで増えたコストを「高付加価値な検出ロジック」で取り返す、という発想もあわせて検討するとよいでしょう。

3. 取り込み量と課金サイズをモニタリングする KQL を用意する

最後に、「知らないうちに取り込み量が爆増していた」という事態を避けるための、簡単なモニタリングクエリを用意しておきます。

新旧テーブルの件数推移を比べる

// 直近 14 日間の新旧テーブル別取り込み件数推移
let start = ago(14d);
ThreatIntelligenceIndicator
| where TimeGenerated &gt;= start
| summarize OldCount = count() by bin(TimeGenerated, 1d)
| join kind=fullouter (
    ThreatIntelIndicators
    | where TimeGenerated &gt;= start
    | summarize NewCount = count() by bin(TimeGenerated, 1d)
) on TimeGenerated
| order by TimeGenerated asc

課金バイト数（_BilledSize）を比較する

// 直近 14 日間の課金バイトを MB 単位で比較
let start = ago(14d);
let OldTable =
    ThreatIntelligenceIndicator
    | where TimeGenerated &gt;= start
    | summarize OldSizeMB = sum(_BilledSize) / 1024.0 / 1024.0
      by bin(TimeGenerated, 1d);
let NewTable =
    ThreatIntelIndicators
    | where TimeGenerated &gt;= start
    | summarize NewSizeMB = sum(_BilledSize) / 1024.0 / 1024.0
      by bin(TimeGenerated, 1d);
OldTable
| join kind=fullouter NewTable on TimeGenerated
| order by TimeGenerated asc

これらのクエリを Workbook 化しておけば、

デュアル取り込み期間中に「どれだけ旧テーブルが余分にコストを食っているか」
project-away Data 適用前後で課金サイズがどう変わったか

を視覚的に把握でき、運用側の合意形成にも役立ちます。

まとめ：仕様を理解しつつ「止血」と「移行」を両輪で進める

本記事の要点を整理します。

2025 年 4〜8 月の間、Microsoft Sentinel は意図的に新旧テーブルへ同一の脅威インテリジェンスをデュアル取り込みしている（旧テーブルへの書き込み延長は 2025-08-31 まで）
旧 TAXII ソリューションをアンインストールしても、取り込み先テーブルはサービス側のロジックで決まるため、デュアル取り込み期間中は旧テーブルへの書き込みを完全には止められない
2025-09-01 以降、（延長オプトインしていない限り）旧テーブルへの新規取り込みは止まり、2026-05-31 に旧テーブル自体が正式廃止予定
移行期間中にできる「止血策」は、
- Threat Intelligence Ingestion Rules で不要な TI を Delete する
- DCR / workspace 変換で Data 列や不要行を削る
- 旧テーブルの保持期間を最小化し、必要に応じて新テーブルを Basic Logs で長期保存する
- Logic Apps やカスタム取り込みを棚卸しし、重複ソースを排除する
移行完了後は、
- すべてのクエリ・Analytics ルール・Workbooks を ThreatIntelIndicators / ThreatIntelObjects 前提に書き換え
- STIX オブジェクトを活用したハンティング・相関分析を作り直す
- 新旧テーブルの取り込み量と課金サイズを継続的にモニタリングする

もともとの Q&A では Microsoft Sentinel Blog へのリンク紹介のみで終わっているケースも見られますが、実運用では「いま何が起きているのか」をチームに説明しつつ、「どこまで止血し、どこから移行を進めるか」を決めていく必要があります。本記事が、そのための社内説明資料や運用設計のたたき台として役立てば幸いです。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Sentinel TAXIIコネクタで脅威インテリジェンスが二重取り込みされる原因と対策【ThreatIntelligenceIndicatorとThreatIntelIndicatorsの違いとコスト最適化】

Microsoft Sentinel TAXII コネクタでの二重取り込みは「仕様」

新テーブル公開とデュアル取り込み開始

タイムラインをざっくり整理

なぜ TAXII ソリューションをアンインストールしても旧テーブルが増え続けるのか

理由 1：取り込み先テーブルの決定は「コネクタ」ではなく「プラットフォーム側」

理由 2：データは 7〜10 日ごとに再発行される

理由 3：Microsoft 側のベースライン TI は完全停止できない

旧テーブルと新テーブルの違い（コスト観点）

旧テーブルへの取り込みを止める「本質的な」方法

移行期限後の挙動

いますぐできるコスト抑制策

1. Threat Intelligence Ingestion Rules で不要な TI を「Delete」する

注意点

2. Workspace 変換（DCR）で `Data` 列を落として課金サイズを圧縮

3. 保持期間とログプランを見直す

旧テーブル：保持期間を最小限に

新テーブル：Basic Logs の活用は慎重に

4. Logic Apps・カスタム取り込みの「幽霊ジョブ」を止める

移行後に必ずやるべき 3 つのこと

1. クエリ・分析ルール・ワークブックを新テーブル前提に切り替える

旧テーブルから新テーブルへのクエリ書き換え例

2. STIX オブジェクトを活用したハンティング・相関分析を作り直す

3. 取り込み量と課金サイズをモニタリングする KQL を用意する

新旧テーブルの件数推移を比べる

課金バイト数（_BilledSize）を比較する

まとめ：仕様を理解しつつ「止血」と「移行」を両輪で進める

この記事を書いた人

コメント

コメントするコメントをキャンセル

Microsoft Sentinel TAXIIコネクタで脅威インテリジェンスが二重取り込みされる原因と対策【ThreatIntelligenceIndicatorとThreatIntelIndicatorsの違いとコスト最適化】

Microsoft Sentinel TAXII コネクタでの二重取り込みは「仕様」

新テーブル公開とデュアル取り込み開始

タイムラインをざっくり整理

なぜ TAXII ソリューションをアンインストールしても旧テーブルが増え続けるのか

理由 1：取り込み先テーブルの決定は「コネクタ」ではなく「プラットフォーム側」

理由 2：データは 7〜10 日ごとに再発行される

理由 3：Microsoft 側のベースライン TI は完全停止できない

旧テーブルと新テーブルの違い（コスト観点）

旧テーブルへの取り込みを止める「本質的な」方法

移行期限後の挙動

いますぐできるコスト抑制策

1. Threat Intelligence Ingestion Rules で不要な TI を「Delete」する

注意点

2. Workspace 変換（DCR）で Data 列を落として課金サイズを圧縮

3. 保持期間とログ プランを見直す

旧テーブル：保持期間を最小限に

新テーブル：Basic Logs の活用は慎重に

4. Logic Apps・カスタム取り込みの「幽霊ジョブ」を止める

移行後に必ずやるべき 3 つのこと

1. クエリ・分析ルール・ワークブックを新テーブル前提に切り替える

旧テーブルから新テーブルへのクエリ書き換え例

2. STIX オブジェクトを活用したハンティング・相関分析を作り直す

3. 取り込み量と課金サイズをモニタリングする KQL を用意する

新旧テーブルの件数推移を比べる

課金バイト数（_BilledSize）を比較する

まとめ：仕様を理解しつつ「止血」と「移行」を両輪で進める

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

2. Workspace 変換（DCR）で `Data` 列を落として課金サイズを圧縮

3. 保持期間とログプランを見直す

コメントするコメントをキャンセル