ロボット稼働データの収集・可視化基盤（全文）

エグゼクティブ・サマリー

稼働データ基盤は、1台目には要らないが3台目には必須になる。 1台なら現場が目で見て把握できる。複数台・複数拠点・複数ベンダーになった瞬間、「今どれだけ動いているのか」が誰にも答えられなくなる。この転換点を過ぎてから作ると、遡れるデータが存在しない。
最大の障害は技術ではなく調達である。 ロボットのデータはベンダーのクラウドに閉じていることが多い。自社でデータを取れるかどうかは、契約書に書いたかどうかで決まる。導入後に「データをください」と頼んでも、多くの場合、有償の追加開発になる。
測るべきは6カテゴリ。 稼働時間・停止事象・作業量・品質・消耗と保全・環境。このうち投資判断に直結するのは停止事象である。止まった時刻・場所・理由・復旧までの時間が残っていない現場は、改善の議論ができない。
共通イベントスキーマを先に決める。 機種ごとのログ形式をそのまま溜めると、比較も合算もできない。最小限の共通項目（機体ID・時刻・拠点・状態・イベント種別・所要時間）へ正規化してから溜める。項目は少ないほど続く。
画面は3つに分ける。 現場向け（今日どうか）、管理者向け（今月どうか・なぜ止まったか）、経営向け（投資は回収できているか）。ひとつの画面で全員を満足させようとすると、誰も見ない画面ができる。
AI活用は基盤の後にしか来ない。 予知保全も稼働最適化も、一定期間の連続した稼働・停止データがあって初めて成立する。データを溜め始める判断そのものが、AI活用の第一歩である。

ロボットの導入検討では、機種・価格・安全・工期が議論の中心になる。稼働データの話が出るのは、たいてい導入から半年〜1年後、「効果が出ているのか説明してほしい」と経営から問われたときである。そのとき現場が持っているのは、断片的な日報と、ベンダーの管理画面に表示されている直近30日分の数字だけ、というケースが少なくない。遡れないデータは、存在しないのと同じである。

本稿は、ロボットを販売しない中立の立場から、ロボット稼働データを「自社の資産」として持つための設計を整理する。大がかりなIoT基盤の構築論ではない。表計算ソフトから始めて段階的に育てる、実務的なロードマップとして書いている。

1. なぜ3台目で必要になるのか

1台のロボットは、現場の目で管理できる。動いているか止まっているかは見ればわかるし、止まった理由は担当者が覚えている。問題は次の段階で起きる。

2台目が別ベンダーになる。 管理画面が2つになり、用語も指標の定義も違う。「稼働率」がベンダーAでは電源投入時間比、ベンダーBでは計画時間比、ということが平然と起きる。
2拠点目ができる。 拠点間で成績を比べたくなるが、比べられるデータがない。良い拠点のやり方を横展開したくても、何が違うのかを数字で言えない。
担当者が異動する。 「あのロボットは雨の日によく止まる」という現場知が、人と一緒に消える。
経営から投資判断を問われる。 3台目の稟議を書く段になって、1〜2台目の実績を示せと言われる。過去の稼働率を出そうとして、初めてデータがないことに気づく。

この4つは、ほぼ確実に起きる。したがって基盤の検討は、3台目を買う時ではなく、2台目を検討する時に始めるのが正しいタイミングである。データは遡って作れない。

2. 何を測るか——6カテゴリのデータ項目

測る項目を最初から広げすぎると、収集が続かない。次の6カテゴリを、優先度順に段階的に増やしていく。

#	カテゴリ	主な項目	何に使うか	優先度
1	稼働時間	電源投入・自動運転・待機・充電の各時間、計画稼働時間	稼働率の算定、投資回収の説明	最優先
2	停止事象	停止時刻、場所、エラーコード、停止理由分類、復旧時刻、対応者	改善対象の特定。最も価値が高い	最優先
3	作業量	搬送件数、走行距離、清掃面積、処理個数、サイクル数	生産性、単位あたりコストの算定	高
4	品質	失敗・やり直し件数、精度指標、苦情・指摘件数	「速いが雑」を検出する	中
5	消耗と保全	消耗品交換履歴、稼働積算時間、点検実施記録、部品交換	予知保全への接続、保守費の実績把握	中
6	環境	拠点、フロア、時間帯、気温・湿度（屋外・特殊環境の場合）、同時作業の人数	停止要因の相関分析	低（後から）

カテゴリ2の停止事象が、この基盤の中核である。 稼働率という単一の数字は、経営には説明できるが改善には使えない。「なぜ止まったか」を分類して積み上げて初めて、次に何を直すべきかが決まる。停止理由の分類は、最初から精緻にする必要はない。次の程度の粗い分類で十分に機能する。

分類	例	打ち手の方向
機器故障	部品破損、センサ異常	保守契約、予備部品、予知保全
環境要因	障害物、床の汚れ、人の滞留、通路の荷物	現場のルール、レイアウト、時間帯変更
運用要因	起動忘れ、充電切れ、設定ミス、消耗品切れ	手順書、担当者の明確化、教育
通信・システム	ネットワーク断、サーバ側障害、連携先の不調	通信設計、連携仕様の見直し
計画停止	点検、イベント、休館、繁忙対応	（分母から除外する。混ぜてはいけない）
不明	原因が記録されていない	この比率を下げることが最初の改善目標

導入初期は「不明」が半分を超えることが普通である。不明比率を下げること自体を最初の3か月のKPIに置くとよい。原因が分類できて初めて、打ち手が議論できる。

3. どこから取るか——4つの取得経路

データの取得経路は、実務上4つに整理できる。多くの現場は複数を併用することになる。

経路	内容	長所	短所
A. ベンダー管理画面の手動出力	CSV/Excelを定期的にダウンロード	すぐ始められる。追加費用が小さい	手作業が続かない。項目・期間の制約
B. ベンダーAPI	ベンダーのクラウドからAPIで取得	自動化できる。項目が比較的豊富	提供可否・費用が契約次第。仕様変更のリスク
C. 機器から直接	PLC・上位コントローラ・ゲートウェイから信号やログを取得	ベンダー依存が小さい。粒度が細かい	現場ネットワークの設計・保安の調整が必要
D. 人が入力	日報・停止記録の手入力、タブレット入力	「なぜ止まったか」を残せる唯一の手段	入力負荷。項目を絞らないと形骸化する

経路Dを軽視しないこと。 機器から自動で取れるのは「止まった」という事実までであり、「通路に台車が置かれていたから」という理由は人しか入力できない。そして改善に効くのは後者である。入力項目は、停止1件につき分類の選択1つと自由記述1行まで、と決めるのが現実的である。それ以上を求めると入力されなくなる。

導入の順序としては、A→D→B→C が定石である。まず手動出力と人の記録で「何がわかると嬉しいか」を確かめ、続ける価値があると判断できてから自動化に投資する。最初からCまで作り込む提案が来たら、費用と工期の妥当性を慎重に検討したほうがよい。

4. 調達で決まる——契約に書くべきデータ条項

本稿で最も強調したいのがこの節である。ロボットの稼働データが自社で使えるかどうかは、技術ではなく調達で決まる。

多くのロボットは、稼働ログをベンダーのクラウドへ送る構成になっている。ベンダーの管理画面では見られるが、生データの出力可否、保存期間、API提供の有無、退会後の扱いは、製品によって大きく異なる。そして導入後に交渉すると、ほぼ確実に立場が弱い。

要件定義書・見積依頼書（RFP）の段階で、次の項目をベンダーに回答させることを勧める。ロボット導入の要件定義書で扱った枠組みの、データ編にあたる。

#	確認事項	回答してほしい粒度
1	取得できるデータ項目の一覧	項目名・単位・更新頻度が並んだ一覧表
2	生データの出力可否と形式	CSV/JSON等、手動・自動の別
3	APIの有無、認証方式、レート制限、仕様書の提供	仕様書そのもの、または目次
4	ベンダー側でのデータ保存期間	「◯か月」の明示。無期限とは限らない
5	追加費用の有無	API利用料、出力オプション料の年額
6	データの所有権・利用権の帰属	契約条項の文言
7	ベンダーが当該データを二次利用する範囲	学習利用・統計利用の可否と条件
8	契約終了時のデータの返還・削除	返還形式と期限
9	現地からの通信経路と接続先	接続先ドメイン、通信方向、必要なポート
10	停止事象のエラーコード一覧と意味	コード表の提供。これが無いと分類できない

10番のエラーコード表は特に見落とされる。 コードだけ取得できても意味がわからなければ、停止理由の分類ができない。「エラーコード一覧を納品物に含めること」を仕様書に一行入れておくだけで、後の苦労が大きく変わる。

複数ベンダーが入る場合の統合論点全般は複数ベンダー・複数機種の統合とデータ連携で扱っている。データはその6層のうちの1層であり、本稿はその層を掘り下げたものと位置づけられる。

5. どう溜めるか——3層のデータ設計

溜め方は、次の3層に分けて考えると破綻しにくい。層の名前は何でもよいが、「生のまま残す層」と「揃えた層」を分けることが要点である。

第1層：生データ層（Raw） ベンダーから取得したファイル・APIレスポンスを、加工せずそのまま日付付きで保存する。加工後にしか残していないと、後から「あの項目も見たかった」となったときに遡れない。ストレージは安価であり、捨てる理由はほとんどない。

第2層：正規化層（共通イベント） 機種・ベンダーが違っても同じ形になるよう、最小限の共通スキーマへ変換する。ここで項目を欲張らないことが継続の鍵である。実務上、次の8項目があれば大半の分析は成立する。

項目	内容	例
`event_id`	一意のID	連番でよい
`robot_id`	機体の識別子。自社で採番する	`WH-AMR-003`
`site` / `area`	拠点・フロア・エリア	`東京DC / 2F / A通路`
`timestamp`	発生時刻。タイムゾーンを明記	ISO 8601形式
`event_type`	稼働開始／停止／再開／充電／作業完了／点検等	10種類程度に固定
`state`	直後の状態（自動・待機・停止・充電・保全）	5値程度
`duration_sec`	その状態の継続秒数	停止時間の集計に使う
`reason_code`	停止理由の分類コード（第2節の分類）	`ENV-01`（障害物）等

作業量（搬送件数・清掃面積など）は機種ごとに単位が違うため、共通スキーマに無理に押し込まず、metric_name / metric_value / unit の3項目を持つ別テーブルにするのが扱いやすい。

機体IDは必ず自社で採番する。 ベンダーのシリアル番号をそのまま主キーにすると、機体交換・レンタル入替のたびに履歴が分断される。自社IDとベンダーシリアルの対応表を別に持つ。

第3層：集計層（指標） 日次・週次・月次で、稼働率・停止時間・停止件数・作業量・単位あたりコストを事前集計しておく。画面の応答が速くなるだけでなく、指標の定義を1か所に固定できるという効果が大きい。稼働率の定義が人によって違う状態は、データ基盤があっても議論を壊す。

指標の定義書は、たとえ表計算ソフト1枚でも必ず作る。「稼働率＝自動運転時間 ÷ 計画稼働時間（計画停止は分母から除く）」のように、分子と分母を文章で書く。KPI設計の考え方はロボット導入のKPI設計と効果測定を参照されたい。

6. 誰が何を見るか——3つの画面

ひとつのダッシュボードで全員を満足させようとすると、情報量が多すぎて誰も見なくなる。読み手を3つに分け、それぞれ画面1枚・指標5個以内に絞る。

読み手	見る頻度	問い	主要な表示
現場（作業者・リーダー）	毎日	今日、正常か	各機体の現在状態、本日の停止件数、未対応の異常、消耗品の残量目安
管理者（設備・改善担当）	毎週・毎月	なぜ止まったか、何を直すか	停止理由別の時間内訳（多い順）、拠点・機体別の比較、不明比率の推移、改善施策の進捗
経営	四半期	投資は回収できているか、次はどこか	稼働率の推移、削減効果の実績と計画差、単位あたりコスト、次の展開候補

管理者向け画面で最も効くのは、停止理由を時間の多い順に並べた棒グラフである。これ一つで「今月は環境要因の停止が全体の4割で、うち3割が同じ通路」といった話ができる。台数が増えても、この画面の構造は変わらない。

経営向け画面では、稼働率よりも削減効果の実績と当初計画の差を主役に置く。経営が知りたいのは機械の調子ではなく、投資判断の妥当性である。効果の語り方はロボット導入の投資対効果（ROI）の語り方で扱った枠組みに合わせる。

7. AI活用への接続——基盤がないと始まらない

稼働データ基盤を作る動機として、AI活用を挙げる企業は多い。順序を明確にしておきたい。AIは基盤の後に来る。 具体的には、次の3段階である。

段階1：可視化（データを溜めて見る） まず数か月分の連続したデータを持つこと。ここでできるのは記述——何が、いつ、どれだけ起きたか。実務上、改善効果の大半はこの段階で出る。停止理由の上位2つを潰すだけで稼働率が数ポイント動くことは珍しくない。

段階2：分析（要因を探る） 時間帯・曜日・拠点・作業種別と停止の関係を見る。「金曜夕方の停止が多い」「特定の通路で集中している」といった規則性が見つかれば、運用で対処できる。この段階でも高度なAIは要らない。集計と可視化で足りることが多い。

段階3：予測・最適化（AIを使う） 消耗品交換や故障の予兆を推定する予知保全、配車・経路・時間帯の最適化がここに入る。ただし成立には条件がある。故障・交換という「起きたこと」のラベルが、十分な件数、時刻付きで残っていること。 故障が年に数回しか起きない機体では、そもそも学習に足るデータが溜まらない。予知保全の前提条件と現実的な適用範囲は予知保全——設備データからAIで「止めない運用」へで詳しく扱っている。

したがって、AI活用を将来やりたいのであれば、今日から保全記録を構造化して残すことが最も効く準備になる。交換した部品名、交換日、その時点の稼働積算時間、交換理由。この4項目を1行ずつ残すだけで、数年後の選択肢がまったく変わる。保守運用の設計は保守・稼働管理を参照されたい。

8. 段階導入のロードマップ

大きな基盤をいきなり作らない。次の4段階で、投資を効果に追随させる。

段階	期間の目安	やること	道具	判断ポイント
第0段階	導入前	契約にデータ条項を入れる。エラーコード表を納品物にする	要件定義書・RFP	ここを飛ばすと後段すべてが高くつく
第1段階	最初の3か月	ベンダー画面から月次でCSV出力。停止事象を人が1行記録	表計算ソフト	「不明」比率が下がっているか
第2段階	3〜9か月	共通スキーマへ正規化。停止理由別の集計と月次レビューを定例化	表計算ソフト＋簡易DB／BIツール	月次レビューで改善が決まっているか
第3段階	9か月〜	API等で自動収集。3画面を整備。拠点横断で比較	データ基盤／BIツール	手作業が月◯時間を超えたか（超えてから自動化する）
第4段階	台数・拠点が増えてから	予知保全・最適化などAI活用の検討	上記＋分析環境	ラベル付きデータが十分に溜まったか

第3段階へ進む判断基準を「手作業の負荷」に置くことを勧める。「自動化したほうが格好いいから」ではなく、「毎月8時間を集計に使っており、自動化すれば回収できる」という理由で投資する。この規律があると、基盤が過剰にならない。

9. 落とし穴

項目を欲張って始める。 30項目のフォーマットを作ると、3か月で誰も入力しなくなる。8項目で始めて、足りないと感じてから足す。
稼働率の定義を揃えない。 分母が違う数字を並べて議論が空転する。定義書1枚を先に作る。
計画停止を停止に混ぜる。 点検やイベント休館を故障と同じ扱いにすると、稼働率が実態より悪く見え、改善対象を誤る。
ベンダー画面をそのまま「うちの基盤」と呼ぶ。 契約が切れた瞬間に履歴ごと失う。生データを自社側に残す仕組みを持つ。
時刻のずれを放置する。 機器・サーバ・人の記録で時刻がずれていると、突き合わせができない。タイムゾーンと時刻同期は初期に確認する。
映像・画像を安易に集める。 カメラ映像は容量とプライバシーの両面で負担が大きい。まずイベントログだけで始め、映像は必要性が確認できてから、保存期間と閲覧権限を決めたうえで扱う。
見る会議を作らない。 基盤の価値は、月次レビューで改善が決まることで初めて現れる。画面だけ作って会議を作らない導入は、必ず形骸化する。定着化・運用設計で述べた原則がここでも当てはまる。

10. 発注前チェックリスト

まとめ

ロボット稼働データの基盤は、大規模なシステム投資として構えると、たいてい始まらないまま台数だけが増えていく。実際に必要なのは、契約書の数行と、表計算ソフト1枚と、月に一度の会議である。それを3か月続けられた現場だけが、自動化に投資する価値を判断できる。

そして最も重要なのは順序である。データ条項を契約に入れるのは導入前にしかできない。停止理由を記録し始めるのは、稼働初日からでないと意味がない。AI活用の検討は、その積み重ねの上にしか乗らない。基盤とは、後から作るものではなく、最初の1行から始まるものである。

RobiZyはロボットを販売しない特定非営利活動法人であり、特定のメーカー・SIer・ツールベンダーから独立した中立の立場で、導入企業の側に立ってデータ条項の設計、指標定義、段階的な基盤構築の伴走を行っている。ユーザー企業・ロボットメーカー・SIer・運用事業者・自治体・大学が同席する場を持っていることが、この領域では特に効く。ベンダーごとに異なるデータの出し方や、他社が何をどこまで測っているかといった知見は、一社では集まりにくいためである。稼働データの扱いを含め、ロボット活用の実務知見を業界横断で共有し、標準化に向けた議論に加わっていただける方には、正会員としての参加をお勧めしたい。導入前の構想段階でのご相談も歓迎する。

ロボット稼働データの収集・可視化基盤