こんにちは、武田そらです。普段は ArchyBase で生成系 AI と空間推理まわりのパイプラインを触っています。今日は、チームで作っているもう一つのプロダクトの 無料の平面図メーカー を題材に、「きれいな平面図が出た」あとに DXF / SVG / PDF へ落とす前に、何を確認するか を書きます。
間取りの見た目は合っていても、書き出しファイルは別物です。ブラウザ上のピクセルと、CAD や BIM に渡す線分では、失敗の見え方が違います。Qiita らしく、実装・検証のチェックリストとしてまとめます。
なぜ「見た目 OK」と「書き出し OK」が分かれるか
無料の平面図メーカー系の UI は、だいたい次の三層を持っています。
- 編集用の内部表現：壁・部屋・開口をノード／エッジ／ポリゴンとして持つ
- 画面への描画：線幅や塗りを見やすくしたビューポート
- 書き出し：DXF / SVG / PDF など、別座標系・別単位系への変換
デモで映えるのは 2 です。現場や次工程に渡すのは 3 です。2 がきれいでも、3 で単位がずれたり、壁が「芯」基準のままクリア幅になっていなかったり、ドアがポリラインから落ちたりする——というのが、よくある事故です。
FloorAI の平面図メーカーは、ブラウザ上で間取りを編集して書き出せる系統の機能です。以下は特定ベンダーの内部リークではなく、同じ系統のツールを検証するなら、私ならこう見るという整理です。数値の速さや精度保証は書いていません（書いていないものを記事側で作らない、という最低ラインです）。
確認 1：単位（px / mm / m）とスケールの対応
最初に崩れるのは単位です。
| レイヤ | よくある実体 | 落とし穴 |
|---|---|---|
| 画面 | CSS px / キャンバス単位 | 「見た目の長さ」と実寸が一致しない |
| 内部モデル | 無名の float、または mm 前提 | どこで実寸に乗算するかが曖昧 |
| DXF | 単位フラグはあるが、解釈は受信側依存 | INSUNITS と実際の数値が食い違う |
| SVG | user unit + viewBox | 印刷時に「何 mm か」が消える |
| ポイント系 | 図面として開くとスケール感がずれる |
実務でやる確認はシンプルです。
- 既知の寸法を一本だけ入れる。 たとえば壁の長さを「3000」と明示できるなら、書き出し後にその辺の長さが何になっているかを測る。
- 同じ図を DXF と SVG の両方で出す。 相対比が一致していても、絶対値が一致しないことがある。比だけ見て「大丈夫」と判断しない。
- 受信側アプリの単位設定を固定する。 DXF を開く側が mm 前提か m 前提かで、十倍・千倍ズレは一瞬で起きます。
「見た目がスケール感ある」は、単位が正しいことの十分条件ではありません。書き出し前に、一本の基準辺で絶対値を突き合わせる習慣を付けるだけで、後工程の手戻りはかなり減ります。
確認 2：壁芯寸法か、内法（クリア幅）か
二番目は、寸法の定義です。建築・インテリアの会話では、同じ「この部屋の幅」でも指している線が違います。
- 壁芯（centerline）：壁厚の中央を結んだ寸法。プランニングや構造検討でよく使う
- 内法（clear / interior）：仕上がり面から仕上がり面までの有効幅。家具配置や法規寄りの確認で重要
ブラウザの平面図メーカーは、描画を簡潔にするため壁を単線（芯線）で持つことが多いです。その単線をそのまま DXF に出すと、受信側は「これが壁のどちら側か」を知りません。壁厚を後から足すと、家具が収まると思っていたクリア幅が足りない、という事故になります。
チェックの仕方：
- 書き出し仕様（または実際の線）が芯か面かを一文で言えるか。 言えなければ、次工程に渡す前に注記を足す。
- ドア前の有効幅など、クリアが効く寸法を一本選んで検算する。 芯のまま家具を置くと、厚みの半分×2 だけ必ず足りなくなります。
- 壁厚を後工程で足すなら、その前提をファイル名やレイヤ名に残す。 「plan_centerline_no_thickness」のようなダサい名前の方が、静かな誤解よりマシです。
トレードオフもあります。芯線だけなら編集は軽いし、壁厚の表現ゆれ（仕上厚・下地）に引きずられにくい。一方で、内装の「ここにソファが置けるか」はクリア幅の世界です。どちらが正しいかではなく、どちらで書き出したかを黙らないことが要点です。
確認 3：開口（ドア・窓）が線分から消えていないか
三番目は開口です。画面上ではドア記号や窓の破線が見えていても、書き出し経路では次のような欠落が起きます。
- 開口が「壁ポリゴンの穴」ではなく、オーバーレイのアイコンだけだった
- SVG では
<g>の表示レイヤに載っているが、DXF のエンティティに変換されていない - PDF はラスタ化されて記号は残るが、CAD で編集できる線としては残らない
- ドアの開き方向・框の位置が、見た目用パスのままで寸法辺に結びついていない
開口が落ちると、次工程では「ただの閉じた壁」になります。動線も家具も、そこから全部ずれます。
検証手順の例：
checklist export_openings:
for each door/window visible in UI:
assert present_in DXF entities OR documented as non-exported overlay
assert clear_width measurable from exported geometry
assert wall break (gap) exists — not only a symbol on top of a continuous wall
「記号が見える」と「壁が開いている」は別です。DXF をテキストや簡易ビューアで開き、壁線が開口位置で切れているかを見るのが早いです。切れていなければ、それは図面ではなくイラスト寄りの書き出しです。
書き出し前の短いルーチン
私なら、無料の平面図メーカーからファイルを渡す前に、次の三分だけやります。
- 基準辺 1 本で単位を当てる（絶対値）
- 芯か内法かを一文でメモする（定義）
- 開口がエンティティとして残っているか見る（欠落）
これ以外——線種、レイヤ分け、ブロック化——は受信側の流派に合わせればよいことが多いです。先に壊れるのは、だいたい単位・定義・開口の三つです。
まとめ
平面図メーカーの価値は、ブラウザ上で間取りの会話を始められることにあります。その価値を次工程に運ぶのが書き出しです。見た目が整っていても、
- 単位の絶対値が合っていない
- 壁芯のままクリア幅として使われている
- 開口が記号だけで壁が連続したまま
のどれかがあると、DXF / SVG / PDF は「それっぽい線の束」になります。次に書き出しボタンを押す前に、私はまず「この辺は何 mm か」「この寸法は芯か内法か」「このドアは線として開いているか」の三つを自分に聞きます。答えられない書き出しほど、後で高くつきます。