タイトル: Speckle と IFC の違い・使い分け
SEOタイトル: SpeckleとIFCの違い｜標準ファイル交換とライブ連携の比較表と併用の現実解
| この記事の要点 |
|
本記事は Speckle カテゴリの一部として、IFC と Speckle の違いと使い分けを整理します。両者は競合ではなく目的が異なる道具で、混同すると設計判断を誤ります。IFC 自体の定義は IFCとは を参照してください。
そもそも何が違うのか
最大の違いは「フォーマットか、プラットフォームか」です。IFC は buildingSMART が定める 標準化された交換フォーマットであり、その実体は1つのファイル（静的なスナップショット）です。Speckle は データを送受信・蓄積・配信するプラットフォームで、ファイルというより「ライブに更新されるデータの流れ」を扱います。
言い換えると、IFC は「決まった器に詰めて受け渡す」もの、Speckle は「常に最新を流し続けるパイプとデータベース」に近い、と捉えると整理しやすくなります。
比較表
| 観点 | IFC | Speckle |
|---|---|---|
| 性質 | 標準フォーマット（ファイル） | データ連携プラットフォーム |
| 標準化 | buildingSMART による国際標準・ISO | OSS の実装（標準規格ではない） |
| データの状態 | 静的なスナップショット | ライブに更新・蓄積される |
| 版管理 | ファイルを別名保存で管理しがち | Version として体系的に管理 |
| プログラム連携 | 読み書きライブラリはあるが手間 | SDK / API で扱いやすい |
| 得意な用途 | 確認申請・長期保存・契約・アーカイブ | 頻繁な更新・自動処理・ダッシュボード |
| 相互運用 | ベンダー中立の長期互換が狙い | 多ツール間のライブ連携が狙い |
IFC が強い場面
IFC は国際標準として安定しており、特定ベンダーに依存しないことが価値です。次のような「正本・記録」を残す用途に向きます。
- 確認申請・行政手続きなど、決まった形式での提出が要る場面
- 長期保存・アーカイブ：数十年後も読めることが重要な記録
- 契約・納品の成果物として、合意された静的スナップショットを残す
「この時点の合意内容」を固定して残す性質は、ライフサイクルの長い建築（BIM総論）と相性がよい部分です。
Speckle が強い場面
Speckle は更新・連携・自動化に強みがあります。
- 設計中の頻繁な更新を、版を追いながら共有したい
- SDK / API でデータを取得し、集計・QA・ダッシュボードに使いたい
- 複数ツール（Revit・Rhino など）の間でデータをライブに行き来させたい
プログラマブルである点が大きく、データ取得は specklepy や .NET SDK、自動チェックは Automate といった形で組み合わせられます。
併用という現実解
実務では「どちらか」ではなく併用が現実的です。たとえば次のような役割分担が考えられます。
- 進行中：日々の設計連携・レビュー・自動チェックは Speckle で回す
- 節目・提出：確認申請や納品の段階では IFC を正本として書き出す
- 長期保存：将来も読めるアーカイブとして IFC を残す
Speckle 側にも IFC を扱う仕組みがあり、両者を橋渡しする運用が取れます（本記事の前提として、対応の詳細は版に依存します）。
注意点：標準と実装は別物
どちらを使うにせよ、「標準どおりに書き出した／読み込んだ」ことと「相手ツールで意図どおり開ける」ことは別問題です。IFC でもツールごとに対応範囲や解釈に差があり、Speckle でもコネクタごとに変換できる属性・形状に差があります。重要なデータ受け渡しの前には、実際のツールの組み合わせで往復検証（送って戻して崩れないか）を行うことを勧めます。設計判断としては、目的（記録か連携か）から逆算してどちらを正本にするかを決めるのが筋の良いやり方です。