是正処置が同じ不具合を繰り返す構造——品質保証の「水平展開」が形骸化する理由とAIで補える範囲
量産品質の現場では、是正処置（CAPA）を一件きちんと起票し、なぜなぜ分析も対策の打ち込みも正しく終えたはずなのに、数か月後に別ラインや別工場で「同じ不具合」が顔を出すことがあります。水平展開（横展開）の指示は出した。それでも射程の遠い工程までは届かず、最後は市場品質のクレームとして跳ね返ってくる——品質保証部のこの徒労感は、担当者の注意不足ではなく、是正処置という業務フローそのものの構造に根があります。
本記事では、是正処置の水平展開がなぜ形骸化するのかを「人・プロセス・情報・ツール」の四つに分解し、AIエージェントに任せてよい範囲と、品質保証の担当者が握り続けるべき判断の線引きを示します。読み終えたとき、自社の再発防止のどこに穴が空いているかを、業務の言葉で説明できる状態を目指します。
是正処置の一日と、水平展開が止まる場所
品質保証部の一日は、不具合情報の受信から始まります。製造ラインからの工程内不良、出荷検査（IQA）での検出、取引先からの受入監査（SQA）の指摘、そして市場品質のクレーム解析。これらを是正処置票として起票し、なぜなぜ分析で真因に降りていき、4M変更（人・機械・材料・方法）のどこに起因するかを切り分け、対策を決定します。工程能力指数の悪化を伴う案件であれば、暫定対策と恒久対策を分けて管理することもあります。ここまでは多くの組織で機能しています。問題は、その次の「水平展開」の工程で起きます。
水平展開とは、ある工程で見つかった不具合の対策を、同じ条件を持つ他の工程・製品・拠点にも先回りで適用する活動です。ところが現実には、この指示は朝礼での口頭連絡、対策会議の議事録、関係部署へのメール、拠点間のFAXといった属人的な連絡手段に依存しています。起票部署のなかでは対策が完結しても、「同じ4M条件を持つ工程がどこにいくつあるのか」という地図を誰も持っていないため、射程が遠い工程ほど指示が届かなくなります。
この「届かなさ」は感覚論ではありません。同じ不具合に対する対策が、実際にどこまでの工程に反映されたかを追跡すると、起票元のライン内ではほぼ徹底される一方、別工場の同系列製品や設計・FMEAへのフィードバックまで到達する割合は大きく落ち込みます。下図は、その減衰を典型的なパターンとして表したものです。
整理すると、水平展開が形骸化する原因は四つに分けられます。人：対策の妥当性は判断できても、横展開先を網羅的に洗い出す時間が担当者にない。プロセス：是正処置の起票から横展開までが一本のフローでつながらず、横展開が「やれたらやる」付帯作業になっている。情報：不具合が4M・工程・部品といった属性で構造化されておらず、類似工程を機械的に引き当てられない。ツール：是正処置台帳がExcelや紙のQMSに分断され、検索も突合も人手頼みになっている。このうち、人が担うべきは対策の質の判断であり、残りの三つの多くは情報の構造化で解ける性質のものです。
「対策を配る作業」と「対策を決める判断」を分ける
ここで必要なのは、是正処置を支える業務基盤——本サイトで業務OS（ここでは品質OS）と呼んでいる考え方です。要点は、不具合を起票した瞬間に、その不具合を「どの工程の・どの4M条件で・どの部品に・どんな現象として」起きたかという属性の集合として構造化することにあります。属性として持っていれば、同じ条件を共有する工程をシステム側が機械的に抽出でき、横展開の射程を人の記憶力に頼らずに広げられます。
具体的な業務シナリオで考えます。ある量産ラインで、特定ロットの樹脂成形品にヒケ（収縮による外観不良）が発生したとします。従来であれば、起票部署が対策を決め、横展開は「似た成形条件のラインにも一応共有」という温度感で止まりがちでした。構造化された基盤の上では、同じ材料グレード・同じ型温度帯・同じ肉厚条件を持つ工程が自動で一覧化され、各工程の担当者に「この点検項目を確認してほしい」という形で対策と点検リストが配信されます。担当者は配信された対策が自工程に本当に当てはまるかだけを判断すればよく、探す作業はエージェントが肩代わりします。
この発想は、品質保証だけで完結する話ではありません。是正処置が本当に効くのは、市場品質で見つかった失敗が設計のFMEAにまで戻り、次の設計で同じ失敗モードを最初から潰せたときです。本サイトの品質OSの解説でも、この分断の危うさを次のように指摘しています。
FMEA・是正処置・市場品質を分断したまま運用すると、設計起因の不具合は半年から1年遅れて設計に戻り、その間に同じ系列の不具合が複数の量産品で再生産されてしまう
品質OSとは——FMEA・是正処置・市場品質を一気通貫させる構造
なぜ既存の仕組みではこれが起きにくかったのか。理由は、これまで現場に入っていたシステムの多くが「記録」を目的に設計されていたからです。業務そのものを動かす基盤という観点は、従来のERPやPLMの延長線上には置かれていませんでした。この違いは、業務OSの基礎を解説した記事で次のように述べられています。
ERPは『お金とモノの記録台帳』、PLMは『図面とBOMの保管庫』であって、業務そのものを実行する仕組みではない
業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体
是正処置の水平展開も同じ構図です。台帳に「記録」されることと、対策が他工程で「実行」されることの間には深い溝があり、その溝を埋める作業がこれまで人手に丸投げされてきました。どこまでを人が握り、どこからをエージェントに任せるべきか。対策の質を決める判断は人に残し、配信・追跡・突合といった定型作業を機械に渡すという線引きを、業務単位で整理したものが次の表です。
| 是正処置の作業 | 人（品質保証）が握る判断 | エージェントに任せる定型 |
|---|---|---|
| 真因の特定 | なぜなぜ分析の打ち止め判断・4M切り分けの妥当性 | 過去の類似不具合・是正処置票の検索と提示 |
| 対策の決定 | 恒久対策の有効性とコストの判断 | 同種不具合に対する過去対策の候補出し |
| 水平展開先の特定 | 展開対象に含める／除外する最終判断 | 同一4M条件を持つ類似工程の自動抽出 |
| 横展開の配信 | — | 該当工程への対策・点検項目の自動配信 |
| 実施状況の追跡 | 未実施工程への督促要否の判断 | 配信先の確認状況の集計と未完一覧の提示 |
| 設計・FMEAへの反映 | 故障モードへの反映可否の技術判断 | 市場品質と設計FMEAの突合・差分の提示 |
注意したいのは、立ち上げ期と量産期では「何を再発防止の知見として残すか」が変わる点です。量産で安定してから見つかる不具合と、ライン立ち上げ時に作り込まれる不具合は、原因の層も対策の宛先も異なります。この期をまたいだ知見の連続性については、生産技術OSの解説が参考になります。
立ち上げ期と量産期では、現場の判断に必要な情報源がまったく違う。両期の文脈を同じ基盤に持たない限り、量産後の改善は立ち上げ判断の轍を踏まない理由を持てない
生産技術OSとは——立ち上げ・保全・改善を統合する業務基盤
ROIは「再発1件あたりの損失」で考える
投資判断を金額で語る前に、考え方の軸を揃えておきます。是正処置の水平展開を構造化する効果は、横展開作業そのものの工数削減ではなく、「同じ不具合の再発を一件減らすこと」で測るのが妥当です。再発が一件起きると、選別・手直し・特別採用の手続き、顧客への報告、場合によっては市場回収まで、起票一件の対策コストとは桁の違う損失が発生します。水平展開の射程を遠い工程まで広げられれば、この再発を未然に止められる確率が上がります。したがってROIは「横展開にかかる時間が何分縮んだか」ではなく、「再発による損失が年間で何件分回避できたか」で見積もると、現場の実感と一致します。
「ChatGPTで足りるのでは」への答え
汎用の生成AIを使えば、是正処置票の文章整形やなぜなぜ分析の壁打ちはたしかに楽になります。実際、対策案のたたき台づくりやクレーム文面の要約には十分役立ちます。では、それで水平展開の問題まで解けるのか。ここは正直に切り分けるべきところです。
汎用ツールが苦手なのは、「自社の工程台帳・4M条件・部品構成と紐づいた状態で、同一条件の工程を漏れなく引き当てる」作業です。これは対話の上手さではなく、自社データが構造化され、業務フローの中に組み込まれているかどうかで決まります。逆に言えば、ChatGPTのような汎用ツールで十分なケースもあります。工程数が少なく、横展開先が一目で見渡せる小さな組織や、単発の文章作成が主目的の場合です。一方、拠点をまたいで同系列の製品を複数ラインで作っており、横展開の抜けが市場品質に直結している組織では、対話型ツールの外側にある「構造化と配信の仕組み」が要になります。自社がどちらに当てはまるかを見極めることが、ツール選定の出発点です。
自己診断：水平展開が形骸化していないか
次の5項目のうち、3つ以上に「いいえ」がつく場合、是正処置の水平展開が属人連絡に依存している可能性が高い状態です。
- 是正処置票に、不具合の4M条件・工程・部品が検索可能な属性として記録されているか
- ある不具合の対策を、同一条件を持つ全工程に対して「漏れなく」展開した記録が残っているか
- 横展開の指示が、口頭・メール・FAXではなく追跡可能な形で配信されているか
- 市場品質のクレームが、設計のFMEAに戻った件数を月次で把握できているか
- 別拠点・別ラインでの「同じ不具合の再発」を、件数として定点観測できているか
次のアクション
まずは、直近1年の是正処置票から「再発したもの」だけを抜き出し、その横展開がどの射程で止まっていたかを一度たどってみてください。自社のどの工程間で対策が届いていないかが見えれば、構造化すべき属性の優先順位が決まります。その作業を一緒に進めたい場合は、貴社の是正処置フローを業務分解の観点から点検する30分の業務診断を無料で提供しています。
よくある質問（FAQ）
是正処置の水平展開を仕組み化するのに、まず何から始めればよいですか。
過去1年で再発した是正処置票を抜き出し、不具合を4M・工程・部品の属性に分解して棚卸しすることから始めます。再発が起きた工程間の関係が見えれば、最初に構造化すべき属性が特定できます。全社一斉ではなく、再発損失の大きい製品系列から着手するのが現実的です。
既存のQMSや是正処置台帳を捨てる必要がありますか。
捨てる必要はありません。重要なのは、台帳に蓄積された不具合情報を検索・突合できる属性として持ち直し、横展開の配信と追跡を業務フローに組み込むことです。既存の記録資産を構造化の入力として活かす形が、移行のコストも品質も両立しやすい進め方です。
AIが横展開先を抽出すると、対策の責任の所在が曖昧になりませんか。
抽出はあくまで候補出しであり、展開対象に含めるか除外するかの最終判断は品質保証の担当者が握ります。責任の所在は人の側に残したまま、探す・配る・追う作業だけを機械に渡すのが基本設計です。判断のログが残ることで、むしろ「なぜその工程を対象にした／しなかったか」が後から説明できるようになります。
効果が見え始めるまでどのくらいかかりますか。
横展開の配信と追跡を仕組みにすれば、未実施工程の可視化は導入直後から効きます。一方、「同じ不具合の再発が減った」という最終的な効果は、対象とした製品系列の量産サイクルに依存するため、数か月から半年の定点観測で評価するのが妥当です。再発件数を月次で観測する仕組みを最初に用意しておくことが、効果検証の前提になります。
次に読むべき記事
