2026年7月20日

制御設計者としての最初の一歩は「GPUが要る／要らない」の切り分けを自分の案件で持っておくこと。装置に載せるAIが画像判定なら GPU 前提だが、アラーム履歴の分類・稼働ログの異常検知・仕様書からの文章生成のような逐次処理は CPU で足りる可能性がある、というのがこの記事の主張の骨子。次の段階として、客先から「AI入りの装置を」と言われたときに、まず既存の産業用PCのCPUで回して様子を見る案を第一候補に置く提案書を作ると、見積りが一桁変わる。コスト感は、GPU搭載の産業用PCを新規に入れると数十万円規模の上乗せになるのに対し、既存機のCPUで回せば追加ハード費ゼロ。注意点は、この記事の段階では MONAKA はまだ PoC 開始時点で市場導入は2027年目標であること。今日買える製品の話ではないので、装置の更新計画に「2027年以降の選択肢」として書き留めておく使い方が現実的。

これはAI返信の話として書かれているが、そのまま「設計標準プロンプトの管理」に転用できる。最初の一歩は、いま自分が GX Works のタグ表チェックや仕様書要約に使っている定型プロンプトを1つ選び、スプレッドシートに「日付・変更者・変更理由・変更前・変更後・試した結果」の6列で台帳を作ること。今日30分でできる。次の段階は、その台帳から最新版を引いてくる GAS を書いて、シートを開けば常に「現行版のプロンプト」がコピーできる状態にする。コストは Google アカウントがあれば無料、GAS も無料枠で足りる。注意点は、記事が指摘しているとおり「本文だけを上書きすると戻し先が分からなくなる」こと。台帳を作っても変更前を残さない運用にすると意味がないので、列は必ず変更前と変更後の両方を持つこと。客先固有の情報をプロンプトに埋め込んでいる場合は、シートの共有範囲にも注意がいる。

制御屋にとっての読み替えは「PLCプロジェクトの版管理を、Gitに詳しくないまま始められる」ということ。最初の一歩は、GX Works のプロジェクトを書き出したフォルダで git init だけ済ませ、あとは区切りのいいところで「今の変更をコミットして」と言葉で頼む運用にすること。コマンドを覚える必要がない、というのがこのガイドの主眼。次の段階が bisect で、これは制御設計に一番効く。「先月は動いていた装置が今は動かない、途中で誰かが何かを変えた」というときに、動いていた版と壊れている版を指定すれば、壊れた変更が入ったコミットを機械的に絞り込める。手作業なら半日の犯人探しが数分になる。コストは Git 自体が無料、エージェント側は既存の契約範囲で足りる。注意点は、ラダーのプロジェクトファイルはバイナリなので diff が読めないこと。Git は「どの版か」の管理には効くが「どこが変わったか」は GX Works の比較機能で見る、と役割を分けて使うこと。あと reset や履歴書き換えを頼むときは、必ず先にコミットしてある状態でやること。

これは「客先にAI提案をするときの説明の型」としてそのまま使える。最初の一歩は、いま関わっている装置1台について、この投稿の4項目（動かない条件・止まる条件・復旧の手順・非常停止の優先）を1枚の紙に書き出してみること。書けない項目があれば、そこがAI以前に設計の穴。次の段階は、AI提案を受けたときにこの1枚を持ち出して「AIが提案するのはここまで、この4条件はPLC側で担保する」と線を引くこと。客先の安全担当を説得する材料になるし、自分の仕事が減らないことの説明にもなる。コストはゼロ、紙とペンで今日できる。注意点は、この投稿はあくまで一エンジニアの整理であって規格や基準ではないこと。実際の安全設計は機能安全の規格に従う必要があるので、この4項目は「話の入口」として使い、根拠は規格側に置くこと。

新人・若手にラダーを教える立場なら、これは今日試す価値がある。最初の一歩は、自分で4課題を通しでやってみて、「壊れる」課題が実機のどのトラブルに対応しているかをメモすること。登録不要なので、開いて5分で判断できる。次の段階は、新人に渡す前に自分の現場の失敗事例を1つ足して「この課題のあとに、うちで実際にあったのはこれ」と接続すること。シミュレータの弱点は現場固有の癖が入らないことなので、そこは人間が埋める。コストは体験版が無料。注意点は、体験版である以上、機能や課題数は製品版と違う可能性があること。教育カリキュラムに組み込む前に、継続して使える形かどうかを確認しておくこと。それと、シミュレータで通電の怖さを消しきることはできない。立上げ支援ツールを作っている別のエンジニアが「怖さをなくすのではなく、怖くても次の一手を選べるようにしておく」と書いているとおり、実機の初回通電には必ず経験者が付くこと。

最初の一歩は、担当している装置1台について、この投稿の5ステップ（プログラム転送→I/O確認→手動動作→原点合わせ→空運転1サイクル）を自分の装置の言葉に置き換えて書き出すこと。1台なら1時間で書ける。書いてみると「原点合わせの手順が自分の頭の中にしかない」ことに気づくはずで、それが一番の穴。次の段階は、その手順書を持って、実際に自分以外の人にやってもらうこと。読んで動けなければ手順書として不完全なので、詰まった箇所を追記する。コストはゼロ、必要なのは非稼働日の半日。注意点は、この手順書はプログラムのバックアップとセットでないと意味がないこと。手順があってもプロジェクトファイルの最新版がなければ復旧できない。バックアップの保管場所と最新性の確認を、手順書の0番目のステップとして先頭に書き足しておくこと。

フィールドエンジニアとして注目すべきは「三菱自が提供するノウハウ」の側に、生産技術・品質管理・安全管理・保全技術が名指しで入っていること。つまりヒューマノイドは自律的に働く箱ではなく、既存の工場の安全設計と保全体系に組み込む対象として扱われている。最初の一歩は、自分の客先工場で「人がやっていて、位置決めが緩く、力の要らない作業」を3つ挙げてみること。ヒューマノイドが最初に入るのはそこで、逆に言えばその工程の周辺機器・安全柵・インターロックが将来の改造対象になる。次の段階は、その3工程の現状の安全設計（非常停止の範囲、人検知の方式）を確認しておくこと。人と機械の協働が前提になると、既存の「柵で囲って止める」設計が通用しなくなる。コスト感としては、今日の投資判断ではない。2027年量産・2030年に年1000台という規模は、日本の自動車工場全体から見れば試験導入の域なので、当面は情報収集の枠。注意点は、この記事の数字はあくまで三菱自の目標値であること。プロトタイプ活用の段階なので、計画通り進む前提で自社の設備計画を組むのは早い。

これは道具の話ではなく手順の話なので、明日の現場でそのまま試せる。最初の一歩は、客先でトラブル対応に入るときに、スマホのメモでも紙でもいいので「変えたこと」を1行ずつ記録する欄を作ること。条件を変える前に書く、が肝で、後から書こうとすると必ず抜ける。次の段階は、その記録を持ち帰って報告書に転記すること。同じ装置で次に呼ばれたときの初手が変わるし、客先にも「何を触ったか」を示せる。コストはゼロ。注意点は、この「一つずつ変える」原則は復旧時間とトレードオフになること。ラインを止めている時間が金額に直結する現場では、客先が同時変更を求めてくる場面がある。そのときも記録だけは分けて残しておけば、後日の切り分けが効く。原則を守れない状況でも、記録は守れる。

制御側でも同じ型が使える。最初の一歩は、客先から「この動作を変えてほしい」と言われたときに、いきなりプログラムを正式改版せず、タッチパネルの調整画面やデバイス直書きで仮の動きを作って見てもらうこと。半日で試せて、外れてもすぐ戻せる。次の段階は、現場で作業者と一緒に動かして「副作用」を聞き出すこと。この投稿の要点は効果の確認より、作業者が副作用を事前に知りたがっていたという発見のほうにある。制御でいえば「サイクルタイムは縮んだが、段取り替えが増えた」といった類。コストは仮検証ならほぼゼロ、正式改版してから戻す場合と比べると差が大きい。注意点は、仮の状態を放置しないこと。ガムテープの例が最後にボルト締結まで行っているとおり、暫定を暫定のまま残すと次のトラブルの種になる。仮検証をやるなら、正式化の期限も同時に決めておくこと。

これはFAの話ではないが、自分の管理下にサイトがあるなら今日の作業。最初の一歩は、自分や勤務先が WordPress で作ったサイト（製品紹介ページ、技術ブログ、客先に納めた装置の情報ページなど）を洗い出し、バージョンを確認すること。6.9.0〜6.9.4 か 7.0.0〜7.0.1 なら未認証RCEが成立する範囲なので即更新。記事にあるとおり wp2shell.com のチェッカーでも確認できる。次の段階は、自動更新が有効になっているかの確認。今回は WordPress 側が強制アップデートを有効化しているが、自動更新を切っていたサイトは対象から漏れる可能性があるので、切っていないかを見る。コストはゼロ、更新自体は数分。注意点は、装置に組み込まれた社内サーバー上の WordPress を忘れないこと。工場内ネットワークにある社内Wiki的なサイトは外から見えないと思われがちだが、PoC が公開されている以上、内部に足がかりを取られた後の横展開の踏み台になる。それと、更新前にバックアップを取ること。7.0.2 への更新でテーマやプラグインが壊れる可能性は常にある。

制御屋にとってのローカルLLMの価値は、速度ではなく「客先の図面やプログラムを外に出さずにAIに読ませられる」こと。最初の一歩は、いま自分がクラウドのAIに貼れずに諦めている情報を書き出してみること。客先の仕様書、装置のラダー、トラブル報告書あたりが該当するはず。それが業務の中で頻繁に起きるなら、ローカルLLMを検討する理由になる。次の段階は、この記事の構成を目安に見積もること。統合メモリ128GBクラスのミニPCは現状20〜30万円規模、そこに 32B クラスのモデルを載せて 10〜11トークン/秒。これは体感でいうと「読める速度で文章が出てくるが、待てるほどではない」水準なので、対話には向くが大量バッチには向かない。注意点は、この記事の数値は Qwen3-32B の Q4量子化という特定条件のものであること。もっと小さいモデルなら速く、大きければ遅くなる。それと、社内に持ち込む前に、モデルのライセンスと、客先との秘密保持契約でAI利用がどう書かれているかを確認すること。ローカルで動かせば契約上問題ないとは限らない。

モデルの世代交代は、こちらが何もしなくても契約プラン側で切り替わることがある、というのが実務上の注意点。最初の一歩は、自分が使っているAIサービスのプランで「標準モデルが変わる」通知が来ていないか確認すること。今回は7月20日、つまり今日からの話。次の段階は、モデルが変わったあとに手元の定型プロンプトの出力が変わっていないかを確認すること。軸Aのトピック2で挙げた「プロンプトの変更台帳」がここで効く。プロンプトを変えていないのに出力が変わったなら原因はモデル側、と切り分けられる。コストはプラン内なので追加ゼロ。注意点は、「上位モデルを超えた」という主張と、自分の業務での使い勝手が一致するとは限らないこと。この記事は週次のニュース紹介であって、日本語のFA用語の扱いや長文仕様書の要約精度が良いかどうかは別の話なので、乗り換えを検討するなら自分の実業務のプロンプトで比べること。