2026年10月1日

最初の一歩は「試す前に測る」こと。11月4日のトライアル開始まで1カ月あるので、その間に自分の手元で「仕様書が残っていない旧設備の改造箇所を特定するのに、実際どれだけ掛かっているか」を1件だけ計測しておく。対象を1プロジェクト決めて、ラダーを開いてから改造範囲が確定するまでの実時間と、誰に何回聞いたかをメモするだけでよい。これがないと「4日へ短縮」の数字を自分の現場に当てはめられず、社内説明が印象論になる。
次の段階は、トライアル申込の判断材料を2つそろえること。1つは対象PLCで、この製品はCJシリーズとCX-One向けなので、自分が触っている盤のPLCがCJ2M／CJ1系なのかCP/NJ系なのかを台帳で数える。CJ系が一定数あるなら候補、ほぼ無いなら今回は見送って情報収集に留める。もう1つは持ち出し可否で、解析時はインターネット接続が必要かつ顧客プログラムをクラウドのLLMへ送る構成なので、客先資産を外へ出せるかを先に確認する。ここは技術判断ではなく契約とNDAの話なので、営業・品質と一緒に詰める。
コスト感は、トライアル期間中の申込ならBasicライセンスが2カ月無償なので、評価フェーズの実費はゼロで済む。正式販売は2027年2月で価格は未公表なので、今期の予算に入れるのではなく「来期の設計工数削減枠」として名前だけ置いておくのが現実的。BasicとPremiumの差は機能ではなくAI処理量なので、見積もり時は「月に何本のプログラムを解析するか」を先に決めてからグレードを選ぶ。
注意点は2つ。まず、要約と相関図は「読む手間を削る道具」であって、ラダーの読み方を知らない人が改造できるようになる道具ではない。出てきた要約の正しさを判定できるのは結局ラダーを読める人なので、若手に渡すときは必ずレビュー者を付ける。次に、入力を一般LLMの学習に使わない設計やプロンプトインジェクション検知が「設ける」とされている点は、自社のセキュリティ部門に仕様書ベースで確認してもらう。説明会の資料ではなく正式な仕様として書面で取ることを、トライアル申込の前提条件にしておくと後で揉めない。

最初の一歩は、自分が関わる案件の中に「欧州向け」または「将来欧州へ出る可能性がある」装置があるかを1枚に書き出すこと。輸出先が欧州にある案件は、安全系の適合証明をどこで取るかが設計初期の分岐になる。ここでコントローラー自身がEU型式認証を持っていれば、安全機能の妥当性を装置ごとにゼロから立証する部分を減らせる可能性がある。まず案件リストに「欧州向けフラグ」の列を足すだけでよい。
次の段階は、一般制御と安全制御を1台に寄せる構成の検討。今まで標準シーケンサ＋安全リレー／専用安全PLCの2系統で組んでいた盤を、iQ-Rの安全シーケンサ1台に寄せられるかを、既存案件1件で図面ベースだけ試算する。減るのは盤内スペース、配線、電源系統、それに安全側とのデータ受け渡し回路。増えるのはプロジェクト内での安全プログラムの分離管理と、レビュー体制。図面だけの試算なので実費はかからず、半日で結論が出る。
コスト感は、認証そのものは製品側の話なので追加費用はかからない。効く場所は、CEマーキング作業での技術文書作成工数と、第三者機関とのやり取りの回数。ここは1案件あたり数十万円規模の外部費用が動く領域なので、削れるなら効果が見えやすい。逆にハードは安全シーケンサのユニット単価が上がるため、盤の総額で比較する。
注意点は3つ。まず、コントローラーが認証を持つことと、その装置全体が機械規則に適合することは別物で、リスクアセスメントと装置単位の適合宣言は残る。次に、CC-Link IE TSNでの駆動機器連携が評価されているので、この構成の利点を取るならサーボやインバータ側もTSN対応で揃える必要があり、既存資産との混在は事前に確認する。最後に、認証の対象範囲・版・評価された構成は必ず三菱電機の正式資料で確認する。安全系は「記事で読んだ」では通らないので、客先へ出す前に一次資料を取り寄せる。

最初の一歩は、段1の仕様トレースだけを次の1案件で試すこと。AIにコードを書かせているかどうかに関係なく効く。やることは、着手時に入出力・状態遷移・異常時の振る舞いをテキスト1枚に書き、完成後にその1枚とプログラムを並べて「仕様の各項目がどのデバイス／回路で実現されているか」の対応表を作るだけ。GX Works3ならプロジェクトのコメントとラベル一覧をCSVで出しておけば突き合わせが早い。所要は1案件あたり1〜2時間で、費用はゼロ。
次の段階は、段2の机上トレース表をラダー向けに写すこと。記事の表はスキャンを縦・変数を横に取っている。同じ形をExcelで作り、行にスキャン1〜5、列に起動条件・自己保持・完了・異常保持を並べて手で埋める。ラダーで一番多い「2回目が起動しない」「異常が解除できない」の2パターンは、この5行の表でほぼ露出する。シミュレーション機能で追うのとは別に、紙で追う工程を1つ残す価値がここにある。
段3の独立レビューは、体制の話として読み替える。自分が書いたプログラムを自分でレビューしても効かないのは、AIでも人でも同じ。チェックリストを固定して、レビューする人には「回路を読む」のではなく「リストを潰す」ことだけを頼む。ラダー向けのリストなら、未初期化のデバイス、二重コイル、インターロックの抜け、異常時に出力が残る経路、保持デバイスの電源断後の扱い、タイマー値の直値埋め込み、あたりを7項目くらいに固定する。項目を固定すると、経験の浅い人でもレビュー役が務まる。
コストは無料枠で始められる。ChatGPTやGeminiの無料枠、もしくはClaudeの通常プランで、仕様書とコードを貼って対応表を作らせるところまでは追加費用なしで試せる。ただし客先のプログラムをそのまま貼るのは持ち出しになるので、まず自機の練習用プロジェクトか、変数名を伏せた抜粋で検証する。
注意点は、記事も明言しているとおり「AIのトレースを鵜呑みにしない」こと。AIが作った対応表やトレース表は、自分が追った結果との差分を見るために使う。差分が出たときに、AIが間違っているのか自分が読み違えたのか、コードが曖昧なのかを切り分ける。この切り分けができない状態でAIの表を信じると、検証工程そのものがハルシネーションの上に乗ってしまう。実機確認を省かないという最後の一線も、そのまま自分のルールに入れる。

この記事の価値は受注レポートではなく「集計はコード、文章化はLLM」という分け方そのもので、これは制御設計の報告書にそのまま効く。最初の一歩は、自分が毎月手で作っている表を1つ選ぶこと。候補は月次の不具合対応件数、客先ごとの立ち会い工数、部材の納期遅れ一覧あたり。それをスプレッドシートに1行1件で貯める形に直す。列は日付・客先・設備・分類・工数・備考の6列で足りる。ここまでは今日できる。
次の段階は、集計だけをGASに移すこと。記事のとおり getDataRange().getValues() を1回呼んで reduce で畳む形にすれば、月次の件数・分類別内訳・工数合計までは20行程度のスクリプトで出る。ここを先に固めるのが重要で、数字が確定してからしかLLMへ渡さない。数値をLLMに計算させない、という一点だけ守れば「報告書の数字が合っていない」という一番痛い事故は起きない。
文章化の段は、Gemini APIを使わずに手で貼るところから始めてもよい。集計結果のJSONをコピーして、Gemini やClaude の画面に「この数字だけを使い、推計と補完は禁止。3段落の平文で、最終行に合計工数」と指示して貼る。これで効果の有無が確認できる。効くと分かってからAPIキー（Google AI Studioで無料発行）をスクリプトプロパティに置き、UrlFetchApp で自動化する。
コストは、GAS自体は無料枠で足り、Gemini APIも月1回の呼び出しなら無料枠の範囲に収まる可能性が高い。実費が出るのは想定外に呼び出しを増やしたときだけなので、トリガーは月1回の時刻トリガーに限定し、手動実行でデバッグする。有償化の判断は、呼び出し回数が日次に増えてからでよい。
注意点は3つ。まず、客先名や設備名が入った実データを外部APIへ送る構成になるので、送る前に客先名を記号へ置き換えるか、社内規程を確認する。次に、記事が挙げているエラーの潰し方はそのまま真似する価値がある。muteHttpExceptions を立ててステータスコードを自分で見て、レスポンス本文の先頭を例外メッセージに混ぜておく。GASは失敗したときのログが薄いので、ここを省くと原因特定に時間を取られる。最後に、LLMが返した文章はそのまま送らず、数字が集計結果と一致しているかを目で1回確認する工程を残す。文章化を任せても、送信の責任は人に残る。

顧客への展開が2027年度からなので、今やることは導入ではなく「自分の担当設備で自律化の対象になる工程を名指ししておく」こと。記事が対象に挙げているのは、さまざまな形状の部品のピッキングと、生産品の変更に伴う段取り替え。この2つを自分の客先で探すと、だいたい「治具を人が差し替えている工程」と「バラ積みを人が整列させている工程」に落ちる。次回の立ち会いで、その工程の1サイクルの時間と、段取り替え1回にかかる分数を実測してメモするだけでよい。
次の段階は、その工程の現在のPLC側インタフェースを整理しておくこと。フィジカルAIのロボットが入るとき、既存設備との境界は結局PLCの入出力と通信になる。段取り替えなら「品種切替の指令はどこから来ているか」「段取り完了の確認は人の目か、センサか」を図面で洗う。ここが人の目だけなら、AIが入る前にまずセンサと完了条件を足す仕事が発生する。つまり今の準備作業は、AIとは無関係に効く「完了条件の機械化」になる。
コスト感は、この提携そのものに費用はかからない。効いてくるのは2027年度以降で、日立とファナックのインストールベース経由の提案になるため、自分の客先がファナックのロボットを既に使っているかどうかが分岐になる。使っているなら情報が入ってくる側、使っていないなら別ベンダーの同種提案と比較する側。まずは客先のロボットメーカーを台帳で確認しておく。
注意点は3つ。まず、これは共同実証の開始段階で、2027年度までに技術を確立する計画という段取りなので、今すぐ使える製品ではない。客先に紹介するときは「提携が発表された」までに留める。次に、検証対象として挙げられている認識精度・動作・タクトタイム・品質は、そのまま自分が提案を評価するときの4項目に使える。ベンダー提案が来たら、この4つの実測値を必ず聞く。最後に、エッジAI半導体との組み合わせも「有効性を検証する」段階の項目なので、構成が確定したものとして扱わない。

最初の一歩は、PDF版を落として2章2節（AIの安全性確保の取り組み）と1章（国内外のサイバー脅威の動向）だけ先に読むこと。白書は全部読むと重いので、自分に効く節を決めて読む。制御設計・現場対応の立場で効くのは、AIを悪用した攻撃の手口がどう高度化しているかと、サプライチェーン経由の被害事例。ここは客先の工場が「取引先経由で止まる」話なので、立ち会い時の雑談から提案につながる。無料で、今日読める。
次の段階は、読んだ内容を自分の持ち出し物の点検に落とすこと。フィールドエンジニアリングで一番現実的なリスクは、自分のノートPCとUSBメモリが客先ネットワークへ入る経路。白書の脅威動向を読んだ上で、(1) 持ち込みPCのOS・ウイルス対策の更新日、(2) 客先で使うUSBメモリの専用化と持ち出し記録、(3) プログラムのバックアップをどこに置いているか、の3点を棚卸しする。紙1枚で済み、費用はゼロ。
3つ目は、社内教育の材料として使うこと。白書はIPA自身が社内教育・自己研鑽での活用を想定しているので、章立てをそのまま勉強会のアジェンダに流用できる。若手向けなら「AIを悪用したサイバー攻撃への対処」の節を30分で読み合わせて、自分たちの持ち出し手順のどこが危ないかを1人1つ挙げさせる形が回しやすい。書籍版は10月19日刊行なので、机に置いて回覧する形が好みなら1冊買っておく。
コスト感は、PDF版は公開されているので0円、書籍版を買う場合でも数千円規模。中小企業の取引先を持つ客先には「SCS評価制度」「サイバーセキュリティお助け隊サービス（新類型）」の制度が制度構築として進められたと書かれている点を伝えるだけで価値がある。自分の勤め先が取引先から対策水準を問われる立場なら、ここは総務・情シスへ渡す情報になる。
注意点は、白書は制度と脅威動向の整理であって、制御系（OT）向けの具体的な設定手順書ではないこと。工場ネットワークの具体的な分離設計やPLCのセキュリティ設定は、メーカーのセキュリティガイドやIEC 62443系の資料に当たる必要がある。白書を読んで「何が問題になっているか」の地図を持ち、個別の対策は製品ドキュメントで詰める、という二段構えにする。

この統計の使いどころは「安全設計の優先順位を数字で説明できるようになる」こと。最初の一歩は、休業4日以上の原因内訳（転倒3万7195人 ＞ 動作の反動・無理な動作2万2166人 ＞ 墜落・転落2万864人 ＞ はさまれ・巻き込まれ1万3047人）を1枚にして手元に置くこと。設備側の安全対策は「はさまれ・巻き込まれ」に寄りがちだが、件数で見ると転倒と無理な動作が上位に来る。装置周りの床・段差・ケーブル配線・保守時の姿勢が、実は件数の多い領域だと示せる。
次の段階は、自分が設計・立ち会いする設備で「保守時の作業姿勢」を1件だけ見直すこと。盤の中の端子台が床から200mmにあれば、増し締めのたびにしゃがむ。フィルタ交換が頭上にあれば、無理な姿勢で上を向く。この2つは「動作の反動・無理な動作」に直結する。図面段階でできるのは、点検頻度の高い部品を作業しやすい高さへ寄せることと、点検口の前に足場を確保すること。追加費用はほぼゼロで、レイアウト検討の一項目を足すだけ。
3つ目は、高齢者と外国人労働者を前提にした表示・HMIの見直し。60歳以上が死傷者の31.3%を占め、外国人労働者の死傷者が約7000件・5.3%まで増えているという数字は、HMIの文字サイズと色、警告表示の多言語化を検討する根拠になる。GOT/HMIの画面なら、警告ポップアップのフォントを1段大きくする、アイコンと色で伝える、主要な操作手順だけ2言語併記にする、あたりが画面データの修正だけで実現できる。工数は1案件あたり数時間規模。
コスト感は、床・足場・表示の改善はほぼ図面と画面データの工数のみ。ここから先の「転倒防止のための5S」と安全教育は客先側の運用なので、自分は設備を渡すときの取扱説明書に点検姿勢と足場要件を明記する形で貢献する。無償でできる範囲が広いのが、この種の対策の利点。
注意点は、この統計は全業種の集計で、製造業の死亡者数（115人）と死傷者数（2万6371人）はいずれも前年より減っているという点を落とさないこと。「製造業が悪化している」という説明は数字と合わない。使えるのは「全体として高齢化と外国人労働者の増加が課題になっており、第14次労働災害防止計画でも課題とされている」という文脈で、自分の設備がその2つの層に使われる前提で設計する、という話に限る。数字を客先へ出すときは、必ず出典の年と定義（休業4日以上）を添える。

制御設計の側から見ると、この製品の要点は「PLCやAPIを介した工場設備との連携にも対応する」の一行にある。最初の一歩は、自分の客先で工程間搬送を人が台車で押している区間を1つ選び、通路の実効幅を測ること。本体幅600mmで800mmの通路を通れる仕様なので、測るのは最狭部の幅と、曲がり角の内径、それに床の段差。ここが800mmを下回る箇所が1つでもあれば、レイアウト変更が前提条件になる。メジャー1本で今日できる。
次の段階は、PLC連携の受け口を図面で設計しておくこと。AMRを入れる案件で実際に揉めるのは車体性能ではなく、設備との受け渡し条件。具体的には「搬送要求を出すのは誰か（設備PLCか上位か）」「到着したことを設備はどう知るか」「異常時にAMRを止めるのは設備の非常停止系に入れるのか別系統か」の3点。既存設備のPLCに搬送要求用の出力とAMR到着入力を1点ずつ確保できるか、余りI/Oを数えるところから始める。
3つ目に見るのが稼働時間の設計。約1時間の充電で約9.5時間の連続稼働という仕様なので、2交代なら昼休みに充電を差し込む運用が成立するかを、搬送本数×1サイクル時間で試算する。位置補正はマーカー読み取りなので、床にマーカーを貼る前提での床面の管理（水や切粉で汚れる区画かどうか）も現地で確認する。切粉が出る加工エリアは、マーカー方式の弱点が出やすい。
コスト感は、この記事に価格は書かれていないので見積もりを取る前提。AMR本体に加えて、通路整備、マーカー設置、設備側I/O追加とプログラム改造、安全評価の費用が乗る。経験的には本体以外が本体と同額規模まで膨らむことがあるので、客先へ話すときは「本体価格だけで判断しない」と先に言っておく。
注意点は2つ。まず、待機時間をほぼゼロにして稼働率を高めるという効果は、搬送要求が連続して発生する工程での話なので、1日数回の搬送に入れても効かない。導入前に搬送回数を実測する。次に、人が通る通路をAMRが走る構成になるため、安全は設備単体ではなく通路全体で評価する必要がある。既存設備の非常停止との関係は、メーカーの安全仕様書を取り寄せてから設計する。

この6項目は「AI導入の通知」の話として書かれているが、中身は設備改造の変更管理とほぼ同じ構造なので、そのまま現場に流用できる。最初の一歩は、次の設備改造1件で、影響範囲・正本・確認者・例外・戻し先・更新日の6項目をスプレッドシート1行に書いてから客先へ連絡すること。列名は記事のものを日本語に置き換えるだけでよい（対象工程／最新図面の置き場／確認者／異常時の連絡先／旧プログラムへ戻す条件／図面更新日）。所要5分、費用ゼロ。
次の段階は、status の4値をそのまま借りること。DRAFT／REVIEW／READY／HOLD の4値だけに絞るという割り切りが効く。設備改造なら「起案」「レビュー中」「連絡可」「保留」に相当する。特に効くのは READY の定義を「連絡してよい」ではなく「6項目が埋まった」にしている点。図面が更新されていないのに現場へ「変更しました」と伝えてしまう事故は、この定義1つで止まる。
3つ目は、rollback（旧手順へ戻す条件と方法）を必須列にすること。制御の改造で一番抜けるのがここで、「新プログラムで動かなかったら、どのバージョンへどうやって戻すか」を書かずに現地へ行くと、その場で判断することになる。列を必須にしてしまえば、書かないと先へ進めない。GASで必須チェックを掛ける実装は記事のコードをほぼそのまま使えるが、最初は条件付き書式で空欄を赤くするだけでも運用は回る。
コストは、スプレッドシートとGASなので追加費用なし。GASを書く場合も、記事の readChangeNotices_ / validateChangeNotice_ / classifyNotice_ の3関数で50行程度。社内で共有するなら、シートを1枚作って改造案件ごとに1行足す運用から始め、件数が増えて目視が辛くなってからスクリプトを入れる順番がよい。
注意点は、記事が明記しているとおり「正規表現や必須チェックは入力漏れを減らす補助であり、機密性や権限を証明するものではない」こと。シートが緑になったから安全、ではない。同じく、通知文の配信自体は人間の確認に残す設計になっている点も守る。設備改造で言えば、チェックリストが埋まっていても、現場への最終連絡は人が内容を読んでから出す。自動化するのは「抜けの検出」までで、「出す判断」は自動化しない。

最初の一歩は、締切を先にカレンダーへ入れること。申込締切が開催当日10月23日（金）11:00で、開始が同日12:00なので、当日思い出しても間に合う一方、当日の現場対応が入ると確実に落とす。今日のうちに「10/22までに申込」というリマインダを立てる。費用は無料、オンライン開催で場所は専用URLなので、客先移動の合間でも聴ける。
次に、聴く目的を1つに絞る。この手のサミットは製品紹介が中心になりがちなので、自分が持ち帰る問いを事前に決めておくと空振りしない。おすすめは「図面・仕様書・過去トラブルの検索にAIを当てている会社が、元データをどう整えたか」の一点。登壇者の紹介では、内田洋行の「Mugen(ミュージェン)」が図面、仕様書、過去トラブル、FMEAなど社内に散在する技術情報の検索・生成AI活用を支援するとされているので、この問いは正面から当たる。
3つ目は、聴いた内容を自分の手元の実験へ落とす段。過去トラブルの検索がテーマなら、自分の不具合対応記録を10件だけテキスト化して、手元のAIに「同じ症状の過去事例を探して」と聞く実験が翌日できる。ここまでやると、ベンダー製品が必要な部分（社内データの権限管理・検索対象の網羅性）と、自分の工夫で足りる部分（記録の書き方を揃える）が切り分けられる。
コストは参加費無料。ただし会社のメールアドレスが必要で、フリーアドレスでは登録できないとされているので、社用アドレスで申し込む。申し込みは1名ごとなので、同僚と聴くなら各自で申し込む。事業が競合する企業や個人事業主の申し込みは断る場合があるという条件も書かれているので、副業・個人名義での申込は避ける。
注意点は、これはアイスマイリーが主催するAIポータルメディア発のイベントで、登壇はソリューション提供側の4社である点。製品の良し悪しはこの場では判定できないので、聴くのは「どういう課題設定で入ったか」と「元データの整え方」に限る。導入判断に使う数字（精度、工数削減率）は、その場の発表ではなく個別の見積もりと評価で取る。

この数字が自分の仕事に効いてくるのは「攻撃側の道具がオープンウェイトへ降りてくる速さ」の指標として。4%や6%という成功率は低く見えるが、以前のモデルが0%だったところからの変化なので、来年には桁が変わる前提で考える。最初の一歩は、自分が客先へ持ち込むPCと持ち出すプログラムについて、「盗まれたら何が起きるか」を1枚に書いてみること。ラダーのソース、IPアドレス表、パスワード一覧、客先の設備配置図。どれが漏れると一番痛いかを順位付けするだけでよい。
次の段階は、その上位2つの保護を具体的に上げること。プログラムのソースならPCのディスク暗号化とバックアップの置き場所の見直し、パスワード一覧ならExcel保管をやめてパスワードマネージャへ移す。どちらも無料または年数千円のツールで済み、今週中に終わる。攻撃の自動化が進むと、狙われるのは大企業だけでなく「守りが薄い個人のPC」になるので、ここは費用対効果が高い。
3つ目は、客先のPLC・HMIへの持ち込み経路の再確認。制御機器は更新が遅く、脆弱性が残ったまま動き続ける。自分が持ち込むPCがインターネットと客先制御LANの両方に触る運用になっていないかを、いま一度たどる。両方に触るなら、作業用PCを分けるか、少なくとも作業前後でネットワークを切り替える手順を書面にする。費用はPC1台分か、運用手順の追加のみ。
注意点は、この引用が示しているのは「ベンチマーク上のタスクで成功した割合」であって、実際の攻撃が4%で成功するという話ではないこと。数字を社内で共有するときは、出典（Anthropic Frontier Red Team のレポートを Simon Willison が引用したもの）と、内部ベンチマークでの評価であることを必ず添える。過大に伝えると「AIが勝手に工場を攻撃する」という誤解になり、必要な対策の議論から遠ざかる。

今日の時点で自分が触れるモデルではない（信頼できるサイバー防御者への段階的提供の段階）ので、使うのは「次に来るものの前提」として。最初の一歩は、出力上限が64Kから100万トークンへ拡張されたという点だけを自分の使い方に当てはめること。今まで長い出力を諦めていた作業、たとえば設備1台分の仕様書をまとめて起こす、不具合対応記録を10件まとめて分類する、といった作業が「一度に通る」側へ動く。今のモデルでも、出力が途中で切れるから分割していた作業を洗い出しておくと、提供開始と同時に試せる。
次の段階は、価格から使い方を逆算すること。導入時価格は入力100万トークンあたり2ドル、出力100万トークンあたり10ドル、キャッシュ入力は95%割引。日本語の技術文書なら、1万字でおおよそ数千〜1万トークン規模なので、仕様書1本を読ませる実費は数円〜数十円のオーダー。つまり業務での試用はコストの問題にならず、問題になるのは持ち出し可否だけ。ここを先に社内で確認しておく。
3つ目は、セキュリティ側の使い方の予習。Argon は重大な脆弱性を自律的に発見・検証・パッチできるとされ、Wiz が Scan for Good で既に使って、病院で使われるヘルスケアソフトウェアの重大な脆弱性を発見した例が挙げられている。制御系のソフトを自分で書いている範囲（GASのスクリプト、PC側のツール、Webの点検帳票）については、こうしたモデルにレビューさせる工程を将来足す前提で、いまのうちにソースをリポジトリへまとめておく。散らばっていると、モデルが使えるようになった日に渡せない。
注意点は3つ。まず、信頼できる防御者とGoogle社内にはサイバー分野のガードレールを外した形で提供するとされている一方、一般提供の条件は別なので、自分が使えるようになったときの機能範囲は同じではない。次に、記載されているベンチマーク（DeepSWE v1.1 77.9%、CWE-bench v1 68%、AutomationBench 51.3%、LVBench 91.7%）はいずれもGoogle側の発表値なので、自分の用途での良否は自分の課題で測る。最後に、間接プロンプトインジェクションへの耐性を強化し続けているという記述は「対策中」であって「解決済み」ではない。Webページや客先から受け取ったファイルをモデルに読ませる使い方では、指示が混入する前提の運用（重要な操作は人が確認する）を崩さない。