2026年8月7日

異メーカーPLC間接続は、客先の既設が Rockwell で自社標準がキーエンス／三菱という案件で必ず出る。最初の一歩は、この連載の第7章から第10章までを1時間で通読し、「タグ通信で組む場合」「PLCリンクで組む場合」の作業項目を紙1枚の対比表にすること。ポイントは作業量ではなく「どちら側のプロジェクトを開く必要があるか」で、客先PLCのプロジェクトを触らせてもらえない案件では、この一点で選べる方式が決まる。次の段階は、その対比表を自分の見積テンプレに「異メーカー接続の方式選定」という1行として組み込み、方式ごとの設定工数（半日／1日）を持っておくこと。見積段階で方式を決めておけば、現地で「客先PLCは開けません」と言われたときの手戻りがゼロになる。さらに進めるなら、対比表をそのまま Gemini や Claude に貼って「この2方式で、通信異常時に検知できる／できない事象をそれぞれ列挙して」と聞くと、正常時の疎通確認では見えない差分が出てくる。コストは、読むだけならゼロ円。実機検証は KV-XLE02 か客先の予備機が要るので数万円〜借用、生成AIへの相談は無料枠で足りる。注意点は2つ。1つは、片側から相手のタグを直接読み書きする構成にすると、相手側の変更履歴に自分の通信が残らないこと。客先の保全担当が「誰も触っていないのに値が変わる」と混乱するので、接続仕様書に「どのタグを誰が書くか」を必ず書いて渡す。もう1つは、実機で確認できた＝本番で成立ではないこと。更新周期と通信異常時の挙動は、方式ごとに別途詰める。

インバータ設定は「触る人によって手順が違う」典型で、その属人性がそのまま立ち上げ時間の差になる。最初の一歩は、この記事をベースに自社版の「FR-E 試運転チェックシート」をA4一枚で作ること。項目は、モータ銘板から写す定格値、上限周波数、加減速時間、運転モードの切り替え、単体動作の確認、PLC連動の確認の順に並べる。既に頭に入っている人ほど省略しがちな順序を、紙で固定するのが狙い。次の段階は、そのチェックシートを Google スプレッドシートに移し、案件名・号機・設定値を1行1台で残す運用にすること。3案件も溜まれば「同じ負荷なのに加減速時間が倍違う」といった自社内のばらつきが見える。さらに進めるなら、その表をそのまま Gemini や Claude に貼って「この設定値の組み合わせで危ない箇所を、過負荷と過電圧の観点から指摘して」と聞く。生成AIは銘板の読み違いまでは見つけられないが、表の中の外れ値は拾ってくれるので、レビューの一次フィルタとして使える。コストは、チェックシート作成もスプレッドシート運用も生成AIの無料枠も込みでゼロ円。既存のインバータと工具だけで今日から始められる。注意点は、FR-E700 と FR-E800 で番号がほぼ共通だからといって設定値をそのまま横流ししないこと。後継機は新機能の追加でパラメータが増えているので、旧機種の設定表を丸ごとコピーした運用にすると、増えた項目が初期値のまま放置される。世代を跨ぐときは「共通のもの」と「E800 で増えたもの」を表の中で列を分けて管理する。

ここで言われている「正常運転中の信号を残す」は、言うのは簡単だが実際にやっている現場は少ない。最初の一歩は、次のPLC更新案件で切替の2週間前に現地へ行き、GX Works3 のリアルタイムモニタか既設のロギングで、正常運転1サイクル分のデバイス値を CSV に落とすこと。全点は要らない。上流・下流とのインターロック信号、起動シーケンスのステップ番号、ワーク受け渡しの完了ビット、この3系統だけで十分に効く。半日で終わる作業が、切替当日の「これは元からこうだったのか？」という迷いを消す。次の段階は、その CSV を新PLCの同条件の実測と並べて Gemini や Claude に貼り、「2つの波形で、ビットが立つ順番が入れ替わっている箇所を列挙して」と頼むこと。人間の目でタイムスタンプを追うと数百ミリ秒のずれは見落とすが、表にして機械に比べさせれば拾える。さらに進めるなら、切替当日の判断基準を紙1枚にして、着手前に客先の生産管理と一緒にサインしておく。書く項目は3つだけでいい。調査の打ち切り時刻、継続してよい状態の定義、旧PLCへ戻す判断の担当者名。これがないと、深夜に一人で「あと10分だけ」を繰り返すことになる。コストは、ロギングも比較も生成AIの無料枠も込みでほぼゼロ円。既設にロガーが無い場合だけ、簡易ロガーのレンタルで数万円を見ておく。注意点は、旧PLCへ戻す手順は「戻せるはず」ではなく実際に一度リハーサルしておくこと。バックアップは取ったが復旧に必要なケーブルとソフトのバージョンが手元に無かった、というのが一番よくある詰み方で、当日の現場では取り返しがつかない。

設計側でこれが刺さるのは、週次の進捗報告と部材の納期一覧という2つの定型帳票。最初の一歩は、いま手で作っている報告書の中から「毎週同じフォーマットで、元データがスプレッドシートにある」ものを1つ選び、記事の週次レポートのコードをコピーして列番号と宛先だけ書き換えること。所要は1〜2時間で、以後は毎週30分が浮く。次の段階は、案件別の設計進捗シート（図面番号・担当・ステータス・期限）を作って、毎週月曜9時に「期限まで3日を切った未完了の図面」だけを自分宛にメールさせるトリガーを組むこと。全件を送っても読まないので、閾値を跨いだ行だけを送るのがコツ。さらに進めるなら、社内チャットに Webhook で流す形に変え、上長と共有する。報告書を作る作業そのものが消えて、例外だけが流れてくる状態になる。コストは、GAS も Google アカウントの標準機能なので追加費用ゼロ。ただしメール送信は無料アカウントで1日100通の上限があるので、宛先を増やす運用にするなら Workspace アカウント（月額数百円〜／人）を前提にしたほうがいい。注意点は2つ。1つは、スプレッドシートから読んだ日付は Date オブジェクトとして返るので、文字列と比べようとして黙って0件になる事故が起きやすいこと。最初のテストは必ず「意図した件数が出るか」を手で数えて確認する。もう1つは、トリガーの実行時刻は指定時刻きっかりではなく前後にずれること。朝9時の報告に間に合わせたいなら8時台に寄せておく。

「アラートではなくアクションまでの経路が要る」という指摘は、振動センサーを付けたのに誰も見ていない、という日本の現場そのままに当てはまる。最初の一歩は、客先で既に鳴っている警報の棚卸しを半日でやること。直近1か月の警報履歴を出してもらい、「発報件数」「そのうち人が何か作業した件数」の2列だけを埋める。この比率が1割を切っていれば、センサーを増やす提案は通らないし通してもいけない。次の段階は、比率の低い警報を3つ選び、「この警報が出たら誰が何分以内に何をするか」を1行で書き切ること。書けない警報は閾値がおかしいか、そもそも要らない。ここまでは製品を買わずにできて、しかも今回の提携が狙っている「検知と実行の橋渡し」を人力で先取りできる。さらに進めるなら、その1行をスプレッドシートの点検記録テンプレに落とし、警報IDと作業内容を紐づけた台帳にする。将来 Fiix のような CMMS を入れる判断をするとき、この台帳がそのまま移行データになる。コストは、棚卸しと台帳作りは自分の工数だけでゼロ円。Fiix / Augury 側は提供開始が2026年9月予定で価格は公表されていないため、今の段階で見積を前提にした提案はしないこと。注意点は、客先に警報の稼働率を見せるときの伝え方。「9割の警報が無視されています」と言うと保全担当が責められている構図になるので、「今の運用で本当に効いている警報はこの3つ、という整理をしませんか」と持っていく。数字は同じでも、その先に協力が得られるかどうかが変わる。

客先工場での不具合対応は、現場でメモ→帰社してから報告書に清書、という二段構えになりがちで、ここがそのまま置き換わる。最初の一歩は、自分が普段書いている作業報告書の項目を10個以内に絞って AppSheet でフォームを1枚作ること。日付・客先・装置名・現象・処置・部品交換の有無・写真、この程度で足りる。AppSheet は Google アカウントがあればプロトタイプ作成まで無料で、ノーコードなので半日で動くものができる。次の段階は、記事の Webhook パターンで GAS を呼び、送信ボタンを押した瞬間に Google ドキュメントの雛形から報告書PDFを生成させること。現場を出る前に報告書が出来上がっている状態になり、帰社後の清書が消える。さらに進めるなら、生成した PDF のリンクを Slack や LINE にも流し、社内の応援要請を同じ一押しで済ませる。コストは、試作は無料プランで足りるが、本番運用でユーザーを増やすなら AppSheet の有料プラン（Starter / Core）への移行が前提になる。GAS 側は無料。注意点は2つで、どちらも記事に明示されている。1つは GAS の Web アプリを「全員」公開にする必要があるため、AppSheet から送るデータに秘密の認証トークンを含めて GAS 側で検証すること。客先の装置情報が入るフォームなので、ここを飛ばしてはいけない。もう1つは GAS の実行時間が最大6分である点で、写真の一括変換のような重い処理は分割して非同期に回すこと。最初は写真1枚から始めて、動いてから増やすのが安全。

官公庁がAI活用の方針を出したこと自体より、そこで挙がっているリスク2つが自分の使い方にそのまま当てはまる点が実利になる。最初の一歩は、自分が生成AIに貼っている内容を1週間分だけ振り返り、「客先名・装置名・図面番号・IPアドレスが含まれていた回数」を数えること。数えるだけで数分だが、たいてい自分で思っているより多い。次の段階は、貼る前に置換する自分用のルールを紙1枚で決めること。客先名は「A社」、装置名は「装置1」、IPアドレスは「192.168.0.x」に伏せる、と決め打ちしておけば、判断に迷う時間がゼロになる。ラダーのコメントやタグ名は客先の製品名がそのまま入っていることが多いので、コピーする範囲を狭める癖も同時に付ける。さらに進めるなら、「最終的な判断と責任は人間が担う」というこの方針の書きぶりを、そのまま社内でAI利用を提案するときの根拠に使う。反対されたときに個人の主張で押すより、官公庁が同じ整理をしていると示すほうが通りやすい。ハルシネーション対策としては、AIに型式や規格番号を出させたら必ずメーカーのカタログで裏を取る、という一手間を手順に固定する。コストはゼロ円で、今日から始められる。注意点は、伏せ字にすれば何でも貼ってよいわけではないこと。客先との秘密保持契約に「第三者のクラウドサービスへの入力」を制限する条項が入っていることがあるので、契約書の該当箇所を一度は自分の目で読んでおく。判断がつかないうちは、自分で書いたメモと議事録だけを対象にするのが安全側。

客先常駐の日は、日報を書く体力が一番残っていない時間に日報を書くことになるので、この2つの用途は現場エンジニアとの相性がいい。最初の一歩は、今日の作業から NotebookLM のノートを1つ立て、作業の区切りごとに「10:20 盤内点検、X10入力なし」のように1行だけ打ち込むこと。文章にしようとしないのがコツで、時刻と単語だけでいい。スマホのブラウザから打てるので、装置の前で立ったまま30秒で済む。次の段階は、退勤前に同じノートへ「この日のメモを、時系列の作業経過・確認した事実・未解決事項・翌日の予定の4項目で日報にして」と頼むこと。断片のメモから体裁の整った日報が出るので、あとは事実誤認だけ直して送る。5分で終わる。さらに進めるなら、案件ごとにノートを分けて1週間貯め、金曜に「この1週間で同じ現象が繰り返し出ている箇所を挙げて」と聞く。日報を書くための作業が、そのまま不具合の傾向分析になる。コストは、NotebookLM の基本的な読み込みと要約は無料枠で試せるので、まず1週間ゼロ円で回してから課金を判断すればいい。注意点は、現場で打つメモにこそ客先名・装置型番がそのまま入ることで、ここはクラウドに置いてよい情報かを先に確認しておく。判断が付かない間は、装置名を「1号機」のような自分だけが分かる符丁に置き換えて打つ運用にしておくと、後から困らない。もう一点、AIが生成した日報は事実の順序を入れ替えることがあるので、時刻が絡む記述だけは自分のメモと突き合わせてから送ること。

このキャンペーンで実際に成果が出たのは、ゼロデイではなく既知CVEが放置された機器だった点が自分の守りに直結する。最初の一歩は、社内と自分が関わった客先で「インターネットから直接見える管理画面」を洗い出すこと。VPN装置、リモートデスクトップのゲートウェイ、そして意外な盲点として社内で立てた開発ツール類のWeb UIが該当する。Shodan や Censys の無料枠で自社ドメインを引くだけで、今日30分でできる。次の段階は、洗い出した機器のファームウェア／バージョンを一覧にして、CVE番号と突き合わせること。ここは Gemini や Claude に「この製品のこのバージョンに該当する既知の重大脆弱性を、CVE番号と公開日つきで挙げて」と聞いて下書きを作り、必ずメーカーのセキュリティ情報ページで裏を取る。AIの回答をそのまま信じないのは、この記事の攻撃側が jailbreak したモデルを使っていたのと表裏の話で、防御側も出典確認を省いてはいけない。さらに進めるなら、社内で誰かが検証用に立てた n8n や Langflow のようなワークフローツールを対象に、認証が有効か・外から到達できるかを確認する。今回のキャンペーンでも、認証が有効だったインスタンスは悪用に至っていない。コストは、洗い出しも生成AIの下書きもゼロ円。パッチ適用の停止調整だけが工数になる。注意点は、客先の機器を自分の判断でスキャンしないこと。許可のないスキャンは不正アクセスと見なされ得るので、必ず客先の情シスの承認を書面で取ってから動く。自社資産と自分の検証環境から始めるのが安全。

ここで使えるのは1位という順位ではなく、「成功1件あたりコスト」という物差しのほうで、これは社内でAI利用を稟議に上げるときの武器になる。最初の一歩は、自分がよく投げるタスクを1つ決めて（例えばタグ表の命名規則チェック、あるいは仕様書からの機器リスト抽出）、同じ入力を手元の2〜3モデルに投げ、「使えた／手直しした／捨てた」の3判定を10回分だけ記録すること。1時間で終わるし、成功率が体感でなく数字になる。次の段階は、その表に所要時間と概算トークン数を足して、1件を仕上げるまでの総コストを出すこと。単価の安いモデルが往復を増やして結局高くつく、という今回の指摘が自分の用途でも起きているかが分かる。制御設計の用途は往復が多くなりがちなので、ここは効く。さらに進めるなら、この10行の表をそのまま稟議の添付にする。「モデルAのほうが安い」ではなく「1件仕上げるまでの費用がモデルBのほうが安く、手直しが週2時間減る」と書けると、決裁の通り方が変わる。コストは、記録を取るだけなので実質ゼロ円（既存の無料枠・サブスクの範囲）。注意点は2つ。1つは、ベンチマークの順位を社内資料にそのまま引くのを避けること。今回のように制限時間の前提が違えば結果が逆転する以上、順位は根拠にならない。もう1つは、自分で取った10件の記録も母数として小さいので、「この用途ではこうだった」以上の言い方をしないこと。用途を跨いだ一般化をした瞬間に、指摘されて信用を落とす。

「自分の作品は自分で採点しない」は、そのまま設計レビューの型として使える。最初の一歩は、AIに何かを作らせたら、必ず別のチャットを新規に開いて「この成果物は誤りを含むと仮定して、根拠つきで欠陥を3つ挙げよ」と貼り直すこと。同じチャットで「間違いはない？」と聞くのは自己採点なので効かない。タブを1つ増やすだけで、今日から無料でできる。次の段階は、自分の業務ごとに役割を分けたフォルダを作り、そこに指示ファイルを1枚ずつ置くこと。制御設計なら「ラダー命名規則チェック係」「仕様書の抜け探し係」「客先向け文面の推敲係」の3つで足りる。それぞれのフォルダに「前回こう間違えた」を1行ずつ書き足していくと、数週間で自分専用の別々の担当者になる。この「却下の理由を書き戻す」部分が一番面倒で、一番効く。さらに進めるなら、レビュー係の指示ファイルに「合格を出す前に、必ず出典または実機での確認方法を1つ書け」という条件を足す。生成AIの一番怖い失敗は自信のある嘘なので、確認方法まで書かせておくと自分の手戻りが減る。コストは、無料枠と既存のサブスクの範囲でゼロ円。ファイルはローカルのテキストで十分で、特別なツールは要らない。注意点は、役割を増やしすぎないこと。3つを超えると指示ファイルの更新が止まり、更新が止まった役割は普通の一発質問と同じ精度に戻る。まず1つの役割を2週間続けてから増やすのが現実的。あわせて、記事にある90.2%という数字は特定のベンチマーク上の話なので、自分の業務でそのまま出る改善幅として社内に説明しないこと。