2026年9月28日

最初の一歩は、自分が関わった装置のうち「欧州へ出る／出る可能性がある」ものを1枚に書き出すこと。装置名、納入先、安全PLCの型式、リモート保守の有無の4列でよく、今日30分でできる。ここで効くのは、認証の評価対象に「不正アクセスやソフトウェア改ざんで安全機能が損なわれない設計」が入ったという事実で、これまで安全回路の話だったものに、ネットワーク側の話が正面から乗ってきたことを意味する。次の段階は、その一覧の装置ごとに「安全PLCへ誰がどこから書き込めるか」を洗うこと。GX Works3のプロジェクトを預けている先、客先のVPN、保守用ノートPCの持ち出し、この3つを書き出すだけで、自分の案件の弱いところが見える。設計側で今から仕込めるのは、安全プログラムのパスワード運用と、リモート保守の接続経路を常時接続にしない構成の2点。コストは棚卸し自体はゼロ、認証済み機種への置き換えが要る場合はCPU・ベースの入れ替えで1台あたり数十万円規模を見込む。注意点は、この記事はあくまで三菱電機が対象機種について認証書を取得したという話であって、その機種を使えば装置全体が欧州機械規則に適合する、という意味ではないこと。記事も「機械や装置の適合に関わる設計、検証などの業務負荷軽減に寄与する」という書き方に留めている。客先へは「装置の適合は別途必要、ただしコントローラー部分の証跡は揃う」と正確に伝えるのが安全。2027年1月20日という期日は交渉できないので、欧州案件は逆算して今期のうちに機種選定の方針を決めておくとよい。

ここで持ち帰るべきは製品名ではなく「プロジェクトがテキストで保存されているかどうかが、AIを使えるかどうかの分かれ目になる」という一点。GX Works3のプロジェクトはバイナリなので、そのままではAIに読ませられない。最初の一歩は今日できる代替策で、GX Works3から「プロジェクトの文書化」やラベル・デバイスコメントのCSV出力を行い、そのテキストをGeminiやClaudeの無料枠に貼って「この命名規則で揺れている箇所を挙げて」と聞いてみること。読み書きはできなくても、読ませるだけで設計レビューの当たりは付く。次の段階は、記事のMCP連携が示している「AIが現在値を見て答える」部分の代用。既存案件でSLMPやModbusで上位へ出しているデータがあるなら、それをCSVでローカルに落とし、AIに「この30分のログで、停止前に先に変化した信号はどれか」と聞く運用にする。ここは装置を止めずに試せる。もう一方のConnected PLC側は、客先で「チョコ停の原因が分からない」と言われたときの提案材料として温めておく価値がある。既存PLCのプログラムを変更せずLANケーブル1本で済むという構成は、こちらが再検証の工数を負わなくてよいという意味で、見積もりの出しやすさが違う。コストは、AIへ読ませる検討は無料枠で今日から、カメラ連携は機器＋アプリで一式数十万円規模を想定して客先に幅で伝える。注意点を2つ。1つは、AIエージェント連携は参考出展のデモとして紹介されたものなので、現段階で客先へ「できます」と約束しないこと。もう1つは、AIから値の変更やRUN／STOPができる構成は、裏返せば書き込み権限を渡すということなので、自分で試すときは必ず実機から切り離したシミュレータか予備機で行うこと。

最初の一歩は、記事の7要素のうち4番目「禁止パターン表」だけを、自分の環境向けに10行書くこと。三菱系なら、GX Works3のST／ラダーでAIがやりがちな取り違え——デバイス種別（D／M／L／SD）の混同、タイマ・カウンタの設定値記法、`MOV` と `DMOV` の使い分け、ビットデバイスへの数値代入——を「よくある誤り → 正しい書き方」の2列で並べる。これは今日、メモ帳1枚で始められる。次の段階は、その表を毎回貼るのをやめてファイル化すること。Claude Desktopのスキルを使うならSKILL.mdに、そうでなければ社内共有フォルダのmdファイルに置き、AIに聞くときの最初のメッセージで丸ごと貼る運用にする。記事が言うとおり、プロンプトは揮発するがファイルは残るので、来週の自分と後輩に引き継げるかどうかがここで決まる。3番目の段階は運用ルールで、ビルドで弾かれるたびに1行追記すること。半年続けると、これが自分の「ハマりポイント集」になり、AI抜きの新人教育資料としても使える。コストはゼロ。Claude Desktopのスキル機能を使わなくても、テキストファイル＋コピペで同じ効果の8割は出る。注意点は2つ。1つは、記事自身が「定量比較はしていない」と断っているとおり、精度向上の程度は環境で変わるので、上司や客先へ「AIで不具合が減ります」と数字で約束しないこと。もう1つは、リファレンスにない関数の捏造がゼロにはならない点で、AIが出したSTはビルドを通すまで信用しないという原則を崩さないこと。とくに安全関連や非常停止に絡む部分は、AIの出力を下書きにすらしない線引きを自分で決めておく。

この製品そのものよりも、「同じ箱でCODESYSとNode-REDを選べる」という構成が、自分の案件設計の考え方に効く。最初の一歩は、いま抱えている監視・データ収集の要件を「締切がある処理」と「遅れてもよい処理」の2つに仕分けること。インタロックや保護停止のように応答時間に締切がある処理はソフトPLC側（ラダー／ST）、日報の集計・メール通知・クラウド送信のように多少遅れても困らない処理はNode-RED側、という分け方を紙1枚に書くだけで、後の選定がぶれなくなる。今日できるのはこの仕分けまでで十分。次の段階は、Node-RED自体を手元で触ってみること。Raspberry Piでも自分のWindows PCでも無料で動くので、「Modbus TCPで温度を読んでスプレッドシートに書く」フローを1本作れば、どこまでノーコードで済むかの肌感が掴める。ここを知っておくと、客先から「見える化だけ安くやりたい」と言われたときに、PLCを盛らずに答えを出せる。コストは、試すだけなら無料（Node-REDはオープンソース、CODESYSは評価用で試せる範囲がある）。実機を入れる場合は、リモートI/Oを含めた構成で見積もりを取る。注意点は、記事が挙げている複数プロトコル対応（EtherCAT、EtherNet/IP、OPC UA、PROFINET）はCODESYSの利用時という条件付きで書かれていること。Node-REDで組むつもりの部分に産業用プロトコルを期待しないこと。もう1つ、この製品はビルオートメーションや省エネ監視システム向けとして紹介されているので、生産設備の主制御へそのまま持ち込む前提で客先に話さないほうがよい。

最初の一歩は、客先で「また止まった」と言われる回転機械を3台挙げて、それぞれ「止まると何分／何時間ラインが止まるか」を数字で書くこと。予知保全の提案が通るかどうかは、センサーの性能ではなくこの停止コストの数字で決まる。今日この3行が書ければ十分。次の段階は、いきなりシステムを入れずに手持ちで測ること。スマホの振動・騒音アプリでも、同じ位置・同じ運転条件で週1回撮り続ければ傾向は出る。ここで「変化が出る機械／出ない機械」を仕分けてから本格導入に進むと、無駄な投資を避けられる。3番目に、PLC側でできる下準備をしておく。運転時間の積算、起動回数、電流のピーク値の3点をGX Works3でロギングしてSDカードに残すだけでも、あとで振動データと突き合わせる材料になる。この記事のシステムが「4段階で可視化して専門知識が少なくても判断できる」ことを狙っている点は、自分の現場でも同じで、生データを現場に渡しても見てもらえないという教訓として使える。コストは、手持ち測定はゼロ、本格導入は設備診断エッジユニット＋アプリ＋支援の一式なので数十万円〜が目安（記事に価格の記載はないため、客先には概算を約束しない）。注意点は、記事に出てくる6カ月間の実証評価は資源リサイクル事業者での先行実施の話で、ベルトコンベヤー回転軸のクラックという特定の事例であること。自分の客先の設備で同じ期間・同じ成果が出るとは限らないので、提案では「まず1台・数カ月の実証から」という段取りをセットで出すこと。

このリリースで一番使えるのは75％という数字ではなく、「何のデータを取るか」から設計するという順番のほうで、これはそのまま客先提案の型になる。最初の一歩は、自分が関わる設備で「予測したい故障」を1つだけ決めること。ベアリング焼き付き、ヒーター断線、エア漏れ、サーボの過負荷——どれか1つに絞り、その故障が起きるときに先に変わる物理量を3つ挙げる。紙1枚、今日15分で書ける。次の段階は、その3つがいまPLCで取れているかを確認すること。取れていなければ、サーボアンプの実電流、温調計の偏差、インバータの出力周波数のように、既に盤の中にあるのに上位へ出していない値がないかを探す。新しいセンサーを買う前にここを潰すのが安く済む。3番目は、リリースが挙げている「検知後に誰がどのように対応するか」を先に決めること。アラートが出たあと誰が現場を見て、誰が部品を手配するかが決まっていないシステムは、必ず無視されるようになる。コストは、既存データの棚卸しと1設備のロギング追加なら実質ゼロ〜数万円。外部にAI開発を依頼する規模になると数百万円クラスを覚悟する。注意点は、75％削減はあくまでモデルケースの試算であり実績値ではないこと。リリース自身がその旨を明記しているので、客先や上司に持っていくときは「試算値」と言い切って引用すること。もう1つ、このリリースは同社が2026年9月30日・10月1日の「AI博覧会 Fukuoka 2026」にゴールドスポンサーとして出展し、10月1日11:00〜11:40に代表取締役CEOの大塚空来氏が登壇するという告知も含んでいるので、九州圏にいるなら現物を見て話を聞くほうが早い。

この記事の一番の実利は「1週目は何も自動化せず、いまの手間を測る」という指示。最初の一歩はこれで、今日から1週間、データ回収・転記・集計に何分かかったかを日報の隅にメモするだけ。ここを飛ばすと、導入後に「速くなった気がする」しか言えなくなり、次の予算が取れない。次の段階は対象設備を1台に絞ること。選定基準は記事のとおり、PLCへ接続でき、転記や集計の手作業があり、過去に原因確認で困った異常がある設備。自分の担当ならどれかは即答できるはずなので、選んだ理由を1行書いておく。3番目は、タグを20〜50点に絞る作業。ここで欲張ると、データ量よりネットワーク設計と保存容量の話に引きずられて30日が終わる。運転／停止、異常コード、サイクル開始・終了、主要な温度・圧力・電流、この程度で十分。4番目は、記事の3週目が言う「現場の人が見る場所に置く」の実装で、GOTの空き画面かタブレット1枚に直近24時間のトレンドを出すだけでよい。コストはゼロ〜数万円（既存のPLC、ノートPC1台、フリーのOPC UAクライアントやロガーで組める）。注意点は、記事が挙げる合格条件のうち「必要なデータの取得率が99％以上」は思ったよりハードルが高いこと。PC再起動やネットワーク瞬断で1日抜けると99％を割るので、2週目の安定確認を手抜きしないこと。もう1つ、これは筆者が自身の考えとして提示している計画であって、業界標準や公的なガイドラインではない。社内へ持ち込むときは「この型を借りる」という言い方にしておくと、後で数字が合わなかったときに揉めない。

注目すべきは水産の話ではなく、「目視と手作業の選別」という、どの工場にも1つはある工程に画像解析＋ロボットアームを当てている構図のほう。最初の一歩は、自分の客先で目視選別・目視検査をしている工程を1つ選び、「不良の見え方」を分類すること。色が違う、形が違う、傷がある、サイズが外れている——どれに当たるかで難易度がまるで変わり、色・サイズ系なら既存のビジョンで届くことが多い。今日はスマホで良品・不良品を各20枚撮って並べるところまででよく、これだけで「人が見れば分かるが写真では分からない」不良かどうかが判定できる。次の段階は、除去側の設計。この事例はコンベア上を流しながらアームで抜く構成なので、自分の案件でも「止めて選別する」のか「流しながら抜く」のかを先に決める。流しながらならコンベア速度と撮像タイミング、エンコーダによる追従が要り、PLC側の作り込みが一段増える。3番目に、記事が挙げている「複数メーカーの協働ロボットや周辺機器をノーコードで制御」という点は、見積もり段階で効く観点。ロボットメーカーが客先都合で変わっても制御側を作り直さずに済むかを、提案の比較軸に入れておく。コストは、良否の見極め確認はスマホと無料のAIチャットでゼロ円、実装は協働ロボット本体＋ビジョン＋架台で数百万円規模を見ておく。注意点は、この案件は「試験導入」であり「装置の精度向上と継続的な運用体制を整備する」という段階で紹介されていること。完成した導入事例として客先に紹介しないこと。また生物のような個体差の大きい対象は、良品の幅が広く教師データが増えがちなので、工数見積もりではデータ収集とラベリングを別枠で積むこと。

制御設計の実務でこれがそのまま効くのは、請求書ではなく「客先・商社から届く図面と仕様書」の管理。最初の一歩は、検索式を `has:attachment newer_than:3d -in:chats` から自分用に書き換えるだけ。案件用のGmailラベルを1つ作り、`label:案件A has:attachment` にして、保存先を案件フォルダに向ければ、届いた図面が受信日つきのファイル名で自動的に溜まる。今日20分で動かせる。次の段階は、保存ログのシートを「受領台帳」として使うこと。メールID・受信日・送信元・件名・保存数・ドライブURLが1行ずつ残るので、「その改訂図はいつ誰から来たか」を後から即答できる。仕様変更の経緯を追われる場面で、これが効く。3番目は、拡張子リストの調整。既定の `pdf/xlsx/xls/csv/docx/doc/zip/jpg/jpeg/png` に、自分の業務なら `dwg` や `dxf`、`gx3`（圧縮されて届くなら `zip` のまま）を足すか外すかを決める。最小サイズ5KBで署名画像を弾く仕掛けはそのまま使える。コストはゼロ。GASの無料枠だけで動き、記事もAPIキー不要・追加費用なしと明記している。注意点を3つ。1つ目は権限で、初回実行でGmailとDriveへのアクセス承認を求められるため、会社アカウントだと組織のポリシーで止まることがある。まず個人アカウントか、情報システム部門の了解を取ってから。2つ目は6分の実行上限で、記事は4.5分で打ち切って続きを次回に回す作りにしているが、初回に古いメールを大量に対象にすると何周も回ることになるので、最初は `newer_than:3d` のまま狭く始めること。3つ目は、客先の図面をDriveへ自動保存する構成は社外秘の扱いに触れるので、社内の情報管理ルールを先に確認すること。

制御設計の文脈にそのまま置き換えられる話で、最初の一歩は「自分がLLMに渡してよい作業」と「渡すと自分の腕が落ちる作業」を紙に2列で書き出すこと。渡してよい側には、メーカー資料の横断検索、命名規則チェック、英文マニュアルの下訳、議事メモの整形あたりが入る。渡さない側には、シーケンスの状態遷移を自分で描くこと、異常時の切り分け手順を頭の中で組むこと、現場で「なぜこの制御にしたか」を口で説明することが入るはず。今日15分で書ける。次の段階は、記事の「これを理解するために、僕は何を先に知る必要がありますか？」をそのまま自分の勉強に使うこと。たとえばCC-Link IE TSNやOPC UAのように、名前は知っているが説明できない技術について、いきなり解説を求めず「理解するために先に知るべきことを順番に」と頼む。出てきた地図を1枚にして、分からない語に印を付ける。3番目は「人に聞くこと」の実装で、客先のベテラン保全担当や社内の先輩に聞く前に、三行メモ（ここまでこう理解している／根拠はこの資料のここ／ここを確かめたい）を用意する運用にすること。これは相手の時間を奪わない聞き方でもあるので、現場での信用に直結する。コストはゼロ、必要なのは紙とペンだけ。注意点は、記事自身が断っているとおり「手書きが優れている」という主張ではなく、筆者にとって都合のよい制約がペンだった、という話であること。自分に合うのがタイピングでも音声メモでも構わない。もう1つ、この線引きは一度決めて終わりではなく、担当業務が変わるたびに引き直すもの。設計から保全支援へ軸足が移れば、渡してよい作業も変わる。

会社がMicrosoft 365を使っているなら、これはGoogle系のGASでやっている自動化と同じ土俵の話になるので、先に自分の環境がどちらかを確認するところから。最初の一歩は、自分のアカウントでCopilotの画面を開き、Word・ExcelがCopilotの中から直接触れる状態になっているかを見ること。なっていなければライセンスの問題なので、そこで検討は止めてよい。5分で終わる。次の段階は、記事が挙げるCodeの「ダッシュボード・トラッカー」に当たるものを、自分の業務で1つ決めること。制御設計なら、案件ごとの進捗トラッカー（設計→製作→出荷→立ち会いの4段階）か、客先別の不具合対応リストあたりが現実的。いまExcelで手作業管理しているものを1つ選び、自然言語で作らせて既存ファイルと比べるのが一番早い評価になる。3番目は、Autopilotのような継続動作するエージェントを検討する前に、社内のルールを確認すること。記事が「AIを企業で安全に使うための共通基盤」としてCopilot Managed Runtimeや権限・ガバナンスの話を挙げているのは、裏を返せばこの層を整えないと現場で勝手に走らせるのは危ういという意味に読める。コストは、Copilot系の機能は多くの場合Microsoft 365の追加ライセンスが必要で、個人で試すなら月数千円規模、全社展開なら人数分の見積もりになる。まずは自分1人分で試して価値を測るのが安い。注意点は、ここで書かれている整理はQiita記事の筆者によるもので、Microsoftの公式説明そのものではないこと。社内に持ち込むときは元の発表を自分で確認すること。もう1つ、会議準備やタスク追跡を継続的に実施するエージェントは、客先名や装置情報を含むメール・カレンダーを常時参照することになるので、社外秘情報の扱いを情報システム部門と先に握ること。

Dockerそのものを使っていなくても、この発表から持ち帰れるのは「ベンダー自身が、AIエージェント向けの作法をSKILL.mdという形で配る」という流れが始まったこと。最初の一歩は、自分が普段AIに間違えられて困っている領域で、同じ形の自前スキルを1つ作ること。軸Aのトピック3で触れたPLC用スキルと同じ構造で、`SKILL.md` に「どういう作業で使うか」をdescriptionに書き、本文に原則と禁止例を並べる。今日、テキストファイル1枚から始められる。次の段階は、11種類のうち `docker-destructive-guardrails` の考え方を自分の運用に移すこと。これは「元に戻せない操作を実行する前の確認方針」を扱うスキルで、AIに作業を任せる場面では領域を問わず効く発想になる。自分の場合なら、PLCへの書き込み、客先サーバーへのファイル削除、バックアップの上書きといった不可逆な操作について、「実行前に何を確認させるか」を文章にしておく。3番目は、記事が触れている公式ドキュメントの案内——エージェントの提案した変更やコマンドをレビューし、テストを実行してから採用する——をそのまま自分のルールにすること。コストはゼロ。Docker Skills自体もApache License 2.0で、`npx skills add docker/skills` で導入できると記事は書いている。注意点は、Docker Sandboxes向けの `docker-sandboxes-env` と `docker-sandboxes-kits` は実験段階として紹介されている点で、この2つを業務の前提にしないこと。もう1つ、これはあくまで開発者向けの発表で、FA現場の装置制御に直接関係する話ではない。自分の業務に持ち込むのは「スキルという配り方」の部分だけに留めるのが妥当。