数年前までは、小規模な企業が自社で SOC を運営するという発想は、現実的とは言い難いものでした。そのためには、複数のアナリスト、検知エンジニア、24時間365日のシフト体制、そして全体を理解して運用できる組織的知見が必要だったからです。多くの組織にとって自然な選択肢は、Managed Security Services Provider（MSSP）に運用を委ね、うまくいくことを期待することでした。
しかし、多くのチームにとって、まさにその「うまくいくことを期待する」という点が問題でした。SOC のアウトソーシングモデルは、セキュリティ運用は複雑であり、人材は不足しており、専門事業者に任せた方がより良い成果が得られるはずだ、というもっともな前提の上に成り立っていました。ところが実際には、アナリストの離職、文脈の喪失、十分な補足情報もないまま差し戻されるアラートなど、現場での体験には大きなばらつきがありました。負担軽減のために外部委託したはずの組織が、結果として同じような作業を、より高いコストで引き受けることになるケースも少なくありません。
ただし、状況は変わってきています。AI 主導のセキュリティ運用によって、小規模なチームでも実現できることが大きく広がりました。社内運用か外部委託かという問いも、以前ほど一方的に「外部委託」に傾くものではなくなっています。今では、セキュリティ運用の一部または全部を社内に戻す組織が増えています。判断の前提条件そのものが、根本から変わったためです。
外部委託された SOC の何が実際に問題なのか
MSSP との関係における問題は、徐々に表面化し、ある時一気に顕在化する傾向があります。多くの場合、それは提供側の善意の欠如ではなく、構造的な問題です。
まず挙げられるのが、知識の喪失です。SOC アナリストの平均在職期間は 18 か月未満とも言われており、この数字でさえ実態より長めかもしれません。MSSP 側であれ社内チームであれ、アナリストが離職するたびに、その人が自社環境について理解していた内容も一緒に失われます。後任者は立ち上がって成果を出せるようになりますが、やがてその人も離職します。その結果、オンボーディング後に品質が上がり、離職で下がり、後任者の立ち上がりでまた上がる、という鋸歯状のパターンが生まれます。MSSP を利用している場合、自社がそのカーブのどの位置にいるのかを把握しにくいという問題もあります。
エクサフォースのある大手機関のお客様も、まさにこのサイクルを経験していました。もともとは SOC を社内で構築していましたが、燃え尽きや離職によって継続が難しくなり、MSSP に委託しました。しかし、品質のばらつきが委託先に移っただけでした。ある月は精度の高いアラートが届き、翌月はそうではない。費用に見合う安定した品質は得られませんでした。
次にあるのが、コンテキストギャップです。外部委託しているチームから繰り返し聞く不満の一つは、MSSPがアラートに確信を持てないときに起こることです。本来なら解決まで進めるべきところ、最小限の補足情報しか付かないまま社内チームへ差し戻されることがあります。その結果、社内担当者は、自分たちで作成していない検知に対して、十分な文脈がないまま、場合によっては直接アクセスできないツールを使って調査しなければなりません。これでは、外部委託の意義の多くが失われてしまいます。
そして最後が、透明性の欠如です。MSSP との運用は、今でもブラックボックスになっていることが少なくありません。顧客はログを渡し、MSSP からはアラートが返ってくるだけです。チューニングの判断、検知ロジック、トリアージ基準といった重要な要素は、利用者から見えないところで決まります。その結果、品質を評価しにくく、カバレッジの改善はさらに難しくなり、外部委託を続けながら社内の運用知見を蓄積することもほとんどできません。
もちろん、これは外部委託そのものが間違っているという意味ではありません。ただ、その価値提案は当初の売り文句ほど強固ではなく、実際には現場で作業する人に大きく依存していた、ということです。
AI SOC が前提を変える理由
数年前には難しかった「社内回帰」が今現実的になっているのは、AI 主導のプラットフォームが運用モデルをいくつかの重要な点で変えたからです。
最大の変化は、組織の知識がようやく定着するようになったことです。従来の SOC では、社内でも外部委託でも、知識は個人の頭の中、Confluence のページ、あるいは「あのアラートは毎月新入社員の入社日に必ず出るから無視してよい」といった暗黙知の形で存在していました。そうした人が離れると、その理解も一緒に失われます。
AI SOC プラットフォームでは、その知識がシステムに組み込まれます。アナリストがあるアラートを誤検知と判断し、その理由を記録すれば、その判断根拠は次回以降も残ります。同様のアラートが発生したとき、システムはすでに履歴に基づく文脈を持っています。業務上の文脈も同じです。あるお客様は「毎月第1火曜日は新入社員の入社日で、その日は過去 45 日以内に作成されたアカウントによる MFA 登録が急増する」と共有してくれました。従来の SOC では、その知識は誰か一人の頭の中か、誰も読まない Wiki にある程度でした。今では、それがシステムに組み込まれ、自動的に適用されます。人の入れ替わりの影響は残るとしても、ゼロからやり直しになるわけではありません。
二つ目の変化は、人がアラートを見る前に、トリアージと調査が進むことです。従来の SOC では、アラートが作業の出発点でした。アナリストはアラートを受け取り、ログを引き、ユーザー履歴を確認し、権限を評価し、文脈を組み立てます。このプロセスこそがセキュリティ運用における最も労力のかかる中核業務であり、MSSP が対価を得ていた主要な部分でもあります。
AI SOC プラットフォームは、この作業を事前に実行します。たとえばエクサフォースの Exabots は、すべてのアラートに対して包括的なトリアージ処理を行い、過去のベースライン、設定データ、業務文脈、過去の対応結果を取り込みます。誤検知の大半はこの段階で除外されます。最終的に残るのは、十分な文脈と詳細な説明が付いた検出結果です。これにより、小規模なチームでも、以前ならはるかに大きな体制、あるいは外部委託先が必要だった業務量に対応できるようになります。
この変化は、最初に採用すべき人材にも影響します。従来は、一人だけ採用して始めることはできませんでした。アラートのトリアージ、調査、対応フローを回すために、まずアナリストのチームとマネージャーが必要で、その後さらにアナリストを増やし、場合によっては検知エンジニアや SOAR の自動化担当も必要になります。土台が手作業だったため、組織は裾野の広いピラミッド型にならざるを得ませんでした。
一方で、AI がトリアージを担うようになると、組織はセキュリティ体制の初期段階から、検知エンジニアや脅威ハンターを優先して採用するようになります。これらの役割は、組織固有の知識と、AI がまだ十分に代替できない創造的・探索的な調査能力の両方を必要とします。燃え尽きや離職の原因となっていた、単調で反復的な作業はプラットフォーム側が吸収します。より興味深い仕事に集中できる人材は、結果として長く定着しやすくなります。
私たちは、これを実際の現場で見てきました。ある小規模なヘルステック企業では、少人数のセキュリティ担当者だけで完全内製の SOC を運営しています。2 年前であれば、これは現実的ではなかったでしょう。しかし、その企業には社内に十分なセキュリティ知見があり、AI SOC が運用負荷を処理してくれることで、MSSP は不要だと判断できました。出力はすでにトリアージされ、文脈も付与されています。チームはノイズの選別ではなく、検知エンジニアリングや脅威ハンティングに時間を使えるようになったのです。
社内回帰は二者択一ではない
ここでの意思決定は、「MSSPの利用をやめる」か「現行の体制を維持する」かの二択ではありません。その中間にはさまざまな選択肢があり、多くの組織はそのいずれかを採用します。
たとえば、特定の機能だけを社内に戻し、その他は外部委託のままにするケースがあります。よくあるのは、検知エンジニアリングを社内へ戻すパターンです。自社環境を最もよく理解している社内チームが検知を作成・チューニングし、サービスプロバイダーは引き続き運用トリアージや調査を担当します。これにより、24時間365日の体制を自前で構築しなくても、検知品質に対する主導権を持てます。
また、従来の MSSP モデルを逆転させる組織もあります。通常業務時間中のコアワークフローは社内チームが担い、夜間・週末・祝日のみ MSSP に任せるのです。これは、誰が受け手であっても一貫した文脈付きアラートを提供できる AI SOC プラットフォームと非常に相性が良い運用モデルです。
どのモデルが適切かは、それぞれの状況によって異なります。社内にどのような専門性があるのか。その人たちは、実際には何に時間を使いたいのか。どれほどの速度で成長しているのか。どこで業務負荷が予測不能に跳ね上がるのか。あるお客様が使っていたたとえが印象的でした。「スーパーボウルの日に合わせて駐車場の台数を決めることはしない。普段の日を基準に設計し、ピーク時は別の手段で吸収する。」
社内回帰を正しく進める方法
運用の全部または一部を社内に戻すことを検討しているなら、私たちが実際に効果を見てきた進め方があります。
ツールを選ぶ前に、SOC の目的を定義する
何かを変える前に、まず自社の SOC が何のためにあるのかを明確にしてください。最重要資産は何か。自社にとって本当に重要な脅威は何か。現時点で、あえて対応しないと決める範囲はどこか。これは当然のように思えるかもしれませんが、実際にはここを飛ばすチームが少なくありません。成功の定義を言語化する前に採用やツール導入を始めてしまい、結局は何も十分に守れない SOC を作ってしまうのです。
MSSP が実際に何をしているかを監査する
何を社内に戻すかを決めるには、まず委託先が実際にどの価値を提供しているのかを率直に把握する必要があります。アラートを解決まで進めているのか、それとも転送しているだけなのか。検知は自社環境向けに調整されているのか、それとも無差別に発報する既成ルールを動かしているだけなのか。件数は減っているのか、質は上がっているのか、それともベンダーのロゴが付いただけで同じ量のノイズが来ているのか。この監査によって、実際に価値を生んでいる機能が、当初の想定とは違っていたと分かることもよくあります。
自社の人材に合った運用モデルを選ぶ
あるお客様は、従業員 1,300 人超のヘルスケア企業で、社内に優秀なセキュリティ人材を多数抱えていました。それでも、SOC スタッフ機能については エクサフォースの 24時間365日対応を活用することを選びました。自社チームはプロダクトセキュリティなど他の領域との親和性が高く、24時間体制の SecOps 監視を自前で回すより、そこは外部に任せた方が合理的だと判断したためです。SOC の主導権は社内に置いたまま、Exaforce でカバレッジギャップを埋め、継続的なトリアージ業務を補完していました。
一方で、社内に深い SecOps の専門知識を持つ、より小規模なヘルステック企業は、すべてを自前で運営する道を選びました。同じ AI SOC プラットフォームを使っていても、運用モデルは大きく異なります。どちらの選択も、それぞれの状況に照らして正しかったのです。
24時間365日の対応を軽視しない
これが、組織が外部委託要素を残す最大の理由であり、それには十分な理由があります。24時間365日の対応体制を整えるには、大規模なチームか、国際的な拠点体制が必要です。AI はトリアージ負荷の多くを継続的に処理できますが、それでも午前 2 時に人間の判断が必要になる場面は残ります。その体制を持てないのであれば、夜間や休日だけでも MSSP を活用し続けるのは現実的な選択です。
切り替え前に並行運用する
社内回帰は、スイッチを切り替えるように一気に進めるものではありません。外部支援を使いながら社内能力を構築する重複期間が必要です。その期間を意図的に活用してください。一定期間、AI SOC プラットフォームを MSSP と並行して運用し、出力を比較し、ギャップを洗い出し、業務文脈ルールを構築しながら、システムに自社環境を学習させます。AI がプロセスを加速できるとはいえ、社内 SOC を有効に機能させる組織知は蓄積に時間がかかります。移行を急ぐと、かえって以前より悪い状態になりかねません。
本当に重要な指標を追う
社内回帰の目的はコスト削減ではなく、より良い成果を得ることです。もちろん結果としてコストが下がることはあり得ますが、本質ではありません。検知までの平均時間、対応までの平均時間、誤検知率、またアナリストの業務負荷や満足度も継続的に確認してください。社内運用が MSSP より良い結果を出せていないなら、やり方を見直すか、移行のタイミング自体を再考すべきです。
今後の方向性
12 か月前、SIEM やセキュリティ運用の世界で長く働いてきた人に、小規模なスタートアップが独自に SOC を運営できるかと尋ねれば、即答で「無理だ」と言われたでしょう。作業負荷が大きすぎ、ツールには多くの手間がかかり、その規模では人材面の課題も解決不能だと思われていたからです。
しかし、もはやそれは当てはまりません。そしてその意味は、単に各組織の外部委託判断にとどまりません。人材不足そのものは解消していませんが、AI によって SOC に必要な人数は減りました。アラート件数は依然として膨大でも、インテリジェントなトリアージにより、その大半は人の手に届く前に処理されます。運用負荷の中心は、手作業から、システムの設定と監督へと移っています。
他に選択肢がなかったから外部委託していた組織は、その前提が今も本当に成り立つのかを問い直す価値があります。答えは今でも「はい」かもしれません。ただし、それは過去の惰性ではなく、今の状況に照らした意図的な判断であるべきです。
そして、今日どの選択をしたとしても、将来もう一度見直す前提で考えてください。組織が成長し、チームが新たな能力を身につければ、必要な体制も変わります。今年に最適な SOC モデルが、2 年後も最適とは限りません。それで構わないのです。もともとこれは、固定された答えではなく、連続的な選択肢の中で考えるべきものだからです。
こうした運用モデルの中で、自社がどこに位置づけるべきかを検討している場合は、エクサフォースが支援できます。AI SOC プラットフォームと MDR の両方を提供する立場として、双方の運用を踏まえたうえで、貴社にとって現実的な選択肢を明確にお伝えします。顧客事例や意思決定のフレームワークについてさらに詳しく知りたい方は、ウェビナーの全編録画をご覧ください。
