オンプレAIの検討は「入れるまで」に注目が集まりがちですが、実際に効いてくるのは2年目以降の運用です。ハードが壊れたら誰が動くのか、モデルが陳腐化したら誰が更新するのか。導入時に決めておくべき責任分界点を、契約と社内体制の両面から考えます。
オンプレAIの本当の難所は、導入できるかどうかではなく「入れた後に誰が面倒を見るのか」にあると考えます。オンプレミスとは、AIの処理を外部クラウドではなく自社の設備内（工場・倉庫のサーバやエッジ機器）で完結させる方式を指します。データが外に出ないという安心と引き換えに、稼働を支える一次責任がベンダー側から社内側へ寄る構造になりやすいためです。
クラウドサービスであれば、サーバの死活監視・障害復旧・基盤の更新はサービス提供側が担うのが一般的です。ところがオンプレでは、その物理的な機器が自社の建屋の中にあります。停電で落ちた、ファンにホコリが詰まった、SSDが寿命を迎えた——こうした事象の一次対応者が誰なのかは、契約と運用設計で明示しない限り曖昧なままになります。オンプレを選ぶ理由そのものは工場データの主権の観点で語られることが多い一方、その裏返しとしての運用責任は見落とされがちです。
導入プロジェクトには予算・担当・期限が付き、関係者の熱量も高い状態です。しかし本稼働に入ると、AIは「動いていて当たり前の設備」に変わります。この温度差が盲点を生みます。誰も故障を想定した段取りを引き継がないまま、最初のトラブルで初めて「これ、どこに連絡するんだっけ」となる——現場でよく起こりうる展開だと考えます。
2年目以降に運用を揺らすのは、主に4つの変化だと整理できます。ハード故障、モデルの陳腐化、対象品目の追加、担当者の異動です。いずれも導入直後には表面化せず、時間の経過とともに効いてくる点が共通しています。
エッジ機器（現場で推論を実行する小型のAI実行装置）も産業用カメラも、消耗品を含む物理機器です。ファン・電源・記録媒体は経年で故障率が上がりうるため、「壊れたらどうするか」ではなく「いつ壊れても稼働が止まらない備えをどう持つか」で考える必要があると考えます。予備機の有無、復旧手順、代替稼働の可否が論点になります。
検査・OCRのAIモデルは、導入時点の現場を前提に調整されています。照明が変わった、梱包資材が変わった、新しいラベル書式が増えた——こうした現場側の変化が積み重なると、当初の精度が保てなくなる可能性があります。モデル更新の主体とタイミングを決めておかないと、精度低下に誰も気づかないまま運用が続くリスクがあります。
導入を主導した担当者が異動・退職すると、判断の背景や運用ノウハウが失われがちです。設定変更の理由、閾値を今の値にした経緯、ベンダーとの連絡ルート——これらが個人の記憶に依存していると、引き継ぎの断絶が運用停止の引き金になりえます。
最初にやるべきは、事象ごとに「社内で一次対応する範囲」と「ベンダーを呼ぶ範囲」の線引きを言語化することだと考えます。責任分界点とは、どこまでを自社で対応し、どこからを外部に委ねるかの境界を指します。この線が曖昧だと、トラブル時に対応の押し付け合いや空白が生じます。
線引きの粒度は、事象のカテゴリで分けると整理しやすくなります。物理的な事象（機器の再起動・ケーブル・清掃）は社内一次対応に向く一方、ソフトウェアやモデルに関わる事象（推論結果の異常、モデルの再学習）はベンダー領域に寄りやすい、という分け方が一つの目安になりえます。ただし、これは現場の技術リテラシーや体制によって最適な線が変わるため、一律の正解はないと考えます。
同じAI活用でも、クラウド方式とオンプレ方式では分界点の位置が根本的に異なります。クラウドは基盤運用を提供側が担う分、社内の責任範囲は狭くなりやすい一方、オンプレは基盤ごと社内側に来るため責任範囲が広がりやすい構造です。どちらが向くかは体制次第で、この違いはクラウドとオンプレの比較の観点で事前に理解しておく価値があると考えます。
社内一次対応を厚くする設計が向くのは、現場に設備保全の文化があり、機器トラブルへの初動が根付いている場合だと考えます。逆に、保全人員が薄く夜間・休日の初動が難しい場合は、ベンダー側の対応範囲を広めに設計するか、遠隔での復旧支援を含めた契約を検討する方が現実的になりうるでしょう。
保守契約で押さえたいのは、対応時間・対応範囲・更新の扱い・機器の扱いの4点だと考えます。金額や比率そのものより、これらの範囲が言語化されているかどうかが運用の安定を左右します。
対応時間については、平日日中のみか、夜間・休日を含むかで運用の安心感が大きく変わります。24時間連続稼働のラインと、日勤のみの現場では、必要な対応時間帯が異なります。自社の稼働カレンダーに照らして、どの時間帯の停止が許容できないのかから逆算するのが現実的だと考えます。
モデル更新を保守に含めるかは、契約の要となる論点です。含める場合でも、更新の頻度・トリガー（精度低下の検知か、品目追加の申請か）・更新後の検証手順を決めておかないと、更新が誰の宿題でもなくなります。更新後に現物で精度を確認する工程を、契約と運用手順の両方に組み込むことが望ましいと考えます。
機器故障時の復旧を実効的にするには、予備機の保有主体・保管場所・入れ替え手順・設定の再投入方法まで定めておく必要があると考えます。設定やモデルのバックアップがどこにあり、新しい機器へどう戻すのかが決まっていないと、予備機があっても復旧に時間がかかりえます。光学系からPLC連携までを含めた実装の勘所は、ハード導入・設備実装の設計段階で保守も併せて詰めておくと後戻りが減ると考えます。
社内体制で最優先すべきは、一次対応できる人を「役割として」置くことだと考えます。特定個人の善意ではなく、役割・手順・連絡先が文書化されている状態が、異動に耐える体制の条件になります。
具体的には、日常点検（機器の稼働ランプ・温度・エラー表示の確認）、簡易復旧（再起動・清掃・ケーブル確認）、そしてベンダー呼び出しの判断——この3層を誰が担うかを決めておくと運用が回りやすくなります。実行基盤としてのNsight Edgeのようなエッジ環境でも、日々の目視確認と初動を現場が担えるかどうかで安定度が変わってきます。
体制を絵に描いた餅にしないためには、運用開始前の教育が要になります。エラー表示の読み方、正常・異常の見分け方、判断に迷ったときのエスカレーション先を、現場の言葉で共有しておく必要があると考えます。この観点は現場でのエッジVLM運用教育で扱う領域で、導入と同時に設計すべきだと考えます。
中長期では、閾値調整や品目追加の一部を社内で判断できるようになると、ベンダー依存が減り運用コストの見通しが立ちやすくなりえます。いきなり全部を内製化する必要はなく、AI人材育成・伴走研修のように伴走しながら段階的に権限と技能を移すアプローチが現実的だと考えます。
実際の運用で顕在化しやすい落とし穴を、あらかじめ挙げておきます。いずれも導入時には見えにくく、時間の経過とともに効いてくるものです。以下は現場で起こりうるパターンとして整理したもので、自社に当てはまるかは現物・現場での確認が前提だと考えます。
これらに共通するのは、「導入時に決めなかったこと」が2年目に請求書として返ってくる、という構造です。裏を返せば、導入前の設計で相当程度は予防できる論点でもあると考えます。
出発点は、今の運用実態を客観的に把握することだと考えます。誰が何時に現場にいて、機器トラブルへの初動が今どうなっているのか。この現状把握なしに責任分界点を机上で引いても、現場では機能しない可能性が高いためです。
次に、想定される事象（故障・精度低下・品目追加・異動）ごとに「一次対応者」「エスカレーション先」「必要な対応時間帯」を一枚に書き出します。この一覧が、保守契約に何を書き込むべきかと、社内で何を担えるようにすべきかの両方の設計図になります。
最後に、その設計が現場で本当に回るかを現物・現場で検証します。実際に予備機へ入れ替えてみる、更新後の精度を現物で確認する、初動を担う人にエラー表示を見てもらう——机上の想定と現場の手触りのギャップを、稼働前に潰しておくことが持続する運用への近道だと考えます。金額・比率などの見積もりも、この検証を経た前提条件の上で初めて意味を持つと考えます。
日常点検・再起動・清掃・ケーブル確認といった一次対応は、現場に設備保全の文化があれば社内で担える範囲が広いと考えます。一方で推論結果の異常判定やモデルの再学習は専門性が高く、ベンダー領域に寄りやすい傾向があります。どこまで内製化できるかは現場の体制次第で、伴走研修などで段階的に範囲を広げるアプローチが現実的だと考えます。
金額は対応時間帯・対応範囲・モデル更新の有無・予備機の扱いなど条件で大きく変わるため、一律の相場を断定することはできません。まず自社でどの停止が許容できないかを整理し、必要な対応範囲を定めた上で見積もりを取ることをおすすめします。数値は前提条件と現物検証を経て初めて意味を持つと考えます。
一律の周期を断定することはできません。更新の必要性は経過時間ではなく、照明・資材・書式・対象品目といった現場側の変化の大きさに左右されると考えます。精度低下を検知する主体と、更新後に現物で確認する手順を運用に組み込んでおくことが、適切なタイミングを逃さない鍵になりうると考えます。
役割・手順・連絡先・設定の根拠が文書化されていれば、異動に耐える可能性が高まると考えます。逆に、判断が特定個人の記憶に依存していると引き継ぎの断絶が起こりえます。閾値をその値にした経緯やベンダー連絡ルートを個人ではなく役割に紐づけて残しておくことが有効だと考えます。
クラウドは基盤の運用・障害復旧・更新を提供側が担う分、社内の責任範囲が狭くなりやすい傾向があります。オンプレは機器が自社設備内にあるため基盤ごと社内側に責任が寄りやすく、一次対応や予備機の備えが論点になります。どちらが向くかは自社の保全体制次第で、事前に責任分界点を比較しておく価値があると考えます。
誰が一次対応し、どこからベンダーを呼ぶのか——その線引きは、現場の実態を見てからでないと機能しません。まずは今の運用実態の把握と、現物・現場での検証から一緒に始めます。元キーエンス画像処理事業部の現場知見をもとに、保守・サポート設計の観点でご相談を承ります。
保守・サポート設計について相談する