AIが理解していない工場を最適化できない理由

機械が生産の途中で停止します。ERPは顧客の受注と納期を把握し、MESはどの工程が止まったかを把握し、保全部門は修理の進捗を把握し、機械レイヤーは障害コードと正確なタイムスタンプを把握しています。そこで誰もが当然の問いを投げかけます。「では、今どうすべきか?」

AIはアラームを要約し、過去の停止履歴からパターンを見つけ、何が起きた可能性が高いかを説明できます。しかし、どの製品が稼働していたのか、どの受注がその工程に依存しているのか、どの機械が承認済みの代替候補か、どの治具や工具が利用可能か、どのオペレーターが資格を持っているか、どの品質・工程ルールが適用されるかを理解していなければ、対応策を安全に最適化することはできません。
これは主にAIの問題ではなく、工場コンテキストの問題です。

データはコンテキストと同じではない
工場では already 大量のデータが生成されています。ERP、MES、保全、品質、ヒストリアン、PLC、IoTプラットフォーム、スプレッドシートには、いずれも有用な事実が蓄積されています。
問題は、それらの事実が互いにつながっていないことが多いという点です。機械の停止コードだけでは、その事象が生産中、段取り替え中、保全中、あるいは厳格な処理時間枠のあるバッチ中に起きたのかはわかりません。機械が待機中に見えても、必要な治具が使えない、あるいは資格を持つオペレーターがシフトに入っていないため、実際には使用できないこともあります。
コンテキストとは、事象をその周囲の稼働状況と結びつけるものです。

それには次のような要素が含まれます。

• 設備とリソースの識別情報
• 稼働中の工程と作業指示
• 製品と改訂版
• ルートと代替ルート
• 材料とバッチの状態
• 工具と治具
• スキルとシフトの人員配置
• 品質上の制限
• 保全の状態
• 生産能力と後工程への依存関係
• 顧客への約束

ダッシュボードでは不十分な理由
Power BIや稼働ダッシュボードは、何が変化したかを示すのに優れています。停止時間、増加する待ち行列、遅延受注、スクラップ、利用可能な生産能力などを可視化できます。

しかし、問題を示すことと、生産が次に何をすべきかを決めることは別物です。
ダッシュボードは、別の機械が空いていることを示すかもしれません。しかし、その機械が現在の製品改訂版に承認されているか、治具がすでに別の作業に予約されていないか、移送に品質部門の承認が必要か、作業を移すことで後工程に新たなボトルネックが生じないかは、自動的にはわかりません。

レポートに何十もの特殊ケースの計算が含まれ、計画担当者が代替案を検証するために結果をExcelにエクスポートし続けているなら、欠けているのは通常、さらなる可視化ではありません。その判断の背後にある工場ルールの明示的なモデルです。

予測は最適化ではない
予測は、ある機械が故障しやすいことや、ある受注が遅延する確率が高いことを示せます。
それは有用ですが、何をすべきかは教えてくれません。
最適化は別の役割を担います。可能な行動を、工場のルールと制約に照らして評価するのです。

たとえば機械故障後、最適化エンジンは、影響を受けた作業を元のリソースに残すか、承認済みの代替機械に移すか、順序を変えるか、残業を使うかを検証するかもしれません。
実行可能な計画は、実際の条件を尊重しなければなりません。
安全限界、工程承認、材料適合性、オペレーターの資格、工具、品質制限、保全時間帯、順序ルールは、別の機械が空いているように見えたからといって消えるものではありません。

AI、最適化、ルールは異なる役割を持つ
生成AIは、計画担当者が状況を理解し、関連情報を検索し、代替案を比較し、トレードオフを説明し、有用な引き継ぎ資料を作成するのを支援できます。
予測モデルはリスクを見積もれます。
最適化エンジンは実行可能なスケジュールを探索できます。
決定論的なルールは、提案された行動が既知の生産条件を満たしていることを検証できます。
これらの要素は連携できますが、混同すべきではありません。
言語モデルは説得力のある説明を生成できます。しかし、それは生産計画が実行可能であることを証明するものではありません。

製品、工程、リソース
有用な工場モデルは、製品、工程、リソースから始まります。
製品とは、何を生産するのかを表します。改訂版、材料、バッチ規則、顧客固有の要件を含みます。

工程とは、それを製造するために必要な作業、順序、段取り条件、検査、代替経路、ルールを表します。

リソースとは、その作業を実行できるものを表します。機械、工具、治具、炉、試験装置、搬送装置、人員などが含まれます。
重要なのは、それらの間の関係です。

問うべきことは次のことではありません。
「どの機械が空いているか?」

有用な問いは次のとおりです。
「この正確な製品と受注について、承認された工程、工具、材料、品質、人員配置、タイミングの条件のもとで、次に必要な工程を実行できる利用可能なリソースはどれか?」

ナレッジグラフの現実的な活用
ナレッジグラフは、こうした工場内の関連性を表現する一つの方法を提供します。
機械、工程、受注、工具、材料を孤立したレコードとして保存するのではなく、グラフはそれらの間の関係も表現します。

機械は工程を実行できます。工程はルートに属します。ルートは製品改訂版に属します。作業指示はそのルートを必要とします。ある工程には治具が必要かもしれません。その治具は現在、別の作業に割り当てられているかもしれません。

こうすると、「なぜこの受注を機械7に移せないのか?」といった問いへの説明がはるかに容易になります。
答えは単に「実行不可能」であってはなりません。

機械7はその工程をサポートしているが、必要な治具が利用不可である、製品改訂版が未承認である、あるいは後工程の品質条件がそのルートをブロックしている、と説明すべきです。

デジタルツインには目的が必要
ライブダッシュボードは、自動的にデジタルツインになるわけではありません。
有用なツインは、物理的な工程の定義された部分を表し、特定の目的のために構造、状態、ルール、元データを結びつけます。

設備ツインは保全の判断を支えるかもしれません。
ラインツインは流れやボトルネックの理解を助けるかもしれません。
生産システムのツインは、設備の状態を受注、ルート、材料、人員、品質ルール、納期の約束と結びつけるかもしれません。

重要な問いは「デジタルツインはあるか?」ではありません。
「このツインはどのユーザー、どの判断、どの時間枠を支えるのか?」です。

設備の識別情報は基盤
一つの物理的な機械は、複数の識別情報を持つことがあります。
保全部門は設備番号を使うかもしれません。MESは生産リソースを使います。ERPは作業場を使います。IoTレイヤーはコントローラーやタグパスを見ています。

これらの識別子は消す必要はありませんが、その関係は管理されなければなりません。
AIシステムが、似た名前の二つの機械が同一の物理設備を表すと推測してしまうと、基礎データが技術的にはきれいであっても、その後のすべての判断が誤る可能性があります。

したがって、設備のマッピングには、責任者、有効日、元データの参照、変更管理が必要です。

制約はデータの一部
ルートは技術的には可能でも、生産には受け入れられないことがあります。

ハード制約には次のようなものがあります。
• 安全限界
• 承認済みのレシピ
• 材料の適合性
• 機械の能力
• オペレーターの資格
• 品質リリース
• 工具の可用性
• 保全上の制限

その他の制約は絶対的な限界ではなく、トレードオフを表すものです。緊急の納品を守るために追加の段取り替えを受け入れることもあるでしょう。ある顧客の約束のためには残業を許可し、別の顧客のためには許可しないこともあるでしょう。

システムは、そうしたトレードオフを不透明な推奨の中に隠すのではなく、明示すべきです。

クリーンなデータは必要だが、十分ではない
正確なタイムスタンプ、完全なイベント、標準化された識別子、信頼できるインターフェースは不可欠です。

しかし、完全にきれいなテーブルであっても、「利用可能」「完了」「生産能力」が何を意味するのかは説明してくれません。
機械は機械的には利用可能でも、現在の工程に対しては利用不可であることがあります。P