以前ツイートした「製造業における制御設計の設計工程を見直そう」という内容を、noteにまとめました。機械設計はFMEAやDRFBMといった設計フェーズでの実践手法について書かれたサイトが多いのですが、制御設計も設計フェーズに重きを置くことの重要性は同じです。 note.com/toki_engineer/n/n7c…

制御設計者にも同じことが言える。 長期目線で考えるのに加え、今の受注が特定顧客や人手不足など、何に依存しているのかも重要。生成AIが設計業務の一部に入り始めているので、「人がいないから委託する」は今だけかもしれない。どこで価値を出すのかを考えておかないと詰むと思う。

AIを使ってもクソ忙しさからは解放されないというジレンマ！

五十嵐さん渾身の「工作機械・愛」動画が流れてます！

AIを使って設備設計するのは大賛成だけど、最終的には自分で設備をいじりましょう。動かしながらメカ調整・制御調整することによって得られる「手触り感」は無くしてはダメです。AI設計だけやって終わりの人は論外です。 大事なので2回言いますね。 手触り感！！

以前、生成AIだけで単純な設備の機械設計ができた、というポストをした。今後、生成AIが更に進化すると、その先の可能性が一気に広がるな。 機械設計だけでなく、電気設計、PLCプログラム、HMIまでAIで生成できるようになったら、工場のあり方そのものが変わる。 例えば、機械・電気・制御を共通の設備仕様からAIで設計し、デジタルツインで動作検証。そして、工場内のサーバーで動作する仮想PLCに、検証済みの制御プログラムを配信する。 こうすれば、標準化・モジュール化された生産設備に対して、必要な制御機能をソフトウェア側から構成・変更できるようになる。 生産管理システムからの指示に応じて、設備の制御機能や工程構成まで柔軟に変更する工場も考えられる。 従来は、設備ごとに機械・電気・制御を個別設計し、PLCにプログラムを書き込んでいた。それが、設備仕様から設計・検証・配備・更新までをソフトウェア中心に一元管理する形へと変わっていく。 いわゆるSoftware-defined Manufacturingの世界。 欧州の工場で目指そうとしていることが、一気に具現化していきそう。

SiemensのAIエージェントは、たんに生成AIでPLCプログラムを作るどころの話ではないな。次のような設計作業ができるようになってる。 ・PLCプログラムの生成・修正 ・PLCプログラムのテストコード生成、エラー修正 ・HMI画面の生成・編集 ・PLCやI/O、PROFINETの機器構成・設定 ・サーボドライブの設定やパラメータ変更 ・既存プログラムの解析、依存関係の調査 ・PLCタグ、データ型、HMI画面などの参照関係の調査 これからは、AIエージェントを使いながら設計していくことが当たり前になるな。

最近やたらと「日本の勝ち筋」という言葉を目にするようになった。これって裏を返せば、「負けている」とまでは言わないにしても、少なくとも「出遅れている」と認識しているんだろうな。

大学生から就活の質問や、中高生から受験勉強についての質問を受けることがあるけど、ワイに聞くのは間違いや。ワイは就活も経験したことがないし、受験勉強もしたことがないから、「知らん」としか答えられへん！

この引用元のポストのように、同じように危機感を覚えるベテランと、「いやいや、ベテランには経験があるんだから、若手が生成AIを使ったところで脅威にはならんよ」というベテランに分かれる。 これはあくまでも私の仮説だが、脅威にならない派は、更に次の全く異なる2つのグループに分かれると思ってる。 ・AIを使い倒していないがために、AIの現在地を把握できていない ・AIの能力を十分に理解したうえで、限界も把握している

PLCでST言語を使うなら、一度C++やC#などで、オブジェクト指向プログラミング（OOP）を本格的に学ぶことをお勧めする。 ST言語のメリットは、複雑な演算や配列処理を記述しやすいことだけではない。それだけを目的に使うのはもったいない。 STを使う最大のメリットは、FBによる機能分割、データと処理のカプセル化、インターフェースの設計、さらには（環境によって）継承や多様性まで、ソフトウェア工学の設計手法をPLCプログラムに取り入れられることにある。 もちろん、OOPを知らなくてもSTでプログラムは書ける。ただ、STの文法を覚えただけでは、ラダーの処理をテキストに置き換えただけになってしまう。 勘違いしないで欲しいのは、それが悪いという話ではない。 一品一様の装置や、小規模の装置では、保守性などを考えるとOOPを取り入れることが正解にならないケースも多々ある。単純な設備に過度な抽象化を持ち込めば、かえって分かりにくくなる。 ここで言いたいのは、「OOPを知らないから使わない」のか、「OOPを理解した上で使わないと判断するのか」という違い。 STを単なるラダーの代替言語として捉えるのではなく、設計手法の引き出しを増やし、設備に応じて使い分けられるようになることが大切だと思う。

機構設計でCADを全く使わず、次のことにチャレンジ中。 ・生成AIで、プロンプト指示だけでHTML形式の3D図とアニメーションを作成 ・これもCADを介さずバラシ図と組み図とBOMを作成 ・物によってはそのままミスミで原価計算 簡単な設備なら、なんとかイケそうなところまで来てるな。

エンジニアリング業務で、最近感じていること。 ・生成AIで若手のアウトプットの質が上がり、ベテランとの差が縮まっている。それを目の当たりにして、危機感を覚える。 ↓ ・しかし、現場で場数を踏んだからこそ気づけること、判断できることもあり、経験の積み重ねが生む強みはまだまだ健在だと安心する。 ↓ ・だがそれも今のうちで、生成AIが進化すれば、その差もいずれ縮まっていくのだろうと、やっぱり危機感を持つ。（←今ココ）

会社で生成AIに課金して積極的に社員に使わせている会社と、そうでない会社で、仕事のアウトプットにどんどん差が付いていってる。

今日は用事で5年ぶりに銀行の窓口に来た。周りの客を見てると銀行員にNISAの相談をしてる人が何人かいるけど、銀行に相談したらダメだろー。銀行と客は利益相反の関係なんだから。投資のスタート地点で躓いてる。

生成AIの登場によって、FA分野でも「設計の民主化」が進んでいると感じる。機械設計者も制御設計者も、設計という専門領域の境界が変わり始めている。どこで専門領域を発揮し、設計者以外の人達と差別化するのかを考える時代に突入した。

三菱PLCのMC/SLMP通信はホント弱いな。三菱のクソ仕様をあげてみる。 ・接続台数分の設定が必要という手間 ・UDPはポートを分ける謎仕様 ・複数台からコマンド命令があった時、応答前の次要求を破棄するという暴挙 また、CPUユニットのEthernetポートは貧弱過ぎて、TCPで複数台接続したとき、3wayハンドシェイクでコケまくる。 MC/SLMP通信の安定性を取るのであればキーエンスのほうが良い。

Claudeのおかげで、機械設計者じゃない私でも、メカの構想設計ができるようになった。 これまで散々、装置の組み立てやメカ調整をやってきたので、機構の良し悪しは判断できるが、白紙の状態から自分でメカの構想を練ることはできなかった。でも、これができるようになったのはありがたい。簡単な装置であれば、詳細設計やバラシ、組図の作成までやってくれる。 もちろん、応力・たわみ計算、強度計算、慣性モーメントの計算などもやってくれる。計算条件や結果の妥当性は自分で確認する必要があるが、でもめっちゃ助かってる。 今まで、「設計の良し悪しを判断できること」と「自分で設計できること」は、全く別の能力だったが、今後その差を生成AIがどんどん埋めていく。

最近、1日2食（昼と夜）から1食（夜のみ）に変えたが、もの凄く体の調子がいい。仕事中に眠くなったり集中力が切れるのは、食事の取り過ぎだったと実感。

三菱FAの「国内では強いが、海外で成長できるかは別問題」が、ブレーカやマグネットにも表れていると思った。 ■三菱側 ・国内では高いシェアを持つ ・ただ海外は電化で需要が伸び、競争も激しくなる ・そこで勝つには、パートナーとの共同運営が必要だと判断 ■ABB側 ・ABBの電化事業は日本での存在感が限られていた ・そこへ、日本の低圧市場で首位に立てる事業が、顧客基盤と工場ごと手に入る ・しかもABBは、この合弁で5年以内にOperational EBITA率20%以上を目指す ・そうなると、他の電化事業並みの水準になる 利害が一致したわけだが、しかし、ABBには中期的に100%取得できるオプションがある。そうなると制御盤の中の定番製品がガラリと変わるな。

共感しかない。 ・月400時間働いてた頃 ・開発で手詰まり、最終電車の中でも考え続け、降りる駅を通り過ぎて家に帰れなかった事が何度もあった時期 ・仕事に没頭し過ぎて会社の保健室に寝泊まりしてた日々 渦中にいる時は大変だったが、今振り返ると「生きてる感」がもの凄くあった。