異なる工場のための3つの夢

産業機械を一度でも稼働させた人なら誰もが一度は疑問に思った3つのことがあります。口に出すにはあまりにユートピア的すぎるため、語られない3つのことです。この記事では、それらを並べて紹介します。

まず、ある光景から

深夜のシフト、X部門。ラインが停止する。HMIパネルにはコードが表示される：E-1423。マニュアルは3棟離れたキャビネットに保管されている。その機械に詳しい技術者は休暇中だ。オペレーターには二つの選択肢がある。サポートサービスを呼ぶ（たぶん朝にならないと出ない）か、それとも推測に頼るか。工業化された世界全体で、このような光景は一晩に何百回も繰り返されている。

問題はマニュアルがないことではない。マニュアルはありすぎる。問題は、機械が何が必要かを非常によく知っていること――圧力センサーが30秒前から何かがおかしいと教えてくれているのに――だが、オペレーターが理解できる言葉で話すことができず、話せても問題点を伝えるだけで解決策を伝えてくれないことだ。「圧力範囲外」という言葉は、深夜3時には役に立たない。「空気回路のV12バルブを確認してください、おそらく固着しています」という言葉は、役に立つ。

ここから私たちが取り組んでいる作業が始まります。新しいPLCではありません。より美しいHMIでもありません。2026年、機械を動かすソフトウェアがどうあるべきかという考え方を変える方法です。そして、私たちが一緒に実現しようとしている3つの固定観念、あるいは夢があります。

夢ナンバーワン：プログラミングなしで自動化

今日の産業用オートメーションは、非常に特殊な人物を必要とします。それは、IEC 61131-3ファミリー（ラダー、ファンクションブロック、ストラクチャードテキストの各方言を持つ）という、ソフトウェアの世界の他の場所ではほとんど使用されない言語でプログラムできる人です。これらの言語を知っている人は珍しく、高価で、ほとんどの場合、3週間遅れています。

パラドックスなのは、機械を本当に知っている人がプログラマーではないことが多いということです。それは部門長、ベテランのメンテナンス担当者、または20台の同様のプラントを設置したインテグレーターです。これらの人々は、機械が何をする必要があるかを理解しています。1990年代に生まれたプログラミング言語を学んでそれを説明する気はありません。

そのアイデアは、チェーンを覆すことです。ソフトウェア開発者は、モーションコントロール、センサー管理、オペレーションシーケンスなど、再利用可能なコンポーネントを、最新の汎用言語で一度だけ記述します。機械インテグレーターはそれらをプログラムするのではなく、機械が何をする必要があるかを音声または書面で指定して組み立てます。大規模言語モデル（LLM）が翻訳者として機能します。インテグレーターの機能仕様を取り込み、実行可能な構成に変換し、すでに記述およびテスト済みのコンポーネントを組み立てます。

これは、「AIがあなたの代わりにコードを書く」という空想ではありません。より控えめで現実的なものです。それは、AIがあなたの仕様を読み取り、認定されたコンポーネントの中から、それらをどのように組み合わせるかを選択することです。5ミリ秒のサイクルで軸を動かすようなクリティカルなコードは、依然として人間が、決定性と信頼性を保証する言語で記述します。しかし、そのコードは一度記述されれば、100回再利用されます。

夢の二つ目：自己認識する機械

今日、機械はほとんど話せず、そして下手です。アラームは数値コードです。診断は一連のLEDです。ログは、メーカーしか開けないバイナリファイルです。その機械が、どのような許容範囲で、2000回のサイクルを経てどのように機能するかという知識は、誰かの頭の中にあるか、どこかのPDFの中にあります。

2つ目の夢は、機械自身が自己認識することです。神秘的な意味ではなく、非常に具体的な意味で：技術ドキュメント、プロセスパラメータ、典型的な故障事例、介入手順は、もはやキャビネットや別のドキュメントサーバーに保存されるのではなく、機械自体の中に保存され、その機械自身のソフトウェアから読み取れるようになります。そして、何かがうまくいかないとき、機械は「エラー1423」とは言いません。「バルブV12はおそらく固着していると思われるので、確認してください。その間、速度を60％に落としてデグレードモードで続行できます」と言います。

違いは、受動的に信号を送るオブジェクトと、能動的に提案するオブジェクトです。前者は問題をオペレーターに任せます。後者は彼と一緒に問題に取り組みます。

これには、2つの自明ではないことが必要です。第一に、機械の知識（歴史的にはマニュアル、電気図、CAD図面、技術者の頭の中に保管されてきたもの）を形式化し、システムに統合することです。第二に、システムが会話できる相手を持つことです。再び、LLMを使用しますが、ここではコードを生成するためではなく、症状を理解できる行動に翻訳し、目の前の人の言葉で伝えるために使用します。

繰り返しますが、魔法ではありません。より良く書かれ、より良くインデックス化されたドキュメントと、その上にある会話型インターフェースです。しかし、夜勤者にとってはすべてが変わります。

夢の3番目：どこでも稼働するソフトウェア

3つ目の夢は最も技術的であり、逆説的にも最も政治的です。今日の産業オートメーションは、閉鎖的なエコシステムの世界です。各PLCの大手メーカーは、独自の言語、開発環境、ハードウェア、ドライバー、販売代理店ネットワークを持っています。サプライヤーを変更すると、すべてを書き直す必要があります。

ここで目指すのは、汎用ハードウェア—産業用ミニPC、組み込みコントローラ、地下室のサーバー—上で動作するソフトウェアシステムを構築することです。ハードウェアは、どのPLCメーカーが交渉に勝ったかではなく、予算と必要なパフォーマンスに基づいて選択します。リアルタイム版のLinuxオペレーティングシステム、オープンスタンダードに基づいた通信カード（EtherCATなど）、決定的な部分には最新の言語、そうでない部分にはよりアジャイルな言語を使用したソフトウェアコンポーネント。

ルールは、そしてここでユートピアが具体化するのは、ハードウェアは信頼性ではなく、パフォーマンスに影響を与えるべきだということです。処理時間が5ミリ秒から10ミリ秒に変わっても、同じ精度で軸が動きますが、速度は半分になります。決して「ほぼ同じ」ではありません。「この場合を除いては動作する」こともありません。同じシステム、同じ決定、同じ保証。

これは熟練したエンジニアが笑ってしまう部分です。リアルタイム処理が難しいこと、Linuxがリアルタイムシステムとして設計されていないこと、LLMがRaspberry Piで動作しないこと、同じスタックで異なる言語を混在させると、チュートリアルで約束されているよりも多くの落とし穴があることを彼らはよく知っています。彼らは正しいのです。しかし、方向性はそれであり、それを構築するための構成要素（Linuxカーネルのリアルタイム拡張、成熟したオープンソースのEtherCATスタック、そして控えめなハードウェアで動作し始めたLLM）が、今日、初めてすべて一緒に存在します。

なぜ「ユートピア」なのか

ユートピアは正直な言葉です。これらの3つのうちのどれも、今日、完成品ではありません。最初のものは、生産環境で使用できるほど信頼性の高いLLMを必要とし、私たちはまだ初期段階にあります。2番目のものは、今日ほとんどが非公式である産業知識の莫大な形式化作業を必要とします。3番目のものは、20年以上の優位性を持つクローズドエコシステムに対するオープンな代替手段を構築する必要があります。

しかし、これらの3つの夢を並べると、明確な方向性が見えてきます。それは、ハードウェアがコモディティであり、ソフトウェアが再利用可能であり、知識が機械に組み込まれ、今日の産業全体のボトルネックとなっているPLCプログラマーの役割が消滅するのではなく、本当に必要な場所に移動する、つまり、一度きりの基本コンポーネントを書くようになる自動化です。

今後の記事で、このパズルのピースを構築していく様子をお伝えします。一度に一つずつ、パズルが完成することを約束するものではありません。まだ完成していません。しかし、輪郭が見え始めています。