現場にはカメラ、マイク、温度・振動・重量などのセンサーが増え続けています。しかしデータが機器ごと・拠点ごとにばらばらのままでは、AIは力を発揮できません。データを取る「手足」と、判断する「脳」をどう分けて設計するか——多店舗・多拠点の困りごとから考えます。
この数年で、現場に設置される「データを取る機器」は急速に増えました。防犯・品質確認用のカメラ、作業記録用のマイク、設備の温度・振動・電流・重量を測るセンサー、入退室や在庫の読み取り機。人手不足を補うために各社が投資を進めた結果、現場には膨大なデータが日々生まれています。ところが「データはあるのに、意思決定は相変わらず人の勘と経験に頼っている」という声を、多店舗・多拠点を持つ経営者やDX推進担当の方からよく伺います。
原因の多くは、データが機器ごと・拠点ごとに分断されていることにあると考えられます。カメラの映像はカメラのアプリの中、センサーの数値は設備メーカーの管理画面の中、現場の気づきは口頭や紙、あるいはチャットの断片。それぞれが別の場所に別の形式で溜まっているため、「A店で起きた異常が、B店でも起きていないか」を横断的に見ようとした瞬間に手が止まります。
重要なのは、データを取ること（収集）とデータを活かすこと（判断・行動）は、まったく別の設計課題だという点です。センサーを増やす投資は目に見えやすく稟議も通りやすい一方、集めたデータを構造化して一元化する基盤づくりは地味で後回しにされがちです。しかしAIエージェントに現場を支援させたいなら、後者こそが本丸になりうると考えます。
整理のために、現場のデータ活用を人体になぞらえてみます。カメラ・マイク・各種センサーは、外界の情報を取りに行く「手足」あるいは感覚器官です。手足は多ければ多いほど、より細かく現場を捉えられます。一方で、集められた情報を突き合わせ、意味を解釈し、次の一手を判断するのは「脳」——すなわちデータを集約する基盤とその上で動くAIの役割です。
手足だけがどれだけ優秀でも、脳につながっていなければ反射的な動きしかできません。逆に、脳が賢くても手足からの信号がばらばらの言語で届けば、正しく解釈できません。多くの現場で起きているのは「優秀な手足が、脳につながっていない」状態だと考えられます。
ありがちな失敗が、個々の機器（手足）に高度な判断ロジックを埋め込みすぎることです。カメラ側で完結した判定、設備側だけで完結したアラート——それぞれは動くのですが、拠点をまたいだ全体最適や、複数センサーを組み合わせた総合判断ができなくなります。判断は極力「脳」に寄せ、手足は質の高いデータを正確に届けることに徹するという役割分担が、後々の拡張性を左右すると考えます。
もちろん、通信が途切れる現場や即応が必要な安全系では、手足の近く（エッジ）で一次判断させる設計も必要です。ここは「全部を脳に集める」か「全部を手足で処理する」かの二択ではなく、どの判断をどこに置くかを一つずつ決める設計問題になりうると考えます。
手足から届くデータは、そのままでは種類も形式もばらばらです。映像、音声、数値の時系列、テキストの気づき。これらを脳が扱えるようにするには、共通の構造に「翻訳」する工程が欠かせません。ここで鍵になるのが、非構造データの構造化です。
たとえば会議や現場でのやり取りの音声は、そのままでは検索も比較もできませんが、文字起こしを経て「いつ・どこで・誰が・何について」の要素に整理すれば、他のデータと突き合わせられるようになります。音声をナレッジに変える発想は、会議音声の文字起こし活用の考え方とも地続きです。カメラの映像も、VLM（視覚言語モデル）で「何が写っているか」を言葉に落とせば、テキストとして扱えるデータになりうると考えられます。
多店舗・多拠点で特に効いてくるのが、この翻訳のルールを拠点間で揃えておくことです。A店では「気温」、B店では「室温」、C店では数値だけ——といった揺れがあると、後で横断分析しようとした瞬間に整合作業で膨大な工数がかかります。物流の現場でも、拠点ごとにKPIの定義が違えば比較そのものが成立しません（物流KPIのデータ活用）。手足を増やす前に、共通フォーマットと粒度を先に決めておくことが、後からのAI活用のコストを大きく左右すると考えます。
翻訳されたデータの集約先——社内ナレッジ基盤・データ集約基盤——が、この構想の中核になります。設計で最初に問うべきは「何を、どの粒度で、どこまで残すか」です。全データを生のまま無期限に溜めれば容量もコストも際限なく膨らみます。逆に要約しすぎれば、後から別の観点で見直したいときに元情報が失われます。生データ・要約・メタ情報を層で分けて持つ考え方が現実的だと考えられます。
現場データには、映像に写り込む人物、設備の稼働状況、取引に関わる情報など、外に出しにくいものが含まれます。すべてをクラウドの外部サービスに送るのではなく、機微なデータは自社の閉じた環境（オンプレミス／閉域）で処理する設計が求められる場面が増えると考えます。現場設備とLLMを閉域で連携させる論点は、現場設備×オンプレLLM連携で扱っています。どのデータを閉域に留め、どこからをクラウドに委ねるかの線引きは、業種や規制によって変わりうるため、自社の要件で個別に判断することが前提になります。
集約基盤は「全社の全データを一気に統合する巨大システム」を目指すと、たいてい頓挫します。むしろ、1つの業務・1つの拠点でデータの流れを通し、そこで得た共通フォーマットとルールを他へ横展開していく方が、失敗のダメージが小さく学びも早いと考えられます。脳は一度に完成させるものではなく、手足からの入力を受けながら育てていくものだと捉えるのが現実的だと考えます。
データが共通の形で一元化されて初めて、その上でAIエージェントを動かす土台が整います。ここでのエージェントとは、単発の質問に答えるチャットではなく、集約基盤を参照しながら、状況を解釈し、次の行動を提案・実行まで担う存在を指します。「複数拠点で同種の異常が増えていないか」「ある設備の振動と生産不良に相関はないか」といった、人が横断的に見るには手間のかかる問いに、基盤を根拠として答えられるようになりうると考えられます。
ポイントは、エージェントの賢さの上限は、下にある集約基盤の質でほぼ決まるということです。手足の翻訳が雑で、基盤に断片的なデータしか無ければ、どれだけ高性能なモデルを載せても、それらしいが根拠の薄い出力になりがちです。「AIが賢くない」の正体が、実は「脳に届くデータが整っていない」ことだった、というケースは少なくないと考えます。
現場で信頼されるエージェントの条件は、答えだけでなくその根拠（どのデータを見てそう言ったか）を示せることです。判断の出どころが集約基盤の具体的なレコードまで遡れれば、人は納得して確認でき、誤りにも気づけます。ここは「精度が何%」という数字より、検証可能性を担保できるかどうかが実運用の鍵になりうると考えます。実際の精度や効果は、現物・現場での検証を経てはじめて評価できるものです。
手足と脳の仕組みは、一度組んだら放置できるものではありません。現場は変わり続けます。新しいセンサーが増え、業務の手順が変わり、扱う商材が入れ替わる。そのたびに翻訳ルールや集約の粒度を見直さなければ、基盤は徐々に現実とずれていきます。運用とは「データと現場の一致を保ち続ける」営みだと捉えるのが実態に近いと考えられます。
この見直しを毎回すべて外部に依頼していると、スピードもコストも合わなくなりがちです。だからこそ、共通フォーマットの意味やエージェントの挙動を理解し、日々の調整を自社で回せる人材を社内に育てる価値が高まると考えます。ツールを導入するだけでなく使いこなす人を増やす取り組みとして、AI研修（社内AI人材の育成）を並行させることが、内製化の土台になりうると考えます。
内製と外部支援は対立するものではありません。設計の勘所や難所は経験のある外部と伴走しつつ、日常の運用は社内で回す——この役割分担が、持続可能な形だと考えられます。
最後に、この取り組みで実際につまずきやすい点を率直に挙げます。どれも「やってみないと見えない」部分を含みます。
では、どこから手をつけるか。おすすめは、いきなり全社統合ではなく、1拠点・1業務でデータの流れを一本通してみることです。既にある手足（カメラ・センサー・音声・現場の気づき）のうち1〜2種類を、共通フォーマットに翻訳して集約基盤に流し、その上で小さなエージェントを動かしてみる。ここで初めて「翻訳の抜け」「粒度の過不足」「根拠を辿れるか」といった、机上では見えない課題が現物として見えてきます。
その検証で得た共通ルールと勘所を、次の業務・次の拠点へ横展開していく。手足を足すか、翻訳を直すか、脳の設計を見直すか——判断の材料は、毎回の現物検証から得られると考えられます。抽象的な全体構想より、小さく回して確かめるサイクルの方が、結果的に早く確実な土台になりうると考えます。
Nsightは、元キーエンス画像処理事業部の現場知見を基盤に、VLM・Jetsonエッジ・産業用カメラ・現場ライティングを組み合わせて、現場データを構造化し集約する取り組みを支援しています。まずは自社の1拠点で「どの手足が、どの形式で、どこに集まっているか」を可視化するところから、相談することをおすすめします。
機器（手足）を増やすだけでは、データが機器ごと・拠点ごとに分断されたまま死蔵されがちです。取ったデータを共通形式に翻訳し、集約基盤（脳）に一元化して初めて横断的な判断が可能になりうると考えられます。手足への投資と、集約・翻訳の設計は別の課題として順番を考えることが重要だと考えます。
カメラ・マイク・センサーはデータを正確に取って届けることに徹し、判断ロジックは極力集約基盤側（脳）に寄せる考え方です。個々の機器に高度な判断を埋め込みすぎると、拠点横断の総合判断がしにくくなります。ただし通信断や安全系ではエッジでの一次判断も必要で、どの判断をどこに置くかは個別設計になりうると考えます。
データの共通フォーマットと粒度を、拠点間で揃えておくことだと考えられます。同じ対象を拠点ごとに別の名称・別の定義で記録すると、後から横断分析しようとした際に整合作業で大きな工数がかかります。手足を増やす前に、薄くてもよいので共通ルールを先に決めておくことが後のコストを左右すると考えます。
映像に写る人物や設備の稼働状況、取引に関わる情報など、外に出しにくいデータが含まれる場合があります。機微なデータは自社の閉じた環境で処理し、どこからをクラウドに委ねるかを線引きする設計が求められる場面が増えると考えます。判断は業種や規制で変わるため、関連する制度は所管省庁の最新の公表資料でご確認ください。
認識率や削減率などの数値は、現物・現場での検証を経てはじめて評価できるもので、事前に一般的な数字を断定することは避けています。むしろ実運用では、答えの根拠となったデータまで遡れる検証可能性を担保できるかが信頼の鍵になりうると考えます。まず1拠点・1業務での検証から始めることをおすすめします。
「どの手足が、どの形式で、どこに集まっているか」を一本通して見るだけで、次の一手が見えてきます。抽象的な全体構想ではなく、現物・現場での小さな検証から一緒に始めましょう。
現場データの集約について相談する