BIMとFMをつなぐ「COBie」とは？デジタルツインやISO規格との関係

BIMについて調べていると、「COBie」という言葉を見かけることがあります。

特に、BIMを設計・施工だけでなく、その後の維持管理にまで視野を広げると登場してくる言葉です。

私自身、最初にCOBieについて調べたときは、「BIMの設備情報をExcelにして引き渡すためのフォーマットなのかな」くらいに考えていました。

ところが調べてみると、それだけでは少し説明が足りません。さらにISO 19650やIFC、デジタルツインなどとの関係まで考え始めると、かなり分かりにくくなります。

そこで今回は、COBieが実際には何なのか、BIMやFM、ISO規格とはどういう関係なのかを整理してみます。

COBieとは何なのか

COBieは、正式には Construction to Operations Building information exchange といいます。

名前からも分かるように、建物を「Construction（建設）」する側から「Operations（運用）」する側へ、必要な情報を受け渡すことを主な目的としています。

ここで重要なのは、COBieを単純な「Excelフォーマット」と考えないことです。

確かにCOBieでは、Excelで扱えるスプレッドシート形式が広く知られています。しかし現在のCOBie V3では、JSONやIFCによるデータ交換も扱われています。つまり、ExcelそのものがCOBieなのではなく、施設の運用・維持管理に必要な情報を、決められた構造で交換するための仕様と考えた方がよさそうです。

では、なぜそのようなものが必要なのでしょうか。

建物が完成すると、施設管理者にはさまざまな情報が必要になります。

たとえば、

どんな設備があるのか
それはどこに設置されているのか
メーカーや型式は何なのか
どの設備システムに属しているのか
保守には何が必要なのか
関連する図書や説明書はどこにあるのか

といった情報です。

ところが、これらが図面、PDF、機器表、Excel、メーカー資料などにバラバラに入っていると、施設管理者が自分の管理システムへ登録し直す必要が出てきます。

COBieは、こうした「建物が完成した後に必要になる情報」を、建設プロジェクトの段階から整理して受け渡せるようにするための仕組みです。

COBieには何が入っているのか

では、実際にどんなデータを持っているのでしょうか。

COBie V3を見ると、Facility、Level、Space、Type、Component、System、Attribute、Document、Job、Instruction、Resourceなど、かなり多くの情報が定義されています。

たとえば空調設備を考えてみます。

「Type」は、ある種類の設備機器を表します。メーカーや型式、仕様など、その製品タイプについての情報を持たせます。

一方、「Component」は、実際の建物に設置された個々の機器です。

つまり、

Type = どんな製品なのか

Component = 実際にどの個体が設置されているのか

という関係です。

さらに、そのComponentがどのSpaceにあるのか、どのSystemに属しているのか、といった関係を持たせることができます。

ここにDocumentやInstruction、Jobなどを関連付ければ、「この機器は何なのか」だけではなく、「この機器をどう維持管理するのか」というところまで情報をつなげられます。

この構造を見ると、単なる「設備一覧表」とは少し違うことが分かります。

むしろ、建物を運用するために必要な情報を、関係を保ったまま受け渡すためのデータモデルと考えた方が近そうです。

では、なぜExcelのイメージが強いのか

COBieについて検索すると、Excelの表がたくさん出てきます。

これは実際にCOBieがスプレッドシート形式で扱われてきたからです。人間が確認しやすく、既存の業務でも使いやすいという利点があります。

ただ、COBie V3ではJSONやIFCも扱われています。

そのため、

COBie = Excel

と覚えてしまうと、少し狭すぎます。

より正確には、

COBie = 運用・維持管理に必要な情報を構造化して交換するための仕様

であり、Excelはその表現方法の一つ、と考えるのがよさそうです。

BIMとはどういう関係なのか

ここで次の疑問が出てきます。

「それならCOBieとBIMは何が違うのか？」

これも調べてみると、COBieはBIMの代わりになるものではありません。

BIMでは、建物や設備について、形状を含むさまざまな情報を扱います。

一方COBieは、その中でも特に施設の運用・維持管理に必要となる情報を構造化して交換することに重点があります。

そのため、かなり単純化すれば、

BIMは建物に関する情報を扱う大きな枠組み

COBieは、その中の運用・維持管理に必要な情報を受け渡すための仕組み

という関係として捉えられます。

ただし、ここも「BIMからCOBieを出力すれば終わり」という話ではありません。

COBieの情報は設計・施工の最後に突然現れるものではなく、プロジェクトの各段階で必要な情報を少しずつ作っていき、最終的に運用側へ引き渡すという考え方になっています。

この点は、BIMを単なる3Dモデル作成ではなく、ライフサイクル全体の情報管理として考える場合に重要になってきます。

ISO 19650とはどう関係するのか

ここからが少しややこしくなります。

COBieを調べていると、ISO 19650も一緒に出てくるからです。

ISO 19650は、BIMを利用した情報管理について定めた国際規格です。

誰が、どの情報を、どのタイミングで、どのような要求に基づいて作成・確認・承認・交換するのか、といった情報管理のプロセスが中心になります。

一方、COBieは施設の運用・維持管理に必要な情報を構造化して交換するための仕様です。

したがって、単純に、

ISO 19650 = 上位規格

COBie = 下位のデータフォーマット

と考えるのは正確ではありません。

ISO 19650が「COBieを使いなさい」と定めているわけでもありません。

むしろ、ISO 19650によって情報管理の要求やプロセスを定め、そのプロジェクトで必要な情報をどのような形で交換するかを別途決める。その選択肢の一つとしてCOBieがある、と考える方が分かりやすそうです。

英国のBIM Level 2ではCOBieが情報交換に利用され、BS 1192-4としてCOBieに関する標準も整備されていました。その後、英国のBIM関連の情報管理はISO 19650シリーズを中心とする体系へ移行しています。

この経緯を調べると、COBieとISO 19650が一緒に語られる理由も見えてきます。

ISO 55000やISO 41000は？

さらに調べると、今度はISO 55000やISO 41000も出てきます。

ISO 55000シリーズはアセットマネジメント、ISO 41000シリーズはファシリティマネジメントを扱う規格です。

ここまで来ると、「ISO 55000 → ISO 19650 → COBie」という階層になっているようにも見えます。

しかし、どうもそう単純な話ではありません。

それぞれ扱っている対象が違います。

ISO 55000は、資産をどのように管理し、組織の価値につなげていくかというアセットマネジメントの領域です。

ISO 41000は、施設やファシリティをどのように管理するかというFMの領域です。

ISO 19650は、BIMを利用した情報管理のプロセスを扱います。

COBieは、その中で施設の運用・維持管理に必要な情報を構造化して交換するための仕様です。

したがって、これらを一列に並べるよりも、同じ建物のライフサイクルを、それぞれ異なる角度から扱っている標準と考えた方が実態に近いでしょう。

デジタルツインとはどうつながるのか

ここまで来ると、もう一つ気になるのがデジタルツインです。

COBieはデジタルツインなのでしょうか。

これは違います。

COBieだけでデジタルツインを構築できるわけでもありません。

デジタルツインを実際に構築するのであれば、3Dモデル、設備・資産情報、センサーの時系列データ、BMSのデータ、保守履歴など、用途に応じてさまざまな情報を組み合わせることになります。

その中でCOBieが担当できるのは、主に設備や資産に関する情報を構造化して受け渡す部分です。

たとえば、IoTセンサーから「空調機の振動値が異常」というデータが入ってきたとします。

その数値だけでは、実際の運用ではあまり意味がありません。

「どの空調機なのか」

「どこに設置されているのか」

「メーカーと型式は何なのか」

「どの設備システムに属しているのか」

「保守に必要な情報はどこにあるのか」

といった情報と結び付いて、初めて設備管理上の意味を持ってきます。

COBieは、こうした設備側の情報を整理するための一つの手段になります。

ただし、COBieを導入しただけでIoTデータと自動的につながるわけではありません。実際のシステムでは、設備IDや分類、各システム間のマッピングなどを別途設計する必要があります。

この意味では、COBieを「デジタルツインのバックボーン」と呼ぶより、デジタルツインを構成する資産情報の一つを標準化する仕組みと考える方がしっくりきます。

結局、COBieは何のためにあるのか

ここまで調べてみると、COBieの重要なところは「Excelの書式」ではないことが分かってきます。

本質的なのは、

「竣工したら設備台帳を作る」のではなく、「運用段階で必要になる情報を、設計・施工の段階から定義しておき、最終的に構造化されたデータとして引き渡す」

という考え方です。

これは、BIMを考えるときにもかなり重要なポイントです。

3Dモデルを作って終わりではなく、そのモデルに含まれる情報を誰が使うのかを考える必要があります。

設計者に必要な情報と、施工者に必要な情報と、施設管理者に必要な情報は同じではありません。

COBieは、その中でも特に「建物が完成した後に、その建物をどう管理するのか」という側からBIMの情報を考えるための仕組みだと言えます。

そしてISO 19650などの情報管理の考え方と組み合わせることで、「どんなデータを作るか」だけではなく、「誰が、いつ、何のためにそのデータを作るのか」というところまで考えられるようになります。

まとめ

COBieについて調べ始めると、「BIMからExcelを出力するための規格」という説明をよく見かけます。

しかし、実際のCOBie V3まで確認すると、それだけではありません。

COBieは、施設の運用・維持管理に必要な情報を構造化し、設計・施工側から運用側へ受け渡すための仕様です。Excelはその代表的な表現方法の一つで、JSONやIFCも扱われています。

BIMとの関係では、BIMそのものを置き換えるものではなく、BIMで扱われる情報のうち、特に運用・維持管理に必要な情報を交換するための仕組みと考えると分かりやすくなります。

ISO 19650との関係も、「ISO 19650が上位、COBieが下位」という単純な階層ではありません。ISO 19650は情報管理のプロセスを扱い、COBieは施設運用に必要な情報の交換仕様を扱います。

さらにISO 55000やISO 41000まで含めると、これらはそれぞれアセットマネジメント、FM、BIM情報管理、データ交換という異なる領域を担当しています。

そしてデジタルツインについては、COBieそのものがデジタルツインになるわけではありません。

むしろ、3Dモデル、設備・資産情報、IoT・BMSなどの動的データ、保守・運用履歴といった複数の情報を組み合わせていく中で、COBieは設備・資産情報を整理して受け渡すための一つの部品になる、と考えるのが自然でしょう。

こうして見ていくと、COBieの面白さは「Excelのフォーマット」にあるというより、建物の情報を竣工時にまとめて作るのではなく、運用段階から逆算して、設計・施工の段階から準備しておくというところにあるようです。