インターネットに出ない工場・倉庫でAIを動かし続けると、いつか「モデルをどう更新するのか」という問いに突き当たります。結論から言えば、管理された持ち込みメディアで運び、検証機で確かめてから本番へ反映し、旧版を残して切り戻せる状態を保つ——この順序が基本形です。この記事は、外へ出ない前提のまま更新を安全に回す手順と、そもそも更新すべきかどうかの判断軸を、現場運用の視点で整理します。
閉域ネットワークでAIを運用すると、更新の瞬間に運用設計の甘さが表面化しやすいと考えられます。閉域ネットワークとは、インターネットや社内の基幹系ネットワークから物理的・論理的に切り離された運用環境のことです。多くのローカルAIは「クラウドから最新モデルを自動で取得する」ことを前提に設計されており、その前提が丸ごと使えない環境では、更新という当たり前の作業が途端に手作業の連続になります。
ここでいうローカルLLM/VLMは、社内の機器の中だけで動く生成AIを指します。LLMは大規模言語モデル、VLM（Vision Language Model）は画像と言語を合わせて扱うモデルで、産業用途では検査画像やラベルの読み取り・照合に使われます。オンプレミス、つまり自社の敷地・機器内で完結させる構成は、データを外に出さない安心と引き換えに、更新の面倒を自分たちで引き受けることになります。
導入直後は誰もモデル更新のことを考えません。動いているからです。問題が顕在化するのは、業務要件が変わったとき、読めない対象が増えたとき、あるいは「もっと新しいモデルが出たらしい」と現場から声が上がったときです。そのとき初めて「このAI、どうやって新しくするんだっけ」という問いが宙に浮きます。閉域運用の全体像は閉域でのAIエージェント運用で扱っていますが、更新はその中でも後回しにされがちな領域だと考えます。
更新が設計されていない環境では、更新のたびに「誰かが手順を思い出しながら」作業することになります。手順が属人化すると、更新のたびにリスクが増え、結果として「怖いから更新しない」という消極的な塩漬けに陥りやすくなります。塩漬け自体が悪いわけではありませんが、選んで塩漬けにするのと、怖くて動かせないのとは意味が違うと考えます。
閉域のモデル更新で決めるべきことは、大きく分けて「経路」「順序」「戻り方」「頻度」の四つだと整理できます。どれか一つでも欠けると、更新が博打になります。逆にこの四つを事前に紙一枚で決めておけば、更新は淡々とした定型作業に近づくと考えられます。
| 決める論点 | 決める内容 | 決めていないと起きること |
|---|---|---|
| 経路 | 持ち込みメディアの管理・ウイルスチェック・持ち込み記録 | 統制されない媒体の持ち込みで、閉域である意味が崩れる |
| 順序 | 検証機での事前確認→本番反映という流れ | 本番でいきなり入れ替え、失敗が業務停止に直結する |
| 戻り方 | 旧バージョンの保管と切り戻し手順 | 問題発覚後に戻る先がなく、復旧が長引く |
| 頻度 | 業務要件から逆算した更新間隔の考え方 | 「新しい＝良い」で更新し、重要な対象で静かに後退する |
外部接続がない以上、新しいモデルは何らかの物理メディアで持ち込むしかありません。ここで問われるのは、持ち込みメディアの管理・ウイルスチェック・持ち込み記録という、情シスやOT（制御・現場側の運用技術）セキュリティの領域です。工場ネットワークの前提そのものはOTセキュリティと閉域AIで整理していますが、更新はこの前提の上に乗る行為だと捉える必要があると考えます。
順序とは、検証機で確かめてから本番へ反映する流れのことです。戻り方とは、新バージョンで問題が出たときに旧バージョンへ戻す（切り戻す）手順のことです。この二つはセットで、片方だけでは意味をなしません。切り戻せない更新は、失敗が許されない更新であり、失敗が許されない更新ほど現場は触りたがらなくなります。
更新頻度は「新しいモデルが出たから」ではなく、業務要件から決めるべきものだと考えます。読み取り対象が増えた、精度に対する不満が具体的に出ている、といった業務側の理由があって初めて更新の検討が始まります。理由なき更新は、動いているものをわざわざ揺らす行為になりうるからです。
持ち込みメディアによる更新は、「外で作った成果物を、検査を通してから、閉域内へ一方向に運ぶ」という流れで組み立てるのが基本だと考えられます。外の環境で更新用のモデルを用意し、それを管理された媒体に載せ、ウイルスチェックと持ち込み記録を経て、まず検証機へ入れる。この一方通行を崩さないことが、閉域の閉域たる意味を守ることになります。
更新経路の設計で重要なのは、閉域の内側から外へデータやログを吸い出す経路を、更新のついでに作らないことです。更新は「入れる」作業であって「出す」作業ではありません。持ち出しが必要になる場面（障害調査など）は、更新とは別の手続きとして分けて設計するほうが、後々の統制がしやすいと考えます。データを外に出さない構成の考え方はデータを外に出さないローカルLLMも参考になります。
持ち込みに使う媒体は、普段使いのUSBメモリを流用せず、更新専用のものを決めておくほうが安全だと考えられます。何が入っているか分からない媒体を閉域内に挿すこと自体が、閉域運用で最も避けたい行為の一つだからです。専用媒体・専用の受け渡し担当・受け渡し記録という三点を決めるだけで、持ち込みの統制はかなり締まると考えます。
なお、更新用の成果物には、モデル本体だけでなく「どのバージョンを、いつ、誰が、何のために作ったか」を示す情報を一緒に添えておくことをおすすめします。閉域内では後から外部の履歴を参照できないため、成果物自体が自分の素性を語れる状態にしておくことが、半年後の自分を助けると考えられます。
更新は「検証機で挙動を確かめる→本番へ反映する→問題が出たら旧版へ戻す」という順序で進めるのが安全だと考えられます。いきなり本番のモデルを入れ替える運用は、閉域という戻りにくい環境では特に避けたいやり方です。順序を守ることで、更新の失敗を「本番停止」ではなく「検証機での見送り」に留められる可能性が高まります。
新旧バージョンの挙動差を見る最も実務的な方法は、更新前と更新後で同じ評価用データを流し、出力がどう変わったかを突き合わせることだと考えます。評価用データとは、現場で実際に扱う対象を代表する、あらかじめ用意しておいた確認用の一式です。同じ入力に対する出力を比べれば、「今まで読めていたものが読めなくなった」といった後退（デグレード）に気づける可能性が高まります。
更新前後の比較で見たいのは平均的な性能の良し悪しではなく、「自社の業務にとって重要な対象で、望ましくない変化が起きていないか」です。一般的な性能が上がっていても、自社が最も頼りにしていた読み取りが弱くなっていれば、その更新は自社にとって改善とは言えません。更新で挙動が変わること自体への備えはモデルのバージョン移行でも触れています。
更新の際に旧バージョンをすぐ消さないことは、切り戻しの前提として重要だと考えます。新バージョンが検証機で良く見えても、本番の多様な入力で初めて問題が出ることはありえます。旧版が手元に残っていれば、問題発覚時に「元の動いていた状態」へ短時間で戻せます。少なくとも直前の安定版は、次の更新が安定するまで保管しておく運用が現実的だと考えられます。
本番反映は、可能なら一気に全面切り替えるのではなく、影響範囲を絞って様子を見る段階を挟むほうが安全だと考えられます。工程の一部や特定の時間帯から始め、想定どおりに動くことを確認してから広げる。この慎重さは、閉域という「戻りにくさ」への保険になりうると考えます。
安定して業務要件を満たしているモデルを、新しいものが出たという理由だけで更新しないことは、正当な運用判断だと考えます。新しいモデルほど良いとは限りません。ベンチマーク上の一般的な性能が向上していても、自社の特定の対象では変化がない、あるいは後退する可能性もあり、それは実際に流してみるまで分かりません。
更新の検討が向くのは、業務側に具体的な理由がある場合だと整理できます。たとえば、読み取り対象の種類が増えて現行では対応しきれない、現場から精度への不満が具体的な事例つきで上がっている、セキュリティ上の対応が必要になった、といった状況です。これらは「新しくしたい」ではなく「新しくしないと困る」に近い状況だと考えます。
逆に、現行モデルが要件を安定して満たしていて、現場からの不満も具体的でなく、更新の動機が「なんとなく古い気がする」に留まるなら、見送りが向くと考えられます。閉域環境での更新は、持ち込み・検証・切り戻し準備という手間とリスクを伴う行為です。その手間に見合う便益が見えないなら、動いているものを揺らさないことにも十分な合理性があります。
ただし「更新しない」を選ぶ場合も、更新できる状態は保っておくことをおすすめします。手順が失われ、いざ必要になったときに誰も更新できない、という塩漬けは避けたい状態です。更新しないことと、更新できないことは、区別して管理する必要があると考えます。
情シスやセキュリティ担当が閉域AIの更新で確認したいのは、多くの場合「何が・いつ・誰によって・どの媒体で持ち込まれたか」の記録だと考えられます。AIの中身の良し悪しよりも先に、閉域の統制が更新のたびに崩れていないかが関心事になります。ここに答えられる運用にしておくと、更新の社内承認が通りやすくなると考えます。
持ち込みメディアは、閉域内に挿す前にウイルスチェックを通し、その事実を記録に残すことが基本だと考えられます。記録に残す項目としては、持ち込み日時・持ち込み者・媒体の識別・持ち込んだ成果物のバージョン・チェック実施の有無などが挙げられます。これらは特別な仕組みがなくても、決められた台帳に書くだけでも成立します。大切なのは、更新が「記録の残る行為」になっていることだと考えます。
この記録は、監査や社内説明のためだけのものではありません。トラブル時に「いつの更新から挙動が変わったか」を追う手がかりにもなります。切り戻しの判断も、記録があるからこそ「あの更新まで戻す」と具体的に指示できます。記録は統制と復旧の両方に効く、更新運用の背骨だと考えられます。
どの規模の更新に誰の承認が要るのか、という線引きを事前に決めておくと、更新のたびの調整コストが下がると考えられます。小さな調整と、モデル本体の入れ替えでは、伴うリスクが違います。線引きを明文化しておけば、現場は「これは誰に確認すればいいか」で迷わずに済み、統制も保たれると考えます。なお、モデルの入れ替えを含む日常運用全体を、社内とベンダー保守でどう分担するかは情シス専任なしのオンプレAI運用で整理しています。
閉域のモデル更新でつまずきやすい点は、多くが「更新そのもの」ではなく「更新の前後の準備不足」に起因すると考えられます。代表的なものを挙げます。
これらはいずれも、更新の技術的な難しさというより、運用の段取りの問題だと考えられます。裏を返せば、段取りさえ事前に決めておけば、閉域のモデル更新は特別に恐ろしい作業ではなくなると考えます。
最初にやるべきは、新しいモデルを探すことではなく、「今動いているものを、いつでも同じ状態に戻せる」状態を作ることだと考えます。現行バージョンの保管、評価用データの整備、持ち込みと承認の手順の明文化。この三点が揃って初めて、更新は安全に検討できる作業になると考えられます。
次に、更新頻度を業務要件から逆算します。読み取り対象がどの程度の頻度で変わるのか、精度への要求がどれくらい厳しいのか。これらから「そもそもどのくらいの間隔で更新を検討すべきか」が見えてきます。頻度が決まれば、更新は突発的なイベントではなく、計画された定期作業に近づくと考えます。
閉域という制約の中で、更新の順序・戻り方・記録・頻度をどう自社の実態に合わせて設計するかは、現物と現場を見ないと決めきれない部分が多くあります。工場データ基盤のように社内で完結するデータとAIの土台を前提に、運用設計まで含めて伴走する導入コンサルティングという進め方もあります。まずは自社の現行運用の棚卸しから始めることをおすすめします。
Nsightは、元キーエンス画像処理事業部の現場知見を持つエンジニアが、VLM・エッジ機器（現場側に置く小型のAI処理端末。Jetson等）・産業用カメラ・現場ライティングを一体で扱ってきました。閉域で動くAIを「導入して終わり」ではなく「更新しながら動かし続ける」視点で、運用の順序づくりから一緒に考えられると考えています。
更新できると考えられます。方法は、外部で用意した更新用モデルを管理された物理メディアで持ち込み、ウイルスチェックと持ち込み記録を経て、まず検証機で挙動を確かめてから本番へ反映する流れが基本です。オンライン自動更新は使えないため、持ち込み・検証・切り戻しを含む手順を事前に決めておくことが前提になると考えます。
更新頻度は「新しいモデルが出たか」ではなく、自社の業務要件から決めるものだと考えます。読み取り対象の変化の頻度や精度要求から逆算します。安定して要件を満たしているなら更新しない判断も正当です。一律の推奨間隔があるわけではなく、業務側に具体的な理由があるときに検討するのが現実的だと考えられます。
ありえます。一般的な性能が向上していても、自社の特定の対象では変化がない、あるいは後退する可能性があります。これは実際に流してみるまで分かりません。だからこそ更新前後で同じ評価用データを流して挙動差を確認し、旧バージョンを消さずに残して、問題時に切り戻せる状態を保っておくことをおすすめします。
持ち込み日時・持ち込み者・使った媒体・持ち込んだ成果物のバージョン・ウイルスチェック実施の有無などを、決められた台帳に残すのが基本だと考えられます。特別な仕組みは必須ではなく、まず記録が残る運用にすることが重要です。この記録は監査対応だけでなく、トラブル時に「いつの更新から変わったか」を追う手がかりにもなります。
分担は体制によりますが、持ち込み・台帳への記録・本番反映の立ち会いといった現場作業は社内、更新版の用意・検証の設計・切り戻し判断の支援は外部の保守へ寄せる形が現実的だと考えられます。どちらが担うにせよ、手順と記録の様式を先に決めておくことが重要です。日常運用全体の分担と合わせて検討することをおすすめします。
現行版の保管・評価用データの整備・持ち込みと承認手順の明文化という土台が揃えば、自社運用に近づけられると考えます。一方で、更新の順序・戻り方・頻度を自社の実態にどう合わせるかは現物と現場を見ないと決めきれない部分があります。運用設計まで含めて外部と伴走する進め方もあり、まずは現行運用の棚卸しから始めることをおすすめします。
外部接続のない環境でのモデル更新は、技術より運用の段取りで決まると考えています。現行運用の棚卸しと現物確認から、更新の順序・切り戻し・記録の設計まで一緒に整理できます。まずは自社の現状を見せていただくところから始めませんか。
閉域AIの更新運用について相談する