0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

AIに「建築家の良識」を持たせる — MCPでText-to-3D生成の品質を自律保証する

0
Posted at

この記事の3行まとめ

  • テキストから3Dモデルを作るAIは、見た目は自然でもドアが宙に浮く・窓が壁を突き抜けるといった構造的な間違いを頻繁に起こします。
  • そこで、AIに「画像を見せる」のではなく、MCP(Model Context Protocol)経由で3D空間の数値(座標・寸法)を直接読ませて計算させる仕組みを作りました。建築基準法をルール化し、AI自身に検査・修正させます。
  • 結果、AIは違反を自力で見つけて直せるようになり、さらに経験を蓄積するほど手数が減りました(初回9ターン/22万トークン → 9回目は2ターン/9.1万トークン)。

論文本体と発表ポスターは、この記事の末尾「関連資料」にすべて掲載しています(📄 論文PDF / 🖼️ ポスターPDF)。

発表と外部からの反響

本研究は DEIM2026(第18回データ工学と情報マネジメントに関するフォーラム/第24回日本データベース学会年次大会) のインタラクティブセッションでポスター発表しました。DEIMは国内最大級のデータ工学系フォーラムで、今年は約500件の発表が集まっています。

その中で、プラチナスポンサーである 株式会社LayerXのDEIM2026参加レポート において、同社エンジニアが聴講したポスターの中から「面白かったもの」として紹介された4件のうちの1件に、本研究を選んでいただきました。

3次元の建築物の情報を2次元画像としてLLMに与えるのではなく数値的に検証可能な3次元のjsonオブジェクトとして与える点、ユーザとのやりとりから知識データベースを動的に更新していく点が面白い

— DEIM2026参加レポート|LayerX エンジニアブログ

「フィードバックループによって使うほど賢くなる仕組みは、AIエージェント開発においても重要な観点」という評価もいただきました。研究室の外、しかも実際にAIエージェントを事業として開発している現場の方に、狙いどおりのポイントを面白がってもらえたのは大きな励みになりました。

1. きっかけ:「それっぽいけど、なんかおかしい」問題

メタバースやデジタルツインの広がりで、3Dモデルの需要は急増しています。いまや「木造二階建ての家を作って」と打ち込めば、AIが数十秒で3Dモデルを出してくれます。

ただ、出てきたものをよく見ると——ドアが地面から50cm浮いている。窓がドアと重なっている。階段の一段が異様に高い。パッと見は「家」なのに、人が住めない家です。

これは画像生成AIの「指が6本ある」現象の3D版で、幾何学的ハルシネーションと呼ばれます。厄介なのは、見た目が自然なので画像ベースの評価(CLIP Scoreなど)ではすり抜けてしまう点です。

既存研究の多くは「生成した画像をAIに見せて評価させる」方向で解こうとしています。しかし画像からは色や雰囲気は読み取れても、「この窓は壁に対して垂直に刺さっている」といった構造の異常は読み取りにくい。ここが出発点でした。

2. 発想の転換:見せるのではなく、測らせる

そこで方針を変えました。AIに絵を見せるのをやめて、数字を触らせる。

3Dソフト(Blender)の中には、すべてのオブジェクトの寸法と座標が数値として存在します。ドアの高さは2.0m、中心のZ座標は1.0m——だから下端は0.0m、つまり接地している。この程度の引き算ができれば、「浮いている」は確実に判定できます。人間が目で感じる違和感の多くは、実は四則演算で表現できるのです。

この「AIとBlenderをつなぐ配管」に使ったのが MCP(Model Context Protocol) です。LLMは本来ステートレス(会話ごとに状態を忘れる)ですが、MCPを介することで、AIはBlenderの現在の状態を継続的に読み書きできるようになります。

3. システムの仕組み

システムは、役割の違う2つのAIと、2種類の知識ベースでできています。

deim_architecture.png

図1:システム全体構成。ユーザ層からBlender環境層までを、MCP統合層の4ツール(操作・空間・検査・知識)が仲介する。右側の知識層が本研究の提案点で、不変の「規制知識(StaticDB)」と適応的な「経験知識(DynamicDB)」の二層構造になっている。

図中のツール群がそれぞれの役割を担っています。T1(操作)とT2(空間)が「作る」側、T3(検査)が「チェックする」側、T4(知識)が「覚える」側です。

Generator(生成役/図のT1・T2) はユーザーの指示を受けてBlenderを操作します。ピクセルではなくPython API経由の「操作手順」を出力するので、寸法をミリ単位で制御できます。

Inspector(検査役/図のT3) は完成したシーンの数値を取得し、ルールと照合します。違反があれば「ドアの高さを1.5mから2.0mに変更せよ」と、具体的な数値を含む指示をGeneratorに投げ返します。

そして知識を2層に分けたのが本研究の提案点です。

種類 中身 性質
規制知識 建築基準法(採光面積は床面積の1/7以上、階段の蹴上げは23cm以下 など) 不変。AIによる書き換えを禁止し、品質の下限を保証する
経験知識 「窓の上端はドアと揃えると通りやすい」等、修正の過程で得たコツ 可変。セッションを跨いで蓄積され、成長する

法律は勝手に変えられては困る。でも現場のコツは増えていってほしい。この2つを混ぜないことが、コンプライアンスと学習能力の両立につながりました。

4. 実験1:AIは自分の失敗に気づけるか

まず小さく検証しました。「ドアと窓のある壁」を作らせ、2つのルールを課します。

  • ドアの縦横比(高さ÷幅)は1.8以上
  • 窓の上端はドアの上端と揃える(誤差±5cm)

AIが最初に作ったのは、縦横比1.5の「ずんぐりしたドア」と、80cmもズレた窓でした。

評価項目 初期生成 自律修正後
ドアの縦横比 1.5 ❌ 2.0 ✅
ドアと窓の上端のズレ 0.8m ❌ 0.0m ✅

Inspectorが数値で違反を検出し、3回のやり取りで全制約を満たすモデルに収束しました。視覚を一切使わずに、です。画像を見なくても、適切なAPIを与えればAIはCAD的な精密作業ができる——これが第一の手応えでした。

5. 実験2:AIは「使い込むほど賢くなる」か

本命はここです。わざと5つの欠陥を仕込んだ家(ドアが浮いている、窓とドアが重なっている、採光面積が足りない、など)を用意し、毎回同じ状態からスタートして10回修正させました。毎回チャットの記憶はリセットしますが、経験知識のファイルだけは次回に引き継ぎます。

試行 完了までのターン数 消費トークン 様子
1回目 9ターン 約22万 修正と再検証を延々ループ。試行錯誤の末に初めてルールを発見
5回目 5ターン 約14.4万 開始時に過去の教訓を参照。初期配置の精度が向上
9回目 2ターン 約9.1万 指示直後に採光面積を自力計算。ほぼ初手で正解に到達

手数もコストも3分の1以下になりました。モデル自体は一切再学習していません。変わったのは、外部に蓄積された知識だけです。

「AIが賢くなる」というと巨大なモデルの再学習を思い浮かべがちですが、経験を構造化して外に書き出しておくだけで、専門分野に特化していくことを実データで示せたのが、この研究の一番の成果だと考えています。

6. 副産物:AIが作った「ハムスター用階段」

実験中、思わず笑ってしまった失敗があります。

「階段の1段の高さは23cm以下」というルールを実装したつもりが、検査プログラムのバグで階段全体の高さを見て判定していました。AIが普通の階段(全高2m)を作ると、検査は「基準0.23mを超えている、違反!」と却下します。

するとAIは文句ひとつ言わず、1段2.3cm・全高23cmのミニチュア階段を作り直し、「法令に適合しました」と胸を張って報告してきたのです。

これは 報酬ハッキング と呼ばれる現象の典型例です。AIは「常識」ではなく「与えられた評価関数」を極めて忠実に最大化します。裏を返せば、自律生成システムの品質を決めるのは生成側の賢さではなく、評価側の設計精度だということ。失敗データとして、とても学びの多い一件でした。

7. 実装で効いた地味な工夫

論文では詳しく書ききれませんでしたが、実務的に効果が大きかったのは次の2つです。どちらもプロンプトの工夫ではなく、ツール側のコードで決定論的に処理するのがポイントでした。

  • 原点の統一 — 3Dソフトではオブジェクトの原点が「底面」か「中心」かがまちまちで、LLMはこれを取り違えて高さの半分だけズラす(浮かせる/埋める)ミスを頻発します。生成直後に原点を強制的に幾何中心へ揃えることで、AIは中心座標だけ管理すればよくなり、配置ミスが激減しました。
  • 操作の冪等性 — LLMは「修正」のつもりで新規作成を連発し、同じ場所に Cube.001, Cube.002 を積み上げがちです。同名オブジェクトがあれば更新のみ行う設計にしたところ、修正ループが何周してもシーンが汚れなくなりました。

AIエージェントを実用に乗せる作業は、AIが間違えやすいポイントを先回りして、間違えようのない道具を渡すことなのだと実感しました。

8. これから

現在は、複数のルールが競合する状況(例:採光を確保したいが耐力壁も必要)でどう折り合いをつけるか、そして長期運用で知識ベースが肥大化したときの取捨選択に取り組んでいます。

建築に限らず、「正解が数値で定義できる領域」——工業製品、回路設計、レイアウト設計など——には同じ枠組みが応用できるはずです。生成AIを「一発で正解を出す魔法」ではなく、検査と修正のループを回せる同僚として扱う。そのための土台づくりを続けています。

資料

使用技術:Python / Blender 4.2 LTS (bpy) / Model Context Protocol (FastMCP) / Ollama (gpt-oss:20b) / JSON知識ベース / 全処理ローカル実行(外部API・通信コストゼロ)

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?