なぜなぜ分析のやり方｜システム障害の例とテンプレート

なぜなぜ分析とは、起きた問題を出発点にして「なぜ」を繰り返し、直接の原因の奥にある根本原因までさかのぼって、再発を防ぐ対策を決める方法です。 英語では 5 Whys と呼ばれます。IPA（情報処理推進機構）の障害分析手法の資料でも、発生した事象の根本原因を分析する手法として紹介されています。

この記事では、架空の予約サイトで起きたデプロイ後の障害を題材に、原因を「発生原因（なぜ起きたか）」と「流出原因（なぜ見逃したか）」の2系統に分けて掘る手順を示します。ツリーはMermaidのコードで、記入表はMarkdownとタブ区切りで載せているので、そのまま自分のチームの分析に使えます。障害報告書の書式ではなく、原因の掘り方に絞った内容です。

確認環境：Ubuntu 24.04、Python 3.11.15（ツリー・記入表・逆読みの文を同じデータから生成、時間の検算）、@mermaid-js/mermaid-cli 12.0.0（Mermaid 12.1.0）と Chromium（ツリーの描画）。確認日は2026-10-05です。

この記事の結論

• 「5回」という回数で止めるのではなく、仕組み（手順・チェック・設計）を変える対策が出たところで止めます。 今回の例では、発生原因は4段、流出原因は2〜3段で対策に届きました。
• 「注意不足」「確認不足」のような個人の心がけで止めません。 「どの手順に確認項目が無かったか」と言い換えて、もう1段掘ります。
• 原因は発生原因（なぜ起きたか）と流出原因（なぜ見逃したか）の2系統に分けます。片方だけだと、対策が半分になります。
• 各段には根拠となる事実（ログ、手順書、記録）を書きます。事実が無い段は、推測として分けておきます。
• 書き終えたら、下から「だから」でつないで逆に読み、筋が通るかを確かめます。

なぜなぜ分析の早見表

題材：架空の予約サイトで起きたデプロイ後の障害

会議室やスタジオを予約できる架空のサイトを題材にします。

「マイグレーションを適用し忘れた」で終えると、対策は「次回は忘れないように気をつける」になります。ここから、仕組みの原因まで掘っていきます。

手順1：事象を1文で書く

出発点の文は、事実だけで書きます。原因や評価の言葉を入れないのがコツです。

手順2：発生原因と流出原因の2系統に分ける

障害の対応では、発生原因だけを掘って終わることがよくあります。流出原因を別の枝として掘ると、テストや監視の改善点が見つかります。 今回の例でも、対策5件のうち3件は流出原因の枝から出ました。

手順3：なぜを繰り返して記入表を埋める

1段ごとに「原因」と「根拠となる事実」を並べて書きます。1つの原因に答えが2つあるときは、枝を分けます（下の表では、A2からA3とA5に、事象からB1とB4に分かれています）。

タブ区切り（表計算ソフトに貼れます）：

系統  ID  なぜ  原因  根拠となる事実 対策  担当  期限
発生  A1  なぜ1 アプリが、本番のデータベースに無い列 guest_count を読み書きしようとした  エラーログに「column "guest_count" does not exist」が10:00から記録されている  （下の段へ）  ―   ―
発生  A2  なぜ2（A1の続き）  列を追加するマイグレーションが本番に適用されないまま、アプリだけが新しい版に切り替わった    本番のマイグレーション履歴に、該当の番号（0042）が無い   （下の段へ）  ―   ―
発生  A3  なぜ3（A2の続き）  手作業の手順であるマイグレーションが実行されないまま、デプロイが先へ進んだ   手順書の7番が「必要な場合はマイグレーションを実行」。当日の作業記録の7番は空欄    （下の段へ）  ―   ―
発生  A4  なぜ4（A3の続き）  マイグレーションを実行しなくても、デプロイのスクリプトが最後まで進む作りになっている  スクリプトに、マイグレーションの履歴を確認する処理が無い    デプロイの自動処理にマイグレーションの実行を組み込み、適用が終わらなければ切り替えを止める   開発チーム   10月15日
発生  A5  なぜ3（A2の続き）  アプリが、必要な列が無い状態でも起動し、リクエストを受け付けた 起動時の確認はデータベースへの接続だけで、テーブル定義の版は見ていない 起動時にマイグレーションの版を確認し、合わなければ起動を止めて、切り替え前の版で動かし続ける  開発チーム   10月31日
流出  B1  なぜ1 公開前のテストで、このエラーが出なかった    検証環境の自動テスト312件はすべて合格していた    （下の段へ）  ―   ―
流出  B2  なぜ2（B1の続き）  テストを行った検証環境には列が追加済みで、本番とテーブル定義が違ったままだった 検証環境の履歴には、9月17日に0042を適用した記録がある  （下の段へ）  ―   ―
流出  B3  なぜ3（B2の続き）  本番と検証環境のテーブル定義の差を比べる項目が、リリース判定に無い   リリース判定のチェックリスト12項目に、該当する項目が無い   リリース判定の前に、本番と検証環境のマイグレーション履歴を自動で比べ、差があれば判定を止める  開発チーム   10月15日
流出  B4  なぜ1 デプロイの直後に気づけず、利用者からの問い合わせで分かった   デプロイは10:00、最初の問い合わせは10:25   （下の段へ）  ―   ―
流出  B5  なぜ2（B4の続き）  デプロイ後の動作確認が、トップページの表示だけだった  手順書の9番が「トップページが表示されることを確認」  デプロイ後に、検索→予約の確定→取消を通す自動の確認を追加する 開発チーム   10月22日
流出  B6  なぜ2（B4の続き）  サーバーエラーが増えても、通知が出なかった   監視の設定に、HTTP 500番台の割合に対する通知が無い   HTTP 500番台の割合が5分間で1%を超えたら通知する（値は例）  運用チーム   10月10日

1段を書くときの確かめ方

手順4：止めどころを判定する

次の3つにすべて「はい」と答えられたら、その段で止めます。

A3（手作業のマイグレーションが実行されないまま進んだ）で止めると、対策は「手順書に太字で書く」になりがちです。これは3つ目の問いに「はい」と言い切れません。もう1段掘ったA4（実行しなくてもスクリプトが最後まで進む）では、「自動処理に組み込み、終わらなければ切り替えを止める」という、人に頼らない対策が書けます。

逆に、「会社全体の予算が足りないから」のように、自分たちで動かせない範囲まで進んだら、1段戻ります。

ツリーにする（Mermaidのコード）

記入表と同じ内容を、ツリーの図にします。次のコードは、Mermaidに対応したエディタやドキュメントのサービスに貼ると、図として表示されます。

flowchart TD
    X["事象：10月1日 10:00のデプロイ後、予約の確定が42分間エラーになった"]
    subgraph HASSEI["発生原因：なぜ起きたか"]
        A1["なぜ1：アプリが、本番のデータベースに無い列 guest_count を読み書きしようとした"]
        A2["なぜ2：列を追加するマイグレーションが本番に適用されないまま、アプリだけが新しい版に切り替わった"]
        A3["なぜ3：手作業の手順であるマイグレーションが実行されないまま、デプロイが先へ進んだ"]
        A4["なぜ4：マイグレーションを実行しなくても、デプロイのスクリプトが最後まで進む作りになっている"]
        A5["なぜ3：アプリが、必要な列が無い状態でも起動し、リクエストを受け付けた"]
    end
    subgraph RYUSHUTSU["流出原因：なぜ見逃したか"]
        B1["なぜ1：公開前のテストで、このエラーが出なかった"]
        B2["なぜ2：テストを行った検証環境には列が追加済みで、本番とテーブル定義が違ったままだった"]
        B3["なぜ3：本番と検証環境のテーブル定義の差を比べる項目が、リリース判定に無い"]
        B4["なぜ1：デプロイの直後に気づけず、利用者からの問い合わせで分かった"]
        B5["なぜ2：デプロイ後の動作確認が、トップページの表示だけだった"]
        B6["なぜ2：サーバーエラーが増えても、通知が出なかった"]
    end
    X --> A1
    A1 --> A2
    A2 --> A3
    A3 --> A4
    A2 --> A5
    X --> B1
    B1 --> B2
    B2 --> B3
    X --> B4
    B4 --> B5
    B4 --> B6
    A4 --> TA4(["対策：デプロイの自動処理にマイグレーションの実行を組み込み、適用が終わらなければ切り替えを止める"])
    A5 --> TA5(["対策：起動時にマイグレーションの版を確認し、合わなければ起動を止めて、切り替え前の版で動かし続ける"])
    B3 --> TB3(["対策：リリース判定の前に、本番と検証環境のマイグレーション履歴を自動で比べ、差があれば判定を止める"])
    B5 --> TB5(["対策：デプロイ後に、検索→予約の確定→取消を通す自動の確認を追加する"])
    B6 --> TB6(["対策：HTTP 500番台の割合が5分間で1%を超えたら通知する（値は例）"])
    classDef taisaku fill:#fff3c4,stroke:#b8860b,color:#000
    class TA4,TA5,TB3,TB5,TB6 taisaku

ノードの文は、二重引用符で囲んでいます。日本語の文に半角の丸かっこが入ると、引用符なしでは図にならないためです（「確かめて分かったこと」で詳しく書きます）。

手順5：「だから」で下から逆に読む

末端の原因から事象に向かって、「だから」でつないで読みます。声に出して読んで、つながりに飛びや無理があれば、その段を書き直します。

記入表のデータから、Pythonで逆読みの文を組み立てた結果です。

［A4から事象へ］
  マイグレーションを実行しなくても、デプロイのスクリプトが最後まで進む作りになっている。（A4）
  だから、手作業の手順であるマイグレーションが実行されないまま、デプロイが先へ進んだ。（A3）
  だから、列を追加するマイグレーションが本番に適用されないまま、アプリだけが新しい版に切り替わった。（A2）
  だから、アプリが、本番のデータベースに無い列 guest_count を読み書きしようとした。（A1）
  だから、10月1日 10:00のデプロイ後、予約の確定が42分間エラーになった。
［A5から事象へ］
  アプリが、必要な列が無い状態でも起動し、リクエストを受け付けた。（A5）
  だから、列を追加するマイグレーションが本番に適用されないまま、アプリだけが新しい版に切り替わった。（A2）
  だから、アプリが、本番のデータベースに無い列 guest_count を読み書きしようとした。（A1）
  だから、10月1日 10:00のデプロイ後、予約の確定が42分間エラーになった。
［B3から事象へ］
  本番と検証環境のテーブル定義の差を比べる項目が、リリース判定に無い。（B3）
  だから、テストを行った検証環境には列が追加済みで、本番とテーブル定義が違ったままだった。（B2）
  だから、公開前のテストで、このエラーが出なかった。（B1）
  だから、10月1日 10:00のデプロイ後、予約の確定が42分間エラーになった。
［B5から事象へ］
  デプロイ後の動作確認が、トップページの表示だけだった。（B5）
  だから、デプロイの直後に気づけず、利用者からの問い合わせで分かった。（B4）
  だから、10月1日 10:00のデプロイ後、予約の確定が42分間エラーになった。
［B6から事象へ］
  サーバーエラーが増えても、通知が出なかった。（B6）
  だから、デプロイの直後に気づけず、利用者からの問い合わせで分かった。（B4）
  だから、10月1日 10:00のデプロイ後、予約の確定が42分間エラーになった。

逆に読んで引っかかる例と、直し方です。

言い換えたい表現の対照表

次の言葉が出てきたら、そこが止めどころではなく、もう1段掘る合図です。右の問いに言い換えて、仕組みの原因を探します。

IPAの障害分析手法の資料でも、なぜなぜ分析の目的は、障害を発生させた個人を責めることではなく、原因を究明して組織としての再発防止策を検討することだと書かれています。主語を人から仕組みに替えることが、分析の質を決めます。

手順6：対策に担当と期限を付ける

末端の原因ごとに出た対策を、一覧にします。

担当は個人名ではなくチーム名にしていますが、実際には、進み具合を答えられる人を1人決めておくと動きやすくなります。

空欄のテンプレート（タブ区切り）

発生原因と流出原因それぞれに、なぜ1〜なぜ5の行を用意したテンプレートです。5段まで埋める必要はなく、止めどころに着いたら残りの行は消します。枝が分かれたら行を足し、「なぜ」の列に「なぜ3（A2の続き）」のように親のIDを書きます。

系統  ID  なぜ  原因  根拠となる事実 対策  担当  期限
発生  A1  なぜ1                 
発生  A2  なぜ2                 
発生  A3  なぜ3                 
発生  A4  なぜ4                 
発生  A5  なぜ5                 
流出  B1  なぜ1                 
流出  B2  なぜ2                 
流出  B3  なぜ3                 
流出  B4  なぜ4                 
流出  B5  なぜ5

似た手法との違いと選び方

• 特性要因図は、ASQ（American Society for Quality）のページで、品質管理の基本的な7つの道具の1つとされ、Materials・Machinery・Methods・Measurement・Manpower・Mother Nature といった分類の見出しが挙げられています。枝を深くするときに「なぜ」を問い続ける、とも書かれており、なぜなぜ分析と組み合わせて使えます。
• FTAは、IPAの資料で、望ましくない事象の要因を探るトップダウンの手法で、各要因の発生確率から事象の起こる確率を算出するもの、と説明されています。
• ポストモーテムは、Google の SRE本で、インシデントとその影響、緩和や解決のために行った対応、根本原因、再発を防ぐための事後の対応を記した文書、と定義されています。個人やチームを責めずに、要因の特定に集中することも強調されています。

どれを使うかの判断表

確かめて分かったこと

• 5段まで掘らなくても、対策に届きました。 今回の例で対策が出た末端は5件で、発生原因の枝は最大4段、流出原因の枝は最大3段（B5・B6は2段）でした。回数ではなく、止めどころの3つの問いで判定するほうが合っています。
• 逆読みで、下書きのつながらない段が見つかりました。 この記事の下書きでは、A3を「マイグレーションの実行が手作業の別手順になっていた」、A4を「スクリプトが適用状況を確かめない作りになっている」と書いていました。上から読むと自然でしたが、Pythonで「だから」をはさんで下から出力すると「確かめない作りだ。だから、手作業の別手順になっていた」となり、つながりませんでした。A3を「実行されないままデプロイが先へ進んだ」に書き直して、5本の筋すべてが通る形にしています。
• Mermaidのノードの文に半角の丸かっこを入れると、引用符なしでは描画が止まります。 A[なぜ1：確認(手順7)が空欄] は Parse error になり、A["なぜ1：確認(手順7)が空欄"] と二重引用符で囲むと描画できました（mermaid-cli 12.0.0）。全角の丸かっこ（）とかぎかっこ「」は、引用符なしでも描画できました。
• 時間を並べると、流出原因の重みが見えます。 発生から復旧までの42分のうち、検知までが25分、検知から復旧までが17分でした。半分以上が「気づくまで」の時間で、B5（デプロイ後の確認）とB6（通知）の対策がそのまま短縮につながります。
• IPAの資料には、個人を責めないことが目的として明記されています。 一方で、開いた範囲では、発生原因と流出原因の分け方や逆読みの手順についての説明は見当たりませんでした。この2つは、この記事で紹介した進め方として使ってください。

よくある質問

Q. なぜなぜ分析とは何ですか？ A. 起きた問題に「なぜ」を繰り返して、根本原因までさかのぼる分析の方法です。直接の原因を直すだけでなく、同じ問題が再び起きない仕組みを作ることが目的です。

Q. なぜは必ず5回繰り返す必要がありますか？ A. 5回は目安で、必須ではありません。手順・チェック・設計を変える対策が書けた段で止めます。3段で届くこともあれば、6段かかることもあります。

Q. なぜなぜ分析と特性要因図の違いは何ですか？ A. なぜなぜ分析は1つの因果を深く掘り、特性要因図は原因の候補を広く洗い出します。候補が絞れていないときは特性要因図から始め、有力な枝をなぜなぜ分析で掘ると、両方の良さを使えます。

Q. 原因が人のミスにたどり着いたときは、どうすればよいですか？ A. そこで止めずに、ミスが起きても障害にならない仕組みが無かった理由を問います。「確認不足」は「どの手順に確認項目が無かったか」に言い換えると、対策が手順やチェックの変更になります。

Q. なぜなぜ分析がうまく進まないときは？ A. 事象の文と、根拠となる事実に戻ります。事実が無い段は推測なので、ログや記録を調べてから書き直すと、次の「なぜ」が出やすくなります。

まとめ

• 回数ではなく、仕組み（手順・チェック・設計）を変える対策が出たところで止める。
• 発生原因（なぜ起きたか）と流出原因（なぜ見逃したか）の2系統に分けて掘る。
• 各段に根拠となる事実を書く。主語は人ではなく、手順・設定・作りにする。
• 「確認不足」「注意不足」は、「どの手順に確認項目が無かったか」に言い換えて、もう1段掘る。
• 書き終えたら、下から「だから」でつないで逆に読む。
• 対策には担当と期限を付ける。
• 候補を広く挙げたいときは特性要因図、起きる前の検討はFTA、全体の記録はポストモーテムと使い分ける。

参考・出典

• IPA（独立行政法人情報処理推進機構）「別冊Ⅱ：障害分析手法」（2020年3月16日改訂） https://www.ipa.go.jp/archive/files/000071988.pdf
• ASQ「Fishbone Diagram」 https://asq.org/quality-resources/fishbone
• Google「Site Reliability Engineering」Postmortem Culture: Learning from Failure https://sre.google/sre-book/postmortem-culture/

（いずれも2026-10-05に確認）

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。