BIM・IFCブログに戻る
プライバシーとセキュリティ · 2026-06-28 · 19分
ブラウザーでのIFC検証かクラウドか：BIMチームが判断を誤りがちなアーキテクチャの選択
WebAssemblyによるオフラインのIFC検証なら、何もアップロードせず、現場でも使えます。ブラウザー型とクラウド型のIFC検証ツールを、プライバシー、GDPR、アップロード速度、オフライン利用の観点で比較し、それぞれのアーキテクチャが有利になる場面を解説します。
ブラウザーでのIFC検証かクラウドか：BIMチームが判断を誤りがちなアーキテクチャの選択 — IFC Viewer Online article cover
- 0バイト — ブラウザー検証でのアップロード量
- 40秒 — 10Mbpsで50MBをアップロードする時間
- 44 — クライアント側でチェックするルール数
- 10× — OPFSキャッシュによる再読み込みの高速化
BIMコーディネーターが「IFCファイルはどこで検証できますか？」と尋ねると、たいていURLがひとつ返ってきます。クラウドサービスです。モデルをアップロードし、待って、レポートを受け取る。これがIFC検証の一般的なイメージですが、実際にこの方法が使われているプロジェクトの少なからぬ割合にとって、これは誤った選択です。
IFC検証には、根本的に異なる2つのアーキテクチャがあります。その違いを理解し、どのプロジェクトにどちらが適しているかを判断できることは、BIMマネージャーやデジタル建設チームにとって、ますます重要な専門スキルになっています。どのアーキテクチャを選ぶかというひとつの判断で、プライバシー、速度、法令遵守、オフラインでの可用性がすべて決まるのです。
まったく異なる2つのアーキテクチャ
この違いは、製品の細かな仕様の話ではありません。計算がどこで行われるかという問題であり、それがその後のすべてを決めます。
ARCHITECTURE A — Cloud Validation
══════════════════════════════════
Your Machine Internet Cloud Server
──────────── ──────── ────────────
① Open IFC file
│
│ ② UPLOAD ──────────────────────────────► Server receives file
│ 50 MB → ~40 s at 10 Mbps │
│ 250 MB → ~3 min at 10 Mbps ③ Server parses IFC
│ 1 GB → ~13 min at 10 Mbps │
│ ④ Validation runs
│ │
│ ⑤ RESULTS ◄───────────────────────────────────────┘
│
⑥ View report
Data custody: Your machine → Transit (TLS) → Third-party server
ARCHITECTURE B — Browser-Based Validation
══════════════════════════════════════════
Your Machine Internet
──────────── ────────
① Open IFC file
│
② WASM binary loads (Nothing uploaded.
│ Nothing leaves the device.
③ Web Worker: IFC parsing Ever.)
│
④ 44 validation rules run
│
⑤ Health Score calculated
│
⑥ WebGL renders 3D model
│
⑦ Results: instant, local
OPFS cache: parsed geometry persists → repeat load ~10× faster
Data custody: Your machine only
アーキテクチャAでは、IFCファイルは自分では管理できないインフラで処理されます。ファイルはネットワークを渡り、第三者のサーバー上に置かれ、自分がデプロイしたわけではないソフトウェアによって扱われます。アーキテクチャBでは、同じ検証ロジックがブラウザーの中で動きます。使われるのは、ネイティブのデスクトップBIMツールを支えているのと同じC++コードからコンパイルしたWebAssemblyです。デバイスの外には何も出ず、処理に第三者が関わることもありません。
IFCモデルに機密情報が含まれる理由
IFCファイルをPDFと同じように、どこへでも共有・アップロード・保管してよいものとして扱いがちですが、それは複雑な建物モデルに埋め込まれている情報を過小評価しています。IFCファイルは、資産情報を構造化したデータベースです。多くの種類のプロジェクトにおいて、その情報は実際に機密性が高く、取り扱いが制限されていたり、秘密に指定されていたりします。
官公庁・公共インフラ
裁判所、官公庁舎、データセンター、重要なライフライン設備。構造上の脆弱性に関するデータ、非常用設備のレイアウト、セキュリティ設備の系統図が、IFCのジオメトリやプロパティとして埋め込まれています。
空港・交通ハブ
保安検査場の形状、エアサイドの境界レイアウト、監視カメラ（CCTV）やセンサーの配置、非常用設備の経路。ほとんどの国・地域で、航空保安や国家安全保障上の機密区分の対象になります。
病院・医療施設
患者動線のためのインフラ、医療ガス供給の冗長構成、集中治療室のレイアウト。NHSの情報ガバナンス（IG）要件（英国）やHIPAA（米国）の対象です。生命安全に関わる設備の構造データも含まれます。
鉄道・重要交通機関
トンネルの形状、信号設備、非常時の避難経路、電力供給のトポロジー。国の重要インフラに指定されることが多く、第三者へのアップロードが明確に禁止されています。
産業・プロセスプラント
プロセス機器のレイアウト、危険物を封じ込める設備の形状、安全設備の配置。EUではCOMAH／SEVESO III規制の対象です。商業上の機密にあたるプロセスデータも含まれます。
防衛・軍事
ほとんどの国で、防衛調達規則によって明確に制限されています。軍事インフラのIFCファイルは、特定のセキュリティクリアランスと契約上の承認がなければ、商用クラウドサービスに合法的にアップロードすることはできません。
プロジェクトの種類とは別に、IFCファイルには、複数の法的枠組みのもとで機密とみなされるメタデータも埋め込まれています。STEPファイルのヘッダーにあるFILE_NAMEフィールドには、作成者名と組織名が含まれます。IfcProjectのプロパティには、発注者やプロジェクトの識別情報が入っています。スペース計画のモデルには、在室人数や職員の配置が含まれることもあります。プロパティセットからは、設備の容量、構造仕様、施設の運用特性が読み取れる場合があります。まさに産業スパイに利用されうる種類の情報です。
GDPRとデータの取り扱い
EU一般データ保護規則（GDPR）第4条は、個人データを広く定義しています。識別された、または識別可能な自然人に関するあらゆる情報が含まれます。BIMでいえば、スペースの割り当てに記載された在室者の氏名、IfcProjectのメタデータにある所有者の連絡先、避難計算に使う人員数などがこれにあたります。さらに、ほかのデータセットを通じて特定の個人に結びつく場合は、資産の参照コードが該当することもあります。
実際には、大手のAEC企業（設計・建設会社）や公共機関の多くが、承認されていない第三者のサービスにプロジェクトモデルをアップロードすることを規程上禁止する、データ取り扱いポリシーを定めています。ところが、ポリシーは文書管理システムの奥にしまわれ、検証ツールのURLはコミュニティフォーラムで共有されているため、コーディネーターのレベルではこうしたポリシーが無視されがちです。ブラウザー検証なら、規程を守ることが最も手間のかからない道になります。アップロードするかどうかという判断そのものがなくなるからです。
WebAssemblyはブラウザーのBIMツールをどう変えたか
ブラウザー検証がいまや技術的に信頼に足る理由を理解するには、何が変わったのかを知る必要があります。2017年より前は、本格的なIFCパーサーをブラウザーで動かすことを真剣に検討するBIMソフトウェアベンダーはありませんでした。ブラウザーが実行できるのはJavaScriptだけで、JavaScriptは、ISO 10303-21のSTEP形式を実用に耐える速度で解析するのに向いた言語ではないからです。
WebAssembly以前：2017年より前の状況
- IFCの解析には、サーバー側での処理が必要でした。クラウドの検証ツールは便利だから存在したのではなく、それ以外に実現可能なアーキテクチャがなかったのです。性能面で太刀打ちできる代替手段はありませんでした。
- ブラウザー型のIFCビューアーは、IFCをリアルタイムに解析するのではなく、事前に処理した中間形式（JSONで抽出したジオメトリや簡略化したメッシュ）を使っていました。画面に表示されていたのはIFCそのものではなく、サーバーが生成した近似にすぎませんでした。
- 50MBのIFCファイルを純粋なJavaScriptで解析すると数分かかり、メモリの少ないマシンではタブがクラッシュしました。200MBのファイルとなると、ブラウザー上では事実上不可能でした。
- 3Dレンダリングは初期段階のWebGLでした。GPUで高速化されてはいても、扱えるシーンの複雑さはJavaScriptで処理できる範囲に限られていました。数十万の要素を持つ大規模な構造モデルは、現実的ではありませんでした。
- Web Workerでスレッドを分離することはできても、コンパイル済みのネイティブコードを実行する手段はありませんでした。性能は、JavaScriptのガベージコレクションによる停止と、シングルスレッドの実行モデルによって頭打ちになっていました。
WebAssembly以後：いま可能になったこと
WebAssembly（WASM）は、スタック型仮想マシン向けのバイナリ命令形式で、ブラウザー内でネイティブに近い速度で動作します。C、C++、Rustで書かれたコードをWASMにコンパイルすると、最新のブラウザーであればどれでも、ネイティブのおよそ60〜90%の速度で実行できます。プラグインもインストールも不要で、メモリは完全に分離され、サンドボックスも保証されています。WASMは2019年にW3C標準となり、主要なブラウザーすべてで利用できます。
IFCに関していえば、@thatopen/componentsライブラリが使っているパーサーのweb-ifcは、C++からWebAssemblyにコンパイルされています。IFCのSTEP形式を、ネイティブのデスクトップ向けライブラリと同じクラスの速度で解析できます。50MBのIFCファイルなら、最新のノートPCのブラウザータブ内で、サーバーを一切介さずに10秒未満で解析できます。SolibriやNavisworksがローカルのファイルを読み込むのと同じクラスの性能を、ブラウザーで実現しているのです。
WASM：ブラウザーでC++並みの速度
web-ifcはC++からWebAssemblyにコンパイルされています。IFCのSTEP解析はネイティブの60〜90%の速度で動作し、デスクトップのBIMツールと同じクラスの性能です。50MBのモデルなら、最新のノートPCで10秒未満で解析できます。
Web Worker：本当の並列処理
WASMによる解析は、専用のWeb Worker（OSの別スレッド）で実行されます。重いモデルを読み込んでいる間も、ブラウザーのUIは操作可能なままです。検証は並行して動く別のWorkerで実行されるため、ジオメトリの読み込み中にも結果が得られます。
OPFS：永続的なローカルキャッシュ
Origin Private File System（OPFS）は、ブラウザーにネイティブに備わるストレージAPIです。オリジンごとにサンドボックス化されており、サーバーからはアクセスできません。解析済みのジオメトリは、初回の読み込み後にOPFSへ書き込まれます。2回目以降の読み込みは約10倍速く、再解析も再アップロードも必要ありません。
WebGL／WebGPU：GPUレンダリング
Three.jsがWebGLを抽象化し、高性能な3Dレンダリングを実現します。フラグメントベースのシーン管理により、数十万の要素を持つモデルもインタラクティブなフレームレートで扱えます。次世代のレンダリングに向けて、WebGPUへの対応も予定されています。
OPFSキャッシュ：再読み込みがワークフローを変える理由
Origin Private File Systemは、現在のWebオリジンに限定してサンドボックス化された、ブラウザーネイティブのストレージ層です。ほかのオリジンやほかのブラウザータブ、そして何より重要なことにリモートのサーバーは、その中身にアクセスできません。内容はブラウザーのセッションをまたいで保持されます。IFCのワークフローにおいてOPFSは、重いモデルを扱うツールで最もつらい問題、つまり開くたびに再解析するコストを解消します。
250MBのIFCファイルを一から解析すると、最新のマシンでも20〜40秒かかります。同じファイルをOPFSキャッシュから読み込めば2〜3秒です。同じプロジェクトモデルを1日に何度も開くBIMコーディネーターにとって、OPFSは「速いと感じるツール」と「待たされると感じるツール」の分かれ目になります。さらに、OPFSのストレージはオリジンごとにサンドボックス化され、ローカルのファイルシステム上にあるため、キャッシュされたモデルデータがサーバーに届くことはありません。ブラウザー検証そのものと同じプライバシーの保証が、キャッシュにもそのまま引き継がれるのです。
アップロードというボトルネック：実際の数字
クラウドでのIFC検証で最も過小評価されているコストは、アップロード時間です。製品比較では見えませんが、実際のワークフローでは大半を占めます。一般的なサイズのIFCファイルを、現実的な回線の種類ごとにアップロードするとどうなるか、そしてブラウザーでのローカル処理と比べてどうかを以下に示します。
| IFCファイルサイズ | オフィス（上り10Mbps） | 4Gモバイル（3Mbps） | 現場（1Mbps） |
|---|
| 50MB | 約40秒 | 約2分15秒 | 約7分 |
| 250MB | 約3分20秒 | 約11分 | 約33分 |
| 1GB | 約13分 | 約45分 | 約2時間15分 |
| 2GB | 約27分 | 約1時間30分 | 約4時間30分 |
アップロード時間のみの数値で、これにサーバーでの処理時間が加わります：50MB +5〜15秒 · 250MB +30〜90秒 · 1GB +2〜6分 · 2GB +5〜15分。ブラウザー検証では、どの場合もアップロード時間は0秒です。250MBのモデル：チェック開始までに数分
- ブラウザーでのローカル解析（アップロードなし）: 0.7分 — 最新のワークステーションで初回解析20〜40秒
- オフィスからアップロード（10Mbps）: 3.3分
- 4Gでアップロード（3Mbps）: 11分
- 現場からアップロード（1Mbps）: 33分
サーバー型ツールはアップロード時間のみの数値です。処理にさらに30〜90秒かかります。
中規模の商業プロジェクトの調整用モデルとして典型的な250MBのIFCファイルは、高速なオフィス回線でもアップロードに3分以上かかります。4Gなら11分です。納品前チェックを1日に何度も行うBIMコーディネーターにとっては、アップロード時間だけで週に数時間もの無駄な待ち時間が生じます。検証そのものにかかる時間は、アップロード時間のほんの一部にすぎません。
建設現場では4G回線が当たり前で、帯域は現場事務所とBIM用のタブレットで共有されています。そうした環境で1GBのIFCファイルをアップロードすると、検証ルールがひとつも実行されないうちに45分が過ぎてしまいます。ブラウザー検証なら、同じファイルをネットワークに依存せずローカルで90〜180秒で処理でき、OPFSキャッシュのおかげで次回以降のセッションでは2〜5秒で済みます。
徹底比較：ブラウザーとクラウドのIFC検証
| 観点 | ブラウザー検証 | クラウド検証 |
|---|
| プライバシー | ✅ ファイルがデバイスの外に出ない | ⚠️ ファイルをサーバーにアップロード |
| データ主権 | ✅ 第三者がデータを保管しない | ⚠️ 第三者がデータを保管 |
| GDPR準拠 | ✅ 設計段階から準拠 | ⚠️ DPAと法的根拠が必要 |
| 機密性の高いプロジェクト | ✅ 多くの場合、唯一の選択肢 | ❌ 禁止されていることが多い |
| 速度（50MB未満の小規模） | ✅ ほぼ即時 | ⚠️ アップロードと処理の待ち時間 |
| 速度（250MB超の大規模） | ✅ アップロードの負担なし | ❌ アップロードがボトルネック |
| 再読み込み | ✅ OPFSキャッシュ（約10倍高速） | ❌ 毎回すべて再アップロード |
| アップロード時間 | ✅ ゼロ | ❌ ファイルサイズに比例 |
| オフラインでの利用 | ✅ 完全にオフライン対応 | ❌ インターネット接続が必要 |
| 現場での利用 | ✅ 4Gでもオフラインでも動作 | ❌ 現場では遅く不安定 |
| インターネットへの依存 | ✅ なし（初回読み込み後） | ❌ 実行のたびに必要 |
| バッチ処理 | ❌ 手作業で1件ずつ | ✅ API／バッチで自動化 |
| CI/CDとの連携 | ❌ 不向き | ✅ Webhook／APIを標準で提供 |
| チームの監査証跡 | ⚠️ ローカルのみ | ✅ 履歴を一元管理 |
| 組織全体のレポート | ⚠️ 集約されない | ✅ プロジェクト横断のダッシュボード |
| セキュリティ（データ） | ✅ 通信経路・サーバーのリスクなし | ⚠️ 通信経路とサーバーでの露出 |
| セキュリティ（侵害） | ✅ 侵害されるサーバーが存在しない | ⚠️ クラウド事業者次第 |
| 2GB超の超大容量ファイル | ⚠️ デバイスのRAMに制約される | ✅ サーバーのほうがRAMが多い |
| コスト | ✅ 無料〜低コスト | ⚠️ 従量課金またはサブスクリプション |
| インフラの負担 | ✅ ゼロ（ブラウザーで動作） | ✅ 事業者が管理 |
| 導入の手間 | ✅ URLを開いてファイルをドラッグ | ⚠️ アカウント／APIキーが必要 |
クラウド検証が本当に優れている場面
一方の長所だけを強調する比較は、ただの宣伝です。クラウドでのIFC検証には、特定の状況で確かな利点があります。そうした状況にブラウザー検証を当てはめるのは、判断の誤りです。
自動化されたCI/CDパイプライン
モデルをコミットするたびに検証が自動で実行されます。ソフトウェアの単体テストと同じ考え方です。ヘッドレスな自動化を実現できるアーキテクチャは、Webhookで応答するクラウドAPIだけです。サーバー側のパイプラインには、WASMを動かすためのブラウザーのセッションが存在しません。
ポートフォリオ規模のバッチ処理
過去データの移行や共通データ環境（CDE）のアーカイブ監査のように、プロジェクトのポートフォリオ全体にわたって既存の数百ものIFCファイルを監査する作業は、クラウドのバッチAPIを使えば現実的ですが、ブラウザーで1ファイルずつ手作業で進めるのは非現実的です。
チームのレポートの一元化
BIMマネージャーは、複数のプロジェクトと作成者にまたがる検証履歴（スコアの推移、指摘事項の頻度、準拠状況の経時変化）を、ひとつの画面で把握する必要があります。クラウドサービスはこれを集約します。ブラウザーのツールが出すのは、ローカルの結果だけです。
CDEゲートウェイとの連携
CDEの中には、アップロードされたIFCを受け入れる前に自動で検証するものがあります。これは本質的にサーバー側の処理です。ファイルを処理するのはCDEのサーバーであり、ユーザーのブラウザーではありません。連携の接点になるのは、クラウド検証のAPIです。
ブラウザー検証が最適なケース
- 官公庁・公共部門のプロジェクト
- 防衛・インフラ・空港のBIM
- 病院・医療施設のモデル
- 産業プラント・プロセスエンジニアリング
- GDPRやデータ制限ポリシーの対象となるモデル
- 現場やオフラインでの検証
- クラウドへの正式な提出前の事前チェック
- 個人のコーディネーターや小規模なチーム
クラウド検証が最適なケース
- 自動化されたCI/CD検証パイプライン
- ポートフォリオ全体の一括品質監査
- BIM品質を一元管理するダッシュボード
- CDEゲートウェイと納品の自動ゲート
- 機密性の低い大規模な商業プロジェクト
- 複数チームにまたがる企業のワークフロー自動化
- APIによるほかのシステムとの連携
- ローカルデバイスのRAMを超える超大容量ファイル
ブラウザーでのIFC検証に関する5つの誤解
誤解1：「ブラウザーアプリはクラウドより遅い」
2015年ならそのとおりでしたが、今は違います。WebAssemblyのコードは、最新のブラウザー内でネイティブC++の60〜90%の速度で動作します。IFC解析エンジン（web-ifc）はC++からコンパイルされており、Solibri、AutodeskのIFCインポーター、IfcOpenShellを支えるライブラリと同じ性能クラスに属します。アップロードの待ち時間がゼロであることも合わせると、一般的なサイズのモデルでは、特に上りが50Mbps未満の回線で、ブラウザー検証のほうがクラウドより速いことが少なくありません。
この誤解がなくならないのは、ブラウザーのJavaScript（遅く、ガベージコレクションがある）と、コンパイル済みのネイティブアプリケーション（速い）を比べてしまうからです。最新のブラウザー型BIMツールは、重い処理をJavaScriptでは行いません。コンパイル済みのWASMをネイティブに近い速度で動かし、JavaScriptは処理の流れを制御するだけです。JSとWASMの違いは、PythonとC++の違いに匹敵するほど大きいのです。
誤解2：「IFCファイルを検証するにはアップロードが必要」
これは誤りです。ブラウザー型の検証ツールでIFCファイルを開くと、ブラウザーはローカルメモリ上にFileオブジェクトを作成します。このオブジェクトには、そのブラウザーのコンテキストで動くWASMやJavaScriptからアクセスできますが、コードが明示的にfetchやXHRのAPIを呼び出さないかぎり、どのネットワークのエンドポイントにも送信されません。これは自分で確かめられます。ブラウザーのネットワークインスペクター（F12 → Networkタブ）を開き、モデルを開いて検証してもアップロードが発生しないことを確認してください。
誤解3：「大きなIFCファイルはブラウザーでは扱えない」
最新のブラウザーは、一般的なワークステーションであれば数GBのRAMを確保できます。250MBのIFCファイルがメモリ上で占めるのは250MBで、16GBのマシンでブラウザーのプロセスが確保できる範囲に十分収まります。Web Workerを使えばメインスレッドの外でメモリにアクセスできるため、さらに余裕が生まれます。500MBを超えるファイルでも、空間単位で分割して読み込むことで、メモリの制約が厳しい環境でもブラウザーで処理できます。また、OPFSのおかげで、一度解析した大きなモデルを次回以降のセッションで再解析する必要はありません。
誤解4：「クラウドのほうが常に安全」
セキュリティは単一の属性ではなく、多面的なものです。クラウドサービスは一般に、通信中のデータ（TLS 1.3）と保存中のデータ（AES-256）を暗号化しており、受動的な傍受には対処できています。しかしその一方で、ブラウザーでの処理なら完全になくせる攻撃対象領域を生み出します。サーバー側の侵害、ストレージバケットの設定ミス、クラウド事業者の従業員による内部アクセス、クラウド事業者のインフラに対するサプライチェーン攻撃、そしてサーバーが契約で定められた法域の外にある場合のデータ所在地（データレジデンシー）違反です。
デバイスの外に出ないファイルは、ネットワーク経由の脅威にさらされることが一切ありません。問うべきは「絶対的に見てどちらのアーキテクチャが安全か」ではなく、「このプロジェクトにとって最も重要な脅威モデルは何か」です。国防省の施設モデルであれば、ブラウザーでの処理によって、アップロードという脅威の経路を完全に断てます。一元的なログ管理が重要な、機密性の低い商業プロジェクトであれば、クラウド側の管理機能を選ぶのが妥当なトレードオフかもしれません。
誤解5：「ブラウザー検証はエンタープライズ向けではない」
エンタープライズ品質のソフトウェアを決めるのは、信頼性、機能の充実度、組織として運用・サポートできるかどうかであって、どのようなデプロイ形態をとるかではありません。Figma、AutoCAD Web、Google Earth、Microsoft Office for the Webは、WebAssemblyと最新のWeb APIを使ってブラウザーで動くエンタープライズ向けアプリケーションです。これらを支えているのと同じWASMランタイム、Web Worker、WebGLの基盤が、ブラウザーでのIFC検証も支えています。「ブラウザーベース」とは、計算をどこで行うかというアーキテクチャ上の判断であり、品質の上限を意味するものではありません。
ブラウザー検証のトラブルシューティング
モデルは読み込めるが、検証が遅く感じる
検証は別のWeb Workerで実行されるため、UIをブロックしません。検証がバックグラウンドで動いている間も、3Dモデルは操作できるはずです。読み込み全体が遅く感じる場合は、モデルがOPFSキャッシュから読み込まれている（速い）のか、一から解析されている（大きなファイルでは遅い）のかを確認してください。初回の読み込みでは、ローカルであっても200MBのファイルの解析に20〜40秒かかります。2回目以降のキャッシュからの読み込みは2〜5秒です。
超大容量ファイルでメモリ不足になる
400〜500MBを超えるファイルは、RAMが8〜16GBのマシンではブラウザーのメモリを使い果たすことがあります。症状：ブラウザーのタブがクラッシュする、または応答しなくなる。対処法：ほかのブラウザータブを閉じてメモリを空ける、16GB以上のRAMを搭載したマシンを使う、または統合モデルを分野別のファイルに分けてから読み込む。常に500MBを超えるファイルを扱うなら、クラウド検証のほうが適したアーキテクチャかもしれません。一般に、サーバーのハードウェアのほうがRAMに余裕があるからです。
OPFSキャッシュが次第に肥大化する
OPFSには、読み込んだモデルごとに、解析済みのジオメトリのフラグメントが保存されます。何週間にもわたって多数のモデルを読み込むプロジェクトチームでは、キャッシュが数GBに達することもあります。検証ツールのキャッシュマネージャー（Cache Manager）では、キャッシュされたすべてのファイルとそのサイズを確認でき、個別に削除できます。ブラウザーのストレージ設定から、そのオリジンのストレージをすべて消去することもできます。キャッシュはローカルのデバイスに保存されており、リモートのサーバーからはアクセスできません。
ブラウザーとクラウドで検証結果が異なる
結果が異なる場合、最もよくある原因は、適用されているルールセットが違うことです。ブラウザー検証（44の品質ルール）とクラウドのスキーマ検証（ISO 10303-21への準拠）は、別々のことをチェックしています。同じルールを別の場所で実行しているわけではありません。レベル1のスキーマチェック、レベル2の品質チェック、レベル3のIDSの違いについては、検証レイヤーのガイドを参照してください。IDSの結果であれば、仕様に準拠したエンジン同士で、同じモデルに同じ.idsファイルを適用すれば一致するはずです。
このアーキテクチャにおけるIFC Viewer Onlineの位置づけ
IFC Viewer Onlineは、アーキテクチャBをブラウザーで実装したものです。IFCパーサー（WASMにコンパイルしたweb-ifc）、44ルールの検証エンジン、Health Score（ヘルススコア）の算出、IDS 1.0のチェックエンジン、BCFパネル、3Dレンダラー（WebGL経由のThree.js）は、すべてブラウザーの中で動きます。何もアップロードされません。これは実装レベルで保証されています。そもそも、モデルデータの送り先となるサーバー側のエンドポイントが存在しないのです。
Web WorkerでのWASM解析
web-ifc（C++ → WASM）は専用のワーカースレッドで動作します。大きなモデルの読み込み中もUIは操作可能なままです。50MBのファイルなら10秒未満、200MBのファイルなら20〜40秒で解析できます。最初の結果は、ローカルで得られます。常にです。
再読み込みのためのOPFSキャッシュ
解析済みのジオメトリのフラグメントは、最初のセッションのあともOPFSに保持されます。2回目以降の読み込みは約10倍速く、再解析もネットワークへの依存もありません。キャッシュはブラウザーのオリジン専用で、リモートのサーバーからはアクセスできません。
44の品質ルール＋IDS 1.0
44のモデル品質ルール（モデル構造の整合性、ISO 19650、Pset、分類、LOD、設備（MEP））に加え、bSIの公式テストケース100件すべてで検証済みのbuildingSMART IDS 1.0エンジンを搭載。すべてクライアント側で動作します。
非破壊のプロパティ編集
受け取ったIFCファイルの要素名、プロパティセットの値、GlobalIdを、オーサリングツール（BIMソフト）に戻して往復させることなく編集できます。どのサーバーにもアップロードする必要はありません。
専門家の推奨：適切なアーキテクチャの選び方
ブラウザー検証とクラウド検証のどちらを選ぶかは、ツールの好みではなく、プロジェクト単位のガバナンスに関わる判断です。よくあるシナリオごとの判断基準は、次のとおりです。
- 官公庁、防衛、空港、鉄道、病院、産業プラントのプロジェクト：ブラウザー検証を前提とすべきです。クラウドを検討する前に、所属組織のデータ取り扱いポリシーがモデルのアップロードを認めているかを確認してください。ポリシーに記載がなければ、アップロードは禁止されているものとみなし、データ保護責任者（DPO）に確認しましょう。
- データの機密区分がない商業プロジェクト：どちらのアーキテクチャも選択肢になります。監査証跡の一元管理やCI/CDとの連携が必要ならクラウドを、速度、プライバシーの重視、オフラインでの利用が必要ならブラウザーを使いましょう。
- コーディネーター個人による日々の納品前品質チェック：ブラウザー検証のほうが速くてシンプルで、アカウントも不要なうえ、アップロードの待ち時間もありません。CDEへの正式な提出の前に、ローカルで実行しましょう。
- 多数のモデルにわたるポートフォリオ監査やCDEの準拠状況評価：クラウドのバッチ処理が適しています。200のモデルをクラウドAPIにかけて統合された品質レポートを得るような作業は、ブラウザーでは現実的ではありません。
- CDE内の自動化された納品ゲート：API連携を備えたクラウド検証が、唯一の現実的なアーキテクチャです。サーバー側で自動化されたワークフローには、利用できるブラウザーのコンテキストがありません。
- ハイブリッドなワークフロー：日々の品質ゲートにはブラウザー検証（高速、プライバシーを確保、アカウント不要）を使い、監査証跡、API連携、バッチによる自動化が本当に価値を生むCDEへの正式な提出にはクラウドを使います。この2つのアーキテクチャは補完関係にあります。
よくある質問
ブラウザーでのIFC検証は、本当にプライバシーが守られますか？
はい、正しく実装されていれば守られます。WebAssemblyは、ブラウザーのサンドボックス化されたコンテキストで動作します。IFCデータを含むFileオブジェクトは、ブラウザーのローカルメモリ上に作成されます。そのデータがサーバーに届くには、コードが明示的にネットワークAPIを呼び出す必要があります。正しく実装されたブラウザー型の検証ツールは、IFCファイルについてそのような呼び出しを行いません。ブラウザーのネットワークインスペクター（F12 → Networkタブ）を開き、モデルを開いて検証してもアップロードが発生しないことを確認してみてください。
ブラウザー検証はオフラインでも使えますか？
はい。ただし条件がひとつあります。アプリケーション自体は、少なくとも一度はオンラインの状態で読み込む必要があります。初回アクセス時にWASMバイナリとJavaScriptバンドルがダウンロードされるためです。その後は、プログレッシブWebアプリ（PWA）として完全にオフラインで動作できます。OPFSにキャッシュされたモデルは、ネットワークに接続せずに読み込めます。通信が不安定な現場に行くときは、前日の夜にアプリケーションを読み込み、プロジェクトモデルをキャッシュしておけば、翌日オフラインで使えます。
ブラウザー検証で扱えるファイルサイズの実用上の上限は？
16GBのRAMを搭載したハードウェア（一般的な最新のワークステーションやハイエンドのノートPC）なら、400〜500MBまでのファイルを安定して解析できます。8GBのマシンでは、メモリ不足で動作が不安定になる手前の200〜250MB程度が実用上の上限です。OPFSキャッシュによって再解析のコストはなくなるため、処理の負荷をまるごと負担するのは初回の解析だけです。常に500MBを超えるファイルを扱うなら、クラウド検証のほうが余裕があるかもしれません。
WebAssemblyにセキュリティ上のリスクはありますか？
WASMはJavaScriptと同じサンドボックス環境で動作します。ファイルシステム、オペレーティングシステム、ネットワークにアクセスするにはブラウザーのAPIを経由しなければならず、そこには他のWebコンテンツと同じセキュリティポリシーが適用されます。セキュリティ上問うべきなのはWASMランタイムそのものではなく、アプリケーションがどのようなネットワーク通信を行うかです。そして、正しく実装されたブラウザー型の検証ツールは、IFCファイルについて一切の通信を行いません。
同じプロジェクトのワークフローで、両方のアーキテクチャを使えますか？
はい。多くの場合、それが最も現実的な構成です。コーディネーターは、正式な提出の前の事前チェックとして、ローカルでブラウザー検証を実行します。CDEのゲートウェイでは、監査証跡と自動受け入れのためにAPI付きのクラウド検証を使います。ブラウザーでのチェックは速くてプライバシーが守られ、クラウドでのチェックは公式な記録と組織全体のレポートを提供します。2つのアーキテクチャは異なるニーズに応えるもので、互いに補い合う関係にあります。
まとめ
検証の際にIFCファイルがどこへ行くかは、技術的な細部の話ではありません。AECプロジェクトの大部分において、法令遵守を左右するデータガバナンス上の判断なのです。
IFC Viewerブログ
機密性の高いプロジェクト：ブラウザーを優先
官公庁、防衛、医療、インフラのプロジェクトでは、ブラウザー検証を標準にすべきです。単に便利な選択肢というだけでなく、規定を守れる唯一の選択肢であることも少なくありません。データがデバイスの外に出ることはありません。
自動化とバッチ処理：クラウド
CI/CDパイプライン、ポートフォリオ監査、レポートの一元化には、クラウドのアーキテクチャが必要です。ブラウザーのセッションは、ヘッドレスな自動化ワークフローに参加することも、チームをまたいで結果を集約することもできません。
日々の検証：速度ではブラウザーが優位
アップロード時間はゼロ、再読み込みはOPFSで高速化され、アカウントも不要です。コーディネーターの日々のワークフローの中心となる納品前チェックでは、一般的なモデルサイズであればどれでも、ブラウザーでの処理のほうがクラウドより速くなります。
44の品質ルールが実際に何をチェックしているのか、そしてスキーマ検証やIDSとどう関係するのかについては、IFCモデルチェッカー完全ガイドをご覧ください。品質をひとつの数値にまとめるHealth Scoreについては、IFC Health Scoreガイドを参照してください。受け取ったIFCファイルのプロパティ値やGUIDを、どこにもアップロードせずに修正したい場合は、無料のオンラインIFCエディターが、同じブラウザー優先のアーキテクチャで非破壊のプロパティ編集を実現します。
ブラウザーでのIFC検証かクラウドか：BIMチームが判断を誤りがちなアーキテクチャの選択