検証項目: MCPツール12種のstdioでの実行、ドキュメント記載内容と実装の一致、SVG出力の目視確認、npmパッケージ内容の確認。
ロードマップ
開発ロードマップです。今後、Koyuのビジョンを実現するためにやっていきたいことを書いています。カードを選択すると詳細を表示します。
最終更新 · 2026年7月
01
コア基盤
現在、台帳は実装の内部にのみ存在します。機械可読な出力があれば、外部ツールは検査ルールを再実装せずに共有できます。
壁・スラブ・階段・扉位置・接続グラフは導出済みですが、現在はTypeScript APIからのみ取得できます。シミュレータやビューアが直接読める出力を追加します。
02
生成とシミュレーション
訓練用の建物を大量に用意する方法は、今のところどれも問題を抱えています。BIMで手作りするのは遅すぎ、合成生成器は見た目は建物でも間取りとして成立しておらず、実在の図面は権利の整理が要るうえラベルがありません。
koyuでは、どの室が何の用途か、どの扉を通れるか、どの境界が何分耐火かは、幾何から推定した値ではなく書かれた事実そのものです。したがって正解ラベルが間違いようがありません。checkが不成立を弾き、validateが建築として成立しているかを採点します。
出力はシミュレータが読む形式を直接生成します。汎用の交換形式は経由しません。
完了条件1,000棟を生成して全棟がcheckを通り、8割以上がvalidateで違反ゼロ、生成した経路グラフで外部の経路計算が動き、同じ.muroから同じ形状が再現されること。
接続グラフと扉のデータはモデル内に揃っています。足りないのは、特定の計算機が読む形に整えることだけです。
汎用の交換形式は経由しません。最初の利用者を一つ決め、その相手が読む形式を出します。二つ目が現れてから共通化を考えます。
完了条件実在の避難シミュレータがkoyuの出力をそのまま読み込み、経路と避難時間を算出できること。
細分化された境界は.muroソースには追加しません。出力側で導出します。
03
測地参照と法規計算
これは書き出しのためではなく、koyu自身が計算するための機能です。日影規制も斜線制限も、設計者が今日答えなければならない問いで、真北と方位が分からないと計算できません。
座標系はEPSGコードで指定し、日本では平面直角座標系を使います。モデルがmmの直交グリッドなので、緯度経度より素直に載ります。
運搬層の名前空間付き属性として敷地のzoneに書きます。coreは測地座標を解釈する必要がなく、読むのは判定と作図の側だけなので、言語の版も属性台帳も動きません。記述の不備はvalidateが判定として報告します。
完了条件真北を与えた敷地で日影の計算結果が手計算と一致し、測地参照の記述漏れをvalidateが報告すること。
これは外部の誰かのための書き出しではなく、ユーザーが今日困っていることへの回答です。基本計画の段階で答えが出れば、変更がまだ安いうちに形を直せます。
coreは数値の算出のみを行い、合否の基準値はvalidate側に置きます。判定の追加で言語の版は動きません。
完了条件日影の計算結果が手計算と一致し、斜線の判定が既存の設計例で妥当な結果を返すこと。
CityJSONには階・室を直接表すオブジェクト型があり、koyuの空間モデルはそのまま載ります。測地参照の実装が前提です。
ただし「都市データと繋がる」だけでは着手の理由になりません。何を問うために都市の座標系に載せるのかが決まってから作ります。
04
IoT・デジタルツイン連携
時系列データは.muroには保存しません。外部のデータベースが、パス（またはuid）をキーとして計測値を空間に紐づけます。
BMS連携で必要になった時点で、パス階層とは別の明示的な所属記述として設計します。現時点では未着手です。
05
外部形式への書き出し
BOT・IndoorGML・CityJSONはいずれも「受け取る側の形式」で、誰かがkoyuのデータを待っているという前提の上に乗っています。調べた限り、まだ誰も待っていません。
使われない書き出しが増えるほど、保守する範囲が広がります。一棟がLLMのコンテキストに収まることも、差分が人に読めることも、記述量が少ないことに依存しています。ここを失うと目的そのものが壊れます。
したがって順序を逆にします。解きたい問いと、それを解く相手のソフトウェアを先に決め、その入力形式へ直接出力する。二つ目の相手が現れたときに初めて、共通化を検討します。
koyuのboundaryは、二つのゾーンの界面であるbot:Interfaceと同じ構造です。ここまで綺麗に対応する語彙は他にありません。
ただしBOTはW3Cの勧告ではなくコミュニティグループの草案で、設備管理やデジタルツインの実務では使われていません。2026年の建物オントロジー比較論文でも、比較対象はBrick・RealEstateCore・Haystack・Google Digital Buildingsで、BOTは入っていません。
一方その論文は、4つとも空間のトポロジー表現力が弱いと指摘し、その用途にはBOTの再利用を推奨しています。つまりBOTは競合ではなく、ツイン側が持っていないトポロジーの担当です。これは対応する意味がある位置づけですが、デジタルツイン連携そのものではありません。着手は、BOTを実際に要求する相手が現れてからにします。
完了条件doorsコマンドと同じ経路質問にSPARQLで回答できること。
koyu本体の語彙は追加しません。対応表は.muroのレイヤーとして管理します。
IndoorGMLはOGCの正式標準で、中核は屋内空間のトポロジーと経路網です。koyuの空間グラフはその双対グラフそのもので、対応づけは自然です。
しかし本番で使われている例をほとんど確認できませんでした。研究論文は「実用的なツールの不足により生成が難しく、事実上入手できない」と述べており、屋内地図の実務で動いているのはIMDF（Apple作、GeoJSON基盤、OGCコミュニティ標準）です。
経路計算や避難シミュレーションが目的なら、その計算機が読む形式へ直接出力する方が速く、途中にIndoorGMLを挟む理由がありません。相手が明示的にIndoorGMLを求めた場合にだけ意味を持ちます。
完了条件同一建物への経路計算の結果が、koyuとIndoorGML側で一致すること。
IFC→koyu→IFCのラウンドトリップは対象外です。取り込み対象は空間構造・境界・属性で、形状表現は取り込みません。
06
対象外
形状はグリッド参照と境界の関係から導出されます。スキャンや点群から取得できる形状データと、ソースの役割を分けるための設計です。
.muroが保持するのは、空間の構成・関係・識別子です。
ソースファイルを唯一の原本とするためです。編集は常に.muroに対して行います。
koyuの対象範囲は、基本計画〜基本設計の空間構成です。詳細設計はBIMツールの領域とします。