平面図をAIに読ませて住宅の3Dモデルを作ると、完成画像の説得力に目を奪われます。しかし、窓の位置や部屋の寸法を読み違えていても、立体としては自然に見えることがあります。「きれいに生成できた」と「元図に合っている」は別の確認です。

今回取り上げるのは、平面図をいったん中間JSONへ変換し、元画像への重ね描きで確認してから、立面図・3Dモデル・ルームツアーへ展開する試作です。建築設計や施工の正確性を保証するものではなく、画像の解釈と形状生成を分けるソフトウェア上の工夫を扱います。

最近の取り組みで確認できたこと

2026年9月29日の開発記録には、平面図から立面図と3Dビューアを作り、平屋に加えて二階建てのサンプルを生成したことが残っています。日次要約だけでは動画の確認状況が曖昧だったため、記事作成時には実装、検証レポート、テストを追加で確認しました。

実装には、画像へ座標グリッドを付ける処理、JSONを読み込んで検証画像を作る処理、共通の形状から各形式を出力する処理があります。9月30日に作業ツリーのテストを再実行し、79件の成功を確認しました。ただし未コミット変更を含む状態の結果です。公開版や特定のコミットが同じ条件で動くことを保証する数ではありません。

検証レポートでは、平屋の合成サンプルで部屋10室、開口21件を正解データと照合しています。部屋面積はグリッド補正後に一致した一方、開口位置の誤差は平均61mm、最大144mmと記録されていました。これは9月29日の観測値で、今回すべてを再測定したわけではありません。しかも画像の作成者と読み取り側が独立していないため、未知の手書き図面に対する精度とは呼べません。

仕組みを分解する

第一段階は、画像に座標グリッドを重ねることです。AIに「右上の窓」とだけ説明させるのではなく、部屋の輪郭や開口位置を画像座標で表現させます。拡大や分割表示を使って読む場所を限定すれば、見落としの修正箇所も特定しやすくなります。

第二段階で、読み取った内容を`plan.json`へ保存します。この試作の中間表現は、座標単位、階、部屋の多角形、開口、寸法の手掛かりなどを持ちます。ピクセル座標と実寸を区別し、縦横の縮尺を別々に推定できる構成です。画像の縦横が少し伸びている場合に、一つの倍率だけで全体を合わせないための設計です。

第三段階は、JSONを解釈した壁や開口を元画像へ重ねる検証です。ここでは立体の見栄えより、部屋の欠落、共有壁の重複、窓のずれを探します。自動補正や警告も確認し、合わない部分があればJSONに戻ります。元画像を正本にし、生成画像に合わせて読み取りの説明を変えないことが重要です。

第四段階で、確認した形状を立面図、3Dモデル、ビューアへ展開します。コードでは設備配置を含む建物データを組み立て、そこから共通の面データを生成しています。立面図を画像として再解釈して3D化するのではありません。同じ形状を別の見方で描くため、出力ごとの食い違いを追いやすくなります。

小さく再現する手順

まず実在の住宅図面ではなく、利用権限に問題のない架空の平面図を用意します。部屋の輪郭、入口、窓、少なくとも一つの既知寸法を書き込みます。最初から複雑な二階建てにせず、隣り合う二部屋程度で共有壁と通路を確認すると原因を追いやすくなります。

次に、読み取り担当と形状生成担当の境界を決めます。画像を読むAIは座標や寸法の候補をJSONに記録し、形状生成側はその構造を検査します。推測した窓種や高さは、画像で確認できた情報と区別してメモします。寸法情報が足りなければ保留し、もっともらしい数値で埋めない運用にします。

手元の試作では次の順で確認できます。これは当該プロジェクト固有のCLIで、同名の公開パッケージをインストールする案内ではありません。コードを用意していない読者は、この三段階を自身のツールへ置き換えてください。

“`bash
house-tour grid sample.png -o sample_grid.png
# グリッド画像を読み、仕様に沿った plan.json を作成
house-tour check plan.json -o output/check
house-tour build plan.json -o output/preview –no-video
“`

先に動画を省くのは、長い出力を作る前に形状を点検するためです。確認用と生成用の出力先を分け、入力JSONと警告を残します。JSONを一か所だけ修正し、同じ部屋が重ね描きと立面図の両方で変わるかを確かめれば、共通データを使う利点も確認できます。

確認指標

確認は三つに分けます。一つ目は入力の対応です。部屋と開口について、数が合うだけでなく、階・位置・種別が対応するかを見ます。二つ目は寸法です。既知寸法と推定寸法、補正前と補正後を分けて記録します。三つ目は出力の整合です。同じ窓が平面の重ね描きと立面図で矛盾せず、警告の内容を説明できることを確認します。

合格条件は利用目的に応じて先に決めます。たとえば「確認用模型なので未知寸法は明示したまま残す」「主要な部屋や開口の欠落があれば生成を保留する」は運用上の提案であり、今回測定した達成率ではありません。画像ファイルが存在すること、単体テストが通ること、図面の解釈が正しいことも、それぞれ別の指標です。

失敗しやすい点と安全策

**グリッド補正後の一致だけを精度と呼ばない。** この試作では寸法を一定のグリッドへ寄せる処理があります。面積が一致しても、元の読み取りが無誤差だったとは限りません。補正前の縮尺と開口位置の誤差を併記し、規則的な合成図面だけで評価しないことが必要です。

**3D表示を建築上の妥当性と混同しない。** 窓高、壁厚、屋根などには既定値や推測が入ります。耐力、法規、施工納まりを検証したわけではありません。実物の設計判断に使う場合は、専門家による別の確認が必要です。公開用には住所や施主名だけでなく、実在住宅の詳細な間取りも持ち出さず、架空図面で説明します。

**単一HTMLだからオフラインで動くと思わない。** 現在の試作ビューアはthree.jsをCDNから読み込みます。9月30日に確認した公式Installation文書でも、CDN方式とビルドツール方式が説明され、CDN停止時の影響や依存の版をそろえる注意が示されています。ファイルを保存したことと、必要な依存を同梱したことは別です。

**ファイル形式の検査を他アプリでの確認に置き換えない。** Khronosの公式説明では、glTFは3Dシーンやモデルの伝送・読み込みを目的とする形式で、単一のバイナリファイルがGLBです。この試作でもGLBを出力しますが、ヘッダや構造のテスト成功だけでは、別アプリでの見え方まで確認したことにはなりません。

再現チェックリスト

• [ ] 架空図面を使い、画像の利用権限を確認した
• [ ] 座標単位と既知寸法をJSONに明記した
• [ ] 推測した情報と画像から読めた情報を分けた
• [ ] 元画像への重ね描きで部屋と開口を照合した
• [ ] 補正前後の寸法と警告を保存した
• [ ] 合成サンプルの成功を実図面の精度と呼んでいない
• [ ] CDN依存と別アプリでの未検証範囲を明示した

次に改善するなら

次は、作成者が異なる未知の図面を使い、読み取り条件と採点基準を固定した検証が必要です。また、オフライン配布、ビューアの実操作、別アプリでの読み込みは独立した確認項目として残します。今回は中間JSONと重ね描きの経路に絞り、ツアー動画の演出や全出力の品質を完成済みとは評価していません。

参考情報

• 執筆根拠：2026年9月29日の日次記録・開発検証レポート、および9月30日の実装確認・テスト再実行。非公開の作業資料であり、読者向け公開リンクではありません。
• [three.js公式：Installation](https://threejs.org/manual/pages/installation.html) — CDN、ローカル開発、依存の版に関する説明。2026年9月30日確認。
• [Khronos公式：glTF](https://www.khronos.org/gltf/) — glTFとGLBの用途・構成。2026年9月30日確認。