先日、【医療・教育・サプライチェーン】各種ガイドラインをもとに考える 2026年のログ管理の動向ウェビナーを開催しました。ご参加いただいたみなさま、ありがとうございました。
ウェビナー後に回答していただいたアンケートのなかで、最も多かった課題が「ログ管理・運用の仕組みが整っていない」という切実な声でした。
「機器にログはある（はず）」
「保存期間がバラバラ」
「いざという時に誰も探し方を知らない」……。
この状態が一番怖いのは、間違いなく有事（セキュリティインシデント）の際です。ログがなければ原因特定ができず、対策も打てず、再発の恐怖に怯え続けることになります。
ログはいわば「ITインフラの保険」です。
今回は、SIerやNIerの皆様が、設計・提案時にそのまま活用できる「ログ管理・運用の最小構成」をまとめました。
まずは「ログ管理の仕組み」を作る
まずは「ログ管理の仕組み」を作ります。
こちらはもうやっているよ！という方もいると思いますが、ご参考までにメーカーとしての推奨方法を記載します。
ログ管理の根拠を作ろう
今後、ログ管理はセキュリティ対策で必須要件になっていきますが、まずは「なぜログが必要なのか？」を誰でも分かるように根拠とともに定義をします。
- 業種別ガイドラインを確認： 自治体なら総務省、医療なら厚労省の指針をチェック。
- 「最低ライン」の言語化： 取得項目、保存期間、点検頻度をガイドラインに合わせて定義します。
「なんとなく3か月」ではなく、「ガイドラインに準拠して1年」と言える状態にすることが、提案の説得力を生みます。
ログ収集の種類・方法・期間を決めよう
①何を集めるか（優先順位の策定）
全部集めるとストレージがいくらあっても足りないので、まずはネットワーク機器の「管理系ログ」に絞るのが定石です。
- FW/UTM： 許可・遮断、脅威検知、VPN接続、管理者操作
- ルーター/スイッチ： リンクUp/Down、経路変動、認証ログ
- 最優先事項： 「誰がいつ設定を変えたか」という管理者ログイン・設定変更ログは、原因特定の生命線です。
②どこに集めるか（集約先の最小設計）
ログが散っていると、有事の際に確認するのが非常に大変になり、原因特定が遅くなってしまいます。
「集約先は1箇所」を鉄則にします。
- NTP同期： 時刻がズレたログは証拠能力を失います。
- 容量監視： 攻撃を受けるとログ量は跳ね上がります。ピーク時を見越した設計を。
- アクセス権限： ログそのものの改ざんを防ぐため、閲覧者を限定します。
③どのくらい残すか（保存期間の根拠）
「いっぱいになったら消す」運用をしがちですが、ログ管理の根拠に基づき保存期間を決めましょう。
- 基本ライン： ガイドラインに基づき1年（または半年）と設定。
- 濃淡管理： 直近30日は詳細ログ、それ以前は重要イベントのみに絞って圧縮保存するなど、コストとのバランスを取ります。
ログの確認・運用方法を決める
ここからが一番大事なポイントです。
ログ管理の仕組みができたら、次に決めるべきは「運用をどう回すか」になります。
一般的に採用されているかつ、メーカーとしても推奨している設計をご紹介します。
ログの確認方法を決めよう
①【週次】「異常なし」を確認するだけの15分
毎日全ログを見るのは不可能ですよね。
なので、週に1回、特定の「フィルター」をかけて異常がないかだけを確認します。
- 管理画面へ「ログイン失敗」が続いていないか？（総当たり攻撃の兆候）
- 深夜や休日など、業務時間外の「設定変更」がないか？（内部不正・乗っ取りの確認）
- 特定のIPから「FWの拒否」が急増していないか？（スキャニングの確認）
そして、チェックリストに「異常なし」と記帳します。
この「見た」という証跡が、監査対応において最強の武器になります。
②【随時】「即時アラート」に反応する
いわゆる、特定のログに対して通知する方法で、以下のような通知条件に設定していきます。
- ログの受信が1時間以上止まった（ログサーバー自体の異常・停止）
- 管理者（Admin）権限のパスワード変更、または新規作成
- VPNの同時接続数が異常値を超えた
こちらはおそらく、皆様すでに実行していると思いますが
「通知がきた」＝「すぐに調査を開始する！」という体制が整っていることが一番大切なゴールです。
誰がどう動く？責任者を決めよう
週次でログを確認し、異常時にはすぐに動く体制を整えておく。
ここまでできれば、あとは指揮するリーダー（セキュリティ責任者）と各メンバーの一次役割を決めておけば、運用設計まで可能になります！
①初動の3ステップ
- 特定： 被害端末のIPと、発生時刻を特定する。
- 追跡： そのIPが「いつ」「どこ（宛先）」と「どれくらいの量」通信したかをログ集約サーバーで検索する。
- 隔離： ログから特定した通信経路（ポート/SSID）を遮断する。
まずは被害が広がる前に一時切り分けをして、その後にログの詳細な調査と解析を進めましょう。
②連絡・報告ルート
- 一次報告： 情シス担当・運用責任者
- 二次報告： 経営層・法務（情報漏洩の疑いがある場合）
- 外部相談： 導入SIer、セキュリティベンダー、警察（必要に応じて）
異常事態がないことが一番ですが、どんな時に起こってもスムーズに対応できるように
責任者を筆頭に、インフラ担当に対して年に１回程度の研修を行ったり、緊急時の手順書を作成してすぐに利用できるように手元においておくのがベストです。
ちなみに、生成AI（Google Geminiなど）で「インシデント時の手順書を作って」とお願いすると、いい感じにそれっぽいものが出来上がります。
まだインシデント時のログ管理に関する手順書がないという方は、ぜひ自社の運用ルールに合わせて相談してみてください。（個人的な最近のおすすめはclaudeです！）
最後に
ログサーバーは自作も可能ですが、OSのアップデート、容量管理、検索の重さなど、「ログサーバー自体のメンテナンス」が運用を圧迫しがちです。
もし「そこまで手が回らない」「もっと手軽にログ管理を始めたい」という場合は、ぜひ弊社のSyslogサーバーアプライアンスをご検討ください。導入したその日から「集約・保管・検索」の土台が整います。
「ログ管理、何から手を付ければいい？」というご相談も大歓迎です。まずは一歩、ガイドラインの確認から始めてみませんか？