3Dアプリへ家具や設備を足すたびに、利用する人の環境まで複雑になる必要はありません。素材を作るためのライブラリと、完成した素材を読み込むためのライブラリは、別の責任を持っています。両者を一緒に配ると、普段は使わない生成ツールの更新やインストールまで運用に入り込みます。

住宅モデリングの試作では、three.jsを使ったオブジェクト生成を独立した工程にし、その成果物をGLBとして同梱しました。本稿は平面図の読み取り精度ではなく、「生成時だけ必要な依存を、日常の処理から外す」設計を扱います。見た目の改善と、配布・再現性の改善を分けて確認するための実践です。

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

2026年9月30日の開発記録には、three.jsの生成ツール、内装テクスチャ、新しい住宅サンプルを追加し、コミットしたことが残っています。家具・建具・照明に加え、便器、洗面台、浴槽を含むGLB素材は11点です。ここで扱うのは、そのうち素材の生成と読み込みの境界です。内装の質感や動画演出を別々の成功事例へ細分化することはしません。

10月1日に実装とテストを確認し、オブジェクト関連のテストを再実行したところ、26件が成功し、スキップはありませんでした。同梱GLBの読み込み、寸法と原点、材料名、生成側とビューア側の版の一致、再生成したバイト列の一致が対象です。確認時のGit作業ツリーに変更はなく、コミット済みの実装で検証できました。

9月30日の記録にある全体テスト164件成功と、今回の26件成功は異なる範囲です。本稿のために全体164件を再実行したわけではありません。また、素材を読めることは、住宅図面の解釈、建築上の妥当性、動画の全編品質まで証明するものではありません。

仕組みを分解する

第一段階は、素材の約束を決めることです。この試作の家具は実寸のメートル単位で、上方向をY、幅をX、正面をプラスZとしています。家具の原点は左・下・手前の角です。一方、ドアレバーは取り付け座の中心、照明は天井に接する上面の中心を原点にします。全素材を同じ原点に押し込まず、取り付け方ごとの規約を明示します。

第二段階で、Node.jsとthree.jsを使って形を生成します。箱や円柱、押し出し形状などを組み合わせ、材料名ごとにまとめ、GLTFExporterでGLBへ書き出します。現行公式文書でも、GLTFExporterは追加機能として明示的に読み込み、`binary: true`でGLBを出力する仕組みが説明されています。ただし手元の実装は固定した版を使い、最新文書の全機能を採用しているわけではありません。

第三段階は、生成物をアプリの素材として同梱することです。生成コードだけでなく完成GLBも管理するため、普段の住宅ビルドではNode.jsを起動しません。Python側の読み込み処理が、同梱GLBを形状と材料へ変換します。Khronosが説明するglTFの役割も、3Dシーンやモデルの効率的な伝送・読み込みです。生成言語と利用言語の間を、ファイル形式でつなぐ設計と相性がよい境界です。

第四段階で、再生成と利用を別々に検査します。生成側では同じ入力から同じバイト列になるか、利用側では許可した材料名、有限な座標、期待した外接寸法を満たすかを確認します。「ファイルができた」だけで受け渡し成功とはしません。

小さく再現する手順

最初は架空の机など一つの素材に絞ります。寸法、原点、向き、材料名を短い仕様にし、生成コードと期待値を一緒に管理してください。複雑な住宅全体から始めると、素材の向きの問題と配置の問題が混ざります。

次は生成専用ディレクトリを作り、依存の版とロックファイルを保存します。以下は今回の試作にある構成で、一般公開された同名パッケージの導入案内ではありません。読者自身のプロジェクトでは、同じ役割のディレクトリとスクリプトへ置き換えます。

“`bash
cd /path/to/project/tools/objects
npm ci
node gen.mjs
“`

`npm ci`はロックファイルを前提にしたインストールです。公式文書では、依存定義とロックが一致しなければ更新せずエラーとなり、既存の`node_modules`は削除してからインストールすると説明されています。作業中の別プロジェクトでは実行せず、生成専用の場所で使います。インストールには通信が必要になる場合があるため、「事前生成だから初回から完全オフライン」とは説明しません。

生成したGLBを二度作って比較し、次にPython側で読み込みます。この試作なら、プロジェクトの依存を用意した環境で次の対象テストを実行できます。生成テストは同梱素材を書き直すので、変更を確認できる作業用コピーで行うのが安全です。

“`bash
python -m pytest -q tests/test_objects.py
“`

読み込みだけの検査と、Node.jsを使う再生成検査を分けておけば、利用環境に生成ツールを置かない判断ができます。Node.jsや生成側の依存がない場合、この試作の再生成テストはスキップします。成功件数とスキップ件数の両方を確認してください。

確認指標

一つ目は素材の契約です。寸法、原点、向き、材料名が仕様どおりかを検査します。今回のテストでは家具と水回りで許容差を分けています。この数値は試作の造形に対する許容差であり、施工精度や製品寸法の保証ではありません。

二つ目は再生成の一致です。今回の環境では、生成前後の同梱素材のバイト列一致をテストできました。ただし、将来のNode.js、ライブラリ、OSの組み合わせでも永久に一致するという意味ではありません。版を更新するときは、意図した変更を確認してから期待する生成物を入れ替えます。

三つ目は依存の境界です。通常処理が生成ツールを呼ばず、完成GLBから形状を読み込むかを確認します。今回の根拠は実装と対象テストであり、Node.jsを削除した新規マシンでの配布試験までは行っていません。その試験は次の受け入れ条件として残します。

失敗しやすい点と安全策

**原点と上方向を暗黙にしない。** 正しい形でも、床下へ沈む、壁と逆向きになる、天井から浮くといった問題が起きます。見た目を手修正する前に、座標規約と配置側の変換を照合します。

**生成側の依存を外せたことと、アプリ全体のオフライン化を混同しない。** この試作のブラウザビューアには、別途CDNからthree.jsを読む経路が残っています。Node.jsが通常ビルドで不要になっても、ビューアまで通信不要になったわけではありません。

**バイト列一致だけで品質を決めない。** 同じ間違った形状も毎回同じように生成できます。外接寸法、材料、面の向きと、表示結果の確認を組み合わせます。GLBを読み込めても、別の3Dアプリでの見え方まで確認済みとは言えません。

**自動化の範囲を広く言いすぎない。** 居室の家具は入力JSONで指定したもので、自動配置ではありません。素材を生成したこと、配置したこと、配置が適切なことは別の判定です。実在の住宅情報を公開せず、説明には架空データを使います。

再現チェックリスト

• [ ] 素材の寸法、原点、向き、材料名を決めた
• [ ] 生成専用の依存とロックファイルを保存した
• [ ] GLBを同梱し、利用側から読み込めた
• [ ] 再生成の一致とスキップの有無を確認した
• [ ] 生成時依存と表示時の通信依存を分けた
• [ ] ファイル検査と表示品質の確認を区別した
• [ ] 自動配置など未実装の機能を明示した

次に改善するなら

次はNode.jsを入れていない環境で、同梱素材だけを使う最小ビルド試験を行うことです。さらに依存更新時の生成物差分を一覧化し、寸法と表示の両方を確認する工程を設けられます。いずれも今後の提案であり、今回完了した検証には含めません。生成の便利さを利用者全員の依存へ転嫁しないことが、この設計の持ち帰りどころです。

参考情報

• 執筆根拠：2026年9月30日の開発記録・検証レポート、および10月1日の実装確認・対象テスト再実行。非公開資料であり、読者向け公開リンクではありません。
• [three.js公式：GLTFExporter](https://threejs.org/docs/pages/GLTFExporter.html)
• [npm公式：npm ci](https://docs.npmjs.com/cli/v11/commands/npm-ci)
• [Khronos公式：glTF](https://www.khronos.org/gltf/)

上記の公式文書は2026年10月1日に確認しました。