2026年8月25日

明日できる最初の一歩は、いま担当している1プロジェクトのGX Works3を開いて、使用中のMデバイスを「デバイス使用リスト」で吐き出し、機能ごとに色分けしてみること。空き番から取った履歴があるプロジェクトほど、手動・自動・異常が同じ100番台に混在しているのが見えるはずで、それが引き継ぎのときに一番効くコストになっている。次の段階は、既存プロジェクトを直すのではなく（稼働中の設備でデバイス番号を動かすのは事故のもと）、次に新規で書く装置に対して割付表テンプレートを1枚だけ作ること。列は「先頭番号／点数／用途／予備率／備考」の5列で十分で、ExcelでもGoogleスプレッドシートでもいい。予備2割というのは、M0〜M99の手動ブロックなら実使用を80点までに抑えてM80〜M99を空けておく、という具体の話に落ちる。次の改造でM100番台の自動ブロックへ食い込まずに済む。コストはゼロ、要るのは着手前の30分だけ。注意点は、この表を客先仕様書に載せないこと。仕様として固定すると改造のたびに承認が要る。あくまで自分の設計標準として持ち、成果物としては「割付表を添付した完成図書」の形で渡すのが実務的に収まりがいい。さらに一歩進めるなら、割付表のCSVをGeminiやChatGPTの無料枠に貼って「このブロック分けで用途が重複しているMを挙げて」と聞くと、目視で見落とす重複を拾える。

最初の一歩は、担当装置1台について「品種を1つ増やすときに触るファイルと箇所」を数え上げること。ラダー、HMI画面データ、ロボットプログラム、画像処理レシピ、サーボ／インバータのパラメータで、それぞれ何箇所か。10箇所を超えていたら、この投稿が言う「触りにくい設備」に入っている。次の段階は、いきなり全部をデータ駆動に作り替えるのではなく、まず品種テーブルをPLCのデバイスメモリ上に切ること。GX Works3でD3000〜を品種テーブル領域と決め、1品種あたり16ワード（品種番号／寸法X／寸法Y／工程パターン番号／把持タイプ／予備）を確保して、ラダー側は「現在品種番号」から間接指定でその領域を読む形にする。既存の分岐ラダーを消さずに、新規品種だけこの経路に載せる並行運転から始めれば、稼働中の設備でも入れられる。その次が投稿の後半にある一致確認で、PLC・ロボット・画像処理・専用機のそれぞれが「自分がいま何番の品種で動いているか」を1ワードずつ返す仕組みを作り、全部が一致したときだけ自動運転許可のコイルを立てる。ここが一番効く。「4台中3台だけ切り替わってそのまま動く」は、不良を作り続けても誰も気づかない事故で、止まる故障より発見が遅れて損害が大きい。コストは追加ハードが要らないので実質ゼロ、工数は装置1台あたり2〜3日規模。注意点は、レシピ番号の一致確認を入れると今まで通っていた段取りで自動運転が掛からなくなる場合があること。導入直後は警報だけ出して自動運転は止めない「観測モード」を1〜2週間挟んでから、インターロックへ昇格させるのが安全。

これは検証の型がそのまま真似できる話で、「AIに仕様書を読ませる」ではなく「人が全部読む前提を崩さず、探し直す時間だけを削る」という切り分けが実務的に正しい。最初の一歩は、自分が過去に扱った客先仕様書を3〜5件選び、そこから毎回探す項目を列挙すること。挙がった項目名（検収条件、シグナルタワーの色と点滅パターン、増し締めマーキング色、非常停止の復帰手順、盤内温度の上限など）をスプレッドシートの列にする。ここまでは紙とExcelだけで、AIは要らない。次の段階が、その表を人手で1件ずつ埋めて所要時間を測ること。この投稿と同じで、測っておかないとAIを入れた効果が「なんとなく速い」で終わる。A4半ページで5〜10分という実測値は自分の比較基準としても使える。その次に、同じ仕様書PDFをGeminiやNotebookLMに投げ、「次の項目について、記載されている箇所のページ番号と原文をそのまま抜き出せ。書かれていない項目は『記載なし』と答えよ」という形で聞く。要約させずに原文抜き出しにするのが肝で、要約させると読んだ気になって検収で事故る。コストは手元のGemini／NotebookLMの無料枠で足りるので実質ゼロ、要るのは比較のための時間。注意点は2つ。客先の仕様書は秘密保持の対象なので、社外サービスへ上げてよいかを先に確認すること（社内規程で禁止ならローカルLLMかオンプレ環境の話になる）。もう1つは、AIの抜き出しを人の結果と突き合わせるときに「AIが拾えなかった項目」だけでなく「AIが拾ったが実は別の箇所だった項目」を必ず数えること。後者を数えないと、実運用で一番危ない誤りを見逃す。

「下書きの完成」と「送信してよいか」を別の状態として持つ、という発想は問い合わせ返信に限らず、こちらの業務でそのまま効く。最初の一歩は、いま自分がAIに書かせて外に出しているもの——客先への不具合報告メール、日報、部品の見積依頼——のうち1種類を選び、Googleスプレッドシートに5列のシートを作ること。列は「起票日時／対象（案件名）／AI下書きの有無／レビュー結果（送信・差し戻し・保留）／差し戻し理由」。この時点ではGASを書かず、手で埋めるだけでいい。1〜2週間埋めると、差し戻し理由に自分のパターンが出る。「型番が違う」「日付が今日になっていない」「客先名の表記ゆれ」のような、毎回同じところで引っかかる項目が見えるはずで、これが後でチェックリストの中身になる。次の段階でGASを入れる。スプレッドシートの拡張機能→Apps Scriptから、行が追加されたときに「保留」のまま24時間経った行へ色を付ける、あるいは自分宛にGmailで通知を出す、という程度の30行スクリプトで足りる。ここまで全部Googleアカウントの無料枠で動くのでコストはゼロ、着手から動くまで半日。次の段階は、差し戻し理由から抽出したチェック項目を、AIに下書きを書かせるときのプロンプト末尾に固定文で足すこと。「出力後、次の項目を自己点検して結果を表で示せ：型番の一致／日付／客先名の表記」のようにする。注意点は、ログを溜めること自体を目的にしないこと。列を増やしすぎると埋めるのが面倒になって3日で止まる。5列で始めて、埋め続けられたら足す。もう1つ、客先固有情報を含む下書きをシートに丸ごと貼らないこと。判定と理由だけ残し、本文は元のGmail下書きに置いたままにすれば、記録の粒度を保ちつつ情報の置き場所を増やさずに済む。

客先工場での不具合対応は、腕ではなく手順の有無で時間が決まる。最初の一歩は、この8原則をそのまま自分の現場用チェックカードに落とすこと。名刺サイズのカードに「①電圧で切り分ける ②開回路は電圧が残る ③半割法で範囲を半分にする ④交換前に理論と測定を一致させる ⑤根本原因まで戻る」の5行だけ書いて、テスターのケースに入れておく。次の段階は、直近3件の不具合対応を振り返って、どの原則を飛ばしたかを1行ずつ書き出すこと。おそらく多いのは原則7で、症状が消えたので部品を替えて終わりにしたが、なぜ壊れたかは分かっていない、という形になる。これが再発呼び出しの主因になっている。特に効くのが原則5の半割法で、盤内の配線が長い場合、端から順に当たるのではなく、経路の真ん中の端子台で1回測る。これだけで候補が半分になる。10箇所の候補なら順当たりで平均5回、半割で3〜4回。1回の測定に盤を開けて計器を当てる時間が5分かかるなら、実測で10分以上の差になる。コストはゼロで、要るのは事前に経路図の中点を決めておくことだけ。原則3も現場で効く形に落とせる。「電圧は来ているのに動かない」と言われたときに、電圧が来ていること自体は開回路を否定しないと知っていれば、負荷側で電流が流れているかを見に行く判断が早い。注意点は、この手順化を新人教育に使うときに、手順だけを覚えさせないこと。同じ日の別トピックでも触れられているが、手順だけ覚えた人は機種が変わると詰む。カードは判断の順番を思い出すためのもので、なぜその順番かは現物の前で説明する必要がある。

これは自分の担当設備で今日30分あれば着手できる話で、しかも放置したときの損害が一番大きい種類の課題である。最初の一歩は、担当設備を1台選んで「復元に必要なファイル」を数え上げること。挙がった4種——PLCプロジェクト（GX Works3の.gx3）、HMI画面データ（GT Designer3の.G32）、サーボアンプ／インバータのパラメータ、ロボットプログラムと画像処理レシピ——のそれぞれについて、最新版がどこにあるかを書く。「自分のノートPCのデスクトップ」と書く欄が1つでも出たら、そこが単一障害点になっている。次の段階は、共有フォルダに設備単位のフォルダを切って、命名規則を1つだけ決めること。`<設備名>_<データ種別>_<YYYYMMDD>_<担当者イニシャル>` で足りる。日付を入れるのが肝で、versionやfinalやfinal2は3か月で判別不能になる。ここまでコストはゼロ、社内共有フォルダかGoogleドライブがあれば追加費用は出ない。その次に効くのが、パラメータ類を「バイナリのバックアップ」だけでなく「人が読めるテキスト」でも残すこと。サーボアンプやインバータの設定値は、専用ツールでしか開けないバックアップファイルだけを置いておくと、5年後にツールのバージョンが変わって読めない。GX Works3ならデバイスコメントとパラメータをCSVで、インバータなら設定値一覧を画面から書き写したExcelで、二重に持っておく。テキストで残しておけば、差分の比較もできる。さらに一歩進めるなら、その共有フォルダを月1回だけ棚卸しする日を決めて、日付が3か月以上更新されていない設備を洗い出す。改造したのに戻していない設備が必ず出る。注意点は、客先設備のプログラムを自社の共有フォルダへ置いてよいかを先に確認すること。客先の資産扱いになっている場合があり、勝手に持ち出すと契約上の問題になる。その場合は「客先側のどこに最新版があるか」を記録するだけでも、次の呼び出しでの復旧時間が変わる。

欧州向けの設備を扱う案件では、これは近いうちに客先から降りてくる要求になる。最初の一歩は、いま自分が現場で使っている（あるいは提案しようとしている）AIが、この記事のいう高リスクの類型に触るかを確認すること。設備の異常検知や画像検査は基本的に触らないが、「作業者ごとの作業時間を計測して配置を決める」「カメラで作業者を識別する」に踏み込んだ瞬間に、オペレーターの行動モニタリングや遠隔生体識別の側へ寄る。提案書を書く前に線を引いておくと後で戻らずに済む。次の段階は、ログ設計を先に決めること。記事が挙げる「どのデータを使い、どのような判断ロジックで、誰が最終決定したか」の3点は、そのままスプレッドシートの3列にできる。AI異常検知を1ラインに入れるなら、判定ごとに「入力（センサ値・画像ID・時刻）／モデルの出力（スコアとしきい値）／最終判断者（誰が承認して設備を止めたか）」を残す。これはAI側の機能ではなく、こちらの運用設計の話なので、ベンダー製品を待たずに今日決められる。特に3列目の「誰が最終決定したか」が抜けやすい。AIがそのまま設備を止める構成にしていると、記事のいうヒューマン・イン・ザ・ループが成立しない。コストは、ログ列を足すだけならゼロ〜数万円（PLC側にロギング領域を確保する程度）。オンプレミスでモデルを回す構成にするなら、エッジPCで数十万円規模から。注意点は、この記事の適用範囲を自分の案件に広げすぎないこと。EU AI法は欧州市場に出るものへの規制なので、国内向け設備にそのまま義務が掛かるわけではない。ただしログ設計とヒューマン・イン・ザ・ループは、法規制と関係なく「AIが誤判定したときに誰が責任を取るか」の問題として国内案件でも要る。規制対応としてではなく、自分の身を守る記録として先に入れておくのが現実的である。

「入れる予定はあるが、運用の戦略が無い」という60%対40%のギャップは、現場で何が起きるかというと、ロボットが入った後に誰が面倒を見るか決まっていない状態である。フィールド側にいる人間としては、ここが仕事になる。最初の一歩は、担当している客先で協働ロボットや搬送ロボットが入っている（または導入の話が出ている）ラインを1つ選び、次の5項目を誰が持っているかを聞いて回ること。①日常点検（グリスアップ・原点確認）は誰が、どの頻度で。②教示データのバックアップはどこに、いつ取ったものが。③安全柵レスの場合、リスクアセスメントの見直しは誰の責任で。④停止したときの一次対応者と、呼ぶ先。⑤ソフトウェア更新の判断者。この5つのうち3つ以上に「決まっていない」が返ってきたら、この調査でいう「正式な戦略が無い」側にいる。次の段階は、そこを自分の提案枠にすること。ロボット本体は自分の商材でなくても、この5項目を埋める運用表と点検チェックシートを作って渡すのは、追加コストほぼゼロで信頼が積める仕事になる。特に②の教示データのバックアップは、同じ日の別トピック（担当者のPCにしか残っていない設定データ）とまったく同じ構造の問題で、ロボットが入っているラインほど深刻になりやすい。コストは自分の工数だけ、半日で雛形は作れる。注意点は、この調査の数字をそのまま客先の説得材料に使わないこと。海外を含む調査であり、日本の中小製造業の実感とはずれる可能性がある。使うなら「業界全体では入れる前提で動いている」という背景説明までにとどめ、説得は客先自身の5項目の答えでする方が効く。

現場で移動中や客先の合間にスマホからカレンダーへ放り込んだ予定を、夕方に見返す用途がそのまま当てはまる。最初の一歩は、まずデモを開いて動きを確認すること。Googleアカウント不要のサンプルデータで動くので、自分のカレンダーを繋ぐ前に「作成日時順で並ぶと何が見えるか」が分かる。ここまで5分、費用ゼロ。次の段階は、GitHubのソース（MITなので改変・社内利用に制約が少ない）を自分のApps Scriptプロジェクトへコピーして、自分のカレンダーに向けること。Apps Scriptはブラウザだけで動き、Googleアカウントがあれば追加費用は出ない。ここまでで、その日に自分が入れた予定だけを作成順に並べられる。実務への落とし方はここからで、「予定を入れた順」で並ぶと日報が書きやすい。客先で「来週また来ます」と言ってその場でカレンダーに入れた案件が、夕方に作成順で並ぶので、日報の訪問記録と次回予定をそのまま転記できる。時系列が行動順と一致しているのが効く。さらに一歩進めるなら、出力を日報のフォーマットに寄せて、Apps Scriptから自分宛にGmailで送るところまで足す。追加は20行程度。もっと踏み込むなら、その出力をGeminiに渡して「この日の行動から日報の下書きを作れ。訪問先・対応内容・次回予定の3項目で」と投げれば、下書きまで自動化できる。注意点は2つ。カレンダーの予定名に客先名や不具合の内容がそのまま入っている場合、外部サービスへ渡す前に社内規程を確認すること。もう1つは、他人のソースをそのまま社内で動かす前に、どのスコープ（権限）を要求しているかを確認すること。カレンダーの読み取りだけで済むはずのものが書き込み権限を求めていないか、Apps Scriptの承認画面で確認してから許可する。

自分の使い方に直せば、これは「Claude CodeやGemini CLIに作業させているディレクトリに、平文のトークンが置かれた設定ファイルがあるか」という話である。最初の一歩は、AIエージェントを動かしている作業フォルダで `.env`、`config.json`、`credentials.json`、`*.pem` を検索して、中身に生のキーが入っているものを数えること。エージェントはそのフォルダを読めるので、置いてあれば読める。ここまで10分、費用ゼロ。次の段階は、ツールを入れる前に置き場所を変えること。キーを作業フォルダの外（ホーム直下の権限を絞ったディレクトリ、あるいはOSのキーチェーン／Windows資格情報マネージャー）へ移し、エージェントを起動するシェル側で環境変数に展開してから起動する。これだけで「エージェントがファイルとして読める」経路は消える。trustless のような broker を挟むのは、この次の段階の話で、複数のキーを扱っていて起動コマンドごとに必要なキーだけを渡し分けたくなったときに効く。単一静的バイナリで外部依存が1つなので、業務PCに入れる際の審査も通しやすい部類ではある。コストはOSS前提でゼロ、要るのは起動手順を変える手間だけ。注意点は、環境変数に入れれば安全というわけではないこと。エージェントがシェルコマンドを実行できる構成なら、環境変数も読める。本当に守りたいキー（課金に直結するAPIキー、客先システムの認証情報）は、そもそもエージェントを動かすマシンに置かないのが一番強い。この記事の「値は起動時にだけ注入する」という考え方は、露出時間を短くする方向の対策であって、露出をゼロにするものではない、と理解して使い分けるのがいい。

この話は「AIに手順書を書かせて、それをAIに読ませる」という運用をしている人全員に刺さる。自分の使い方に落とすと、GeminiやClaudeに毎回貼っている定型プロンプト、CLAUDE.md のようなルールファイル、社内で共有している「AIへの聞き方テンプレ」が対象になる。最初の一歩は、いま自分が使っている定型プロンプトを1つ選び、それを付けた場合と外した場合で、同じ質問を3回ずつ投げて出力を比べること。比較の題材は自分の実務から取る——たとえばGX Works3のタグ表CSVを渡して命名規則の例外を挙げさせる、あるいは不具合報告メールの下書きを書かせる。3回ずつ比べるのは、1回だと偶然のばらつきに騙されるから。ここまで30分、無料枠でできる。次の段階は、比較の判定基準を先に決めておくこと。「短い方がいい」ではなく「例外を何件拾えたか」「型番の誤りが何件混ざったか」のように数えられる形にする。これがこの記事のいう Eval に当たる。数えられる形にしないと、なんとなく良くなった気がする、で終わって、劣化していても気づけない。実際に外した方が良かったという結果が出ることがあり、そのときは素直に消す。プロンプトは足すほど良くなるものではない。注意点は、社内で共有しているテンプレを勝手に消さないこと。自分の手元で比較して劣化を示せたなら、その比較結果ごと共有する。「なんとなく効かない気がする」では通らないが、3回×2条件の出力を並べて「例外検出が5件から2件に減った」と示せば話が早い。

制御設計はソフト開発とは別の世界だが、この数字は「ツールを選ぶときの周辺情報の量」に効いてくる。週1回以上使う人が90%まで来ているということは、詰まったときに検索して出てくる事例・回避策の量が、他のツールと桁で違う段階に入っているということである。最初の一歩は、いま自分が業務で使っているAIツールが1つだけなら、シェア上位のものを1つ触っておくこと。制御設計の実務で試す題材は決まっていて、ラダーのコメント整備、タグ表の命名チェック、客先仕様書からの項目抜き出し、日報・報告書の下書き、この4つで比べれば自分の用途での差が出る。無料枠で足りる範囲から始めればコストはゼロ、有償にしても個人利用で月20〜30ドル程度の水準。次の段階は、業務PCで使ってよいかを社内で確認すること。ここが実は一番時間がかかる。シェアの数字は、情報システム部門に説明するときの材料としては使える（「一部の人が使っている珍しいツール」ではないという説明）が、それだけでは通らない。通すために必要なのは、何を入力するか（客先情報を入れない・図面を上げない）と、どこにデータが残るかの2点を先に自分で書いておくこと。注意点は、シェアが高いことと自分の用途に合うことは別だということ。この調査の対象はプロの開発者であり、制御設計者ではない。開発者向けの評価軸（コード生成の精度、IDE統合）で1位のものが、日本語の仕様書読解や報告書の下書きで1位とは限らない。上に挙げた4つの題材で自分で比べるのが結局早い。