koyu と IFC の実測比較
同じ二室 — 3.6m×4.5m の室が二つ、界壁の扉一枚、玄関一枚 — を、.muro と IFC4 (SPF) と IFCX (IFC5 alpha) で書いたものが examples/comparison/ にある。形式の巧拙を競う比較ではない。記述の主語を「建築物 (物)」から「建築 (空間)」に取り替えると何が起きるかを、行数とバイト数とトークン数で測るためのものである。
測った結果
LLM が読み書きする単位 (o200k_base) での実測。
| 形式 | 主語 | 行 | バイト | トークン | 対 .muro |
|---|---|---|---|---|---|
.muro (原本) | 空間と境界 | 18 | 394 | 178 | 1.0x |
| koyu 正準JSON | 同上 | 116 | 1,696 | 587 | 3.3x |
| IFC4 (理想化最小) | 部材 | 152 | 7,291 | 3,379 | 19.0x |
| IFCX (alpha) | 部材＋メッシュ同梱 | 1,030 | 20,111 | 6,034 | 33.9x |
.muro の行は、IFC 版と同じ場面に揃えたものを測っている。同梱の examples/two-rooms.muro は窓を二つと daylight:1 を余分に持つので 26行 / 916バイト / 359トークンあり、IFC 版はそれらを持たない。多く運んで、なお9分の1である。
トークンは何に費やされているか
- IFC4 の 57% は幾何・配置系のエンティティである。プロファイル → 押し出し → 形状表現 → 配置という階段を、壁5枚・開口2・扉2それぞれについて登る必要がある。
- IFCX の 44% は、数値しか載っていない行である。メッシュ座標配列がそれで、バイトで見れば7割を超える (JSON の構造キーの方がトークン単価が高いので、トークン比では下がる)。
つまりどちらも、トークンの過半が「形は生成物である」という立場が原本から追放した層に費やされている。
答えられる問いが違う
「a から外へ扉を何枚通るか」を IFC4 に訊くには、Space → RelSpaceBoundary → Wall → RelVoids → Opening → RelFills → Door と5段の関係を辿った上で、なお「その扉がどの空間とどの空間を繋ぐか」がデータに無いので幾何から推定することになる。
.muro では一行である。
npx tsx src/cli.ts doors examples/two-rooms.muro /L1/a /out
2 doors — /L1/a → /L1/b → /outこれは形式の優劣ではなく、主語の違いの帰結である。IFC4 も IFCX も形が原本なので任意の形状を運べるが、構成 (どの空間がどう繋がるか) は関係の網から掘り出すか幾何から推定するしかない。koyu は構成が原本なのでグラフへの問いと差分と図の生成が無料になるが、形は直交グリッドの生成規則が届く範囲しか出せない。対称なトレードオフではない。
IFC4 版の中身
examples/comparison/two-rooms.ifc の152行は、徹底的にごまかした理想化最小である。プロパティセット・材料・スタイル・OwnerHistory・接合処理を全部落とし、形状は矩形押し出しのみ、名前は ASCII のみ。空間は IfcSpace として2つ入れ、IfcRelSpaceBoundary を8本手で張ったが、境界の接続ジオメトリは省略した — 実務の書き出しで最も欠落しやすいのがまさにここで、IfcSpace 自体が書き出されないことも珍しくない。
読めることは検証済みで、IfcWall×5 / IfcSpace×2 / IfcDoor×2 / IfcOpeningElement×2 / IfcRelSpaceBoundary×8 が取り出せ、ブーリアン込みで7つのメッシュが組み上がる。
参考として、IFC5-development の hello-wall は壁1枚＋窓2つの場面で .ifc が79KB、.ifcx が43KB ある (オーサリングツール経由の現実的な出力)。実務モデルなら数十MBになる。
IFCX 版の中身
examples/comparison/two-rooms.ifcx は hello-wall.ifcx の流儀 (UUID パス、children による階層、bsi::ifc::class による分類、usd::usdgeom::mesh の同梱) に倣って生成した。形式は JSON になり、レイヤー合成という強力な機構を得たが、場面の原本がビルド成果物 (メッシュ) を抱えて肥大する構造は変わらない。主語も依然 IfcWall である。開口のブーリアンは省略し、扉を壁の子の箱として置いた近似なので、alpha 仕様への厳密な準拠は保証しない。
桁を上げても載る
同じ物差しで大きい例を測る。
| 例 | 屋内床面積 | 空間 | 境界 | 原本トークン | 正準JSONトークン |
|---|---|---|---|---|---|
| tower | 4,785.92㎡ | 178 | 543 | 8,574 | 74,704 |
| complex | 31,606.24㎡ | 425 | 1,364 | 12,685 | 137,913 |
| twin | 141,448.56㎡ | 1,808 | 5,973 | 26,630 | 450,040 |
床面積が 6.6倍 になって、原本は 1.48倍 にしかならない (tower → complex)。原本の大きさは建物の大きさではなく設計判断の数に比例するからで、複合建築は繰り返しでできている。レベルスパンと帯と stack がその繰り返しを丸ごと畳む。
倍率をそのまま当てれば、complex 相当の一棟は IFC4 で約13万トークン、IFCX で約24万トークンになる。しかもこの倍率は「徹底的にごまかした理想化最小の IFC」に対するものであって、実務のオーサリングツールが書き出すこの規模の IFC (数十MB) はどのコンテキストにも載らない。
一棟を LLM の一つのコンテキストに置けるかどうかが、この主語の取り替えで桁ごと変わる。しかも複合建築の全体が文脈に載ったうえで、一つの階を書き換えるのに触るのは一枚のレイヤーだけで済む。
再現
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 は名前から決定的に導いているので、生成し直しても差分は出ない。トークン数は o200k_base (GPT-4o 系トークナイザ) による実測で、cl100k_base でもほぼ同値になる。
用語
IFC・IfcSpace・IFC5 / IFCX・OpenUSD・BIM といった koyu の外の語の定義は用語集の末尾にある。「建築」と「建築物」を日本語が区別することの意味も、そこに書いてある。