「もし今、社内システムに不正アクセスがあったら、誰が・いつ・どのデータに触れたかを、後から追えますか？」――この問いに自信を持って「はい」と答えられないなら、ログ保存と監査の体制づくりが、いますぐ取り組むべきテーマです。 セキュリティの世界では、インシデントは「起きるか起きないか」ではなく、「起きたときに検知できるか、後から追跡できるか」で被害規模が大きく変わります。そして、その追跡を可能にする唯一の材料が、システムが記録する ログ（操作・通信・認証の記録） です。

ところが、ChatGPT・Claude・Cursor・GitHub Copilot といった生成 AI を使って自社で組み上げた、いわゆる バイブコーディング のシステムには、ログそのものが残っていないケースが少なくありません。AI は「動くコード」は書いてくれますが、「誰が何をしたかを記録しておきましょう」という運用上の配慮までは、明示的に指示しない限り盛り込んでくれないからです。本連載の第 6 回「ランサムウェアに 6 ヶ月気づかない理由」でも触れたとおり、ログと監視が無い環境は、侵入されても気づけません。

本記事は連載「バイブコーディング危機」第 21 回（防衛策の実装編）として、監査ログとして残すべき 7 カテゴリ、保存期間の決め方、SIEM を内製するか（OSS の Wazuh・Graylog）、MDR を外注するか（月額相場）の判断軸、そして 90 日で監査体制を立ち上げる現実的な工程 を、NIST・IPA・PCI DSS・ISACA を一次ソースに整理します。

目次

  1. なぜ「ログが無い」が致命傷になるのか
  2. 監査ログとして残すべき7カテゴリ
  3. ログの保存期間をどう決めるか
  4. SIEMとは何か：ログを「集めて気づく」仕組み
  5. 内製（OSS）か外注（MDR）か：中堅企業の判断軸
  6. 90日で監査体制を立ち上げる工程
  7. 異常検知ルールの考え方（最初の10項目）
  8. 中堅・中小企業が陥りやすい5つの失敗
  9. 国内・国際の文脈：NIST・IPA・ISACA
  10. よくある質問（FAQ 10問）
  11. 参考一次ソース
  12. まとめ
  13. 関連記事

なぜ「ログが無い」が致命傷になるのか

セキュリティインシデントが発生したとき、対応の出発点になるのは「何が起きたかを正確に把握すること」です。これを フォレンジック（証跡の調査） と呼びます。そして、その調査の材料がログです。ログが無ければ、被害範囲も、侵入経路も、流出したデータの件数も、すべてが推測になってしまいます。

ログが無いと「報告」も「説明」もできない

個人情報の漏えいが疑われた場合、企業には個人情報保護委員会への報告義務が生じます（詳しくは本連載第 22 回で扱います）。このとき求められるのは、「漏えいした個人データの項目」「本人の数」「原因」といった具体的な事実です。ログが無ければ、これらを正確に出すことができません。取引先や顧客への説明、監督官庁への報告、そして社内での再発防止――いずれもログという事実の裏付けがあって初めて成立します。

バイブコーディングのシステムは「記録しない」初期設定

AI に「ログイン機能を作って」と指示すると、ログインの仕組みは作られますが、「いつ・誰が・どの IP からログインしたか」「ログインに失敗した試行はあったか」を記録する部分は、明示的に求めない限り省かれることがあります。同様に、データの更新・削除・閲覧といった操作も、記録されないまま運用されているケースが見られます。つまり、バイブコーディングのシステムは、初期状態では「記録しない」ことが多いのです。

「気づけない」構造を断つ

本連載第 6 回で扱ったとおり、ランサムウェアの被害者の多くは、侵入から発覚まで長期間気づきませんでした。その背景には、ログと監視の不在があります。逆に言えば、ログを残し、それを監視する仕組みを持つことが、「気づけない 6 ヶ月」という構造を断つための前提条件になります。

要点：ログは「平時には何の役にも立たないように見えて、有事に唯一頼れる材料」です。インシデントが起きてから「ログを取っておけばよかった」と気づいても、過去にさかのぼって記録を作ることはできません。

監査ログとして残すべき7カテゴリ

「すべてを記録する」と意気込むと、量が膨大になり、かえって運用が破綻します。米 NIST のログ管理ガイド（NIST SP 800-92: Guide to Computer Security Log Management）も、ログの計画・選別の重要性を説いています。中堅企業がまず押さえるべきは、次の 7 カテゴリです。

カテゴリ何を記録するかなぜ重要か
認証ログログイン成功・失敗、ログアウト不正アクセスの最初の兆候が出る
権限変更ログ管理者権限の付与・剥奪、ロール変更内部不正・乗っ取りの検知
データ操作ログ重要データの作成・更新・削除・閲覧漏えい時の影響範囲の特定
管理操作ログ設定変更、ユーザー追加・削除不審な構成変更の追跡
アクセスログ（Web/API）通信元 IP、リクエスト内容攻撃パターンの分析
エラー・例外ログシステムエラー、異常終了障害・攻撃の予兆把握
ネットワークログ外部との通信、ファイアウォール記録不審な外部通信の検知

「いつ・誰が・何を・どこから」を必ず含める

ログとして役立つためには、各記録に最低限 タイムスタンプ（いつ）・利用者または主体（誰が）・操作内容（何を）・接続元（どこから） が含まれている必要があります。AI に生成させたシステムのログが、単に「エラーが起きた」とだけ記録していて、誰の操作で起きたかが分からない、というケースはよくあります。この 4 点が揃っているかを、まず確認してください。

時刻のずれをなくす（時刻同期）

複数のシステムのログを突き合わせて調査するとき、それぞれの時計がずれていると、出来事の順序が分からなくなります。すべてのサーバー・機器の時刻を NTP（時刻同期の仕組み）で合わせておくことは、地味ですが極めて重要な前提です。

ログの保存期間をどう決めるか

「ログはどれくらい保存すればよいのか」は、よくある質問です。結論としては、自社に適用される法令・業界規制・契約から逆算して決めるのが基本です。

業界規制から逆算する

たとえば、クレジットカード情報を扱う場合に求められる国際的なセキュリティ基準 PCI DSS では、要件 10 において、監査証跡（ログ）の履歴を少なくとも 1 年間保持し、そのうち直近 3 ヶ月分はすぐに分析できる状態にしておくことが求められています（PCI DSS v4.0.1）。このように、業界によっては保存期間が明確に定められています。

一般的な目安

特定の規制が無い場合でも、インシデントの発覚が遅れることを考えると、最低でも 6 ヶ月から 1 年、可能であれば 1 年以上を一つの目安とする考え方が広く採られています。本連載第 6 回で見たように、侵入から発覚まで長期間かかることがあるため、保存期間が短すぎると、いざ調査しようとしたときに肝心のログが消えている、という事態になりかねません。

「すぐ見られる」と「保管しておく」を分ける

すべてのログをいつでもすぐ検索できる状態に置くと、ストレージコストが膨らみます。そこで、直近のログは検索しやすい場所に、古いログは安価なアーカイブにという二段構えが現実的です。PCI DSS の「1 年保持・直近 3 ヶ月は即分析可能」という考え方は、この二段構えのよい参考になります。

改ざんされない場所に保管する

ログは、攻撃者が痕跡を消すために真っ先に狙う対象でもあります。そのため、ログを生成するシステムとは別の場所に集約し、書き換えできない（追記のみの）形で保管することが望まれます。これにより、システムが侵害されてもログだけは守られます。

SIEMとは何か：ログを「集めて気づく」仕組み

ログを残すだけでは、十分とは言えません。残したログを 集約し、相関を見て、異常に気づく 仕組みが必要です。これを担うのが SIEM（Security Information and Event Management＝セキュリティ情報イベント管理） です。

SIEMの役割

SIEM は、複数のシステムから出るログを一箇所に集め、横断的に分析します。たとえば「ある利用者が、短時間に何度もログインに失敗し、その後成功した」という一連の記録は、個別のログを見ているだけでは気づきにくいものです。SIEM はこうした 複数ログの組み合わせ（相関） から、不審な兆候を浮かび上がらせます。

SIEMがあると何ができるか

  • 集約：散らばったログを一箇所で検索できる
  • 相関分析：複数の出来事を組み合わせて異常を検知する
  • アラート：あらかじめ決めたルールに反する動きを通知する
  • 可視化：ダッシュボードで状況を一目で把握する
  • レポート：監査・報告用の証跡をまとめて出力する

ログ管理とSIEMは地続き

「まずログを集める（ログ管理）」と「集めたログから気づく（SIEM）」は、別々の段階というより地続きです。後述する OSS ツールは、ログ管理から SIEM 的な機能まで、段階的に広げられます。最初からすべてを揃える必要はなく、ログ集約から始めて、徐々に検知・アラートへ広げていくのが現実的です。

内製（OSS）か外注（MDR）か：中堅企業の判断軸

監査体制をつくるとき、大きく分けて 自社で構築・運用する（内製） か、外部の専門サービスに任せる（外注） かの二択があります。中堅企業にとっては、この判断が最初の分かれ道になります。

内製：OSSのSIEMを自社で運用する

OSS（オープンソース・ソフトウェア）の SIEM を使えば、ソフトウェアのライセンス費用を抑えながら、自社で監査体制を構築できます。代表的なものを 2 つ挙げます。

  • Wazuh：無料・オープンソースのセキュリティプラットフォームで、ログ収集・分析、ファイル改ざん監視、クラウド連携、PCI DSS や NIST などの規制向けレポートまでをカバーします（Wazuh 公式）。エージェント（各端末に入れる収集役）を通じて、OS やアプリケーションのログを中央に集約します。
  • Graylog：無料で使える「Graylog Open」があり、syslog・Windows イベント・クラウドサービスなど多様なソースからログを取り込み、ダッシュボード・検索・アラートを提供します（Graylog 公式）。

OSS のメリットは費用を抑えられる点ですが、構築と運用を担う人手が必要です。アラートを誰が見て、誰が判断し、誰が対応するか――この運用体制が無いと、「ツールはあるが誰も見ていない」状態になりがちです。

外注：MDRサービスに任せる

MDR（Managed Detection and Response＝監視・検知・対応の運用代行） は、ログの監視・異常検知・初動対応までを外部の専門事業者に委託するサービスです。自社に専門人材がいなくても、24 時間 365 日の監視体制を持てる点が大きな利点です。

費用は提供範囲・監視対象の規模によって幅がありますが、月額数十万円規模が一つの目安になります。専任のセキュリティ担当を採用・育成するコスト（本連載第 14 回・第 24 回で扱う ROI 比較の論点）と比べて、どちらが自社に合うかを検討します。

判断軸の整理

観点内製（OSS）外注（MDR）
初期費用低い（ライセンス無料）サービス開始費用
月額費用人件費が中心月額数十万円規模が目安
必要な人手構築・運用の担当が必要委託先が運用
監視時間自社の勤務時間に依存24 時間体制が可能
ノウハウ蓄積社内に残る委託先に依存
向いているケース技術人材がいる・段階導入したい専門人材がいない・早く始めたい

専任のセキュリティ担当がいない中堅企業であれば、まず重要なログの集約だけを OSS で始めつつ、検知・対応の部分は MDR の活用を検討する、というハイブリッドが現実的なことが多いものです。

90日で監査体制を立ち上げる工程

監査体制は、一度にすべてを完成させようとすると挫折します。90 日を 3 つの段階に分けて、段階的に立ち上げるのが現実的です。

ステップ1（〜30日）：可視化と方針決定

まず、いま何のログが、どこに、どれだけ残っているかを棚卸しします。バイブコーディングのシステムについては、そもそもログを出しているか、出していないなら何を追加すべきかを確認します。あわせて、自社に適用される法令・業界規制から 保存すべきログと保存期間 を決め、内製か外注かの方針を固めます。

ステップ2（〜60日）：ログ集約と保管

決めた方針に沿って、重要なログを一箇所に集約します。OSS を使う場合は、Wazuh や Graylog でログ収集を始めます。このとき、前述の「別の場所に・追記のみで保管する」を意識します。最初は認証ログ・権限変更ログ・データ操作ログといった 影響の大きいカテゴリから始め、徐々に対象を広げます。

ステップ3（〜90日）：検知・通知・運用定着

集約したログに対して、異常検知のルールを設定し、アラートが出たら誰が確認するかという 運用体制を決めます。あわせて、月に 1 回はログとアラートを振り返る 定期レビューの場を設けます。MDR を併用する場合は、この段階で監視範囲・連絡フローを確定させます。

工程のまとめ

期間やること成果物
〜30 日ログ棚卸し・保存期間決定・方針決定ログ台帳・保存ポリシー
〜60 日ログ集約・改ざん防止保管集約基盤（OSS or MDR）
〜90 日検知ルール・運用体制・定期レビューアラート運用・月次レビュー

異常検知ルールの考え方（最初の10項目）

検知ルールは、最初から精緻に作り込む必要はありません。「これが起きたら、まず人が確認したい」という観点で、シンプルなものから始めます。以下は、中堅企業が最初に設定するとよい 10 項目の例です。

  1. 短時間に一定回数を超えるログイン失敗（総当たり攻撃の兆候）
  2. 通常使われない時間帯（深夜・休日）の管理者ログイン
  3. 海外など、普段アクセスのない地域からのログイン
  4. 管理者権限の新規付与・ロール変更
  5. 大量のデータ閲覧・ダウンロード
  6. 重要テーブルの削除・一括更新
  7. 同一利用者の、異なる場所からのほぼ同時ログイン
  8. 退職予定者・退職者アカウントの利用
  9. ログ出力そのものの停止・設定変更
  10. 普段と異なる外部宛ての大量通信

これらはいずれも「必ず攻撃」というわけではなく、「確認したほうがよい兆候」です。最初は通知が多くなりがちなので、自社の通常運用に合わせて少しずつ調整します。

中堅・中小企業が陥りやすい5つの失敗

1. ログを「取っている」が「見ていない」

ログは出力されているものの、誰も確認していないケースです。アラートを見る担当と、対応を判断する責任者を決めておかないと、ログは「貯めているだけ」になります。

2. バイブコーディングのシステムがログを出していない

AI に作らせたシステムが、そもそも操作ログを残していないケースです。新規開発時は「誰が・いつ・何を・どこから」を記録する仕様を最初から盛り込み、既存システムは後付けで追加します。

3. ログとシステムを同じ場所に置いている

侵害されると、攻撃者にログごと消されるケースです。ログは別の場所に集約し、書き換えできない形で保管します。

4. 保存期間が短すぎる

ストレージ節約のため保存期間を短くしすぎ、いざ調査しようとしたときに該当期間のログが消えているケースです。法令・業界規制から逆算し、最低でも一定期間は確実に残します。

5. ツールを導入して満足してしまう

SIEM や MDR を導入したことで安心し、運用ルール・定期レビューを決めないケースです。体制は「導入」ではなく「運用の定着」で初めて機能します。

国内・国際の文脈：NIST・IPA・ISACA

ログ管理と監査の考え方は、国内外の主要な枠組みでも重視されています。

NIST「Guide to Computer Security Log Management（SP 800-92）」

米 NIST の SP 800-92 は、ログ管理の計画・構築・運用に関する実務的なガイドで、インシデント対応やシステム管理に携わる担当者を対象としています（NIST SP 800-92）。ログをどう選び、どう集約し、どう保護するかの基礎を押さえるうえで、出発点になる文書です。

IPA「中小企業の情報セキュリティ対策ガイドライン」

IPA（情報処理推進機構）の 「中小企業の情報セキュリティ対策ガイドライン（第 4.0 版）」 は、専任担当がいない中小・中堅企業向けに、情報資産の管理から具体的な対策までを段階的に解説しています（IPA: 中小企業の情報セキュリティ対策ガイドライン）。ログ管理を含む運用の基礎を、自社規模に合わせて学べます。

ISACA「COBIT」（監査・ガバナンスの枠組み）

ISACA が策定する COBIT は、IT ガバナンスと統制の国際的な枠組みで、IT パフォーマンスや統制の有効性を継続的に監視・評価することの重要性を示しています（ISACA COBIT）。ログと監査は、この継続的なモニタリングを支える具体的な手段にあたります。

よくある質問（FAQ 10問）

Q1. ログは具体的にどれくらいの期間、保存すればよいでしょうか？

A. 自社に適用される法令・業界規制から逆算するのが基本です。たとえばクレジットカード情報を扱う場合の PCI DSS では、ログを少なくとも 1 年間保持し、直近 3 ヶ月分はすぐ分析できる状態にすることが求められています。特定の規制が無い場合でも、最低 6 ヶ月から 1 年を一つの目安にする考え方が広く採られています。

Q2. バイブコーディングで作ったシステムに、後からログを追加できますか？

A. できます。既存システムには、認証・権限変更・重要データ操作といった影響の大きいカテゴリから順に、ログ出力を後付けで追加していきます。新規開発時は、最初からログ仕様を盛り込むことをおすすめします。

Q3. SIEM は中堅企業に必要でしょうか？大げさではないでしょうか？

A. 「ログを集めて気づく」仕組みは、規模を問わず有効です。最初から大規模な製品を導入する必要はなく、OSS のログ集約から始めて、徐々に検知・アラートへ広げる段階的な進め方が現実的です。

Q4. OSS の Wazuh や Graylog は本当に無料で使えるのでしょうか？

A. ソフトウェア自体は無料で利用できます。ただし、運用する人手・サーバー費用・学習コストはかかります。費用の中心はライセンスではなく「運用」になる、と理解しておくのが現実的です。

Q5. MDR を外注すると、月額はどれくらいかかるのでしょうか？

A. 監視範囲・対象規模・対応レベルによって幅がありますが、月額数十万円規模が一つの目安です。専任のセキュリティ担当を採用・育成するコストと比較して、自社に合う方を検討します。

Q6. 内製と外注、どちらから始めるのがよいでしょうか？

A. 技術人材がいるなら OSS による内製から、専門人材がいないなら重要ログの集約は内製しつつ検知・対応は MDR を併用する、というハイブリッドが現実的なことが多いです。自社の人材状況から判断します。

Q7. ログが大量で、どこから手をつければよいか分かりません。

A. すべてを記録しようとせず、影響の大きい順――認証ログ・権限変更ログ・重要データの操作ログ――から始めます。本記事の「7 カテゴリ」を優先順位の目安にしてください。

Q8. アラートが多すぎて、対応しきれません。

A. 最初は通知が多くなるのが普通です。自社の通常運用に合わせてルールを調整し、明らかに問題ない動きは除外していきます。「すべてに反応する」より「重要な兆候を見逃さない」を優先します。

Q9. ログがあれば、インシデントは防げるのでしょうか？

A. ログは「防ぐ」ものではなく「気づく・追跡する」ためのものです。防御（MFA・アクセス制御など、本連載の他回で扱う対策）と組み合わせて初めて、検知から対応までの体制が機能します。

Q10. まず何から始めればよいでしょうか？

A. いま何のログが・どこに・どれだけ残っているかを棚卸しすることから始めてください。そのうえで、保存すべきログと保存期間を決め、影響の大きいログから一箇所に集約していきます。

参考一次ソース

  1. NIST「SP 800-92: Guide to Computer Security Log Management」（ログ管理ガイド）
  2. IPA「中小企業の情報セキュリティ対策ガイドライン」
  3. PCI Security Standards Council（PCI DSS 公式）
  4. ISACA「COBIT」（IT ガバナンス・統制の枠組み）
  5. Wazuh（オープンソースの SIEM・XDR）公式
  6. Graylog（オープンソースのログ管理）公式
  7. 個人情報保護委員会「漏えい等報告・本人への通知の義務化について」

まとめ

  1. インシデントの被害は「起きるか」ではなく 「検知できるか・追跡できるか」 で決まり、その材料が ログ です
  2. バイブコーディングのシステムは、初期状態では ログを残していないことが多く、後付けでの追加が必要です
  3. 監査ログは 7 カテゴリ（認証・権限変更・データ操作・管理操作・アクセス・エラー・ネットワーク） を優先し、各記録に「いつ・誰が・何を・どこから」を含めます
  4. 保存期間は 法令・業界規制から逆算します（PCI DSS は 1 年保持・直近 3 ヶ月は即分析可能）
  5. ログは 改ざんされない別の場所に集約・保管します
  6. 集めたログから気づく仕組みが SIEM。OSS の Wazuh・Graylog で内製するか、MDR で外注するかを、自社の人材状況から判断します
  7. 立ち上げは 可視化（〜30 日）→ 集約・保管（〜60 日）→ 検知・運用定着（〜90 日） の順が現実的です

「動くシステム」を作るだけでなく、「何が起きたかを後から追える」状態を整える。これが、バイブコーディングを安全に運用するための、監査体制づくりの第一歩です。

ログ保存と監査体制の構築を相談したい方へ

GXO の セキュリティ顧問（リテイナー）サービスでは、中堅企業向けに次のようなご相談を承っています。

  • ログ・監査体制の現状診断：いま何のログが残っているかを棚卸しし、不足を可視化
  • 保存ポリシーの策定支援：法令・業界規制から逆算した保存期間・保管方法の設計
  • SIEM 内製の構築支援：Wazuh / Graylog などの OSS を用いたログ集約基盤の立ち上げ
  • MDR 外注の選定支援：自社に合う監視サービスの選定と連携フロー設計
  • 異常検知ルール・運用体制の設計：アラートを誰が見て・誰が判断するかの体制づくり

→ 30 分無料相談を予約する

関連記事

著者: GXO株式会社 初回公開: 2026 年 6 月 10 日 最終更新: 2026 年 6 月 10 日 連載: バイブコーディング危機 第 21 回（全 30 回予定 / 第 5 週・防衛策の実装編）