本記事は、建築設計のワークフローをWeb上で完結させるクラウドプラットフォーム『DDDDbox（フォーディーボックス）』を展開する株式会社AMDlab様の開発現場について、実際に技術の舵取りを担うエンジニアの皆様に詳しく伺ってきました。

Rust/WebAssembly/Web3Dというモダンかつ高難度な技術スタックを、なぜ、どのように使いこなしているのか。その実態に迫ります。

建築設計のすべてをWebで完結させる「DDDDbox」とは

――本日はよろしくお願いします。まずは自己紹介をお願いできますか？

松原: AMDlabの松原です。取締役CTOとして、受託案件から自社サービスまで会社全体の技術的な責任者を務めています。自社サービスではプロダクトマネージャー的な役割も兼務しています。私自身が一級建築士でもあるという点が少し珍しい特徴かもしれません。

鈴木: シニアエンジニアの鈴木です。入社して約2年になりますが、現在は自社サービスの「DDDDbox」の中でも、主に「WEBBIM」（BIMをWebブラウザ上で扱えるようにするサービス※）という部分の開発を推進しています。

柴田: 柴田です。私は今回メインでお話しする内容とは別の「建物カルテ」というプロダクトのチームリーダーをしています。スクラムマスターの資格を持っており、チームビルディングやマネジメントの側面から開発に携わっています。

――ありがとうございます。今回お話を伺うプロダクト「DDDDbox」とは、どのようなサービスなのでしょう
か？

松原: 一言で言えば、「建築設計をすべてWeb上で完結させる」ことを目指したツールです。
大きく分けて2つの機能があります。一つはプロジェクト情報管理。建築には条例や地図データ（GIS※）など膨大な情報が必要ですが、それらをあらかじめDDDDboxが収集・集約し、ガントチャートやタスク管理まで一気通貫で行えるようにしています。

もう一つがWebブラウザ上での3Dモデリングです。法規に適合した建物のボリュームを自動生成したり、壁・床・天井などをモデリングしたり、将来的には図面作成までWebで完結させたりすることを目指して開発を進めています。

※ BIM（Building Information Modeling）: コストや性能などの情報が付与された部材の3Dモデルを組み立てて建物の3Dモデルを作成する手法またはその3Dモデル。
※ GIS（Geographic Information System）: 地理情報システム。位置に関するデータ（地図、地形など）を管理・活用する技術。

なぜ「Rust」と「WebAssembly」だったのか

――建築のモデリングをWebで行うのは非常に負荷が高そうですが、技術スタックの選定理由を教えてくださ
い。

松原: これまで受託開発で3Dビューアーを数多く作ってきましたが、100階建てのビルのような大規模モデルだと部品数が膨大になり、JavaScriptではガタつきやクラッシュが出てしまいます。JSだとガベージコレクション（GC）のタイミングを制御できないためメモリ管理の限界に突き当たるんです。
そこで、「DDDDbox」を立ち上げる際はメモリの管理を徹底すべく「最初から全部Rustでやろう」と決めました。当時はBevyというRustのゲームエンジンを使ってレンダリングを行い、UIも全てRustで描画しようと試行錯誤していました。

――UIまでRustで！かなり尖った構成ですね。

松原: ですが、実際にやってみると開発コストが跳ね上がりました（笑）。ライブラリ自体が開発途上で数ヶ月ごとに仕様が変わってしまいますし、何よりWebブラウザ上のUI表現が非常に難しい。
結局、デザイン通りのUIを効率よく作るために、UI層はReactに、ロジック層をRust/WebAssembly（Wasm）に切り分ける今の形に落ち着きました。

鈴木: 現在はフロントエンドにNext.jsを使用し、数値計算や状態管理のコアロジックにRust/Wasmを採用しています。バックエンドも、Go言語で書かれたBFF（※）以外はほとんどRustで構築し、複雑な数理最適化計算にはPythonを使い分けるなど、適材適所でスタックを組んでいます。

※ Rust: 高いパフォーマンスとメモリ安全性を両立したプログラミング言語。※WebAssembly（Wasm）: 、Webブラウザ上でC、C++、Rustなどの言語で書かれたコードをネイティブに近い速度で実行できるようにする、高速なバイナリフォーマット仕様
※ BFF（Backend For Frontend）: フロントエンド専用のバックエンド。複数のAPIをまとめたり、データを整形したりする役割。

厳格なメモリ管理の安心感と、ライブラリ未成熟の壁

――実際にRustを現場で使ってみて、手応えはいかがですか？

鈴木: コンパイル時のチェックが非常に厳格なので、ビルドさえ通ればかなりの安心感がありますね。最近はAIを使ってコードを書くことも増えましたが、AIが出力したコードの正しさをコンパイラが保証してくれるので、スクリプト言語よりも信頼して開発を進められます。

特に「DDDDbox」では大規模なBIMデータを扱うため、GCに頼らず厳密にメモリ管理ができるRustの特性は、大きなメリットになっています。

――逆に、苦労されている点はありますか？

鈴木: やはりエコシステムの未成熟さです。例えばGCPのSDKも、つい最近まで公式のものがなく、サードパーティ製を使わざるを得ない状況でした。また、Rust/Wasm特有の問題として、Rust側とTS（TypeScript）側でレイヤーが分かれるため、呼び出し階層が増えて複雑化しやすい側面もあります。

柴田: 採用や教育の面でもハードルは感じます。Rust特有の所有権などの概念を習得するのは時間がかかりますし、目的が明確でないまま「流行っているから」という理由だけで導入すると、スピードが出ずに苦労することになりますね。

実際、私のチームのプロダクトでは、言語統一の観点でRustを導入したものの、開発スピードを優先するためにGoへ移行するという判断も行っています。

※ 所有権: Rust独自のメモリ管理ルール。誰がそのデータを持っているかを明確にすることで、安全性を高める。

Web3Dとマルチスレッドへの挑戦

――3D描画周りでは、Three.js（React Three Fiber）を使われているんですよね。

鈴木: はい。当初は自前レンダラーの検討もしましたが、コスト面からThree.jsを採用しました。ただ、ReactのレンダリングサイクルとThree.js（Wasm経由）の更新サイクルを同期させるのは一筋縄ではいきません。状態が変わっているのに再描画されない、あるいは過剰に描画されるといった不整合には今も苦労しています。

またパフォーマンス向上のために、WebWorkerを使ってWasmをマルチスレッドで動かす構成も自力で実装しました。サンプルが世の中にほとんどなくて、かなり頑張って構築した部分です。

――WebGPUの導入についても検討されていると伺いました。

松原: 当初からWebGPUによる並列計算には期待して、Rustのみでチャレンジしていた時には導入していましたが、未対応ブラウザもまだある時期であったこともあり、UIもReactに移行するという方針にもなったので、まずは機能を実装し切ることを優先し一旦断念しました。ただ、Three.jsのバージョンアップでWebGPUへの移行が容易になりつつあるので、動向を見つつ、パフォーマンスが必要なタイミングで差し替えていく予定です。

※ Three.js / React Three Fiber: Webブラウザで3Dを表示するためのライブラリ。Reactで使いやすくしたのがFiber。
※ WebWorker: ブラウザ上で、重い処理をメインの画面表示とは別の「裏側」で実行させる仕組み。
※ WebGPU: WebブラウザからPCのグラフィック処理機能（GPU）をより直接的に操るための最新技術。

エンジニアへのメッセージ：エッジな技術で「新しい建築」を創る

――最後に、この記事を読んでいるエンジニアの方々へメッセージをお願いします。

柴田: まだスタートアップとして整っていない部分はありますが、モダンで難易度の高い技術にチームで前向きに取り組める方には、非常にエキサイティングな環境だと思います。

鈴木: Rustを書きたい、難しいWeb開発に挑戦したい、WebAssemblyや3Dプログラミングに興味がある。そういった方にとって、日々新しい発見があるプロジェクトです。レアなスキルも身につくはずです。

松原: 建設系のスタートアップは多いですが、私たちは「シミュレーション」を重視した建築設計というフェーズに挑んでいます。今日お話ししたようなエッジの効いた技術を駆使しないと実現できない世界があるので、他では経験できないような開発をしたい方、ぜひ建築設計という分野で一緒に楽しみましょう。

――本日は貴重なお話をありがとうございました。