「もし今、社内システムから情報が漏れていたら、それに気づけますか？」――この問いに自信を持って「はい」と言える企業は、多くありません。 セキュリティ対策というと「攻撃を防ぐ（予防）」に意識が向きがちですが、攻撃が高度化し、内部不正も後を絶たない今、**「異常に気づき、対応する（検知・対応）」**ことが同じくらい重要になっています。そして、その土台になるのが ログです。
この「気づくための仕組み」に正面から取り組んだのが、**デジタル庁が 2026 年 3 月 31 日に公開した「DS-222 政府情報システムにおける脅威の検知・対応のためのログ取得・分析導入ガイドブック」**です（デジタル庁: デジタル社会推進標準ガイドライン）。サイバー攻撃の高度化や内部不正による情報漏えいの増加を背景に、政府情報システムの運用において 実施しておきたいログ分析のポイントをまとめたものです。
これは政府システムだけの話ではありません。中堅・中小企業の業務システム（顧客管理・予約管理・問い合わせ管理・基幹システム）でも、ログがないと事故に気づけず、原因も追えません。本記事では DS-222 を一次ソースに、なぜ「気づける」設計が必要か、ログがないと何が起きるか、目的から考えるログ設計、業務システムで最低限残しておきたい 5 種のログ、ログ設計チェックリスト、FAQ を整理します。なお本記事は SIEM 製品の比較やコストではなく、「何を・何のために取るか」という設計の考え方に絞ってお伝えします（製品・運用の比較は SIEM・ログ管理の導入ガイド をご参照ください）。
目次
- なぜ「気づける」設計が必要なのか
- ログがないと何が起きるか
- デジタル庁DS-222に学ぶ「目的から考えるログ設計」
- 業務システムで最低限残しておきたい5種のログ
- システム別に見るログ設計の具体例
- ログ設計チェックリスト
- AIチャットボット・RAGのログも忘れずに
- 中堅・中小企業が陥りやすい5つの失敗
- 国内・国際の文脈：NIST・経産省・IPA
- よくある質問（FAQ 10問）
- 参考一次ソース
- まとめ
- あわせて読みたい
なぜ「気づける」設計が必要なのか
セキュリティ対策は、大きく **「予防」と「検知・対応」**の 2 つに分けられます。
- 予防：攻撃を未然に防ぐ（ファイアウォール、認証強化、脆弱性対応など）
- 検知・対応：異常に気づき、被害を最小化する（ログ分析、監視、インシデント対応）
多くの企業は「予防」に投資しますが、予防だけで 100% を防ぎきることはできません。攻撃は高度化し、内部不正も起こりえます。だからこそ、**「もし突破されたら、すぐ気づいて対応できるか」**という検知・対応の備えが必要になります。DS-222 が「脅威の検知・対応のための」ログ分析を主題にしているのも、まさにこの考え方にもとづいています。
「気づけない」ことが大きなリスク
情報漏えいやシステム侵害でとくに深刻なのは、侵害が長期間気づかれないまま続いてしまうことです。気づくのが遅れるほど、被害は広がり、流出する範囲も大きくなります。ログによる検知の仕組みがあれば、異常の兆候を早めに捉え、被害が広がる前に手を打てます。
内部不正にも「ログ」が役立つ
脅威は外部からの攻撃だけではありません。退職者による持ち出し、権限の悪用といった内部不正も、情報漏えいの主な原因の一つです。誰がどのデータにアクセスしたかのログがあれば、内部不正の抑止にも、発覚後の調査にも役立ちます。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
ログがないと何が起きるか
ログを取得・分析していないシステムでは、具体的に次のような状況に陥りやすくなります。
1. 事故が起きても原因を追えない
「情報が漏れたらしい」「データが書き換えられた」――そうした事態が起きても、いつ・誰が・何をしたかの記録がなければ、原因も範囲も特定できません。対応は後手に回り、再発防止も難しくなります。
2. 異常そのものに気づけない
ログを取っていても 見ていなければ、不審なログイン試行や、深夜の大量アクセスといった異常の兆候を見逃してしまいます。「取る」だけでなく「分析・監視する」ところまでが必要です。
3. 説明責任を果たせない
取引先や監督官庁、社内から「何が起きたのか説明してほしい」と求められたとき、ログがないと答えられません。説明責任（アカウンタビリティ）を果たせないことは、信頼にも影響します。
4. 内部不正を抑止できない
「操作が記録されている」という事実そのものが、内部不正の抑止力になります。ログがなければ、その抑止力も働きません。
要点：ログは「事故が起きてから取り始める」ものではありません。事故が起きる前に、設計段階で「何を・何のために残すか」を決めておくことが大切です。これは セキュリティ・バイ・デザイン の考え方そのものです。
デジタル庁DS-222に学ぶ「目的から考えるログ設計」
DS-222 の大切なメッセージは、「ログは手当たり次第に全部取ればよいものではなく、“目的”から考えて設計する」という点にあります。ガイドブックは、ログ分析の概要、目的設定の基本指針、目的設定における分析事象・観点の具体例、ログ取得から分析に向けた留意事項などで構成されています。
「とりあえず全部取る」の落とし穴
ログを「とりあえず全部取る」と、量が膨大になり、保管コストもかさみ、いざというときに必要な情報が埋もれて見つからなくなることがあります。逆に、取るログを絞りすぎると、肝心なときに記録がありません。だからこそ、「何のためにログを使うのか（目的）」を先に決め、その目的に必要なログを設計するという順番が大切になります。
目的の例
ログ取得・分析の目的には、たとえば次のようなものがあります。
- 不正アクセス・侵入の検知
- 内部不正（不正な操作・データ持ち出し）の検知
- 障害発生時の原因究明
- 監査・コンプライアンス対応
- システムの稼働状況の把握
**「自社のこのシステムでは、何を検知・把握したいのか」**を決めることで、取るべきログ（ログイン履歴か、操作履歴か、データ閲覧履歴か）と、保管期間、監視の頻度が決まってきます。
「取る」だけでなく「分析する」
DS-222 のタイトルが「ログ取得・分析」であることが示すように、ログは取得して終わりではなく、分析してこそ意味があります。異常を検知するルールやアラート、定期的なログレビューの仕組みまで含めて設計しておきましょう。
業務システムで最低限残しておきたい5種のログ
中堅・中小企業の業務システム（顧客管理・予約・問い合わせ・基幹システムなど）で、最低限残しておきたいログを 5 種に整理しました。
| # | ログの種類 | 何が分かるか |
|---|---|---|
| 1 | ログイン履歴（認証ログ） | 誰が・いつログインしたか、失敗の試行はないか（不正アクセスの兆候） |
| 2 | 操作履歴（操作ログ） | 誰が・いつ・どのデータを作成/更新/削除したか |
| 3 | データ閲覧履歴（アクセスログ） | 誰が・どの顧客情報・機密データを見たか（内部不正の検知） |
| 4 | エラー履歴（エラーログ） | いつ・どんな障害・異常が起きたか（原因究明） |
| 5 | 管理操作の履歴（管理ログ） | 権限変更・設定変更など、重要な管理操作の記録 |
とくに、顧客情報や個人情報を扱うシステムでは、「誰がそのデータを見たか・変更したか」を残せる 操作ログ・アクセスログが重要です。これがないと、情報漏えいが起きても「誰が関わったか」を追えません。
ログに含めておきたい基本項目
各ログには、最低限 **「いつ（日時）」「誰が（ユーザー）」「何に（対象）」「何をしたか（操作）」「結果（成功/失敗）」**を含めておくと、後から追跡しやすくなります。
システム別に見るログ設計の具体例
「目的から考える」と言っても、自社のシステムに当てはめにくいかもしれません。中堅・中小企業によくある 4 つのシステムで、とくに重点的に残しておきたいログを例示します。
顧客管理システム（CRM・顧客台帳）
顧客の個人情報を扱うため、誰がどの顧客情報を閲覧・更新・出力したかのアクセスログ・操作ログが要になります。とくに、大量の顧客データを一度に出力（エクスポート）した記録は、情報の持ち出しの検知に直結します。
予約・受発注システム
金銭やキャンセルが絡むため、予約・注文の作成・変更・取消の操作ログを残しておきます。誰がいつ取り消したか、不審な大量の操作がないかを追える状態にしておきます。
問い合わせ管理システム
顧客からの問い合わせと個人情報を扱います。閲覧・返信・削除の履歴に加え、外部への送信記録を残しておくと、誤送信・情報漏えいの調査に役立ちます。
ECサイト・会員サイト
不特定多数がアクセスするため、**ログイン履歴（成功・失敗）**がとくに重要になります。同一アカウントへの連続ログイン失敗や、見慣れない地域からのアクセスは、不正ログインの兆候として検知しておきたいところです。
いずれにも共通するのは、「お金」「個人情報」「外部公開」が絡む操作ほど、ログを手厚く残しておくという考え方です。すべてを均一に取るのではなく、リスクの高い操作に重点を置く――これが DS-222 の「目的から考える」の実践になります。
ログ設計チェックリスト
システムを開発・改修するときに、ログについて確認しておきたい項目を整理しました。
■ 目的（何のために取るか）
□ 1. このシステムのログで「何を検知・把握したいか」を決めているか
□ 2. 目的に対して、取るべきログの種類が選べているか
■ 取得（何を残すか）
□ 3. ログイン履歴・操作履歴・データ閲覧履歴を取得しているか
□ 4. 各ログに「いつ・誰が・何に・何をしたか」が含まれているか
□ 5. 重要な管理操作（権限変更・設定変更）が記録されているか
■ 保管（どれだけ残すか）
□ 6. ログの保管期間が決まっているか（短すぎて消えてしまわないか）
□ 7. ログ自体が改ざん・削除されない保護がされているか
■ 分析・監視（どう活かすか）
□ 8. 不審なログイン・異常な操作を検知する仕組みがあるか
□ 9. ログを定期的に確認・レビューする運用があるか
□ 10. 異常を検知したときの対応手順・責任者が決まっているか
このチェックで「取っていない」「見ていない」「決めていない」が出てきたら、そこが事故時の盲点になりやすい部分です。設計・改修のタイミングで埋めておくほうが、後から追加するより確実で、費用も抑えられます。
AIチャットボット・RAGのログも忘れずに
近年、AI チャットボットや RAG（社内文書を検索して答える仕組み）、AI エージェントを業務に取り入れる企業が増えています。これらにも ログ設計が欠かせません。
- 誰が・どんな質問をしたか：不適切な利用や情報の引き出しを把握する
- AI がどのデータを参照し、何を回答したか：誤回答や情報漏えいの調査に必要
- AI が実行した操作（エージェントの場合）：何を・いつ実行したかの記録
とくに AI エージェントは、人間の確認を待たずに操作を実行することがあるため、「何をしたか」を後から追えるログが安全な運用の前提になります。詳しくは AIエージェント導入前のセキュリティ設計 をご参照ください。
中堅・中小企業が陥りやすい5つの失敗
1. ログを取っていない
開発時にログ設計を省いてしまい、そもそも記録がないケースです。事故が起きても何も追えなくなります。
2. 取っているが見ていない
ログは出力されているものの、誰も確認していないケースです。異常の兆候が記録されているのに見逃してしまいます。
3. 保管期間が短すぎる
ログがすぐ上書き・削除され、調査しようとしたときには既に消えているケースです。
4. ログが改ざんされうる
ログ自体が、攻撃者や内部不正者によって消去・改ざんできる状態になっているケースです。証拠としての価値が失われてしまいます。
5. 異常時の対応が決まっていない
異常を検知しても、「誰が・どう対応するか」が決まっておらず、結局そのままになってしまうケースです。
国内・国際の文脈：NIST・経産省・IPA
ログによる検知・対応の大切さは、国内外で一貫して示されています。
NIST「Guide to Computer Security Log Management（SP 800-92）」
米 NIST は、コンピュータセキュリティのログ管理に関するガイド **「SP 800-92」**を公開しており、ログの生成・保管・分析のプロセスを体系的に整理しています（NIST Computer Security Resource Center）。ログ管理の基本的な考え方の参照点になります。
経済産業省「サイバーセキュリティ経営ガイドライン」
経済産業省と IPA の 「サイバーセキュリティ経営ガイドライン」 は、インシデントの検知・対応体制の整備を、経営者が取り組んでおきたい重要事項として位置づけています（経済産業省: サイバーセキュリティ経営ガイドライン）。
IPA の情報発信
IPA（情報処理推進機構）も、インシデント対応やログ活用に関する情報を発信しています（IPA: 情報セキュリティ）。
共通するメッセージ
DS-222、NIST SP 800-92、経産省ガイドライン――いずれも、**「予防だけでなく、検知・対応の備えを」「ログを取り、分析・活用しましょう」**という点で一致しています。
よくある質問（FAQ 10問）
Q1. うちは小さい会社なので、ログ分析まで必要ないでしょうか？
A. 規模に関わらず、顧客情報や機密データを扱うなら取り入れておきたいところです。専任の監視チームがなくても、まずは「ログを取る」「定期的に確認する」だけでも、事故時の対応力は大きく変わります。
Q2. ログは全部取ったほうが安全でしょうか？
A. 「全部取る」は保管コストがかさみ、必要な情報が埋もれてしまいます。DS-222 が示すように、「何のために取るか（目的）」から考えて、必要なログを設計するほうが効果的です。
Q3. ログはどれくらいの期間、保管すればよいでしょうか？
A. システムの重要度・目的・法令や取引先の要件によって変わります。短すぎると調査のときに消えているため、**「いざというとき遡って調べられる期間」**を目安に、設計段階で決めておきます。
Q4. ログを取れば、自動で異常に気づけるのでしょうか？
A. 取るだけでは気づけません。異常を検知するルール・アラート、定期的なログレビューまで設計して、初めて「気づける」状態になります。
Q5. 既存システムにも、後からログを追加できますか？
A. 追加できる場合が多くあります。まず「今どんなログが取れているか」を確認し、不足している重要なログ（操作・アクセス履歴など）から補っていきます。改修のタイミングで設計を見直すのが現実的です。
Q6. SIEM などのツールは必須でしょうか？
A. 必須ではありません。まずは業務システム自体が必要なログを残しているかが先になります。ログが増え、横断的な分析が必要になった段階で、SIEM などのツール導入を検討するとよいでしょう（製品の比較は別記事をご参照ください）。
Q7. 内部不正対策に、ログは役立ちますか？
A. 役立ちます。「誰がどのデータを見たか・操作したか」が記録されていること自体が抑止力になり、発覚後の調査にも欠かせません。
Q8. AIチャットボットやRAGにも、ログは必要でしょうか？
A. 必要です。誰がどんな質問をし、AI がどのデータを参照して何を答えたかを記録しておくと、誤回答や情報漏えいの調査に役立ちます。AI エージェントの場合は、実行した操作のログが安全な運用の前提になります。
Q9. ログ自体が消されたり、改ざんされたりしませんか？
A. その可能性はあります。だからこそ、ログを改ざん・削除されにくい形で保護する設計が重要になります。攻撃者はまず痕跡（ログ）を消そうとするため、ここは大切なポイントです。
Q10. 結局、最初に何から始めればよいでしょうか？
A. 「このシステムで何を検知・把握したいか（目的）」を決め、ログイン履歴・操作履歴・データ閲覧履歴が取れているかを確認することです。取れていなければ、そこから設計・改修を検討していきます。
参考一次ソース
- デジタル庁「デジタル社会推進標準ガイドライン」（DS-222 ログ取得・分析導入ガイドブック を含む、2026-03-31公開）
- NIST「Computer Security Resource Center（SP 800-92 Log Management 等）」
- 経済産業省「サイバーセキュリティ経営ガイドライン」
- IPA「情報セキュリティ」
まとめ
- セキュリティは「予防」だけでなく **「検知・対応（気づいて対応する）」**が重要です。その土台がログになります
- デジタル庁は 2026 年 3 月、**「DS-222 ログ取得・分析導入ガイドブック」**を公開し、脅威の検知・対応のためのログ分析を体系化しました
- ログがないと、事故の原因を追えず・異常に気づけず・説明責任を果たせず・内部不正も抑止できません
- DS-222 の核心は **「目的から考えるログ設計」**です。全部取るのではなく、何のために取るかを先に決めます
- 業務システムで最低限残しておきたいのは ログイン履歴・操作履歴・データ閲覧履歴・エラー履歴・管理操作の履歴の 5 種です
- ログ設計チェックリスト 10 項目で、目的・取得・保管・分析監視を確認しましょう
- AI チャットボット・RAG・AI エージェントにもログ設計は欠かせません
「気づけるシステム」は、設計の段階でログを織り込んだシステムです。事故が起きてからでは、残っていない記録は取り戻せません。
システムのログ設計・改修を相談したい方へ
業務システムや AI システムの開発・改修を検討している方は、**「何を・何のためにログとして残すか」「異常にどう気づくか」**を設計段階で織り込んでおくことで、事故に強いシステムをつくれます。
GXO株式会社では、中小・中堅企業向けに次のようなご相談を承っています。
- ログ設計を含むシステム開発：目的に応じたログ取得・保管・監視の設計
- 既存システムの改修：不足しているログ（操作・アクセス履歴など）の追加
- AIチャットボット・RAGのログ設計：誰が・何を質問し、AI が何を参照したかの記録
- 検知・対応の運用設計：異常検知・定期レビュー・インシデント対応体制づくり
あわせて読みたい
- システム開発は「作ってから守る」では遅い｜セキュリティ・バイ・デザインで考える開発会社の選び方
- AIエージェントに業務を任せる前に｜権限・ログ・暴走リスクと導入前セキュリティチェックリスト
- SIEM・ログ管理の導入ガイド（中小企業向け）
著者: GXO株式会社 初回公開: 2026 年 5 月 23 日
