同じ現場で動いているのに、WMSと設備PLCはお互いを知らない。なぜ「何が起きたか」と「記録」と「動作」が個別最適のまま繋がらないのか。その構造を分解し、AIの認識結果を共通言語にするという解のかたちを考えます。
倉庫や工場の現場を歩くと、不思議な光景に出会います。入荷から出荷までのモノの流れは倉庫管理システム（WMS）が握り、搬送コンベアや自動倉庫、加工設備の動作はPLCやSCADAが握っている。両者は数メートルの距離で並んで稼働しているのに、システムとしてはお互いの存在をほとんど知りません。WMSは「棚番号A-12に何が何個あるべきか」を知っていても、目の前のコンベアで今どの箱が流れているかは見ていない。PLCは箱を正確に搬送していても、その箱が伝票上のどのオーダーなのかを知らない。この非対称が、多くの現場に静かに横たわっています。
この分断は、誰かの怠慢で生まれたものではありません。むしろ、それぞれが真面目に最適化されてきた結果と考えるのが自然です。WMSは情報システム部門やロジ部門が業務要件から選定し、設備のPLCは生産技術や設備保全がライン設計から選定する。導入時期も数年〜十数年ずれ、ベンダーも設計思想も、更新サイクルも異なります。それぞれの世界の中では完結しているのに、境界をまたいだ瞬間に情報が途切れる——これが構造的な課題の正体だと考えられます。
では、これまで境界をどう繋いできたのか。多くの場合、その隙間を人が埋めてきました。作業者が現品票やラベルを目視で読み、ハンディターミナルでWMSに打ち込み、設備のタッチパネルで品種を切り替える。つまり「認識」と「記録」と「動作指示」の橋渡しを、人間の目と手が担ってきたわけです。これは長年うまく回ってきた一方で、労働力の逼迫、多品種化、トレーサビリティ要求の高まりの中で、限界が見え始めているという声を現場でよく聞きます。人が翻訳者として立ち続ける前提そのものが、揺らいでいると考えられます。
分断を解くには、まず現場の情報の流れを3つの層に分けて捉えると見通しが良くなると考えます。第一に「認識」——目の前で何が起きているか（品目は何か、数量はいくつか、良品か不良か、向きや状態はどうか）。第二に「記録」——それをWMSに在庫・入出荷・ロットとして反映すること。第三に「動作」——PLC/SCADAが搬送・仕分け・加工・停止をどう実行するか。多くの現場で、この3つは別々のシステム（あるいは人）が担当し、間に翻訳が挟まっています。
よくある失敗は、どちらか一方の世界だけで完結させようとすることです。WMS側の整備に投資すれば入出荷の記録精度は上がりますが、それが設備の動作に反映されなければ、結局は人が現場でパネルを操作し続けます。逆にPLC側の制御を高度化しても、そこで得た「今この箱を処理した」という事実がWMSに返らなければ、在庫データは現物とずれていきます。WMSとOCR連携の実務のようなWMS側の統合と、PLC連携によるAI検査のような設備側の連携は、本来はひと続きの話として設計されるべきだと考えます。
重要なのは、認識層こそが両者の共通の入口だという点です。WMSが欲しい「何が何個か」も、PLCが欲しい「どう処理すべきか」も、突き詰めれば「今、目の前に何があるか」を正しく認識できれば、そこから枝分かれして両方へ供給できます。認識を一度きちんと行い、その結果を両側に配る——この発想の転換が、分断を解く鍵になりうると考えます。
ここでAIによる画像認識、とりわけVLM（視覚言語モデル）を用いた認識が、一つの解になりうると考えます。産業用カメラと現場に合わせたライティングで対象を撮り、AIが「品目」「数量」「ラベルの文字（OCR）」「良否」「向き」といった意味を読み取る。その結果を、特定のシステムに依存しない中立的なデータ——たとえば品目コード・数量・判定・タイムスタンプの構造化された記録——として出力します。これは人間が現品票を読んで頭の中で行っていた翻訳を、機械可読な形に置き換える作業に近いと考えられます。
認識結果が中立的な構造化データになっていれば、それは一方でWMSのAPIやデータベースに在庫・入出荷レコードとして流れ、もう一方でPLC/SCADAへ「この品種なので仕分け先はこちら」「不良なので排出」といった動作トリガーとして流れます。同じ一つの認識から、記録と動作の両方が生まれる。これが「共通言語」という発想の核心です。WMSとPLCを直接繋いで無理に会話させるのではなく、両者が理解できる中間言語を挟むことで、それぞれの独立性を保ったまま連携させられると考えます。
元キーエンス画像処理事業部で培われた現場知見が効いてくるのは、まさにこの認識層の作り込みだと考えています。どんなカメラをどの角度で置き、どう照らせば対象の意味が安定して読めるか——照明・レンズ・撮像の設計は、AIモデルの性能以前に認識の土台を左右します。ここが甘いと、下流のWMS記録もPLC動作も、砂上の楼閣になりかねません。認識の質が、統合全体の質を決めると言っても過言ではないと考えます。
統合と聞くと、WMSや設備を刷新する大工事を想像されるかもしれません。しかし現実的には、稼働中のWMSも設備も止められないことがほとんどです。だからこそ、既存資産の外側に薄い「橋渡し層」を挟むアプローチが現実解になりうると考えます。具体的には、現場にJetsonのようなエッジデバイスと産業用カメラを設置し、そこでAI認識を行い、結果を既存WMSのインターフェースと既存PLCの入出力へ橋渡しする。既存システムには極力手を入れず、境界にだけ知能を足すイメージです。
認識と橋渡しを現場のエッジで完結させることには、いくつかの意味があると考えます。設備制御はミリ秒単位の応答が求められる領域があり、クラウド往復では間に合わない場面がある。また、工場・倉庫のネットワークはセキュリティ上クラウド接続が制限されることも多い。撮像から認識、判定、PLCへのトリガーまでを現場内で閉じられれば、応答性と運用の両面で扱いやすくなりうると考えます。もちろん、全てをエッジに寄せるべきという話ではなく、集計や学習はクラウドで、という役割分担が現実的な場面も多いはずです。
既存システムとの付き合い方は、統合設計で最も繊細な部分です。長年運用してきたWMSには独自のデータ構造や運用ルールが染み付いており、それを無視した連携は現場に受け入れられません。WMSレガシー移行の観点も踏まえ、既存の伝票フローや在庫ロジックを尊重しながら、認識結果をどの粒度で・どのタイミングで流し込むかを、現場担当と擦り合わせて決める必要があると考えます。橋渡し層は技術以上に「現場の合意形成」の産物だと感じています。
現場は理想通りにはできていません。統合を考え始めると、必ず「そもそもPLCが載っていない古い設備」「信号を外に出せない設備」に突き当たります。ここでもAI認識が一つの回避策になりうると考えます。設備の内部信号が取れなくても、外からカメラで状態を観察すれば、稼働・停止・異常・品種切り替えといった情報を推定できる場面がある。PLCなし設備の監視のように、制御信号ではなく「見た目」から状態を読む発想は、レガシー設備の多い現場ほど有効になりうると考えます。
日々の運用で分断が最も表面化しやすいのが入荷検品です。届いた現品を目視で確認し、ラベルを読み、WMSに登録し、必要なら設備へ搬送指示を出す——この一連が人手依存だと、繁忙時にボトルネックになりやすい。ここに認識層を入れ、現品の読み取りからWMS登録、搬送設備への引き渡しまでを一気通貫にできれば、翻訳作業を機械側へ寄せられる可能性があります。具体像は入荷検品とWMS自動化で整理していますが、入荷は統合の効果を最初に実感しやすい接点だと考えます。
ただ、運用で忘れてはならないのは「AIが間違えたとき、人がどう介入するか」の設計です。認識には必ず不確実性が伴います。確信度が低いときは人にエスカレーションし、判断を仰ぐ。その判断を学習に戻す。こうした人と機械の役割分担と例外処理を最初から織り込んでおかないと、統合システムは「たまに間違える不安な箱」になってしまいます。運用に耐える統合とは、AIの精度そのものより、間違いを前提にした運用設計の質だと考えます。
ここまで統合の可能性を述べてきましたが、誠実に限界も共有しておきたいと考えます。以下は、実際に検証を始めてみて初めて見えてくることが多い論点です。
これらは統合を諦める理由ではなく、最初に見積もっておくべき現実だと考えています。むしろ、こうした落とし穴を事前に洗い出し、自社の現場でどれが効いてくるかを見極めることが、投資判断の精度を高めます。「やってみないと分からない部分」を正直に地図化することが、遠回りに見えて最短の進め方になりうると考えます。
最後に、現実的な進め方を整理します。いきなり全ラインの統合を目指すのではなく、段階を踏むことを勧めたいと考えます。第一段階は「可視化」——自社の現場で、認識・記録・動作のどこで情報が途切れ、どこを人が翻訳しているかを棚卸しする。ここに投資対効果の大きい接点が眠っていることが多いと考えます。第二段階は「一接点の検証」——入荷検品など効果が見えやすい一箇所で、現物を使ってAI認識の精度と、WMS/PLCへの橋渡しの成否を小さく試す。
この検証段階では、認識率という単一の数字だけを追わないことが肝心だと考えます。確かめるべきは、①現物・現場の条件で意味が安定して読めるか、②その結果が既存WMSに無理なく流し込めるか、③PLC側の応答時間に間に合うか、④人の例外介入が現実的に回るか——の4点です。これらを一箇所で確認できて初めて、横展開の見取り図が描けます。数値は必ずモデル前提・一例として扱い、自社の現物での検証結果に置き換えていく姿勢が重要だと考えます。
第三段階が横展開です。一接点で「認識を共通言語にする」型が回ることを確認できれば、同じ橋渡し層の考え方を他の接点・他のラインへ広げられます。認識から記録・動作までを一気通貫でどう実装するかはWMSとPLCをAIでつなぐで具体化しています。自社のどこに分断があり、どこから始めるべきか迷われている段階でも構いません。現物を前に一緒に整理するところから、相談することができればと考えています。
技術的に直接連携が不可能というわけではありませんが、導入時期・ベンダー・データ構造・所管部門が異なるため、直接結合は保守や変更に弱くなりがちだと考えられます。両者が理解できる中立的な認識結果を『共通言語』として間に挟む方が、それぞれの独立性を保ちやすく現実的になりうると考えます。自社の既存システムのインターフェース条件次第で最適解は変わるため、現物・現場での確認が前提です。
必ずしも入れ替えが前提とは限らないと考えます。稼働中の資産は止めにくいため、既存の外側にエッジデバイスと産業用カメラによる薄い橋渡し層を挟み、既存WMSのインターフェースや既存PLCの入出力へ認識結果を渡す構成も選択肢になりうると考えます。ただしAPIの有無やデータ構造の独自性で難易度は変わるため、事前のインターフェース調査が要になります。
制御信号が取り出せない設備でも、外からカメラで状態を観察して稼働・停止・品種などを推定できる場面があると考えられます。制御信号ではなく『見た目』から状態を読む発想は、レガシー設備の多い現場で有効になりうると考えます。ただし何をどこまで読めるかは設備と設置条件に依存するため、現場での撮像検証が前提になります。
認識には必ず不確実性が伴うため、間違いを前提にした運用設計が重要だと考えます。確信度が低い場合は人へエスカレーションして判断を仰ぎ、その判断を学習に戻す仕組みを最初から織り込むことが要になります。精度そのものより、例外処理と人の介入をどう設計するかが、運用に耐える統合の質を決めると考えます。
効果は現場の分断箇所・物量・品種数・既存システムの条件によって大きく変わるため、一律の数値をお示しすることは避けたいと考えます。認識率や削減率といった数字は、あくまでモデル前提・一例として扱い、自社の現物・現場での検証結果に置き換えていく姿勢が適切だと考えます。まずは効果が見えやすい一接点で小さく検証することをお勧めします。
WMSと設備PLCの分断は、現場ごとに途切れ方が異なります。まずは認識・記録・動作のどこで人が翻訳しているかを、現物を前に一緒に棚卸しするところから始めませんか。小さな一接点の検証から、無理のない統合の道筋を描けると考えます。
WMSとPLCの統合について相談する