本記事が扱う事象は、Windowsの不具合調査で「原因が特定できない」という状況が生じた際に、OSが内部で記録しているログをどのように参照し、事実関係を整理するか、という点です。対象となるのは Windows Event Viewer（Windowsイベント ビューアー）であり、修復機能ではなく記録機能として位置づけられます。そのため、画面上のエラー表示が曖昧な場合でも、時刻・発生源・識別番号を軸に、出来事を時系列で追える点が論点になります。
- Windowsイベントビューアーの役割と「記録」に特化した性質
- ログ階層の基本と、見るべき場所が分かれる構造
- Event IDとレベル分類が「曖昧な症状」を分解する
- クラッシュ・再起動・アプリ終了で参照点が変わる
- 起動の遅さとセキュリティ監査での扱い、限界の整理
Windowsイベントビューアーの役割と「記録」に特化した性質
Windowsイベントビューアーは、システム・セキュリティ・アプリの出来事を時系列で記録し、調査用の根拠を残すための標準機能です。
Windowsでは、利用者が見ている画面の裏側で、kernel（カーネル）や各種service（サービス）、driver（ドライバー）、アプリケーションが状態を通知し続けます。ただし、通常利用でそれらを常時確認する必要はなく、表示もされません。そこで記録の受け皿になるのがイベントログであり、イベントビューアーはそれを閲覧・抽出するためのMicrosoft Management Console（Microsoft管理コンソール、MMC）のsnap-in（スナップイン）として提供されています。
一方で、この機能は「問題を自動的に直す」ことを目的にしていません。そうすることによって、調査は「推測」よりも「記録された事実」に寄りやすくなります。ただし、ログは解釈と突合が必要になるため、次に示すログの構造理解が実務上の確認点となります。
ログ階層の基本と、見るべき場所が分かれる構造
ログはWindows logs（Windowsログ）を中心に階層化され、出来事の種類ごとに記録場所が分かれています。
イベントビューアーを開くと、まずWindows logs（Windowsログ）が入口となり、Application（アプリケーション）、Security（セキュリティ）、Setup（セットアップ）、System（システム）、Forwarded Events（転送されたイベント）などに分類されます。この分割は、障害の種類によって「どこに証跡が残るか」が異なるためです。たとえばSystem（システム）はOS構成要素やドライバー関連が中心になり、Application（アプリケーション）は個別ソフトの例外やクラッシュが入りやすくなります。なお、内部データはXML（拡張可能マークアップ言語）形式で保持され、timestamp（タイムスタンプ）、source（ソース）、Event ID（イベントID）などの項目が構造化されます。
そのため、整理の起点は「どの分類のログか」と「発生時刻を一致させるか」になります。そこで、最小限の切り分けを行うために、分類と用途を表にまとめます。
| ログ分類 | 記録されやすい内容 | 使い分け実例（コピペ可） |
|---|---|---|
| System（システム） | 起動・ドライバー・サービス | 「System → 重大 / エラー」 |
| Application（アプリケーション） | アプリのクラッシュ・例外 | 「Application → エラー」 |
| Security（セキュリティ） | ログオン・監査結果 | 「Security → 失敗の監査」 |
| Setup（セットアップ） | 更新・役割追加 | 「Setup → エラー」 |
| Diagnostics-Performance（診断-パフォーマンス） | 起動/終了の遅延要因 | 「イベントID 100〜199」 |
ただし、分類だけでは件数が多くなりがちです。この結果、次の段階として「レベル」と「フィルター」で情報量を絞り込む論点が出てきます。
Event IDとレベル分類が「曖昧な症状」を分解する
Event ID（イベントID）とレベル（重大・エラー・警告など）を軸にすると、症状の説明が「どの失敗点か」に分割されます。
Windowsの表示上は「問題が発生しました」といった一般化された文言で終わるケースがあります。言い換えると、画面の情報は「結果の報告」に偏り、原因の位置が残りにくい構造です。そこでイベントビューアーでは、各記録にEvent ID（イベントID）が付与され、同じ種類の出来事は同じIDで繰り返し現れます。以上を踏まえると、調査の単位は「現象」ではなく「IDと時刻の組み合わせ」になります。
さらに、レベルはInformation（情報）/ Warning（警告）/ Error（エラー）/ Critical（重大）などで付けられ、通常動作の記録と障害の兆候を分けます。なお、Custom Views（カスタムビュー）で条件を保存できるため、同様の事象が再発した際に同じ絞り込みを再利用できます（ここで「さら に」手作業の差が出ます）。
そのため、絞り込みの設計を簡略化するために、レベルと読み取りの方向性を表に整理します。
| レベル | 意味合い | 絞り込み実例（コピペ可） |
|---|---|---|
| Critical（重大） | 強制終了・重大な停止 | 「レベル=重大」 |
| Error（エラー） | 処理失敗・クラッシュ | 「レベル=エラー」 |
| Warning（警告） | 遅延・再試行・不安定兆候 | 「レベル=警告」 |
| Information（情報） | 通常動作の通知 | 「除外：情報」 |
他方、ここまでの整理は「ログから何が読み取れるか」を示すにとどまります。次に、具体的に参照されやすい場面を、時系列の整合という観点で整理します。
クラッシュ・再起動・アプリ終了で参照点が変わる
再起動やブルースクリーン（Blue Screen of Death、BSOD）後は、落ちた瞬間の時刻に一致するSystem（システム）側の重大イベントが中心になります。
突然の再起動や停止では、画面に詳細が残らないことがあります。これは、表示を担う構成要素自体が停止し、説明のためのUIが成立しないためです。ただし、OSが停止直前にSystem（システム）へ記録を残せる場合があり、タイムスタンプを基準に周辺のイベントを追うことで、driver（ドライバー）更新や特定デバイスの失敗が並んでいないかを確認できます。
一方で、特定アプリが「無言で終了する」場合は、Application（アプリケーション）側に記録が寄ります。ここではfaulting module（障害モジュール）やDLL（動的リンクライブラリ）名が残ることがあり、同じモジュール名が複数回出るかどうかが、単発の例外か継続的な競合かを分ける判断材料となります。
つまり、同じ「落ちた」という結果でも、OS停止とアプリ停止では記録の場所と粒度が異なります。この点から、次は「遅い」という現象に対して、どのログが使われるかを整理します。
起動の遅さとセキュリティ監査での扱い、限界の整理
Diagnostics-Performance（診断-パフォーマンス）とSecurity（セキュリティ）は、体感ではなく計測記録として遅延要因や監査結果を残します。
起動や終了が長い場合、Diagnostics-Performance（診断-パフォーマンス）に、起動所要時間や遅延の原因になったprocess（プロセス）やdriver（ドライバー）が記録されます。そうすることによって、「どれが遅いか」を秒単位の計測として追えるため、現象の再現が難しい場面でも説明がしやすくなります。ただし、遅延要因が必ず単独で示されるとは限らず、複数の小さな遅れが積み上がるケースもあります。
他方、Security（セキュリティ）はSuccess Audit（成功の監査）/ Failure Audit（失敗の監査）としてログオン試行やアクセス試行を残します。疑わしい操作があったかどうかは、時刻・アカウント・結果で整理されるため、出来事の列挙として利用されます。なお、監査ポリシー設定によって記録範囲が変わるため、記載が不足しているように見える場合は「記録されていない」のか「記録対象外」なのかの切り分けが必要となります。
以上を踏まえると、イベントビューアーは万能な原因特定装置ではなく、事実の断片を時系列で束ねるための基盤です。そのため、次の調査手段（更新履歴、ドライバー状態、アプリ側ログなど）へ接続する前提として位置づけることが整理の要点になります。
