信喜プロダクトモデルの開発略史(図形からBIMまで)IGESBIMやCIMの概念を実現するためには、種々の異なるソフトウェア間でデータがスムーズに共有できることが必要条件となる。そのためには、個々のソフトウェア同士でデータ互換用プログラムを作るよりは、標準化されたデータモデルを介する方が、はるかに効率的である。Specification:アイジェスと読む)が開発された。幾何形状の他、文字やハッチングパターン等のデータの仕様を標準化したものである。オブジェクト指向1980年代に入ると、3次元CADが商用化され、航空機や自動車業界では競って、3次元CADを導入した。同時に機械工学の分野で、Feature-based(フィーチャー・ベース)あるいはModel-based(モデル・ベース)という概念が生まれた。ヤング率などの特質(フィーチャー)を有する一つのオブジェクトとして捉え、モデリングする際にもフィーチャーに基づいて、形状や属性を入力してパラメトリックに設計する方法である。この概念の基になっているのが「オブジェクト指向」である。オブジェクト)という概念が合体したもので、1960年代から萌芽が生まれ、70年代にSmalltalk言語がゼロックス・パロアルト研究所(PARC)で開発されて、コンピュータサイエンスの分野で広がり始め、80年代にC++等の言語が開発されると、オブジェクト指向プログラミングが広く採用されるようになった。フィーチャーベースに話を戻すと、機械系CADでは、パイプやカムといった部品や部材(オブジェクトあるいはエンティティ)の名称、属性、関係などを標準化する必要性が生まれた。CAD会社が当時、勝手に部品や部材のデータモデルを作り始めたからである。IGESは単なる幾何形状の標準であるからオブジェクトの標準にはなり得なかった。Data)の策定を始めた。Specification)を対抗して策定したが、1990年代にISO-STEPに吸収された。ISO-STEPでは、プロダクトモデルを表現するための言語仕様を標準化し、EXPRESS、EXPRESS-Gが決められた。分野のプロダクトモデルの規格化が進んだ。IAI-IFCところが、建築や土木分野では、3次元CADそのものをプレゼンテーションなどの目的以外ではほとんど使わなかったことから、プロダクトモデルの策定は進まなかった。Interoperability)というコンソーシアムを1994年に立ち上げた。当時の最初の「I」はIndustryであった。Classes)を策定し始めた。1996年に、IAIの最初のIをInternationalに改称し、国際的なコンソーシアムとなった。各国や地域は支部(Chapter)という形をとり、日本も1996年からIAI日本として加盟している。IFCは、非常にシンプルなプロダクトモデルであったが、次第にエンティティ(部材)の数が増え、その後、度重なるバージョンアップ(upgradingが正しい英語の用語)により、部材だけでなく、人間(Actor)、施工過程(Process)などが加わり、エンティティの関係を表した図をプロットアウトすると、畳2畳分くらいになってしまい、2005年ごろには全てのエンティティを一つの図で表現することをIAIでは止めてしまった。その代りにHTMLを使って、コンピュータ上でハイパーメディアとして閲覧できるようにしている。IAIでは、2005年ごろまでは、創設した米国は実はあまり力を入れず、ヨーロッパが中心となってモデル策定を進めていたのであるが、2005年ごろから急に米国でBIMと言い始めて、トップダウンでBIMを推進することになった。すると、それまでIFCに対して、それほど積極的とは言えなかったCADベンダー達は、IFCとの互換性を持たせるようになり、そのおかげで、世界中でBIMが話題となり、今のような状態となったのである。前述のように、ISO-STEPではプロダクトモデルの開発に大幅に出遅れた土木分野であるが、わが国においても、鋼橋分野や一部の大学や団体などで、研究的ではあるが、プロダクトモデルの開発は行われてきている。海外においても、一部で橋梁や道路などのプロダクトモデルの開発が行われてきている。橋梁わが国の鋼橋製造会社のいくつかは、船舶製造とのつながりもあったことから、1980年末から3次元CADを使用し始め、数値制御(NC)による鋼板の罫書きやボルトの穴開けなどCAMまで進めていた。90年代末には、数社でコンソーシアムを作り、鋼橋のプロダクトモデルを民間CADソフトウェアベースに策定しようという動きがあったが、その後の公共工事の大幅削減等により、そうした活動はなくなってしまったようである。筆者は、2000年から建築分野のIFCをベースに橋梁に必要なエンティティのみを新たに加えて、鋼桁橋のプロダクトモデルYLSG-Bridgeを作成し、その後、2002年にプレストレスト・コンクリート建設業協会との共同研究により、PC/RC橋梁のプロダクトモデルYLPC-Bridgeを開発した(図-3、図-4)。CSTBが中心となって活動しているIAIフランス語圏支部では、SETRA(日本の国総研に相当)が1998年に開発したOA-EXPRESSと呼ばれる橋梁のプロダクトモデルをIFCを拡張するという方法で翻訳し、IFC-Bridgeという名称でIAIの国際会議で発表した(図-5)。筆者と似たアプローチであったため、別々に開発するより、2つのモデルを合わせて、共同で開発する方が、国際的に展開できると考え、2004年フランスに行き、共同開発することで合意した。SAKURAに申請したところ、幸運にも採択され、2005年から2007年にかけての2年間、共同で新IFCBridgeを開発した(写真-2)。Internationa(IAIの親組織)に新IFC-BridgeをIFCの拡張として認めてもらうように申請を行ったが、資金不足から途中でストップした。国際標準になったり、IAIで認められることにはなりそうもない、とCADベンダーに判断されてしまったため、互換性を持たせるようなアクションを取った会社はない。その後の経緯については、後に記す。道路については、旧道路公団が、高速道路のエンティティの関係を示したプロダクトモデルJHDMを2005年に開発したが、公団の分割民営化に伴い、利用されてこなかった。プロセス小委員会で、見直しを始めている。3Dと互換性があることから、道路モデルのデファクトスタンダードになると期待されたが、コンソーシアムであるLandXML.orgは2012年、WEBサイトを閉鎖した。LandXMLの現状と今後については、後に記す。わが国の国総研では、道路の中心線形標準データモデルとしては、LandXMLは用いず、XMLで別途開発し、道路の情報化施工に利用できるように整備されている。この他、ドイツではOKSTRAと呼ばれる道路のネットワークモデルがあるが、ドイツ語でのみ記述されているため、内容については不明である。シールドトンネルシールドトンネルについては、2005年から2007年にかけて、筆者と日本建設情報総合センター(JACIC)との共同研究により、プロダクトモデルIFC-ShieldTunnelを開発した。当時、シールドトンネルを選択したのは、世界のシールドトンネルの総延長の約半分が日本にあったから、日本でプロダクトモデルを作成することは世界にとっての責務であり、今後の世界展開を考えた場合、有利であるとも考えたからである。IFCを拡張することによって、シールドトンネルのプロダクトモデルを実装したのは、IFC-Bridgeの際と同じ理由である。IFC-ShieldTunnelは2007年に完成したのであるが、IFCBridgeと同様、CADベンダーはどこも互換性を持たせるような行為はしなかった。モデル小委員会によって引き継がれ、2009年に全体的にエンティティの追加と修正を施し、ドキュメントも整備した(図-6)。2010年には、開削トンネルのプロダクトモデルIFCCut&CoverTunnel(図-7)を、2011年には、山岳トンネルのプロダクトモデルIFC-MountainTunnel(図-8)を開発し、2012年に以上3つのトンネルのプロダクトモデルを統合化して、IFC-Tunnelを完成させた。IFC-ShieldTunnelについては、2009年から2011年にかけて株式会社大林組の古屋氏らによって東京の大井トンネルの建設現場でセグメントリングのモデリングなどに活用された。CAD等のソフトウェアがIFC-ShieldTunnelとの互換性を持たせていないのに、利用することができたのは、IFCの中にあるIfcBuildingElementProxyと呼ばれる「代理エンティティ」による「読み替え」を行ったことによる。