# 工程FMEAとQC工程表をAIで最新に保つ方法

> Source: https://netray.co/ja/process-fmea-qc-koteihyo-ai
> Language: ja
> Publisher: Netray (netray.co)

工程FMEAとQC工程表は、作った時点では整合していても、設計変更、工程変更、不具合の発生で少しずつ食い違っていきます。AIは、不具合実績や変更履歴を読み、FMEAの故障モードや管理項目の見直し候補を挙げる補助役として有効です。ただし、リスク評価の最終判断は品質保証の担当者が行います。

自動車部品をはじめ、IATF 16949 の対応を求められる工場では、工程FMEA、QC工程表(コントロールプラン)、作業標準書の三点が揃っていることが監査の前提になります。現実には、工程が変わるたびに三つを手作業で直す必要があり、改訂が遅れた結果、監査で不整合を指摘されたり、過去に起きた不具合の対策がFMEAに戻っていなかったりします。

本ページは、既存の生産管理システムや品質記録を残したまま、生成AIで工程FMEAとQC工程表の見直しを支援する方法をまとめたものです。FMEAの様式や評価基準そのものを置き換える話ではなく、見直しの抜け漏れを減らし、根拠を探す時間を短くする話として読んでください。

## 工程FMEAとQC工程表が古くなる典型的な理由

工程FMEAは、新製品の立ち上げ時に時間をかけて作られ、その後は顧客クレームや監査のタイミングでしか見直されないことが多くあります。一方で、現場では治具の変更、作業順序の入れ替え、検査設備の更新、材料メーカーの切り替えなどが日常的に起きています。変更管理の記録は変更申請書や設計変更通知にあり、FMEAのExcelとは別の場所に保管されているため、両者を突き合わせる作業が後回しになります。

QC工程表も同様です。工程名、管理項目、管理方法、測定方法、サンプリング頻度、反応計画が表になっていますが、その根拠となる故障モードはFMEA側にあり、番号で対応付けていない会社では、どの管理項目がどのリスクに対応しているのか追えなくなります。

- 変更申請と工程FMEAの改訂が別の担当者・別の保管場所になっている
- 不具合報告書の再発防止策が、FMEAの検出度や管理方法に反映されていない
- FMEAの故障モードとQC工程表の管理項目に共通の番号がない
- AIAG・VDA版FMEAへの移行で、旧様式のRPNと新様式の行動優先度(AP)が混在している

## AIに任せられる作業と任せてはいけない作業

任せやすいのは、文章を読んで突き合わせる作業です。たとえば、過去三年分の不具合報告書と工程FMEAの故障モードを照合し、「この不具合に対応する行がFMEAに見当たらない」という候補を一覧にする。変更申請書の内容から、影響を受けそうな工程とQC工程表の行を挙げる。FMEAの故障モードの表現ゆれ(「かじり」「かみ込み」「焼付き」など)をそろえる。これらは担当者が確認する前提の下書き作業です。

任せてはいけないのは、厳しさ、発生度、検出度の点数付けや、行動優先度の最終決定です。これらは製品の安全に関わる判断であり、顧客要求や社内基準に基づいて、FMEAチームが責任を持って決める必要があります。AIには、判断の根拠になりそうな過去事例と出典の候補を示させ、採否は人が決める形にします。

## データの流れと構成の例

入力となるのは、工程FMEAとQC工程表(Excelや品質管理システム)、不具合報告書、変更申請、検査実績、そして生産管理システム上の工程マスタと品目マスタです。これらを社内に置いたまま、検索用の索引を作り、社内のGPUサーバーまたは国内のプライベートクラウドで動くオープンウェイトのモデルから参照できるようにします。モデルの実行にvLLMやOllamaを使う構成が一般的です。

回答には、必ず参照した文書名、版数、行番号を付けます。FMEAやQC工程表への書き込みはAIから直接行わず、修正案を差分として出力し、品質保証の担当者が承認してから反映します。ERP側の工程マスタは、読み取りのみを既定とします。

- FMEA行と不具合報告書を故障モードで突き合わせた未対応リスト
- 変更申請ごとの影響工程・影響管理項目の候補
- QC工程表の管理項目に紐づくFMEA行の対応表(番号付け)の下書き
- 用語ゆれの統一案(承認後に反映)

## 社外秘と顧客要求への対応

FMEAや工程表には、製造ノウハウと顧客の図面情報が含まれます。顧客との秘密保持契約や、不正競争防止法上の営業秘密としての管理を考えると、外部の汎用クラウドAIにそのまま貼り付ける運用は避けるべきです。社内または管理下のプライベート環境で動かし、閲覧権限を文書ごとの既存の権限に合わせることが前提になります。

なお、Netrayが特定の認証や登録を取得しているという意味ではありません。構成の設計により、お客様側で自社のルールや顧客要求を満たしやすくなる、という位置づけです。

## 進め方と、AIが向かない場合

最初は一つの製品ラインを選び、直近の不具合報告書とそのラインの工程FMEAだけで試すのが現実的です。二、三週間で「未対応の不具合候補」がどの程度拾えるか、担当者が見て有用と感じる割合を確認します。有用性が低ければ、データの整備(故障モードの表記、番号付け)を先に行ったほうが早い場合もあります。

FMEAの点数が少なく、変更も少ない小規模な工場や、すでに専用の品質管理パッケージが関連付けと通知を備えている場合は、AIを追加しても効果が小さい可能性があります。その場合は、既存ツールの設定を整える方が先です。

## FAQ

### AIにFMEAの発生度や検出度の点数を付けさせてもよいですか。

点数付けは、製品の安全と顧客要求に関わる判断なので、FMEAチームが決めるべきです。AIには、過去の不具合事例や根拠となる記録を探させ、候補として示す使い方にとどめることをお勧めします。

### AIAG・VDA版のFMEAに移行中ですが、旧様式の資料も扱えますか。

文書として読み取ることは可能です。ただし、RPNと行動優先度(AP)は考え方が異なるため、自動で変換せず、様式ごとに扱いを分けて、移行は担当者が確認しながら進める形が安全です。

### FMEAやQC工程表がExcelの場合でも使えますか。

使えます。ただし、セルの結合や表記ゆれが多いと読み取り精度が下がります。最初に故障モードの表記と行番号の付け方を整えると、突き合わせの精度が上がります。

### AIが修正案を直接Excelに書き込みますか。

いいえ。修正は差分の提案として出力し、品質保証の担当者が承認してから反映する運用を既定とします。書き込みの履歴も残せます。

### データを社外に出さずに運用できますか。

できます。オープンウェイトのモデルを社内のGPUサーバーまたは管理下のプライベート環境で動かし、文書も社内に置いたまま検索する構成が可能です。