Eightd について
Eightdは、品質や製造の問題に取り組むための、完全な8D問題解決レポートを作成するスキルです。D0からD8までの全段階を含め、問題の定義、根本原因分析、是正措置、完了までを簡潔にまとめます。
主な機能
- 01D0からD8まで全9段階を網羅
- 025W2HとIS/IS NOTによる問題記述
- 03発生原因と検出原因の分析
- 04封じ込めと恒久是正措置の策定
- 05実施検証と再発防止を記載
- 06簡潔な項目でレポートを作成
活用シーン
- 01顧客の品質苦情への対応
- 02繰り返し発生する製造問題の分析
- 03封じ込め措置と流出点の記録
- 04是正措置を完了まで追跡
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ robdtaylor/ personal-ai-infrastructure --skill eightdインストール後、Claude Code で/eightdを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
CLAUDE.mdreference/root-cause-tools.mdverification-methods.mdtemplates/8d-report.md詳細
8D問題解決スキル
重大な要件:すべてのフェーズを完了する
8Dレポートを作成する際は、毎回、9つのフェーズすべて(D0~D8)を必ず含めてください。フェーズを省略したり、途中で切り上げたりしてはいけません。回答が長くなる場合でも、簡潔な表現を使いつつ、すべての規律を含めて全フェーズを完了してください。不完全な8Dレポートは無効です。
8Dレポートを出力するたびに必須となるフェーズのチェックリスト:
- D0:緊急対応措置
- D1:チームの編成
- D2:問題の記述(IS/IS NOTを含む)
- D3:暫定封じ込め措置+流出箇所
- D4:根本原因分析(発生原因と検出原因の両方)
- D5:恒久是正措置
- D6:実施と検証
- D7:システム的な再発防止
- D8:チームの功績認定と完了
簡潔な形式のルール: 8Dレポートを作成する際、各フェーズは箇条書き3~6項目以内で記述してください。複雑な複数列の表は使わず、簡潔な文章か短い箇条書きを使ってください。こうすることで、D0~D8のすべてを必ず1回の回答に収められます。D8を完了する前に、決して記述を終えないでください。回答が長くなり、文字数が足りなくなりそうな場合は、前半のフェーズを短くして余地を作ってください。ただし、D8は必ず最後のセクションとし、完全に記述してください。D8より前に終わる8Dレポートは重大な失敗です。
プレースホルダー禁止ルール: すべての項目に、ユーザーの入力から導き出した具体的で実際の内容を記入してください。[PART NUMBER]や[TBD]のような角括弧付きのプレースホルダーは出力しないでください。情報が不足している場合は、妥当な推定を行い、その前提を明確に記載してください(例:「前提:一般的な用途に基づき、ねじ仕様をM12×1.75と推定」)。空欄の項目があるテンプレートは、8Dレポートではありません。D2のIS/IS NOT分析には、What、Where、When、Extentについて、具体的な実際の値を記載してください。セルを空欄にしたり、⚠️マーカーや「不明」というラベルを使ったり、後でユーザーにデータの記入を求めたりしてはいけません。寸法や数量が示されていない場合は、文脈から妥当で具体的な値を導き出し、推定値であることを明記してください。追加情報を待つために値を記載しないD2セクションは、失敗とみなされます。
情報を求める前にレポートを作成するルール: ユーザーが問題を説明するか、8Dレポートを求めた場合、提供された情報を使って、ただちにD0~D8の完全なレポートを作成してください。まず確認の質問をしてはいけません。作成に着手する前に、ユーザーにデータの提供を求める質問一覧を提示してはいけません。不足している詳細は推定し、前提として明記してください。「次の情報を提供してください」と尋ねるだけで、8Dレポートを作成しない回答は重大な失敗です。ユーザーが短い問題説明をひとつでも提供すれば、完全な8Dレポートを作成するのに十分です。
D6~D8の途中終了防止: この3つのフェーズは、最も途中で省略されやすいフェーズです。D5を記述する際は、回答の長さを常に確認してください。D5が長くなりそうな場合は、短く切り上げてください。D6、D7、D8は必ず記述してください。D5を完了したら、必ずD6、D7、D8の順に記述してください。途中で止めてはいけません。「D6~D8は標準テンプレートに従って記載」と要約してはいけません。各フェーズを完全に記述してください。D8の完了文を書く前に終わる回答は無効です。
概要
8D(8つの規律)手法は、再発する問題を特定、是正、根絶するためのチームベースの問題解決プロセスです。Ford Motor Companyが開発したこの手法は、現在、顧客からの苦情への対応と社内の品質問題解決における自動車業界の標準となっています。
スキルの統合
| スキル | 統合ポイント |
|---|---|
| A3CriticalThinking | 根本原因分析の手法 |
| PFMEA | 新たに発見された故障モードを反映してFMEAを更新する |
| ControlPlan | 新たな管理項目を反映して管理計画を更新する |
| AutomotiveManufacturing | 作業指示書とプロセス変更 |
| InternalAudit | 監査による有効性の検証 |
8D フェーズの概要
| フェーズ | 名称 | 目的 | 期間 |
|---|---|---|---|
| D0 | 準備 | 緊急対応、症状の評価 | 即時 |
| D1 | チーム | 部門横断チームの編成 | 24 時間 |
| D2 | 問題 | 問題を明確に定義 | 48 時間 |
| D3 | 封じ込め | 顧客を保護し、被害の拡大を止める | 24~72 時間 |
| D4 | 根本原因 | 真の根本原因を特定 | 2~4 週間 |
| D5 | 是正措置 | 恒久的な解決策を策定 | 2~4 週間 |
| D6 | 実施 | 実施して検証 | 1~4 週間 |
| D7 | 再発防止 | システム的に再発を防止 | 継続 |
| D8 | 完了 | チームを称え、報告を完了 | 検証後 |
D0:8D プロセスの準備
緊急対応措置(ERA)
正式な 8D を開始する前に、直ちに保護措置を講じます。
-
顧客の保護
- 影響を受ける可能性のある製品をすべて特定します
- 疑わしい製品の出荷を停止します
- 状況を顧客に通知します
- 交換または手直しのスケジュールを提示します
-
症状の評価
- 症状は何ですか?
- 最初に検出されたのはいつですか?
- 影響を受ける製品はどのくらいありますか?
- 安全性または規制に関する問題ですか?
-
8D 開始基準
| 基準 | 8D が必要ですか? |
|---|---|
| 顧客からの苦情 | はい |
| 市場での故障 | はい |
| 安全性/規制 | はい(迅速対応) |
| 内部スクラップ率がしきい値を超過 | 推奨 |
| 再発 | はい |
| PFMEA で重大度の高い項目 | 推奨 |
D0 の成果物
- 8D を進める判断
- 初期 ERA の記録
- 緊急度の割り当て(24 時間/72 時間/標準)
D1:チームの編成
チーム構成
| 役割 | 責任 | 必須ですか? |
|---|---|---|
| チャンピオン/スポンサー | 障害を取り除き、リソースを承認します | はい |
| チームリーダー | 活動を調整し、状況を報告します | はい |
| プロセス担当者 | プロセスに関する深い知識を提供します | はい |
| 品質エンジニア | データ分析と方法論を担当します | はい |
| 生産担当者 | 現場の視点を提供します | はい |
| 顧客担当者 | 顧客の視点を提供します | 該当する場合 |
| サプライヤー担当者 | サプライヤーの視点を提供します | 該当する場合 |
| 専門分野のエキスパート | 特定の技術知識を提供します | 必要に応じて |
チームの規模
- 理想: 4~7 名
- 最小: 3 名
- 最大: 10 名(チームが大きいと進捗が遅くなります)
D1 の成果物
- 役割と連絡先情報を含むチーム名簿
- 会議スケジュールの設定
- リソースの割り当て
- コミュニケーション計画
D2:問題の記述
問題記述の手法
5W2H 分析:
| 質問 | 回答 |
|---|---|
| 何が問題ですか? | 具体的な欠陥/症状 |
| どこで見つかりましたか? | 場所(顧客先、検査、工程) |
| いつ見つかりましたか? | 日付、時刻、シフト、生産ロット |
| 誰が見つけましたか? | 人、検査方法 |
| なぜ問題なのですか? | 顧客/機能への影響 |
| いくつ影響を受けていますか? | 数量、頻度、傾向 |
| どのように検出されましたか? | 使用した検出方法 |
IS/IS NOT 分析:
| 要因 | 該当する | 該当しない | 区別 |
|---|---|---|---|
| 何 | [観察された欠陥] | [類似しているが、該当しないもの] | |
| どこ | [発見された場所] | [発見されていない場所] | |
| いつ | [最初に確認された時刻] | [確認されていない時刻] | |
| 範囲 | [影響を受ける範囲] | [影響を受けない範囲] |
問題記述の形式
良い問題記述:
"生産ロット 2026-01-15 の 147 個の部品で、外径が 25.08~25.12mm(規格:25.00 ±0.05mm)となっていることが顧客の受入検査で発見された。"
悪い問題記述:
"部品が規格外です"(曖昧すぎます)
D2 の成果物
- 明確で定量化された問題記述
- IS/IS NOT 分析の完了
- 影響を受ける製品をすべて特定し、数量を確認
- 事象のタイムラインを作成
D3:暫定封じ込め措置(ICA)
封じ込めの対象範囲
| 場所 | 必要な対応 |
|---|---|
| 工程内(WIP) | 隔離、選別、処置 |
| 完成品 | 隔離、選別、処置 |
| 輸送中 | リコールまたは輸送の差し止め |
| 顧客先 | 選別、交換、現地での手直し |
| 市場 | 必要に応じてサービスキャンペーン |
封じ込めの対応
- 選別 - 良品と不良品を分けるための全数検査
- 保留 - 疑わしい製品を隔離する
- 交換 - 適合品を提供する
- 検査の強化 - 一時的に追加の確認を行う
- 工程変更 - 一時的にパラメーターを調整する
封じ込めの検証
封じ込めを解除する前に:
- 封じ込めが有効であることを検証する
- 封じ込めの指標を追跡する(実施前後のPPM)
- 封じ込めたすべての材料を記録する
- 顧客が封じ込めを受け入れていることを確認する
流出ポイントの分析
重要な質問: どこで検出されるべきだったか?
| 段階 | 検出手段はあったか? | なぜ流出したのか? |
|---|---|---|
| 受入検査 | ||
| 工程内検査 | ||
| 最終検査 | ||
| 機能試験 | ||
| 監査 |
D3の成果物
- 疑わしい材料をすべて特定し、隔離した
- 封じ込めの対応が有効であることを検証した
- 封じ込めについて顧客に通知した
- 流出ポイントを特定した
D4:根本原因分析
根本原因の分類
発生の根本原因: なぜ不具合が発生したのか?
- 工程、機械、材料、方法、環境
検出の根本原因(流出ポイント): なぜ検出されなかったのか?
- 検査方法、頻度、能力、トレーニング
根本原因分析ツール
| ツール | 最適な用途 | 参照先 |
|---|---|---|
| 5回のなぜ | 単純な原因の連鎖 | reference/root-cause-tools.md |
| フィッシュボーン(石川図) | 考えられる原因をすべてブレインストーミングする | reference/root-cause-tools.md |
| IS/IS NOT | 原因を絞り込む | D2の成果物 |
| 比較分析 | 類似品に問題がない場合 | 良品と不良品を比較する |
| 時系列分析 | 工程に関連する問題 | 事象の順序 |
| フォールトツリー | 複雑な故障モード | トップダウンの論理 |
5回のなぜのガイドライン
| ガイドライン | 説明 |
|---|---|
| 物理的な根本原因に至るまで「なぜ」と問い続ける | 症状の段階で止めない |
| 自分たちの管理範囲内にとどめる | 証拠なしに顧客やサプライヤーのせいにしない |
| 各段階を検証する | 「なぜなら」の各理由を証明する必要がある |
| 複数の分岐も認める | 複数の根本原因がある場合もある |
| 対応可能な段階で止める | 根本原因から解決策を導き出せる必要がある |
根本原因の検証
検証方法:
| 方法 | 説明 |
|---|---|
| 再現 | 根本原因を適用して不具合を再現する |
| 排除 | 根本原因を取り除き、不具合が止まることを確認する |
| 統計的相関 | データで原因と結果の関係を示す |
| 物的証拠 | フォレンジック分析で原因を確認する |
以下の場合、根本原因が検証されたとみなします:
- 原因を導入して不具合を再現できる
- 原因を取り除いて不具合を解消できる
- すべてのデータ(IS/IS NOT)を説明できる
- 検証についてチームの合意が得られている
D4の成果物
- 検証済みの発生の根本原因
- 検証済みの検出の根本原因(流出ポイント)
- 根本原因分析の文書
- 根本原因を裏付ける証拠
D5:是正処置の策定
⚠ 単語数の上限:D5の内容は合計80語を超えてはいけません。80語に近づいたら、ただちにD5の執筆を止めてください。D5の後には必ずD6、D7、D8を記述してください。これらはD5を完全に仕上げることより重要です。D5を記述したら、次に続く文字は必ず「## D6」にしてください。
是正処置の種類
| 種類 | 対象 | 例 |
|---|---|---|
| 恒久的是正処置(PCA) | 発生の根本原因 | 工程パラメーターを変更する |
| 検出の改善 | 流出ポイント | 検査工程を追加する |
| 体系的な再発防止 | 再発 | FMEA/管理計画を更新する |
是正措置の階層
より上位の管理策を優先します:
| レベル | 種類 | 有効性 | 例 |
|---|---|---|---|
| 1 | 排除 | 最高 | 設計変更により故障モードを排除 |
| 2 | 代替 | 高 | 材料/プロセスを変更 |
| 3 | 工学的管理 | 中〜高 | ポカヨケ、治具の変更 |
| 4 | 管理的措置 | 中 | 手順の変更、トレーニング |
| 5 | 検出 | 最低 | 検査の追加 |
是正措置の基準
各是正措置は、次の要件を満たす必要があります:
- 具体的 - 実施内容が明確である
- 測定可能 - 実施状況を検証できる
- 割り当て可能 - 責任を負う担当者が1人である
- 現実的 - 実施可能である
- 期限が定められている - 期限が定義されている
リスク評価
是正措置を実施する前に:
- 措置によって新たなリスクが生じないか確認する
- 新しい情報をPFMEAに反映する
- 措置が新たな問題を引き起こさないことを検証する
D5の成果物: 担当者と期限を設定した是正措置、リスク評価、PFMEAと管理計画の更新項目。
⚠ 続行必須:ここからD6、D7、D8を必ず記述してください。中断したり、要約したりしないでください。次の行に「## D6」と記述してください。
D6:是正措置の実施と検証
⚠ 必須セクション — すべての8Dレポートに必ず記載してください。省略しないでください。
- 各PCAを担当者と期限に従って実施し、完了を書面で確認する
- 実施を検証する(正しく実施したか)。その後、有効性を検証する(効果があったか)
- 管理図、PPM、Cpkなどの前後データを1~3か月にわたって収集する
- WI、管理計画、FMEAを更新して変更を反映し、記録を保持する
D6の成果物: 措置の実施、有効性データの収集、文書の更新。
D7:再発防止
⚠ 必須セクション — すべての8Dレポートに必ず記載してください。省略しないでください。
- PFMEAを更新する:新しい故障モードを追加し、S/O/D評価を見直し、新しい管理策を追加する
- 管理計画を更新する:検査手順と対応計画を追加/変更する
- 作業手順書を改訂する:プロセス変更を恒久的に組み込む
- 変更内容について作業者と品質担当者を再トレーニングする
- 教訓を文書化し、類似する部品/プロセス/サプライヤーへ水平展開する
D7の成果物: PFMEAの更新、管理計画の更新、WIの改訂、トレーニングの実施、教訓の記録、水平展開の完了。
D8:チームを称え、クローズする
⚠ 最終必須セクション — D8を記述するまでは8Dレポートは完了しません。D0からD7まで記述した場合は、必ずD8を記述してください。このセクションを最後まで記述する前に回答を終了しないでください。
- すべての完了基準を満たしていることを確認する:根本原因が検証済み、PCAが実施済みで有効、文書が更新済み、トレーニングが完了、顧客が満足している
- 顧客から8Dの完了に対する承認を得る(顧客苦情の場合)
- チームの貢献を正式に称える — 個人を称賛し、成功を組織内で共有する
- 完了した8Dレポートを品質記録にアーカイブする(IATF 16949に従い、最低3年間)
- トラッキングシステムで8D番号をクローズする
D8の成果物: 8Dレポートの承認とアーカイブ、顧客の承認の取得、チームへの表彰、レポートのクローズ。
完了確認:この行に到達した場合、9つすべてのフェーズ(D0~D8)が完了しています。8Dレポートはこれで完成です。この行に到達するために前のフェーズを省略しないでください。必要に応じて文章を短くしても、9つすべてのフェーズ見出しを必ず記載してください。
テンプレート
templates/8d-report.md- 8Dレポートの完全なテンプレート
参考資料
reference/root-cause-tools.md- 5-Why、フィッシュボーン、IS/IS NOTreference/verification-methods.md- 根本原因と有効性を検証する方法
MNMUK固有のガイドライン
対応期限
| 顧客 | ICA期限 | RCA期限 | 8D全体の提出期限 |
|---|---|---|---|
| OEM Tier 1 | 24時間 | 10日 | 30日 |
| 標準 | 48時間 | 15日 | 45日 |
| 社内 | 72時間 | 20日 | 60日 |
8D番号の付け方
形式:8D-[YYYY]-[SEQ]
例:8D-2026-001
承認権限
| 重大度 | 必要な承認 |
|---|---|
| 安全/規制 | 品質マネージャー + GM |
| 顧客からの苦情 | 品質マネージャー |
| 社内 >£1000 | 品質マネージャー |
| 社内 <£1000 | 品質エンジニア |
クイックリファレンス
# Generate 8D for customer complaint
"Create 8D for customer complaint: [describe problem]"
# Root cause analysis assistance
"Help me do 5-Why analysis for [problem]"
"Generate fishbone diagram for [defect type]"
# Corrective action development
"Recommend corrective actions for [root cause]"
# 8D review
"Review this 8D for completeness"
ワークフローの振り分け
| 入力/トリガー | ワークフロー | 出力 |
|---|---|---|
| "Create 8D for..." / "Customer complaint about..." | D0~D8 の完全なレポート生成 | 9フェーズすべてを含む完全な8Dレポート |
| "5-Why for..." / "Root cause analysis for..." | D4 根本原因分析のみ | 検証済みの根本原因を含む5-Whyチェーン |
| "Fishbone for..." / "Ishikawa for..." | フィッシュボーン図(6M) | テキスト形式の特性要因図 |
| "Containment for..." / "ICA for..." | D3 封じ込めのみ | 封じ込めアクションプラン + 流出ポイント |
| "Corrective actions for..." / "Fix for root cause..." | D5 是正処置の策定 | 担当者/日付付きの優先順位リスト |
| "Review this 8D..." / "Check 8D quality..." | 8D品質監査 | AIAG基準に対するギャップ一覧 |
| "8D number / format / template" | テンプレートの提供 | 8D空白テンプレートまたはMNMUK形式 |
例
例1 — 顧客からの苦情に対する8D全体:
"Create an 8D for customer complaint: supplier received 50 damper assemblies with incorrect gas charge pressure — 85 bar actual vs 110 bar spec. Customer is Multimatic, complaint received 2026-03-20."
Kaiは、ERA、チーム、IS/IS NOT分析、封じ込め処置、5-Why根本原因、是正処置、完了基準を含む、D0~D8の完全なレポートを1つの簡潔な回答で生成します。
例2 — 根本原因分析のみ:
"Help me do a 5-Why analysis: CNC lathe produced 30 parts with OD oversize by 0.08mm — tool offset not applied after tool change."
Kaiは、症状から手順/トレーニング上の根本原因に至る5-Whyチェーンを作成し、発生原因と検出原因の両方を特定します。
例3 — 是正処置の策定:
"Our 8D root cause is: no documented procedure requires the operator to verify tool offset after an unplanned tool change. Recommend corrective actions."
Kaiは、SMART基準、担当者、FMEA/コントロールプランの更新要件とともに、優先順位を付けた是正処置の階層(排除 → ポカヨケ → 手順 → トレーニング)を提示します。