ファイル形式では曖昧なBIMは直らない

IFCやCOBieのファイルは、モデルを印刷したものです。計画ではなく、すぐに古くなります。

日本は慎重な道を選びました。2026年4月、建築確認に「BIM図面審査」が導入されました。設計者はBIMモデルから出力したPDFの図書と、同じモデルから同時に出力したIFCファイルを提出します。審査の対象はPDFの図書です。IFCファイルは審査者が建物の形状を理解する助けとなるもので、国土交通省のマニュアルは、IFCデータのみに含まれる情報に基づいた判断は行わないとしています。³⁸BIMデータそのものの審査は2029年春の開始が予定されています。³⁸

このページはもともと北米向けに書きました。北米では、すべてのプロジェクトでIFCとオープンなツールを義務づければBIMの問題は解決する、という見方がよく聞かれます。カナダでその見方を主導しているのは、IFCを管理する団体のカナダ支部であるbuildingSMART Canadaです。同支部がカナダ国立研究機構と2024年にまとめた報告書は、カナダは公共プロジェクトに明確なオープンBIMの義務を設けることができるとしています。⁴⁰

最初にお断りしておきます。OpenBEPの創設者は、独自の交換形式を持つ会社VIMに勤めています。このページの終わり近くで、ほかの選択肢とあわせてその形式にも触れます。

オープンBIMの主張の多くには賛成です。賛成できないのは、よく耳にする「公共の発注者がすべてのプロジェクトでIFCとオープンなツールを義務づければ、業界のBIMの問題はなくなる」という考えです。

私たちの経験では、主な問題はファイル形式ではありません。発注者が何に使うのかを言わずに「BIM」を求めることです。曖昧なモデルをIFCで保存しても、曖昧なモデルのままです。

これは優先順位と順序についての意見の違いであり、誰かの誠意を疑うものではありません。日本語以外の資料からの引用は、当方による翻訳です。

オープンBIMが正しい点

これらに共通する点に注目してください。IDSとBCFが記述するのは要件と課題です。モデルの原本になろうとはしていません。

書き出したファイルは、モデルのPDF

カナダのロードマップ報告書は、特定のプラットフォームに依存しないことがさまざまなBIMソフトウェア間の相互運用性を促し、ベンダーロックインを防ぐとしています。⁴⁰形式が保証するのは、別のプログラムでファイルを開けることです。そのファイルを作業できるモデルにするわけではありません。

• IFCを推進する人たちも、この比較を使っています。2019年のインタビューでは、RevitモデルからのIFCファイルが、WordファイルからつくったPDFにたとえられました。文章は読めても、その中で文書作成はできない、ということです。²そのときの論点は、誰でも読めるという点でした。私たちが言いたいのはもう半分です。多くの会社が使う設計ソフトでは、その中で作業を続けることができません。
• Revitのヘルプによると、IFCファイルを開くと既定のテンプレートから新しいモデルが作られます。そのうえで、IFCを参照情報としてリンクする方法を案内しています。⁴
• 公平な反論もあります。Bonsai(旧BlenderBIM)のように、IFCで直接モデリングするツールもあり、その場合はIFCがネイティブファイルです。ただ、現在そのように作業している会社は少なく、要件は実際のプロジェクトの進め方に合っているべきです。
• オランダは、公共機関が要求しなければならない「遵守か説明か(comply or explain)」リストにIFCを載せています。しかし2019年、同国の標準化フォーラムは、IFCモデルはコミュニケーションと調整のための元モデルからの出力であり、「元モデルに代わるものではない」と明確にしました。⁵
• 2026年4月に始まった日本のBIM図面審査も、同じ考え方です。審査の対象は、BIMモデルから出力したPDFの図書です。一緒に提出するIFCファイルは形状を理解するための参考です。マニュアルによると、IFCデータのみに含まれる情報に基づいた判断は行わず、IFCデータは法定保存の対象とせず、IFCデータを用いた中間検査・完了検査も行いません。³⁸
• この審査を可能にしたのは、ファイル形式ではありません。通り芯、柱、梁、床、壁などの要素ごとに書かれた共通の「入出力基準」と、それを使う設計者が基準に従うことを誓約する「入出力基準適合誓約書」です。³⁸これは、ファイルを使う側が中身を定めた要件です。多くのオープンBIMのロードマップが後回しにしている部分でもあります。
• カナダの2024年のロードマップ報告書は、日本を例に挙げ、国土交通省は建築基準の審査にIFCの使用を義務づけたとしています。⁴⁰その後に公開された国土交通省のマニュアルが示す内容はもっと限られています。IFCは参考として図書と一緒に提出され、審査されるのは図書です。³⁸

最初の改修で古くなる。

納品されたIFCやCOBieのファイルは、ある時点のスナップショットです。2016年、ある上級BIMエンジニアはCOBieを毎年配られていた厚さ5センチの電話帳のBIM版で、玄関に届いた時点ですでに古いと表現しました。⁶私たちの経験では、IFCのアーカイブも同じです。建物が改修される日には、作業はネイティブモデルで行われ、そのモデルが更新され、IFCとCOBieのファイルは書き出し直しになります。書き出したファイルのアーカイブは、古い印刷物のアーカイブです。

ですから、契約上の原本は設計ソフトのネイティブファイルとし、書き出したファイルは、特定の活用目的が必要とする場合に求める追加の成果物とすべきです。これには、私たちが率直に認めるコストがあります。ネイティブファイルはアーカイブを一つのベンダーの形式に縛り、オープンBIMのロードマップが警告するロックインになります。⁴⁰私たちの答えは、発注者はネイティブファイルを所有し、活用目的ごとに必要なデータと形式を明示することで管理を保てる、というものです。一律のIFCの規則だけでは、その管理は得られません。

カナダの発注者の中には、すでにこのように書いているところもあります。オンタリオ州の交通機関Metrolinxは、提出のたびにネイティブファイルと交換用ファイルの両方を求め、図面はPDFとネイティブ形式の両方で求め、統合モデルはNavisworksかIFCで受け付けます。³⁷この仕組みでは、ネイティブファイルが作業用の原本であり、書き出したファイルは特定の活用目的に使われます。

絞り込みは、発注者が条件を決めるなら利点になる。

IFCの書き出しに元のモデルのデータがすべて含まれることはありません。書き出すソフトウェアは、そのモデルビュー定義が対象とするサブセットだけを書きます。¹⁰これは通常、弱点として語られます。私たちは逆に考えます。発注者は、設計者が使った作業用のパラメータや補助オブジェクトをすべて欲しいわけではありません。欲しいのは活用目的に必要なデータだけです。これが私たちの詳細度(LOD)仕様の考え方で、竣工段階のレベルは施工モデルより多くではなく、少なく残します。問題は書き出しが絞り込むことではなく、発注者の要件がなければ、何を残すかを誰も決めないことです。

IFCの問題

すべてのプロジェクトでIFCを義務づけることは、現在のままの標準の重さを、すべての会社に背負わせることです。IFCを管理するbuildingSMARTも、IFCを扱う研究者も、その重さについて率直に語っています。

大きすぎて全部は実装できず、方言に分かれる。

• buildingSMART自身のブログ:この豊富な取り決めのセットは、ソフトウェア開発者が自社ツールに完全に実装するには多すぎることが多い。そのためソフトウェアは、モデルビュー定義(MVD)と呼ばれるサブセットを実装します。¹⁰
• 同じ記事は、次のリリースでMVDが20近くになると数えています。つまりIFCの方言が20あるということだ。ソフトウェアでの実装も20通り。このままでは、気づいたときにはMVDの数は100に達するだろう。さらにコミュニティとして、私たちは外部の人に「IFCは一つではない」と説明してきたと認め、このやり方を持続可能ではないとしています。¹⁰
• 2021年の研究は、実務の57のIFCモデルを調べました。ほぼすべてが旧バージョンのIFC2x3で、これは今も市場の多くで交換されているバージョンです。IFCの柔軟さは複数の解釈を許し、その結果似た状況に対してばらばらなIFCの解決策が生まれ、相互運用性を大きく妨げているとしています。確認した39モデルのうち、十分な意味情報を持っていたのは8モデルだけでした。¹¹
• ですから、契約に「IFCを納品する」と書くだけでは、ほとんど意味がありません。どのバージョンか、どのサブセットか、どのプロパティかを誰かが決め、受け取る側のソフトウェアがそれに対応しているかを確認する必要があります。

規模に耐えない形状表現。

• buildingSMARTスペインの技術コーディネーターは2024年に、STEPをもとにしたIFCの構造がファイルサイズの肥大化と拡張性の限界を招き、より大きく複雑なプロジェクトでのIFCの普及と効果に影響したと書いています。²²
• IFCに対応する調整ソフトの開発会社Reviztoは、IFCファイルは場合によっては元のファイルサイズの5〜10倍に膨らむことがあり、その影響は大規模なプロジェクトで最も顕著だとしています。²³
• buildingSMART自身のブログは、現在のリソース層(主に形状)は整理が必要だと書いています。¹⁰
• IFC 5で検討されている解決策は示唆的です。主な形状表現としての三角形メッシュ、そして繰り返し現れるオブジェクトは毎回書き直すのではなく、一つの代表要素から形状を引き継ぐ方式です。²²つまり、ゲームエンジンや高速なビューアが何年も前から形状を保存してきた方法です。

変わり続ける標準。

• 次のバージョンであるIFC 5は、更新ではなく作り直しです。²²IFC 4.3がISO規格になったのは2024年になってからです。³⁹
• 2026年10月の時点で、buildingSMARTのIFC 5のリポジトリは、今もその例を暫定的で実務での使用には適さないとし、追加の文書はまもなく公開されると書き、今後の開発の更新により、これらの例の改訂が必要になると警告しています。¹²
• 再びbuildingSMARTスペインのコーディネーターです。新しい概念を加えることは大きな変更を必要とすることが多く、バージョン間の非互換や新機能の採用の難しさにつながりうる。²²
• そのため市場は古いバージョンにとどまります。IFC 5についての投稿の下で、Ivan Shtaerはこう書きました。4〜5年ごとに新しいスキーマへの対応を実装しても、まったく割に合わない。市場には消化する時間がない。大量のデータがこの形式で作られ存在しているため、開発者は2X3への対応を続けざるをえない。¹⁹IFC 4.3は安定したISO規格ですが、今それに合わせて書き出しを調整する会社は、IFC 5でその作業の多くをやり直すことを覚悟すべきです。

IFCが役に立つところ。

IFCが最も力を発揮するのはインフラです。2024年のISO版であるIFC 4.3は、橋梁、道路、鉄道、水路、港湾施設を加えました。³⁹私たちの経験では、こうした仕事でRevitが設計ソフトになることはまれで、複数のツールが一つのモデルを共有する必要があります。米国連邦道路庁のロードマップは、州の機関が工学データのモデル化に使えるオープン標準として、LandXMLとともにIFCを挙げています。³⁵それでも、形式が機能するのは、発注者がどのバージョン、どのクラス、どのプロパティかを決め、それを確認する場合だけです。

読みにくい。

これは日々の実務からの私たち自身の見方です。IFCの文書は、経験豊富なBIMマネージャーにとっても、業界で最も使いにくい技術文書の一つです。一つの要素の一つのプロパティをどう書くかを調べるだけで、エンティティ、プロパティセット、MVD、バージョンの層をたどる必要があります。buildingSMART自身も、MVDを用語の中で最も紛らわしい略語の一つと呼んでいます。¹⁰専門家でも読むのに苦労する標準は、規模を問わずすべての会社に課す要件の基盤としては不向きです。

COBieの問題

COBieは表計算ソフト形式の引き渡し用フォーマットで、IFCのサブセットとして作られています。英国政府の2011年の建設戦略は、中央政府が資金を出すプロジェクトでこれを義務づけました。³⁷国の規模での形式の義務づけであり、その結果は記録に残っています。米国では、COBieは国家BIM標準の一部で、2012年(バージョン2.26)に初めて盛り込まれました。全米建築科学研究所(NIBS)が2013年から管理し、2023年にバージョン3.0を公開しました。³⁴引き渡し後にそのデータがどう使われているかについて、以下の英国の記録に匹敵する米国の調査は見つかりませんでした。

• 中身ではなく形式を求めた発注者。バーミンガム・シティ大学のBIMプロセスマネージャー:発注者が具体的な要件を示さずに「COBieをくれ」とだけ言うと、コンサルタントは頭を抱えることになる。建物を管理するのに、そこまでの情報はまったく必要ないからだ。不必要に誰かが費用を払うことになる大仕事だ。³
• 発注者のシステムに届かなかったデータ。英国で義務化が始まった2016年、BIM+が取材した人のうち3人が、COBieのデータを保全管理ソフトに取り込むのが難しいと答えました。ハンプシャー州議会の枠組み契約マネージャー:プロジェクトの引き渡し後にデータをCAFMシステムに移したいが、まだ実現できていない。同じ調査で、回答者の58%が、COBieを規定する規格BS 1192-4を一度も使ったことがないと答えました。³
• 短い一覧で十分だった。ロンドンのキングス・クロスの開発会社Argentが、アセットマネージャー、ファシリティマネージャー、テナントに本当に必要なものを尋ねたところ、答えはかなり短い一覧でした。同社のBIM責任者:COBieのデータを丸ごと納品させるやり方は、私たちが進みたい方向ではない。³
• 何年たっても誤解されている。2020年、施工会社のデジタル責任者でIFCとCOBieの推進者でもあるJohn Fordは、COBieとは何か、その目的、そしてIFCとの関係が理解されていないことが現在の三つの根本的な障壁であり、それに続くのがソフトウェアのネイティブ対応の不足だと書きました。⁷
• 情報ではなくファイルに支払う契約。英国政府の資金による2020年の意見募集では、契約について回答した全員が、一般的な契約は使える、アクセスできる、十分な品質の情報ではなく、書類の納品を促しているという点で一致しました。⁸
• 汎用的な要件。ウェールズでの2026年の研究では、受け取るEIRは、古いプロジェクトからのコピーか、汎用的すぎて役に立たないかのどちらかだという声が聞かれました。参加者は、COBieの成果物が納品の終盤に静的な表計算ファイルとして渡されると述べています。⁹

公平のために言えば、2016年の記事は、住宅のためにCOBieの全データを活用したサンドウェル市のように、COBieを評価する発注者も紹介しています。³違いは、そうした発注者がデータで何をするのかを分かっていたことです。

なぜうまくいかないのか(私たちの見方)。

以下は、Revitプロジェクトでの日々の実務からの私たち自身の見方です。

• 集計表の書き出しと大差ない。COBieのワークブックは、互いにリンクした表計算のシートの集まりです。スペース、ゾーン、システム、予備品、連絡先の間のリンクを除けば、中身のほとんどは、Revitの集計表をExcelやCSVに書き出したものと同じで、手間が増えているだけです。
• モデルに簡単に戻れない。COBieの行の識別子は通常IFCのGlobalIdで、RevitのエレメントIDではありません。Revitの「IDで選択」はこれを受け付けません。要素を見つけるにはプラグインか、エクスポーターが保存したパラメータが必要です。
• 値の出どころが分からない。COBieは列を定めていますが、どのモデルのパラメータがどの列に入るかは定めていません。同じ値が複数のパラメータから来たり、書き出しの途中で名前が変わったり統合されたりしても、ファイルにはその記録が残りません。二つのチームが同じように記入することはまずありません。
• コンサルタントが必要になる。チームに有効なCOBieを納品させるには、研修、確認ツール、外部の支援が必要で、その周りには講座やサービスの市場ができています。COBieから後継へと引き渡し標準が入れ替わることについて、Bilal Succarは数えきれない人が数えきれない時間をかけて学び、実装し、解決し、適応してきた。AとBを中心に教材や事業を作った人もいる。彼らは今、すぐにまたそれをやり直し、将来もまたやり直すことになると書いています。文字は次々と現れる標準を表しています。¹⁷

周辺のツール。

確認用ソフトウェアも同じことを物語っています。2016年、米国陸軍工兵隊の研究開発センター(ERDC)は、オープンソースのCOBie確認ツールCOBieQCReporterを公開しました。COBieの考案者Bill Eastは、それがOracleが2019年に更新を止めたJavaのコードに依存しており、2019年以降の復活やクラウドファンディングによる後継づくりの試みは成功しなかったと書いています。²⁵彼の現在の確認ツールCOBieQCは販売されていません。彼のサイトによると、印刷版の利用者マニュアルをオンデマンド印刷サービスで一人一冊購入すると、12か月の無償コピーが提供されます。試用版はない。ライセンスはソフトウェアを起動するたびにオンラインで確認され、技術サポートは提供されないとされています。²⁴Bill Eastはこのソフトウェアをボランティアの取り組みと説明しており、²⁵その労力を疑うものではありません。商用ツールにはほかの確認機能もあります。それでも、COBieを要求する発注者は、考案者による基準となる確認ツールがこうした条件で提供されていることを知っておくべきです。

• buildingSMARTは、COBieの後継とされる新しい枠組みAsset Operations Handoverを開発中です。Justin Kirbyは、Digital Construction WeekでのSkanskaのデジタル建設責任者の講演をまとめ、COBieの硬直した、表計算中心のやり方は、ますます大量のデータの無駄を生んできた。契約に書き込まれることには非常に効果的だが、建物を運営し、清掃し、保守するチームに実際に使われることには、これまで非常に弱かった。と書いています。¹⁶
• Bill Eastはこう返しました。COBieを「表計算」として見ることは、ずっと要点を外してきた。これはプロセスの問題で、コンサルタントや専門工事会社は、情報が最初に作られた時点でそれを納品することが求められる。プロセスを変えなければ、何と呼んでもうまくいかない。¹⁶この点では私たちも彼と同意見です。大事なのはプロセスであり、形式の要件がプロセスを生むわけではありません。

今COBieを求める発注者は、消えていく形式に費用を払っています。代わりに、運営部門が実際に使うデータの短い一覧を、そのシステムが取り込める形式で求めてください。

ISO 19650は新発見ではない

ISO 19650は、国際規格であることで唯一の正解になったかのように紹介されることがよくあります。役に立つ規格ですが、その中心となる考えのほとんどは、何年も前に無料で公開されていました。

• 2010年、ペンシルベニア州立大学のComputer Integrated Construction研究グループは、BIM Project Execution Planning Guideをクリエイティブ・コモンズのライセンスで公開しました。その手順は四つの主要なステップ:1) BIMの目標と活用目的を決める、2) プロジェクトのBIM実行プロセスを設計する、3) 情報交換を作成する、4) BIM導入を支える基盤を定めるからなります。¹³
• ISO 19650の第1部と第2部は2018年に公開されました。これらが置き換えた英国規格は、英国の手引き自身の言葉で英国のBIMへの取り組みの基礎をなしていたものです。¹⁴英国の手引きはこうも明言しています。情報の中身は、資産のライフサイクルの中でこれまでも常に求められてきた情報と同じである。¹⁵
• 私たちの読み方では、並べてみると、その多くは呼び名の変更です。ペンシルベニア州立大学のBIMの目標と活用目的は、発注者の「情報要件」になりました。情報交換は「交換情報要件」と納品計画になりました。BIM Project Execution Planは「BIM実行計画書」になりました。それでもISO 19650は、任命の連鎖や共通データ環境のワークフローなど、英国規格から有用なものを加えています。
• ですからISO 19650は、契約のための良い共通語彙です。しかし、発注者にどの活用目的が必要かを教えてはくれません。また、その本文はライセンス販売で、ペンシルベニア州立大学の手引きは無料です。

無料のツールがボトルネックなのではない

オープンソースのツールは歓迎すべきものです。しかし私たちの経験では、プロジェクトが役に立つBIMを得られない理由が、ライセンスの価格であることはまれです。妨げになっているのは、必要なものを言えない発注者、それを納品する訓練を受けたことのないチーム、そして結果を誰も確認しないことです。ウェールズの研究の参加者が求めていたのは、実用的なテンプレート、具体的な事例、検証ツールでした。⁹訓練を受けていない人が無料のツールを使えば、無料の曖昧なモデルができあがります。

注目したいほかの形式

業界が非常に大きなモデルに耐えるオープンな交換を求めるなら、最初からそのために設計された形式を見る価値があります。どれもISO規格ではなく、それぞれ一社か小さなコミュニティが支えています。いずれもIFCより新しく、以下の主張は各形式自身の文書からのもので、私たちはベンチマークしていません。

Fragments(That Open Company)

IFC.jsを手がけたThat Open Companyは、Fragmentsを公開しています。同社はこれを大きなデータセットを効率よく扱うよう最適化されたオープンBIM形式と説明しており、バイナリでコンパクト、形状、プロパティ、関係に対応します。そのビューアは数百万の要素を数秒で扱えるよう設計されています。形式はGoogleのFlatBuffersをもとにしているため、誰でもどの言語でも読み書きのプログラムを作れ、ライブラリはMITライセンスで公開されています。²⁸READMEによると、Fragmentsを作る最も簡単な方法は内蔵のIFCインポーターで、現時点ではIFCを置き換えるのではなく、IFCの上に成り立っています。²⁸

VIM

開示:OpenBEPの創設者は、この形式を開発するVIMに勤めています。その点を踏まえてお読みください。

OpenBEPの創設者の勤務先による、オープンライセンス(MIT)のバイナリ形式です。仕様書は低性能の端末でも効率よく読み込み、描画できるよう最適化された、BIMと製造データのための現代的で効率的なオープンな3Dデータ交換形式と説明しています。²⁶形状はインスタンス化された三角形メッシュで、BIMデータはリレーショナルなテーブルです。²⁶

• 値をさかのぼれる。COBieの行と違い、各要素の行はRevitのエレメントIDと固有ID、そして元のファイルを保持し、すべてのパラメータ値は、パラメータの名前、グループ、インスタンスかタイプかの区別、共有パラメータのGUIDを持つ記述子を指します。³³確認ツールは、どのファイルのどの要素のどのパラメータがその値を出したかを示せます。
• モデル自体の構造が保たれる。ワークセット、フェーズ、レベル、デザインオプション、ビュー、各要素の各マテリアルの体積と面積がテーブルとして保存され、Revitのカテゴリは、別のスキーマのクラスに置き換えられることなく、作成されたとおりに残ります。³³
• オープンなコード。形式のライブラリとReactベースのWebビューアは、MITライセンスで公開されています。²⁷
• 限界。一社の形式であり、ISO規格ではありません。保存するのはメッシュだけで、パラメトリックな形状は持ちません。書き出したファイルなので、ほかの書き出しと同じように古くなります。自身の文書によると、RevitのエレメントIDはリンクされたファイルの間で重複することがあり、Revitの固有IDでさえ、組み込み要素で重複した例があります。³³IFCとのベンチマークはしておらず、サイズや速度については何も主張しません。

その他

• Speckleは、お気に入りのAECツールとつながるオープンソースのデータハブで、ツール間でオブジェクトを受け渡し、Apache-2.0ライセンスのWebビューアを備えています。²⁹
• dotbimはオープンソースでミニマルなBIMのファイル形式で、MITライセンス、三角形メッシュのみ、文書は1ページです。本人たちの数え方では、IFCの文書は100ページを超えます。³⁰
• iTwin.jsはBentleyによるインフラのデジタルツインを作成、照会、変更、表示するためのオープンソースのライブラリで、MITライセンスです。³¹
• OpenUSDはPixarが作ったシーン形式で、その業界団体の言葉では今では映画産業を超えて、建築、エンジニアリング、建設などの産業に受け入れられている形式です。³²IFC 5の作業は、そこから考え方を借りています。²²

私たちは、IFCの代わりにこれらのどれかを要求するよう発注者に求めているのではありません。IFCと同じく、これらは書き出しであって原本ではないので、ネイティブファイルは依然として重要です。私たちが言いたいのはもっと限られた点です。「IFCを納品する」とだけ書いた要件は入れ物を決めるだけですが、「このデータを、このIDSで確認できる形で納品する」と書いた要件は大事な中身を決め、より良い入れ物の余地も残します。

実務者の声

LinkedInの公開投稿とその返信を読みました。buildingSMART International自身の投稿の下の返信も含みます。引用は英語からの当方の翻訳です。役職が表示されていない人は、名前だけを記しています。IFCを擁護する人の声も引用しています。

• Marko Lazic:20年分の標準があるのに、「とりあえずIFCを送って」が今も午後を台無しにする一言だ。さらに:どの実際のプロジェクトにも、半分壊れた書き出しファイルのフォルダと、形式が落としたものを直すのが仕事のすべてという人が一人いる。¹⁸
• Jelena Stevanovicの返信:IFCは解決策として扱われることが多いが、実際は入れ物にすぎない。明確に定義された情報要件と適切な品質確認がなければ、「オープンBIM」はプロセスというより約束のままだ。¹⁸
• 同じスレッドでMayur Tannaは、約3,200のオブジェクトからなる統合IFCを一つ監査しました。352の要素がIfcBuildingElementProxyとして書き出され、本来のクラスは書き出し時に失われていた。統合による重複は793、そして実際は28のレベルなのに階が133。彼はこう付け加えています。どこまでが形式のせいで、どこまでが書き出し設定のせいかは、受け取る側からは分からない。¹⁸
• buildingSMART Internationalの2026年東京サミットについての投稿への、Stefan Kovacsの返信:アプリケーションの開発は順調に進んでいるが、主に非常に理論的なレベルだ。お金を払う運営者や建設者として、私たちに必要なのは、仕事を支える速い解決策(問題を解決するユースケース)だ。彼はbuildingSMARTに業界に向けて期限つきの目標を設定するよう求めています。²⁰
• buildingSMARTスイスのBirgitta Schock:openBIMは、10年前なら野心的に思えたほどの技術的成熟度に達した。それでも多くの組織は、それで実際に何を達成したいのかを言葉にするのに今も苦労している。²¹

擁護する側の声

• Lazicへの、Steven S.の返信:「とりあえずIFCを送って」は情報要件ではない。彼の見方では、送り手と受け手はしばしば実際の交換をきちんと定義していないので、悪いのはいつもIFCとは限りません。¹⁸Erik Björnhageも同じ点を指摘しています。IFCで仕事をするのは、皆が自分が何を求め、何を受け取るのかを理解している限り、本当は問題ではない。¹⁸
• Menno Mekes:オランダの大手施工会社は、ネイティブモデルにしか対応しない大きなプラットフォームを使っているときでさえ、プロジェクトの成果物としてIFCを求め、使っている。そして:とにかく機能する。¹⁹

擁護する人も批判する人も、同じところにたどり着きます。交換は、定義され確認されたときに機能します。その定義こそ発注者が飛ばしてしまう部分であり、BIM実行計画書はそのためにあります。

どれだけの損失だったのか

名前の分かるプロジェクトで、COBieやIFCの成果物のために失われた時間や金額の実測値を探しました。上のLinkedInのスレッドも含めて、公開されたものは見つかりませんでした。最も近いのは、一人の実務者が一つのIFCファイルのエラーを数えたものです。資料はその無駄を言葉で説明していますが、数字はありません。実測された事例をご存じなら、出典とともに追加しますのでお知らせください。

発注者がまず求めるべきこと

1. 活用目的。必要なBIMの活用目的を段階ごとに挙げてください。調整、数量、確認申請、維持管理など。活用目的がなければ、要件もありません。
2. 中身。活用目的ごとに、要素、各段階の詳細度、各要素が持つべきパラメータを挙げてください。名前はすべてのプロジェクトで同じにします。
3. 原本のファイル。設計ソフトのネイティブファイルを契約上の成果物にしてください。そうすれば次のチームも、次の改修も、作業を続けられます。
4. 確認できる要件。要件をIDSファイルとしても出し、納品物を自動で確認できるようにしてください。
5. 課題はBCFで。調整の課題はBCFで求め、視点つきでツール間を移動できるようにしてください。
6. 書き出しは活用目的が必要とするところだけ。設計ソフトを持たない特定の関係者がモデルを使う必要があるときに、IFCやほかの交換形式を求めてください。バージョンとプロパティを明示します。
7. 結果の伴う確認。マイルストーンごとにモデルを確認し、合格するまで支払いを保留してください。
8. 人が実際に使う引き渡しデータ。運営部門が実際に使う資産データの短い一覧を、そのシステムが取り込める形式で求めてください。既定でCOBieを求めないでください。

このページが言っていないこと

• 書き出しが役に立たないとは言っていません。設計ソフトを持たない人がモデルを使う必要があるとき、書き出しは正しい道具です。
• オープン標準が悪い考えだとは言っていません。IDSとBCFは要求する価値があり、ISO 19650は役に立つ語彙です。
• 誰の動機も疑っていません。このページの根拠の多くは、buildingSMARTとオープンBIMを推進する人たち自身によるものです。

出典

以下のリンクはすべて2026年10月20日または21日に開いて確認しました。ページ番号はPDFのページです。日本語の資料は原文のまま、英語、フランス語、オランダ語の資料からの引用は当方による翻訳です。

1. É. Poirier, C. Arnould, Les principes du BIM ouvert et de son application dans les projets publics, Feuille de route gouvernementale pour la modélisation des données des infrastructures, 2025年5月14日承認版, p. 1, 2, 8, 11, 12, 13, 17, 19, 20, 23, 24, 25.
2. M.-È. Sirois, Démystifier le BIM ouvert, Portail Constructo, 2019-10-29 (buildingSMART Canadaの代表3人へのインタビュー).
3. Construction Management (BIM+), To COBie or not to COBie – the client's conundrum, 2016-06-09.
4. Autodesk, Open an IFC File, Revit 2023 Help.
5. Forum Standaardisatie, Forumadvies toepassingsgebieden Geo-standaarden, SETU, WDO, VISI, IFC en COINS 2.0, FS-20190424.04A, 2019.
6. A. Hannell, COBie is already an outdated method of data management, Construction Management (BIM+), 2016-06-09.
7. J. Ford, The future of the IFC-COBie saga, Construction Management (BIM+), 2020-08-21.
8. Centre for Digital Built Britain, BIM Interoperability Expert Group Report: Public Consultation Summary, 2020-06.
9. A. Rawdin, A. Khudhair, H. Li, BIM and ISO 19650 implementation in the Welsh construction industry: a case study of bottom-up governance in a non-mandated region, ITcon, 2026, doi:10.36680/j.itcon.2026.021.
10. L. van Berlo, The curious case of the MVD, buildingSMART International blog, 2019-12-12.
11. F. Noardo, K. Arroyo Ohori, T. Krijnen, J. Stoter, An Inspection of IFC Models from Practice, Applied Sciences 11(5), 2232, 2021.
12. buildingSMART International, IFC 5 development repository, GitHub, README (2026年10月20日閲覧).
13. Computer Integrated Construction Research Program, BIM Project Execution Planning Guide – Version 2.1, The Pennsylvania State University, 2011 (©2010), CC BY-SA 3.0 US, 用語集.
14. UK BIM Framework, Information management according to BS EN ISO 19650 – Guidance Part 1: Concepts, 2nd edition, 2019, p. 14.
15. UK BIM Framework, Information management according to BS EN ISO 19650 – Guidance Part 2: Processes for Project Delivery, edition 4, 2020, p. 8.
16. J. Kirby, LinkedIn post on COBie and Asset Operations Handover, 2026-06-04, B. Eastの返信つき、2026-06-05.
17. B. Succar, LinkedIn post on COBie and AOH, 2026-06-05.
18. M. Lazic, LinkedIn post on IFC exchanges, 2026-07-14, J. Stevanovic、Steven S.、E. Björnhage、M. Tannaの返信つき、2026-07-14および15.
19. L. van Berlo, "Easier said than done: IFC should sell itself", LinkedIn, 2025-05-22, I. ShtaerとM. Mekesの返信.
20. buildingSMART International, LinkedIn post on the Tokyo 2026 summit, 2026-09-25, S. Kovacsの返信、2026-10-04.
21. B. Schock, LinkedIn post on openBIM maturity, 2026-06-14.
22. D. Delgado Vendrell, The Evolution of IFC: The path to IFC5, buildingSMART Spain, 2024-12-03.
23. Revizto, What is IFC format? Exploring BIM and IFC models in detail, blog (2026年10月20日閲覧).
24. Prairie Sky Consulting, Software, FAQ (2026年10月20日閲覧).
25. B. East, Introducing the COBieQC2023 software, Prairie Sky Consulting, 2023-07-17.
26. VIMaec, VIM v1.0.0, format specification, GitHub.
27. VIMaec, vim-format and vim-web, GitHub; GitHubとnpmに記載のMITライセンス.
28. That Open Company, engine_fragment (Fragments), GitHub README; npmによるMITライセンス(@thatopen/fragments).
29. Speckle, speckle-server, GitHub README; npmによるApache-2.0(@speckle/viewer).
30. W. Radaczyński, dotbim, GitHub README and licence.
31. Bentley Systems, iTwin.js, GitHub README; npmによるMITライセンス(@itwin/core-backend).
32. Alliance for OpenUSD, aousd.org (2026年10月20日閲覧).
33. VIMaec, VIM object model (エレメントIDの節)および object-model-schema.json (テーブルElement、ParameterDescriptor、Workset、Phase、DesignOption、View、MaterialInElement)、GitHub(2026年10月20日閲覧).
34. National Institute of Building Sciences, COBie Standard, NBIMS-US (バージョン履歴、2026年10月20日閲覧).
35. Federal Highway Administration, Advancing BIM for Infrastructure: National Strategic Roadmap, FHWA-HRT-21-064, June 2021, PDFの18ページと21ページ.
36. Standards Council of Canada, CAN/CGSB/CSA-ISO 19650-2:24, 2024-11-30.
37. Metrolinx, Metrolinx Exchange Information Requirements (BIM), MX-ALM-GDC-003, June 2025, PDFの18ページ(印刷ページ15).
38. 国土交通省(MLIT)、 BIM図面審査 申請・審査マニュアル 、初版、2026年3月24日、PDFの3、17、31、86ページ.
39. ISO, ISO 16739-1:2024, 概要(2026年10月20日閲覧).
40. C. Cozzitorto, F. Jalaei, Y. Sultan, S. Davari, D. Bhonde, openBIM implementations for a Canadian roadmap, National Research Council Canada and buildingSMART Canada, 2024-03-01, PDFの30、56、114、121ページ.
41. buildingSMART International, validate, README の「Running Validation Checks」節、GitHub(2026年10月21日閲覧).