Windowsサーバーでトラブルが起きたとき、「何が原因だったのか」を探るために欠かせないのがイベントビューアーです。
しかし、いざ開いてみると情報が膨大で「どこを見ればいいのかわからない」と感じたことはありませんか？
本記事では、イベントログの基本的な読み方から、実際の調査ステップ、PowerShellでの活用法まで、実務で役立つノウハウを整理して紹介します。
この記事を読むとわかること
- イベントビューアーの基本構成と主なログの種類（システム・アプリケーションなど）
- トラブル調査時に見るべきログの優先順位と読み解き方
- PowerShellを使ったイベントログの抽出・CSV保存の実践例
Windowsサーバーのイベントビューアーとは何か
イベントビューアーとは、Windowsが自動的に記録している「イベントログ」を閲覧・調査するための管理ツールです。
OSの内部動作やアプリケーションの実行状況、セキュリティ関連の履歴まで、かなり幅広い情報が時系列で蓄積されており、トラブル発生時の原因特定に欠かせません。
起動方法は、[スタート]メニューで「eventvwr」と入力するか、「Windowsキー + R」で[ファイル名を指定して実行]を開いて eventvwr.msc と入力する方法が一般的です。
コントロールパネルや「サーバーマネージャー」からも起動できますが、結局このショートカットが一番早い印象です。
最初に迷う「どこを見ればいいか」問題
イベントビューアーを開くと、左側にツリー形式のログ一覧が表示されます。初心者のうちは、この構成だけで圧倒されがちですが、実際にチェックすべきなのは大きく分けて以下の3つです。
- システム：OSやドライバ周辺の情報
- アプリケーション：アプリケーションやサービスの記録
- セキュリティ：ログオンなどセキュリティ関連の動作
まずは「システム」と「アプリケーション」の2つを見慣れておくといいと思います。セキュリティは監査ログなども含まれるため、目的が明確なときに使うことが多い印象です。
イベントログの種類と役割（システム・アプリケーションなど）
各ログには、それぞれ記録の対象があります。
たとえば「システム」ログでは、ドライバの読み込み失敗や、サービスの起動失敗などが記録されます。ハードウェア寄りの問題はここで見つかることが多いです。
一方「アプリケーション」ログは、SQL ServerやIISなどのアプリケーションからの出力が主です。特定のアプリで障害が出ているなら、こちらのチェックが必要になります。
また、「カスタムビュー」で複数ログをまとめて表示する設定もできますが、慣れるまではデフォルトのログ単位で見る方が混乱は少ないかもしれません。
ログ調査でまず見るべきポイントと順番
エラー調査の基本は「何が起きたか」「いつ起きたか」「その直前に何があったか」の3点を追うことです。
時間をさかのぼりながら、前後の関連を読み取る力が求められます。
ただ、最初から全部を見ようとすると時間がいくらあっても足りません。優先度をつけて、ある程度“型”を決めておくと効率的です。
時系列で見るべきログの流れ
障害が発生した時間が分かっている場合は、その時間を基点に「直前」から「直後」にかけてログを見ていきます。順番としては以下のような流れです。
- 障害発生の時刻を確認
- その時間帯のエラー（赤）や警告（黄）をピックアップ
- それより少し前の情報レベル（青）も併せてチェック
特に「直前に止まったサービス」「失敗したドライバ」などは、後続のエラーに影響していることが多いです。
レベル（情報・警告・エラー）の意味と優先順位
ログには「レベル」があり、視覚的にも色で分かれています。
- 情報（青）：正常に完了した処理の記録。流し読み程度。
- 警告（黄）：将来的なエラー予兆。気になるログは要チェック。
- エラー（赤）：明確な失敗。まずここを中心に調査。
また、「重大」というレベルもありますが、これは主にOSやシステムの致命的な停止を示します。日常運用ではあまり頻繁には出ませんが、出たときは腰を据えて調査することをお勧めします。
参考になるイベントIDのパターン
慣れてくると、「このエラー、またこれか…」というようなイベントIDが見えてきます。たとえば以下のようなIDは比較的よく目にします。
- 1000番台（アプリケーションのクラッシュ）
- 7000～7040番台（サービスの起動失敗）
- 4625（ログオン失敗）／4672（特権ユーザーのログオン）
筆者は「とりあえずID控えてあとでネット検索」という方法で慣れていきました。
ログから原因を読み解く実践ステップ
実際にエラー原因を突き止めるには、単にエラーメッセージを読むだけでは足りません。ログ同士の関係や、時系列の流れを追うことで、ようやく全体像が見えてきます。
慣れないうちは“読めるログ”だけを見てしまいがちですが、見落としがちな部分に本当の原因が潜んでいることもあります。
よくあるトラブルとログのつながり方
たとえば「共有フォルダにアクセスできない」という問い合わせ。
原因がネットワークだと思っていたら、実はサーバー側のサービスが落ちていた、ということもあります。
このようなとき、「サービスが停止したログ」→「直前のドライバエラー」→「さらに前の再起動情報」…という具合にログがつながっていきます。
どこか一点だけで判断せず、“線でつなぐ”感覚が大事です。
「このIDはよく見る」自分なりのチェック観点
個人的に頻出だと感じたのは、以下のようなログです。
- Event ID 7031／7034：サービスが異常終了した
- Event ID 1001：アプリケーションがクラッシュした（障害報告の詳細あり）
- Event ID 6008：予期しないシャットダウン
これらは「何が起きたか」に直結するヒントになります。調査では、まずこれらのログを目印に前後を探ることが多いです。
PowerShellでイベントログを扱う基本操作
GUIのイベントビューアーは便利ですが、大量のログを見るには少し不便です。
そこで便利なのがPowerShell。フィルタリングやCSV出力など、自動化にもつなげやすいです。
基本はGet-WinEventを使うのが推奨されます。Get-EventLogよりも柔軟で、フィルタもかけやすくなっています。
Get-WinEventの使い方とフィルター例
ログを種類・レベル・日付などで絞り込むと、目的の情報が取り出しやすくなります。以下は「システムログ」からエラーを直近100件のみを取得する例です。
Get-WinEvent -LogName System -FilterXPath "*[System[(Level=2)]]" -MaxEvents 100
XPath形式の箇所ですが、「Level=2」でエラー、「Level=3」で警告など、条件を追加できます。日付指定を入れることも可能です。
CSV出力やテキスト化での活用方法
ログをそのまま保存したい、他部署と共有したい…という場面では、CSVやテキスト形式に変換すると便利です。
以下は、エラーと警告だけを対象に、直近50件のログを取得して、Shift-JIS形式でCSVに保存するスクリプトです。
Get-WinEvent -LogName Application `
-FilterXPath "*[System[(Level=2 or Level=3)]]" `
-MaxEvents 50 |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
ConvertTo-Csv -NoTypeInformation |
Out-File -FilePath "D:\Logs\AppLogs.csv" -Encoding Default
このように、必要な項目だけ抽出してCSVにすることで、Excelでの共有や調査がスムーズになります。ファイル出力は意外と現場で重宝される手法です。
まとめ
イベントビューアーはWindowsサーバー運用の心強い味方ですが、
ただ漠然と眺めているだけでは本当の原因にはたどり着けません。ログの種類や優先度を理解し、「いつ・何が・なぜ起きたか」を時系列で読み解く力が重要です。
私自身、繰り返し見るログIDや典型パターンに慣れることで、だんだんと調査の勘所がつかめてきました。まずは本記事をヒントに、ご自身の調査“型”を作ってみてください。
