IFC・USD との比較
空間をノード、境界を関係とするモデルは新しくない。W3C BOT の bot:Space と bot:Interface、IndoorGML のセル空間と双対グラフ、IFC の IfcSpace と IfcRelSpaceBoundary は、どれも近い形をしている。合成の仕組みは USD が持つ。
近さは隠すべき弱点ではなく、設計上の狙いである。近い形をしているからこそ、それらへの射影が自明になる。新規性は個々の要素にではなく、それらを同時に備えていることにある。
用語に馴染みが無ければ BIM・IFC・USD の基礎 を先に読む。
立ち位置の違い
| 既存の形式 | koyu | |
|---|---|---|
| 立ち位置 | 部材モデルや CAD から派生する射影・交換形式 | 人と機械が直接書く原本。派生元を持たない |
| 大きさ | 一棟が機械の視野に入らない | 一棟が丸ごと入る |
| 合成 | 建築の意味論を持つ形式は合成を持たず、合成を持つ形式は建築の意味論を持たない | 両方を持つ |
| 同一性 | ファイル内の識別子。時点をまたぐ保証は形式の外 | 不変の同一性が第一級 |
同じ二室を三つの世界で書く
同じ場面 — 3.6m×4.5m の室二つ、界壁の扉、玄関、腰窓 — を、IFC4 (SPF) と IFCX (IFC5 alpha) でも書いた。すべて同梱してある。
トークンは o200k_base で実測した。LLM が読み書きする単位で測り直すのがこの表の目的である。
| 形式 | バイト | 行 | トークン | 対 DSL |
|---|---|---|---|---|
| koyu DSL (原本、注釈込み) | 916 | 26 | 359 | 1.0x |
| koyu DSL (注釈を除いた本文) | 496 | 16 | 220 | 0.6x |
| koyu 正準 JSON (機械形式) | 2,164 | 140 | 729 | 2.0x |
| IFC4 (理想化最小、手書き) | 7,291 | 152 | 3,379 | 9.4x |
| IFCX (IFC5 alpha) | 20,111 | 1,030 | 6,034 | 16.8x |
IFC4 の 152 行は徹底的にごまかした理想化最小である。プロパティセット・材料・スタイル・所有履歴・接合処理を全部落とし、形状は矩形押し出しのみ、名前は ASCII のみ。それでもこの量になるのは、壁 5 枚・開口 2・扉 2 をそれぞれ物として置き、プロファイル → 押し出し → 形状表現 → 配置の階段を要素ごとに登る必要があるからである。空間は IfcSpace として 2 つ入れ、IfcRelSpaceBoundary を 8 本手で張ったが、境界の接続ジオメトリは省略した — 実務の書き出しで最も欠落しやすいのがまさにここである。
IFCX の 1,030 行のうち大半はメッシュ座標である。形式は JSON になり、レイヤー合成という強力な機構を得たが、場面の原本がビルド成果物を抱えて肥大する構造は変わらない。主語も依然 IfcWall である。
どちらも、トークンの過半が「形は生成物」が原本から追放した層に費やされている。
参考として、buildingSMART の IFC5 開発リポジトリにある hello-wall は、壁 1 枚 + 窓 2 つの場面で .ifc が 79KB、.ifcx が 43KB ある (オーサリングツール経由の現実的な出力)。実務モデルなら数十 MB になる。
問いに答えられるか
「a から外へ扉をいくつ通るか」に IFC で答えるには、IfcSpace → IfcRelSpaceBoundary → IfcWall → IfcRelVoidsElement → IfcOpeningElement → IfcRelFillsElement → IfcDoor と 5 段以上の関係を辿り、なお「その扉がどの空間とどの空間を繋ぐか」はデータに無いので幾何から推定する。
npx tsx src/cli.ts doors examples/two-rooms.muro /L1/a /out
2 doors — /L1/a → /L1/b → /out構成が原本なので、グラフへの問いと差分と生成が無料になる。代わりに形は直交グリッドの生成規則が届く範囲しか出せない。これは対称なトレードオフではない — 設計の決定は構成の側でなされ、形は決定の帰結だから、というのがこの賭けである。
桁を上げて測る
同じ物差しで、同梱のショーケースを測った。
| tower | complex | twin | |
|---|---|---|---|
| 延床 (屋内) | 4,785.92 ㎡ | 31,606.24 ㎡ | 141,448.56 ㎡ |
| 空間 | 178 | 425 | 1,808 |
| 境界 | 543 | 1,364 | 5,973 |
| 原本の行 | 453 | 646 | 1,220 |
| 原本のバイト | 21,227 | 33,284 | 64,961 |
| 原本のトークン (o200k) | 8,574 | 12,685 | 26,630 |
| 正準 JSON のトークン | 74,704 | 137,913 | — |
床面積が 6.6 倍になって、原本は 1.48 倍にしかならない。
理由は建築そのものの性質にある。複合建築は繰り返しでできているので、レベルスパン (/B2..L19/) と帯 (band) が繰り返しを丸ごと畳む。complex では、コア (2 階段・2 EV バンク・便所・PS・給湯) の B2 から L19 まで 21 レベル分が 9 本の space 行、ホテルの 84 空間が 13 本の帯の要素、基壇の 92 空間が 16 本の帯の要素、事務所 7 層の 21 空間が 3 行である。
原本の大きさは「建物の大きさ」ではなく「設計判断の数」に比例する。
これは記法の性能ではない。大きい建物が大きいのは、違うものがたくさんあるからではなく、同じものがたくさんあるからである。
上の倍率をそのまま当てれば、complex 相当のものは IFC4 で約 12 万トークン、IFCX で約 21 万トークンになる。しかもこの倍率は「徹底的にごまかした理想化最小の IFC」に対するものである。実務のオーサリングツールがこの規模で書き出す IFC (数十 MB) は、どのコンテキストにも載らない。
BOT — 形が近いので射影が自明になる
W3C の Building Topology Ontology は、koyu と同じ形をしている。bot:Space、bot:adjacentZone、そして bot:Interface — 二つの Zone の界面。
koyu の boundary は、bot:Interface の、人が書ける表面記法だと言ってよい。空間 = bot:Space、垂直の階層 = bot:Storey、境界 = bot:Interface、隣接 = bot:adjacentZone へ、正準 JSON から一方向に射影できる。
これは「乗り換える」話ではなく「説明させる」話である。W3C 系の既存語彙に自分を説明させることが、オントロジー上の位置づけそのものになる。
USD — 借りるのは機構だけ
OpenUSD からは機構だけを借りている。
| 借りるもの | 借りないもの |
|---|---|
| パス名前空間を背骨にしたレイヤーの非破壊的な重ね合わせ | UUID を主キーにした同一性 (koyu は人間可読パス) |
| 名前空間つきの語彙 | メッシュの同梱 (形は生成物) |
| 外部レイヤー参照の発想 | バリアント (案の分岐は git のブランチが持つ) |
そして USD には建築の意味論が無い。空間と境界と用途と階を、USD の側から与えることはできない。
建築の意味論を持つ形式は合成を持たず、合成を持つ形式は建築の意味論を持たない。
koyu の主張は、両方を持てるというところにある (ファイル分割と重ね合わせ)。
相互運用の方針 — 出口は作る。往復は作らない
作る — 安定した機械形式 (版つき)、外部参照の鍵としての同一性、グラフの出力、読み取り専用の射影。
作らない — 往復互換、外部形式の完全な取り込み、カバレッジの主張、他形式との大きさの比較の追求。必要なのは「一棟が入る」という絶対値であって、比較ではない。
外に置く — 既存資産からの取り込みは、一方向の変換として核の外に置く。
IFC が肥大化したのは、どのツールが吐いたものも失わずに戻せることを要求されたからである。その要求を受けない、というのがこの方針である。
再現
比較のファイルは同梱してある。
npx tsx examples/comparison/gen-ifc4.ts > examples/comparison/two-rooms.ifc
npx tsx examples/comparison/gen-ifcx.ts > examples/comparison/two-rooms.ifcx
npx tsx examples/comparison/validate-ifc.ts examples/comparison/two-rooms.ifc
UUID と GUID は名前から決定的に導いているので、生成し直しても差分は出ない。