ログイン

トップ

アウェアネス

PhishAI

AI SOC

サービス一覧

会社概要

記事

ホワイトペーパー

セミナー

用語集

ニュース

インシデント速報

お問い合わせ

資料ダウンロード

Insight

2026/09/11

MTTR・MTTDとは？SOCのKPI設計と改善の実務

迎健太

MTTD・MTTA・MTTR・MTTCの定義と計測方法、時間指標が重要な理由を公開データで確認し、量・質・時間・カバレッジで構成するSOCのKPI体系、数を追う・閉じるだけのアンチパターン、改善の実務、経営層への報告の見せ方までを整理します。

「わが社のセキュリティ対策は十分か」と経営層から問われたとき、導入製品の一覧やアラート件数で答えても納得は得にくいものです。監視体制の実力を示す物差しとして多くの組織が使うのが、MTTD（平均検知時間）や MTTR（平均対応時間）といった「時間」の指標です。ただし、これらの用語は定義が揺れやすく、計測の起点と終点を決めずに数字だけを追うと、かえって運用をゆがめることがあります。本記事では、MTTD・MTTA・MTTR・MTTC の定義と計測方法を整理し、時間指標がなぜ重要なのかを公開データで確認したうえで、SOC（Security Operations Center：セキュリティ監視・運用の専門組織）の KPI 体系、陥りやすいアンチパターン、改善の実務、経営層への報告の考え方を解説します。

MTTD・MTTA・MTTR・MTTCとは？——定義と計測方法

SOC の時間指標は、インシデントのライフサイクルのどの区間を測るかで名称が変わります。攻撃者の侵入（不正な挙動の発生）→ 検知（アラート生成）→ 着手（担当者が受領）→ 調査・判定 → 封じ込め → 根絶・復旧 → クローズという流れのなかで、「2 点間の経過時間」を平均または中央値で表したものが時間指標です。

MTTD（Mean Time to Detect：平均検知時間）

侵害や不正な挙動の発生から、組織がそれを検知するまでの平均時間です。厳密な起点は「攻撃者が侵入した時刻」ですが、これは事後のフォレンジック調査で初めて判明することが多いため、日々の運用ではログにイベントが記録された時刻や、SIEM（Security Information and Event Management：ログを集約・相関分析する基盤）で検知ルールが発火した時刻を起点にとるのが一般的です。Mandiant が M-Trends で公表する「dwell time（滞留時間）」は、攻撃者が侵入してから検知されるまでの期間で、攻撃者側の視点に立った MTTD に近い概念です。

MTTA（Mean Time to Acknowledge：平均着手時間）

アラートの生成から、担当者が受領して調査に着手するまでの平均時間で、「人（または自動化）が動き始めるまでの待ち時間」を測ります。夜間・休日に監視員がいない、アラートが多すぎて順番待ちになっている、といった状況で大きく伸びます。Microsoft Sentinel の「Security operations efficiency」ワークブックでは、インシデントの作成時刻から最初の更新時刻までの差分を「Mean time to triage（平均トリアージ時間）」として集計しており（Microsoft Learn）、MTTA に相当します。

MTTR（Mean Time to Respond／Resolve／Recover）——最も混同されやすい指標

MTTR は最も広く使われる一方で、最も定義が揺れている略語です。「R」には少なくとも次の 4 つの用法があります。

Respond（対応）：検知から、封じ込めなどの初動対応を完了するまで
Resolve（解決）：検知から、インシデントをクローズするまで
Recover（復旧）：検知から、業務やシステムが通常状態に戻るまで
Repair（修復）：IT 運用や信頼性工学に由来する用法で、障害発生から修理完了まで

同じ「MTTR 4 時間」でも、Respond なら初動完了まで、Recover なら業務復旧までと意味はまったく異なります。外部委託先の SLA（サービス品質保証）上の MTTR と自社の MTTR が別の区間を測っていた、というケースは珍しくありません。Sentinel のワークブックがインシデント作成からクローズまでを「Mean time to closure（平均クローズ時間）」と呼ぶように（Microsoft Learn）、社内でも「R が何を指すか」「終点をどのイベントで判定するか」を文書で定義することが第一歩です。

MTTC（Mean Time to Contain：平均封じ込め時間）と侵害ライフサイクル

検知から、端末のネットワーク隔離やアカウント無効化といった封じ込め措置の完了までの平均時間です。IBM の Cost of a Data Breach Report では、侵害の特定（identify）と封じ込め（contain）に要した日数をあわせて「侵害ライフサイクル」と呼び、コストとの関係を分析しています。MTTD と MTTC の合計がおおむねこれに対応すると考えると、社内指標と外部調査を対応づけて読めます。いずれの指標も、「起点」「終点」「対象母集団（全アラートか確定インシデントか）」「集計方法（平均か中央値か）」の 4 点を明文化しておかないと、運用が改善したのか計測方法が変わっただけなのかを区別できなくなります。

なぜ「時間」が重要なのか——侵害ライフサイクルと被害額の関係

時間指標が重視される理由は明快で、攻撃者が環境内に長く滞留すればするほど、被害の範囲と復旧コストが膨らむからです。公開データで確認します。

IBM の Cost of a Data Breach Report 2025 によると、侵害を特定し、封じ込めるまでの平均期間は 241 日で、前年から 17 日短縮しました。セキュリティ運用で AI と自動化を広範に活用している組織は、活用していない組織に比べて平均侵害コストが約 190 万米ドル低く、侵害ライフサイクルも平均 80 日短かったと報告されています。また、侵害を自組織で検知した組織は、攻撃者による公表で発覚した組織より約 90 万米ドルコストが低かったと報告されています（IBM, 2025）。2026 年版では、侵害コストの世界平均は約 499 万米ドルで前年から 12% 増加し、AI と自動化を広範に活用する組織と、まったく活用しない組織の平均侵害コストの差は約 193 万米ドルとされています（IBM, 2026）。

Mandiant の M-Trends 2026 によると、2025 年の調査における攻撃者の滞留時間の世界中央値は 14 日で、前年の 11 日から延びました。一方、組織が不正な挙動を自ら最初に検知した割合は 52% と、前年の 43% から改善しています（Mandiant, 2026）。前年版の M-Trends 2025 では、滞留時間の中央値は外部からの通知で発覚した場合が 26 日、自組織で検知した場合が 10 日、ランサムウェアの脅迫のように攻撃者自身が通知した場合が 5 日と、検知経路による差が示されています（Mandiant, 2025）。「自分たちで検知できる」ことが、滞留時間を短くする最大の要因です。

注目すべきは攻撃側のスピードです。M-Trends 2026 は、初期アクセスを得た攻撃者が別の攻撃グループに引き渡すまでの時間の中央値が、2022 年の 8 時間超から 2025 年には 22 秒に短縮したと報告しています（Mandiant, 2026）。侵入からランサムウェア展開までが分業化・自動化された現状では、検知・対応の単位を「日」で考える組織と「分」で考える組織の間に、被害の大きさで決定的な差が生まれます。IPA の「情報セキュリティ10大脅威 2026」でも組織向け脅威の 1 位は「ランサム攻撃による被害」であり（IPA, 2026）、日本企業にとってこの時間との戦いは他人事ではありません。時間指標は SOC の作業効率ではなく、事業インパクトに直結するリスク指標として位置づけることが重要です。

SOCのKPI体系——量・質・時間・カバレッジ・成熟度の5つの軸

時間指標だけを見ていると、後述するアンチパターンに陥りやすくなります。SOC の KPI は複数の軸を組み合わせて初めて実態を映します。ここでは 5 つの軸に整理します。

量の指標

受信アラート数、インシデント数、実際に調査したアラートの割合（調査率）、未処理のバックログなどです。負荷を把握するために必須ですが、それ自体を目標にすべきではありません。とくに調査率は見落とされがちで、アラートの一部しか調査できていない状態では、MTTD がどれだけ短くても「調査されたアラートについての MTTD」にすぎません。

質の指標

誤検知率（調査の結果、無害と判定された割合）、真陽性率、エスカレーション精度（上位層へ上げた案件のうち実際に対応が必要だった割合）、クローズ後の再オープン率、同種インシデントの再発率などです。質の指標は時間指標の「裏取り」として機能します。MTTR が短くなったのに再オープン率が上がっていれば、調査が浅くなっている可能性を疑うべきです。

時間の指標

前述の MTTD・MTTA・MTTR・MTTC です。実務上のポイントは、平均だけでなく中央値やパーセンタイル（たとえば 90 パーセンタイル：全体の 90% がこの時間以内に収まる値）を併記することです。少数の長期化案件が平均を引き上げる一方、中央値だけでは取りこぼされている一部が見えないためです。Sentinel の運用効率ワークブックでも、平均に加えてトリアージ時間・クローズ時間のパーセンタイルが標準で提供されています（Microsoft Learn）。重大度（Critical／High／Medium／Low）別に集計し、重大度が高いほど厳しい目標値を置くのが一般的です。

カバレッジの指標

監視対象資産のうち EDR（Endpoint Detection and Response：端末の挙動を監視する製品）が導入されている割合、想定ログソースのうち SIEM に取り込まれている割合、ログの保持期間、MITRE ATT&CK（実世界の観測に基づく攻撃者の戦術・技術のナレッジベース）に対する検知ルールのカバー率などです。「そもそも見えていない領域」を可視化する指標であり、MTTD の前提条件でもあります。M-Trends 2026 は、400 日近い滞留時間に達する脅威に対しては、90 日程度の標準的なログ保持方針では初期侵入経路や侵害範囲を把握できなくなると指摘しており（Mandiant, 2026）、ログ保持期間もカバレッジの一部として KPI に含める価値があります。

成熟度の指標

ランブック（対応手順書）が整備されているインシデント種別の割合、一次調査の自動化率、ポストモーテム（事後検証）の実施率と改善アクションの完了率、机上演習の回数などです。NIST SP 800-61 Rev. 3（2025 年 4 月公開）は、インシデント対応をサイバーセキュリティリスク管理全体に組み込むことを求め、インシデント対応プログラムのパフォーマンスを定期的に評価して修正すべき問題や不備を特定することを推奨しています（NIST, 2025）。成熟度の指標は、この「定期的な評価」を具体化するものです。

5 軸をすべて完璧に計測する必要はありません。SANS の SOC Survey（2025 年版）のように業界横断で SOC の指標や課題を調査した資料も参考にしつつ、自組織のリスクと運用段階に合った指標をまず 5〜10 個程度に絞り、計測できる状態を作ることが現実的です。SOC の基本的な役割や体制は「SOCとは？役割・Tier体制・24時間365日運用の基本と限界」で解説しています。

KPIのアンチパターン——数を追う、閉じることが目的化する

KPI は設計を誤ると、運用を改善するどころか、ゆがめる力を持ちます。SOC で起きやすいパターンを整理します。

処理件数を生産性として評価する。件数を評価指標にすると、アナリストは判断の難しいアラートより簡単に閉じられるアラートを優先します。件数が増えても、危険度の高いアラートが後回しになっていれば、組織のリスクは下がっていません。

MTTR の短縮を追い、クローズが目的化する。MTTR（Resolve）を厳しく目標管理すると、十分な調査をせずに「誤検知」として閉じる圧力が生じます。誤検知率と再オープン率が上がり、ある日、以前に閉じたアラートが侵害の初期兆候だったと判明する——多くの組織で見られる構図です。時間指標には必ず質の指標を対にして設定します。

平均値だけで語る。平均は少数の極端な案件に引きずられます。逆に平均が良好でも 90 パーセンタイルが極端に悪ければ、一部の案件が長期間放置されていることを意味します。分布を見ずに平均だけを報告することは、リスクを見誤る原因になります。

検知できたものだけで MTTD を計算する。MTTD は「検知できたインシデント」の統計であり、検知できなかった侵害は分母に入りません。侵害の多くが外部からの通知で発覚しているなら、MTTD が短くても検知能力そのものに問題があります。M-Trends が示す「自組織で検知した割合」のような指標を併用し、外部通知で発覚した件数も正直に報告することが健全です。

計測点を定義せずに比較する。外部委託先の報告書の MTTR と自社の MTTR、昨年と今年の MTTD が異なる起点・終点で計測されていれば、比較に意味はありません。指標の定義書を作り、変更履歴を残します。一般に「指標が目標になると、良い指標であることをやめる」と言われます。KPI は現場を統制する道具ではなく改善点を発見する道具と位置づけ、目標値は複数の指標のバランスのうえで設定することが重要です。

KPIを改善する実務——ログの網羅、自動トリアージ、ランブック、ポストモーテム

KPI の改善は、指標ごとにボトルネックとなる工程が異なります。時間指標と質の指標を改善する実務を工程順に整理します。

計測基盤を整える

最初に取り組むべきは、指標を「自動で」算出できる状態を作ることです。手作業の集計は継続せず、集計のたびに定義がぶれます。SIEM やチケット管理システムのインシデントレコードに、作成・初回着手・封じ込め・クローズの各時刻、重大度、分類（真陽性／誤検知）が記録される仕組みを整え、そこから機械的に算出します。Sentinel では、インシデントの作成・更新のたびにレコードが追記される SecurityIncident テーブルをクエリして時間差を算出する方法が公式ドキュメントに示されており（Microsoft Learn）、他の SIEM でも同様の考え方で実装できます。

ログの網羅性と相関分析で MTTD を短くする

MTTD を短縮する最大のレバーは、検知ロジックの調整よりも、必要なログが揃っているかどうかです。エンドポイント、認証基盤、クラウド、ネットワーク境界、SaaS のログが SIEM に集約され、相互に関連づけられていなければ、単体のアラートはノイズとして埋もれます。単体アラートでは見えない攻撃の全体像の捉え方は「ログの相関分析はなぜ重要か」で解説しています。カバレッジの KPI（ログソース取り込み率、EDR 導入率）を先に改善し、その結果として MTTD が改善するという順序を意識してください。

一次調査の自動化で MTTA と調査率を改善する

MTTA と調査率のボトルネックは、多くの場合「人手の待ち行列」です。アラートの重複排除、資産情報や脅威インテリジェンスによるエンリッチメント（付加情報の自動付与）、過去の類似アラートの参照といった一次調査を自動化すれば、アナリストは判断が必要な案件に集中できます。手順と精度の担保は「アラートトリアージの自動化：AIエージェントによる一次調査の手順と精度の担保」を参照してください。自動化の効果は MTTA の短縮だけでなく、調査率の向上（すべてのアラートに目が届く状態）として測るべきです。

ランブックと初動連携で MTTC を短くする

封じ込めが遅れる典型的な原因は、技術的な難しさより「誰が判断し、誰が実行するか」が決まっていないことです。端末隔離やアカウント停止は業務影響を伴うため、判断基準・権限・連絡経路をランブックとして事前に定めておかないと、夜間・休日に判断が止まります。検知から封じ込めまでの流れは「インシデント初動対応とSOCの連携：検知から封じ込めまでの実務ランブック」で整理しています。ランブックの整備率と、ランブックに沿って自動実行できる封じ込め措置の割合は、MTTC 改善の先行指標になります。

ポストモーテムで指標を「学習」に変える

NIST SP 800-61 Rev. 3 は、あらゆる活動から得た教訓を「改善（Improvement）」に集約し、分析と優先順位づけを経てすべての機能にフィードバックすることを求めています（NIST, 2025）。KPI の観点では、重大インシデントや長期化案件ごとに、どの工程で時間を要したか（検知・着手・判断のいずれの遅れか）を分解して記録し、対策を検知ルール・ランブック・自動化のいずれかに反映するのがポストモーテムの実務です。改善アクションの完了率を成熟度 KPI として追えば、「開催して終わり」を防げます。

AI SOCはKPIをどう変えるか

ここまでの実務のうち、「一次調査の待ち行列」と「調査率の限界」は、人手を前提とした SOC では構造的に解消しにくい課題です。人が 24 時間 365 日、すべてのアラートを同じ品質で調査し続けることは現実的ではないためです。AI エージェントがアラートの調査・対処を自律的に行う AI SOC は、この構造に直接働きかけるアプローチです。仕組みや従来型 SOC との違いは「AI SOCとは？仕組み・従来型SOCとの違い・導入メリットをわかりやすく解説」で解説しています。

KPI の観点では、AI SOC の効果を主に 3 つの指標で確認します。第一に MTTA と調査率です。AI による一次調査を取り入れた結果、調査開始までの待ち時間や未調査の件数がどう変わったかを測定します。第二に MTTR です。調査の自動化だけで対処完了までの時間が決まるわけではないため、承認待ちや封じ込め、復旧の各工程も分けて確認します。第三に質の指標です。ヤグラAI SOC は、コンテキストメモリで自社環境の情報を調査に生かし、担当者の判断を支援する設計です。誤検知判定やエスカレーションの精度、人が再調査した時間も評価に含めます。手作業をどこまで減らし、脅威ハンティングやポストモーテムに時間を振り向けられるかは、自社環境での検証が必要です。

一方、AI SOC を導入しても、ログのカバレッジが不足していれば MTTD は改善せず、封じ込めの判断基準がランブックとして定義されていなければ MTTC も十分には改善しません。AI SOC は「時間」「量」「質」に強く効く手段であり、「カバレッジ」と「成熟度」は組織側の取り組みとして残ると整理するのが適切です。導入検討の際は、PoC の段階で自社の KPI 定義に基づいて前後比較を行い、掲載数値ではなく自社環境での実測値を確認することをお勧めします。

経営層への報告——KPIをどう見せるか

KPI を計測できるようになったら、最後の課題は経営層への伝え方です。技術指標をそのまま並べても経営層は判断できません。報告は「リスク」「運用」「改善」の 3 層に分けて構成するのが分かりやすい方法です。

リスク層（取締役会・経営会議向け）：重大インシデント件数、MTTD・MTTC の中央値と 90 パーセンタイルの推移、外部通知で発覚した件数、監視カバレッジ（EDR 導入率・ログ取り込み率）。「どれだけ早く気づき、止められる体制か」を示す
運用層（CISO・情報システム部門長向け）：アラート数と調査率、バックログ、誤検知率、重大度別の MTTA・MTTR、エスカレーション精度。「体制が健全に回っているか」を示す
改善層（セキュリティ担当部門向け）：自動化率、ランブック整備率、ポストモーテムの改善アクション完了率、検知ルールの ATT&CK カバー率。「来期どこを良くするか」を示す

報告のたびに意識したいのは、単一時点の数値ではなく推移を見せること、指標の定義と計測点を脚注に明記すること、時間指標を事業インパクトの言葉に翻訳することです。「滞留時間の世界中央値は 14 日（Mandiant, 2026）、AI と自動化の広範な活用で侵害ライフサイクルが平均 80 日短縮（IBM, 2025）」といった外部データを添えれば、自社の数値の位置づけが伝わります。金融機関や防衛サプライチェーンなど規制産業では、監督当局や取引先への報告が求められる場面があり、「いつ検知し、いつ封じ込めたか」を時刻付きで説明できる記録がそのまま説明責任の基盤になります。そして、KPI の悪化を隠さないことです。外部通知で発覚したインシデントや長期化案件を正直に報告し、原因分析と改善計画を添えることが、経営層の信頼と予算の裏付けにつながります。KPI は SOC の成績表ではなく、組織としてリスクをどう管理しているかを示す共通言語です。

まとめ

MTTD・MTTA・MTTR・MTTC は、ライフサイクルのどの区間を測るかで意味が異なり、「R が何を指すか」「起点と終点」「母集団と集計方法」を定義しなければ比較も改善もできません。公開データは、侵害の特定・封じ込めに要する時間が被害コストと結びついていること、自組織で検知できることが滞留時間を左右すること、攻撃側のスピードが秒単位に達していることを示しています。KPI は量・質・時間・カバレッジ・成熟度の 5 軸で設計し、数を追う、閉じることが目的化するといったアンチパターンを避けながら、ログの網羅、自動トリアージ、ランブック、ポストモーテムで改善していきます。AI SOC は時間・量・質の指標に大きく作用する選択肢ですが、カバレッジと成熟度は組織自身の取り組みとして残ります。まずは自社の KPI を定義し、計測できる状態を作ることから始めてください。

関連サービス：EDR・SIEMのアラートをAIエージェントが24時間365日自律的に調査・対処し、MTTRやアラート調査率の改善を支える「ヤグラAI SOC」の詳細はこちら。