2026年10月21日

中核モデルをドメイン特化型言語モデル（DSLM）と見なすことも誤解に挙げ、中核的な役割を担うのは物理世界の状態や変化を理解・予測する「World Model」と、視覚情報や言語による指示を実際の行動につなげる「Vision-Language-Action（VLA）」などのモデルで、これらを組み合わせて認識・予測・判断・行動を一連の仕組みとしてつなげることが重要だとする。「製造データや現場の暗黙知を持つ日本企業は自然と競争優位性を持つ」も誤解とされ、データや暗黙知は強みになり得るとしながらも、保有しているだけで競争優位に立てるわけではなく、工場、設備、業務プロセス、人と機械の役割分担そのものを再設計し、計算基盤、AIモデル、データ、人材への投資判断まで含めて考える必要があるとしている。「リアルタイム制御のためエッジやオンプレミスだけで構築する必要がある」という見方も誤解で、現場に近い基盤でリアルタイム処理を実行しつつ、大規模な学習やシミュレーションにはクラウドを活用するなど、処理の特性に応じて全体を設計することが重要だとする。第10の誤解は「高度化すれば完全無人化が最終形になる」という考え方で、目的は自動化率や自律度を最大化することではなく、人、AI、機械の役割を再設計し、安全性、生産性、品質、柔軟性を最適化することだと説明している。ガートナーの亦賀忠明氏（ディスティングイッシュト バイス プレジデント アナリスト）は、既に「フィジカルAIを使う」段階から「フィジカルAIを前提として、企業の形、仕事の進め方、工場、インフラ、業務そのものを再定義する」段階へ移行していると述べる。着手の進め方としては、最初から企業全体をフィジカルAI化するのではなく対象領域を限定し、現場、デジタルツイン、World Model、制御、データ基盤をつないだ最小の完成形を構築してから段階的に対象を広げる方法を示しており、人材面ではWorld Model、ロボティクス、制御、シミュレーション、IT／OT、安全、データ、業務を横断して実世界に実装できるフォワードデプロイドエンジニア（FDE）のような高度専門人材の確保・育成が課題になるとしている。

記録の選び方としては、一定の間隔で記録し続ける方法と、異常などのきっかけの前後を残す方法があり、どちらが良いかではなく「何を調べたいか」で使い分ける、傾向を見たい値は連続して、突発的な停止は前後を残す組み合わせも考えられるとしている。記録項目は役割で分けると漏れに気付きやすいとして、運転の状態（運転・停止、自動・手動、段取り中）、異常・警報（異常の番号、発生と解除の時刻）、入力の変化（センサー、リミットスイッチ、押しボタン）、出力の指令（電磁弁やモーターへの運転指令）、数値（温度・圧力・電流など）、生産の数字（生産数、1回の動作にかかった時間）の6区分を挙げ、全部をそろえる必要はなくその設備で困っている止まり方に関係する行から選ぶとする。核になるのは「指令」と「結果」を組で残すことで、シリンダーを前に出す指令だけを記録していると分かるのは「指令は出ていた」ことだけだが、前進端センサーの入力も同じ時刻の並びで残しておけば「指令から何秒で入ったか」「入らなかったのか」を比べられると説明する。読み分けの例として、普段どおりの時間で入った／普段より遅れて入った（動きが重くなっている可能性）／入らなかった（動作しなかったかセンサー側で検出できていない）／指令が出ていない（前の条件がそろわず指令まで進んでいない）の4パターンを示し、記録から分かるのは信号の並びと時間までで、実機が正しく動いたかどうかは現場で別に確かめる必要があると断っている。既設PLCで始める前の確認としては、記録の機能を使えるかどうかがPLCの機種、本体のソフトウェア（ファームウェア）の版、製造番号によって変わることがあり、同じ三菱電機の紹介ページでもロギングファイルの自動転送の機能には対象となるCPUの製造番号の条件が書かれているとして、まず盤内のPLCの正確な型式を確認してメーカーのマニュアルで対応を調べることを挙げる。あわせて保存先（メモリカードなど）の容量、PLCの時計が合っているか、記録の設定が制御の動きに影響しないかもマニュアルの記載で確認し、既設のプログラムや設定を変える作業は設備の安全手順と社内の手順に従って止められる時間に計画して行い、変更前のプログラムと設定のバックアップも取るとしている。新しい機種については、キーエンスのKV-8000シリーズの製品ページ（英語）で「Machine Operation Recorder」として、機器やカメラ、イベントのデータを自動で記録し、問題が起きる前からの様子を連動して再生できる機能が紹介されていると書いている。

手順は、集計先シートの1行目に「週開始日」「カテゴリ」「合計時間(h)」のヘッダーを手動で入力し、スプレッドシートの「拡張機能」→「Apps Script」からコードを貼り付け、コード上部の `SPREADSHEET_ID`（スプレッドシートのURLの `/d/` と `/edit` の間の文字列）、`PREFIX_MAP`（プレフィックスとカテゴリ名の対応）、`SHEET_NAME`（集計シートのタブ名）の3カ所を書き換える流れになっている。関数 `aggregateWeeklyWorklog` は先週の月曜〜日曜を計算し、`CalendarApp.getDefaultCalendar()` の `getEvents(開始, 終了)` で期間内の予定を取得して、`getStartTime()` と `getEndTime()` の差分から所要時間を分で計算し、タイトルの先頭が `PREFIX_MAP` のプレフィックスと一致すればそのカテゴリへ、一致しなければ `DEFAULT_CATEGORY`（「未分類」）へ加算する。終日イベントは時間計算できないのでスキップし、最後に `sheet.appendRow()` でカテゴリごとに「週開始日・カテゴリ・合計時間」の行を追記する（合計時間は小数点1桁に丸め、週開始日は `Utilities.formatDate` で "Asia/Tokyo" の `yyyy/MM/dd` 形式）。トリガーは、スクリプトエディタのトリガー画面で実行する関数に `aggregateWeeklyWorklog`、イベントのソースを時間主導型、タイプを週ベースのタイマー、曜日を月曜日、時刻を午前8〜9時に設定する例を挙げている。つまずきポイントとして、`CalendarApp.getDefaultCalendar()` はデフォルトカレンダーのみ対象なのでチーム共有カレンダーを使っている場合は `CalendarApp.getCalendarById(カレンダーID)` に変更する、時間がずれる場合は「プロジェクトの設定」でタイムゾーンを「Asia/Tokyo」にする、終日イベントも集計したい場合は `isAllDayEvent()` でのスキップを外して480分（8時間）の固定値として扱う改造例、`appendRow` で追記する設計のため同じ週を2回手動実行するとデータが重複する、の4点を挙げている。応用として、プレフィックス運用が難しい場合は `event.getColor()` で取得できる色IDとカテゴリを対応させる `COLOR_MAP` に置き換える方法、月次でまとめたい場合は週の開始日をキーに `SUMIF` で集計するか月次集計用の関数を別途追加する方法を示している。

PLCの入力ユニットは電流が小さい機種が多く、筆者が使っている三菱の入力ユニットもおよそ4mAだったとしている。対策は、最小適用負荷が1mAのリミットスイッチへの交換で、4mAの電流なら仕様の範囲に収まるという判断。ほかに検討して見送った対策として、近接センサーへの変更（配線や電源の改造範囲が広く費用対効果が合わない）、リレー受け（改造範囲が広く盤内に空きがない）、抵抗を追加して電流を増やす方法（電流は増えるが配線工事と図面の修正が必要で、抵抗が断線すると元の不安定な状態に戻り気づきにくく、後から見た人が「なぜ抵抗があるのか」を分からないという問題も出る）の3つを挙げ、スイッチの交換は配線と図面の変更がほぼなく原因そのものを取り除けるため採用したとしている。ただし交換できる製品がない場合やすぐに対処したい場合は抵抗の追加も選択肢になり、その場合は図面に反映して現場にも目印を付けることを勧めている。メーカーごとの違いについては筆者が確認した範囲として、A社のリミットスイッチは多くの型式で最小適用負荷が10mAで1mA対応品は見つからず、B社には1mA対応品があり、カタログでは信頼性の水準を示す形で最小適用負荷が書かれていたと記している。確認の手順は、PLCの入力ユニットの入力電流を仕様書で調べる（できれば実測する）、リミットスイッチの最小適用負荷をカタログで調べる、入力電流が最小適用負荷を下回っていたら要注意として微小負荷対応品への交換や無接点センサーを検討する、の3段階。まとめでは、装置メーカーが作った設備でもこの組み合わせが残っていることがあり、見た目では分からず不具合が間欠的に出るため原因の特定に時間がかかること、同じ構成の箇所を水平展開で確認する価値があることを挙げ、交換後は1年再発していないとしている。数値や製品の仕様は記事の執筆時点で筆者が確認した範囲のものであり、実際の選定では最新の仕様書・カタログを確認するよう注記されている。

メーカーが示す寿命として記事が挙げるのは、三菱電機が2026年9月7日公開の公式FAQで、MELSECシーケンサ本体の耐用年数について10年を目安とすると説明していること。ただし使用環境や運転条件によって異なるとされる。予防保全のための推奨交換周期としては、アルミ電解コンデンサを重要部品として使用するユニットが5年、その他のユニットが5〜10年と記載されている。記事はここで注意点として、耐用年数の10年がすべてのPLCに適用される法定交換期限ではないこと、バッテリやリレーなどの有寿命部品は本体の耐用年数とは別に管理する必要があることを挙げる。また、製造から20年以上経過しても稼働しているPLCはあり得るが、長期間動いていることは今後も安定稼働することを保証しないとしている。そのうえで筆者は、設備保全の実務上の考え方として使用年数ごとの目安を示している。使用5年で電源ユニットなど有寿命部品の点検・予防交換を検討、使用10年で後継機種、保守終了時期、更新費用の調査を始める、使用15年で重要設備について具体的な更新計画を策定する、使用20年以上は保守終了や予備品の枯渇を前提に更新の緊急性を評価する、という4段階だ。記事はこれが筆者が提案する管理指針であり、各メーカー共通の寿命基準ではないと明記しており、実際には使用年数だけでなく設備の重要性によって判断を変えるべきだとしている。

そのためCLIベースのAIコーディングツールは導入自体に環境構築が要る時点でハードルが上がり、筆者がデスクトップアプリ側（Claude Desktop）を選んだ理由の一つがこれだったと書く。追加のランタイムなしでフォルダを繋ぐだけで使える形は制約の多い現場と相性がよく、ツールを選ぶときは「技術的な強さ」だけでなく「自分の環境で実際に動かせるか」を同じくらい重く見るべきで、使えないツールはどれだけ高機能でも現場では価値がゼロになるとしている。許可されていないものを黙って入れるのは後で自分の首を絞めるとして、手順を踏んで許可を取るか、許可されている範囲で工夫するかのどちらかだと書く。2つ目は、情報をどこまで渡してよいかという制約。FAのコードや仕様書には客先名、装置構成、レシピ、過去案件の数値といった外に出せない情報が含まれるため、筆者は何を読ませているかを自分で把握し、フォルダ接続で繋ぐフォルダを記事・個人検討用と業務資料用で分け、業務コードをそのまま記事や外部に出さないという線引きを最初に決めている。AIに渡す前に「この情報が外に出ても問題ないか」を一度考える癖をつけ、特定の装置の設定値や客先の要求そのものなら渡し方を考える、装置名や数値を伏せて構造だけの質問に変えれば聞きたいことの大半は聞けるとして、「この構造のFBで、異常からの復帰をどう書くか」という聞き方を例に挙げる。3つ目は成果物の権利と公開のルールで、業務で書いたコードには職務著作の問題があり、実務で得た知見を書くのと実務の成果物を持ち出すのは別のことだと整理している。進め方としては、制約の多い環境でAIを使い始めるならいきなり本番のコードで使わず、業務と切り離した題材（汎用のサンプルを書かせる、公開されている仕様を要約させる）から入り、AIの癖と自分の使い方の癖を掴んでから業務に近い題材へ広げることを勧める。周りへの説明については、「AIが全部書く」という説明は警戒されるため「たたき台を速く作らせて、検証は今までどおり人がやる」という説明のほうが通りやすく、実際に検証の工程は減っておらずむしろ重くなっていると書く。効果を語るときは盛らず、数値を出すなら出せる根拠を持ってからにするとしている。さらにFAならではの実務として、装置に入れるコードは誰がいつ承認したかを追えるようにしておくことを挙げ、AIが書いたコードでもレビューして実機に入れると決めたのは人であり責任は承認した人にあるとして、生成したコードのどこをどう直し誰が最終確認したかを簡単に記録していると書く。記録は凝らなくてよく、ファイル名にレビジョンを付け、変更点と確認者を1行ずつメモに残す程度で、gitが使えない環境なのでファイル名のレビジョンとメモが版管理の代わりになるとしている。

最も活発なクラスタは中国語を使い、関連する可能性が高い14パネルで1,100超の攻撃プロジェクトを持ち、標的は主に米国、日本、豪州の組織で、認証不要のRCEの発見とアップローダー型Webシェルの設置が目標として与えられていた。別の報道を含む整理では、中国語を使う攻撃者は9月25日から米国、カナダ、豪州、日本のECサイトを標的にし、1,200超のサイトへの侵入を試み、侵入に成功したのは100社超とされる。NorForgeは観測した作戦で使われたハーネスの平均成功率を約10%と推定しており、目標に到達したタスクは開始から達成までが平均23時間弱、1プロジェクトあたり平均140のファクトを生成したとする。費用については1タスクあたり平均約5ドル、トークン費用は総額約5,000ドル、成功1件あたり約50ドルという推定が示されている（テクノエッジの記事では総額約5000ドルを約79万円、1件約50ドルを約7900円と換算している）。使用モデルについてNorForgeは、ワーカー名からClaude CodeのハーネスでDeepSeekのモデルを使う構成を意味しうるとしており、DeepSeekとClaude Codeを混用しているように見えたともされる。公開されたパネルには、エージェントが調査で見つけた標的の情報、見つかった弱点、侵害の有無に加え、別の場所で入手した資格情報を含む人間の入力も残り、NorForgeがシークレットスキャナーのTrufflehogを実行したところ、さまざまな種類の秘密情報が数百件見つかり11%が有効と検証された。プロジェクトの開始と停止、進行中の作戦への介入、データの挿入、エージェントの向け先の変更、過去のプロジェクトの再開といった管理機能が認証なしで露出しているように見えるとも指摘している（これらの管理機能が認可なしで実際に動作するかは試していないとしている）。公開状態だったのは悪意ある活動に限らず、正規のレッドチームの活動とみられるものも相当数が同じように露出しており顧客を危険にさらしうるとしている。被害企業については、Reutersがパネルの活動記録を独自に調べ、Deere、SharkNinja、Cumminsが含まれることを特定した。Cairnの作者は10月8日のX投稿で、Cairnは「hacking tool」ではなく汎用の状態空間探索エンジンであり、ペネトレーションテストは考え方を検証した最初の領域にすぎないと説明し、「Misuse is a human decision, not a feature of the engine」と述べている。NorForgeは、CairnをはじめとするオープンソースのAIエージェントプラットフォームを公開・運用する組織に対し、インスタンスが認証なしでインターネットからアクセス可能な状態になっていないか早急に確認するよう呼びかけ、AIエージェント基盤の展開に際してはデータベースや管理パネルと同様に、デフォルトでの認証設定・ネットワーク分離・ログ監視を徹底することが重要だとしている。

同庁の調査によると、こうした高度なAIエージェント環境を、一般の職員も日常業務で使える政府共通基盤として約18万人規模で導入するのは世界初の試みだという。AIエージェントは源内がこれまで提供してきた機能より高度かつ複雑で、実行できる処理の範囲も広いとして、職員が安全に使うためのルール「ガバメントAI 源内 ガバナンス・セキュリティ・セーフティに関する基準」（源内基準）を策定し、同日公表した。源内基準は「利用者」「管理者」「開発者」の立場ごとに責務と遵守事項を定めたもので、AIの安全性評価を担うAIセーフティ・インスティテュート（AISI）の協力を得てまとめられた。デジタル庁の古川俊治大臣は同日の記者会見で、AIエージェントの導入をこれから検討する自治体や民間企業が、自らの組織でAIの統制を考える際にも源内基準が参考になるとの考えを示し、政府が開発した利用環境を民間に広げる意義を問われた際には「AIエージェントを使うことでリスクも若干上がってくる。これを安全に、信頼できる環境で使っていくためには、政府がまず率先して取り組み、広げていくことに意義がある」と答えた。エージェントチャットと源内工房は、誰でも利用・改変・再配布できるオープンソースソフトウェア「源内OSS Ver.2.0」として、2027年2月ごろをめどに一般公開する予定とされる。源内自体はデジタル庁が内製した生成AIの活用環境で、25年5月に同庁内で利用を始め、26年5月には全府省庁の職員約18万人を対象とする大規模実証を開始しており、法制度の調査や国会答弁の作成支援などに活用され、実証期間は27年3月までの予定だという。