Windowsのログイン履歴を確認｜イベントログで分かること・限界

Windowsには、ログオン・ログオフ、ロック・ロック解除などの記録が残る場合があり、イベントログからどのアカウントについて、いつ、どの種類のログオンが記録されたかを確認できます。

ただし、最初に区別しておきたいことがあります。

「あるアカウントがログオンした」という記録と、「特定の人物が実際にそのPCを操作した」という事実は同じではありません。

共有アカウント、サービス、自動処理、ネットワークアクセス、遠隔操作などでもログオン関連イベントは発生します。また、ログオンしていた時間を、そのまま「PCを操作していた時間」や「勤務時間」とすることもできません。

MicrosoftはイベントID 4624について、アクセス先のコンピューター上にログオンセッションが作成されたときに生成されるイベントと説明しており、同じ4624でもLogon Typeによって意味が異なります。

一般には「Windowsのログイン履歴」と検索されることが多いため、本記事では検索上の表現として「ログイン」も使用しますが、Windows Security Auditingの技術用語では主に**ログオン（Logon）**として説明します。

この記事では、株式会社赤井事務所／デジタルフォレンジックPROが、Windowsのログオン記録から何を確認でき、どこから先は別の証拠が必要なのかをフォレンジック調査の視点から整理します。

Microsoft公式仕様の確認日：2026年9月13日

Windows PC全体に残る証拠の種類については、PCフォレンジックとは？Windows PCで分かる証拠・調査範囲も参照してください。

Windowsのログオン履歴だけでなく、ファイル操作、アプリ実行、USB接続、ブラウザなどPCの利用状況を広く確認したい場合は、Windows・PCフォレンジックで、主な証拠と調査方法をまとめています。

Windowsのログイン履歴は確認できる？

対象期間のSecurityログが残っていれば、Windowsのログイン・ログオン履歴を確認できる場合があります。

通常の社内管理目的で現在のPCを確認する場合、基本的な入口はイベントビューアーです。

イベントビューアーで確認する基本手順

1. Windowsで「イベント ビューアー」を開く
2. 「Windowsログ」→「セキュリティ」を開く
3. 「現在のログをフィルター」で対象期間やイベントIDを指定する
4. 時刻だけでなく、アカウント、Logon ID、Logon Type、接続元等を確認する

ログオンの確認では4624だけを一覧にするのではなく、目的に応じて4625、4634、4647、4800、4801等も確認します。

また、イベント数が多い場合はPowerShellのGet-WinEvent等で抽出する方法もあります。しかし、抽出できることと、イベントの意味を正しく評価できることは別です。

ログが生成されるかどうかは監査設定にも依存し、過去の記録が現在まで残っているかはログの保存・上書き状況にも左右されます。

懲戒、紛争、訴訟等への利用を想定しているPCでは、対象PCを繰り返し操作して確認するより、すでに取得されているログや保全データを使って解析する方が適切な場合があります。

ログオン記録だけで「誰がPCを使ったか」は断定できない

Windowsログを読むうえで特に重要なのは、アカウントと人を分けることです。

次の関係を同じ事実として扱わないでください。

• 4624がある ≠ その社員本人が操作した
• ログオンした ≠ その時間ずっとPCを操作した
• ログオフ記録がない ≠ その後もずっと使用していた
• PCが起動していた ≠ 誰かがログオンしていた
• ロック解除 ≠ 新しいログオン
• RDP関連のログオン ≠ ローカルのキーボードで操作した

例えば、4624にはInteractiveだけでなく、Network、Service、Unlock、RemoteInteractive等があります。サービスの開始やネットワーク経由のアクセスを、人がPCの前でログインした記録として数えると実態を誤ります。

さらに、人が利用するアカウントであっても、共有アカウント、パスワード共有、保存された資格情報、自動ログオン、管理者による操作、遠隔操作などが考えられます。

そのためフォレンジック調査では、

「Aさんのアカウントに関係する記録がある」

という段階と、

「Aさん本人による操作と評価できる」

という段階を分けます。

Windowsのログオン履歴で確認する主なイベント

WindowsのSecurityログには、ログオン状態を確認するうえで重要なイベントがあります。

イベントIDだけで結論を出すのではなく、イベント本文、アカウント、Logon ID、Logon Type等を併せて確認します。

4624｜ログオンセッションの作成

イベントID 4624は、ログオンに成功し、アクセスされたコンピューター上にログオンセッションが作成されたときに生成されるイベントです。

主な確認項目には、

• Account Name
• Security ID
• Logon ID
• Logon Type
• Workstation Name
• IP Address
• Logon Process
• Authentication Package

等があります。

ただし、4624を見つけただけで、

「この時刻に社員本人がPCの前に座ってログインした」

とは判断できません。

まずLogon Typeを確認し、そのセッションがInteractiveなのか、Networkなのか、Serviceなのか、RemoteInteractiveなのかを区別します。

4625｜ログオン失敗

イベントID 4625はログオン失敗を記録するイベントです。Microsoftは、ログオン試行が行われたコンピューター上に記録され、ワークステーション、メンバーサーバー、ドメインコントローラー等で生成されると説明しています。

確認できる場合がある情報には、

• 対象アカウント
• Logon Type
• Failure Reason
• Status／SubStatus
• 接続元
• 関連プロセス

等があります。

ただし、

4625がある ＝ 不正アクセス

ではありません。

パスワードの入力間違い、古い資格情報を使用する処理、設定されたサービスやアプリ等による失敗も考えられます。

短時間に大量発生している、通常使用しないアカウントが対象になっている、不自然な接続元と一致している、といった周辺事情を確認して評価します。

4634・4647｜セッション終了とユーザーによるログオフを分ける

4634と4647は同じ「ログオフ」と一括りにしない方が正確です。

Microsoftによれば、4634はログオンセッションが終了し、存在しなくなったことを示すイベントです。

一方の4647は、特定アカウントがログオフ機能を使ってログオフ手続きを開始した場合に生成されるイベントです。標準的なInteractive／RemoteInteractiveのログオフでは、4647と4634の両方が確認される場合があります。

4624と4634等を関連付ける場合は、同じPC上のLogon ID等を確認します。

ただし、

4624から4634までの時間 ＝ 人がPCを操作していた時間

とは限りません。

PCを放置していた時間、ロック中の時間、バックグラウンド処理等が含まれる可能性があります。

また、対応するログオフ記録が見つからないことだけから、「その後もセッションが継続していた」と決めることもできません。監査設定、ログの上書き・欠落、セッションの状態等を追加確認します。

4800・4801｜ロックとロック解除

イベントID 4800はワークステーションがロックされた場合、4801はロック解除された場合に生成されるイベントです。

ここで重要なのは、

4801のロック解除 ＝ 新規ログオンではない

ことです。

すでに存在しているユーザーセッションへ戻った場面を示すため、朝の新規ログオンと、昼休み後のロック解除を同じ扱いにはしません。

また、これらは「Audit Other Logon/Logoff Events」に属するため、対象環境で必要な監査記録が生成され、対象期間まで残っていることが前提です。Microsoftは同じ監査カテゴリにRDP等のセッション再接続・切断に関するイベントも含めています。

4648・4672も「本人ログイン」とは限らない

4648は、プロセスが特定アカウントの資格情報を明示的に指定してログオンを試みた場合に生成されます。

Microsoftは、スケジュールされた処理やRUNAS等でよく発生し、通常のOS動作でも発生するイベントと説明しています。したがって、4648が存在することだけを不正な資格情報利用とすることはできません。

4672は、ログオンセッションに特定の強い権限が割り当てられた場合のイベントです。

これも「管理者本人がPCへログインした」という意味ではありません。MicrosoftはSYSTEMアカウントのログオンでも多数の4672が記録されることがあると説明しています。

ログオンタイプから何が分かる？

4624を調べる場合、特に重要なのがLogon Typeです。

同じ4624でも、ログオンタイプが違えば調査上の意味は大きく変わります。

Logon Type	名称	主な意味
2	Interactive	PC上での対話型ログオン
3	Network	ネットワーク経由でユーザーまたはコンピューターがアクセス
5	Service	Service Control Managerによるサービス開始
7	Unlock	ワークステーションのロック解除
9	NewCredentials	現在のトークンを基に、外向き接続用として別の資格情報を指定
10	RemoteInteractive	Terminal Services／Remote Desktopを使った遠隔ログオン
11	CachedInteractive	ドメインコントローラーへ照会せず、PCに保存された資格情報でログオン

Microsoft公式の定義では、Interactive、Network、Service、Unlock、RemoteInteractive等は明確に別のログオンタイプです。

例えばType 3のNetworkは、共有フォルダ等のネットワーク資源へのアクセスでも発生し得ます。

そのため、

Type 3が記録された ＝ 誰かがリモート画面でPCを操作した

とは言えません。

反対にType 10はRemoteInteractiveで、Remote Desktop／Terminal Servicesに関連するログオンです。

また、Type 5のServiceが大量に存在していても、その件数を人のログイン回数にはできません。

フォレンジック調査では、単に「4624を何件発見したか」ではなく、対象アカウント・Logon Type・Logon ID・時刻・接続元等を組み合わせて分類することが重要です。

PC起動・終了とログオン・ログオフは別の記録

PCの稼働時間とユーザーセッションは分けて考えます。

PCが起動した後、ユーザーがすぐログオンするとは限りません。また、ユーザーがログオフしてもPC自体は起動したままの場合があります。

さらに、

• スリープ
• 復帰
• ロック
• ロック解除
• ユーザー切替
• 遠隔セッション

等が入れば、単純な「電源ONからOFFまで」という時間軸では利用実態を説明できません。

したがって、

PC起動時刻 ＝ ログオン時刻

でも、

PC終了時刻 ＝ 人の作業終了時刻

でもありません。

同様に、ログオンセッションが残っていたからといって、その時間ずっとキーボードやマウスを操作していたとは限りません。

勤務実態等を調べる場合は、起動・終了、ログオン・ログオフ、ロック・解除をそれぞれ別の状態として時系列へ配置します。

RDP・ネットワークログオンはどう区別する？

RDPと通常のネットワークアクセスを分けるときもLogon Typeが重要です。

4624のMicrosoft公式定義では、

Logon Type 3＝Network

Logon Type 10＝RemoteInteractive

です。Type 10はTerminal Services／Remote Desktopを使って遠隔ログオンしたセッションに対応します。

一方、Type 3はネットワーク経由のアクセスであり、必ずしもリモートデスクトップ画面を開いたことを意味しません。

RDPについても、

Type 10の4624がある ＝ RDPに関するすべての操作内容が分かった

わけではありません。

Microsoftの「Audit Other Logon/Logoff Events」には、Window Stationへの再接続を示す4778や切断を示す4779も含まれています。RDPでは、セッションをログオフせず切断する場合もあるため、接続、再接続、切断、ログオフを同じ出来事として扱わないことが重要です。

RDP利用の全体像を調べる場合は、

• 対象アカウント
• Logon Type
• 接続元情報
• Logon ID
• 再接続・切断関連イベント
• Terminal Services関連ログ
• 同時間帯のアプリ・ファイル操作

等を照合します。

さらに、RDPで使用されたアカウントが分かっても、その資格情報を使用した実際の人物が誰だったかは別に評価します。

実際の人物によるPC使用を確認するには何を照合する？

実際の操作者を評価するときは、ログオン履歴だけではなく、ログオン後に何が起きていたかを同じ時間軸で確認します。

例えば次のような情報です。

アカウント・端末の対応

最初に、対象PCが誰へ割り当てられていたか、対象アカウントが専用か共用かを確認します。

WindowsのSIDやアカウント名だけでなく、会社の端末管理台帳、利用者変更履歴等も重要です。

ロック・解除とセッション

4624、4634、4647、4800、4801等を照合すると、ログオン、ロック、ロック解除、セッション終了の流れをより具体的に整理できる場合があります。

ただし、これでも物理的な人物確認が完了するわけではありません。

ファイル・アプリ・Webの操作痕跡

同じ時間帯に、

• LNK
• Jump Lists
• ブラウザ履歴
• UserAssist
• Prefetch
• SRUM
• ファイルシステムの記録
• USB接続記録
• アプリ独自ログ

等を確認します。

例えばLNK・Jump Lists等は特定ユーザープロファイルに関連するファイル利用の手掛かりになり得ます。一方、Prefetchはプログラム実行の検証には役立ちますが、それだけで操作したユーザー本人を特定するものではありません。

重要なのは、アーティファクトの数ではなく、

「この証拠は、何を裏付けているのか」

を分けることです。

Prefetch、UserAssist、SRUM、Amcacheなどからアプリやプログラムの実行痕跡を確認する方法については、Windowsのアプリ実行履歴はどこまで分かる？PCフォレンジックで確認できる証拠で詳しく解説しています。

PC以外の記録

人物や勤務実態を確認する目的であれば、

• メール
• Microsoft 365／Google Workspace
• 勤怠
• 入退室記録
• 防犯カメラ
• 業務システム
• 会社支給スマートフォン

等も照合します。

例えば「9時にログオンした」というPC側の記録と、「9時から勤務していた」という勤怠申告が一致しても、それだけで9時から連続して業務を行っていたとは確定できません。

反対にPC操作の空白があっても、会議、電話、紙資料、外出、別端末での業務等があり得るため、

PCログがない ＝ 働いていなかった

とも判断できません。

実際の調査事例｜勤怠とPCログを照合したケース

株式会社赤井事務所／社内不正バスターズが公表している匿名事例には、退職社員から残業代の未払い請求訴訟を起こされた企業から、勤務実態の調査を依頼されたケースがあります。

この事例では、過去の勤怠書類から労働時間を整理し、対象者が使用していたPCのログと照合しています。

その結果、本人が残業と主張している日時に、ネットサーフィンに関するログを多数確認したと公表しています。そのログを証拠として提出した後、訴訟申立てが取り下げられたことも記録されています。

ただし、この公表事例では、4624、4634、4801等のどのWindowsイベントIDを使用したかまでは記載していません。

そのため、

「4624を使って残業時間を否定した事例」

とは扱いません。

また、訴訟申立てが取り下げられたという時系列が確認できても、取り下げの理由をPCログだけに帰属させることも避ける必要があります。

この事例の重要な点は、人が入力・申告した勤怠資料と、PC側に残っていた客観的な利用記録を照合したことです。

PCログは会社側に有利な証拠とは限りません。会社の勤怠記録より遅い時間まで業務関連操作が継続していれば、逆に従業員側の説明を補強する可能性もあります。

当社公表事例：退職した社員から労働訴訟を起こされた事案

Windowsログオン履歴で分かること・分からないこと

ログオン関連記録を評価するときは、「記録された事実」と「そこから推測した事実」を分けます。

記録	比較的言いやすいこと	それだけでは言えないこと
4624	対象PC上にログオンセッションが作成された	特定人物本人がPCを操作した
4625	ログオンに失敗した記録がある	不正アクセスや攻撃だった
4634	ログオンセッションが終了した	本人が手動でログオフした
4647	特定アカウントからログオフ処理が開始された	直前まで本人が操作し続けていた
4800	ワークステーションがロックされた	なぜ離席したか、誰が離席したか
4801	ワークステーションがロック解除された	新規ログオン、物理的な本人による解除
Logon Type 10	Remote Desktop／Terminal ServicesによるRemoteInteractiveログオン	RDP操作の全期間・操作内容・実際の人物
複数ログの整合	セッション状態をより具体的に時系列化できる	操作者本人を完全に特定できる

フォレンジック調査では、この「それだけでは言えないこと」を残すことも重要です。

証拠が不足している部分を推測で埋めるのではなく、

確認できた事実

複数証拠から合理的に評価できること

現在の証拠では確認できないこと

を分けます。

ログが残っていない場合はどう考える？

必要なイベントが見つからなくても、

「その操作はなかった」と直ちに判断することはできません。

主な確認事項は次のとおりです。

• 当時、必要な監査設定が有効だったか
• 対象期間が現在のSecurityログに残っているか
• 最大ログサイズ到達後に古いイベントが上書きされていないか
• ログが削除・消去されていないか
• OSの初期化・再インストール・PC再利用が行われていないか
• EDR、SIEM、Windows Event Forwarding等へ別途転送された記録がないか
• 調査対象期間やタイムゾーンを誤っていないか
• RDP等について別のイベントログも確認すべきではないか

MicrosoftのEventLogServiceポリシーでは、ログファイルが最大サイズに達した場合の動作を設定でき、設定によっては新しいイベントが古いイベントを上書きします。

したがって、

「4624がない」

という結果から言えるのは、まず

「今回確認したデータの範囲では、条件に合う4624を確認できなかった」

ということです。

記録されなかったのか、残っていないのか、抽出対象から漏れているのかを切り分けます。

調査前に保存するもの・避けたい操作

社内処分、訴訟、労務紛争、情報漏えい等でWindowsログを利用する可能性がある場合は、解析より先に証拠状態を考える必要があります。

最初に整理したいのは、

• 対象PC
• 使用アカウント
• 対象期間
• 現在の電源状態
• ネットワーク接続状態
• すでに行った操作
• Securityログ等の保存状態
• EDR・SIEM等へ転送されたログ
• 関連する勤怠・メール・クラウド記録

です。

イベントログを取得する場合も、画面のスクリーンショットだけで終わらせず、可能であれば元のEVTXや管理システムからの出力結果を保存し、対象期間、取得日時、取得者、取得条件、タイムゾーン等を記録します。

一方、調査前には、

• PCの初期化
• OSの再インストール
• ログ削除
• ユーザープロファイル削除
• 不要なOS更新
• 調査ソフトの大量導入
• 大量のファイル操作
• 通常業務での長期間の再利用

等によって証拠状態が変わる可能性があります。

ただし、

「フォレンジック調査をするなら必ず今すぐ電源を切る」

という一律の対応も適切ではありません。

NIST SP 800-86は、揮発性データの価値と取得による影響を評価し、システムに適した取得・シャットダウン方法を判断する必要があるとしています。NISTIR 8387でも、デジタル証拠には通常の物品とは異なる保全上の考慮が必要とされています。

暗号化、メモリ上の情報、進行中の攻撃、情報漏えいの継続等によって判断は変わります。

現在も不正アクセスや情報送信が進行している場合は、証拠保全だけを理由に被害を放置せず、必要な封じ込めを行い、その操作内容と時刻を記録してください。

PC保全の具体的な考え方は、デジタルフォレンジックの証拠保全とは？で詳しく解説しています。

退職者PCについては、退職者PCは初期化してよい？保全の判断基準と残すべき証拠も参照してください。

自社確認で足りる場合とフォレンジック調査を検討する目安

Windowsのログイン履歴を確認したいからといって、すべてのケースでディスク全体のフォレンジック調査が必要なわけではありません。

状況	検討しやすい対応
最近のログオン成功・失敗を確認したい	社内IT担当者によるSecurityログ確認で足りる場合がある
特定アカウントのLogon Typeを確認したい	イベントログや集中管理済みログを確認
共用アカウントで実際の操作者を確認したい	他の操作痕跡との照合を検討
RDP・ローカル・ネットワーク利用を時系列化したい	複数イベント・RDP関連ログを横断して解析
ログが消えている、期間が不足している	PC内の他の痕跡、EDR・SIEM、バックアップ等を追加確認
ファイル、ブラウザ、アプリ、USB等も含めて調べたい	PCフォレンジックを検討
初期化・再配布予定の退職者PCを調べたい	保全の要否を先に判断
懲戒・訴訟・労務紛争等に利用する予定がある	取得・保管・解析経緯を説明できる証拠保全を検討

重要なのは、

何を明らかにしたいのか

を先に決めることです。

「特定アカウントが10時にログオンしたか」を確認したいだけなのか、「10時から18時までAさん本人がPCを使って勤務していたこと」を確認したいのかでは、必要な証拠が大きく異なります。

前者はイベントログだけで確認できる場合があります。

後者は、ログオン履歴だけでは不足し、ファイル、アプリ、ブラウザ、メール、勤怠、入退室等との照合が必要になる可能性があります。

株式会社赤井事務所／デジタルフォレンジックPROでは、必要な事実に応じてWindows PCの証拠保全・フォレンジック調査に対応しています。最初からすべてのデータを解析するのではなく、対象期間、アカウント、PC、現在残っているログを整理して調査範囲を決めることが重要です。

まとめ

Windowsのログイン・ログオン履歴は、Securityログに残っている4624、4625、4634、4647、4800、4801等から確認できる場合があります。

ただし、調査で最も重要なのは、イベントIDを見つけることではなく、その記録が何を意味しているのかを正しく限定することです。

特に押さえておきたいのは次の点です。

• 4624はログオンセッションの作成を示しますが、特定人物本人の操作を単独で証明するものではありません。
• Logon Typeを確認し、Interactive、Network、Service、Unlock、RemoteInteractive等を区別する必要があります。
• ログオンからログオフまでの時間を、そのままPC操作時間や勤務時間にはできません。
• PC起動、ログオン、ロック解除、RDP接続、ログオフはそれぞれ別の事実です。
• 実際の操作者や勤務実態まで確認する場合は、ファイル、アプリ、ブラウザ、USB、メール、勤怠、入退室等を時系列で照合します。
• 必要なログがない場合も、「操作がなかった」と即断せず、監査設定、上書き、他の保存先、別のアーティファクトを確認します。
• 懲戒・紛争等への利用を想定する場合は、PCを初期化・再利用したり大量操作したりする前に、必要な証拠の保全範囲を決めます。

自社のイベントビューアーだけで必要な事実が確認できるなら、それで足りる場合もあります。

一方、「アカウント」ではなく「実際の人物」を特定したい場合や、複数の証拠を組み合わせて過去のPC利用を再構成する必要がある場合は、フォレンジック調査を検討する目安になります。

参考資料

• Microsoft Learn「4624(S): An account was successfully logged on」
• Microsoft Learn「4625(F): An account failed to log on」
• Microsoft Learn「4634(S): An account was logged off」
• Microsoft Learn「4647(S): User initiated logoff」
• Microsoft Learn「4648(S): A logon was attempted using explicit credentials」
• Microsoft Learn「4672(S): Special privileges assigned to new logon」
• Microsoft Learn「4800(S): The workstation was locked」
• Microsoft Learn「4801(S): The workstation was unlocked」
• Microsoft Learn「Audit Other Logon/Logoff Events」
• Microsoft Learn「Audit Policy CSP」
• Microsoft Learn「EventLogService Policy CSP」
• NIST SP 800-86「Guide to Integrating Forensic Techniques into Incident Response」
• NISTIR 8387「Digital Evidence Preservation: Considerations for Evidence Handlers」
• 株式会社赤井事務所／社内不正バスターズ「その他不正調査」公表事例