DXの情報基盤となる“構造化データ”がなぜ必須なのか？【日本列島BIM改革論：第4回】：日本列島BIM改革論〜建設業界の「危機構造」脱却へのシナリオ〜（4）（1/3 ページ）

これまで「日本列島BIM改革論」の連載では、日本のBIMの危機構造とは何かについて述べてきた。危機構造から脱却し、建設DXへ向かうには、情報基盤としてのBIMが必要となる。しかし、日本で作られるBIMモデルは、情報基盤としての構造化データとはいえないばかりか、竣工後には使い捨てられ、再利用されることは少ない。そこで、BIMモデルを構造化データとするためには、何をすべきかを考えてみよう。

[伊藤久晴（BIMプロセスイノベーション），BUILT]

構造化データと非構造化データ

　連載第2回で、「構造化データ」と「非構造化データ」について解説した。そのなかで、建物の設計・施工の情報は、BIMモデルなどの構造化データと、図面・書類・写真・パース・ビデオなどの非構造化データの2つに分類され、両方を合わせると設計・施工に必要な全情報が網羅されるとした。

　これまで述べてきたように、「BIMとは情報を作成・管理する“プロセス”」である。そのため、設計・施工に必要となる非構造化データを作成することも、BIMというプロセスの範囲に含まれる。下図でいえば、2のように、BIMソフトを利用して作ったかどうかに関係なく、情報（構造化データと非構造化データ）の全てを対象に、プロセスを考える必要がある。

設計・施工でのBIMの範囲についての2つの考え方

　日本では、意匠・構造などはBIMソフトウェアを使った設計が進みつつあるが、設備や見積については遅れている。だが、設備や見積がBIMソフトを使ったり、連携したりしていなくても、共通データ環境を使った情報の受け渡しやレビュー・承認といった情報デリバリーのサイクルを組むことは可能である。そのため、BIMソフトを直接使用しない業務でも、情報デリバリーのサイクルに組み込むことで、BIMというプロセスに対応することは可能であると考えてよい。

　しかし、連載第3回で触れたように、BIMがDXの情報基盤に成り得るとするならば、設備が2次元CADで設計し、非構造化データを作っていることは好ましくない。なぜなら、DXの情報基盤は、“データベース”に連携することのできる構造化データでなければならないからだ。

　では、現在、日本の設計・施工で作られているBIMモデルは、DXの情報基盤となる構造化データといえるだろうか？RevitなどのBIMソフトは、構造化データを作れる機能を持ってはいるが、情報基盤としては十分とはいえない。

　そこで今回は、DXの情報基盤となるBIMによる構造化データについて考えてみたい。

★連載バックナンバー：

『日本列島BIM改革論〜建設業界の「危機構造」脱却へのシナリオ〜』

日本の建設業界が、現状の「危機構造」を認識し、そこをどう乗り越えるのかという議論を始めなければならない。本連載では、伊藤久晴氏がその建設業界の「危機構造」脱却へのシナリオを描いてゆく。

構造化データとしてのBIMモデル

　ISO 19650-1では、「4　資産及びプロジェクトの情報、展望及び協働作業」の原則説明のなかで、「AIM（資産情報モデル）及びPIM（プロジェクト情報モデル）には、構造化された及び構造化されてない情報を含めることができる」と規定している。さらに、「構造化された情報」としては、BIMモデルや工程・データベースを挙げている（本稿では「構造化された情報」を「構造化データ」と呼称）。

　一般的に構造化データとは、ExcelやCSVファイルに代表される「列」と「行」の概念を持つデータのことを指す。「構造化」されているので、検索、集計、比較などが容易（たやす）く、データの解析や分析に適したデータ構造のため、データベースと連携できる。例えば、RevitなどのBIMソフトであれば、BIMモデルに入れた情報を、構造化データとして、Excelやデータベースなどに出力できる。ある意味でRevitなどのBIMソフトは、情報を管理する機能でデータベースと同様の構造を有しているので、そのまま構造化データとして、他のデータベースなどへの連携が容易である。

　一方で、ISO 196560-1では「構造化されてない情報」については、文書・ビデオ・録音・サンプルなどに加えて、2次元CADデータも非構造化データとしている（本稿では「構造化されていない情報」を「非構造化データ」と呼称）。

　非構造化データは、そのままではデータベースとの連携ができないため、検索や集計・解析には向かない。現状では、建物の情報は、まだまだ非構造化データの方が大部分を占める。こうした非構造化データも、BIMプロセスのなかでは、共通データ環境で情報の受け渡しやレビュー／承認保管（情報デリバリーのサイクル）をしなければならない。

　また、ISOで工程（スケジュール）が、構造化データと見なされているのは興味深い。おそらく海外では、工程情報を構造化データとして連携できる工程管理ソフトを使っているためであろう。日本でも、同様のことができる工程管理ソフトが主流となり、BIMの4D（時間軸）の対応が進むことを期待したい。

　構造化データ活用の取り組みでは、「COBie（Construction Operations Building information exchange）」というデータフォーマットがある。COBieは、BIMモデルをもとに、竣工後の維持管理運用でもデータを活用するため、引き渡す際に用いられる。既に英国ではかなり普及しており、実際に維持管理運用のために発注者が提供を要求している。

　Revitであれば、Autodeskから提供されているアドイン「Autodesk BIM Interoperability Tools」の「COBie Extension」により、Excel形式でCOBieデータを直接書き出せる。Excel形式なので、内容を確認するのも難しくはなく、後で書き足すこともできる。出力したCOBieデータは、維持管理運用ソフトで読み込むことで、BIMモデルと情報連携する仕組みだ。

COBieを使った維持管理運用へのデータ連携のイメージ

　上図の設計の中にあるコンポーネントがBIMモデルのオブジェクト（部材）にあたり、タイプがその仕様を示している。Uniclassは、このコンポーネントや仕様を特定する目的で使われている。データベースに連携させてFMシステムなどで運用するには、曖昧な言葉では識別できない。そのために分類コードによって、データベース側でのコンポーネントと仕様の識別を助けている。COBieは一例ではあるが、BIMモデルの情報をFMシステムなどに応用できる仕組みを持っているかどうかが、構造化データとしての要件となるだろう。