Claudeでなぜなぜ分析の飛躍を洗い出す — 各段の根拠を点検させる型

なぜなぜ分析は、不具合に対して「なぜ」を繰り返し、真因に近づく手法です。Claudeに「なぜを5回やって」と頼むと、きれいな連鎖がすぐ返ってきます。ただ、その連鎖の途中に、記録で裏づけられていない段が混ざっていても、見た目では分かりません。この記事では、Claudeに原因を考えさせる代わりに、各段の根拠(記録・観察)の有無を点検させ、飛躍を指摘させる型を紹介します。Projectに資料を置き、指示文を保存し、表で判定を受け取る流れです。

なぜなぜ分析のどこで飛躍が起きるか

なぜなぜ分析が外れるときは、段数が足りないのではなく、段と段のつなぎ目が弱いことが多くあります。点検の観点を先に決めておくと、Claudeへの指示が具体的になります。ここでは、飛躍を5つの型に分けます。

この5つは、点検用に整理した分類で、特定の規格の用語ではありません。自社の手順書に分類がある場合は、そちらの名前に置き換えて指示文に入れてください。

「展開させる」より「点検させる」が向く理由

Claudeにゼロから5段を展開させると、文章として自然な連鎖が出ます。自然であることと、事実であることは別です。展開の途中で、資料に無い設備の状態や作業者の行動が、もっともらしく補われることがあります。

点検型にすると、Claudeの仕事は「連鎖を作る」から「連鎖を資料と突き合わせる」に変わります。人間が書いた連鎖、または人間が現場で聞き取ってまとめた連鎖を渡し、各段について次の3つを返させます。

• その段を支える記録や観察が、渡した資料のどこにあるか
• 資料に無いなら、それは「推測」か「飛躍」か
• 裏づけるために、現場で確かめる項目は何か

この形なら、Claudeの出力は「人が次に何を確かめるか」の一覧になります。原因を決めるのは人のままです。

Projectに置く資料と設定

不具合の記録は、毎回チャットに貼ると手間がかかります。Projectは、資料(知識)と指示を保存して、そのProject内のチャットで使い回せる仕組みです。ProjectはFreeを含む全ユーザーが使え、Freeで作れるのは最大5つです。

最後のStepには理由があります。メモリーはFree・Pro・Maxで既定でオンで、Projectごとに独自のメモリーを持ち、同じProjectのチャットでは使われます。何もしないと、ある案件で保存された内容が、同じProjectの別の案件のチャットに入り込みえます。そのために、上のStepでMemoryをオフにしています。

また、有料プランでは、プロジェクトの知識がコンテキストの上限に近づくと、Claudeが自動でRAGモードを有効にして容量を広げます(RAGは検索で必要な部分だけを引く仕組みです)。ただし、ヘルプセンターにはRAGモードで何が引かれるかの説明がありません。点検の根拠に使う資料は、案件のチャットに直接添付するほうが、Claudeが見ている範囲を確かめやすくなります。

プロジェクト指示の例

指示文の要点は3つです。根拠は渡した資料からだけ引くこと、資料に無いものは「根拠なし」と書くこと、原因を新しく考え出さないことです。次は、そのまま使える書き方の例です。

あなたは製造現場の品質改善を支援するレビュー担当です。
ユーザーが渡すなぜなぜ分析の連鎖を、各段ごとに点検してください。
 
規則:
1. 根拠として使ってよいのは、このProjectの資料と、
   チャットに添付された資料だけです。
2. 各段について、根拠の資料名と該当箇所を引用してください。
   見つからない場合は「根拠なし」と書いてください。
3. 「根拠なし」の段は、推測か飛躍かを区別し、
   確かめる方法を1つ以上挙げてください。
4. 新しい原因を自分で追加しないでください。
   原因の候補が思い浮かんでも、「候補」と明記して別枠に書いてください。
5. 判定は「根拠あり」「推測」「飛躍」のいずれかで、
   理由を1文で添えてください。

3番目の規則が、点検型の核です。「根拠なし」と言われた段に、確認の方法が付いていれば、現場で動けます。

連鎖を渡して、判定表を受け取る

チャットには、不具合の報告と、確認済みの事実、現時点の連鎖を渡します。次は、架空のプレス加工ラインの例です。

【不具合】金型交換後の初回ロットで、寸法Aが規格上限を超えた(30個中4個)。
【確認済みの事実】
 - 交換は第2シフトの引き継ぎ直後に実施
 - 交換記録に「ボルト締付トルク」の記入欄はあるが空欄
【連鎖】
 1. なぜ寸法Aが超えた? → 金型の位置がずれたから
 2. なぜずれた? → ボルトの締付が不十分だったから
 3. なぜ不十分? → 作業者がトルクレンチを使わなかったから
 4. なぜ使わなかった? → 作業者の注意不足

この入力に対して、Claudeには次の列を持つ表で返させます。指示文に書いておけば、毎回同じ形で返ります。

上の表は、指示文の規則に沿って返ってくる形の例です。実際の判定の文言や粒度は、渡す資料と指示文で変わります。どの段をどう判定するかは、出力を人が読んで確かめてください。

注目したいのは、空欄の記録をどう扱うかです。空欄は「締めていない」の証拠ではなく、「記録されていない」ことしか示しません。点検型の指示を入れておくと、Claudeはこの差を判定の理由に書きやすくなります。

飛躍の指摘を、次の確認につなげる

表を受け取ったら、「推測」と「飛躍」の段を現場で確かめ、結果をチャットに戻します。戻すときは、確かめた事実だけを書き足し、連鎖の側は書き換えません。

この反復では、Claudeに連鎖を書き換えさせない点が肝心です。書き換えを任せると、事実が足りない段を再び文章で埋めてしまいます。

真因にたどり着いたかを逆向きに確かめる

連鎖の全段が「根拠あり」になったら、最後に逆向きの読み下しで確認します。最下段から上へ、「だから」でつないで読み、各段が成り立つかを見る方法です。

次の連鎖を、最下段から最上段に向けて「だから」でつないで読み上げ、
つなぎ目で成り立たない箇所があれば指摘してください。
また、最下段の原因を取り除いた場合に、最初の不具合が
再発しない理由を、資料の記録に基づいて説明してください。
説明できない場合は、その旨を書いてください。

「最下段を直せば再発しない」と資料から説明できないなら、そこは真因ではない可能性があります。説明できない理由が、さらに確認すべき項目になります。

任せる範囲と人が決める範囲

真因の確定は、現場の観察と責任者の判断で行います。Claudeの判定は、確かめる順序を決める補助です。

つまずきやすい点

• 資料に無い事実が根拠として挙がる: 引用の欄に、資料に存在しない文が出ることがあります。引用された箇所を原本で検索して確かめます。見つからなければ、その段を「根拠なし」に戻します。
• 指摘が多すぎて追えない: 全段が「飛躍」と返るときは、渡した事実が少なすぎる場合があります。確認済みの事実を足してから、もう一度点検させます。
• 同じ表現の言い換えで「根拠あり」になる: 段2の主張が、段1の言い換えにすぎない場合があります。5つの型のうち「対策の言い換え」に当てはまらないかを、指示文で確かめさせます。
• 長いチャットで事実が混ざる: 反復が増えると、どの事実がいつ確認されたかが見えにくくなります。区切りのたびに、確認済みの事実の一覧を出させ、新しいチャットで続けます。Memoryをオフにして始める操作は、上のStepのとおりです。

近い分析との使い分け

顧客に返す8D報告書の中で原因を扱う場合は、手順の全体をClaudeで顧客クレームの8D報告書を過去の不良記録から下書きするにまとめています。報告書の欄を埋める作業は、そちらが対象です。

数値の変動に理由を付ける作業は、不具合の連鎖とは性質が異なります。月次の差異なら、Claude for Excelで月次変動分析 — 前月比と前年同月比の理由メモを作るで、理由メモに根拠を添える流れを扱います。

また、資料に出典を付け、事実と解釈を分ける考え方は、SWOT・3C分析の下書きの手順と共通しています。

まとめ

なぜなぜ分析をClaudeに任せるときの危うさは、連鎖が自然な文章で出てくる点にあります。展開させず、点検させると、出力は「次に確かめる項目」の一覧になります。Projectに記録を置き、指示文で「資料に無ければ根拠なし」と固定し、判定表で受け取ります。表の判定を信じ切らず、引用箇所は原本で確かめます。真因の確定は、現場で確かめた事実を持つ人が行います。