空間中心のモデル

建築が扱っているのは、壁や床や天井そのものではなく、それらが生み出す空間である。ところが建築のデータは、一貫して「建てるべき物」の記述であり続けた。koyu は順序を逆にする — 室を数え上げれば、その間の壁は付いてくる。

この頁はその転回が何であり、なぜそれが自然なのかを説明する。記法の詳細は space にある。

三十年、誰も「読み」をデジタル化しなかった

平面図は、本来は構成の記述である。線と記号が空間の切り方と繋がり方を伝え、読み手は頭の中で空間を再構成する。図面の内容とは、この読みのことだった。

デジタル化の歴史は、この読みを一度も捉えていない。

• CAD は図面の線を捉えた。意味は紙の時代と同じく読み手の頭に残った
• BIM は意味を持たせた。ただし意味を取り付けた先は三次元の部材ソリッドだった。空間は、部材が囲んだ結果として後から導くものになった

IfcSpace が IFC の規格に存在しながら、実務では書き出されないことも珍しくない二級市民であり続けているのは、この順序の帰結である。物の表現ばかりが精緻になり、読みは誰もデジタル化していない。

形を原本にしたことの症状は三つある。

データがツールに閉じる。原本がオーサリングツールの独自データベースにある限り、モデルにできることはそのツールの UI と API が許す範囲に限られる。

版が管理できない。行番号で相互参照する形式では、書き出し直すだけでファイル全体の差分が壊れる。どのファイルを最新とみなすかは、データではなく人の運用が決めることになる。

外の世界と繋がらない。オントロジーもデジタルツインも都市データも、必要としているのは空間とトポロジーと意味であって、ソリッドではない。部材の集合からそれらを毎回抽出し直すことが、接続のたびに個別の統合作業を発生させる。

逆にするとどうなるか

データの一次要素を空間にする。室・ゾーン・外部の領域。壁はそれ自体が独立した物ではなく、二つの空間の境界という関係として持つ。開口は境界に開いた接続である。

次の 4 行が、整合し、平面図まで描ける最小のファイルである。

grid X 0 3600
grid Y 0 4000
level L1 0 h:2400 slab:150
space /L1/a room X1..X2 Y1..Y2

✔ Consistent — 1 space / 0 boundaries
  Structural consistency only — architectural validity is what koyu validate says, separately

koyu 1.0 も unit mm も name も要らない。必要なのは、grid が二軸あること、それを使う行より前にあること、level が宣言されていること、space に型が付いていることだけである。座標は直接書かない — 位置は常に通り芯の言葉で書く (位置の書き方)。

室を一つ足す。境界は一行も書かない。

grid X 0 3600 7200
grid Y 0 4000
level L1 0 h:2400 slab:150
space /L1/a room X1..X2 Y1..Y2 name:居室A
space /L1/b room X2..X3 Y1..Y2 name:居室B

✔ Consistent — 2 spaces / 1 boundary
  Structural consistency only — architectural validity is what koyu validate says, separately

境界を書いていないのに「境界 1」と出る。二室が接しているので、その間の壁が導かれている (既定の境界)。

space 行だけのファイルが、欠けた図面ではなく完全な建築の記述である。これがこの記法の出発点である。

データが自然にグラフになる

空間を節点、境界を辺にすると、建築のデータはそのままグラフになる。設計で問われることが、変換なしにグラフへの問いになる。

npx tsx src/cli.ts graph examples/two-rooms.muro

/L1/a (居室A)
  — 1 door → /L1/b  (spec:PW1)
  | wall → /out  (spec:EW1 fire:60)
/L1/b (居室B)
  — 1 door → /L1/a  (spec:PW1)
  — 1 door → /out  (spec:EW1 fire:60)
/out (外部)
  | wall → /L1/a  (spec:EW1 fire:60)
  — 1 door → /L1/b  (spec:EW1 fire:60)

「この室とこの室は繋がっているか」「この境界は耐火か」「ここからここまで扉をいくつ通るか」に、抽出作業なしで答えられる。

npx tsx src/cli.ts doors examples/two-rooms.muro /L1/a /out

2 doors — /L1/a → /L1/b → /out

部材モデルで同じ問いに答えるには、空間 → 空間境界 → 壁 → 開口の関係 → 建具、と何段も辿った上で、なお「その扉がどの空間とどの空間を繋ぐか」はデータに無いので幾何から推定することになる。避難も面積も区画も動線も、koyu では同じ記述の異なる読み方である。

抽象度は新しくない

構成のほとんどは二次元で決まる。平面の割り付け、隣接、動線。そこにレベルと高さ、吹抜けや階をまたぐ関係が乗る。これで直交グリッドの建物は決まる。

重要なのは、これが新しい抽象化ではないことである。図面が数百年運んできた抽象度そのものを、紙から機械可読なテキストへ移しているだけである。実務の成果物が今なお図面であり、確認申請が図面で行われているのは、建築の決定がこの抽象度でなされているからである。

だから空間を一次にすることは、情報を捨てる操作ではない。捨てられているのは形であって、形は決定の帰結である。決定の側を原本にした、というのがこの選択である。

空間だけで建築のすべてが書けるとは言わない

構造と設備は、空間ではなく物が主役である。柱、梁、ダクト、盤。空間を一次にしたモデルは意匠と計画の側に強く、構造と設備は物を持つ別の層として重ねることになる。

柱だけは例外的に扱いが定まっている — 位置を書かない要素として、通り芯の交点と床の交わりから現れる (column)。壁が境界から現れるのと同型の規則を、点の要素に適用したものである。

境界が曖昧な場所も残る。吹抜け、半屋外、外部空間。IfcSpace が実務で機能しにくい理由の一つもここにあり、koyu はこれを逃げずに決めている — 半屋外は宣言ではなく導出である (導出される情報)。

粒度も自明ではない。室で切るのか、ゾーンで切るのか、両方を持つのか。koyu の答えは「両方を持ち、パスが両者を繋ぐ」である (パスと面積集計)。

この先

• 境界による壁の表現 — この転回の直接の帰結
• 既定の境界 — 既定の三段構え
• 導出される情報
• space の書き方