製造業の不具合のなぜなぜ分析は、Claude Codeに「現象」「確かめた事実」「前提条件」をファイルで渡して要因の表の下書きを作らせ、その表を点検のスクリプトとskill（決まった手順を呼び出せる指示書）で確かめる、という分担で進められます。どの要因が根本原因かの判断と、再発防止策を決めるのは、品質保証の担当者と現場の参加者です。
この記事は、部品メーカーの組立工程で起きた部品の付け忘れを、品質保証の担当者がClaude Codeを使って分析する場合の構成を、想定シナリオとして組み立てたものです。特定の会社の導入事例ではありません。点検に使う決まりは、情報処理推進機構（IPA）の「プロセス改善入門－プロセス改善のためのツールの概要－」（2013年）にある「押さえておきたい９つのポイント」と、「情報処理システム高信頼化教訓集（ITサービス編）別冊Ⅱ：障害分析手法」（2020年3月16日改訂）から取っています。
この記事の要点
- 結論：Claude Codeに任せるのは、事実と前提条件の整理・要因の表の下書き・9つのポイントでの点検・逆読みの文の作成・再発防止策の台帳の点検の5つ。根本原因の判断と対策の決定は人が行う。
- 9つのポイント：IPAの資料は、責任の所在は個人ではなく組織・主語をしっかり書く・抽象的な表現は使わない・心理面の要因で終わらない・要因の出し切りなど9つを挙げています。このうち機械で見られる所をスクリプトに、読んで判断する所をskillに書き、参加者の選定と問題の整理は打ち合わせの準備で扱う。
- 回数：IPAの資料は、「なぜ？」を繰り返す回数（深堀回数）は決められていないとしています。5回で止めず、対策が打てる原因まで掘る。
- 再発防止策：根本原因を裏返して再発防止策と未然防止策を出し、妥当な策が出ない時は分析をやり直す。策は台帳で期限と効果の確認日まで管理する。
- 作業者の名前：要因の表には名前を書かず「組立2工程の作業者」のように役割で書く。分析の目的は個人を責めることではなく、組織の再発防止策を考えることだからです。
なぜなぜ分析でClaude Codeに任せる所と任せない所
なぜなぜ分析は、IPAの別冊Ⅱの言葉では、発生した事象を起点に「なぜ（それが発生したのか）」と問いながら、根本原因（それに対策すれば問題が再発しなくなる原因）まで遡っていく分析手法です。同じ資料は、この手法を「製造業で成功した方法」と紹介し、特別なツールを入れなくても始められる点を挙げています。
一方で、要因を書き出すと「確認不足」「注意が足りなかった」のような言葉で止まりやすく、主語が抜けた文や、逆から読むとつながらない段も混じります。こうした書き方の点検は、決まりを文章にしておけばClaude Codeに繰り返し確かめさせられる所です。
任せる所
- 不具合の記録と聞き取りのメモから、現象・確かめた事実・前提条件を決まった形のファイルに整理する
- 事実に沿って要因の表の下書きを作る（事実で裏付けがない要因には「仮説」の印を付ける）
- 9つのポイントのうち、主語の抜け・「〜が悪い」の表現・心理面の要因で終わっていないか・出ていない観点を点検する
- 一番下の要因から現象まで「だから」でつないだ逆読みの文を作る
- 再発防止策の台帳から、期限や効果の確認日を過ぎて結果が空の行と、要因の表とつながらない行を一覧にする
任せない所
- どの要因を根本原因とするか、どの対策を採るかの決定
- 現物の確認（現場で現物を見て事実を確かめること）と、当事者からの聞き取り
- 客先への報告書の最終の文面と、提出の判断
なぜなぜ分析の進め方を2つの資料で確かめる
Claude Codeに渡す決まりは、担当者の記憶ではなく資料から写します。ここではIPAの2つの資料を使います。どちらもIT（ソフトウェアやシステム障害）の分野の資料です。2013年の資料には「for Mo･No･Zu･Ku･Ri」の表記があり、別冊Ⅱはなぜなぜ分析を製造業で成功した方法として紹介しています。製造業向けの規格や社内の品質の手順ではないので、この記事では考え方を想定シナリオに当てはめ、実際の分析では自社の品質の手順と合わせて使います。
原因分析から対策までの流れ
別冊Ⅱは、なぜなぜ分析を「原因分析」と「再発防止策／未然防止策の検討」の2段に分けています。原因分析のポイントは次の2つです。
- 直接の原因（直接原因）を見つけ、さらにそれを引き起こした原因を見つける手順を繰り返して、根本原因を見つけ出す
- 分析は事実をもとに行い、できる限り当事者の参加を求める。目的は「個人」を責めることではなく「組織」としての再発防止策を考えることだと参加者に徹底する
対策の検討では、直接原因を裏返して直接原因への対応策を、根本原因を裏返して再発防止策と未然防止策を洗い出します。根本原因を解消でき、対策に必要な費用や人的・物的リソースを投入でき、それに見合う効果が期待できる再発防止策が出ない時は、分析をやり直すとしています。
押さえておきたい9つのポイント
2013年の資料は、なぜなぜ分析で押さえておきたい点を9つ挙げています。見出しは原文のままです。
| 番号 | ポイント（原文の見出し） | 資料の説明の要点 |
|---|---|---|
| 1 | 責任の所在は個人ではなく組織 | 当事者の責任を追及してはいけない |
| 2 | 参加者の選定 | 当事者のほか、現場のベテラン（管理者）、仕組み・ルールの策定担当者、品質保証の担当者など、得意分野や経験が異なる人も参加するとよい |
| 3 | 問題の整理 | 実行前に事実をつかみ、問題が発生した流れを整理する |
| 4 | 問題発生の前提となる条件の明確化 | 分析の前に前提条件（事実）を書き出し、要因が無闇に広がるのを防ぐ |
| 5 | 主語をしっかり書く | 主語が欠けると次の「なぜ？」の主体がぼやける |
| 6 | 抽象的な表現は使わない | 「～が悪い」は人によって解釈が違うので具体的な言葉に置き換える |
| 7 | 要因分析の展開に飛躍はないか | 最後の「なぜ？」から現象までを「だから」でつないで逆向きに読む |
| 8 | 心理面の要因で終わらない | 「疲れていた」「気づかなかった」などで止めず、もう一段掘り下げる |
| 9 | 要因の出し切り | 環境･プロセス･人･管理などの観点で要因が展開されているか確かめる |
「なぜ」は5回と決まっていない
2013年の資料は、真の要因に辿りつくまで「なぜ？」を繰り返し、最後の要因を裏返して再発防止策を立てるとしたうえで、深堀回数は決められていないと書いています。Claude Codeへの指示でも「5段で止める」とは書かず、「裏返すと対策になる要因まで掘る」と書きます。
想定シナリオ：組立工程の部品の付け忘れを分析する
ここからは想定のシナリオです。実在の会社・製品・人物ではありません。
部品メーカーの組立工程で、最終検査の段階で部品Aが付いていない製品が見つかりました。部品Aは今月のモデル切替で新しく加わった部品です。品質保証の担当者は、客先に出す不具合報告の前に、組立の班長・作業手順書を作る生産技術の担当者・当事者の作業者と分析の打ち合わせを開きます。打ち合わせの前に、Claude Codeで要因の表の下書きと点検を済ませておく、という使い方です。
担当者が決めたこと
- 分析のファイルはすべて1つのフォルダに置き、作業者の名前は書かない
- 要因の表は打ち合わせの「たたき台」とし、確定は打ち合わせで行う
- 9つのポイントの点検に通らない表は打ち合わせに出さない
- 決めた再発防止策は台帳に移し、効果を確かめる日まで追う
分析のフォルダとCLAUDE.mdを作る
Claude Codeは、プロジェクトのCLAUDE.md（Claude Codeに毎回読ませる指示のファイル）をセッションの初めに読みます。分析の決まりはここに書きます。Claude Code公式の「How Claude remembers your project」は、CLAUDE.mdを「Claude reads them at the start of every session」と説明しています。
フォルダの例
naze-analysis/
├── CLAUDE.md # 分析の決まり
├── rules/
│ └── 9points.md # 9つのポイント（IPAの資料から写した見出しと説明）
├── 00_records/ # 不具合の記録・聞き取りのメモ（名前は役割に直してから置く）
├── 01_analysis/
│ └── NC-2026-10-01.yaml # 要因の表（1件1ファイル）
├── 02_countermeasures/
│ └── ledger.csv # 再発防止策の台帳
├── scripts/
│ └── check_naze.py # 機械で見られる点の点検
└── .claude/
├── settings.json # 読ませない場所の設定
└── skills/
└── naze-check/
└── SKILL.md # 9つのポイントの点検手順
CLAUDE.mdの例
# 不具合のなぜなぜ分析フォルダ
## このフォルダでやること
- 00_records の記録から、現象・事実・前提条件を 01_analysis の yaml に整理する
- 要因の表の下書きを作る。1段ごとに主語・文・観点（環境/プロセス/人/管理）を書く
- 下書きができたら scripts/check_naze.py と /naze-check で点検する
## やらないこと
- 人の名前を書かない。「組立2工程の作業者」のように役割で書く
- 記録に無い事実を足さない。裏付けのない要因には「仮説: 」を頭に付ける
- 根本原因と対策を決めない。候補として並べるだけにする
## 書き方
- 「〜が悪い」「確認不足」で止めず、何がどうなっていたかを書く
- 心理面の要因（気づかなかった・思い込んでしまった など）で終わらせない
- 回数で止めない。裏返すと対策になる所まで掘る
事実と前提条件をファイルに書かせる
最初の作業は、記録とメモから事実を拾って形をそろえることです。9つのポイントの「問題の整理」と「問題発生の前提となる条件の明確化」に当たります。前提条件を先に書いておくと、要因が工程と関係のない話へ広がるのを抑えられます。
要因の表の例
id: NC-2026-10-01 # 想定の不具合番号
現象: 最終検査で部品Aが付いていない製品が見つかった
事実:
- 部品Aが無い製品は組立2工程を通っていた
- 組立2工程の作業手順書は前のモデルの版のままだった
前提条件:
- 部品Aは今月のモデル切替で新しく加わった
- モデル切替の前に作業手順書を改訂する決まりがある
要因:
- id: "1"
主語: 組立2工程の作業者
文: 部品Aを付けずに次の工程へ流した
観点: 人
下位:
- id: "1-1"
主語: 組立2工程の作業手順書
文: 前のモデルの手順のままになっていた
観点: プロセス
下位:
- id: "1-1-1"
主語: モデル切替の準備の手順
文: 作業手順書の改訂を確かめる項目を持っていなかった
観点: 管理
最後の要因は、裏返すと「モデル切替の準備の手順に、作業手順書の改訂を確かめる項目を足す」という対策になります。2013年の資料にも、部品の付け忘れから手順書の見直しまでを「だから」でつなぐ例が載っています。
下書きを作らせる指示
00_records/NC-2026-10-01_memo.md を読んで、01_analysis/NC-2026-10-01.yaml を作って。
CLAUDE.md の書き方に従うこと。
記録に書かれていない事実は足さず、裏付けのない要因は「仮説: 」で始めること。
作り終えたら、記録のどの行を根拠にしたかを要因の id ごとに一覧で出して。
根拠の行を一覧で出させると、打ち合わせで「その要因はどの記録から来たか」をすぐ示せます。
9つのポイントで要因の表を点検する
9つのポイントには、スクリプトで拾える所と、決まりを読んで判断する所があります。スクリプトは、主語の抜け・「が悪い」を含む文・心理面の言葉で終わる要因・一度も出ていない観点を一覧にします。責任を個人に向けていないか・前提条件の外へ広がっていないか・飛躍が無いかは、skillの手順で逆読みの文を読ませて確かめ、最後は打ち合わせで人が判断します。「参加者の選定」は打ち合わせの人選で、「問題の整理」は前の節の事実と前提条件の書き出しで扱います。
点検のスクリプトの例
# scripts/check_naze.py 要因の表を読み、機械で見られる点を一覧にする
import sys
import yaml # pip install pyyaml
NG_END = ["ボーッとしていた", "疲れていた", "気づかなかった", "思い込んでしまった"]
VIEWS = {"環境", "プロセス", "人", "管理"}
def walk(node, path, leaves):
path = [*path, node]
kids = node.get("下位") or []
if not kids:
leaves.append(path)
for kid in kids:
walk(kid, path, leaves)
def main(filename):
data = yaml.safe_load(open(filename, encoding="utf-8"))
leaves = []
for top in data["要因"]:
walk(top, [], leaves)
checked, seen_views = set(), set()
for path in leaves:
for node in path:
seen_views.add(node.get("観点", ""))
if node["id"] in checked:
continue
checked.add(node["id"])
if not node.get("主語"):
print(f"[主語なし] {node['id']}")
if "が悪い" in node["文"]:
print(f"[抽象的な表現] {node['id']} {node['文']}")
last = path[-1]
if any(word in last["文"] for word in NG_END):
print(f"[心理面で終わっている] {last['id']} {last['文']}")
chain = " だから ".join(f"{n['主語']}が{n['文']}" for n in reversed(path))
print(f"[逆読み] {chain} だから {data['現象']}")
missing = VIEWS - seen_views
if missing:
print(f"[出ていない観点] {'・'.join(sorted(missing))}")
if __name__ == "__main__":
main(sys.argv[1])
心理面の言葉の一覧は、2013年の資料が挙げる「ボーッとしていた」「疲れていた」「気づかなかった」「思い込んでしまった」をそのまま入れています。現場でよく出る言い方があれば足していきます。
上の要因の表の例でこのスクリプトを動かすと、一番下の要因から現象までをつないだ逆読みの文が1本と、「[出ていない観点] 環境」が出ます。環境の要因が本当に無いかは、打ち合わせで現場の参加者に確かめます。
点検のskillの例
人の目で見る点は、skillに手順として書きます。Claude Code公式の「Extend Claude with skills」によると、skillは .claude/skills/<skill-name>/SKILL.md に置き、/skill-name で呼び出せます。frontmatterに disable-model-invocation: true を書くと、Claudeが自分から読み込まず、人が呼んだ時だけ動きます。$ARGUMENTS には呼び出す時に渡した文字列が入ります。
---
name: naze-check
description: なぜなぜ分析の要因の表を9つのポイントで点検する
disable-model-invocation: true
---
$ARGUMENTS の要因の表を点検する。
1. python3 scripts/check_naze.py $ARGUMENTS を実行し、出力をそのまま表に写す
2. rules/9points.md を読み、次の点を要因ごとに確かめる
- 個人の責任で終わっていないか（1 責任の所在は個人ではなく組織）
- 前提条件にない話へ広がっていないか（4 前提条件の明確化）
- [逆読み] の文を読み、「だから」でつながらない段はないか（7 飛躍）
- 一番下の要因を裏返すと、組織で打てる対策になるか
3. 結果は「要因の id／当たったポイント／直す案」の表で返す。表は書き換えない
最後の「表は書き換えない」は大事な一行です。点検の役と書く役を分けておくと、直した理由を打ち合わせで説明できます。
逆読みで見つけたい形
逆読みの文で見つけたい形の1つは、上の段と下の段の主語が入れ替わって、「だから」でつなぐと意味が通らない形です。たとえば「作業者が部品Aを付けずに流した」の下に「検査の担当者が見逃した」を置くと、逆から読んだ時に因果が逆になります。見逃しは流出の要因で、付け忘れの要因ではないので、別の枝に分けます。どこで枝を分けるかの判断は打ち合わせで行い、Claude Codeには分けた後の表の点検をさせます。
再発防止策を台帳で管理する
別冊Ⅱは、根本原因を裏返して再発防止策と未然防止策を出し、妥当な策が出ない時は分析をやり直すとしています。打ち合わせで決めた策は、要因の表とは別の台帳に移し、実施と効果の確認まで追います。
台帳の列の例
| 列 | 書く内容 |
|---|---|
| 不具合番号 | NC-2026-10-01 など、要因の表の id |
| 要因の id | 策が裏返している要因（例: 1-1-1） |
| 区分 | 直接原因への対応策／再発防止策／未然防止策 |
| 内容 | 何をどう変えるか |
| 担当 | 役割で書く（生産技術の担当者 など） |
| 期限 | 実施する日 |
| 効果の確認日 | 同じ不具合が出ていないかを見る日 |
| 結果 | 確認した日と内容 |
台帳を見させる指示
02_countermeasures/ledger.csv を読んで、次の3つを一覧にして。
1. 期限を過ぎて結果が空の行
2. 効果の確認日を過ぎて結果が空の行
3. 要因の id が 01_analysis のどのファイルにも無い行
一覧だけ出して、台帳は書き換えないこと。
この想定手順では、効果を確かめて同じ不具合が続いていた場合、その不具合を分析のやり直しの対象にします。台帳の3つ目の点検は、要因の表を直した時に策と要因のつながりが切れていないかを見るためのものです。
作業者の名前と記録を守る設定
不具合の記録には、作業者の名前やシフトが書かれていることがあります。要因の表に名前が入ると、分析が個人の責任の話へ寄りやすくなり、個人情報を扱う範囲も広がります。
個人情報保護委員会の注意喚起
個人情報保護委員会の「生成AIサービスの利用に関する注意喚起等」（令和5年6月2日）は、個人情報取扱事業者が個人情報を含むプロンプトを入力する場合、「特定された当該個人情報の利用目的を達成するために必要な範囲内であることを十分に確認すること」を求めています。同じ注意喚起は、本人の同意を得ずに個人データを含むプロンプトを入力する場合は、サービスを提供する事業者がその個人データを機械学習に利用しないこと等を十分に確認することも求めています。分析には名前が要らないので、00_records に置く前に役割へ置き換えます。
アカウントの学習設定
Claude Code公式の「Data usage」によると、Free・Pro・Max・Ultraのアカウントでは、モデルの改善に使うことを許す設定がオンの時、Claude Codeの利用も含めて新しいモデルの学習に使われます。TeamやEnterprise、APIなどの商用の条件では、顧客が提供を選ばない限り学習に使わないとしています。会社の記録を扱うなら、どの契約で使うかを先に決めます。
読ませない場所の設定
名前の入った元の記録は、Claude Codeに読ませない場所に分けておきます。公式の「Configure permissions」は、ファイルを読ませない時は Read(./secrets/**) のような Read のdenyのルールを足すとしています。チームで同じ設定を使うなら、公式の「Settings files and precedence」が説明する .claude/settings.json に書きます。Gitで共有するプロジェクトでは、このファイルをコミットしてチームに共有します。
{
"permissions": {
"deny": [
"Read(./00_records/raw/**)"
]
}
}
同じページは、このdenyのルールが grep -r のようにファイル名を書かずに読むコマンドや、Pythonなどのスクリプトが自分でファイルを開く読み方には効かないとしています。名前の入った元の記録は、分析のフォルダの外に置きます。ただし同じページは、cat などの読み取り専用のコマンドが既定では作業フォルダの外でも確認なしで動くとしています。どのプロセスからも読めなくするには、同じページが案内するサンドボックスを有効にします。
なぜなぜ分析をClaude Codeで進める時の失敗と対処
❌ 要因の表をClaude Codeに最後まで書かせる
記録に無い要因が、もっともらしい文で混じります。⭕ 裏付けのない要因は「仮説: 」で始めさせ、根拠の行の一覧と合わせて打ち合わせで事実を確かめます。
❌ 「なぜ」を5回で打ち切る
一番下の段が「〜を忘れていた」のような行動で止まると、裏返しても「忘れないようにする」という策しか出ません。⭕ 回数でなく、裏返すと組織で打てる対策になるかで止める所を決めます。
❌ 作業者の名前を表に書く
名前があると、要因が「〇〇さんが気づかなかった」の形に寄ります。⭕ 役割で書き、名前の入った記録は読ませない場所に置きます。
❌ 点検と書き直しを同じ指示で頼む
点検の結果と直した表が一度に出ると、何をなぜ直したかが追えません。⭕ skillには表を書き換えさせず、直す案だけを返させます。
まとめ
なぜなぜ分析でClaude Codeが役に立つのは、要因の表の下書きと、決まりに沿った点検を何度でも同じように繰り返せる所です。決まりはIPAの資料にある9つのポイントと、原因分析から対策までの流れから写しておくと、打ち合わせで「何を基準に直したか」を示せます。
- 事実と前提条件を先にファイルに書かせる
- 要因の表は1段ごとに主語・文・観点で書かせる
- 機械で見られる点はスクリプト、人の目で見る点はskillで点検する
- 根本原因の判断と対策の決定は、現場の参加者と人が行う
- 再発防止策は台帳で効果の確認日まで追う
今日やることは、直近の不具合を1件選び、現象・確かめた事実・前提条件の3つを書き出すことです。
あわせて読みたい
よくある質問
なぜなぜ分析はAIでできますか？
要因の表の下書きと、書き方の点検はAIに任せられます。ただし事実を確かめること、根本原因の判断、対策の決定は人が行います。Claude Codeでは、記録に無い要因に「仮説」の印を付けさせ、根拠にした記録の行を一覧で出させると、打ち合わせで確かめやすくなります。
「なぜ」は5回繰り返すと決まっていますか？
IPAの「プロセス改善入門」は、「なぜ？」を繰り返す回数（深堀回数）は決められていないとしています。最後の要因を裏返して再発防止策を立てるので、裏返すと組織で打てる対策になる所まで掘ります。
製造業以外の不具合にも使えますか？
使えます。この記事で使ったIPAの2つの資料は、ソフトウェア開発やシステム障害の分析を扱う資料です。要因の表と点検の仕組みは同じで、観点（環境･プロセス･人･管理）の中身を業務に合わせて書き換えます。
作業者の名前を入れても大丈夫ですか？
分析には名前が要らないので、役割に置き換えてから渡します。IPAの資料は、責任の所在は個人ではなく組織とし、当事者の責任を追及してはいけないとしています。名前の入った元の記録は分析のフォルダの外に置き、Read のdenyのルールだけに頼らず、どのプロセスからも読めなくする時はサンドボックスを使います。
妥当な再発防止策が出ない時はどうしますか？
IPAの別冊Ⅱは、根本原因を解消できる妥当な再発防止策が出ない時は、分析をやり直すとしています。要因の表の一番下の段が、心理面の要因や「〜が悪い」で止まっていないかを点検し直すところから始めます。
運営元 Uravation よりこの事例を自社の業務で試す場合のテーマ選定・評価・本番移行の確認項目を、無料のチェックリストにまとめています。 Claude Code業務自動化PoCチェックリストを受け取る（無料）
参考・出典
2026年10月31日に各ページを取得して内容を確かめました。
- 独立行政法人情報処理推進機構（IPA）「プロセス改善入門－プロセス改善のためのツールの概要－」（2013年）
- 独立行政法人情報処理推進機構（IPA）「情報処理システム高信頼化教訓集（ITサービス編）別冊Ⅱ：障害分析手法」（2020年3月16日改訂）
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（令和5年6月2日）
- Anthropic「How Claude remembers your project」（Claude Code Docs）
- Anthropic「Extend Claude with skills」（Claude Code Docs）
- Anthropic「Configure permissions」（Claude Code Docs）
- Anthropic「Settings files and precedence」（Claude Code Docs）
- Anthropic「Data usage」（Claude Code Docs）
