工場でAIによる自動化が本当に見合うのはどこか

工場のAIプロジェクトの成否を決めるものの大半は、モデリングではありません。自分が抱えている課題がどの種類のものかを名指しすること、実行データがそれを支えられるか確かめること、そしてモデルが外れたときに何が起きるかを設計することです。

ルール、機械学習、最適化、言語モデル：どの課題にどれが合うのか

まずルールと統計であり、これらは実際に受けている評価より敬意に値します。技術者が書き下せるルールで価値の大半が取れるのなら、どんなモデルであれ公正な比較対象はそのルールであって、何もしないことではありません。

機械学習が真価を発揮するのは、入力と結果の関係が実在するのに誰もそれを書き下せない領域です。数十のプロセス変数が相互に作用する場合、材料ロット・周囲湿度・キャビティ内の位置に左右される不良などです。機械学習は見せられた条件については知っていますが、一度も見たことのない条件については何も有益なことを語りません。

最適化は別の学問分野であり、日常的にAIと誤ってラベル付けされています。有限能力での工場のスケジューリング、段取り替えを最小化する順序付け、有資格のオペレーターの割り当て。これらは目的関数を伴う制約問題です。ラベル付きの事例は要りませんが、正直な工程時間と制約は必要であり、それらはたいてい前提で済ませるのではなく実測しなければなりません。計画業務では、自社の実際の治工具制約や乾燥制約を表現できるソルバーがほぼ常に正しい道具です。計画は予測問題ではなく制約問題だからです。

言語モデルは最も新しい登場人物であり、その適所は限定的です。文書と会話のかたちをした仕事に向いています。引き合いを読んで構造化された回答を起案する、長大な保全履歴を技術者が機械へ歩いていく前に読める分量に凝縮する、作業手順書が段取りについて何と書いてあるかに答える、といった仕事です。言語モデルは計測器ではありません。振動データからベアリングの故障を予測させるのは、ねじにハンマーを使うようなものです。

工場のAIプロジェクトに実際に必要なデータ

モデルに必要なのは、状況と結果を対にした事例であり、ある状況を別の状況と区別できるだけの文脈を伴っている必要があります。すなわち、オーダー、設備、工具、材料ロット、オペレーター、そして真であるタイムスタンプに紐づいた信号または条件の組です。タイムスタンプは思われている以上に重要です。実績確認が直交替の終わりにまとめて入力されているなら、その直のすべてのイベントがおおよそ同じ時刻を共有することになり、順序や継続時間に依存するものはプロセスではなくデータ入力の習慣を学習します。

結果側はたいていもっとひどい状態です。予知保全には、原因と日付を伴って故障として記録された故障が必要であり、理由欄が空白の計画外停止では役に立ちません。品質予測には、月次の数字に集計されたものではなく、工程と、それを引き起こした不良モードに紐づけて計上された不良が必要です。需要予測には、在庫調整によって黙って書き換えられていない消費履歴が必要です。多くの工場では、入力はヒストリアンの中にあり、結果は保全のノートか誰か一人の表計算の中にあります。

問われるのは、ヒストリアンが何ギガバイト抱えているかではなく、一つのラインと一つの製品群について、各行が条件と結果を持つ一年分の行を取り出せるか、そしてプロセスを知る二人がその行は真だと同意するか、です。その抽出に手作業の突合で一週間かかるなら、プロジェクトはモデルではなく記録のほうです。だからこそMESとヒストリアンのデータ品質が律速の制約であり、どれほど高度なモデリングでも、そもそも取得されなかったものを取り戻すことはできません。

需要と消費の予測、投資回収が最も近いところ

需要予測はたいてい金銭的効果への道のりが最も短い領域です。比較対象が目に見えて弱いからです。多くの工場は昨年の実績に何パーセントか足すか、営業に数字を聞いて、それが実は目標値だったりします。受注履歴、季節性、顧客構成、進行中の案件、カレンダー効果を使うモデルは、需要が規則的に繰り返される品目ではそれを上回ります。断続需要や案件駆動の品目、つまり品番数では多数を占めるのに数量ではわずかな割合の品目では、たいてい上回らず、ナイーブ予測やクロストン法のベースラインを超えるのは困難です。誠実なやり方は、まず品目をセグメント分けし、そうした品目は在庫方針と人の判断に委ねることです。

価値は予測そのものではなく、その下流に現れます。安全在庫が動き、長納期品の発注タイミングが変わり、スケジュールを壊す緊急の段取り替えが減ります。スライドに載る予測精度のパーセンテージは便益ではありません。在庫日数と特急対応の件数が便益です。

予知保全は、故障モードが本当に予測可能なところだけで

ここではすべてが、故障が徐々に進行し、測定できる何かに兆候を残すかどうかにかかっています。ベアリングの劣化、アンバランス、ミスアライメント、フィルターや冷却回路の目詰まりの進行、油圧圧力のドリフト、同じ加工でモーター電流が少しずつ上がっていくこと。これらは数週間から数か月かけて進行し、まれに数時間ということもありますが、その場合はたいてい計装する価値が出る前に手遅れです。そして振動、電流、温度、圧力に現れます。モデルはそれを捉えられますし、よく選ばれたしきい値でも捉えられることが多く、だからこそここでは単純な統計との比較が重要になります。

制御基板の突然死、不良チップによる工具の折損、オペレーターのミスによる損傷。これらは事実上瞬時であり、存在しないトレンドからそれを予測できるモデルはありません。

二つ目の条件は、その予兆が使える時間を稼いでくれることです。部品の納期が長く、週末までラインを止められないなら、投資すべきは予備品の方針であって、モデルではありません。センサーの予算を組む前に介入可能な時間の幅を見積もってください。

品質予測と不良削減

品質はたいてい最も大きな金額が眠っている領域であり、同時にデータ要件が最も厳しい領域です。魅力的なやり方は、加工中の条件からどの部品やバッチが危ないかを予測し、最終検査で見つけるのではなく不良が作られる前に誰かが調整できるようにするというものです。

これが機能するのは、予測したい対象の粒度でプロセスが計装されていて、かつ不良が工程に対して実のある原因コードを伴って計上されているときです。逆に静かに失敗するのは、不良がオーダー終了時にオーダー全体に対して計上されているときです。その場合モデルは、どの条件がどの不良を生んだのかを区別できません。

どんなモデルよりも先に元が取れる、地味な一手があります。不良の理由を、その場で、機械のそばで、オペレーターが見て分かる短い原因リストから記録することです。品質予測を求めてきた工場の多くは、そのデータだけから、少数の原因が損失の大半を占めていることを知り、最大のものを設計変更で潰します。それは失敗したプロジェクトではなく、よい成果です。

生産スケジューリングのAI：なぜ予測ではなく最適化の問題なのか

計画が毎週崩れるなら、原因が知能の不足であることはまれで、たいていは制約の不足です。それを変えるのは、共用治工具、段取り替えのファミリー、オペレーターの資格、養生時間、そして守るつもりでいる保全枠を尊重するスケジューラーです。

ここで学習が効くのは、一つの狭い、しかし現実的な形です。工程時間です。何年も誰も測り直していない標準時間の上に組まれたスケジュールは、間違った数字について精密であり、MESを通じて取得した実際の所要時間はスケジューラーが計画に使う値を更新できます。スケジューリングの提案は、表現できる制約と、何かが壊れたときの再計画の速さで評価してください。再生成に一晩かかる計画は、朝の会議で手作業で覆されます。

エネルギーとプロセス信号の異常検知

異常検知は正常がどう見えるかを学習し、そこからの逸脱を知らせます。良好な挙動のデータは大量にあるがラベル付きの異常は少ない連続信号に向いています。サイクルあたりの電力消費、圧縮エアの消費、チラーの性能、調子がよいときには波形が安定しているプロセス信号などです。

その強みは、誰も想定していなかったことに反応できる点です。弱みは、何かが普通でないとしか言わず、何が悪いのかは決して言わない点であり、説明のつかないアラートを受け取り続ける工場はそれを無視することを学びます。設計すべき仕事は検知器ではなく振り分けです。どのアラートを誰に出すのか、最初に確認することは何か、そして同じ形の次のアラートが履歴を伴って届くように対応をどう記録するか、です。

営業と顧客対応のAI、仕事が文書のかたちをしているところ

製造業の商売側は文書と会話で回っています。引き合い、仕様、見積、注文請書、納期の問い合わせ、クレーム。ここは言語モデルが本当に合う領域です。仕事が読む、抜き出す、起案する、要約するだからです。

具体的には、受信した引き合いを品目、数量、希望日、特記事項に分解し、過去の見積を横に並べる。メールのやり取りを、約束した内容と次のアクションを持つCRMの記録に凝縮する。

これが破綻しないための二つの原則があります。第一に、モデルは起案し、送信するのは人であること。少なくともそのワークフローでの誤り率が把握できるまでは。第二に、価格、リードタイム、在庫、確約納期といった事実に関わるものはすべて、モデルではなく記録システムから取ること。モデルは参照した値を引用すべきであって、決して生成してはなりません。リードタイムをでっち上げるCRM自動化は、自動化なしより悪いのです。会社を拘束してしまうからです。

何かを買う前に効果の大きさを見積もる

損失を、自社の工場がすでに管理している単位で名指ししてください。対象製品群の月あたり不良費用、ボトルネック設備の計画外停止時間に、その一時間が設備レートではなく限界利益でいくらに相当するかを掛けた額、特急便の運賃、需要予測で動かせる部品に寝ている在庫、システム間の再入力に週あたり費やしている時間。

次に、その損失のうちどれだけをそのアプリケーションが現実的に扱えるかを、悲観的に見積もります。予知保全は停止をなくしません。せいぜい、カバーする故障モードについて、計画外の停止の一部を計画停止に変えるだけです。品質モデルは不良をなくしません。プロセスが狂ってから誰かが気づくまでの時間を短くするだけです。

その誠実な数字を、実際に計画するであろう使用年数にわたる総コスト、すなわち統合費用と運用する人の分も含めた総額と突き合わせ、同規模の他の投資に財務部門が適用するハードルを越えないなら、そのプロジェクトは科学実験です。それは許されますが、科学実験として予算化され、科学実験として評価されるべきです。

統合の本当のコスト

モデルはたいてい安い部分であり、コストは継ぎ目に宿ります。まず機械から信号を取り出すことであり、実在する工場は混成の設備群です。OPC UAを話す資産もあれば、Modbusやシリアルプロトコルのものもあり、ドライ接点しかないものもあり、閉じたコントローラーの設備ではスピンドル、油圧回路、電源ラインに後付けセンサーが要ります。次に、その出力は行動を引き起こす場所に着地しなければなりません。オペレーターがすでに見ている画面、保全で発行される作業指図、スケジューラーに渡される制約、品質で掛けられる出荷保留です。

その後に、誰も見積もりに入れないマスターデータの整合作業が来ます。システム間で接尾辞が違う品番、一致しない単位、二か所で維持されている部品表、ライン変更のときに変わった設備ID。どれも難しくはなく、どれもソフトウェアより時間がかかります。モデルには値段を付け、継ぎ目は「別途要スコープの統合作業」として残す提案書は、値段ではありません。

誰がモデルを運用し、外れたときに何が起きるのか

本番で動くモデルにはすべて、名前のある所有者が必要であり、調達で問うべきは自社の誰がそれになるのかです。その人は、何で学習したのか、どの条件がその範囲外なのか、なぜその出力になったのか、そして生産を止めずにどうやってループから外すのかを知っている必要があります。応答しなくなったモデルは、それ以前にプロセスを律していたもの、すなわち抜取検査計画、しきい値、オペレーターの確認に戻らなければならず、素通りにも全面停止にもなってはいけません。そのどちらなのかを本稼働前に決めてください。

説明可能性は現場では哲学的な関心事ではなく、定着のための要件です。どの信号がどれだけ、どの基準に対して動いたかを言う推奨は、実行されます。根拠のないスコアは覆され、覆すことが日常になった時点で、そのシステムは飾りです。

過剰なアラートは、検知漏れよりも速く信頼を壊します。検査装置での過検出が同じ理由でそうであるように、誤報はただちに全員に見えるのに対し、見逃しは故障が来るまで見えないままだからです。アラートの発生頻度は、現場に実際に割ける注意の量に合わせて設計し、判断の微妙な帯域は人に回して、ラインには回さないでください。

ガバナンス、ドリフト、そして誰も予算化しない維持の負担

モデルは学習した瞬間のプロセスのスナップショットであり、プロセスは動きます。新しいサプライヤー、工具のオーバーホール、部品の改訂、ラインの再配置、製品構成の変化、わずかに仕様の違うセンサーへの交換。どれもが入力を十分に動かし、昨日のモデルが今日は静かに間違っている状態を作り得ます。しかもその壊れ方はエラーメッセージではなく、じわじわ悪くなる助言です。

出力だけでなく入力も監視してください。入力のドリフトは結果の劣化より先に現れるからです。実際の事例を、判断の際どいものも含めて、手元に取り置いたテストセットとして保持し、新しいモデルを現行モデルと公正に比較できるようにします。モデルにバージョンを付け、どのバージョンがどの推奨を出したかを記録してください。再学習の後では、昨日の出力は別の判定者が出したものです。

そして継続的な工数を予算化してください。本番で動くモデルは維持される資産であり、買い切りのレポートよりも生産設備に近いものです。再学習、アラートのレビュー、データが今も届いているかの確認に時間が割り当てられていなければ、人が使うのをやめるまで劣化していきます。

現実的な最初のプロジェクトと、その受入基準

一つのラインまたは一つの製品群で、名前の付いた損失を一つ選び、数字の入った一文で述べてください。この工程でこれだけ不良を出している、この設備のせいでボトルネック時間をこれだけ失っている、この製品群を予測できないのでこれだけ在庫を持っている。そのように言えないなら、そのプロジェクトはまだ準備ができていません。

何かを買う前に、データ抽出をやってください。一年分、一ライン、同じ行に条件と結果、そしてプロセスを知る二人がその行は真だと確認すること。それから単純な代替手段、すなわちしきい値、管理図、あるいは現在の計画担当者の判断とベンチマークしてください。

受入基準は本稼働前に工場の単位で、しかもトレードオフが明示されるように対で書いてください。予知保全なら、カバーする故障モードのうち一週間以上前に検知できたものの件数を定め、それを月あたりの誤報件数の上限と対にします。需要予測なら、対象製品群の在庫日数の削減幅を定め、欠品を増やさないことと対にします。品質なら、対象工程の不良の削減幅を前年同月比で定め、併せて実施したプロセス変更を記録します。

所有者、異常時の挙動、再学習の頻度を同じ文書に書き、正直に中止という選択肢を持つレビュー日を設定してください。証拠に基づいて拡大しないという判断で終わる最初のプロジェクトは成功です。恒久的なデモンストレーションになったパイロットは成功ではありません。

Meta Smart Factoryはどこに位置づくか

Meta Smart Factoryはモジュール式であり、それがここで意味を持つのは、AI・機械学習モジュールが実行レイヤーの横ではなく、その上に乗っているからです。MESがイベントと文脈を供給し、IIoT接続とOPC UAが機械の信号を供給し、品質が原因付きの不良を供給し、保全が故障履歴を供給し、答えが予測ではなくスケジュールである場合にはAPSがその出力を受け取ります。

一つの名指しされた制約に対して一つのモジュールから始め、それが使われるようになってから次を足すことができます。どのプラットフォームも取り除いてくれない難しい部分があります。数字が何を意味するかを合意すること、原因を機械のそばで記録させること、そしてモデルが外れたとき誰がそれを所有するのかを決めることです。特定の工場について、その順序を話し合うことのほうが、デモンストレーションよりも有益な最初の会話です。デモンストレーションは、常に動くのですから。