構造BIM（ST-BRIDGE）の課題を解決する３つの技術

構造BIMに関する課題

BIM（Building Information Model）の普及は急速に進んできています。一方で、一貫構造計算プログラムが中心となっている日本の構造設計において構造データのBIMデータ連携はまだ多くの課題があります。

意匠用の建物情報と構造設計用の情報はデータの考え方が異なるため、構造のことを考えずに作成された意匠用のBIMデータはそのまま構造設計に使うことは難しくなります。

それを吸収するために作成されたのが、日本の構造設計用BIMフォーマットである「ST-Bridge」です。この仕様により、建物躯体情報を各アプリケーション間でやりとりすることがスムーズになりました。

ですが、実務上はまだまだいくつかの課題が残されていることも事実です。

そこで本記事では、残された課題を解決しうる、私達の取り組んでいる技術を紹介します。

技術①　GUIDに頼らない、ST-Bridgeの差分抽出「STB-NoGUID-Diff」

設計工程においては、意匠設計者と構造設計者が並行して作業を進めることがほとんどです。

構造躯体の設計を行った後、ST-Bridgeによるデータ連携で構造躯体の情報を意匠用のモデルに反映することということはよく行われています。

ここで問題になるのは、設計工程では構造モデルの取り込みが頻繁に起こりうるということです。

当然、まっさらな状態でST-Bridgeのデータから構造躯体のモデルをアプリ間連携するのは多くの場合うまく行きます。ですが、その後ちょっとした変更があった場合、意匠側での変更もあるため、それを上書きしないように差分だけ読み込みたくなります。では、「差分」とはどのように抽出すればいいのでしょうか？

一般的には、ST-Bridgeには各部材に「GUID」と言われるユニークなIDを付与することができるので、GUIDを照合して部材の同一性を確認し、同一GUIDを持つ部材について差分があるかどうか確認するというアプローチが取られます。しかし、この方法には以下の問題があります。

様々なアプリケーションが付与するGUIDをST-Bridge内に保持・継承しつづけなければならない
同じ部材でも、誤って一度削除したりすると、二度と同じ部材としてみなされない

アプリケーションAで生成された部材に対してGUIDが付与されていたとすると、これをアプリケーションBが読み込んだときに、GUIDをプログラムが保持し続ける必要があります。これを更にアプリケーションC、アプリケーションDとデータを渡していった場合にも、GUIDを引き継ぎ続けていなければどこかでデータの整合が失われます。また、一見モデル的に差がなくても、部材が一度削除したりされると、削除された部材のGUIDが失われ、部材の同一性が照合できなくなる事も考えられます。

そこで考えたのが、「階、軸名称を元に部材の一意性を特定する」手法（以下、STB-NoGUID-Diffと表記）です。

よくよく考えれば、2次元の図面でコミュニケーションをとる場合には、「2階のX3-Y2通りの柱を、、」「4階のX2-X3,Y2-Y3間床の、X2通り大梁に取り付くY2通り寄りの小梁を、、」など、階と軸名称を元に同じ部材のことを説明できていたはずです。これは、GUIDのような複雑な決め事がなくても、部材の一意性が特定できることを意味します。

STB-NoGUID-Diffでは、GUIDが振られていなくても、上記のようなルールにより同一の部材を特定することが可能です。それにより、部材の生成、削除、移動を検出できます。さらには、部材の属性に変化はなくても、参照している断面のサイズが変われば部材が変更されたと見なし、差分として抽出する事もできます。

技術②　BIMデータにトレーサビリティを付与する「BIM-Chain」

アプリケーション間でST-Bridgeを用いてデータ連携を行う場合、受け渡したデータがいつ、どの時点のデータなのかわからなくなり、混乱することがあります。たとえば、最新だと思ったら少し古い時点のデータを渡してしまったとか、プランAのデータを渡したつもりが、プランBのデータを渡してしまっていた、というようなことです。

データが複数のアプリケーションに受け渡されていくと、あとからこのデータの流れをトレースすることは非常に難しくなります。

この問題を解決する手段としては、履歴を管理するようなデータベースを構築し、データベースを介してデータのやりとりすることが考えられます。ですが、多くの場合大掛かりなシステムとなりがちです。

それを解決する手段の一つとして考案したのが、「BIM-Chain（※特許取得済）」です。BIM-Chainは、ブロックチェーン技術に着想を得たアイディアです。履歴管理を中央集権的なデータベースで行うのではなく、各BIMデータの中に含めてしまう、分散管理型の仕組みです。これにより、ルールに従って各ファイルに付加情報を含めるだけで、BIMデータのトレーサビリティを付与することが可能になります。

なお、BIM-Chainはアプリケーション名ではなく、定められた規約の名称です。したがって、ST-BRIDGEに限らず、理論上はどのような種類のデータでも組み込むことが可能な仕組みです。

技術③　リモートでのBIMコラボレーションを円滑にする「BCF-API」

BIMは複雑な建物情報の整合を保つ上で非常に有用な技術ですが、図面として意思疎通していたときよりもコミュニケーションが複雑化する場合もあります。図面では2次元の情報に落とし込まれた状態でコミュニケーションを取っていましたが、BIMでは3次元データとしてコミュニケーションを取ることになります。3次元データは同じディスプレイを見ながら、その場で視点を切り替えつつ議論するには有用ですが、同じ空間にいない人に情報を伝達するのは少し面倒な場合があります。2次元の図面であれば、当該図面の着目箇所にマークをつけてコメントを書き込むという手段がよく取られますが、3次元だとそのような情報伝達が気軽に行いづらかったりします。

そこで活用できる技術が、「BCF（BIM Collaboration Format）」です。

BCFは、buildingSMARTによって策定されている、BIMによるコミュニケーションを円滑化するためのフォーマットです（https://www.buildingsmart.org/standards/bsi-standards/bim-collaboration-format-bcf/）。

3次元データに対する視点の情報や、そのビューに対するコメントなどを表現することができます。

KKEが開発した情報共有のためのグループウェアであるBimClip（https://wm.kke.co.jp/bimclip-lp/）はBCF-APIに対応していますので、下図に示すようにBimClipを経由してインターネット越しに3次元モデルに対する議論を行うことができます。

近年はWeb会議も浸透しましたので、Web会議で画面共有しながらコミュニケーションを取ると同等のことは行なえますが、BCF-APIを活用したシステムでは会議よりも頻繁に行われるメールやチャットのようなコミュニケーションを効率化することができます。メールでは表現しきれない詳細まで瞬時に伝わるので、コミュニケーションコストが減少します。