BIMというツールによるコミュニケーションの変容、そして将来像
現在世界人口は75億人にも及び、2050年には100億人になるとも言われている。そして、自然資源や、熟練労働者は不足している。そうした中での解決策として、労働力としてのコンピュータを活用した生産性向上を行う必要が出てきている。日本政府も若年入職者の確保・育成が喫緊の課題とし、休日の確保等の働き方改革を推進するため、ICTの全面的な活用によるi-Construction推進コンソーシアム（建設現場の生産性革命）や、建設BIM推進会議を設置し、建築物業界の生産性向上を目指している。海外でも同様の動きがあり、英国ではBIMを活用し、企画ー竣工の期間や、温室効果ガス排出量を2025までに50%にするなど野心的な数値目標を立てている。 注1) 英国の例では国を挙げてBIMの標準化及びそのためのツールキット等を提供している。 注2)
人工知能との対話というお題目をいただいたが、現在の日本の建築業会においては人工知能活用以前の段階、つまり未だBIMというツール自体の普及段階であると言える。そこで本稿ではまずコミュニケーションの前提である標準言語について述べた上で、BIMというツールによるコミュニケーションの変容－これは建築業界で最も喫緊の課題である働き方改革の文脈でも大いに歓迎されるべき変容である―についてお話させていただき、その次のステップとして人工知能との付き合い方への提言に進めていきたいと思う。
1. 標準言語について
コミュニケーションとは標準言語があって成り立つ。言語と人工知能との関係をごくシンプルに捉えると、英語という大量に存在する標準言語を学習することにより自然言語処理という人工知能の分野が確立した。同様に大量に存在するRevitデータ（BIMデータ）をためていくことで、BIMにおける人工知能の活用の可能性がある。そうしたときに、BIM活用における”標準言語”の定義が必要であり、国交省によるBIMガイドラインやBLCJ（BIM Library Consortium Japan）、RUG（Revit User Group）を通してまさにそうした整備が進められている。
1.1 BIMにおける標準言語とは何か
たとえば、「壁とは？」といったときに、その受け手によって、必要な情報は異なる。意匠設計者、構造設計者、設備設計者、施工者や施主、それぞれに壁にもたせたい情報、必要とする情報は異なるのである。さらには同じ立場の受け手（例えば2名の設備設計者がいたとする）でさえ、その「壁」という要素の背景にある全ての情報を共有することは不可能である。
あなたの目の前にある「壁」という要素の背後には、多くの情報が紐づいている。それがどういったプロジェクトの壁であるのか、開口や窓など他の要素との取り合いはどうなのか、その壁を何が構成しているのか、サイズはどうなのか、構造強度を持っているのか、遮音断熱/防湿性/断熱性/熱容量といったスペックはどの程度か、といった具合である。
また、一方で、サプライチェーンの中で壁の見方も異なる。メーカーにとっては商品であるし、施工者にとっては、下地を発注し現場で仕上げる工事の成果物である、一方オーナーにとっては自分の資産となる。BIMの標準言語とは、「壁とは、空間を仕切るもの」という一言以上に、標準化する上で考慮すべき受け取り手が多く存在する。従って、仕様がある程度標準化されていることによって、プロジェクトに関わる全ての受け取り手にとって快適なコミュニケーションが可能となる。
2. BIMツールによるコミュニケーションの変遷
2.1図面の理解+口頭
では、背景にある情報がBIMのようにデータ共有できない場合、プロジェクトに関わる人々はどのように上記のような複数の情報を扱ってきたのだろうか。現在でも多く見られるのは、2D図面で線から構成される図形を「壁」と認識し、必要な情報は別表で参照するか、口頭などで確認を取る方法である。 人間は優秀で柔軟に考えられるので図面を理解できるが、コンピュータは（融通の効かない堅物なので）図面を理解できない。
2.2 複製可能性と唯一性_図面化の時代
「AutodeskといえばAutoCAD」と言われるように、Autodeskは２D図面の電子化を牽引した。その変化がどのように革命だったかというと、図面をデジタル化することにより、複製や反復が圧倒的に容易になった。それは、図面内の特定の図表現についてもそうであるし、図面自体の複製も自由にできるようになった。一方、苦手なのは、複数の図面に登場するものが、“同一のものである”、という情報の保持である。情報を抽象化するうえで実際には3Dである建物を2Dで切り取ったことにより、群盲象を評す（注：複数の盲人が象の一部に触れてその形状について語り合うというインドの寓話である）のような状況になってしまいやすい。
2.3 複製可能性と唯一性_最適化の時代
ではBIMがどのようにそこに革命を与えたのであろう？まずは、2次元であったものを３次元化している。次に、GUID（グローバルユニークID）という、2Dで弱点であった唯一性を担保する技術を活用している。これにより、エレメントや、そのパラメータの唯一性を確保するようになった。たとえば、Revitに代表されるようなパラメトリックモデリングで建物をデジタルに3次元化し、パラメータや、オブジェクトにGUIDと言われるようなキーをつけることができる。オブジェクト一つ一つは実際の世界でも唯一なので、GUIDをそれぞれが持つのは理解しやすい。一方、パラメータの唯一性は少し、咀嚼する必要があるので具体的に踏み込んで紹介する。Revitでは共有パラメータと呼ばれるパラメータがある。これはGUIDを持ち、そのエレメントが持っている情報を図面に注記するようにタグをふれるし、集計表等でリアルタイムに管理できる。また、複数のファミリに対して適応可能であり、プロジェクトをまたいで利用できる。注３）
例）メーカーAファミリの共有パラメータ「消費電力」のGUIDが[1234567-abcdefg-1234567890]だったとする。メーカーBファミリの共有パラメータ「消費電力」のGUIDが[1234567-abcdefg-1234567890]の場合に、一括で管理できる。
2.4 複製可能性と唯一性_つながりの時代
このGUID等の技術が、データベースとしてのBIMを支えている。これにより、他のデータベースや、抽象度の高い系統図などのデータを紐づけ、BIMのモデルにさらなる付加価値を加えていくことができる。これまで、こうした実装できる範囲はDesktop上のアドオンだけであったが、Forgeと言われるWebAPI（API：アプリケーションインターフェースについては追って詳細に解説）も公開したことによりPythonやJavaScriptでBIMデータを扱えることにより爆発的にBIMに関われる人口が増えた。これは、Forgeのようなクラウドサービスと繋がることで、クラウドコンピューティングパワー（24時間稼働するサーバ環境を格安で利用できる）も使っていくことができることを意味する。
(P&IDとのリアルタイム連携サンプル)
https://forgeplant.herokuapp.com
(コストデータベースとの連携サンプル)
https://forge-rcdb.autodesk.io
2.5 デジタルツールの作りこみ＿図面出力のための効率化
Autodeskでは多大な時間をAPIの作成に費やしている。APIとはソフトの機能を外部から利用できるようにし、手引きと共に公開する仕組みのことである。おそらくAutodesk製品全般に言えるが、このようにユーザに好きに拡張してくださいという製品であり、そこがある意味使いにくいと言われてしまう所以である。ただ、そうしたAPIをフル活用し、さまざまなアドオンを自発的に提供するユーザーが国内外にいる。また、AppStore等にて販売することを促進している。しかも、図面についてAPIをフルに活用し、３Dモデルから円滑に２D図面を書き出すツールも存在しており、BIMだからと言って2Dが弱いわけではなく、適切な設定やツールの開発によりこれまで以上の書きぶりを確保することは可能である。「大工道具は道具屋から買ってきて使うものではなく、大工が自分でつくるものだ。」という言葉があるように、Revitは大工道具のように作りこんでいくことができる。
2.6 建設業の多忙な現状（巨人の肩に乗る）
そんなにいいことだらけならば、明日から2Dから3Dにすればいいじゃないか？と言った時に業界全体が動くのに時間がかかっている。製造業もかなり時間をかけてきたが、建設業は活況で、一方活況であるがゆえに、働き方改革を行えないでいるのかもしれない。仕事はいっぱいある、ただ、過労や精神的な負荷など問題は山積みだ。標準言語が2D図面と仕様書という非常に限定的なコミュニケ―ションによって成り立っているがゆえに、生産性が悪い。いちいち電話して、図面に抜け落ちた情報を確認する必要があったりする。
ここが実務と、BIM実装の間のジレンマである。これは工期絶対の日本の特徴でもあるが、「明日までに」と言われたら「明日までに」であって、より効率のよいコミュニケーションというよりも至急な事案が多すぎて、将来的に重要な事案に取り組めていないと言える。そこで、提案したいのは巨人の肩に乗る方法である。「大工道具は道具屋から買ってきて使うものではなく、大工が自分でつくるものだ。」と述べたが、大工道具とソフトウェアの違いは無限に複製することができることである。社内外で先に作りこみをしているツールセットを利用していくことで、忙しい中でも業務を改善することができる。
2.7 BIMツールとコミュニケーションのこれから
以上、BIMツールによるコミュニケーションの変遷を見てきた。今後のヒト対BIMのコミュニケーション、つまり「設計者はRevitをどう扱うか」については先人の作ってきたツールを活用しつつも、大工道具の延長として考えれば良いのかもしれない。一方で、Revitを契機とした今後のヒト対ヒトのコミュニケーションについては共有パラメータ等の仕組みを活用し、最低限この情報は必要ですよね、という標準言語を共有することが産業全体としても重要であり、オーストラリアや、英国では、業界団体等が先に述べた共有パラメータを整理することにより、メーカー等がBIMパーツを提供しやすいような土壌を作っている。
3. 人工知能によるコミュニケーションの変遷
3.1 人工知能
BILTという米国での学会において、データサイエンティスト向けのセッションと建設業向けのセッションを併設したが、好き勝手にパラメータを追加するのではなく、ある程度データを構造化することの重要性が強調されていた。構造化とは、どこにデータが入っているのかわかる状況のことで、そのような状態であれば、目的変数と、説明変数により、解析を行うこともできる。人工知能としてデータを活用する時代においては、各プロジェクトでその場しのぎの情報の入れ物（プロパティ）を追加し、そこでデータをやり取りして別ソフトと連携する、というコミュニケーション手法ではなく、先に述べた共有パラメータ等を活用してデータをどこに入れるべきか、という入れ物を少なくとも学習させるデータ群では規定してあげる必要がある。
3.2 人工知能と建設業
今後のコミュニケーションツールとしてのRevitは建設業界内だけでなく、業界外の人に伝えられる必要がある。建設業界にAIについて深く学んだ人は非常に少ないと思う。一方ベンチャー等で数々の優秀なAIベンチャーがいるが、彼らからしたら、データが構造化されていない、しかも要件定義もよくできない建設業界よりも、よほど、金融や先進的な製造業のユーザと話をした方が早い。日本ではAI人材の拡張に向けて危機感があらわになっており、優れたAI人材が現状の建設業と協業したいかというと圧倒的に優先順位が低いのが実情である。2D図面という構造化されていないデータが主流の日本の建設業の現状である。
3.3 Generative Design
それではデータがない場合に、複数案を生成するにはどうすればいいのか？一つの手法がGenerative Design という手法である。Generative Design とは、「自然の進化するアプローチを模倣してデザインを行うテクノロジー」であると定義づけしている。具体的には遺伝的アルゴリズムを活用しながら、設計が達成すべき目的変数を定め、そして複数案を生成し、その複数案の中からクラスタリング等の手法を用いて最適な解を見つける手法である。建築におけるGenerativeDesignの歴史を紐解くと、Gerald L. Delon’s 1970によるA Methodology for Total Hospital Design,にあるように、病院という、解かなければならない与条件が多いビルディングタイプにおいて、その与条件を整理し、設計をある程度自動化するという取り組みであった。国内外で多くの事例が出てきている。
https://www.autodesk.co.jp/redshift/daiwa-house-generative-design/
3.4 重要なパラメータは何か？
Generative Designなどの手法は、重要であろうパラメータを設定し、その目的変数が最大化するように遺伝的アルゴリズム等を活用して、コンピュータに複数案検討させる手法である。ではどういった、パラメータを重要と捉えて設計していけばいいのだろうか？まさに設計としての要件定義である。構造解析など、レギュレーションとして明快に定まっている建物としてのパフォーマンスもBIMと連携する仕組みは既に出来ている。今後、つながりの時代に注目したいのは、そうしたパラメータが建築主や、エンドユーザーへ拡大することだ。オーナーの持っているデータ（主にエクセルだと思われるが）とBIMにつなげてあげることで、飛躍的に、オーナーとの合意がとりやすくなると思われる。他にも、最近関心の高いSDGsに絡めて、BIMでのシミュレーションを活用して光熱費でランニングを抑えるのも訴求力があるかもしれない。
3.5 日本におけるBIMの普及
イギリス等ではDfMA等Design For Manufacturing and Assemblyという概念がうたわれていたが、様々なコード体系を活用している。英国のように国の強いリーダーシップがある場合は良いが、そうした動きがない場合よほど強い交渉力がない限り、そうしたコードの普及は難しい。また、日本語表記とデジタル化のハードルとして地味にではあるが、半角全角問題等が、図面から離れられない要因になってしまっているような気もしている。（カッコやカタカナの全角半角によりプログラムが止まることが多い問題）ただ、ファセット型のコード体系等はBIMとの相性が良いが、本当に必要かというと、疑問でもある。たとえば図書の現代的なデータベースの考えではそこは必須ではない。日本でのBIMの次のステップはISO19650に準拠するように、データ共有の仕組みはしっかりと国際基準に対応し、（ISO19650 はCDE（Common data environment）と言われるような概念を核としたオーナーや、業務関係者間のデータ共有のプロトコル）、日本独自の高いすり合わせ能力を活用した、BIMの発展がなされるべきだと考えている。具体的には、情報の緻密なパス回しによる高い生産性を共有パラメータ等の決めた入れ物を使うことで、設計の進捗等も含めて人工知能等でも学習できる。
3.6 トップダウンと、ボトムアップ
データを最低限構造化させるには、自由すぎるスキーマを持っている形式ではなく、カテゴリなど、固定する必要がある。積算基準等含めて、どのようにBIMを構造化すべきかという議論が現在成されている。オートデスクとしても、日本の仕様に準拠した意匠・構造・設備のオフィスビルを公開することで、こうした議論が具体化することをサポートしている。
Dynamo(Autodeskで公開しているビジュアルプログラミングツール)による設計の自動化は意匠構造設備をつないだ形でDynamoTF（Task Force）というユーザグループによって進められており、そうしたアセットは公開される予定になっている。
3.7 必要なコミュニケーション能力
Generative Design等の登場によって設計者のツールとの対話方法は変わってくる。ではどう変わってくるか？間違いなく言えるのは、明快に設計要件を定義する必要があるということである。これは複数の意味があり、単純に建築設計業務としての要件定義、あるいはプログラムの外注を依頼する際の要件定義という職能。「とりあえず、あれやっといて」ではまだプログラムは動かない。もちろん現状も仕事は進むのであるが、こうした人工知能とのやり取りが必要になる中で建設業に足りない能力はまさに要件定義だと思われる。要件定義が明快であれば、副次的であるが、AIの開発について、発注する方も受託する方も幸せになれる。自分自身もオートデスクのAEC（建築系）ソリューション日本開発責任者として、BIMに取り組んでいる設計＆建設事業者、それをサポートしてくれている多くのBIM関連事業者の方を助けられるように、努力していきたい所存である。
注２） https://www.nationalbimlibrary.com/en/nbs-plug-in-for-autodesk-revit/
注３） ちなみに共有パラメータ以外にも、柔軟にプロジェクトごとで使えるパラメータやそれらを調整する手法も存在する。https://knowledge.autodesk.com/ja/support/revit-lt/learn-explore/caas/CloudHelp/cloudhelp/2019/JPN/RevitLT-Model/files/GUID-E7D12B71-C50D-46D8-886B-8E0C2B285988-htm.html
