Koyuと.muroを始めた理由

01 / 最初の問い

LLM時代の建築は、何によって記述されるべきか。

このプロジェクトは、事業計画や「業界には新しいファイル形式が必要だ」という主張から始まったのではありません。頭から離れない、個人的な問いから始まりました。

いつかLLMが読み書きする原本として、IFCに代わりうる体系を設計するとしたら、それは何を記述するのだろう。

LLMは、関係するソース、制約、意図を一つのコンテキストで見られるときに力を発揮します。従来の建物モデルは非常に豊かですが、その豊かさゆえに、モデル全体を一つのテキストとして保持し、検討し、修正することは難しくなります。

02 / IFCへの敬意

共有された大きな成果と、別の問い。

IFCは、建築に関わる分野やツールが建物情報を交換するための共通基盤を築いた、並外れた共有成果です。Koyuは、積み重ねられてきた数十年の仕事を退けようとしているのではありません。

この思考実験で問題になるのは、IFCをLLMが直接編集する原本として扱う場面です。実際のファイルは、部材、配置、座標、形状といった、建物が何であるかを説明するオブジェクトとジオメトリの比重が大きくなります。意味や関係も保持できますが、記述の中心は完成した出力側にあります。

この実験の言葉でいえば、それは建築を書くというより、建物を記述することに近い。形状は壁がどこにできたかを示せますが、なぜ二つの室が接するのか、その境界が何を担うのか、どこを通れるようにしたかったのかまでは、必ずしも残しません。

03 / 発想の転換

意図を書く。形状はビルドする。

Koyuは、ジオメトリを原本から出力へ移します。原本に記述するのは、空間の識別、隣接、包含、境界、開口、通過、レベルです。コンパイラがそこから平面、3D、集計、寸法、交換形式を導きます。

建築の原本
  = 空間
  + 関係
  + 境界
  + 通過
  + レベル

建物の形状
  = build(建築の原本)

座標や精度をなくすのではありません。役割を変えます。座標は検査、交換、詳細調整のために利用できますが、モデルの最初の一文ではなくなります。

04 / 一つのコンテキスト

一棟を、LLMが保持できるテキストへ。

.muroは、この発想から生まれた簡潔なソース形式です。レベル、空間、境界、扉、窓、インポート、垂直方向の積層を短いテキストで記述します。人とLLMの編集は、同じようにレビューできる差分になります。

現在の比較では、同じ理想化した二室の場面が.muroでは241トークン、意図的に最小化したIFC4では3,379トークンとなり、差は14倍です。11階・延床4,786㎡の例も、.muroでは8,099トークンに収まります。

これは普遍的なベンチマークではありません。形状を繰り返し保存せずビルドすることで、建築の記述を一棟まとめて検討できる大きさに保てる可能性を示す比較です。