Opus 5.5 を用いた測量データをもとに構築された街をつくる──台東区今戸のデジタルツインを3日で組んだ記録

One More Vision

2026年10月26日 08:18

こんにちは、STUDIO55技術統括の入江です。

東京都台東区今戸、隅田川沿いの約3.5km四方の街並みを、Claude Opus 5.5を活用し、測量データや公開データをもとに 3Dモデルとして再構築しました。

制作期間は わずか3日間、コミット数は52件。

建築パースの仕事は、図面という「実測に基づく情報」から、建築空間を立体的に再現する仕事です。

では、その発想を建物単体から街全体へと広げることができたら、どうなるでしょうか。

案件ごとに制作してきた敷地周辺の3Dモデルを、まったく異なるアプローチで構築できるかもしれません。

そんな可能性を探るため、日本のオープンデータを活用し、実際にどこまでが可能であるか、検証した内容をお伝えします。

🚫生成AIで形状や画像は作っていません

掲載している 3Dシーンは、画像生成AI や 3D生成AI によって、建物や地形などの形状を生成したものではありません。

実測された測量データや既存の公開データをもとに、AI が構築したプログラムと制作パイプラインによって、実際の街並みを 3D空間に再構築したものです。

当初は、次のような目標からスタートしました。

「約3.5km四方のエリアを対象に、DEM・PLATEAUの建築物モデル・オルソ画像を組み合わせ、ヘッドレスBlenderでglb形式の3Dモデルを構築し、D5 RenderまたはBlenderで1枚の画像としてレンダリングする」

この目標をもとに制作を進め、最終的に構築された3Dモデルの規模は以下のとおりです。

対象区画のGLB：約56万三角形／約39MB
周辺エリアのGLB：約135万三角形／約116MB
樹木のGLB（簡易モデル）：7,232本／約77万三角形

合計すると、約268万三角形、GLBデータだけで約155MB（樹木を除く）という規模になります。

制作環境には、ヘッドレスBlender、Python 3.13（uvで環境管理）、Claude Code（Claude Opus 5.5） を使用。Windows 11、RTX 4090の環境で検証しています。

AI が測量データや公開データを読み取り、それらを処理・統合するためのプログラムと制作パイプラインを構築し、実際の街並みを 3D空間へと再現しています。

つまり、AI が街を「想像して描いた」のではなく、AI が構築した「仕組み」によって、実測データや公開データを3Dの街並みへと変換したということです。

🗾 なぜこの場所を選んだのか？

東京23区は、東京都が公開する高密度な航空レーザ点群や、PLATEAUの3D都市モデルなど、高精度な公開データが充実している地域です。

そのため、東京23区を対象に、検証に適したエリアを選定するところから考え始めました。

その上で、建築ビジュアルの実務を想定し、住宅や中層ビルだけでなく、河川・公園・道路・高架構造物など、多様な都市要素が含まれることを条件としました。

単に建物群を再現するのではなく、実際の建築ビジュアル制作で必要となる、複数の都市要素を組み合わせた3D空間の構築を検証することが狙いです。

これらの条件をClaude Codeに伝え、公開データの整備状況や利用可能性も含めて調査させた結果、次の3つの候補地が提案されました。

候補1：台東区今戸
候補2：中央区日本橋浜町
候補3：台東区駒形

この候補地の中から特に重視したのが、PLATEAU の LOD2（屋根形状などを再現した詳細な建築物モデル）がどれだけ整備されているかという点です。

調査では、隅田川の東岸側は LOD2 の整備率が低いエリアもあり、江東区の清澄・常盤では約7%、墨田区の向島では約29%という結果でした。

こうしたデータの充実度と街並みの特徴を比較した結果、最も条件に合っていたのが台東区今戸でした。

つまり、単に見た目で場所を選んだのではなく、AI に公開データを調査・比較させ、実際の建築ビジュアル制作に近い条件で検証できる場所を選定しました。

⚙️事前準備とAIモデルの使い分け

まず、3Dモデルの構築に着手する前の準備として、作業環境の整備を行いました。

作業用のプロジェクトフォルダを用意し、その直下に、Claude Codeが作業時に参照するプロジェクトのルールをまとめた 「CLAUDE.md」 を配置します。

ここには、制作目的や座標系、フォルダ構成に加え、「大容量データのダウンロードやソフトウェアのインストール前には、必ず確認を取る」 といった運用ルールを記載しました。

続いて、Python 3.13の実行環境をuvで管理し、GDALなどの地理空間データ処理に必要なライブラリや、ヘッドレスBlenderの実行環境を整えます。

ライブラリのインストール、Gitの初期化、Blenderの実行ファイルの確認、テスト用の立方体の書き出しなど、手順が明確な環境構築作業には Sonnet 5.5 を使用しました。

こうした定型的な作業では、処理速度の速いSonnet 5.5を活用することで、作業時間の短縮とAI の使用量の節約を図っています。

一方、実際の3Dモデル構築に入ってからは、点群とPLATEAUの位置合わせや、建物・道路のメッシュ化など、データの特性を読み取りながら判断や試行錯誤を必要とする工程で、Opus 5.5に切り替えています。

つまり、すべての工程で高性能なモデルを使用するのではなく、作業の難易度や求められる判断能力に応じて、AIモデルを使い分けるという運用です。

今回の検証で重要なのは、単にAIを使って3Dモデルを生成したことではありません。

測量データや公開データをもとに、AI自身が処理手順を考え、必要なプログラムを作成し、3Dモデルを構築するための制作パイプラインそのものを組み上げたことです。

これは、従来のように人間が一つひとつモデリングする方法とは異なる、新しい建築ビジュアル制作の可能性を探る検証でもあります。

✅人間による確認・判断を組み合わせる運用ルール

今回の検証では、AI にすべての作業を任せるのではなく、AI による調査・提案と、人間による確認・判断を組み合わせる運用ルールを設けています。

AI の自律的な作業を活かしながらも、重要な変更や最終的な判断は人間が行うという考え方です。

基本となるのは、次の3つのルールです。

1. 変更を伴う作業は、まず提案から：
AIには、変更内容を事前に提案させ、承認するまでは実行しないよう指示。

2. 最終判断は人間が行う：
AIが提示する比較画像やスクリーンショットを確認し、実行の可否や修正方針を人間が判断。

3. 判断の経緯を記録する：
決定した内容とその理由を notes に記録し、Gitのコミットによって変更履歴を管理。

このように、「AIによる提案 → 人間による確認・承認 → 実行・記録」という流れを基本とすることで、AI が意図しない変更を加えるリスクを抑えながら、各工程を進めています。

☝️具体例の紹介

① 高層マンションのディテールは必要か？

制作の終盤、高層マンションの外壁に、バルコニーを表現する横縞を追加するかどうかを検討しました。

Claude Codeは、残された改善項目の中で、この作業を効果が最も大きい第1位として提案していました。想定作業時間は約1日です。

ただし、この順位は実際の画面上での見え方を測定したものではなく、AI による推測でした。

そこで、約30分を使って、主要カメラに高さ45m以上の建物がどの程度映り込むのかを調査しました。

結果は以下のとおりです。

鳥瞰カメラ：画面の0.15%
川沿いのカメラ：画面の0.18%

該当する建物は4棟で、いずれも画面上端の遠景に小さく映る程度でした。

この結果から、約1日を費やしてディテールを追加しても、主要カメラでの見た目にはほとんど影響しないと判断し、作業を見送りました。

ただし、将来的に低い視点から遠景を見せるカメラを使用する場合には、再検討するという条件も記録しています。

AI が提案した優先順位よりも、実際の画面上での効果を測定し、その結果から判断する。

今回の検証では、こうした進め方を重視しています。

② 建物の壁面テクスチャを比較する

ほかの判断についても、多くは比較画像を並べて確認しています。

例えば、詳細区画内の建物の壁面表現については、次の2つを比較しました。

高い建物だけに実写テクスチャを適用する
すべての建物に実写テクスチャを適用する

比較：左（1）＝高さ15m以上の79棟の壁だけ実写
右（2）＝507棟の壁を全部実写

上が Cam_overview、下が Cam_riverside
屋根はどちらも航空写真

実際の見え方を比較した結果、すべての建物に実写テクスチャを適用する方針を採用しました。

このように、AI には複数の選択肢や比較材料を提示してもらい、それを人間が視覚的に確認して判断するという方法で、制作を進めています。

そのほかにも、次のような比較・検証を行っています。

区画のすぐ外の帯：100m・200m・カメラに映る範囲の3パターンを比較。地表の見た目にまだらな部分が生じにくい100mを採用。

左：変更前（4ae1254、周辺はベージュの基準色）
右：変更後（6a6e225、区画の実写の色の分布＋明るさ×2.2）

首都高速道路の路面：素材の使い分け、プログラムによる区画線の描画、航空写真の適用を比較し、航空写真を採用。

1枚目：案A（左）と案C（右）
上から Cam_overview・首都高の拡大・さらに拡大・Cam_riverside
2枚目：図郭の継ぎ目（赤い印の位置）のうち、明るさの差が大きい4か所の拡大
（路面の写真、左右が中心線に沿った向き）

高層マンションの形状：PLATEAUの建物モデルが実際より40m以上低いことが判明したため、航空レーザ点群をもとに再構築。

左：変更前（LOD1 の箱 97m）
右：変更後（点群で作り直し）
上から render_low・その拡大・Cam_overview

このように、判断材料の多くは、実際の3Dシーンを確認できる比較画像を用いています。

🌳 樹木の配置と表現について

樹木については、まず「位置情報の一覧（CSV）＋簡易3Dモデル」という構成で、基本となる配置データを作成しました。

配置精度については、7,051本すべての樹木について、位置と樹種がCSVデータと一致していることを確認しています。

そのうえで、今戸周辺の樹種を踏まえながら、手持ちの botaniqアセットを使用して、簡易モデルをよりリアルな樹木モデルに置き換えました。

具体的には、ケヤキにはニレ、イチョウにはポプラなど、樹形や外観が比較的近いモデルを選定しています。

左：変更前（桜だけ botaniq）
右：変更後（4種類とも botaniq）
上から Cam_overview・Cam_riverside・公園の拡大

このように、樹木の配置情報と3Dモデルの表現を分けて管理することで、位置情報の整合性を維持しながら、建築ビジュアルとしての品質を高めています。

また、樹木の見た目についても、比較画像を用いて確認・調整を行っています。

例えば、葉や枝の色のばらつきを抑えた場合に、景観全体の印象がどのように変わるのかを確認するため、Claude Codeに次のような指示を出しました。

色のばらつき（bq_random_per_branch・bq_random_per_leaf）を控えめに入れた場合（例：0.8）を、公園の拡大で今の状態（1.0）と並べて見せてください。

桜は対象外で、ほかの3種類だけでお願いします。採用するかは画像を見て決めます。

追加指示

ここでも、AIにそのまま変更を確定させるのではなく、まず比較画像を作成させ、その違いを視覚的に確認したうえで、採用するかどうかを人間が判断するという方法を取っています。

このように、数値の調整だけでは判断しにくい見た目の違いについても、AIに複数の選択肢を可視化させ、人間が最終的な表現を決定するという進め方です。

AI が調べ、人間が判断する

今回の検証では、こうしたやり取りを繰り返しながら制作を進めています。

特に多かったのは、私が比較画像を見て違和感や問題点に気づき、Claude Codeがその原因を調査し、修正するという流れです。

AI は膨大なデータの解析やプログラムの構築、修正作業を担い、人間は実際の見え方や建築ビジュアルとしての品質を判断する。

つまり、AI の処理能力と、人間の視覚的な判断力を組み合わせることで、制作を進めているということです。

今回の検証を通して、AI にすべてを任せるのではなく、何をAI に任せ、どこで人間が判断するのか。その役割分担を明確にすることが、実務で活用するうえで重要だと改めて感じました。

🏙️ 実際に構築された3D都市モデル

Terrain（地形）
航空レーザ点群から得られた地表面の標高データ（DEM）をもとに、500m四方・1m格子の地形モデルを構築しています。

建物や樹木などの高さを含むDSMではなく、地表面そのものの起伏を表すDEMを使用しています。

Water（水面）
隅田川の水面は、PLATEAUの水部モデルから水域の範囲を取得し、点群データの水面に該当する点から求めた標高0.19mの平面として構築しています。
なお、川底の形状については測量データを確保できなかったため、再現していません。

Buildings（建築物）
対象区画内の建築物523棟を、それぞれ独立した3Dオブジェクトとして構築しています。

Buildings（建築物）については、対象区画内の523棟のうち、507棟にPLATEAUのLOD2モデルを採用し、LOD2が存在しない16棟については、箱形のLOD1モデルで補完しています。

これにより、対象区画内の建築物の約96.9%をLOD2モデルで再現することができました。

この結果は、前述した「LOD2の整備状況を事前に調査し、台東区今戸を選定した」という判断が、実際の制作においても有効であったことを示しています。

また、区画（500m四方）とそのすぐ外側100mの帯の建築物は、1棟ずつ独立したオブジェクトとして管理し、オブジェクト名には PLATEAUの gml:id（bldg_ で始まる識別子）をそのまま使用しています。

👉 CityGML（gml:id）：建物の形状だけでなく「それが何か」という意味情報（セマンティック）をあわせて持つ、3D都市モデルを記述するための国際標準データ形式の事。

**gml:id（bldg_…）**：
区画 523個（1棟ずつ）
帯（100m） 552個（1棟ずつ）

これにより、後工程で特定の建築物を名前で識別し、個別に修正・差し替えを行うことができます。

一方、周辺リング（約3.5km四方）の建物は、データの軽さを優先して1つのオブジェクトにまとめています。

**Surround_Buildings**：
周辺リング 1個（約5.3万のかたまりを1メッシュ）

重要なのは、単に街並みを3D化するだけではなく、その後、人間が引き継いで編集・修正・管理できるデータ構造を維持していることです。

こうしたデータの管理方法も、AI が構築した3Dモデルを建築ビジュアル制作の実務で活用するうえで、欠かせないポイントとなります。

💡 検証で見えた可能性と、残された課題

今回の検証で最も大きな発見だったのは、AI が測量データや公開データをもとに、実際の街並みを 3D空間に再構築できたことです。

しかも、東京都の高密度な航空レーザ点群やPLATEAUの3D都市モデルを組み合わせることで、より詳細な再現が可能であることが分かりました。

これまでのように、人間が一つひとつモデリングするのではなく、AI がデータを解析し、制作パイプラインそのものを構築するという、新しい制作手法の可能性を確認できたことは、大きな収穫でした。

一方で、実務活用に向けた課題も見えてきました。

特に、地表や屋根の表現に使用したオルソ画像については、利用条件や二次利用、成果物の公開・商用利用に関する確認が必要です。

測量データや公開データから街並みを再構築する技術が進歩しても、その成果物を自由に利用できるとは限りません。

つまり、技術的に「作れること」と、権利上「使えること」は別の問題です。

今後、こうした制作手法を実務に取り入れるうえでは、AI の技術的な能力だけでなく、使用するデータの出典やライセンス、利用条件まで含めて管理することが重要になります。

AI によって制作の技術的なハードルが下がるほど、最後に問われるのは、データを適切に扱うための知識と判断なのかもしれません。

使用したデータとその活用方法

地形：対象区画は東京都の航空レーザ点群（約44点/㎡）から1m格子の地形モデルを構築。周辺エリアには国土地理院の 5mメッシュ標高データを使用。
水面：水域の範囲にはPLATEAUの水部モデルを使用し、水面高さは点群データから標高0.19mとして設定。川底については、海上保安庁（JODC）などが提供する水深データも候補となりますが、今回の対象区間で利用できる詳細な河床測量データは確保できなかったため、再現対象には含めていません。
建物：対象区画にはPLATEAU LOD2（実写テクスチャ付き）、周辺にはPLATEAU LOD1の約5.3万棟を使用。高層マンション1棟は点群データをもとに再構築。
道路：PLATEAUの交通モデルから車道・歩道を区別。首都高速道路については、OSMの形状情報と点群から計測した高さ・幅を組み合わせて構築。
地表・建物の見た目：東京都の簡易オルソ画像（地上解像度0.20m）とPLATEAUの実写テクスチャを使用。
樹木・素材：樹木にbotaniqを使用。各種素材やHDRIにはPoly Havenを活用。

東京都の航空レーザ点群は、1㎡あたり約44点という高密度な測量データです。これをもとに1m格子の地形モデルを構築することで、実測に基づいた地形の起伏を再現しています。

＝データの出典＝

3D都市モデル（Project PLATEAU）台東区・墨田区・江東区・荒川区・葛飾区（2025年度）（国土交通省）を加工して作成
東京都デジタルツイン実現プロジェクト区部点群データ（CC BY 4.0）
国土地理院地理院タイル（標高タイル DEM5A）
東京都デジタルツイン実現プロジェクト区部点群データ簡易オルソ画像
Poly Haven（CC0）