資料請求 お問い合わせ

Blog

2026.10.06

産業用ヒストリアン導入｜選定比較とタイ工場のRFP・受入試験

産業用ヒストリアン導入｜選定比較とタイ工場のRFP・受入試験

「SCADAに履歴はあるはずなのに、去年の不良が出た日の温度を出そうとすると、遅い、欠けている、どのタグなのか分からない」。タイの日系工場の制御・計装や工場ITの方から、こうした相談をよく受けます。結論から書きます。産業用ヒストリアンの導入で手に入れるべきものは、大量の保存領域ではなく、「信頼でき、文脈が付き、あとから再生できる時系列データ」です。 そのために決めることは4つあります。①そもそもヒストリアンが要るのか、②何をどの精度・どの時刻で残すのか、③ネットワークのどこに置くのか、④受入試験で何を確かめるのか。製品の比較は、この4つを決めてからの方がうまくいきます。

本記事に登場するタグ数・周期・データ量・バッファ容量などの数値は、出典を示したものを除き、後述のモデル工場を前提にした本記事オリジナルの仮定値です。業界平均でも調査値でもありません。また、製品の機能や予定は、各社が公表した内容（メーカー発表）として紹介しています。いずれもTOMAS TECHの製品ではなく、他社の製品です。

なぜ今、産業用ヒストリアンの導入が問われるのか

2026年9月のICC 2026で発表された内容

ヒストリアンをめぐって、ここ数週間で目立つ発表がありました。Inductive Automation社は2026年9月23日付のプレスリリースで、米サクラメントで開いた年次カンファレンスICC 2026（同社によれば1,800人超が参加、60超のセッション）において、次期版「Ignition 2027」の一部として、TimescaleDB向けの新しい「Enterprise Historian Module」をプレビューしたと発表しました。あわせて、TimescaleDBを開発するTiger Data社が戦略的パートナーとなり、両社で「TimescaleDB for Ignition」を開発し、これはInductive Automationが直接販売・サポートするとしています。

同社が9月30日に公開した振り返りの記事によると、このモジュールはクエリ性能・高可用性・保存容量の要求に応えるためのものです。Ignition 2027は2027年2月にリリースされる予定で、年次リリースのモデルに移行するとされています。また、現行のIgnition 8.3は長期サポート（LTS）版として2030年までサポートされる、と同社は説明しています。いずれもメーカーの発表であり、Enterprise Historian Moduleはプレビューの段階です。提供開始日や価格は示されていません。

なお、Tiger Dataは、2025年6月17日にTimescale社から社名を変えた会社です。オープンソースの時系列データベース拡張（PostgreSQLの拡張）は、引き続き「TimescaleDB」という名前です。会社名と製品名を混同しないように注意してください。両社は2026年4月20日のHannover Messe 2026でも協業を発表しており、その発表文では、市場の課題として「クローズドなタグ単位のライセンス」や「独自のデータ形式」が挙げられていました。これは当事者の主張ですが、ヒストリアンの選定でライセンスの数え方やデータの取り出しやすさが論点になっていることを示しています。

タイ工場にとっての意味

この発表は、すぐに何かを買い替える理由にはなりません。ただ、ヒストリアンの選択肢が「専用製品か、SCADAのおまけの履歴か」の二択ではなくなり、汎用の時系列データベースを裏側に使う構成が、産業用ソフトウェアのベンダーの公式な選択肢にもなりつつある、という変化は押さえておく価値があります。

これからヒストリアンを入れる、あるいは古い履歴の仕組みを入れ替える工場にとっては、「今の長期サポート版で入れるか、次の版を待つか」「データを特定の製品の形式に閉じ込めないか」という判断が、以前より具体的になったと考えられます。その判断の土台になるのが、本記事で扱う4つの決めごとです。

産業用ヒストリアンとは：SCADAのログ・汎用の時系列データベースとの違い

NISTによる定義と、制御システムの中での位置

米国立標準技術研究所（NIST）のOTセキュリティのガイド「SP 800-82 Rev.3」（2023年9月）は、用語集でデータヒストリアンを「統計的プロセス管理（SPC）の手法を用いたデータ分析を支える集中型のデータベース」と定義しています。同じ文書は、制御センターの構成として、HMI、エンジニアリング用のワークステーション、データヒストリアンがLANでつながる構成や、PLCのデータがヒストリアンに保存される構成を例に挙げています。

用途はSPCに限りません。同文書は、OTのネットワークに特有のものとして、データヒストリアンがサイバーインシデントの状況を補う「補助的な」イベントデータの情報源になり得る、とも書いています。ただし「補助的」であり、セキュリティのログ基盤の代わりになるという意味ではありません。品質の調査、設備の異常の解析、エネルギーの分析、そして事故の振り返りまで、工場で起きたことを時間軸でたどるための記録、と理解しておくのがよいでしょう。

SCADAのログと何が違うのか

SCADAやHMIにも、トレンド表示のための履歴の機能があります。本記事では、次の3つを分けて考えます。

観点SCADA・HMIの履歴機能汎用の時系列データベース専用の産業用ヒストリアン
主な目的運転画面でのトレンド表示、直近の振り返り時系列データの高速な書き込みと集計を、自前の設計で使う工場全体のプロセスデータを長期に保存し、品質・設備・エネルギーの分析に使う
収集そのSCADAが持つタグに限られることが多い収集の仕組みは別途作る（ゲートウェイ、MQTT、自作の連携など）各種の制御機器向けの収集機能（インターフェース、アダプター、コネクター）を持つことが多い
データの扱い製品ごとの設定。保持期間が短めに設定されていることもある圧縮・保持の方針は設計次第デッドバンド、圧縮、品質フラグ、順序外データの扱いなどを製品が持つ
向く場面1ラインの運転監視が主目的で、分析の要求が小さいIT部門に時系列DBの運用経験があり、収集と運用を自社で設計できる複数ライン・複数システムのデータを、長期に、運転とは独立に残したい

表の内容は一般的な傾向として本記事が整理したもので、製品によって大きく違います。大事なのは、どれが優れているかではなく、「自社の要求がどこにあるか」です。SCADA自体の選定や更新の考え方は「SCADAとは？タイ工場の更新・RFP・FAT/SAT実務」で解説しています。

「保存できる」と「再生できる」は違う

ヒストリアンの価値は、データを大量に溜められることではありません。半年後に品質の問題が見つかったとき、その日のその時刻に、どのタグがどんな値で、その値が信頼できるものだったか（センサーの異常や通信断ではないか）を、あとから再生できることにあります。そのためには、値だけでなく、正確な時刻、品質の情報（正常か、欠測か、代替値か）、タグの意味（どの設備のどの計器か、単位は何か）が、値と一緒に残っている必要があります。本記事が「信頼でき、文脈が付き、再生できる」と言うのはこの意味です。

ヒストリアン選定比較：3つの選択肢と製品動向の読み方

第1の判断：本当にヒストリアンが要るのか

次のような状況が2つ以上当てはまるなら、SCADAの履歴機能だけでは足りなくなっている可能性が高い、と本記事は考えます。

  • 複数のライン・複数のSCADAやPLCのデータを、同じ時間軸で比べたい
  • 品質の調査のために、数年単位でプロセスデータを残す必要がある
  • 運転用のSCADAに、分析のための重い問い合わせをかけたくない
  • 本社や品質保証部門など、制御ネットワークの外の人がデータを見たい
  • 通信が切れても、データの欠けを後から埋めたい

逆に、1ラインの運転監視が目的で、保持期間も短くてよいなら、まずSCADAの履歴設定を見直す方が早いこともあります。

汎用の時系列データベースを使う場合

汎用の時系列データベースは、選択肢が広がっています。例として、InfluxData社は2025年4月15日に「InfluxDB 3 Core」と「InfluxDB 3 Enterprise」の一般提供を発表しました。同社によれば、CoreはMIT/Apache 2ライセンスのオープンソースで、「リアルタイム用途向けの高速な直近データのエンジン」と位置づけられています。Enterpriseは、高可用性、リードレプリカ、自動フェイルオーバーなどを加えたものとされます。Coreが「直近データ向け」と説明されている点は、長期保存のヒストリアンとして使うかを考えるときの確認事項になります。

PostgreSQLの拡張であるTimescaleDB（開発はTiger Data社）も、汎用の時系列データベースの代表的な選択肢の1つです。前述のとおり、Inductive Automation社はこれを自社のヒストリアンの選択肢に組み込むと発表しています。

汎用データベースを選ぶ場合、収集、品質フラグ、順序外データ、欠測の補完、圧縮、保持期間、権限の管理を、自分たちで設計し、運用する必要があります。IT部門にその経験と人手があるかどうかが、選定の大きな分かれ目になると考えられます。

産業用ソフトウェア・専用ヒストリアン製品の動き

産業用ソフトウェアの製品でも、ヒストリアンの機能が見直されています。Inductive Automation社は2025年9月16日にIgnition 8.3をリリースし、「Industrial Historian Solution Suite」として、Historian Core Module、SQL Historian Module、独自のヒストリアンを実装するためのHistorian APIをそろえたと発表しています。同社のドキュメントによると、Core HistorianはQuestDBを組み込んだデータベースで、パーティション分割、重複の排除、アーカイブ、集計の機能を持ち、古いデータの扱いを「None（無期限に保存）」「Prune（古いパーティションを削除）」「Archive（別の場所へ移動）」から選べます。メモリの割り当ては、既定でシステムの総メモリの10%とされています。QuestDB社のドキュメントは、これが従来のSQLiteベースの内部ヒストリアンを置き換えたものだと説明しています。

専用ヒストリアンの例では、Canary Labs社が公式サイトで、保存の方式を「ロスレス圧縮」とし、ストア＆フォワードを専用の構成要素として、オフラインでも確実に届けると説明しています。AVEVA社のPI Systemは、後述する例外（デッドバンド）とスウィングドア方式の圧縮を持つ製品です。AVEVAは、PI Server 2024 R2で順序外データの処理の改善などを公表したとされます。

これらは市場にある選択肢の例で、ほかにも多くの製品があります。ここでは推奨や優劣の評価はしません。比較のときに見るべきなのは、性能の倍率やタグの上限の数字よりも、次の節以降で扱う「何をどう残し、どう受け入れるか」を、その製品と構成で満たせるかどうかです。

標準インターフェースの確認

製品を選ぶときに確認しておきたいのが、履歴データの取り出し方の標準です。OPC Foundationの「OPC 10000-11 UA Part 11: Historical Access」は、ヒストリアンやデータベースへのデータの保存と取得の方法を定めた仕様で、データとイベントの履歴の考え方、アーカイブしたデータや注釈の作成・取得・更新・削除の振る舞い、アクセス権と監査を含むセキュリティを扱っています。最新版はV1.05.04（2024年11月29日リリース）です。補間や時間平均などの集計の扱いについては、「Part 13: Aggregates」という仕様があり、1.05.07版（2026年4月15日公開）がOPC Foundationのリファレンスサイトに掲載されています。

製品が「OPC UA対応」と書いていても、現在値の読み書きだけで、履歴の取得（Part 11）には対応していないこともあり得ます。RFPでは、履歴の取得と集計に何の仕様で対応しているかを、個別に確認します。

何をどう残すか：タグ台帳・サンプリング・時刻・ストア＆フォワード

産業用ヒストリアン導入｜選定比較とタイ工場のRFP・受入試験 - figure 1

タグ台帳が本当の設計書

ヒストリアンの導入で最初に作るべき成果物は、サーバーの構成図ではなく、タグの台帳です。台帳には、少なくとも次の情報を持たせます。

  • タグ名と、どの設備・どの計器のものか（設備の階層）
  • 単位、測定範囲、計器の精度
  • 収集の周期（スキャンの間隔）
  • デッドバンド・圧縮の設定と、その根拠
  • 保持期間
  • 品質フラグの意味
  • 説明（日本語・英語・タイ語）

タグ名がPLCのアドレスのままだと、数年後に誰も意味が分からなくなります。設備やタグの階層をどう名付けるかは、MQTTで送る場合のトピック設計とも関係します。考え方は「MQTT Sparkplug B導入｜タイ工場の検収・90日実証」で扱っています。また、タグの元になる機器の一覧が古いままでは台帳も作れません。制御機器の棚卸しは「OT資産管理の導入実務」が参考になります。

サンプリング周期は「使い道」から決める

すべてのタグを最短の周期で取れば安心に見えますが、容量と通信の負荷が増えるだけで、使われないデータが積み上がります。周期は、そのデータを何に使うかで決めます。温度のようにゆっくり変わる値と、圧力の急な変化を捉えたい値とでは、必要な周期が違います。デジタルの状態（運転・停止、警報など）は、一定の周期で取るより、変化したときだけ記録する方が自然な場合が多いと考えられます。

時刻と品質を値と一緒に残す

あとから再生できるデータにするには、「いつの値か」が正しいことが前提です。タイムスタンプを、PLCやセンサーの側で付けるのか、ゲートウェイで付けるのか、ヒストリアンに届いたときに付けるのかで、意味が変わります。通信が遅れたデータに、届いた時刻が付いてしまうと、原因と結果の順番が入れ替わって見えることがあります。工場内の時刻源を統一し、どこで付けた時刻なのかを仕様に書くことが重要だと考えられます。保存は協定世界時（UTC）で行い、表示のときにタイの現地時刻に変換する方式にしておくと、海外拠点や本社とデータを比べるときに混乱が少なくなります。

値の品質も一緒に残します。センサーの断線、通信の途絶、手入力の代替値などを、正常な値と同じように扱うと、分析の結論を誤ります。

ストア＆フォワードで欠測を防ぐ

工場のネットワークは止まります。機器の故障、工事、停電の後の復帰の順番など、理由はさまざまです。ストア＆フォワードは、収集側（エッジのゲートウェイや収集サーバー）で、送れなかったデータを一時的に貯めておき、通信が戻ったら古い順に送る仕組みです。これがないと、通信が止まっていた時間のデータは永久に失われます。

ここで注意が要るのが、遅れて届いたデータの扱いです。AVEVA社の講演資料によると、PI Systemでは「順序外（out of order）のデータは圧縮をバイパスする」とされています。製品によって、遅れて届いたデータを正しい時刻の位置に入れられるか、入れたときに圧縮や集計がどうなるかは違います。バッファの容量をどう見積もるかは、後の試算で扱います。

プロセスデータ長期保存の要：デッドバンドと圧縮は計器精度から決める

産業用ヒストリアン導入｜選定比較とタイ工場のRFP・受入試験 - figure 2

例外と圧縮：AVEVA PI Systemの例

長期保存で最も議論になるのが、データを間引く設定です。ここでは、方式が公開資料で説明されている例として、AVEVA社のPI Systemを取り上げます（2023年のAVEVA World San Franciscoでの講演資料による。PI Systemに固有の用語で、他社のヒストリアンに一般化はできません）。

PI Systemには、2段階の仕組みがあります。1つ目の「例外（Exception）」は、ノイズを除くための単純なデッドバンドで、収集側のPI Interfacesでだけ実行され、送るイベントの数を減らしてネットワークの帯域を節約します。設定項目は、工学単位でのデッドバンドの幅（ExDev）、スパンに対する割合（ExDevPercent）、イベントの間の最大の秒数（ExMax）です。同じ資料は、AVEVA Adaptersはデッドバンドのフィルタはできるがタグの例外設定は無視する、PI Connectorsは例外のテストを行わない、と注記しています。つまり、同じ製品の中でも、収集の手段によって間引きの挙動が違います。 これはRFPで確認すべき点です。

2つ目の「圧縮（Compression）」は、スウィングドアと呼ばれるアルゴリズムで、補間すれば安全に再現できる点を捨てることで、保存するデータの量を減らします。資料には、目的として「計器やプロセスのノイズを除きつつ、重要なプロセスの変化は記録する」という引用があります。

「設定しない」も「設定しすぎ」も問題になる

同じ資料には、見落としやすい注意点が書かれています。既定値はゼロではないこと、そして「圧縮をオフにする」ことと「圧縮をオンにして偏差をゼロにする」ことは同じではないことです。導入時に既定値のまま運用を始めると、意図しない間引きが起きている可能性があります。

効果の例として、例外なし・1秒のスキャン・0と1だけをとる状態タグで、48時間のイベント数が、圧縮なしで172,800、最小限の圧縮で15とされています。172,800は48時間×3,600秒の全点です。ただしこれは、0と1だけをとるデジタルの状態タグという特定の条件の例で、アナログの値にこの比率を当てはめることはできません。

一方、米国のオフショアの石油・ガスの顧客事例では、87%超のタグが例外も圧縮も使っておらず、陸上側のサーバーが周期的に不安定になっていた、とされています。タグを分類し、計器の精度と現場の有識者の意見から新しい設定を決めて、パイロットのリグで試した結果、保存イベントが約94%減ったと報告されています。これも単一の顧客のパイロットの結果で、工場一般の効果ではありません。ここから読み取るべきなのは、削減率の数字ではなく、「全点を保存し続けることにも、設定しすぎて変化を落とすことにも、どちらにも問題がある」ということです。

計器の精度を基準に決め、元データとの差を検証する

では、設定値は何を基準に決めるのか。同じ資料の米国の製油所の事例では、控えめな例外・圧縮の設定を使った結果、解析の対象としたタグのすべてで、元のデータとの最大の差が計器の測定精度を下回った、と報告されています。この事例が示しているのは、「計器が測れる精度より細かい変化を保存しても意味がない。逆に、計器の精度を超える差を生む間引きは、データを壊している」という考え方です。

本記事では、次の手順を勧めます。

  1. タグを、計器の種類と用途（品質の調査、制御の解析、エネルギーなど）で分類する
  2. 計器の精度をタグ台帳に書き、それを基準にデッドバンド・圧縮の幅の仮の値を決める
  3. 試験用のタグで、全点の生データと、間引いた後のデータを並べて保存する
  4. 間引いたデータを補間したときの、元データとの最大の差を計算し、計器の精度の範囲に入るかを確かめる
  5. 品質に関わる重要なタグは、現場の有識者と一緒に、急な変化が落ちていないかをトレンドで目で確かめる
  6. 問題がなければ、同じ分類のタグに展開する

製品によって方式が違うことにも注意します。間引きをしない「ロスレス圧縮」を掲げる製品もあれば、補間で再現できる点を捨てる方式の製品もあります。どちらが良いかではなく、自社が保存したい精度を、選んだ製品の方式と設定で守れるかどうかを、受入試験で確かめることが大切です。

時系列データベースの容量を工場モデルで試算する（仮定モデル）

ここからの数値は、すべて本記事が独自に置いた仮定値です。製品の性能や業界の平均ではありません。計算の型として使い、自社のタグ数と周期に置き換えてください。

前提（モデル工場H）

項目前提（仮定値）
工場タイ東部の日系の樹脂・化学系工場
タグ数2,000点（アナログ1,500点、デジタル500点）
収集の周期比較を単純にするため、全タグ1秒
1点あたりの保存サイズ16バイト（時刻・値・品質フラグを含む、圧縮前の仮定値）
1年365日
単位1 GB＝10億バイト

生データの量

1タグが1日に生む点の数は、24時間×3,600秒＝86,400点です（前述のAVEVAの例の172,800点は、この2日分にあたります）。2,000タグでは、2,000×86,400＝1億7,280万点/日、1年では1億7,280万×365＝630億7,200万点/年になります。

バイトに直すと、1日は1億7,280万点×16バイト＝27億6,480万バイトで約2.76 GB、1年は630億7,200万点×16バイト＝1兆91億5,200万バイトで約1,009 GB、10年では約10,092 GBです。

保存率による違い

デッドバンドや圧縮でどれだけ減るかは、信号の性質と設定で大きく変わります。そこで、削減率を予想するのではなく、比較のために仮の保存率を置いて、量の感覚をつかみます。

保存率（仮定）1年の保存量10年の保存量
100%（全点保存）約1,009 GB約10,092 GB
50%約505 GB約5,046 GB
25%約252 GB約2,523 GB
10%約101 GB約1,009 GB

この表から読み取れるのは、仮に置いた保存率の幅（10〜100%）だけでも、同じ工場で必要な容量が10倍違うということです。全点保存の1年分と、保存率10%の10年分が、同じ量になります。容量の見積もりは、製品のカタログの値ではなく、試験用のタグで実測した保存率から計算し直すべきだと考えられます。また、バックアップの容量やレプリカの分も別に必要です。

ストア＆フォワードのバッファを見積もる

次に、通信が止まったときのバッファです。連休中に回線の機器が故障し、72時間誰も気付かなかった、と仮定します。この間に貯まる点の数は、2,000タグ×3,600秒×72時間＝5億1,840万点、バイトでは5億1,840万×16＝82億9,440万バイトで約8.29 GBです。余裕を2倍見るなら、エッジ側に約16.6 GB以上のバッファが要ることになります。

通信が戻った後、貯まったデータを送り切るまでの時間も見積もります。エッジの送出能力を毎秒1万点と仮定すると、その間も新しいデータが毎秒2,000点生まれるので、バッファが減る速さは毎秒8,000点です。5億1,840万点÷8,000点＝64,800秒、つまり18時間かかります。この18時間は、ヒストリアン上ではまだデータが埋まっていない時間です。送出能力やヒストリアン側の書き込み能力が足りなければ、さらに延びます。

この計算から、受入試験で確かめるべきことが見えてきます。「何時間の断線に耐えられるか」「戻ってから何時間で追いつくか」「その間、順序外で届いたデータが正しい時刻に入り、圧縮や集計が崩れないか」です。

ヒストリアンをどこに置くか：OT・DMZ・企業ネットワーク

産業用ヒストリアン導入｜選定比較とタイ工場のRFP・受入試験 - figure 3

NISTの原則：企業とOTの通信はDMZのサービスを経由する

ヒストリアンは、制御システムのデータを、制御ネットワークの外にいる人が使うための仕組みでもあります。そのため、どこに置くかがセキュリティの設計と直結します。

NIST SP 800-82r3のセキュリティアーキテクチャの例は、OT環境と企業ネットワークを分けるためにDMZを置き、企業のレベルと運用管理のレベル（Purdueモデルのレベル3を含む）の間の通信は、すべてDMZの中のサービスを経由する、としています。フィールドのレベルはPurdueモデルのレベル0〜2の機器を含むと説明されています。さらに、DMZは外部とつながるので、攻撃者がOTの環境へ気付かれずに入り込まないよう、DMZの中のサービスは監視し、保護しなければならない、としています。

本記事の設計例：OT側の一次ヒストリアンと、DMZの全社向けレプリカ

この原則から、本記事では次の構成を設計例として考えます。なお、これはNISTの原則から導いた本記事の考え方であり、NISTがヒストリアンの配置をこの形で指定しているわけではありません。

  • 一次ヒストリアン：OT側（運用管理のレベル）に置き、PLCやSCADAからデータを集める。運転と品質の調査の正本
  • 全社向けのレプリカ：DMZに置き、一次ヒストリアンからデータを受け取る。本社、品質保証、分析チームなど、企業ネットワーク側の利用者は、このレプリカにだけアクセスする
  • 企業ネットワーク：BIやERPなどは、DMZのレプリカからデータを取る。OT側のヒストリアンに直接つながない

こうしておくと、企業側から重い問い合わせが来ても、運転を支える一次ヒストリアンには影響しにくく、OT側への入り口も少なくできると考えられます。

「直結の自動複製」に潜む弱点

注意したいのは、データを複製する仕組みそのものも攻撃や誤りの経路になる点です。NIST SP 800-82r3は脆弱性の例として「不適切なデータのリンク」を挙げ、データヒストリアンのデータを他のデータベースへ自動的に複製するデータベースリンクが、適切に構成されていないと、不正なアクセスや改ざんを許す脆弱性になり得る、としています。

便利だからといって、IT側のBIやERPのデータベースからOT側のヒストリアンに直接リンクを張る設計は避け、複製の方向、使う通信、認証、監視を設計書に書くべきだと考えられます。OTからITへの一方向だけを物理的に保証したい場合は、データダイオードという選択肢もあります。考え方は「工場データダイオード導入ガイド」で整理しています。

ヒストリアンのサーバー自体の保護

ヒストリアンのサーバーは、多くの場合、汎用のWindowsやLinuxで動きます。NIST SP 800-82r3は、エンジニアリング用のワークステーション、データヒストリアン、保守用のノートPC、バックアップサーバーなどに使われる汎用のシステムは、制御ネットワークの中に置いたウイルス対策サーバーから更新を配るなどの方法で、一般にIT機器と同様に保護できる、としています（「一般に」という限定付きです。PLCなどの制御機器に同じ扱いを広げることはできません）。OSの更新、アカウントの管理、バックアップを、誰がどの手順で行うかを、導入時に決めておきます。

規制対象業種のデータインテグリティと監査証跡

米国向けの医薬品、医療機器、食品などで、米国食品医薬品局（FDA）の規制対象となる電子記録を扱う工場では、ヒストリアンのデータの扱いに、さらに要求が加わる場合があります。米国の連邦規則21 CFR §11.10は、クローズドシステムで電子記録を作成・変更・維持・送信する者に対し、電子記録の真正性・完全性を確保する手順と管理を求めています。その1つとして(e)は、安全な、コンピューターが生成するタイムスタンプ付きの監査証跡で、電子記録を作成・変更・削除するオペレーターの入力と操作の日時を、独立して記録することを挙げています。

これは米国FDAの規制で、FDAの規制対象の記録を扱う場合に限られます。タイの工場一般の法的な義務ではありません。ただし、対象になる工場では、ヒストリアンのデータを後から修正したとき（手入力の訂正、欠測の補完、注釈の追加など）に、誰が、いつ、何を変えたかが残るかが、製品選定の要件になります。前述のOPC UA Part 11も、アクセス権と監査を含むセキュリティを扱っています。対象になるかどうか、何が求められるかは、品質保証部門や専門家に個別に確認してください。

ヒストリアンのRFPに書く12項目

メーカーやシステム会社に見積もりを依頼する際、ヒストリアンのRFP（提案依頼書）に最低限書いておきたい項目です。

  1. 用途と利用者：品質の調査、設備の解析、エネルギー、事故の振り返りなど、何に使い、誰が見るか
  2. タグ台帳：タグ数、データ型、単位、計器の精度、設備の階層、説明の言語
  3. 収集の手段と対象機器：PLC・SCADA・計器の種類、通信方式。収集の手段ごとに、デッドバンドや例外の設定が効くかどうか
  4. 周期・デッドバンド・圧縮の方式と設定方法：方式（間引きか、ロスレスか）、既定値、設定の根拠の残し方、変更の権限と履歴
  5. 時刻と品質：タイムスタンプをどこで付けるか、時刻源、保存の時刻系（UTCか現地時刻か）、品質フラグの種類
  6. ストア＆フォワード：バッファの容量、耐えられる断線の時間、復旧後の送出能力、順序外データの扱い
  7. 保存期間と容量：保持期間、古いデータの扱い（削除・アーカイブ）、容量の見積もりの根拠
  8. 配置とネットワーク：OT側の一次ヒストリアンとDMZのレプリカの構成、複製の方向と方式、外部からのアクセスの経路
  9. データの取り出し：OPC UAの履歴取得（Part 11）や集計（Part 13）への対応、SQL・API・CSVなど、ほかのシステムへの出し方。独自形式に閉じないか
  10. ライセンスの数え方と将来の版：タグ数・接続数・サーバー数のどれで数えるか、増設のときの扱い、長期サポートの期間と次の版への移行
  11. 監査証跡とセキュリティ：データ修正の記録、アカウントと権限、OSの更新とバックアップの手順（規制対象の場合はその要件）
  12. 現地サポートとFAT/SAT基準：タイ国内の保守窓口、タイ語での説明、障害時の対応時間、試験項目と合格基準、立会いの範囲

特に大事なのは3・4・6です。3を書かないと、同じ製品名でも収集の手段によって間引きの挙動が違うことに、導入後に気付くことになります。4を書かないと、既定値のまま意図しない間引きが続きます。6を書かないと、通信断の時間のデータが消えても、誰も責任を持てません。また10は、今回のICC 2026の発表のように製品の版や構成が変わっていく中で、5年後、10年後にデータを持ち出せるかを左右します。全社の製造データの集め方の中でヒストリアンをどう位置づけるかは「製造データ 収集｜タイ工場の90日PoC・RFP設計」で整理しています。

ヒストリアンのFAT/SATで確認すること

工場出荷前の試験（FAT）と、据付後の現地での試験（SAT）では、カタログの値ではなく、「データが欠けない・壊れない・時刻が正しい・必要なときに取り出せる・失っても戻せる」ことを、自社の条件で確かめます。

試験項目方法合格基準の決め方主な段階
通信断と欠測の補完収集側とヒストリアンの間の通信を意図的に止め、再開後にデータが正しい時刻で埋まるかを見るRFPで決めた断線時間に耐え、欠けがないこと。復旧から追いつくまでの時間を記録FAT・SAT
順序外データ遅れて届いたデータが、正しい位置に入り、集計や圧縮が崩れないかを確認再生したトレンドと元データが一致することFAT
圧縮・デッドバンドの誤差試験用のタグで全点データと保存データを並べ、補間した値との最大の差を計算最大の差が、タグ台帳の計器の精度の範囲に入ることFAT・SAT
急な変化の保持品質に関わるタグで、短いピークや段差を発生させ、保存後も残るかを確認現場の有識者がトレンドで確認し、重要な変化が落ちていないことSAT
時刻の正しさ機器側の時刻と、保存された時刻を比べる。時刻源を切り替えたときの挙動も見るRFPで決めた許容の差に入ること。どこで付けた時刻かが仕様どおりであることFAT・SAT
品質フラグセンサーの断線や通信の途絶を起こし、品質が正しく記録されるかを確認異常な値が正常な値として保存されないことFAT・SAT
クエリの性能長い期間・多くのタグの問い合わせを、本番に近いデータ量で実行利用者の業務で必要な応答時間を、事前に決めた基準で満たすことSAT
レプリカと複製一次ヒストリアンとDMZのレプリカの内容を比べ、複製の方向と経路を確認内容が一致し、企業側からOT側への経路が設計どおり閉じていることSAT
バックアップとリストア実際にバックアップから別のサーバーへ戻し、データとタグの設定が戻るかを確認決めた時間内に、決めた時点まで戻せることSAT
停電後の復帰電源を落として再投入し、収集とストア＆フォワードが自動で戻るかを確認手作業なしで復帰し、欠けがバッファで埋まることSAT

合格基準の数値は、工場の用途によって違うので、RFPの段階で決めておきます。特に「リストア」は、計画だけ作って一度も試さないことが多い項目です。ヒストリアンのデータは後から取り直せないので、戻せることを実際に確かめておく価値は大きいと考えられます。

タイ・ASEAN固有の論点

BOIの効率化措置

タイ投資委員会（BOI）の投資奨励ガイド（2023年版）の「スマート＆サステナブル産業への高度化措置」では、既存の事業（BOIの奨励を受けているかどうかを問わない）の効率化について、投資額100万バーツ以上（土地と運転資金を除く）を条件とした恩典が示されています。デジタル技術の導入の措置は、3年間の法人所得税の免除（上限は投資額の50%）、NSTDAの承認を受けた計画によるIndustry 4.0への転換は、3年間の法人所得税の免除（上限は投資額の100%）とされています。デジタル技術の導入の要件として、組織の内外で少なくとも3つの機能のデータをつなぐソフトウェアや情報システムの導入、またはAI・機械学習・ビッグデータ・データ分析の活用などが挙げられ、一部のケースではタイ国内の認証を受けた事業者が開発・改修したソフトウェアへの投資が必要とされています。対象外の業種もあります。

ただし、これは2023年版の資料で、2026年10月時点で受付中か、条件が変わっていないかは確認できていません。ヒストリアンの導入が対象になり得るかどうかは、最新の募集要項を確認し、BOIや専門家に個別に確認してください。

タイのサイバーセキュリティ法

Tilleke & Gibbins法律事務所の解説（2025年8月1日）によると、タイのサイバーセキュリティ法（仏暦2562年、2019年）は現在、国家機関、監督・規制機関、指定された重要情報インフラ（CII）の組織に適用されます。CIIの分野は、国家安全保障、重要な公共サービス、銀行・金融、IT、通信、運輸・物流、エネルギー・公益、公衆衛生で、製造業は現行の分野に含まれていません。CIIの組織は、インシデントの初報を24時間以内に行う必要があります。2025年7月に公表された改正の草案では、「industrial work」の追加も提案されましたが、草案の段階で、その後の成立は本記事では確認できていません。

一般の日系の製造工場に、この法律が直接の義務を課しているわけではありません。ただし、エネルギーや公益の設備を持つ場合や、今後の改正の動きによっては影響が出る可能性があります。適用の有無は、専門家に個別に確認してください。ヒストリアンのデータは、インシデントの際に状況を補う記録にもなり得るので、保存期間や時刻の正しさを決めるときの判断材料の1つにはなると考えられます。

現地の運用で気をつけたいこと

ここからは本記事の考え方です。タイの工場では、運転員や保全の担当者がタイ語で、日本人の駐在員が日本語で、本社や海外拠点が英語でデータを見ることが少なくありません。タグの説明を3つの言語で持てるか、画面やレポートの言語を切り替えられるかは、使われるヒストリアンになるかどうかを左右します。また、障害のときに現地で対応できる保守体制があるか、停電のあとの復帰の手順がタイ語で書かれているかも、導入前に確認しておきたい点です。

複数の工場や、ヒストリアン以外のシステム（MES、品質、保全）のデータとつないで使うことまで考えるなら、ヒストリアンを「データの一部を受け持つ部品」として位置づける考え方もあります。「製造業 データファブリック 導入」もあわせてご覧ください。

産業用ヒストリアン導入の90日計画

0〜30日：用途の整理とタグ台帳の棚卸し

品質の調査、設備の解析、エネルギーなど、ヒストリアンを何に使うかを決め、利用者を洗い出します。そのうえで、対象の設備とタグを一覧にし、単位、計器の精度、必要な周期、保持期間を台帳に書きます。SCADAの履歴で足りるのか、汎用の時系列データベースで作るのか、専用のヒストリアンを入れるのか、第1の判断の仮決めもこの段階で行います。

31〜60日：試験用のタグで実測する

代表的なタグを数十点選び、全点の生データと、デッドバンド・圧縮をかけたデータを並べて保存します。元データとの最大の差が計器の精度に収まるか、重要な変化が落ちないかを、現場の有識者と確かめます。同時に、通信を意図的に止めて、ストア＆フォワードで欠けが埋まるか、時刻が正しいかを試します。ここで得た保存率から、自社版の容量の試算を作り直します。

61〜90日：RFP・FAT/SAT基準・発注判定

実測の結果をもとに、RFPの12項目と、FAT/SATの試験項目・合格基準を確定し、複数社から同じ条件で見積もりを取ります。配置（OT側とDMZのレプリカ）とネットワークの設計を、工場IT・情報セキュリティの担当者と合意します。製品の版の選び方（現行の長期サポート版で入れるか、次の版を待つか）も、各社の公表しているサポート期間を確認したうえで、ここで判断します。

90日の終わりに手元にそろえておきたい成果物は、①用途と利用者の定義、②タグ台帳（精度・周期・保持期間・圧縮の根拠つき）、③試験用タグでの圧縮誤差と断線試験の記録、④自社版の容量の試算、⑤配置とネットワークの設計、⑥RFPとFAT/SAT基準、の6点です。

よくある質問

産業用ヒストリアンとは？SCADAのデータ保存と何が違う？

産業用ヒストリアンは、工場のプロセスデータを時間軸に沿って長期に保存し、分析に使うための仕組みです。NIST SP 800-82r3は、統計的プロセス管理を支える集中型のデータベースと定義しています。SCADAの履歴機能は運転画面でのトレンド表示が主な目的で、対象がそのSCADAのタグに限られたり、保持期間が短めだったりすることがあります。複数のライン・システムのデータを長期に、運転とは独立に残したいなら、ヒストリアンが候補になります。

ヒストリアンと汎用の時系列データベースはどう選び分ける？

汎用の時系列データベースは自由度が高い一方、収集、品質フラグ、順序外データ、圧縮、保持期間、権限の管理を自社で設計し、運用する必要があります。専用のヒストリアンは、これらの機能を製品として持つことが多いのが特徴です。IT部門に時系列データベースの運用経験と人手があるか、データを特定の製品の形式に閉じ込めたくないか、などで判断します。最近は、産業用ソフトウェアのベンダーが汎用の時系列データベースを裏側に使う構成も発表されています。

プロセスデータの長期保存で、圧縮やデッドバンドはどう決める？

計器の精度を基準に決めます。試験用のタグで全点のデータと間引いたデータを並べ、補間した値と元データの最大の差が計器の精度の範囲に入るか、重要な変化が落ちていないかを確かめてから展開します。製品の既定値はゼロではない場合があり、収集の手段によって設定が効かないこともあるので、既定値のまま始めないようにします。

ヒストリアンはネットワークのどこに置くべき？

本記事の設計例は、OT側に一次ヒストリアンを置き、DMZに全社向けのレプリカを置いて、企業ネットワークの利用者はレプリカにだけアクセスする構成です。これは、企業とOTの間の通信はDMZのサービスを経由するというNIST SP 800-82r3の原則から導いた考え方で、NISTがこの配置を指定しているわけではありません。また、ヒストリアンのデータを他のデータベースへ自動複製するデータベースリンクは、適切に構成されていないと脆弱性になり得る例として、NISTも挙げています。

ヒストリアンのRFPとFAT/SATでは何を確認する？

RFPでは、タグ台帳、収集の手段ごとの間引きの挙動、圧縮の方式と既定値、時刻と品質、ストア＆フォワードの容量と順序外データ、保存期間、配置、データの取り出し方、ライセンスの数え方と長期サポート、監査証跡、現地サポートを書きます。FAT/SATでは、通信断のあとの欠測の補完、圧縮の誤差、時刻の正しさ、品質フラグ、クエリの性能、レプリカの一致、バックアップからのリストア、停電後の復帰を確かめます。

ヒストリアンの費用は？

費用は、ライセンスの数え方（タグ数・接続数・サーバー数など）、保存容量とサーバーの構成、収集の対象機器の種類と数、DMZのレプリカの有無、既存システムとの連携、受入試験の範囲で大きく変わります。本記事では価格の一次情報が無いため金額の試算はしていませんが、容量は本文の仮定モデルのように、タグ数×周期×保存率から見積もれます。まずはタグ台帳を作り、試験用のタグで保存率を実測してから見積もりを比べるのが確実です。BOIの奨励措置の対象になり得るかは、BOIや専門家に個別に確認してください。

まとめ

  • 産業用ヒストリアンの価値は保存の量ではなく、「信頼でき、文脈が付き、あとから再生できる時系列データ」を残せること。
  • 最初の判断は、SCADAの履歴で足りるのか、汎用の時系列データベースで作るのか、専用のヒストリアンを入れるのか。製品の比較はその後。
  • 本当の設計書はタグ台帳。周期は使い道から、時刻はどこで付けるかを決め、品質フラグを値と一緒に残す。ストア＆フォワードで断線時の欠けを防ぐ。
  • デッドバンドと圧縮は計器の精度を基準に決め、元データとの差を試験用のタグで検証してから展開する。既定値のまま始めない。
  • 仮定モデルでは、2,000タグ・1秒周期の生データは年約1,009 GB。仮の保存率を10〜100%で置くと、容量は10倍違う。72時間の断線のバッファと、復旧後に追いつくまでの時間も見積もる。
  • 配置は、OT側の一次ヒストリアンとDMZのレプリカという設計例が考えられる。直結の自動複製は避ける。
  • 受入では、欠測の補完、圧縮の誤差、時刻、クエリの性能、リストアを、自社の条件で確かめる。

TOMAS TECHでは、タイの日系工場を対象に、ヒストリアンの用途の整理やタグ台帳の棚卸し、試験用タグでの圧縮誤差の確認や容量の見積もりといった検討の段階から、RFPの作成、ネットワーク配置の設計、FAT/SATの立会い、既存のSCADAや生産管理システムとの連携までご相談を承っています。「まだ製品を決める段階ではないが、何から整理すればよいか知りたい」という段階でも構いませんので、お問い合わせフォームからお気軽にご連絡ください。

参考情報

採用情報

「AI・DX・自動化」で、製造業の未来を
一緒に変革していく仲間を募集しています。

View More

導入事例

View More

資料請求

View More

お問い合わせ

View More