工場や倉庫では、機密や設備の安全上の理由でネットワークを外部から切り離している現場が少なくありません。その閉じた環境の中でAIエージェントを動かすとき、便利さの前に決めておくべきは「誰が」「どこまで」「誰の承認で」動かすかという運用の骨格です。本稿では権限・承認・監査・更新・縮退という5つの観点から、閉域運用の設計を考えます。
工場や倉庫でAIエージェントを閉じた環境で動かすのは、機密の外部流出を避け、設備や人の安全に関わる領域を外部の変化から切り離しておくためだと考えられます。図面・検査記録・稼働データ・不良の写真といった情報は、それ自体が競争力の源泉であり、外に出せない前提の現場が少なくありません。まずこの「外に出せない」という制約を機能より先に置くことが、設計全体の出発点になると考えます。
ここでいうAIエージェントとは、指示を受けて情報を集め、下調べや文書化、定型的な照合などの作業を人に代わって進めるソフトウェアを指します。閉域で動かす前提については データを外に出さないローカルLLM でも扱っていますが、本稿はその一歩先――実際に「運用する」段になって決めておくべきことに焦点を当てます。
閉域でのAI導入でつまずきやすいのは、性能や便利さの検討に時間を使う一方で、「暴走したときにどう止めるか」「誰の責任で動いているか」の設計が後回しになる点だと考えられます。外部サービスなら提供者側に一定の制御が委ねられますが、社内ネットワークの中では止める仕組みも監視する仕組みも自分たちで用意する必要があります。工場ネットワークそのものの制約は OTセキュリティと閉域ネットワーク の観点と切り離せません。
人手不足の中で「現場の判断を助けるものが欲しい」という声は切実です。ただ、切実だからこそ、便利さを急いで広げる前に運用の骨格を先に決めておくほうが、結果的に長く使える仕組みになりうると考えます。
最初に決めるべきは、機能一覧ではなく「権限・承認・監査・更新・縮退」という5つの運用の骨格だと考えられます。何ができるかを積み上げる前に、誰がどこまで動かせて、どの操作に人の承認を挟み、何を記録し、モデルをどう入れ替え、止まったときにどう回すか――この5点を先に紙の上で決めておくことが、後戻りのコストを下げると考えます。
権限は「エージェントに何を触らせるか」の線引きです。承認は「どの操作の手前で人が止まって確認するか」の関門です。監査証跡は「後から誰でも辿れる記録」です。更新は「モデルや設定をどう安全に持ち込むか」の手順です。縮退運用は「止まっても現場が回るための代替」です。いずれも、初出の段階で定義しておくと現場との合意が取りやすくなると考えます。
オンプレミスとは、外部のクラウドではなく自社の管理下にあるサーバーで動かす形態を指します。エッジとは、現場の機器の近くに置いた小型のコンピューターで処理する考え方です。閉域でのエージェント運用は、この両方の性質を帯びることが多く、どちらに寄せるかで承認や更新の手順も変わってきます。クラウドとの比較の判断軸は クラウドとオンプレの比較 が参考になると考えられます。
この5点はどれか一つだけを固めても機能しません。権限を絞っても監査がなければ説明責任を果たせず、更新の手順がなければセキュリティ修正すら入れられない。相互に依存する骨格として、まとめて設計するのが現実的だと考えます。
エージェントの権限は「既定は最小、必要な範囲だけ明示的に許可する」という考え方で設計するのが安全だと考えられます。読み取りだけで済むこと、書き込みを伴うこと、外部や設備に影響を与えることを段階として分け、影響が大きい操作ほど手前に人の承認を必ず挟む構えにします。全部を自律に任せるのではなく、下ごしらえまでをエージェントが担い、最終決定は人が握る役割分担が閉域では扱いやすいと考えます。
人の承認をどこに挟むかは、その操作が「取り返しがつくか」「外に影響が及ぶか」で判断するとぶれにくいと考えられます。取り返しのつく読み取り・下書き作成は自動で進めてよい一方、取り消しにくい書き込みや、設備・在庫・出荷といった現物に影響する操作は人の確認を関門にする、という切り分けが現場感覚になじみやすい。
設備とつなぐ場合はとくに慎重さが要ります。エージェントが読み取った情報をもとに人が判断する形と、エージェントの出力が直接何かを動かす形では、必要な承認の重さがまったく違います。PLCとオンプレLLMの連携 で触れているように、制御に近づくほど「人が介在しない経路」を作らない設計が安全側だと考えます。
権限を絞ると「不便になるのでは」という懸念は当然出ます。ただ、閉域では便利さと安全のどちらを既定にするかで事故時のダメージが変わります。既定を最小に置き、現場の運用実績を見ながら必要な範囲を足していくほうが、広げすぎてから絞るより痛みが小さいと考えられます。
監査証跡は「誰が・いつ・何を指示し・エージェントが何をしようとし・誰が承認し・結果どうなったか」を後から辿れる形で残すのが基本だと考えられます。監査証跡とは、行為の正しさを事後に検証するための改ざんされにくい記録を指します。閉域では外部の監視サービスに頼れないぶん、この記録が唯一の説明手段になりうるため、機能追加より先に「何を残すか」を決めておくのが安全だと考えます。
記録は大きく、指示の内容、エージェントが取った行動、承認の有無と承認者、そして最終的な結果――の四層で捉えると整理しやすいと考えられます。とくに承認を挟んだ操作については、承認前の状態と承認者を残しておくことが、後から「なぜこの操作が通ったのか」を説明する土台になりうる。
一方で、何でも残せばよいわけではありません。閉域とはいえ、機微な情報をログに平文で溜め込めば、ログ自体が新たなリスクになります。残す対象と、閲覧できる人の範囲、保管期間を同時に決めるのが現実的だと考えます。ログの置き場所そのものが「工場データをどこに持つか」という問いに直結するため、工場データの主権 の観点とあわせて設計するのがよいと考えられます。
監査証跡は事故が起きてから作れません。導入初日から記録が積み上がっている状態にしておくこと、そしてその記録を蓄積・活用できる土台――工場データ基盤――の上に載せておくことが、後々の説明責任と改善の両方に効いてくると考えます。
外につながらない環境でのモデル更新は「持ち込む物の素性を確かめ、検証環境で試し、承認を経てから本番へ」という手順を固定するのが安全だと考えられます。閉域では自動更新が使えないぶん、更新は人の手を介した意図的な作業になります。だからこそ、誰が・どの版を・いつ・どんな確認を経て入れたかを記録に残し、いつでも前の版へ戻せる状態を保つことが重要だと考えます。
決めておきたいのは、持ち込む媒体と経路、素性の確認方法、検証環境での確認項目、本番反映の承認者、そして問題が出たときの切り戻し手順です。とくに切り戻しは、更新を進める勇気の裏づけになります。「戻せる」と分かっているからこそ、現場は新しい版を試せると考えられます。
モデルの挙動は版が変わると微妙に変化しうるため、更新後は限られた範囲で現場の実データに近い条件を通し、期待どおりかを人の目で確かめる工程を挟むのが現実的だと考えます。ここで性能を数値で保証することはできません――挙動は前提や現場条件に依存するため、あくまで現物・現場での検証が前提になると考えられます。
更新を止めたままにすると、便利さは保てても、セキュリティ修正すら入らない塩漬けの仕組みになりかねません。閉域だから更新しないのではなく、閉域だからこそ「安全に更新できる手順」を持っておくことが、長く使うための条件だと考えます。
エージェントが止まったときに備えて「AIがなくても現場が回る道」を最初から残しておくことが、閉域運用では欠かせないと考えられます。縮退運用とは、一部の機能が使えなくなっても、重要な業務だけは手動や簡易な代替手段で継続できるようにしておく設計を指します。AIを前提に業務を組み替えすぎると、止まった瞬間に現場が動けなくなりうるため、依存の度合いを意図的に調整しておくのが現実的だと考えます。
縮退は「全部止める」か「全部動かす」かの二択ではなく、段階で考えると扱いやすいと考えられます。応答が遅いだけなら待つ、一部機能が不安定なら該当機能だけ止めて人が代替する、全体が不調なら手動運用に切り替える――といった段階と、それぞれの切り替え判断を誰が下すかを、平時のうちに決めておくのがよいと考えます。
また、止まったこと自体に現場が気づけるかも重要です。静かに機能が落ちて、誰も気づかないまま誤った下ごしらえが流れ続けるのは避けたい状態です。異常を検知したら人に知らせ、自動の経路を止めて人の判断に戻す――この「安全側に倒れる」既定を組み込んでおくことが、閉域での信頼につながりうると考えます。
縮退運用の訓練を一度もしないまま本番を迎えると、いざというときに手順が絵に描いた餅になりがちです。導入前後に一度、意図的に止めてみて、現場が代替手順で回せるかを確かめておくことをおすすめしたいと考えます。
つまずきの多くは、技術の限界ではなく「運用の骨格を後回しにしたこと」に起因すると考えられます。導入前に紙の上で潰せる論点が大半のため、以下を早い段階で点検しておくことをおすすめします。
始め方としては、自律範囲を広げることからではなく、対象を絞った客観的な把握と現物・現場での検証から入るのが現実的だと考えられます。まず「どの業務の、どの下ごしらえを任せたいか」を一つに絞り、その範囲で権限・承認・監査・更新・縮退の骨格を小さく作って試す。うまく回る手応えを確かめてから、少しずつスコープを広げていくほうが、閉域では事故が小さく学びが早いと考えます。
外に出せない情報が中心で、設備や現物への影響が限定的な業務は、閉域でのエージェント導入の入口として向くと考えられます。逆に、出荷や制御など現物への影響が直接的で取り返しのつきにくい業務は、まず人の承認を厚く挟んだ下ごしらえ支援から始め、自動化の範囲は慎重に見極めるほうが安全だと考えます。
Nsightは、元キーエンス画像処理事業部の現場知見を持つエンジニアが、VLM（画像と言語を結びつけて扱うモデル）・Jetsonなどのエッジ機器・産業用カメラ・現場ライティングまで含めて、現場の制約から逆算した検証を重視しています。閉域という制約はマイナスではなく、データの主権を握ったまま現場を助ける設計の土台になりうると考えます。
最初の一歩は、大きな構想を描くことではなく、対象を一つ絞って現物で確かめてみることだと考えます。そこで見えた手触りが、権限や承認をどこまで任せられるかの現実的な線引きを教えてくれると考えられます。
外部につながらない環境でもローカルで動くモデルを用いれば運用は可能だと考えられます。ただし動かせること自体より、権限・承認・監査・更新・縮退という運用の骨格を先に決めておくことが重要です。閉域では止める仕組みや記録も自分たちで用意する必要があり、機能より運用設計を優先するのが現実的だと考えます。
すべての操作に必要というわけではなく、取り返しのつかない操作や設備・在庫・出荷など現物に影響する操作の手前に絞って承認を挟むのが機能しやすいと考えられます。読み取りや下書きのように取り消せる作業は自動で進め、影響が大きいものほど人の確認を関門にする切り分けが、現場になじみやすいと考えます。
自動更新が使えないため、持ち込む物の素性を確認し、検証環境で試し、承認を経てから本番へ反映し、いつでも前の版へ戻せるようにする、という手順を固定するのが安全だと考えられます。閉域だから更新しないのではなく、安全に更新・切り戻しできる手順を持っておくことが、セキュリティ修正を含めて長く使う条件だと考えます。
縮退運用をあらかじめ設計しておけば、止まっても重要な業務は手動や簡易な代替で継続できるようにできると考えられます。AIを前提に業務を組み替えすぎず、人が最終判断を握る役割分担を保つことが鍵です。導入前後に一度意図的に止めてみて、代替手順で回せるかを確かめておくことをおすすめします。
対象業務を一つに絞り、小さな骨格から始めれば取り組みは可能だと考えられます。ただし性能は前提や現場条件に依存するため、事前に数値を断言することは避け、現物・現場での検証を前提に進めるのが誠実だと考えます。まずは外に出せず現物への影響が限定的な業務を入口に、客観的な把握から始めるのが現実的だと考えられます。
権限・承認・監査・更新・縮退のどこを厚くすべきかは、対象業務によって変わります。まずは一つの業務に絞り、現場の制約から逆算した検証から始めるのが近道だと考えます。元キーエンス画像処理事業部の知見を持つエンジニアが、現物・現場を前提にご一緒します。
閉域でのAIエージェント運用について相談する