エクスポートの修正 · 2026-06-03 · 9分

大きなIFCファイルでブラウザーがクラッシュする理由と、1GBのモデルを表示する方法

600MBの統合IFC、1.7GBのRAM消費、毎秒3フレーム、そしてタブが落ちる。大きなIFCファイルがほとんどのWebビューアーを破綻させるのには、具体的な技術的理由があります。実際に何が起きているのか、そしてサーバーも高性能なワークステーションも使わずに、そのサイズのモデルを開く方法を解説します。

大きなIFCファイルでブラウザーがクラッシュする理由と、1GBのモデルを表示する方法 — IFC Viewer Online article cover

統合モデルを扱う人は、誰もが同じ壁にぶつかります。意匠＋構造＋設備（MEP）を統合したIFCは600MBから1GB超にもなり、ブラウザーで開こうとした瞬間にファンが唸りを上げ、メモリ使用量は1.7GBを超え、フレームレートは1桁に落ち込み、最後にはタブがクラッシュします。操作が間違っているわけではありません。大きなIFCファイルがほとんどのWebビューアーを破綻させるのには、きわめて具体的な理由があるのです。

1GB+ — 一般的な統合モデルのサイズ
1.7GB — 最適化してもこれだけのRAMを消費
3FPS — 最適化されていないモデル
12× — オープンソースと商用の速度差

大きなIFCファイルでブラウザーがクラッシュする理由

シングルスレッドでの解析

IFCのテキストを3Dジオメトリに変換する処理はCPU負荷が高く、従来は1つのスレッドで実行されます。何かが描画されるまでにファイル全体を解析しなければならないため、その間UIは固まってしまいます。

メモリの上限

最適化したモデルでも、RAMを約1.7GB消費することがあります。RAM 8GBのノートPCでは、ブラウザーがタブごとのメモリ上限に達してレンダラーが強制終了されます。これが、いわゆる「タブのクラッシュ」画面です。

テッセレーションのコスト

IFCのジオメトリは、多くの場合パラメトリックなソリッド（押し出しやスイープ）として定義されています。これをWebGL向けに三角形メッシュへテッセレーションすると、データ量も処理量も何倍にも膨れ上がり、毎フレーム数百万もの三角形を描画することになります。

すべてを先に読み込む方式

一度に見るのはそのごく一部にすぎないのに、ほとんどのビューアーはファイル全体を最初にダウンロードして変換します。すべての処理が終わるまで、何も描画されません。

オープンソースのビューアーが商用より遅く感じる理由

広く共有されているコミュニティのベンチマークが、その差をはっきりと示しています。288MBの電気設備モデルの読み込みに、あるオープンソースツールでは約830秒かかったのに対し、商用ビューアーでは約67秒でした。12倍以上遅いことになります。この差は魔法ではありません。商用ビューアーは多くの場合、パラメトリックな形状をより直接的に表現することで完全なテッセレーションを避けています。さらに、ユーザーが開く前に、サーバー上でモデルをストリーミングに最適化した形式へ前処理しているのです。

オープンソースのビューアーでは830秒、商用のビューアーでは67秒。いったい何が秘訣なのでしょうか？
IfcOpenShell GitHub：大規模な統合モデルの表示について

その「秘訣」とは前処理とストリーミングであり、そこに落とし穴もあります。最速のオープンソースのパイプライン（IFCをxeokitのXKTやglTFに変換するもの）では、変換のために技術的な知識とサーバーが必要です。製品開発チームならそれでも構いませんが、発注者からメールで届いたばかりのファイルを前にしたコーディネーターにできることではありません。

実際に効果のある対策

一度変換して何度も読み込む：IFCを高速なジオメトリ形式（Fragments、XKT、glTF/GLB）に一度だけ変換し、次回以降はそれを読み込みます。IFCを実行時に毎回解析していては、繰り返し使うには遅すぎます。
タイリング：モデルを空間的なチャンクに分割し、カメラの近くにあるものだけを読み込んで描画します。
カリング：画面外にあるジオメトリや隠れているジオメトリは、毎フレームGPUに送るのではなく、描画対象から外します。
ジオメトリの圧縮：繰り返し現れる要素の重複を排除し（同一のボルトや手すり子はすべて1つのメッシュを参照）、座標を量子化してデータ量を減らします。
開く前にファイルを軽くする：必要な分野だけをエクスポートし、転送用にはZIP圧縮（ifcZIP）します。

サーバーもアップロードも使わずに大きなモデルを開く方法

このビューアーは、WebAssemblyを使ってクライアント側でIFCを解析し、変換したジオメトリをブラウザーのOrigin Private File System（OPFS）にキャッシュします。そのため、重い解析は一度で済み、2回目以降の読み込みはおよそ10倍速くなります。アップロードの手順も、構築すべきサーバーもありません。モデルをどこにも送らずに、商用パイプラインの「一度だけ変換する」メリットが得られます。複数の分野のモデルを1つのビューに統合する場合も同じで、順番に読み込むだけです。

実務規模のモデルを開く

RevitからエクスポートしたIFC4の意匠モデルを、実務規模のまま丸ごと用意しました。大きめのファイルがブラウザーでどのように読み込まれ、キャッシュされるかを確認したら、自分の重い統合モデルも試してみてください。

IFC4 · 14 MB

インタラクティブなIFCビューアーを開く

結論として、1GBのモデルを確認するのに、64GBのワークステーションも有料のプラットフォームも必要ありません。必要なのは、一度だけ解析し、その結果をキャッシュし、見ている部分だけを描画するパイプラインです。そしてそれは、ブラウザーのタブひとつで手に入ります。

大きなIFCファイルでブラウザーがクラッシュする理由と、1GBのモデルを表示する方法