SOC記事のハブ／公的統計から

MDR／MSSPとは？責任分界点を書いている会社は、2割です

どちらも公的な定義がありません。実体は、契約書の作業範囲だけです。

30秒でわかる「MDR／MSSP」

どちらも監視や運用を外部に委ねるサービスの呼び名です。MSSPは機器の運用と監視、MDRは調査と一次対応まで踏み込む形が一般的とされます。
どちらにも公的な定義は存在しません。国際標準にも国内ガイドラインにも、この2語の定義は置かれていません（第1章）。
だから「MDRだから安心」は成立しません。同じ名前でも、事業者ごとに範囲が違います。
誤解：「MDRなら全部やってくれる」。止める権限と社内を動かす判断は、渡せません。
今日やること：契約書の「対応範囲」と「責任分界点」の記載を読み直す。書いている会社は2割です（第4章）。

この記事は短めのハブです。監視体制そのものの話——何人必要か、標準はどう分けろと言っているか——は SOCとは？に書きました。ここでは「外部サービスを選ぶとき、何を見るか」だけを扱います。

⚠ この記事の前提

この記事は2026年8月19日時点の内容です。MDRとMSSPには公的な定義が存在しないため、この記事の説明は業界での一般的な用法にもとづく整理であり、特定の事業者のサービス内容を示すものではありません。

サービスの割り当ての考え方はITU-T勧告X.1060／JNSA・ISOG-J『セキュリティ対応組織（SOC/CSIRT）の教科書第3.2.1版』、統計は内閣官房国家サイバー統括室の調査資料にもとづきます。特定の製品・サービスの推奨はしていません。

CHAP1

第1章 / 全6章

MDR／MSSPとは（定義がないという話）

まず、これを確認しておく必要があります

言葉としては、こう説明されるのが一般的です。

略	正式名称	一般的に指すもの
MSSP	Managed Security Service Provider	ファイアウォールなど機器の運用と監視を代行する事業者。外部のSOCを借りる形
MDR	Managed Detection and Response	監視に加えて調査と一次対応まで踏み込むサービス。「通知だけ」から一歩進んだ契約形態

業界で広く使われている用法にもとづく整理です。この表は定義ではありません。理由を以下に書きます。

この記事を書くにあたって、国内外の公的資料を確認しました。結果は次のとおりです。

資料	MDR／MSSPの定義
ITU-T勧告 X.1060／TTC標準 JT-X1060	なし（9カテゴリー64サービスで機能を定義する枠組み）
JNSA／ISOG-J『セキュリティ対応組織の教科書第3.2.1版』	なし。MSSPは「サービスポートフォリオを見直すタイミング」の例として登場するのみ
JPCERT/CC『CSIRTガイド』	なし
重要インフラ統一基準（2026年7月31日決定）	なし。「外部サービス」という一般的な語で扱われる

2026年8月時点で筆者が確認した範囲です。「定義が無い」ことの証明はできませんが、少なくとも主要な公的文書はこの2語を定義していません。

🚨 だから「MDRだから安心」は成立しません

定義が無いということは、ある事業者のMDRと別の事業者のMDRで、やることが違っていても、誰も間違っていないということです。「MDR」を名乗るのに満たすべき条件が、どこにも無いからです。

実体は、契約書の作業範囲の記載だけです。名前で比較すると、必ず失敗します。比べるべき軸は第2章に、契約前に聞くべきことは第5章にまとめました。

なお、外部に委ねること自体は、標準的な選択です。SOCの記事で詳しく扱ったとおり、X.1060の整理ではリアルタイム監視・通知・警告は「領域IV＝専門組織を中心に連携すべき領域」に置かれています。ISOG-Jの教科書には、こう脚注が付いています。

「フルインソース」を絶対的な目標とする必要はない。（中略）アウトソース比率が大きくても何ら問題はない。むしろ無理にインソース比率を高めてしまって実態が伴わないことの方が問題となる。

JNSA／ISOG-J『セキュリティ対応組織（SOC/CSIRT）の教科書第3.2.1版』6.3節脚注

外注は妥協ではありません。問題になるのは、外注したかどうかではなく、何をどこまで外に出したかを書いていないことです。

第1章おわり — 次は第2章

CHAP2

第2章 / 全6章

比較するときの5つの軸

名前ではなく、この5つを聞きます

提案書に「MDR」と書いてあるか「MSSP」と書いてあるかは、判断材料になりません。次の5つを、事業者ごとに埋めてください。

軸	確認すること	ここが違うと何が変わるか
1. 検知だけか、対処までか	アラートを通知して終わりか。調査までやるか。端末の隔離まで実行するか	夜中に自社の誰かが起きる必要があるかどうか
2. 24時間か、日勤か	受付が24時間なのか、分析担当者が24時間いるのか。休日はどうか	攻撃は営業時間を選びません
3. 対象範囲	どの機器・どのログが対象か。クラウドとSaaSは含むか。端末は何台までか	範囲外で起きたことは、当然ながら見えません
4. 報告の頻度と形式	月次レポートだけか、随時か。生ログは自社でも見られるか	事故のとき、自社で調べられるかが決まります
5. 夜間の連絡方法	誰の、どの端末に、どうやって届くのか。相手が出なかったら次はどうするのか	ここが最も多く抜けます

整理は筆者によるものです。5つとも、契約書または仕様書に書けます。書けないと言われたら、それ自体が答えです。

⚠

1番の「対処まで」には、必ず条件が付きます

「一次対応まで実施」と書かれていても、実際に端末をネットワークから切り離す操作を、外部の事業者が自社の判断で行える契約はまれです。多くは「事前に合意した条件に該当する場合に限り」という限定が付きます。その条件が何かを確認してください。そして条件に当てはまらないケースは、結局は自社の判断です。判断の枠組みは CSIRT の話になります。

費用の考え方については、自社で持った場合と比べるのがいちばん分かりやすい方法です。SOCの記事で扱ったISOG-Jの要員モデルでは、24時間365日の監視を自社で持つと、常時1名を置くだけで交代要員を含めて6名が必要とされています。中規模のモデルケースでは12名です。その人件費と比べて考えるのが出発点になります。

第2章おわり — 次は第3章

CHAP3

第3章 / 全6章

標準の答えは「サービス単位で割り当てる」

「MDRかMSSPか」という問いを立て直します

国際標準X.1060は、この問題に別の角度から答えを出しています。サービスを64個に分解し、1つずつ「誰が担うか」を書くという方法です。ISOG-Jの教科書には、記入例そのものが載っています。

サービス	推奨レベル	サービス割り当て	現状（As-Is）	あるべき姿（To-Be）
サービス1	ベーシック	インソース（AB部門）	3	5
サービス2	スタンダード	アウトソース（Z-MSSP）	2	4
サービス3	アドバンスド	未割り当て	1	2

出典：JNSA／ISOG-J『セキュリティ対応組織（SOC/CSIRT）の教科書第3.2.1版』図10 CDCのサービスマトリクス（記入例）。数字はサービススコアで、現状とあるべき姿を分けて記録します。

この表の3行目を見てください。「未割り当て」という選択肢があります。やらないと決めたなら、それも1つの答えとして記録します。問題なのは、決めていないのに空欄になっていることです。

💡

問いを「どのサービスを、誰に、どのレベルで」に変えます

「MDRとMSSPのどちらを選ぶべきか」は、答えの出ない問いです。定義が無いからです。標準が用意しているのは、64のサービスを1つずつ見て「インソース（部門名）」「アウトソース（事業者名）」「未割り当て」を書き込む表です。この表を先に埋めてから提案を受けると、比較が一気に楽になります。64サービスの全体像は SOCとは？の第3章にまとめました。

第3章おわり — 次は第4章

CHAP4

第4章 / 全6章

外注しても残る仕事と、責任分界点

数字が、いちばん弱いところを指しています

X.1060は、サービスを「取り扱う情報の性質」と「セキュリティ専門スキルの必要性」の2軸で4つの領域に分けています。そのうち領域Iは「自組織で実施すべき／外部に頼ることが困難」とされる領域です。

外注しても自社に残るもの（領域I）	なぜ渡せないか
リスクマネジメント	何を守るかを決めるのは、事業の判断だから
事業継続性	何を止めて何を続けるかは、経営の判断だから
インシデントハンドリング	社内を動かす権限が、外部にはないから
資産棚卸	自社が何を持っているかは、自社しか知らないから
教育	自社の人を変えるのは自社だから
幹部向け報告	経営に説明する責任は、委託できないから

領域の分類はX.1060／ISOG-J教科書第3.2.1版 6.2〜6.4節にもとづき、右列の説明は筆者によるものです。詳しくは SOCとは？の第5章へ。

そして、外部に委ねるときにいちばん重要なのが責任分界点——どこまでが事業者の仕事で、どこからが自社の仕事かの線引きです。ここに、厳しい数字があります。

サプライチェーンに関して実施しているリスク軽減策	実施率
責任分界点の明確化	19.9%
契約事項の合意	16.9%

出典：内閣官房国家サイバー統括室『重要インフラにおける安全基準等の浸透状況に関する調査について［2025年度］』（2026年7月公表）設問16。回答したのは重要インフラ15分野の2,103事業者です。同資料はこの2項目を「対策の起点」と位置づけ、「いずれも2割を切る低い水準に留まっている」と指摘しています。

国が特に守るべきとして指定した事業者でも、2割です。そして同じ調査資料は、こう分析しています。

サプライチェーンリスクへの認識が広まる一方で、対策の実施率は相対的に低水準である。（中略）リスクとして認識しつつも、実効性を担保するための契約締結やルール整備が追いついていないことが推察される。今後は、単なる現状把握のフェーズから、実効性のあるリスク管理体制への移行が必要と思われる。

同資料「浸透状況と課題－リスクマネジメントに関する取組」

この弱さは、実際の事故にも表れています。重要インフラ事業者から国へ寄せられた情報連絡を原因別に見ると、「外部委託先の管理ミス」だけが4年連続で増え続けています。

年度	外部委託先の管理ミス
FY2022	49件
FY2023	50件
FY2024	62件
FY2025	76件

出典：国家サイバー統括室『重要インフラにおける情報共有件数について（2026年度第1四半期）』原因別類型（複数回答）。他の原因が年によって上下するなかで、この項目だけが単調に増えています。

🚨 起きていることと、手当てされていることが噛み合っていません

事故の原因では外部委託先の管理ミスが増え続けているのに、その入口である契約事項の合意は16.9%、責任分界点の明確化は19.9%。いちばん問題になっているところが、いちばん手つかずです。

MDRやMSSPを選ぶときも、同じことが起きます。サービスの機能を比べる時間の一部を、責任分界点を書く時間に回してください。取引先経由のリスク全般はサプライチェーン攻撃をご覧ください。

第4章おわり — 次は第5章

CHAP5

第5章 / 全6章

契約前に聞く8つの質問

そのまま提案依頼に貼れます

第2章の5つの軸を、実際に聞ける形にしました。回答は口頭ではなく、契約書か仕様書に書いてもらってください。

#	質問	なぜ聞くか
1	アラートを検知したあと、どこまでやりますか。通知まで、調査まで、隔離までのどれですか	第2章の軸1。ここで自社に残る作業量が決まります
2	隔離まで行う場合、御社の判断でできる条件を明記してください	「一次対応まで」の実態が分かります
3	深夜2時に重大なアラートが出たら、誰の何にどう届きますか。出なかったら次はどうなりますか	第2章の軸5。いちばん抜けます
4	分析を担当する人は24時間いますか。受付だけが24時間ではありませんか	第2章の軸2
5	クラウドとSaaSのログは対象に含まれますか。含まれないものを列挙してください	第2章の軸3。範囲外は見えません
6	生ログは自社でも参照・取得できますか。契約終了後はどうなりますか	第2章の軸4。事故調査と乗り換えの両方に効きます
7	責任分界点を図か表で示してください。御社の作業が終わる点はどこですか	第4章。実施率19.9%の項目です
8	御社側で事故が起きた場合、当社への通知の期限は何時間ですか	委託先自身が被害を受ける場合の取り決め

質問リストは筆者によるものです。7と8は、機能の比較に集中していると抜けやすい項目です。

💡

6番は「乗り換えられるか」の質問でもあります

生ログが事業者の環境にしか無い契約だと、解約した瞬間に過去の記録が手元から消えます。侵害の調査は過去にさかのぼる作業なので、これは事故対応の質を直接左右します。「自社にもログが残るか」は、価格表には出てこない重要な差です。ログの扱いは SIEM、調査での使われ方はデジタルフォレンジックをご覧ください。

✅ 今日からできる4つ

① いま契約しているサービスの「対応範囲」の条文を読み直す——通知までか、対処までか。
② 責任分界点が図か表で示されているか確認する——無ければ、次回更新までに作ってもらいます（実施率19.9%）。
③ 深夜のアラートが誰に届くか、実際に確かめる——机上演習のいちばん小さい形です。
④ 生ログが自社でも参照できるか確認する——できないなら、乗り換えと事故調査の両方に影響します。

第5章おわり — 次は第6章

CHAP6

第6章 / 全6章

こんな方に	次に読む記事
この記事の詳細版を読みたい	SOCとは？（要員モデル・64サービス・4領域）
誰が判断するか決めたい	CSIRTとは？
監視の道具そのものを知りたい	EDR／XDR／SIEM
委託先経由のリスクが気になる	サプライチェーン攻撃とは？
事故時の手順を先に作りたい	インシデント対応プレイブック
ログの調査での使われ方を知りたい	デジタルフォレンジック
用語を一覧で見たい	セキュリティ用語辞典

MDR／MSSPについてよく聞かれること

検索でよく見かける疑問から

費用の目安はどのくらいですか？

公的な相場データは存在しません。対象の台数、ログの量、24時間かどうか、対処まで含むかで大きく変わるためです。金額そのものより、比較の物差しを持つほうが有効です。目安になるのが自社で持った場合の人件費で、ISOG-Jの要員モデルでは24時間365日の監視で常時1名を置くだけでも交代要員を含めて6名、中規模のモデルケースで12名が必要とされています（SOCとは？）。これを下回るなら、少なくとも人員面では合理的だと言えます。

中小企業でも契約できますか？

できます。台数の少ない構成向けのサービスは各社が提供しています。ただし契約する前に確認したいのが「受け止める側」です。通知が来ても社内で誰も動けなければ、費用に見合いません。まず第5章の質問3（深夜のアラートが誰に届くか）を、自社側について答えられるようにしてください。これは CSIRT の話であり、ISOG-Jが「フルインソースを絶対的な目標とする必要はない」としつつ領域Iを自組織に残しているのも同じ理由です。

自社にログは残りますか？

契約によります。必ず確認してください。事業者の分析基盤にログを集約する形では、生ログの参照可否と保存期間、契約終了後の扱いが契約条件で決まります。侵害の調査は過去にさかのぼる作業なので、ログが手元に無いと自社では何も確かめられません。第5章の質問6です。なお国内では、侵害から発覚までに長い期間が空く例が知られており、ログの保存期間が短いと、その期間の記録がすでに消えているという事態が起こり得ます（デジタルフォレンジック）。

乗り換えは可能ですか？

可能ですが、どれだけ大変かは契約内容で決まります。移行しにくくなる典型は、①生ログが事業者側にしか無い ②チューニングの内容が共有されていない ③検知ルールが事業者独自で持ち出せない——の3つです。これらは契約時に確認しておけば、あとで効いてきます（第5章の質問6）。また第3章のとおり、X.1060のサービスマトリクスで「どのサービスを誰に割り当てているか」を自社の表として持っておくと、乗り換え先に説明する材料がそのまま揃います。

出典・参考

JNSA／ISOG-J『セキュリティ対応組織（SOC/CSIRT）の教科書第3.2.1版』（2025年） https://isog-j.org/output/2017/Textbook_soc-csirt.html
ITU-T勧告 X.1060／TTC標準 JT-X1060『Framework for the creation and operation of a cyber defence centre』 https://www.itu.int/rec/T-REC-X.1060/en
内閣官房国家サイバー統括室『重要インフラにおける安全基準等の浸透状況に関する調査について［2025年度］』（2026年7月） https://www.cyber.go.jp/policy/group/infra/policy.html
内閣官房国家サイバー統括室『重要インフラにおける情報共有件数について（2026年度第1四半期）』 https://www.cyber.go.jp/policy/group/infra/policy.html
JPCERTコーディネーションセンター『CSIRTガイド』 https://www.jpcert.or.jp/csirt_material/

最終更新：2026年8月19日／次回見直し予定：2027年8月（公的定義が存在しない領域のため、統計と標準の改訂を年1回確認します）

名前ではなく、線を引いたかどうかです

MDRにもMSSPにも公的な定義はありません。だから名前で比べても答えは出ません。標準が用意しているのは、サービスを1つずつ見て「インソース（部門名）」「アウトソース（事業者名）」「未割り当て」を書き込む表です。そして事故の原因では外部委託先の管理ミスが4年連続で増え続けているのに、責任分界点を明確化している事業者は19.9%——いちばん問題になっているところが、いちばん手つかずです。機能を比べる時間の一部を、線を引く時間に回してください。

この記事は2026年8月19日時点の公開情報にもとづいています。MDR・MSSPには公的な定義が存在しないため、第1章の整理は業界での一般的な用法によるものです。第2章の5軸、第4章右列、第5章の質問リストは筆者によるもので、公的な雛形ではありません。特定の事業者・製品の推奨はしていません。契約条件の判断は、必ず法務にご相談ください。