保存先は3系統に分かれる
工場の時系列データの保存先は、大きく次の3系統に分かれます。
| 系統 | 代表例 | 主な利用者 | 特徴 |
|---|---|---|---|
| 産業用ヒストリアン | PI System、各DCS・SCADAベンダーのヒストリアン | 運転員、プロセスエンジニア、保全 | OT機器との接続と長期保存に強い。現場のトレンド監視の定番 |
| クラウドの時系列・産業データサービス | 各クラウドの産業IoTサービス、ヒストリアンのクラウド版 | データ基盤チーム、分析担当 | 拡張と運用をクラウドに任せられる。AI・分析サービスと接続しやすい |
| OSS・汎用の時系列DB | オープンソースの時系列DB、時系列拡張を持つRDB | 社内のデータエンジニア | ライセンス費用を抑えられ自由度が高いが、運用は自社で担う |
ヒストリアンのクラウド化も進んでいます。たとえばAVEVAは、OSIsoft Cloud Servicesを前身とするCONNECT Data Servicesを提供し、DatabricksとDelta Sharingで連携するアライアンスを発表しています（ARC Advisory Group、2025年4月報道）。ヒストリアンのデータをレイクハウスにコピーせずに参照する方向の動きで、3系統の境界は少しずつ曖昧になっています。
比較の5軸
図は一般的な傾向を示した模式図で、個別の製品や構成によって評価は変わります。各軸で確認すべき点は次のとおりです。
1. 書込み性能
1秒あたりに書き込む点数（タグ数×周期）を見積もり、余裕を持って処理できるかを確認します。タグ数1万点を1秒周期で集めれば毎秒1万点、10ミリ秒周期の波形を100点集めれば毎秒1万点です。AIのために収集周期を短くすると、この数字が一桁変わることがあります。
2. 圧縮
ヒストリアンの多くはデッドバンド圧縮のような情報が失われる圧縮を使い、汎用の時系列DBはデータを失わない可逆圧縮を使うことが多い傾向があります。AIで小さな変動やばらつきを特徴量にするなら、情報が失われない保存が必要です。圧縮の影響はヒストリアンのデータはそのままAIに使えるかで扱っています。
3. クエリ・分析
AIの学習では、大量の期間・タグを一括で読み出し、MESのロット情報と結合する処理が発生します。SQLで扱えるか、Pythonの分析ライブラリやレイクハウスと直接接続できるか、大量の読み出しで現場の監視用途に影響が出ないかを確認します。
4. OT接続
PLC・DCS・SCADA・OPC UAサーバなど、既存設備からデータを取り込むインターフェースの豊富さです。産業用ヒストリアンが最も強い軸で、汎用の時系列DBではエッジゲートウェイなど別の製品で補う必要があります。
5. 保守体制
ライセンス費用だけでなく、誰が運用・障害対応・バージョンアップを担うかです。OSSはライセンス費用を抑えられますが、24時間止まらない運用を社内で支える人員が必要です。現場の監視に使うデータの保存先は、止まったときの影響が大きい点を考慮してください。
既存ヒストリアンを活かす構成
すでにヒストリアンが現場に定着している工場では、それを置き換えるより、役割を分ける構成が現実的です。
| 役割 | 担うもの | 理由 |
|---|---|---|
| 現場の監視・トレンド確認 | 既存ヒストリアン | 運転員が慣れた画面とツールを変えない |
| AIの学習用の長期蓄積 | レイクハウス、またはクラウドの蓄積先 | MESのデータと結合し、大量読み出しを現場に影響させない |
| 高頻度データ（振動・波形） | エッジで特徴量化し、生データは別保存 | ヒストリアンの書込み負荷と容量を増やさない |
| リアルタイム配信 | MQTTブローカー（UNS） | 複数のシステムに同時に配る |
ヒストリアンのデータをレイクハウスに定期的に複製するか、先に挙げたAVEVAとDatabricksの連携のように、コピーせずに参照する仕組みを使うかは、データ量と更新頻度、製品の対応状況で選びます。レイクハウスの設計は製造業のデータレイク・レイクハウスを参照してください。
選定の進め方
この4つが揃えば、5軸のうちどれを重視すべきかが見えます。タグ数が少なく周期も長いなら既存ヒストリアンの延長で足ります。高頻度データを大量に扱い、MESと結合した分析を繰り返すなら、レイクハウスを含む別の蓄積先が必要になります。運用人員が限られるなら、OSSよりもマネージドなサービスを優先します。産業データ基盤の製品全体の比較は産業データ基盤6製品の比較で扱っています。
よくある質問
PI Systemなどのヒストリアンがあれば、AI用に別の蓄積先は不要ですか？
収集周期と圧縮の設定がAI用途に合っており、MESのデータとの結合や大量読み出しが現場の運用に影響しなければ、ヒストリアンだけでも始められます。テーマが増え、学習のための大量読み出しが頻繁になった段階で、別の蓄積先を検討するのが一般的です。
OSSの時系列DBで工場の本番運用はできますか？
技術的には可能ですが、障害時の対応、バックアップ、バージョンアップを社内で担える体制が前提です。現場の監視に使う場合は、止まったときの影響を考慮し、商用サポートの有無も確認してください。
クラウドに時系列データを置くと、通信が切れたときはどうなりますか？
工場内のエッジやヒストリアンでデータを一時保存し、回復後に送る（ストア・アンド・フォワード）構成が必要です。現場の監視やリアルタイムの推論は工場内で完結させ、クラウドは学習と横断分析に使う役割分担が安全です。
この記事に出てくる用語
AIは「データ基盤」で決まる
PoCは成功したのに本番で止まる。原因の多くはモデルではなく、MESと設備データの側にある 全130本
- MESとAIの関係：ロット・作業指示・品質判定がAIの精度を決める理由
- 製造業AIが本番で止まる7つの理由：PoCは成功したのにラインに載らない構造
- 製造業のAI-OCR：紙の検査記録・点検表・ミルシートをデータ化する手順
- データ基盤の段階的導入ロードマップ：ユースケースから逆算する8ステップ
この記事を書いた人
DELMIA Apriso を中核とした MES / 製造DX の導入・運用・人材育成と、製造業向けAIの調査・開発・教育を手がけるITコンサルティング企業。ISO 9001:2015 / ISO 27001:2022 認証取得。 日本・中国・米国で製造業のMES・データ基盤・AI導入を手がけた実務者が、欧米・中国の一次情報にあたって書いています。
