根本原因と対症療法の違いとは？IT業務初心者向けに障害対応の考え方を解説

結論から言うと、対症療法は「今出ている症状を一時的に解消する対応」、根本原因への対応は「なぜその問題が起きたのかを突き止め、原因そのものを取り除く対応」です。

IT現場では、障害が発生したときにまず業務を復旧させる必要があります。そのため、再起動やサービス再起動、設定の一時変更などで症状を止めることがあります。

ただし、そこで対応を終えると同じ障害が再発する可能性があります。

そのため、社内SE、ヘルプデスク、運用保守、インフラエンジニアなどのIT業務では、「今すぐ直すための対応」と「同じ問題を繰り返さないための対応」を分けて考えることが重要です。

根本原因とは

根本原因とは、障害や不具合を発生させた本質的な原因です。

英語ではRoot Causeと呼ばれます。

たとえば、サーバーのディスク容量が不足して業務システムが停止したとします。

この場合、「ディスク容量が不足した」という事実だけでは、根本原因まで到達していない可能性があります。

さらに調べてみると、次のような流れが見つかるかもしれません。

1. 業務システムが停止した
2. ディスクの空き容量がなくなっていた
3. ログファイルが大量に作成されていた
4. 古いログを削除する設定がされていなかった
5. 容量監視も設定されていなかった

このケースでは、単純な「容量不足」だけではなく、ログ管理や監視の仕組みが不十分だったことまで掘り下げて考える必要があります。

対症療法とは

対症療法とは、根本原因を取り除くのではなく、現在発生している症状を一時的に改善する対応です。

IT現場では「暫定対応」「一次対応」「ワークアラウンド」といった言葉で表現されることもあります。

たとえばディスク容量不足なら、不要なログを削除して空き容量を確保する対応が考えられます。

これによってシステムが動くようになれば、業務は復旧できます。

しかし、ログが増え続ける仕組みが変わっていなければ、数週間後に同じ容量不足が発生する可能性があります。

症状が消えたことと、原因がなくなったことは同じではありません。

根本原因と対症療法の違い

項目	対症療法	根本原因への対応
目的	早く症状を止める	同じ問題を起こさない
対応時期	障害発生直後	復旧後の原因調査後
例	再起動、ログ削除、一時設定変更	設定修正、監視追加、設計改善
再発可能性	残ることがある	低減を目指す
重要な視点	どうすれば今使えるか	なぜ発生したのか

対症療法が悪いわけではありません。

業務システムが停止している場合は、原因調査より先にサービス復旧を優先することもあります。

重要なのは、対症療法を行ったあとに「直ったので終了」としないことです。

具体例：PCを再起動したら直った場合

IT業務で非常によくあるのが、「PCを再起動したら直りました」というケースです。

再起動自体は有効な対処方法です。

しかし、再起動で直ったというだけでは原因は分かりません。

内容	状態
症状	アプリケーションが起動しない
対症療法	Windowsを再起動
結果	アプリが起動した
根本原因	まだ不明

実際には、Windowsサービスが異常だった、メモリ不足だった、更新処理が残っていた、アプリケーションのプロセスが異常終了していたなど、別の原因が考えられます。

「再起動で直った」は対処結果であり、原因ではありません。

具体例：共有フォルダにアクセスできない場合

共有フォルダへアクセスできないため、ユーザーへ強い権限を付与したらアクセスできるようになったとします。

一見すると解決したように見えます。

しかし、本来必要のない権限まで付与してしまった場合は、セキュリティ上の問題が発生します。

本来確認すべき原因には次のようなものがあります。

• Active Directoryの所属グループが間違っている
• 共有アクセス許可に問題がある
• NTFSアクセス許可に問題がある
• 親フォルダからの継承に問題がある
• 別のユーザー資格情報を利用している

「権限を広げれば動く」は原因切り分けの材料にはなりますが、そのまま恒久対策にしてはいけない場合があります。

具体例：DNSの問題

サーバー名で接続できないため、IPアドレスを直接入力したところ接続できたとします。

この場合、IPアドレスを直接使うことは一時的な回避策になるかもしれません。

しかし、本来はDNS（Domain Name System）の名前解決に問題がないか確認する必要があります。

考えられる原因には次のようなものがあります。

• DNSサーバー設定が間違っている
• DNSレコードが存在しない
• 古いDNSキャッシュが残っている
• 端末が誤ったDNSサーバーを参照している
• DNSサーバー自体に障害が発生している

IPアドレス直接指定だけで運用を続けると、サーバーのIPアドレス変更時などに別の問題が発生する可能性があります。

具体例：ディスク容量不足

サーバーの空き容量がなくなり、サービスが停止したケースを考えます。

すぐに不要ファイルを削除すれば復旧できます。

これは重要な対症療法です。

ただし、そこで終わらず次の内容を確認します。

• 何のファイルが容量を使用していたか
• いつから増え始めたか
• ログ保存期間は適切か
• ログローテーションが設定されているか
• 容量監視は行われているか
• 警告通知のしきい値は適切か

根本原因がログ管理不足なら、ログローテーションや監視設定を追加することが恒久対応になります。

対症療法が必要な場面もある

「根本原因が重要なら、対症療法はしないほうがよい」と考える必要はありません。

実際のIT現場では、業務復旧を優先して対症療法を先に行うことがあります。

たとえば全社員が業務システムを利用できない状態なら、数時間かけて根本原因を追うより、まず安全な暫定対応でサービスを復旧させるほうが適切な場合があります。

基本的には次の流れで対応します。

1. 影響範囲を確認する
2. 重大度を判断する
3. 安全な暫定対応で復旧する
4. 復旧後もログや情報を保全する
5. 原因究明を続ける
6. 根本原因を特定する
7. 恒久対応と再発防止を行う

対症療法と根本対応は「どちらか一方」ではなく、役割が違うと覚えておきましょう。

原因を掘り下げる「なぜ？」の考え方

根本原因を探すときは、「なぜ？」を繰り返すと考えやすくなります。

たとえばユーザーが業務システムへログインできなかったとします。

1. なぜログインできなかった？ → アカウントがロックされていた
2. なぜロックされた？ → パスワード失敗が繰り返されていた
3. なぜ失敗が繰り返された？ → 古いパスワードを保存した端末があった
4. なぜ古い情報が残っていた？ → パスワード変更後の確認手順が不足していた

アカウントロックを解除するだけなら対症療法です。

古い資格情報が残る端末や運用手順まで見直せれば、再発防止につながります。

直接原因と根本原因も区別する

障害対応では、「対症療法」と「根本原因」に加えて直接原因も区別すると整理しやすくなります。

項目	例
現象	業務システムが停止した
直接原因	ディスク容量がなくなった
根本原因	ログ管理・監視の仕組みが不十分だった
対症療法	不要ログを削除した
恒久対応	ログローテーションと容量監視を設定した

このように整理すると、「何が起きたか」「なぜ起きたか」「今何をしたか」「今後何を変えるか」を分けて考えられます。

原因を人だけに求めない

再発防止でありがちな失敗が、「担当者の確認不足が原因だった」として終わることです。

人のミスが直接的なきっかけだったとしても、さらに考える必要があります。

• なぜ間違えやすい手順だったのか
• チェック機能はなかったのか
• レビューは必要なかったのか
• 自動化できなかったのか
• 誤操作しても簡単に事故にならない仕組みにできなかったか

「次から気を付ける」だけでは、同じ人でも別の人でも再びミスする可能性があります。

可能な範囲でチェックリスト、レビュー、自動化、権限制御など仕組みに置き換えることが大切です。

障害時は影響範囲を確認する

原因調査を始めるときは、まず影響範囲を確認します。

• 1ユーザーだけか
• 複数ユーザーで発生しているか
• 1台のWindows PCだけか
• 特定部署だけか
• 全社で発生しているか
• 特定サーバーだけか
• 複数システムに影響しているか

1人だけならユーザー固有の権限や端末を疑えます。

全社で同時発生しているなら、サーバー、ネットワーク、DNS、Active Directoryなど共通基盤を優先して確認します。

原因を切り分ける順番

初心者は、いきなり設定を変更するのではなく、次の順番で確認すると整理しやすくなります。

1. 発生している現象を正確に確認する
2. 影響範囲を確認する
3. エラーメッセージを記録する
4. 正常な端末やユーザーと比較する
5. ユーザー・権限を確認する
6. Windows側を確認する
7. ネットワークを確認する
8. DNSやDHCPを確認する
9. Active Directoryを確認する
10. サーバー側の状態を確認する
11. ログから原因候補を絞る

確認してから変更することが重要です。

GUIで状態を確認する

Windows 11では、GUI（Graphical User Interface）から基本的な状態を確認できます。

ネットワークなら「設定」から「ネットワークとインターネット」を確認します。

Ctrl + Shift + Escでタスクマネージャーを起動すると、CPU、メモリ、ディスク、ネットワークなどの利用状況を確認できます。

Windowsキー + Eでエクスプローラーを開けば、ディスク容量やファイルの存在も確認できます。

コマンドプロンプトで確認する

CUI（Character User Interface）を使った確認も原因切り分けに役立ちます。

ネットワーク関連では「ipconfig /all」でIPアドレス、DNSサーバー、DHCPなどを確認できます。

「ping 接続先」では基本的な通信確認が可能です。

「nslookup ホスト名」では、DNSによる名前解決を確認できます。

ただし、pingが成功しただけでネットワーク全体が正常とは判断できません。対象サービス、ポート、認証、権限などは別途確認が必要です。

PowerShellで確認する

Windows環境ではPowerShellも利用できます。

「Get-NetIPConfiguration」ではネットワーク構成、「Get-Service」ではサービス状態、「Get-Volume」ではディスク情報を確認できます。

障害対応では、設定変更を行う前に現在の状態を記録することが重要です。

原因が分からない段階で変更系コマンドを次々と実行すると、元の障害原因が分からなくなることがあります。

イベントビューアーでログを確認する

Windowsではイベントビューアーも重要な調査手段です。

Windowsキー + Rを押して「eventvwr.msc」と入力すると起動できます。

代表的な確認先は「Windowsログ」の「システム」と「アプリケーション」です。

• 障害発生日時
• イベントID
• ソース
• エラーや警告の内容
• 障害直前のログ
• 同じエラーの発生頻度

赤いエラーを見つけても、それだけで根本原因と決めつけてはいけません。

障害時刻や再現条件と一致しているかを確認しましょう。

対症療法で終わっているサイン

次のような状態なら、根本原因まで調査できていない可能性があります。

• 再起動すると毎回直る
• 同じ問い合わせが何度も来る
• 毎月同じファイルを手作業で削除している
• アカウントロックを毎回解除している
• サービス停止のたびに手動で起動している
• 「原因不明だが今は使える」で終了している

こうした対応が繰り返されているなら、「なぜ毎回その作業が必要なのか」を考えてみましょう。

現場でよくある間違い

初心者がやりがちなミスには次のようなものがあります。

• 症状が消えたので原因も解決したと思う
• 再起動で直ったことを原因として報告する
• 最初に見つけたエラーを根本原因と決めつける
• 権限を広げて動けば完了とする
• ファイアウォールを無効化して使えるから解決と判断する
• 原因調査前に複数の設定を変更する
• 同じ障害が再発しても同じ暫定対応だけを繰り返す
• 再発防止策を考えない

一時的にセキュリティ設定を変更するときの注意

原因切り分けのためにファイアウォールやアクセス権限などを変更すると、症状が変化することがあります。

しかし、セキュリティ機能を無効化して動いたからといって、その状態を恒久対応にしてはいけません。

本番環境でセキュリティ設定を変更する場合は、影響範囲、承認、変更前の状態、ロールバック方法を必ず確認します。

対症療法から根本対応へ進む考え方

暫定対応で復旧したら、次の質問をします。

1. なぜこの症状が発生したのか
2. 今回の対応でなぜ直ったのか
3. 原因そのものは残っていないか
4. 同じ条件になれば再発しないか
5. 他の端末やサーバーにも同じ問題がないか
6. 監視や仕組みで事前に防げないか

この確認を習慣にすると、単なる障害復旧から一歩進んだ対応ができるようになります。

筆者が新人時代に勘違いしやすかったポイント

新人のころは、ユーザーから「直りました」と言われると安心して、そのまま対応を終了したくなることがありました。

特に再起動やサービス再起動で復旧すると、「これで解決した」と考えがちです。

しかし同じ問い合わせが再発すると、前回は症状だけ消して原因を残していたことに気付きます。

それ以降は、復旧後に「今回やったのは暫定対応なのか、根本対応なのか」を整理するようにしています。

この区別ができるだけでも、障害対応の記録や上司への報告が分かりやすくなります。

上司へ報告するときのポイント

障害報告では、対症療法と根本原因を分けて伝えることが重要です。

• 発生していた現象
• 影響範囲
• 実施した暫定対応
• 現在復旧しているか
• 確認できた直接原因
• 根本原因が特定できているか
• 恒久対応の予定
• 再発防止策
• 残っているリスク

たとえば、「ログ削除により復旧済み。ただし根本原因はログ肥大化であり、ログローテーション設定を追加予定」と整理すると状況が伝わりやすくなります。

エスカレーションするタイミング

暫定対応では復旧できても、根本原因を特定できない場合があります。

次のようなケースでは、上位担当者や専門担当者へのエスカレーションを検討します。

• 同じ障害が繰り返し発生している
• 原因候補を絞り込めない
• 本番サーバーの設定変更が必要
• Active DirectoryやDNSに関係する
• ネットワーク構成変更が必要
• セキュリティに関係する
• データ破損の可能性がある

「復旧済みだが根本原因は未特定」という状態も正確に報告しましょう。

現場で評価される障害対応

現場で評価されるのは、単に障害を早く直せる人だけではありません。

次の流れまで考えられることが重要です。

1. 影響範囲を確認する
2. 必要なら対症療法で早期復旧する
3. ログや情報を残す
4. 直接原因を特定する
5. 根本原因まで掘り下げる
6. 恒久対応を実施する
7. 再発防止策を考える
8. 手順書やナレッジへ残す

「直せる人」から「同じ障害を減らせる人」へ進むことが、IT業務では大切です。

関連して覚えておきたいIT用語

用語	意味
根本原因	障害を発生させた本質的な原因
直接原因	障害を直接引き起こした原因
対症療法	現在の症状を一時的に改善する対応
暫定対応	業務を早く復旧するための一時的な対応
恒久対応	原因そのものを改善する対応
再発防止	同じ障害を再び起こさないための対策
切り分け	確認を重ねて原因となる範囲を絞ること
ロールバック	変更前の状態へ戻すこと

根本原因と対症療法に関するよくある質問（FAQ）

Q. 対症療法は悪い対応ですか？

いいえ。業務停止中などは、早く復旧させるために必要です。ただし、対症療法だけで対応を終了すると再発する可能性があります。

Q. 再起動で直った場合の根本原因は何ですか？

再起動しただけでは根本原因は分かりません。サービス状態、ログ、メモリ、ネットワーク、Windows Updateなどを調査して原因を絞ります。

Q. 直接原因と根本原因は同じですか？

異なる場合があります。たとえば直接原因がディスク容量不足でも、根本原因はログ管理や監視設計の不足かもしれません。

Q. いつ根本原因を調査すればよいですか？

重大障害ではまず安全な復旧を優先し、その後に原因調査を続ける方法が一般的です。現場の障害対応ルールや影響度に応じて判断します。

Q. 根本原因が分からない場合はどうすればよいですか？

原因不明のまま断定せず、確認した内容、取得したログ、未確認事項を記録します。必要に応じて上位担当者へエスカレーションします。

Q. 新人が最初に覚えるべきポイントは何ですか？

「直った理由」と「発生した理由は別」と覚えておくことです。再起動や設定変更で復旧しても、「そもそもなぜ異常状態になったのか」を考えましょう。

まとめ

対症療法は今発生している症状を一時的に解消する対応で、根本原因への対応は問題が起きた本当の理由を取り除く対応です。

IT現場では、業務を早く復旧するために対症療法が必要になることがあります。

しかし、そこで「解決済み」としてしまうと、同じ障害が再発する可能性があります。

障害対応では、「現象→対症療法による復旧→直接原因→根本原因→恒久対応→再発防止」という流れで考えることが重要です。

新人のうちは、問題が直ったときに「これは症状を消しただけ？それとも原因そのものを直した？」と自分に問いかけてみてください。

この違いを意識できるようになると、その場しのぎの対応を減らし、同じ障害を繰り返さないエンジニアへ近づけます。