1.　はじめに

近年，実験データやシミュレーションによる計算値に機械学習や深層学習によるインフォマティックスの技術を用いて新規材料を開発するマテリアルズインフォマティックス（MI: Materials Informatics）の研究が進展している[1]．また，計測分野ではスパースモデリングによるスペクトル解析[2]や解析条件のベイズ最適化[3]など人為的な主観に頼らず最適解を導く計測インフォマティックスの取り組みもデータ駆動型研究分野で注目されている．実験手法では学術研究分野においてもコンビナトリアル手法によるマルチスクリーニングやハイスループット実験の評価系が取り入れられつつある[4]．これにより，研究開発ではこれまで以上に扱うデータ量は肥大化・多様化し，データの探索空間は大きく広がっている．このような背景から，エキスパートの高度な判断や経験に基づく識別・分類といった作業をAIやIoT，ロボット技術等に任せ，研究者がより付加価値の高い仕事に注力することで研究開発の高度化・効率化・高速化を実現するデジタルトランスフォーメーション（DX: Digital Transformation）が期待されている．

この次世代の研究環境の実現，すなわちDXによるデータ駆動型研究の推進を実現するためには，データのライフサイクルで初端となる計測装置等からのデータをできるだけ人手を介さず，自動的に取得および集積される仕組みが必要である．しかし，現状は依然としてデータの収集段階が最も障壁となっている．その理由の多くは，以下の事由の組み合わせによっている．

• ①データそのものが測定装置本体や個人のローカルPCに保管されており，データの所在が分散している．そのため，データの所在を人に聞いて回らないと集められないこと．
• ②測定装置の多くはウイルスによる誤動作やOSのアップデートによる測定の中断などのトラブルを回避するため，ネットワーク環境から切り離したスタンドアロンで運用されている．そのため，データの取り出しや受け渡しはUSBメモリなどの外部記録媒体で人手が介在していること．
• ③測定データの素性が不明であること．たとえば，新規材料の開発においては試料情報が略語表記やコードネーム化されている．また，計測や分析における前提条件に関する付帯情報がないために，測定当事者以外の第三者による再利用・再解析が難しいこと．
• ④計測データが出力状態のまま（rawデータ）となっていること．特に出力がメーカ固有のバイナリー形式の場合には可読化のためのデータ変換に難航することのほか，記載内容もメーカ固有の計測パラメータの語彙の意味が解読できず，データ駆動にかけるためのデータ構造化が難しいこと．

物質・材料研究機構（NIMS）では上記のようなデータ収集の課題に対応するため，IoT技術を活用したデータ収集基盤のデータ設計（データアーキテクチャ）を行い，実践的な運用を行っている．第2章では①および②の課題に対して，IoT技術を導入したシステム（IoTシステム）を構築しており，その設計要件ならびに技術について述べる．また，③の課題に対しては，ローカル環境にあるPCで動作するHTMLファイルによる実験記録簿（ここではLocal HTMLと呼ぶ）を開発し，IoTシステムと一体となった運用を進めている．第3章ではこのLocal HTMLで記録された実験記録をデータファイルと一緒にデータサーバへアップロードすることによりデータサーバ側でHTMLパーサーによる読み取りが行われ，データベース（DB）にメタデータとして管理する事例について述べる．既報の④の変換ツール・可読化方法[5]をあわせることで，計測条件のメタデータも一体となってデータと紐づけられ，DBへは特定の開発テーマや意味付けをもたせた「データセット」としてデータの収集が行える．

第4章は総括であり，このようなハードウェア面およびソフトウェア面の両面における整備を進めるうえでのデータアーキテクチャの課題と今後の展望について述べる．

2.　IoTシステム設計

2.1　IoT技術を用いる背景

ビッグデータ解析などを活用した材料研究開発のためには，各種実験装置から効率的に計測データを収集して大量に蓄積するシステムを構築することが求められる．しかし科学技術分野では，装置に接続されてその制御やデータ記録を行うPCは，セキュリティや稼働安定性の観点から，ネットワークには接続されずにスタンドアロンで運用される場合が多い．そのためデータの取り出しはUSBメモリなどを用いて人の手で行われていることが一般的であり，データの大量収集と系統的な蓄積には適さない（図1(a)）．

一方，本IoTシステムの特徴は，計測装置やプロセス装置のパソコン（制御PC）に，通信セキュリティを施したデバイス（以後，セキュリティデバイス）を装着することでネットワーク接続していないPCをIoT化させ，rawデータを安全にデータサーバへ転送させることができ，計測装置やプロセス整備から送られてくる大量のデータを効率よく集積することを可能にする点にある．セキュリティデバイスとしてはデータ容量や装置の利用形態を勘案し，Wi-Fiによる無線方式とEthernetに直結する有線方式の二つの方式を併用する．図1(b)は無線方式によるデータ転送の例を示している[6]．USBメモリの代わりにセキュリティデバイス（ここではWi-Fi機能をもつSDカード）にデータをコピーすると，認証サーバを経てデータ蓄積サーバにアップロードされ，続くデータ収集サーバではrawデータが構造化されてDBへ蓄積される．データはNIMSのネットワークにつながる環境にあれば，ウェブブラウザを通じてどの端末からでもダウンロードできる．現行，NIMSでは約70台の計測装置についてセキュリティデバイスが導入済であり，月単位で約10 GBのデータが流通している．なお，本システムは組織内運用における観点からオンプレミス開発を進めているが，システム構成はクラウドでの運用も可能である．

2.2　IoTシステムの設計指針

IoTを利用したデータ収集の導入事例では，インターネット化する“モノ”の対象としてエネルギーハーベスティング等の自立電源で駆動するセンサーを対象とすることが多い．この場合は限られた自立電源の出力でセンサー信号を送信するLPWA（Low Power Wide Area）の無線方式を前提とした設計となっており，消費電力の兼ね合いから扱うデータ容量は比較的に小さい観測データである．

対して本IoTシステムで対象とするネットワークへ接続する“モノ”は，科学技術分野における計測装置や先端プロセス装置，より正確には装置を制御し，装置からの信号をデータとして取り込む制御PCである．ネットワークにつながらない制御PCは“モノ”化してしまっているが，セキュリティデバイスを装着させることでIoT化され，ネットワークを通じて外部のサーバと連携ができるようになる．セキュリティデバイス自体もIoTと見なすことができるが，本稿ではこのセキュリティデバイスを介してIoT化された制御PCを「IoT化PC」と呼び，このようなIoT化PCからデータを収集するシステム全体を「IoTシステム」と称して述べる．

データの形態は，一回の測定で一つのスペクトルデータを取得するといった一般的な計測のデータ様式のみならず，近年の先端計測分野においてはハイパースペクトルに代表される多次元の面データや三次元X線CTのような三次元データの普及も目覚ましい．そのため，データ容量もMB（メガバイト）からGB（ギガバイト）を扱うケースが増え，データ形式も画像形式，動画形式などバラエティに富んできている．加えて，“モノ”が多人数の利用環境にある共用設備や共有装置である場合には，“モノ”からのデータ転送に対しては人と結びついた識別とデータ格納においては適切な分類や秘匿性が求められる．そのうえで，情報セキュリティの三大要素である機密性（Confidentiality），完全性（Integrity），可用性（Availability）を担保する必要があり，運用においては環境における様々な制約をクリアしながらセキュリティ機能を保持させる必要がある．このように，IoT化PCが接続されても，システムとして高度なセキュリティを保持しつつ，かつ研究開発用途に特化できるように様々な工夫を織り込ませることが，研究開発分野におけるIoTシステムのデータアーキテクチャの要諦である．

2.3　セキュリティデバイス

研究開発分野における多様なデータ形式に対応するため，セキュリティデバイスとしては無線LAN接続機能を備えるSDカード（キオクシア製FlashAir^TM W-04）と有線方式では暗号・認証技術を基盤としたセキュリティプロキシデバイス（東芝インフラシステムズ製CYTHEMIS^TM）とを併用して運用している．双方の通信にかかる仕様と運用におけるスループットならびにNIMSで取り決めた一回あたりのアップロード許容量を表1に示す．

FlashAirは市販のSDカードであるが，そのカードには無線機器が内蔵されていることに特徴がある．無線通信にかかる周波数帯は2.4 MHzでIEEE 802.11b/g/nの三つの通信規格を有する．組織内ではWi-Fiのアクセスポイント（AP）側の接続条件や通信安定性の観点からIEEE 802.11gにて運用している．制御PCと接続させるインタフェースはUSB 2.0のSDカードリーダー経由でつなげる．ユーザはその制御PCのファイルシステムを通じてFlashAirにアクセスできる．なお，SDカードリーダーのインタフェースがUSB 3.0の場合には，USB 3.0の端子から発生するノイズが2.4 GHz帯と干渉し，通信の不安定化や高い割合で送信エラーが生じる現象が確認された[7]．また，高圧電源などを使用する特殊装置では，それから発生する干渉ノイズで送信エラーが生じるケースもみられた．このように無線方式においては設置環境や対象機器も十分に考慮してセットアップすることに留意を必要とする実践上の重要な指針を獲得した．スループットはAPの設置位置や設置数，もしくは時間帯にも依存するが，平均して5 Mbpsの伝送速度である．一回あたりのアップロードできる許容量はこの伝送速度も考慮して100 MBとしている．小規模・軽量のデータを主体とする計測装置はこのFlashAirで対応するようにしている．実際，セキュリティデバイスを装着した測定機器のうち八割がFlashAirでまかなえている状況にある．

一方，二割の測定装置については，一回あたりの測定で100 MB以上のデータが出力される機器，もしくはFlashAirの設置が困難であった環境にある測定機器である．これらは産業向けのセキュリティデバイスとして開発された有線方式のCYTHEMISで対応している．CYTHEMISは装置の通信を暗号・認証処理でセキュアにする外付けのデバイス群と，それらのデバイスを管理するPCと一体となって運用する．インタフェースは一般的なRJ-45であるため，古い型でサポート切れのOSの制御PCであっても“モノ”側に特別の設定や改変を施すことなく接続させることができる特徴をもつ．スループットは平均して70 Mbpsの伝送速度であり，構内におけるネットワークの生活線での影響を見定めたうえで一回あたりのアップロードできる許容量は10 GBと定めて運用している．

2.4　セキュリティ

セキュリティデバイスの選定とそれを用いたシステム開発は，以下の三点を特に重要な要件とした．

• ①アップロードの送信のみに特化させて，ダウンロードは許可しない制限をもうけること．
• ②外部からのマルウェアやウイルスの侵入を防ぐのみならず，Windows Updateなど外部トリガーとなるタスクスケジューラの実行を遮断すること．
• ③セキュリティデバイスのためのドライバなどを制御PCにインストールしないこと，もしくは環境設定などの設定変更を行わないこと．

この三要件は，長時間計測では失敗の許されない計測装置やOSの更新によっては動作保証の確約のない特殊な制御プログラムで動かしている先端計測や精密加工プロセスならではの事項である．FlashAirおよびCYTHEMISともにこの要件を満たし，非ネットワーク環境にある制御PCであったとしても，効率的かつセキュアにデータ転送ができている．

なお，無線方式による高速な伝送速度を有するデバイスとしてはRaspberry Pi等のシングルボードPCも検討の俎上に載せていた．シングルボードPCは廉価でありながら，高いパフォーマンスと開発の自由度がある利点は魅力であったが，組織におけるセキュリティポリシーをクリアするには至らず採用を見合わせた．

(1)　無線方式のセキュリティ

FlashAirは一眼レフカメラなどデジタル撮像機器に装着し，その撮像をSDカード内に記録するとともに，FlashAir自身がもつWi-Fi経由で画像や動画をクラウドに自動的にアップロードする用途で用いられている．我々は，そのシンプルな一方通行性の送信方式に着目した．装着対象をPCとした場合，FlashAirのストレージはカード内のマイコンからのアクセスおよびPCへのマウントが可能である一方で，カードからはPCのストレージへのアクセスはできない．これにより，データは構造上一方向にしか流れず，PC自体をネットワークに接続することなくデータのみのアップロードによる収集が可能となる．

また，FlashAirはSDカード内で動作する軽量言語のLuaスクリプトを実行できる機能を有している．本IoTシステムでは，FlashAirにファイルが追加されるとそれを検出し，指定したサーバへ送信するLuaスクリプトをもたせている．FlashAirは実験室内のWi-Fiに接続し，計測日時や実験者を示すメタデータとともにデータ蓄積サーバへ送信される．データ受信認証はFlashAirからアップロードされたデータ蓄積サーバ側で認証され，サーバに登録されたFlashAir以外からのアップロードが行えないようにしている（詳細は3.3節で述べる）．

(2)　有線方式のセキュリティ

有線方式のCYTHEMISは，そのデバイス本体に高い耐タンパー性を備えたICチップをもち，認証方式によるセキュリティ機能を有する[8]．さらには管理システムと一体となって，アクセス制限やフィルタリング機能，不正侵入防止機能を持ち，許可されていない通信や接続（双方向の送受信）は遮断する．本システムにおいてはIoT化PCがデータ蓄積サーバへファイル送信するとき，SMB/FTP/SCP等のプロトコル・通信方向だけを許容し，それ以外の通信を遮断する設定としている．加えて管理システムは，接続されている当該デバイスとその情報がホワイトリスト等で管理されており，条件が満たされたCYTHEMISからの指定のプロトコルの通信のみを許可する．これにより，IoT化PCとデータ蓄積サーバ間のみの通信とし，CYTHEMISが装着されていないPCからの通信は制限をかけている．

ホワイトリストの情報設定やアクセス制限の運用は，ネットワーク上の管理システムを通じて一元的に管理できるようにし，増設対応においても柔軟性をもたせている．CYTHEMISはIoT化PCのOSの種類やバージョン等に依存しないため，ほぼ機器を選ぶことはない．また汎用的な通信プロトコルによる方法で接続を可能にしていることや有線LAN（RJ45 Cat6準拠）に接続できるため，組織内ネットワークに仮想専用線（VPN: Virtual Private Network）で通せる環境にあれば，遠隔の計測機器に対してもCYTHEMISを装着させることで当該装置のデータをデータ蓄積サーバにセキュアに集積することもできる．たとえば，NIMSは茨城県のつくば地区（千現地区，並木地区，桜地区）のほかに兵庫県の大型放射光施設（SPring-8）に分室をもつ（西播磨地区）．西播磨地区との接続は機構専用のVPNでつくば地区と結んでいるが，CYTHEMISではVPNに対してもセキュリティを確保して西播磨地区からつくば地区へのデータのアップロードを可能としている（図2）．

3.　IoTシステムによるデータ集積化

3.1　データ集積にかかる先行技術

IoT化PCから取り出されたデータを有効に活用させるためには，データ収集，蓄積，そしてサービスまでにまたがるインフラストラクチャの構築が不可欠である．科学データの集積にかかるシステムやDBについては数多くの取り組みがなされてきた．先行技術としては，1990年代後半から化学分析分野で普及がはじまった研究ラボのデータを一元的に管理運用するラボ情報管理システム（LIMS: Laboratory Information Management System）の取り組みが挙げられる．主には低分子創薬系の分析データの収集で導入が図られ，サンプル管理から各種の化学分析のトラッキングを含め，測定データを同一DBに一元的に集積するシステムが開発された．異種メーカの機器であっても同一のシステム内で接続ができ，かつデータ流通が図れるように，データフォーマットも互換性をもつAnDI [9]，JCAMP-DX [10]といった標準フォーマットも整備された．とはいえ，イントラネット内での計測機器のつなぎこみはドライバが必要となるケースやデータフォーマットもDB側であらかじめ受け入れる様式を厳密に定めておかなければならない．すなわちデータ収集の考え方は中央制御方式であり，規格に対応しない計測機器や各種センサー，データロガーの接続への拡張性には制限があった．

米国の国立再生可能エネルギー研究所（NREL）では太陽電池分野で得られるデータ収集および管理についてLIMSの概念導入の試みを行っている[11]．市販のLIMSアプリケーションについて上述と同様の拡張性の不備を認識しており，時間や費用の観点から市販品をカスタマイズよりも自製によるLIMS構築の判断をとっている．データ登録ではメタデータの記述方法についてXMLスキーマを定義し，計測器からの自動的に収集されたデータは，そのメタデータとともにデータウェアハウス（DWH）に蓄積するシステムを構築している．旧来型のLIMSとは大きく異なる点は，NRELでは「データ利活用」として公開基盤を意識した設計をとっていることにある．各研究分野に特化したデータセットについてはextract-transform-load（ETL）のプロセスで構築できるようにしており，実際，薄膜半導体材料についてはNRELのウェブサイトを通じてデータ公開を行っている[12]．米国の国立標準技術研究所（NIST）では2011年に始動したMaterials Genome Initiative（MGI）の取り組みの中でデータ集積にかかるインフラストラクチャの整備を担当し，計測機器データや外部からのデータ受け入れも想定した「Material Data Curation System（MDCS）」を開発した．ここでも特徴とするのは計測データについては装置ごとにXMLスキーマを定義し，データの互換性を持たせる設計思想をとっていることにある[13]．

このようにNREL，NISTのデータ収集方式は中央制御方式ではなく，計測機器ごとにXMLスキーマを定義したエッジ制御方式を念頭に置き，多様な計測データを受け入れることを可能にしている．NIMSにおけるデータ収集においても，数多くの計測機器・プロセス機器からのデータ種を受け入れるために，エッジ制御方式がとれるXMLスキーマ方式を採用し，システム設計およびDB設計を行っている．

3.2　ファイル蓄積の概要

NIMSのシステムでは，制御PCから無線方式もしくは有線方式のセキュリティデバイスを経てアップロードされたデータは，一旦，受け口なる「データ蓄積サーバ」に記録される（図3）．ただし，そのファイル転送と受け入れ方法は両者のセキュリティデバイスの仕様の違いにより次のような相違がある．無線方式のFlashAirでは，セキュリティデバイスはIoT化PCからは外付けドライブとして認識される．ユーザがIoT化PCからFlashAirへファイルを配置するとFlashAirのLuaスクリプトが動作し，ファイルはデータ蓄積サーバへ転送される．一方，有線方式のCYTHEMISは，そのデバイスの中にはストレージやファイル送信機能を有してはいない．ここではデータ蓄積サーバに共有フォルダ領域を設け，IoT化PCからはその共有フォルダを介しファイルの転送を行う形態としている．具体的にはデータ蓄積サーバ（Cent OS）にWindowsネットワークを実装しファイルサーバ化ができるsambaを導入した．IoT化PCの共有フォルダにファイルが配置されると同時にデータ蓄積サーバに共有がかかり，それをトリガーとしてDB（PostgreSQL）へファイルが取り込まれる．

DBへの書き込みは，次節で述べる送信時で使うファイルシステムの階層構造情報を利用し，計測機器やデータ送信者を識別し蓄積される．また，データ蓄積サーバへはLDAP方式による機構内認証サーバによりアクセスが認められたユーザについてはウェブブラウザからのアクセスを可能としている．データ蓄積サーバの段階ではメタデータは付与されておらずrawデータのみが取得できるが，ネットワークに接続できる環境にあれば機構内外からもrawデータをダウンロードから入手ができ，実験の速報を知りたい場合などに活用されている．

IoT化PCからのデータは，データ蓄積サーバに蓄積されるものの，データ蓄積サーバの着信がトリガーとなり，「データ収集サーバ」へコピーされる．データ収集サーバは広義にとらえればDWHの役割を担うが，本システムではDB兼バックアップサーバとして機能する．ここでXMLスキーマが定義できている計測機器については，データ収集サーバでrawデータの内部に記載されている計測パラメータの抽出が行われメタデータを生成する．rawデータがメーカ固有のバイナリー形式であるような場合，メーカからの協力の元，テキスト形式への変換を行っている．また，第三者による再利用性を高められるようにするために計測パラメータ部と数値行列部とを分け，後者についてはcsvファイルとして出力する．これらの構造化されたデータは抽出された計測パラメータのメタデータとともにデータ収集サーバで一体化されてDBに書き込まれる．このようにして，IoT化PCより送信されたファイルデータは，できる限り人の手を介さずにコンテンツに富んだメタ情報を付与させてDBへ蓄積し，かつ再利用ができるようにしている．

3.3　データの識別・分類と秘匿性

ここではIoT化PCからのアップロードされるデータの識別・分類とその秘匿性の制御について述べる．装置識別は，セキュリティデバイスを設置の段階に運用側で装置IDを付番する．汎用性の高い機器である場合には，組織をまたいで同一メーカで同一機種のモデルを購入しているケースも想定されるため，異なる装置IDを付番することで区分できるようにしている．またFlashAirとCYTHEMISはいずれもMACアドレスを持つ．このMACアドレスを利用し，一台の装置（制御PC）につき一つのセキュリティデバイスを装着することで，セキュリティデバイスと装置IDとを1:1で紐付けするようにしている．仮にユーザが意図せずセキュリティデバイスを取り外し，別の装置の制御PCに装着した場合には，そのセキュリティデバイスはIoTシステムの中では認識されない．別の装置からのデータ転送ができないようにするため，FlashAirにおいては，クレデンシャルファイルによる制御，CYTHEMISにおいてはホワイトリストの情報における管理システムの設定で行っている．

無線方式および有線方式ともにIoT化PCではファイルシステムに基づくフォルダ階層で表示させている（図4）．第一階層は装置ID名のフォルダ，第二階層はユーザの職員番号にも紐付いているLDAP ID名のフォルダとして定め，セキュリティデバイスの設置時に運用管理者側でセットアップを行う．この両階層のファイル名はユーザには改変をしないようにルール化している．第三階層はユーザが実験テーマなどで自由に設定できるフォルダである．

ユーザは自分の職員IDの配下の第三階層にデータファイルをドラッグ＆ドロップすると，それがトリガーとなってデータ蓄積サーバへアップロードされる．上記で述べたようにファイル転送方法はFlashAirとCYTHEMISとでは原理的に異なるが，ユーザはファイルシステム上ではセキュリティデバイスの違いによる操作を変える必要はない．ここは無線方式と有線方式の併用において最もこだわった点である．

データ蓄積サーバ内では送られてくるファイルのほか，ファイルシステムの第一階層/第二階層/第三階層の各階層情報から「装置」と「人」，そして「テーマ」が識別されてDBに分類される．また，データ送信側の情報としてデータが生成または更新された日時も記録されることから，「人‐装置‐データ‐時刻」の識別ができるようになっている．複数名の利用による共用装置や共有設備であったとしても，第二階層にユーザのIDフォルダを設けるだけでよい．各ユーザは，自分のフォルダにデータを移すだけの操作でアップロードは完了となる．

データのダウンロードは，ユーザが自分のLDAP IDでデータ蓄積サーバへログインすると，図5に示される画面に遷移する．この画面で，ダウンロードのファイルを選択することで取得することができる．この画面にはユーザが登録したデータのみが表示され，別ユーザのデータは表示されない．これは，郵便における私書箱のようなイメージであり，我々はこれをIoTシステムにおける「私書箱機能」と呼んでいる．

なお，第三階層目のフォルダは各ユーザが任意に作成できるフォルダと上述したが，フォルダ名の最初の一文字がアンダーバーから始まる「_フォルダ名」の場合にはあらかじめ申請のあったグループメンバーでデータ共有をすることができる予約メソッドを設けている．これにより，「個人」もしくは「グループ」のどちらかでの秘匿範囲の選択をもたせ，限られた範囲内でデータ共有を行うことができるようにしている．この方法の場合，図5の画面においては，グループやチームのメンバーから予約メソッドでアップロードされた共有データも表示される．測定のオペレーターとデータ解析を担う研究者との役割分担が明確なる研究テーマでは，この予約メソッド形態が多用されている．

ファイルの共有方法の観点でみると，フォルダ名の先頭文字の命名規則による予約メソッドの方法は決して最善な方法ではないことに留意は必要である．システムの設計段階ではデータは測定した個人のみに属する秘匿性と要件定義して開発を行っていた．ところが，実際にサービスを組織で供用したところ，ユーザからはチーム単位や特定のテーマにかかわるグループでのデータ共有の要望が多くあげられた．予約メソッドはその要望を受けて，システム改修上の工夫によるアジリティ的な施策である．

3.4　計測メタデータ

メタデータのXMLスキーマが定義できている計測機器については，計測ファイルに記載されている計測パラメータからメタデータを抽出し，機械可読性の高いXMLファイルへと変換する（図6）．このようにして抽出された「計測メタデータ」はXML形式でデータ収集サーバのDBに書き込まれるようにしている．メタデータによって，DB内での高速検索を可能にするとともに，異なる形式とデータを比較する際においても，メタ情報の語彙を統制することで膨大な数の計測データ群からの特定データファイルの検索を容易にすることに利用している．

また，機械学習やデータ駆動型解析で利用しやすいデータの創出・蓄積を効率的に行えるようにするために，バイナリデータである場合にはテキスト変換を通じてcsvの数値データ行列化を行うとともに，データセットの内容の判別を容易にするためにスペクトル等へのグラフ化（視覚化）変換を同時に行ってDBのサムネイルに供している（図7）．なお，X線回折（XRD: X-ray diffraction），X線光電子分光（XPS: X-ray Photoelectron Spectroscopy），およびオージェ電子分光（AES: Auger electron spectroscopy）については，装置メーカの協力のもと，バイナリデータの変換プログラムの提供や，データファイルに記述された測定にかかるパラメータの語彙の意味について定めている．これらはMaterials Data Conversion Tools（M-DaC）と命名したツール群としてGitHubで公開し，第三者利用を可能にしている[14]．

3.5　Local HTMLによるメタデータ記録

メタデータの中には計測ファイルからは取得できない，または記述できない計測や実験の付帯情報がある．たとえば，自作で組み上げた計測系では，制御信号や調整条件が計測ファイルには記録されないことは往々にして起こる．また，真空装置であればその到達真空度といった日々変動する測定環境の情報も，第三者がデータを利用するうえでは重要な情報になる．それらの付帯情報は主には測定担当者の記録メモや実験ノートに記載される事項であるが，それをデジタル化し，測定ファイルに紐づきデータが管理されることは稀である．

検討初期には，手書きに代わる電子記録の手段として市販の電子ラボノートの導入調査を行ったが，対象は化学向け・バイオ向けの研究が主たるもので，このような簡便な計測記録や機器管理向けに合致するアプリケーションは見いだすことができなかった．また医療向けの電子カルテのようなタブレットを利用するシステムも調査検討を行った．しかし，所内のヒアリングでは数行の計測記録のために，機器利用者全員にタブレットを購入することには，各部署の予算上では捻出が厳しいとの声がよせられた．また，共用設備のような不特定多数の利用者が扱う装置ではタブレットの紛失なども想定した管理は負荷が高いとされた．

導入コストを抑え，かつ現場の作業者が日々，確実に記録を続けることができる検討の中で見いだされたのは，計測の制御PCを入力端末として利用することであった．ただし，2.4節でも述べたように，一般に先端計測や精密加工プロセスは，ウイルスによる制御の誤動作や制御遅延を招く恐れがあるため，プレインストールされているソフトウェア以外のインストールを禁止して運用していることが一般的である．

この制約をクリアする方法として，Windowsであればプレインストールされている「メモ帳」のような軽量エディタで記録し，そのテキストファイルをデータとともに紐付けて送信するアイディアに至った．しかしながら，ガイド機能がない軽量エディタでは作業者にミスのない記録を促すことができない．標準作業化するためには，計測機器の利用形態に応じた記入すべき項目がまとめられたテンプレートが必要である．Microsoft WordやExcelのような高機能アプリケーションであえばテンプレートの作成は容易であるが，プレインストールされている軽量エディタではそのような要求を満たすことは難しい．

我々は，このようなローカル環境の制御PCでも高機能エディタ並の要求に応えられる仕組み作りのツールとしてHyperText Markup Language（HTML）に着目した．一つにはテンプレートで必要となる記入項目のガイドやデザインはカスケーディング・スタイルシート（CSS）機能を使うことで解消できる．また，JavaScript（js）をHTML内のコードに埋め込めば，たとえば，入力内容が要件を満たしているかを判定するバリデーションも可能である．このHTML，js，CSSの構成であれば，制約となっているインストーラーの形を取らずに動かすことができる．もしくは，外部のウェブサーバに接続をさせてCGI（Common Gateway Interface）のような処理プログラムを呼び出すことをせずとも，ネットワークにつながっていないローカル環境において，高機能エディタで作成されたフォーム並の高度な処理を成し得る．このデータの付帯情報をHTML形式のファイルとして作成し，実験・計測情報の入力を支援する方法は，試行段階で協力を得た利用者からも支持が認められ，手書きに代わる計測条件の記録方法として，またデータの再利用にかかる手法としては有効な方法であると考えている．（このようなローカル環境にあるPCでのHTMLファイルによる実験記録簿を，次節以後は「Local HTML」として表記する．）

3.6　Local HTMLの様式

Local HTMLによる入力フォームの書式の事例を図8に示す．記入する項目は，大別すると「基本情報」，「サンプル情報」，そして実験由来の「固有情報」の三つの象限を設け，A4版で1枚程度に収まる内容としている．上記のような計測ファイルに書かれない項目は「固有情報」に欄を設けHTMLエディタで書き換えるだけで簡単に編集できることに特徴があり，主要な装置についてのテンプレートは運用側で作成している．HTML構造も各計測装置でのカスタマイズや拡張性をもたせ，細かい修正はユーザでも対応できるようにしている．

「データ投入者」といった装置利用でほぼメンバーが固定化している記入項目の場合には，プルダウンで選択させることができる．作業項目が「有/無」のような選択性の場合にはラジオボタンを設けることで記録情報をとることもできる．また，測定ファイルとLocal HTMLとの紐づけは，「ファイル選択ボックス」を設けて，対象となるファイルを選択できるようにしている．

入力内容は「submitボタン」を押すと，Local HTMLの内部に埋め込まれたjsファイルが呼び出され，メタデータのkey-value構造がとられるほか，測定データ（ファイル）との紐づけはハッシュ値を取得し，入力フォームとは別のHTMLファイルがデスクトップ上に出力される．

ユーザは測定ファイルと一緒にこの出力されたHTMLファイルをIoT化PCからアップロードすれば，データ収集サーバ側では受け取ったHTMLファイルをパーサーで読み取り，key-valueに基づいて自動的にデータ収集サーバのDBに書き込みが行われる．またファイルについてはハッシュ値を頼りにデータファイルを認識し，そのファイルからデータ変換やパラメータ抽出をかけ，描画に必要な数値データなどを読み出す．これら一連の処理はその装置に特化させたコードをpythonで作成している．そのような一連の処理を終えて，上記の計測メタデータとともに書き込まれて図7の画面に反映される．なお，本稿では詳細は示さないが，Local HTMLでは事前にデータ登録者が特定のテーマのデータ群として分類・収集をする「データセット」単位での仕分けを可能にしている．この「データセット」はデータカタログが付与され，将来，REST APIを通じてこのデータセットの単位でデータを一括してダウンロードを可能とする予定である．

4.　今後の展望

2020年1月のWindows 7のサポート終了により，古いOSであってもセキュリティを保証してネットワーク接続にも対応できる「レトロフィット」の利点も見いだされ，IoTの利用が増えてきている状況にある．また，既存設備で高速通信が可能となるWi-Fi 6や5G（第5世代移動通信システム）の組織内運用が可能な「ローカル5G」の次世代通信技術への適用も見込み，大容量・低遅延化検討も着手し始めているところである．

このようにデータ収集基盤のデータ設計の指針（データアーキテクチャ）や安定運用のためのノウハウは整ってきたところであるが，利活用をより高めてゆくためには，まだ依然として改善項目は多い．インフォマティクスの本丸である機械学習や深層学習などにかけるまでにデータの前処理や定形処理に膨大な作業工数がかかっている実情もある．そのため，rawデータを再利用のしやすいデータ構造へといかに整えるかがポイントにもなる．そのような観点から，データ解析ツールや前処理スクリプトなどによる自動処理化の付加価値を備えることを進めている．図9に示されるようなデータ収集サーバと解析サーバと連携・同期させる試みである．この取組は計測装置や学術分野によって個別最適化する要素もあるが，繰り返しの単調なる人手による作業を緩和させることで利便性を訴求することが期待できる．

一方で，運用側において過度の負荷とならないようにするために，ルーチン化できるデータ構造化などはできるだけメニュー化する必要もある．また，データ構造化したデータを自動的に「データセット化」するだけではなく，二次利用性を高めるためのユースケースやショーケースも整備してゆかなければならない．

今後，IoTシステムのスケーラビリティにおける課題として，数百人または数百台規模でGB単位のデータがローカル5GやWi-Fi 6に大量に流通した場合における分割処理技術や分散システムなどの導入が不可欠となることが予想される．また，最新のデータ技術にも長けたデータ設計家（データアーキテクト）の養成も急務である．そのようなシステムの拡張性におけるIoTシステムの運用や人材育成のあり方については今後検討を進めてゆくものである．

謝辞　Local HTMLのアイディアと助言をいただいた柳生進二郎博士（物質・材料研究機構）およびCYTHEMISのセキュリティデバイスに関する技術的な助言をいただいた友枝裕樹氏（東芝インフラシステムズ株式会社）に感謝を申し上げます．また，本システムの開発に携わったNIMSの諸氏に深い感謝の念を表します．