セキュリティ製品（EDR / SIEM / CASB など）を導入したものの、ダッシュボードを眺めるだけで終わってしまう──そんな悩みはありませんか？本記事では、その解決策として私たちが社内で毎日続けている「お世話会」という取り組みをご紹介します。会の仕組みやアラートの「見方」、チームで続けるための工夫まで、セキュリティ運用に携わる方に向けてまとめました。
こんな経験、ありませんか？
セキュリティ製品を導入したものの、
- 導入後は「ダッシュボードだけ眺めて満足してしまう」
- 実際にアラートが出たとき「対応に立ちすくんでしまう」
このような状態は、多くの組織に共通する悩みです。
「うまく活用できない」の正体
うまく活用できない要因を整理すると、大きく2つの局面に分けられます。
◼︎ 導入時のギャップ
| 要因 | 内容 |
|---|---|
| 製品への過度な期待 | 「入れれば守れる」という期待と現実のずれ |
| 運用の具体的な姿を描けていない | 誰が・いつ・何を見るのかが曖昧 |
| 導入完了がゴールになっている | 本来は運用開始がスタート地点 |
◼︎ 運用の壁
| 要因 | 内容 |
|---|---|
| リソース不足 | 人員などの体制が追いつかない |
| スキル・経験の属人化 | 特定の人しか対応できない |
| 知識習得の「場」がない | 学び合う機会が設けられていない |
その結果として起きること
- ダッシュボードを眺めるだけ ── ランニングコストだけがかさみ、導入時の想いを活かしきれない
- 現在のメンバーや体制を活かせない ── 担当者が複数いても知識や経験の差が埋まらない
- 重要アラートの見逃し ── いざ確認しなければならないとき、確認の仕方がわからない
これらは個人の頑張りだけで解決しようとすると、結局また属人化に戻ってしまいます。大切なのは、チームで継続できる「仕組み」を作ること。
その仕組みが「お世話会」です。
お世話会とは
お世話会は、セキュリティ製品から出るアラートを、セキュリティチーム全員で定期的に確認・対応する会です。
シンプルですが、「全員で」「定期的に」というところに本質があります。
お世話会の概要
| 項目 | 内容 |
|---|---|
| 頻度 | 毎日定例 |
| 時間・ツール | Zoomで1時間枠（平均30分程度） |
| やり方 | 画面共有しながら、一緒にログを見る |
| 参加者 | 原則チームメンバー全員。他チームメンバーの参加も歓迎 |
なぜ「お世話」なのか
セキュリティシステムは「ペット（生き物）」のようなものだと考えています。利用サービスの追加やポリシー変更、新たな脅威の出現により、ログやアラートの出方も変わっていきます。だからこそ、毎日お世話することで変化に気づけるのです。放置すれば状態が見えなくなり、世話を続ければ小さな変化にも気づける──この感覚を大切にしています。
お世話会のポイント
- 正解探しの場ではなく「一緒に考える場」
- 暗黙知の共有を重視する ──「このアラートはまずここを見る」「この通信はいつもの定期処理」といった、文書化しにくい判断の勘どころをチームに広げる
- 事前の資料作成は不要
- 日々の“生活習慣”として続けられる仕組みにする
「知らないアラートが出るたびに立ちすくむ」状態から、「知らないアラートが出ても、見てみよう」と一歩踏み出せる状態へ ── この変化を目指しています。
お世話会の中で行っていること
- アラートやインシデントを確認する
- 情報を精査したうえで、問題なければクローズする
- 情報が足りない場合は、ユーザーヒアリングが必要かどうかを判断する
ヒアリングといっても大げさなものではなく、Slackで本人に「この操作を行われていた認識ですが、あっていますか？」と確認する程度の、軽いやり取りがほとんどです。
設定した時間より早く終わることもあり、その場合は解散して各自のタスクに戻ります。
また、アラート確認だけでなくコミュニケーションの場にもなっています。「業務でわからない点」「相談したいこと」「個人的に気になっていること」を気軽に相談できる環境です。つまりお世話会は、製品やログを「お世話（ケア）する」だけでなく、メンバーを「お世話（サポート）する」場にもなっているのです。
お世話会で確認しているもの
お世話会で確認しているのは「SIEMのアラート」だけではありません。セキュリティ運用の“日々の変化”を拾うために、複数の観点を横断して確認します。
中心のひとつとして、SIEM製品である Microsoft Sentinel に集約されたインシデントも確認しています。
SIEM（Security Information and Event Management）とは？
サーバー、ネットワーク機器、セキュリティソフトなどから「ログ（操作の記録）」を1か所に集約し、相関分析やアラート生成を行うシステムです。通常とは異なるアクセスや不審な振る舞いを早期に検知したり、インシデント発生時に「いつ・どこで・何が起きたか」を効率よく調査できます。長期的なログ保管・検索により、コンプライアンス対応や監査証跡の提出にも活用できます。
チューニングを重ねることで、ノイズとなるアラートを減らし、本当に見るべきものに集中できる状態に近づけています。「このアラートは、閲覧専用（ビューオンリー）権限でサービスを操作したときにも出るログなので、私たちの環境では更に絞り込む追加アクションを構成した方が良い。」といった日々の気づきがチューニングの種になっており、検知ルールの調整や除外の判断は、お世話会での議論から生まれています。
また、SIEM以外にも次のような観点を確認しています（例）。
- 認証・ID：Entra ID（旧 Azure AD）の監査ログ・サインインログ など
- メール/なりすまし：DMARC認証が失敗している状態が想定どおりか（海外IPなど）※DMARC：なりすましメールを防ぐ送信ドメイン認証の仕組み
- SaaS利用/シャドーIT：認可外の生成AIをユーザーが使用していないか（CASB）
- 脆弱性：緊急度の高い脆弱性が出ていないか（脆弱性管理）
こうした「点検項目」を横断的に“お世話”することで、アラート対応だけでなく、運用の変化や違和感に早く気づけるようにしています。
CASB（Cloud Access Security Broker）とは？
利用者とクラウドサービスの間に立ち、どのクラウドサービスが使われているかの可視化、利用制御、データ保護を行う仕組みです。会社が認可していないサービス（シャドーIT）の利用を検知する用途にも使われます。
お世話会での「約束ごと」
運用手順書に沿って確認する
お世話会での気づきをもとに、運用手順書に沿ってアラートを確認しています。これにより「どの種別のアラートか」「どんな観点で確認すればよいか」が整理され、誰が見ても同じ観点で調査が始められる状態になります。
ただし「手順書さえあればいい」「誰かが用意してくれればいい」というわけではありません。利用サービスの追加やポリシー変更、新たな脅威の出現に伴い、確認すべき観点も変わっていきます。
運用手順書も、組織に馴染むものへと「お世話」して育てていく必要があるのです。
実際、お世話会の中で「この観点も確認したほうがよい」「この手順は今の環境に合っていない」といった気づきが出たら、アクションアイテムとして持ち帰り、手順書に反映しています。手順書の更新もまた、お世話会の成果物のひとつです。
具体的な確認観点
お世話会では、次の4つの観点で確認しています。
- どういったアラートなのか（何が問題でアラートとして出ているのか、参考情報はないか）
- 「問題ない」と容認できるのは、どういう情報が揃ったら可能なのか（紐づくアラートはないか）
- 誤検知なのか、そうではないのか（正常検知なら業務上必要な作業で生じたものか）
- ヒアリングが必要な状態なのか、それともこの場で完結するのか
たとえば観点2であれば、「普段とは異なる海外IPからのサインイン成功」というアラートが出たとき、当該ユーザーの出張・VPN利用・作業申告といった裏付け情報が揃ってはじめて「問題なし」と判断できます。
どの情報が揃えばクローズしてよいのかという基準は、アラートの種類ごとに異なります。だからこそ、お世話会を通じてこの「容認の基準」をチームで擦り合わせていくことに意味があります。
補足情報として、Slackの Time チャンネル（業務時間中に何をしているか可視化する仕組み）も参考にします。変更作業を行う際は専用チャンネルで作業内容を共有しているため、こうした情報が調査の助けになります。
ある日のお世話会 ── とある30分の流れ
雰囲気を掴んでいただくために、実際の運用をもとに再構成した一例をご紹介します。
- 開始の儀式 ── 運用手順書を開き、「手順書に沿って確認します」と宣言してスタート。この日の新規インシデントは3件。
- 1件目：管理ポータルへのログイン失敗 ── アクセス元IPを確認すると、いつものISP・国内ロケーションからで、試行回数もごく少数。総当たり的な動きではなく本人の操作と判断し、「確認済みのアクティビティ」としてクローズ。ここまで数分。
- 2件目：単独ユーザーによる大量ダウンロード ── 一見ドキッとするアラートですが、調べてみるとファイル同期ツールによる定期バックアップで、すべて普段と同じIPからの通信。問題なしと判断してクローズ。
- 3件目：本番クラウド環境での普段と異なる経路の操作 ── 調査の結果、CI/CDパイプラインからの自動実行と判明。Slackの作業宣言チャンネルに同時刻の宣言があり、操作ログの時刻とも一致したため、宣言された正規の作業としてクローズ。
あとは定常確認（脆弱性管理の未対応タスクは0件、メール認証レポートは経過観察）と、ちょっとした相談ごとを少し。最後に「調査作業そのものがアラートとして記録されてしまう」という課題が話題になり、除外ルールの検討を翌日のアクションアイテムにして、開始から30分足らずで解散しました。
劇的な攻撃が見つかる日は、ほとんどありません。それでも「いつもどおりであることを、根拠を持って確認する」こと自体に価値があります。「IPは普段のものか」「作業宣言はあるか」「権限は適切か」──こうした突き合わせの型は、この日々の積み重ねの中でチームに染み込んでいきます。
お世話会がもたらす効果
お世話会は、運用の判断を標準化し、暗黙知を横展開し、コミュニケーションと育成の場にもなっている ── そんな仕組みです。
まとめ
- 導入して終わりにしない ── セキュリティ製品は導入がゴールではなく運用が本番。日々の運用に組み込む「仕組み」作りが重要です。
- お世話会で「判断の視点」と「知識」をチームで共有する ── 「正解を当てる場」ではなく、一緒に考え学び合う場にすることが成功の鍵です。
製品とログをお世話し、メンバーとユーザーをお世話する ── その積み重ねが、強い運用文化を育てていきます。さらに、知見が溜まり言語化できる部分が増えれば、その分タスクの自動化にもつなげていくことができます。
セキュリティ運用にお悩みの方は、ぜひ「お世話会」という考え方を取り入れてみてください。
