コード体系が精度の上限を決める
不良コードと停止理由コードは、品質AIや稼働分析AIにとっての「正解ラベル」です。センサの時系列をいくら細かく取っても、ラベルが「その他」や「調整」のような曖昧な分類なら、モデルはその曖昧さ以上の区別を学べません。つまり、コード体系の粒度がAIの精度の上限を決めます。
現場でよく見るのは、次のような状態です。
- 停止理由の上位が「その他」「段取り」「調整」で、合計が半分を超える
- 不良コードに現象（キズ・打痕）と原因（材料不良・設備不良）が混在している
- 工場や班ごとに独自コードがあり、同じ現象に別の番号が付いている
- コードが100種類以上あり、作業者が覚えきれずに上の方の選択肢を選ぶ
これらは入力する人の怠慢ではなく、体系と入力方法の設計の問題です。
6つの原則
- 現象と原因を分ける：「キズ」は現象、「搬送接触」は原因です。1つのコードに両方を詰めると、原因が分からない不良の入れ場所がなくなり「その他」に流れます。現象は検査時に確定し、原因は解析後に別の項目として入れます。AIにとっては、現象が正解ラベル、原因は要因分析の検証用データになります。
- 2階層にして1画面の選択肢を絞る：大分類5〜8個、小分類は各大分類の下に5〜10個程度が、作業者が迷わず選べる目安です（編集部の経験による目安）。100個のフラットなリストより、2回のタップで選ぶ方が入力の揺れが減ります。
- 「その他」に上限を設ける：「その他」を残す場合は、自由記述を必須にし、比率を毎月確認します。比率が一定（たとえば5%）を超えたら、自由記述を読んで新しいコードを作るか既存コードの定義を直します。
- 定義と判定例を書く：各コードに定義文と、境界例（このキズは「打痕」か「キズ」か）の写真を付けます。外観検査では限度見本と同じ考え方です。定義がないコードは、人によって使い方が変わります。
- 停止理由は自動取得と人の入力を組み合わせる：設備が出すアラームコード（自動）と、作業者が選ぶ停止理由（人）を別の項目として持ちます。アラームは「何が起きたか」、人の入力は「なぜ止めたか」を表し、両方あると突発停止と計画停止、チョコ停の区別が付けられます。停止の粒度についてはOEEデータをAIで深掘りするで詳しく扱います。
- 全工場で共通の上位体系を持つ：工場ごとの独自コードは小分類として残してよいので、大分類だけは全社共通にします。共通の大分類があれば、工場横断の比較やモデルの横展開ができます。
入力UIとタイミングが体系と同じくらい効く
コード体系を作り直しても、入力の仕方が変わらなければ記録は良くなりません。効くのは次の3点です。
| 項目 | 悪い例 | 改善例 |
|---|---|---|
| 入力のタイミング | シフト終わりにまとめて日報へ記入 | 停止の再開時、不良の発見時にその場で入力 |
| 入力の手段 | 紙の日報、プルダウン100項目 | タブレットのアイコン選択、部位は図をタップ |
| 必須の範囲 | 停止理由が空欄でも再開できる | 一定時間以上の停止は理由を選ばないと再開できない（MES・HMI側で制御） |
最後の「入力しないと再開できない」制御は効果が大きい一方、ラインを止める理由になるため、対象とする停止時間の閾値は現場と合意して決めます。閾値以下の短い停止はアラームコードと稼働ログから自動で分類し、人の入力は求めない設計が現実的です。
AIで使うときの確認ポイント
コードを作り直したら、AIに使う前に次を確認します。
- 各コードの件数：学習に使うクラスが十分な件数を持つか。件数がごく少ないコードは、学習では上位の大分類にまとめる
- 入力者間の一致：同じ不良を複数の検査員に分類してもらい、一致率を測る。一致しないコードの組は定義を見直す。ラベルの揺れの管理は製造AIの正解ラベルで扱う
- 時刻とロットの紐付け：不良や停止の記録が、発生時刻・設備・ロットと結びついているか
よくある質問
不良コードはいくつくらいが適切ですか？
数そのものより、1画面の選択肢の数と、各コードに定義と境界例があるかが重要です。2階層で、1画面あたり10個程度に収まる構成が入力の揺れを抑えやすい目安です。
コードを変えると過去データとの比較ができなくなりませんか？
対応表で旧コードを新コードに読み替えれば、大分類レベルの比較は続けられます。小分類まで1対1に対応しない部分は、比較の対象外と割り切ります。改定日はマスタの有効期間として記録しておきます。
MESがなくても改善できますか？
できます。紙の日報でも、コード表を2階層にし、定義と境界例を付けるだけで記録の質は上がります。ただし、入力時点で必須にする制御や、アラームとの自動突き合わせはシステムがないと難しくなります。
AIは「データ基盤」で決まる
PoCは成功したのに本番で止まる。原因の多くはモデルではなく、MESと設備データの側にある 全130本
- MESとAIの関係：ロット・作業指示・品質判定がAIの精度を決める理由
- 製造業AIが本番で止まる7つの理由：PoCは成功したのにラインに載らない構造
- 製造業のAI-OCR：紙の検査記録・点検表・ミルシートをデータ化する手順
- データ基盤の段階的導入ロードマップ：ユースケースから逆算する8ステップ
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成と、製造業向けAIの調査・開発・教育を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES・データ基盤・AI導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
