5 Whys（なぜなぜ分析）

Summary

安全・品質・信頼性（Safety, Quality & Reliability）カテゴリにおける 5 Whys は、現象を「再発防止できる原因」まで掘り下げ、対策に結び付けるための基本技法です。

一言で言うと「“原因を“物語”ではなく“因果”として扱うための、反復質問フレーム”」。

いつ使うか： 不具合・クレーム・CVR低下・ヒューマンエラーなど、「まず最短で真因と暫定対策の筋道を揃えたい」ときに使います。

秀逸ポイント

5 Whys の強みは、原因追究を「納得感のある説明」ではなく、反証可能な因果の鎖に変える点です。トヨタ生産方式（TPS）の問題解決では、現場で起きた現象を起点に、なぜを繰り返して「次に同じことが起きない条件（仕組み）」へ落とす発想が重視されます。
また、“5回”は回数ノルマではなく深掘りの目安で、問題の複雑度に応じて増減します（重要なのは「深さ」より「検証」と「対策への接続」）。
マーケ実務に刺さるのは、会議が「犯人探し」や「施策案の乱発」になりがちな局面で、5 Whys が 論点を“原因→再発防止策”へ強制的に整流してくれる点です。さらに生成AIを使う場合、Whysの各段に「証拠（ログ・計測・顧客声）」を紐付けることで、AIの“もっともらしい推測”を抑え、分析の品質を上げられます。

提唱者・発表時期

5 Whys は、TPSの問題解決訓練の主要要素として広く知られ、TPSの体系化に大きく関わった 大野耐一（Taiichi Ohno） が「問題が起きたら“なぜ”を5回」等の趣旨で述べたことがしばしば引用されます。
一方で、起源については整理の仕方に幅があり、「トヨタ創業者の豊田佐吉の時代（1930年代）に遡る」と紹介する実務記事もあります（ただし一次史料ベースでの確定は難しく、諸説として扱うのが安全です）。
また、5 Whys はリーン／カイゼン／シックスシグマ等の文脈へ広がり、製造以外（ソフトウェアのポストモーテム等）でも定着しました。

詳細説明

1) 5 Whysとは何か（最小定義）

5 Whys は、ある問題（現象）に対して「なぜ？」を反復し、**原因—結果の連鎖（causal chain）**を明示して、最後に「再発防止につながる原因（真因）」と「打ち手」を結び付ける技法です。

2) 進め方（テンプレート化すると失敗しにくい）

• Step0：現象を定義する（いつ／どこで／何が／どのくらい。数値と事実で）

• Step1：Why #1（現象の“直前要因”を、推測でなく証拠で）

• Step2：Why #2〜#4（仕組み・設計・運用・前提条件へ遡る。都度「根拠」を付ける）

• Step3：Why #5（または十分な深さ）：対策可能で、再発防止に効く原因か？

• Step4：対策（暫定／恒久）と検証：再発しないことをどう確認するか（KPI・監視・監査）

5 Whys が「やりっぱなし」になりやすいのは、Whyの列が埋まった時点で満足してしまい、対策と検証設計が弱いケースです（“原因の特定”と“再発防止”は別工程）。

3) 関連用語との違い（比較表）

結論： 複合要因が疑われるなら、最初から5 Whysで一本化せず、（簡易）原因ツリー／特性要因図／FTAで分岐を描いてから、枝ごとに5 Whys が堅いです。

4) ヒューマンエラーを「人のせい」にしない

“ヒューマンエラー”は便利なラベルですが、原因を止める言葉にもなります。実務で有効なのは、

• その行動が起きた条件（手順・UI・負荷・権限・教育・監督・例外運用）

• その条件を許した仕組み（設計・運用・監査・計測）
  まで降りることです。
  国内では、なぜなぜ分析をうまく進めるためのルール群として 「なぜなぜ分析10則」 のような整理があり、ヒューマンエラー多発への対応として表現を改訂した、といった説明も見られます（流派は複数あり得る点に注意）。

5) 「10則」「12か条」は“万能ルール”ではなく運用知

• 10則：小倉仁志氏が、なぜを適切に展開し対策へ導くためのルールとしてまとめた、とされています。

• 12か条（12カ条）：研修・コンサル各社が「独自に発展・改良したメソッド」として提示している例があり、一般名詞というより“提供メソッド”に近い扱いです。

ここで押さえるべきは、数字（10/12）よりも中身で、要点は概ね共通して 「現象定義→証拠→因果→対策→検証」 を崩さないことです。

6) AIマーケティングにさりげなく接続すると

生成AIや予測モデルを使う現場ほど、根本原因が「施策」ではなく データ・計測・運用の“見えない断絶” に潜みます。5 Whys を、

• CVR低下 → 計測タグ → 同意管理 → 参照元欠損 → 学習データ分布
  のように「データの因果」に適用すると、AI活用の“当たり外れ”を仕組み側で安定化できます（AIに原因を語らせるのではなく、AIは証拠探索の補助に置く）。

VEの“機能定義（動詞＋名詞）”を5 Whysに転用する

VEの機能定義が、5 Whysの精度を上げる理由

5 Whys は簡便な反面、途中の“Whyの答え”が あいまい語（注意不足／運用が悪い／設計ミス） になった瞬間に、因果が崩れて精神論に流れやすい欠点があります。そこで有効なのが、VE（価値工学／価値分析）で重視される 「機能を動詞＋名詞で言い切る」 という作法です。VEでは、機能を「何か（What it is）」ではなく「何をするか（What it does）」として捉え、動詞は“何をする？”、名詞は“何に対して？” を答える形で表現します。

これを5 Whysに持ち込むと、各段の答えが次のように改善します。

• あいまい（悪い例）：担当者の確認不足

• 機能言語（良い例）：チェック工程が「検出エラー」を実行できていない（＝Detect error が欠けている）

• 効果：原因が“人”ではなく“条件・仕組み”に落ち、対策が「教育します」ではなく「検出機能を実装する（監視／テスト／承認ゲート）」に接続しやすくなります。

5 Whys × VE：書き方テンプレ（おすすめ）

Whyの答えは原則「動詞＋名詞（できれば測定可能）」で書くと、チーム合意が速くなります。

テンプレ

• 事象（現象）：何が起きたか（数値・事実）

• Why #n（答え）：[動詞] [名詞]（例：Increase latency／Lose consent flag／Block submission）

• 根拠：ログ／計測／観察／再現条件

• つながり：それが起きると、なぜ上位事象が起きるのか（因果の説明）

※VEの世界では、機能定義や機能分析は価値向上の中核として扱われ、標準でも「動詞＋名詞」形式が繰り返し強調されます。

5 Whys × VE：機能言語（動詞＋名詞）で“作文”を止め、FASTで“分岐”を残す

5 Whysは、素早く原因と対策の筋道を揃えられる一方で、途中の答えが「あいまい語（確認不足／運用が悪い／意識が低い）」になった瞬間に、因果が崩れて精神論に流れがちです。さらに複合要因の問題を、議論の都合で一本の因果鎖に潰してしまう（＝分岐を消す）失敗も起きやすいです。
この2つを同時に抑えるのに相性が良いのが、VE（Value Engineering/Value Analysis）の「機能を動詞で語る」作法と、FAST（How/Why/When）による“機能のつながり”の可視化です。

1) VEのコツ：Whyの答えを「動詞＋名詞」に矯正する

VEでは機能を「何であるか」ではなく「何をするか」として捉え、**動詞＋名詞（できれば測定可能）**で表現します。この作法を5 Whysの各段に適用すると、原因が“人”ではなく“条件・仕組み”に落ち、対策が「注意する」ではなく「検出／防止／標準化する」に接続しやすくなります。

• 悪い例：担当者の確認不足

• 良い例：チェック工程が 「エラーを検出する（Detect error）」 を実行できていない

• 良い例：リリース工程が 「危険変更を遮断する（Prevent unsafe release）」 を持っていない

ポイントは、動詞が“行為”を、名詞が“対象”を固定するので、議論が「印象」ではなく「検証」へ寄ることです。

2) すぐ使えるテンプレ：5 Whysを“機能＋根拠”で書く

Whyを埋めるときは、列を増やしてでも「根拠」と「因果のつながり」を明示します。

• 現象（事実）：いつ／どこで／何が／どの程度（数値・ログ・観察）

• Why #n（答え）：［動詞］［名詞］（例：Increase latency / Lose consent flag / Block submission）

• 根拠：ログ、計測、再現条件、顧客の声、画面録画など

• 因果のつながり：それが起きると なぜ上位現象が起きるのか（一文で）

これだけで「結論ありきの作文」や「人のせいで終了」をかなり防げます。

3) しかし分岐は残らない：そこでFAST（How/Why/When）を“前処理”にする

5 Whysのもう一つの落とし穴は、複合要因を一本化してしまう点です。ここを補うのがFASTです。FASTは、機能同士を Why（何のために）／How（どうやって） で横につなぎ、さらに When（その機能を行うとき同時に必要な条件機能） を縦にぶら下げて、目的‐手段‐条件を分けて整理します。

FAST→5 Whysの最短手順（10〜15分で十分）

1. 主経路（How/Why） を横に描く：目的 → 手段の連鎖
   例：Increase conversion ← Complete purchase ← Capture payment

2. 各ノードに When（条件機能） を縦に足す：同時に満たすべき要件
   例：Ensure consent／Prevent fraud／Reduce latency／Maintain data integrity

3. 「壊れている場所」を特定する：主経路か？条件機能か？（分岐のまま残す）

4. 該当ノードにだけ5 Whys を当てる：全体を一気に掘らない（一本化しない）

こうすると、たとえば「CVR低下」を広告訴求の問題に短絡せず、Ensure consent（同意分岐）、Maintain data integrity（計測・スキーマ・データ品質）といった“見えない条件機能”の破綻を早期に疑えます。AIマーケ／計測領域で起きる不具合は、まさにこの条件機能側に潜みやすいので、再発防止の精度が上がります。

4) やること／やらないこと（実務の勘所）

やること

• Whyの答えは必ず「動詞＋名詞」にする（曖昧語を禁止ワード化）

• 各段に根拠（ログ・計測・再現条件）を添える

• 複合要因が疑われるなら、まずFASTで主経路と条件機能に分け、分岐を残す

• 対策は「暫定」と「恒久」に分け、最後に“検証方法（監視・テスト・ゲート）”まで書く

やらないこと

• 「注意不足」「教育不足」で止める（再発防止が仕組み化されない）

• FASTを“それっぽい英語の羅列”にする（測れない機能は役に立たない）

• 分岐があるのに、5 Whysだけで一本化して結論を急ぐ（打ち手が外れる）

マーケ／AI運用での「機能言語」適用例

例：CVR低下（5 Whys）を“機能言語”で締める

• 現象：LPのCVRが先週比 -25%

• Why #1：Increase drop-off（フォーム到達後の離脱が増えた）

• Why #2：Increase latency（モバイルで入力が重い）

• Why #3：Execute script twice（同意分岐とA/Bスクリプトが競合し二重実行）

• Why #4：Miss regression test（同意ON/OFF×主要ブラウザの回帰テストが未整備）

• Why #5：Lack release gate（計測・同意・A/B周りの変更を止めるゲートと監視がない）

ここでのポイントは、途中の答えを「担当の確認不足」ではなく、“欠けている機能”（例：Detect script duplication／Prevent unsafe release）として表現することです。すると対策が、教育ではなく 監視（RUM）・回帰テスト・リリースゲート に自然に落ちます。

AIマーケの落とし穴に効く：機能言語で“データ不具合”を特定する

生成AIやスコアリングの品質劣化は「モデルが悪い」で片付けがちですが、実態は データ連携・同意管理・スキーマ変更 など運用要因が多いです。
5 Whys の各段を機能言語にすると、

• Lose feature signal（特徴量信号が欠損）

• Change schema id（同名フィールドが別IDに置換）

• Lack change control（スキーマ変更管理がない）
  のように、原因が“仕組みの欠落”として可視化され、恒久対策（監視・契約・レビューゲート）に結びつきます。

具体例／活用案

例1：TPSの文脈での典型（設備停止の掘り下げ）

大野耐一の例として紹介される「機械が止まる」ケースのように、現象→直前原因→保全・交換・標準化へ遡って、**“次に止まらない仕組み”**へ接続します。重要なのは、最後を「注意します」「気を付けます」で終わらせず、交換点検のルール・部品箱・監視などに落とす点です。

例2：ソフトウェア／運用ポストモーテム（“防御の層”を厚くする）

リーンスタートアップ文脈では、障害が出たときに「なぜテストが捕まえなかったか」「なぜ監視が検知しなかったか」といった防御層（テスト・監視・運用手順）の改善へ5 Whys をつなげ、再発を“仕組み”で潰す実践が語られています。

例3：マーケ施策の失速（CVR低下）— なぜなぜ分析テンプレート例

• 現象：LPのCVRが先週比 -25%（広告流入は同等）

1. Why：フォーム到達後の離脱が増えた

2. Why：モバイルで入力が重い（エラー増）

3. Why：タグ追加でページが遅延、特定ブラウザでバリデーションが暴発

4. Why：A/Bテスト用スクリプトが同意管理の分岐と競合し、二重実行

5. Why：リリース前に“同意ON/OFF×主要ブラウザ”の回帰テストが標準化されていない

• 対策：スクリプト実行条件の統一、回帰テスト観点の標準化、監視（RUM）追加、リリースゲート設定

• 誤用注意：「運用が悪い」「担当が確認不足」で止めると再発します。最後は標準・テスト・監視に落としてください。

例4：AIスコアリング精度の劣化（“モデルのせい”にしない）

• 現象：リードスコアの高スコア群の商談化率が低下

• Why展開の例：

  • Why：高スコアでも“温度感の低い”リードが混入

  • Why：入力特徴量の一部（イベント参加）が欠損

  • Why：MA側の項目定義が変更され、同名フィールドが別IDになった

  • Why：データ契約（スキーマ変更管理）と監視がない

  • Why：変更を検知しアラートする仕組み（データ品質SLO）が未整備

• 対策：特徴量ごとの欠損監視、スキーマ変更のレビューゲート、学習データ分布ドリフトの定点観測
  AI活用ほど、真因は「モデル」より データ・運用・ガバナンスにある、が定番パターンです。

5 Whysで「やること／やらないこと」（実務ノウハウ）

やること

• 現象を数値・事実で固定し、Whyごとに根拠を付ける（ログ、現場確認、顧客声）

• “人”ではなく“条件と仕組み”に遡る（ヒューマンエラーを終点にしない）

• 複合要因が疑わしければ分岐を描く（原因ツリー／FTA等）

やらないこと

• 最初から結論ありきでWhyを“作文”する（会議映えするが再発する）

• 「教育不足」「注意不足」で止める（対策が精神論になりがち）

• 重大事故・安全案件を、5 Whys単独で済ませる（FTA等の併用を検討）

すぐ使える問い（Killer Question）

1. この“最後のWhy”は、仕組み（標準・設計・監視）を変えれば再発が止まる原因か？――止まらないなら「原因」ではなく“説明”で終わっています。

2. 私たちは今、複合要因を一本の鎖に潰していないか？ 分岐（原因ツリー／FTA）が必要では？――複雑問題を単純化し過ぎると、打ち手が外れます。

3. “人のミス”に見えるが、ミスが起きる条件（負荷・UI・権限・例外運用）を設計で消せているか？――再発防止は個人能力ではなく環境設計で決まります。

4. この“Whyの答え”は、機能（動詞＋名詞）として書き直せるか？ ――書き直せないなら、原因が曖昧で検証不能なままです。機能言語に落ちない原因は、たいてい「人のせい」か「印象論」に寄っており、再発防止策が精神論になります。

主要な情報源リスト

一次資料：

1. Ohno, Taiichi (1988). “Toyota Production System: Beyond Large-Scale Production” – Archive.org
2. 小倉仁志 (2007). 「なぜなぜ分析の10則－2007年度版」 – Management Dynamics PDF

二次資料：

1. Wikipedia: Five Whys – Wikipedia
2. Lean Enterprise Institute – Lean.org
3. Institute for Healthcare Improvement – IHI
4. Serrat, O. (2017). The Five Whys Technique. Springer – Springer
5. Toyota Industries Corporation – Toyota Industries
6. Toyota Global – Toyota Global

marketing-ai.bizでは、トヨタ用語集のまとめページもあるのでご覧ください。
トヨタ用語集：TPSはもちろん面着・○カ・号口など…現場と企画で使う頻出ワード集（番外編：略称）