AI検査を入れるとき、避けて通れないのが「検査画像やデータをどこに置くか」という問いです。全部を社内に閉じるか、全部をクラウドに預けるか、その二択で悩む前に、そもそも何を守り何を伸ばしたいのかを分解してみると、判断は驚くほど整理されると考えられます。
AI外観検査や物流OCRの検討を進めると、精度や導入コストより前に情報システム部門やセキュリティ担当から返ってくる問いがあります。「その検査画像は、どこのサーバーに送られるのか」という問いです。数年前ならスペックや価格が最初の関門でしたが、生成AI・VLM（Vision Language Model）の普及で外部サービスへの画像アップロードが一般化した今、データの置き場所そのものが導入可否を左右する一次論点になってきたと考えられます。
背景には複数の圧力が重なっています。一つは、取引先や親会社から課される情報管理要件です。図面・製品外観・ロット情報・数量といった検査データは、それ単体では地味に見えても、競合に渡れば生産能力や不良傾向を推測されうる機微情報を含むことがあります。もう一つは、社内での生成AI利用に対する漠然とした不安です。この点は社内でのAI利用への不安として別途整理していますが、「便利そうだが、うちのデータが学習に使われないか」という懸念は根強いと考えられます。
ここでよく起きるのが、「全部を社内に閉じる（オンプレ）か、全部をクラウドに預けるか」という二択での硬直です。全部オンプレにすればモデル更新や拡張のたびに現場へ出向く負担が膨らみ、全部クラウドにすれば機密面の説明責任が重くなる。どちらの極も一長一短で、その二択のまま稟議に持ち込むと決裁が止まりがちです。実際には、データの種類ごとに置き場所を分けられる余地が大きく、そこを分解できるかどうかが判断の質を決めると考えます。
「オンプレとクラウドどちらが良いか」という問いは、そのままでは答えが出ません。何を最大化し、何を許容できないのかという軸を先に置かないと、比較の土台が揃わないためです。ここでは意思決定者が社内説明に使いやすい4つの軸に分けて考えます。
「検査データ＝全部機密」と一括りにすると議論が硬直します。実務では、（1）製品を特定できる図面・外観そのもの、（2）不良の傾向や歩留まりが読み取れる集計値、（3）モデルの重みや設定といった技術資産、（4）誰が見ても差し支えない匿名化済みのサンプル、では機微度がまるで異なります。自社の規程や取引先要件と突き合わせ、「これは絶対に敷地外に出せない」「これは匿名化すれば連携可」と仕分けするだけで、選択肢の幅が変わってくると考えられます。
AI検査は導入時点が完成形ではなく、新しい不良や新機種が出るたびにモデルを育てていく前提の仕組みです。この「育てる」工程は計算資源とデータの集約を必要としやすく、拡張性の観点ではクラウド側の力を借りたくなる場面が出てきます。一方で推論（現場でその都度判定する処理）は、必ずしも大きな資源を要しません。学習と推論で必要な性質が違うことを分けて捉えると、置き場所の設計も分けて考えやすくなると考えます。
コストは初期費用と運用費の両面で見る必要があります。オンプレは設備投資が先行し保守が自社負担になりやすく、クラウドは初期は軽い一方でデータ転送量や利用時間に応じた継続課金が効いてきます。可用性の観点では、ネットワークが切れたときに検査ラインが止まってよいのかが分水嶺です。回線障害でラインが止まる設計は現場では受け入れられにくく、この一点だけでも現場処理を軸に据える理由になりうると考えられます。
軸が揃えば、取りうる配置は大きく3つに整理できます。それぞれに向き不向きがあり、どれが「正解」ということではなく、自社の制約に照らして選ぶものだと考えます。
検査画像も推論もモデルも、すべて社内ネットワーク内で完結させる構成です。閉域ネットワーク前提の工場では自然な選択で、機密面の説明はもっとも通しやすいと考えられます。この設計思想は工場OTセキュリティの観点とも整合します。一方で、モデル更新や監視のたびに現地作業が発生しやすく、拠点が増えると運用負荷が拡張性のボトルネックになりうる点は正直に見ておく必要があります。
画像をクラウドへ送って判定し、結果を返す構成です。導入が速く、モデル改善や多拠点展開の拡張性に優れると考えられます。反面、検査画像を常時外部へ送ることになるため機密面の説明が重くなり、回線が切れると検査が止まる可用性リスクを抱えます。データの学習利用の可否や保管場所（リージョン）、削除ポリシーを契約レベルで詰められるかが鍵になると考えます。
推論は現場のエッジ端末で完結させ、モデル改善や集計に必要なデータだけを、必要なタイミングで外部と連携する構成です。生の検査画像は敷地外に出さず、匿名化・要約した情報や、選抜した学習用サンプルのみを送るといった分離が可能になります。機密性と拡張性のトレードオフを緩める現実解になりやすいと考えられ、本稿では主にこの設計の考え方を掘り下げます。
ハイブリッド設計の核心は、データを一括りにせず「どのデータが、いつ、どこへ流れるか」というフローを描き切ることにあります。検査というリアルタイム処理と、モデルを育てるという非同期処理を分離し、それぞれに最適な場所を割り当てる発想です。
典型的には、生の検査画像・判定処理・モデルの重みは現場のエッジ端末に留めます。外部と連携するのは、判定結果の集計値、モデル改善のために選抜・匿名化したサンプル、稼働状態の監視情報など、機微度を落とした情報に絞るという考え方です。エッジVLM OCRのように、VLMベースの読み取り・判定をエッジ側で完結させられれば、生画像を外へ出さずに現場で結論を出す設計が取りやすくなると考えられます。
常時接続を前提にすると可用性リスクと機密リスクを同時に背負い込みますが、連携を「必要なときだけ」に限定すると負担が下がります。たとえば、新しい不良傾向が溜まったときにだけ学習用データを送る、更新済みモデルを配布するときだけ通信する、といった間欠的な連携です。通常運転はオフラインでも回り、回線が切れても検査は止まらない——この「切れても止まらない」性質が、現場に受け入れられる設計の分かれ目になりうると考えます。
見落とされがちですが、どこにデータを置くかの前提として、そもそも安定した画像が撮れているかが効いてきます。産業用カメラの選定と現場ライティング（照明設計）が甘いと、クラウドに送ろうがエッジで処理しようが判定は安定しません。元キーエンス画像処理事業部の現場知見が生きるのはまさにこの領域で、データ配置の議論は撮像の安定という土台の上でこそ意味を持つと考えられます。
配置パターンを決めても、運用の責任分界が曖昧だと現場で止まります。データがどこにあるかと同じくらい、そのデータの生成・保管・削除・監査に誰が責任を持つかを決めておくことが、実は導入後のトラブルを左右すると考えられます。
検査画像を何日保持し、いつ・誰の判断で消すのか。証跡として一定期間残す要請と、溜め込むほど漏えい時の被害が広がるリスクは相反します。個人情報や取引先情報が写り込みうる場合、関連する法令・ガイドラインの適用範囲は自社だけで判断せず、所管省庁の最新の公表資料や自社の法務でご確認いただくことをおすすめします。保管期間・アクセス権・削除ログを最初に決めておくことが、後からの説明を楽にすると考えます。
モデルを誰が更新でき、その変更履歴をどう残すかも運用の要です。AIの判定に説明責任が絡む場面では、いつ・誰が・どのモデルに変えたかが追えることが後々の拠り所になりえます。この論点はAIエージェントのガバナンスと共通する部分が多く、権限設計とログ設計はデータ配置と一体で考えるのが望ましいと考えられます。
エッジ端末が故障したら、回線が切れたら、クラウド側が停止したら——それぞれのときに検査ラインをどう回すのか（あるいは止めるのか）の手順を、導入前に紙に落としておくことが実務では効きます。「動くとき」の設計は華やかですが、「止まったとき」の設計こそ現場の信頼を作ると考えます。
この領域には、やってみないと分からない部分と、先に知っておけば避けられる定番のつまずきがあります。誠実に共有します。
ここまでの整理を踏まえると、進め方はある程度定型化できます。ただし最終判断は自社固有の制約に依存するため、一般論で結論を出さず、事実の把握から始めるのが堅実だと考えます。
まず、どんなデータが発生し、それぞれの機微度・取引先要件・法令上の扱いを一覧化します。「絶対に外に出せないもの」と「匿名化すれば連携可能なもの」を分けるだけで、取りうる配置が絞れてきます。この棚卸しは技術より前に、情報システム・法務・現場を巻き込んで行うのが望ましいと考えられます。
次に、実際の製品・実際の現場照明で小さく試します。カタログ精度ではなく自社の現物で、エッジ完結でどこまで判定できるか、どのデータだけ外に出せば改善が回るかを確かめる工程です。ここで得られる手触りが、稟議での説得力にも直結すると考えます。
最後に、保管・削除・権限・障害時手順を紙に落とし、社内説明の材料に仕上げます。技術的に動くことと、社内で承認されることは別物です。設計と運用ルールを一体で示せると、意思決定は前に進みやすくなると考えられます。自社の状況に照らした具体的な設計を詰めたい場合は、お気軽に相談するところから始めていただければと思います。
一律の正解はなく、データの機微度・取引先要件・現場の回線事情によって変わると考えられます。実務では二択ではなく、推論は現場のエッジで完結させ、改善に必要なデータだけを匿名化して連携するハイブリッド設計が現実解になりやすいと考えます。まずは自社データの棚卸しから始めるのが堅実です。
サービスによって扱いが異なり、学習利用の有無・保管リージョン・削除ポリシーは契約条項で決まります。技術仕様より先に契約を精読することが重要だと考えられます。学習利用を避けたい場合は、生画像を外に出さずエッジ側で判定を完結させる構成を検討する余地があると考えます。
社内に置けば必ず安全とは限りません。アクセス権限・物理管理・バックアップの暗号化が甘ければ、オンプレでも漏えいは起こりえます。置き場所そのものより、アクセス管理・保管期間・削除ログといった運用の質が機密性を左右すると考えられます。
業種・データの内容・写り込む情報によって関係する法令やガイドラインが異なりうるため、一律には言えません。個人情報や取引先情報が含まれうる場合は、所管省庁の最新の公表資料や自社の法務でご確認いただくことをおすすめします。実務上は証跡としての保持と、溜め込みによる漏えいリスクの両面から期間を決めるのが妥当と考えます。
常時クラウド接続を前提にした構成では、回線障害で判定が止まりうると考えられます。推論を現場のエッジで完結させ、外部連携を必要なときだけに限定する設計であれば、通常運転はオフラインで回り、回線が切れても検査を継続しやすくなると考えます。障害時の手順を事前に明文化しておくことも重要です。
オンプレかクラウドかは、一般論ではなく自社のデータと現場の実態から決まるものだと考えます。まずは検査データの棚卸しと、現物・現場での小さな検証から始めてみませんか。撮像の安定化からデータ配置の設計まで、現場知見を踏まえてご一緒に整理します。
検査データの配置設計について相談する