大阪大学のデータ集約基盤ONIONを研究現場で使う：研究データ管理の4つの実装事例

ONIONの位置づけと構成

甲斐氏によれば、ONIONは総合大学である大阪大学の学内で生み出される大量のデータを対象とする。将来にわたる持続可能性を保ちつつ、それらを責任を持って利用可能にすることを目的とした基盤であり、新たな社会的価値の創出を目指す産学共創や国際共同研究に向けて、学内外でのデータ活用を支援するデータ集約基盤とされている。

仕組みとしては、学内外で生成されたデータを接続先の計算基盤につなぎ、ストレージに集約する機能を持つ。スライドの大きな枠の中には3つの枠があり、性質の異なる3種類のストレージソリューションが、S3プロトコルを中核として連携している。

ONIONに関連して新たな技術も開発されている。1つは「レッドオニオン」と呼ばれる技術で、分散転送や並列送信によって大規模な研究データを高速に転送するものである。もう1つのSHPCは、ONIONに直接属する機能ではないが、HPCでの解析の履歴を管理する技術だと甲斐氏は説明した。ONIONに蓄えられたデータはそのままHPCに流れて計算される。SHPCは、その計算がどのような指示を受けて行われたのかを保証する役割を担う。これらの開発・運用はONIONを担当する伊達先生が進めているという。

研究データエコシステムのサイクルと学内体制

大阪大学は、ONIONに限らず学内独自の基盤をNII RDC（NII Research Data Cloud）に組み込み、研究データエコシステムのサイクルを実現しようとしている。発端は「RDM説明会2022 in 大阪」だった。当時附属図書館に所属していた甲斐氏、ONIONを開発・運用する伊達先生、コアファシリティ機構で測定データの活用に取り組む教員の3名が、ああでもない、こうでもないと議論しながら取り組みを進めてきた。それから約3年半が経ち、現在はこのサイクルを積極的に回していく段階に入ったと甲斐氏は述べた。

サイクルの各段階にはそれぞれ担当部署がある。研究マネジメント総合支援システムは研究推進部、ONIONはD3センター、利活用の段階はコアファシリティ機構、公開の段階は附属図書館が受け持つ。その中心にはオープンサイエンス推進室があり、各部署と調整を取りながら、サイクルをうまく回すためにどんな機能が必要で、何に留意すべきかを一緒に検討しているという。

甲斐氏は、分野やデータの特性によってはサイクル全体を単純に回せるわけではないことも強調した。スライドには、全体を一周する流れのほかに、小さく回るサイクルや、途中で曲がってONIONに戻ってくる矢印など、さまざまな経路が描かれていた。そのため、現場ごとにどのようなサイクルを設計するかを、現場と一緒に考えている段階だと説明した。

事例紹介の背景

こうした検討の中から、研究データシステム構築事業やオープンアクセス加速化事業などを活用した事例が生まれてきた。今回紹介されたのは次の4つである。

研究データマネジメントの文脈でONIONを活用する事例
質的データの共有・公開にONIONを活用する事例
測定データの集約・共有にONIONを活用する事例
センシティブデータの管理・分析にONIONを活用する事例

事例1：オープンアクセス支援システムとの連携

1つ目は、2年前に附属図書館を中心に開発された、オープンアクセス支援（字幕では「Oアシスト」）の機能を備えたシステムである。このシステムには論文だけでなく研究データなど多種類のデータが蓄積されていく。システム自体が研究プロセス全体を一元化して取りまとめる設計になっているため、データも1か所にまとまっていることが望ましい。そこでこのシステムとONIONを連携させ、運用を進めようとしているところだという。

事例2：人文社会科学のフィールドデータ管理

2つ目は人文社会科学系の事例で、フィールド調査で得られた研究データの管理にONIONを使っている。仕組みは整ったばかりで、これから実際に活用していく段階だと甲斐氏は位置づけた。

背景には分野特有の事情がある。甲斐氏によると、フィールドワークや文化人類学などでは、研究者がそれぞれ独自のやり方で研究データを管理してきた。その結果、後輩がその研究者のやり方をなぞって同じ方法を取りたいと考えたり、教員の退職後にデータがどこに行ったのか分からなくなったりといったことが実際に起きていた。そこで、可視化できるものは可視化しようという取り組みの中からこの事例が生まれた。

中心となるのは開発されたソフトウェアで、ここにさまざまなデータが蓄積され、その保存先がONIONになっている。多様なステークホルダーが関わる研究プロジェクトでは、このソフトウェア上でデータが共有される。共有の過程でステークホルダーから共有や公開についての同意を得やすくなるため、公開できるものは公開していく。こうしてプロセスの見える化を図るとともに、データを成果物として残していく。ストレージであるONIONから機関リポジトリへの公開の流れを作る取り組みだと甲斐氏は説明した。

事例3：理工系の測定データを一気通貫で集める

3つ目は理工系の事例で、測定機器から生まれる実験データをどう管理するかがテーマである。スライドでは、測定機器からのデータを中央のONIONに集める構成が示された。

課題として挙げられたのは、測定機器に付属する解析用PCである。測定機器そのものが高価で解析用PCとセットになっているため、PCだけを新しくすることが難しい。そのためWindows XPや7などが今も多く使われているという。これまではフラッシュメモリーやハードディスクでデータを移し、ONIONに上げたり共有したりしていた。今回のシステムを構築したことで、測定機器からONIONまで一気通貫でデータを集める手法ができたと甲斐氏は述べた。

ただし、考慮すべき点は多い。現場によって管理体制が異なるためである。ネットワーク管理者のような人がいない現場でも運用できる測定データ集約・配信システムを作る一方、そうした担当者がいる現場ではその人がしっかり管理するパターンもありうる。さらに、詳しい人がいる現場ではRaspberry Piを使ってデータを上げる方法もある。このように現場の事情に応じて多様なデータの集め方を実現できている点が、この事例の特徴だと甲斐氏はまとめた。

事例4：歯学の口腔データと歯科用AIサービス

最後の事例は医療データ、特に歯学の口腔データの管理である。大阪府内に限らずさまざまな歯科医院のデータをONIONに集める仕組みは、すでに作られているという。集められたデータはOCTOPUSやSQUIDといったHPCに流れ込み、そこで学習が行われて推定モデルができる。完成したモデルに対して、症例データが歯科用AIサービスに投入されると推定が行われる。

甲斐氏が挙げた用途は役割分担である。たとえば親知らずの抜歯に関する判断で、阪大病院に送るべきか、地元の病院で対応できるかを推定する。阪大の歯学部は国立大学で唯一附属病院を持つ歯学部であり、口腔がんなど希少な疾患が集まってくる。そうした症例にリソースを割けるよう、医療機関の間でうまく役割分担できる仕組みを作っているという。

甲斐氏は時間超過に触れ、これら4つの事例紹介をもって発表を締めくくった。