ログ管理とは｜記録から分かることと求められる背景

パソコンやサーバーには、操作やアクセスの記録が日々残されています。ログ管理は、こうした記録を集めて活用しやすい形にまとめ、必要なときにすぐ確認できる状態を保つ取り組みです。記録がそろっていれば、情報漏えいやシステム障害が起きたときに、誰がいつ何をしたのかをたどれます。

混同されやすい用語の違い、記録から分かること、そして企業でログ管理が求められる背景という3つの視点が、自社の備えを考える出発点になります。

ログ・ログ収集・ログ管理の違い

「ログ」「ログ収集」「ログ管理」は似た言葉ですが、指し示す範囲はそれぞれ違います。3語の意味と業務での例を下の表にまとめました。

3語の違いを押さえないままツールを選ぶと、記録を集めるだけで終わり、後から検索や監視ができない構成になりがちです。ログを集める段階と、集めた記録を検索・監視・分析できる状態にする段階は、別のものだからです。

たとえば、操作ログを管理サーバーへ送れていても、不審な操作を絞り込めなければ調査には使えません。ログ管理まで見据えて設計しておくことが、記録を活かす前提になります。

ログ管理で分かる「誰が・いつ・何をしたか」

複数のログを関連づけて管理すると、「誰が」「いつ」「どの端末やアカウントで」「何をしたか」を時系列で追えます。反対に、記録が機器ごとにばらばらだと、操作の前後関係をつなげられず、調査に時間がかかります。

たとえば、持ち出したファイルの経路を調べる際、ログインの記録とファイル操作の記録が別の場所にあると、突き合わせに時間を取られます。ただし、取得する設定にしていない操作は記録に残りません。何のために記録を残すのかを先に決めておく必要があります。

企業でログ管理が求められる背景

サイバー攻撃の手口は年々巧妙になり、侵入から発覚までに時間のかかる潜伏型の攻撃も増えています。後から「何が起きたか」を説明できる記録の重要性は、そのぶん高まっています。

独立行政法人情報処理推進機構（IPA）が公表した「情報セキュリティ10大脅威 2026」でも、組織向けの脅威としてランサム攻撃による被害が1位、内部不正による情報漏えい等が7位に挙げられ、外部と内部のどちらにも備えが要ることが読み取れます。

さらに、個人情報保護法第26条は、個人の権利利益を害するおそれが大きい漏えい等が起きた場合に、法を所管する個人情報保護委員会への報告と本人への通知を企業に義務づけています。報告や通知の内容を裏づけるうえでも、記録は欠かせません。記録を取得していること自体を従業員へ知らせておけば、内部不正の抑止にもつながります。

参照元：IPA｜情報セキュリティ10大脅威 2026

参照元：個人情報保護委員会｜個人情報の保護に関する法律についてのガイドライン（通則編）

ログ管理の目的と、記録がない場合に起きること

ログ管理の目的は、情報漏えいや内部不正への備え、システム障害の原因特定、監査や内部統制への対応の3つに大きく分かれます。取得すべきログは目的から逆算して決めるため、目的と必要なログ、確認できることの対応を下の表にまとめました。

情報漏えい・内部不正の抑止と事後調査

記録が残っていないと、情報漏えいが起きても、どの経路で、どの範囲の情報が、いつ流出したのかを特定できません。その結果、取引先など社外への説明が立ち行かなくなります。外部のセキュリティ調査会社に依頼しても、手がかりとなるログがなければ、専門業者でも調査そのものを進められないことがあります。

特に、退職予定者による持ち出しのような内部が絡む調査では、業務端末側の操作の記録と、クラウド側のダウンロードや共有の記録の両方が必要です。事後に動けるかどうかは、記録の有無で決まります。

システム障害の原因特定と早期復旧

システム障害が起きたとき、記録がないと、いつ、どこで異常が始まったのかが分からず、復旧が手探りの試行錯誤になります。原因を一つずつ潰していくしかなく、停止時間が延びてしまいます。障害が複数の機器にまたがる場合はさらに難しく、機器ごとに時刻がずれていると、記録を突き合わせても前後関係をつかめません。

そのため、各機器の時刻を合わせておく時刻同期が欠かせません。反対に、時刻のそろった記録が残っていれば、再発防止策を推測ではなく事実にもとづいて立てられます。

監査・内部統制への対応と説明責任

監査では、「誰が、いつ、どの情報にアクセスし、何をしたか」を証跡として示せる状態が前提になります。ここで記録が欠けていると、ルールどおりに運用してきたこと自体を証明できず、社内外からの信用を損なうおそれがあります。問われるのは、不正がなかったという主張ではなく、それを裏づける記録の有無です。

監査のたびに担当者が複数の機器から記録を手作業でかき集める状態になっていないか、自社の運用を点検しておく必要があります。日常的に記録が残り、すぐ取り出せる仕組みこそが、企業の説明責任を支えます。

見落としやすいのが、システムを管理する側の操作です。アカウントの追加や権限の変更、ログの設定そのものを変えられる特権IDの操作履歴が残っていなければ、点検する立場の人だけが点検されない状態になってしまいます。内部統制の考え方では、権限を持つ利用者ほど記録の対象に含めておく必要があります。

企業が取得する主なログの種類と取得範囲

企業が扱うログは一種類ではなく、記録される内容も取得できる場所もそれぞれ違います。主なログの種類と記録内容、取得元を下の表にまとめました。取得元をたどると、ログは従業員が使う端末、社内のサーバーやネットワーク機器、社外のクラウドサービスという3つの場所に分かれます。

それぞれの場所で取得できるログには、記録できる範囲と追いきれない限界があります。どの場所にどのログがあるのかを把握することが、必要な記録を取りこぼさないための出発点になります。

端末で取得する操作ログ・認証ログ

従業員が使うPCやモバイル端末からは、ファイルの操作、アプリケーションの利用、USBメモリなどの外部デバイス接続、印刷、Webアクセスといった手元の操作を記録できます。この層を担うのは、PC操作ログ管理型のツールや、端末やソフトウェアの資産を把握するIT資産管理ツールです。

WindowsなどのOS標準の機能でも一部のログは取得できますが、複数端末をまたいだ横断検索や、ファイル操作の詳細な追跡には専用の仕組みが要ります。ただし、端末側で取得するログでは、サーバー上だけで完結した操作までは追えません。

サーバー・ネットワーク機器で取得するログ

ファイルサーバーや業務サーバー、ルーターやファイアウォールといったネットワーク機器からは、アクセスの記録、通信の記録、システムの動作記録が残ります。この層を担うのは統合ログ管理型のツールで、複数の機器のログを時系列で突き合わせ、状況把握や原因特定に使う用途に向いています。

注意したいのは、機器の多くが、一定期間を過ぎると古いログを自動で上書き・削除する仕組みを持つ点です。別の場所へ集約しておかなければ、必要な記録が消えてしまいます。反対に、この層では端末の中だけで完結した操作は追えません。

クラウドサービス上で取得するログ

クラウドストレージやSaaS（Software as a Service）上でのファイル操作、共有リンクの作成、社外への送信は、端末側でもサーバー側でも把握できない領域です。こうした操作の記録は、クラウド側のログ機能でしか残せません。

ただし、取得できるログの種類や保存期間はサービスごとに違うため、契約前に確認しておく必要があります。確認したいのは、取得できる操作の種類、保存期間、さかのぼって検索できる期間、CSVなどで出力できるかの4点です。まずは自社が使うクラウドサービスを洗い出し、取得範囲と突き合わせる作業から始めてください。

ログ管理ツールの3つの形態と選び方

ここまで見た端末、サーバー・ネットワーク機器、クラウドという3つの層は、それぞれ別の形態のツールが担います。

3つの形態と、それぞれ単独では追えない範囲を下の表にまとめました。

1つの形態だけですべての層を覆えるわけではないため、守りたい情報がどこにあるのかによって、組み合わせを決めることになります。形態を選ぶときは、守りたい情報の所在、確認したい操作の粒度、既存環境と運用体制という3つの軸で見極めます。

所在については、守りたい情報が社内のサーバーにあるのか、クラウドへ移っているのかを問い直します。粒度については、ログインの有無が分かればよいのか、どのファイルを持ち出したかまで追いたいのかを決めます。体制については、集めた記録を誰が定期的に確認できるのかを確かめてください。この3つに答えられれば、必要な形態は絞り込めます。

ログ管理で行う4つのこと｜収集・保存・監視・分析

ログ管理の実務は、収集、保存、監視、分析という4つの工程を継続して回す取り組みです。それぞれ行うことと、あらかじめ決めておくべき事柄を下の表にまとめました。

多くの企業がつまずくのは、収集と保存で止まってしまう点です。記録が判断に使える状態になるのは、監視と分析まで設計してからになります。記録を残す段階、異常に気づく段階、記録を判断に使う段階のそれぞれで、つまずきやすい点を押さえておくことが、ログ管理を形だけで終わらせないための土台になります。

収集と保存で記録を確実に残す

最初に取り組むのは、ログを取得する機器やサービスと、記録する項目の洗い出しです。取得に抜けや漏れがあると、ログ管理そのものの信頼性が下がってしまいます。次に決めたいのが送信のタイミングです。取得したログを常時送り続けると業務ネットワークに負荷がかかるため、一定量をまとめて送る設定も選べます。

また、業務システム側に残る記録は利用者自身が削除できる場合があるので、収集した時点で別の保管先へ移し、改ざんを防ぎます。保管先そのものが失われる事態に備え、ログのバックアップも設計に含めてください。

ログ監視で異常に気づく

監視は、集めたログのなかから確認すべき事象を、あらかじめ定めた条件で検知する工程です。検知の対象になるのは、機密フォルダへの大量アクセス、業務時間外のログイン、認証の連続失敗といった、通常の業務では起こりにくい動きです。

ここで条件を絞り込まないと、アラートが大量に鳴り続け、通知そのものが誰にも確認されなくなります。そうならないよう、条件ごとに優先度と通知先を決めておきます。さらに、検知したときに誰が何をどう確認し、どの時点で上位者へ報告するのかという対応手順まで定めて、監視はようやく機能し始めます。

ログ分析で記録を判断に使う

分析は、複数のログを突き合わせて操作の流れや傾向を確かめ、原因の特定や改善につなげる工程です。1つのログだけでは見えない動きも、機器やサービスをまたいで関連づければ把握できます。たとえば、ログイン失敗の多いユーザーと、他の従業員よりアクセス頻度が極端に高いユーザーを重ねて見ると、注意すべき兆候が浮かび上がります。

確認した結果を定期的にレポートへまとめておけば、監査対応や運用の見直しにも使えます。反対に、分析の頻度と担当者を決めていなければ、記録は積み上がるだけで判断に使われません。四半期ごとに情報システム部門の担当者が確認する、といった形まで具体化しておいてください。

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

ログの保存期間には、すべての企業に当てはまる正解がありません。業務内容や適用される法令、自社のセキュリティ方針によって必要な長さが変わるためです。

それでも、決め方の手順そのものは共通しています。まず根拠となる法令や時効を確かめ、次にログの種類ごとの期間とコストを見比べ、最後に保管先の権限と改ざん対策まで定める流れです。

保存期間は年数だけを決めて終わる話ではなく、保管と運用のルールまでを含めた一続きの取り決めになります。

法令から決まる期間と、時効から逆算する期間

保存期間の根拠は、3つの系統に分けて考えると判断しやすくなります。系統ごとの考え方と確認すべき情報源を下の表にまとめました。

1つ目の系統では、電子帳簿保存法の対象となる電子取引の記録のように、法令が保存の年限を定めている領域を特定します。法人税法では、帳簿や取引に関して受領した書類について、その事業年度の確定申告書の提出期限の翌日から7年間の保存を求めています。欠損金が生じた事業年度は10年間となるため、自社の状況によって必要な長さは変わります。

2つ目の系統で気をつけたいのは、不正アクセス禁止法の違反に対する公訴時効が3年であることから逆算する考え方は、あくまで目安だという点です。法令がログの保存そのものを義務づけているわけではありません。

進め方としては、自社に適用される法令と業界ガイドラインを先に洗い出し、そのうえで足りない分を時効や発覚までの期間の観点で補います。年数を社内で確定させる際は、対象と年限を所管官庁の一次情報で必ず確認してください。

参照元：国税庁｜電子帳簿保存法一問一答（Q&A）～令和4年1月1日以後に保存等を開始する方～

参照元：国税庁｜No.5930 帳簿書類等の保存期間

ログ量と保管コストのバランス

保存期間を延ばせば、その分だけデータ量が積み上がり、保管にかかるコストも上がっていきます。そこで見直したいのが、すべてのログを同じ期間だけ保存するという発想です。ログには操作ログ、認証ログ、アクセスログなど種類があり、それぞれ重要度が違います。

調査で使う可能性が高いログは長めに、日常業務に関わるログは短めにと期間を分ければ、必要な記録を残しながら費用を抑えられます。クラウドサービスを使う場合は、保存期間が契約プランごとに決まっていることもあるため、自社に必要な期間を満たせるプランかどうかを確かめてください。

保存期間とあわせて決める閲覧権限と改ざん対策

ログには、誰がいつどのような操作をしたかに加え、業務上の秘密や利用者が入力した個人情報がそのまま含まれる場合があります。ログ自体が機密情報であるため、保管先にはアクセス制御をかけます。閲覧できる担当者を職務に応じて限定し、誰がログを閲覧したかという記録も残す運用にしておくと安心です。

さらに、保存期間を過ぎたログを削除するのか別のストレージへ移すのか、監査対応中のように例外として延長する場合はどう扱うのかも先に決めておきます。

こうした取り決めは担当者ごとの判断に任せず、社内規程として文書化しておく必要があります。

ログ管理を運用に定着させる際の注意点

ログ管理は、ツールを導入した時点で完成する取り組みではありません。運用のなかで誰にも確認されないまま記録だけが積み上がり、形だけが残る状態になりやすいためです。つまずきやすいのは、従業員への説明が足りないこと、ログ管理だけでは防げない範囲があること、組織やシステムの変化に設定が追いつかないことの3つです。

従業員に対しては、ログを取得する目的、対象、閲覧できる担当者、保管の方法を社内規程として示します。そのうえで、行動の監視ではなく、企業と従業員の双方を守るための証跡の管理であると伝えてください。

もう一つ押さえておきたいのは、ログ管理が支えるのは事後の追跡だという点です。脅威そのものを遮断する働きはないため、アクセス制御やウイルス対策ソフトの導入、従業員への教育と組み合わせて初めて機能します。

人員や拠点、利用するクラウドサービスが変われば、取得すべき対象も変わります。法改正やシステムの更新にあわせて、定期的に設定を見直す運用が欠かせません。運用を始めたあとに確かめておきたい項目を、下の6点にまとめました。

• ●取得しているログの種類と対象範囲を一覧にしているか
• ●ログの保存期間と保管先を社内規程に明記しているか
• ●ログを閲覧できる担当者を限定しているか
• ●定期的にログを確認する頻度と担当者を決めているか
• ●アラートの条件を見直し、通知が過剰になっていないか確認しているか
• ●ログ取得の目的と範囲を従業員へ周知しているか

ログ管理を支えるDirectCloudの機能

ここまで挙げてきた課題は、クラウド上の操作が記録に残らないこと、管理者の操作が追えないこと、監査に必要な期間の記録がないことの3つでした。こうした課題を解決できるのが、法人向けクラウドストレージ「DirectCloud」です。課題と対応する機能の関係を下の表にまとめました。ただし、端末側やサーバー側のログまでをDirectCloud単独で覆えるわけではありません。

続けて、記録の網羅性、管理者操作の追跡、保存期間と検索性という3つの特長をご紹介します。端末側とサーバー側については、前章で取り上げたPC操作ログ管理型のツールや統合ログ管理型のツールと併用する形が基本になります。クラウド上の記録をDirectCloudで確実に残したうえで、手元の端末やサーバーは別の仕組みで補うと、3つの層を隙間なく覆えます。

250種類以上の操作ログで追跡できる

DirectCloudでは、ユーザーのログイン、ファイル操作、管理者の操作などを含めて、合計250種類以上のログを取得していただけます。ファイル操作ではアップロードやダウンロード、プレビュー、送信などが記録され、共有リンクの作成や受取フォルダの送信履歴も残ります。

誰が、いつ、どこで、どのデバイスから操作したかを、期間やユーザーIDといった条件で絞り込んで検索できます。絞り込んだ結果はCSVファイルへ出力できるため、調査結果を社内で共有する際にもそのままお使いいただけます。

参照元：DirectCloud｜業界トップクラス250種類以上のログ監視

管理者と特権IDの操作も記録できる

一般ユーザーの操作だけでなく、管理者（特権ID）の操作履歴も詳細に取得できます。IPアドレスの登録やユーザーのIPアドレス制限の変更など、権限を持つ立場でなければ実行できない設定変更の履歴が残るため、管理者の操作がブラックボックスになりません。

管理画面のログも、期間やユーザーIDで絞り込み、CSVファイルへ出力していただけます。なお、管理者の操作ログを記録する機能は、ビジネスプラン以上をご契約のお客様に提供しております。自社の運用に管理者の追跡が必要かどうかを、プラン選定の段階でご確認ください。

参照元：DirectCloud｜ユーザーID管理

契約プランに応じてログを長期保存できる

ログの保存期間は、スタンダードプランとアドバンスドプランで最新の3年分、ビジネスプラン以上では最新の7年分です。絞り込み検索の対象となる期間も、前者が3か月間、後者が6か月間と分かれています。

また、Amazon OpenSearch Serviceを用いてログを専用データベースへインデックス化しているため、大量のログでも解析処理が速く、監査や調査の場面で必要な記録をすぐ取り出せます。前章で確認した自社に必要な保存期間と、各プランで提供している期間を突き合わせてご検討ください。

参照元：DirectCloud｜業界トップクラス250種類以上のログ監視

ログ取得の課題を解消した導入事例

記録が残らない状態をどう改善したのか、実際にDirectCloudをご利用いただいている3社の事例をご紹介します。3社が抱えていた課題は、操作ログそのものを取得できなかったこと、OS標準の機能では詳細を追えなかったこと、個人向けサービスの利用で監査に耐えられなかったことと、それぞれ異なります。

いずれも業種も規模も違いますが、記録を残せる状態へ切り替えることで、内部統制や監査対応の課題を解決されています。

操作ログを取得できない状態から追跡性の確保へ

システム開発やネットワーク構築を手がける東ソー情報システム株式会社様では、以前利用していたオンラインストレージでユーザーのファイル操作のログが取得できず、内部統制を強化できない状態が続いていました。共通アカウントが使われていたため、有事の際に誰の操作だったのかをたどれないという課題も抱えておられました。

DirectCloudへ移行いただいたことで、利用者ごとに操作が記録されるようになり、共通アカウントでは分からなかった「誰の操作か」を特定できる状態へ変わりました。インシデントが発生した際の追跡性も確保できています。

OS標準機能の限界から詳細な操作ログの取得へ

不動産管理やビルメンテナンスを展開するトーセイ・コミュニティ株式会社様では、Windows Server標準のログ取得機能に限界があり、いつ誰がどのファイルにどのような操作をしたかという詳細まで把握できていませんでした。さらに、ファイルサーバー管理の前任者が退職されており、権限設定がブラックボックス化していたことも課題でした。

DirectCloudに移行後は、フォルダ単位のアクセス権をユーザーごとに一覧で確認できるようになり、前任者の設定に頼らない権限管理へ切り替えられました。操作ログもファイル単位までたどれるため、内部統制を大幅に強化されています。

個人向けサービスの利用から監査対応可能な環境へ

立体駐車場のメンテナンスなどを手がける株式会社 ファム様では、取引先へのファイル転送に無料の個人向けクラウドストレージを使っており、セキュリティ上の不安を抱えておられました。プライバシーマーク制度の認定に合わせ、ファイル転送の仕組みを早急に見直す必要もありました。

DirectCloudをご導入いただいた結果、プライバシーマークの監査に対応できるセキュリティを確保できました。ユーザー数無制限を生かした全社員での利用により、シャドーITの抑制とコスト削減も両立されています。

ログ管理に関するよくある質問

ログ管理の検討を進めると、似た用語との違いや、社外の端末の扱い、認証制度との関係など、判断に迷う場面が出てきます。

本文で触れていない4つの疑問について、混同されやすい前提とあわせてお答えします。

ログ管理・ログ監視・SIEMは何が違うのか

ログ管理は、記録を集めて保存し、監視や分析まで行う取り組み全体を指します。そのなかで、異常を検知してアラートを通知する工程がログ監視です。

一方、SIEM（Security Information and Event Management）は、複数の機器やサービスから集めたログの関係性を突き合わせる相関分析によって、セキュリティ上の脅威を検知する仕組みです。統合ログ管理の発展形と位置づけられます。まず記録を確実に残す段階にある企業と、相関分析まで踏み込む段階にある企業とでは、必要な仕組みが変わります。

無料ツールやOSSでもログ管理を始められるか

取得と保存に限れば、無料のツールやOSS（Open Source Software）でも始められます。OSとして備わっているログ取得の機能を使い、集めた記録を1か所へ集約するところまでは費用をかけずに実現できます。

ただし、複数の端末をまたいだ横断検索や、ファイル操作の詳細な追跡には専用の仕組みが必要です。構築と運用を自社で担うため、設定や不具合への対応、バージョンの更新にかかる工数も見込んでおかなければなりません。まずは無料の範囲で記録を残し始め、監査対応や検索性が求められる段階で有償のツールへ切り替える進め方が現実的です。

テレワーク・在宅勤務の端末のログはどう扱うか

社外にある端末でも、社内の端末と同じ基準でログを取得し、保管する必要があります。総務省の「テレワークセキュリティガイドライン（第5版）」でも、インシデント発生時に原因を調査できるよう、テレワーク端末の操作ログやイベントログを取得し、可能な限り1年以上保存できる状態にすることが管理者の基本対策として挙げられています。

実務上は、社内ネットワークにつながっていない間の操作を後からまとめて送信する仕組みや、クラウド経由で記録を集約する構成が必要です。端末の紛失や盗難も想定し、端末側にログを溜め込まない設計にしておくと安全です。

参照元：総務省｜テレワークにおけるセキュリティ確保（テレワークセキュリティガイドライン第5版）

ISMSやPマークの取得・更新でログ管理は要件になるか

ISMS認証（ISO/IEC 27001に基づく情報セキュリティマネジメントシステムの認証）とプライバシーマークは、対象とする情報の範囲が異なる別の制度です。前者は組織が持つすべての情報資産、後者は個人情報保護法に定められた個人情報を保護の対象とします。

ただし、どちらもアクセスの記録や定期的な監視に関する措置を求めるため、記録を残していない状態では要求事項を満たせません。審査の場で提示を求められることも考えられるので、記録の取得範囲と保存期間を、各制度の要求と突き合わせておいてください。

まとめ

取り組みの第一歩として、先に挙げた6点の点検項目に自社の運用を当てはめてみてください。一覧にできていない領域が見つかれば、そこが着手すべき出発点になります。

ログ管理は、記録を残すこと自体ではなく、必要なときに使える状態を保つことに価値があります。攻撃の手口が巧妙化し、監査や法令への対応も求められる今、「誰が・いつ・何をしたか」を後から示せるかどうかが、企業の説明責任を左右します。取得する範囲も保存期間も、目的から逆算して決めるからこそ実務に耐える仕組みになり、運用のルールまで定めて初めて機能します。自社の目的を言葉にし、取得できていない領域を洗い出すところから着手すれば、情報漏えいや障害への備えと監査対応を同時に前へ進められます。

DirectCloudは、クラウド上のファイル操作を250種類以上のログとして記録し、管理者の操作履歴やプランに応じた長期保存まで備えた法人向けクラウドストレージです。クラウド側の記録を確実に残す手段をお探しの企業のご担当者様は、ぜひ導入をご検討ください。