古い3Dの彫刻作品を思い浮かべてほしい。外形をかたどったデータは残っているのに、「どう削り出したのか」を記した設計図は失われている。CADFatherは、その失われた設計図をよみがえらせる自律エージェントだ。
仕事の進め方が一風変わっている。CADFatherは自ら彫刻刀を握らず、一人の監督のように、性格の異なる専門ツールを代わる代わる呼び出して作業を指揮する。途中の結果を目で確認しながら、どのツールを呼ぶか、いつ終えるかを判断する。ただし、結果が使えるかどうかを測り、最良のものを守る仕事は監督ではなく、別の採点コンポーネントが担う。複数のツールと複数の候補を調整しつつ、有効性の判定と採点だけは切り離してあるのだ。
メッシュ(物体の表面を三角形の断片でびっしり覆い、形だけを記録したデータ)は「この物体がどんな姿か」は教えてくれるが、「どう作ったか」は教えてくれない。
JPEG写真にたとえると分かりやすい。完成した写真が一枚だけ残り、それを作ったPhotoshopのレイヤーは消えてしまった状態だ。レイヤーがないので、目や鼻、背景を個別に修正できない。少し手を加えるだけでも、一から描き直すしかない。メッシュも同じだ。設計履歴が失われたスキャンデータ、古いレガシーモデル——外形は問題ないのに、穴の直径ひとつ、壁の厚みひとつを変えようにも、手をつける「レイヤー」がない。
編集可能なCADプログラム(数値を変えると形もそれに従って変わる設計プログラム)へ復元するというのは、この失われたレイヤーをよみがえらせることだ。穴の直径や壁の厚みを数値ひとつとして取り出し、その値を変えるだけで形も追従して変わるようにする。復元物が役に立つには、三つを満たさなければならない。実際にビルド(実行)でき、中身の詰まった隙間なく閉じた(solid)立体として構造が一貫し、あとで編集できることだ。
問題は、これを一つのツールでは解けない点にある。部品の形もさまざま、復元の段階もさまざまで、あらゆる状況に等しくよく効く単一のツールが存在しない。だから、いまこの瞬間に必要な一手が「演算をもう一つ足す」ことなのか、「寸法だけを整える」ことなのか、「前の段階へ戻す」ことなのかを、その都度見極める指揮者が要る。CADFatherの出発点はここにある。
監督の役割はビジョン・言語アシスタント(画像と文章をあわせて理解するAI)が担う。目標の形と、これまでの復元物を画像として受け取り、こう判断する——どの候補を伸ばすか、どのツールを呼ぶか、提案を何個受け取るか、それとももう終えるか。
監督が使う専門家は三種類だ。一つずつ見ていこう。
1) 学習ベースの提案。 事前学習された演算ジェネレーター(CADENA-RL)が、いまのプログラムに継ぎ足す「次の演算」の候補を一度に複数出す。このジェネレーターは、CADモデリングに合わせて語彙と文法を絞った専用言語(DSL)で設計図を書く——汎用言語ではなく「CAD作業だけのための狭い言語」というわけだ。ここでいう「複数」とは、一つの候補に演算をいくつも積むという意味ではなく、互いに異なる代替案をいくつか出すという意味だ。もっともらしい演算をうまく提案するが、特徴をひとつまるごと取りこぼしたり、寸法を間違えたりすることがある。何個受け取るかは監督が決めるが、残りの予算の範囲内でのみ可能だ。
2) アルゴリズムベースの提案(CADFit系)。 学習モデルを使わず、目標メッシュの形に図形を直接当てはめて演算を作る。出発点が空なら、目標だけを見て最初の演算を提案する——回転体なら断面を軸中心に回し(revolve・回転)、そうでなければ押し上げる(extrude・押し出し)演算を探す。すでに候補があれば、目標と比べて足りない部分は押し出しで埋め、余る部分は切り落とす(cut)。形から直接引き出すので頑丈だが、それだけで全体を説明することはできない。このツールが最も輝く瞬間は、ジェネレーターが出す最初の演算がたびたび「閉じていない曲面」で、その上に積み上げる土台がないときだ。断面を一度押し出せば、少なくとも踏みしめて立てるsolidができる。
3) パラメータ最適化。 演算の構造はそのままに、数値だけを変える。スケッチ座標・半径・押し出し深さといった値を少しずつ動かし、復元物の表面と目標メッシュのあいだの符号付き距離(内側・外側まで区別して測る距離)の誤差が最も小さくなる地点を探す。どちらへ値を動かせば誤差が減るのかは、値を少しずつ揺らしてその変化を比べる方式(有限差分)で見積もる。まず粗く合わせ、次に表面の近くで細かく合わせる。枠が合っているときに寸法を精緻に埋めるが、枠そのものが間違っていれば直せない。「変えないのが最善」という結論が出れば、元の数値がそのまま生き残ることもある。
この三つをまとめる仕組みが候補プールだ。復元過程の中間生成物(候補)を一つひとつ記録しておく保管庫だと思えばいい。候補を発展させるとき、既存の記録を上書きせず、子の候補を新しく作る。だから監督は最新の候補にだけ縛られず、先行する有効な候補へ戻ったり、空の状態からまったく別の初手を打ち直したりできる。一つの道だけを掘る代わりに、複数の枝道を同時に生かしておく構造だ。ただし監督が見るのはプール全体ではなく、上位の候補いくつかと、これまでの最善、そして出発点だけだ。見る情報を狭く一定に保っているのである。
一場面を見てみよう。チェーンのリンク一つを復元している最中、最良の候補は板と柱を一つずつしか持っていないのに、目標はそれぞれ二つだ。監督はこの候補を学習ベースの提案とアルゴリズムベースの提案で同時に進め、学習ベースの提案が二つめの柱を付けた新しい候補を作り出す。ひとつの判断が部品全体を見て下され、一つの段階で複数の候補に同時に手を入れられるという点が、ここに表れている。
この構造にはもう一つ、注目すべき点がある。監督が出すのは「提案」にすぎない、ということだ。別の実行コンポーネントがプログラムを実際に走らせて有効かどうかを検証し、点数をつけたのち、監督が画像を見てプールに受け入れるかを決める。より重要なのは、この実行コンポーネントが監督のその都度の選択とは無関係に「保護された最善」(これまで出た候補のうち点数が最も高いもの)を別個に守っている点だ。監督が見当違いの枝へそれてしまっても、最終的な成果物は監督が最後に触っていた候補ではなく、この保護された最善である。
従来の研究が、形を見て一度に正解を出すか、一つの道だけを深く掘るものだったとすれば、CADFatherは複数の可能性を同時に探索し、目標の形に合うツールを自ら選ぶ点で一線を画す。
性能の結果を見る前に、先に押さえておくべき点がある。この記事が根拠にした資料は手法の説明までであって、特定のデータセットで何点を取ったという性能・コストの数値はその範囲の外だ。だから「どのデータセットで勝った」という数字は、ここでは断定しない。代わりに、評価をどう設計したかを見るだけでも、このシステムの性格はかなり多く見えてくる。
評価は六つのデータセット(DeepCAD・Fusion360・MCBの全テストセットと、CADENA-Bench・CADBench・BenchCAD)で行われる。測る軸は、復元の品質、実行の有効性、そして計算コストに対する品質だ。
品質は二つの角度から見る。 一つはIoUで、二つの形の体積がどれだけ重なるかを測る。もう一つはGMSで、表面の各地点がどれだけ似た方向を向いているか——つまり表面が向いた側(法線)がどれだけ一致するかを測る。どちらも0~1にそろえ、高いほどよい。一つの候補の最終スコアは、使える指標の平均だ——IoUとGMSの平均、あるいはIoUが使えない目標ならGMS単独である(IoUは目標が隙間なく閉じた単一の立体であるときにだけ計算される)。
有効性の基準がかなり厳しい。 プログラムがビルドされないか、成果物が「全体として」隙間なく閉じた立体でなければ無効だ。時間制限を超えても無効になる。比較対象のCADENAより厳格で、CADENAは断片化した結果のうち一片でも閉じていれば点を与えるが、CADFatherは全体が一つの閉じた立体でなければならない。断片ひとつで通過させはしないという意味であり、「実際に使えるモデル」に一歩近い。
大きさまで当てなければならない。 点数をつける前に目標と候補を同じ座標系に置くのだが、候補ごとに自分の大きさに合わせて伸縮させるのではなく、すべて同じ固定変換を使う。だから大きさの違う候補は、「正規化のおかげで大目に見てもらう」ことなく点数が差し引かれる。
ここで一つの性格を押さえておくのが公平だ。最終的な成果物である「保護された最善」は、上のスコア(IoU・GMSの平均)で選ぶ。これは複数の候補を作り、そのうち点数が最もよい一つを選ぶ方式(よくbest-of-Nと呼ばれる)だ。チートではない——選ぶときに正解(目標メッシュ)の外の情報をまったく使わないからだ。だが「一度で最善を出した」のではなく「何度も試してそのなかから最善を選んだ」という性格は、その「何度も」にかかったコストと合わせて読むべきだ。何回まで試すかが品質を左右するからである。評価がコスト対品質を別に分析する理由はここにある。
ところが、このすべてのスコアは形がどれだけ似ているかを測るだけで、復元物が編集しやすいかは測れない。取り出された数値が実際に意味のある形で調整できるのか、演算の組み合わせが人の目に合理的かは、形のスコアとは別の問いだ。そもそもこの課題を価値あるものにしたのは「編集可能性」だったのに、採点はその軸を直接は見ていない。だから「スコアが高い」という言葉と「使いやすく復元された」という言葉のあいだには、まだ評価が埋められていない隙間がある。
完璧には復元できない部品があることを前提にしている。 作業を終える理由は二つだ。すべての特徴を再現し、わずかな数値の差だけが残った場合(「shape」)、そして、まだ誤った特徴があるものの、直近の段階がこれ以上は改善できず、ほかに試すこともない場合(「stalled」)だ。stalledを失敗ではなく正常終了としたのは正直な設計だが、裏を返せば、構造的に手がつけられない部品があることを認めるという意味でもある。
扱える演算が限られる。 数値を整えるパラメータ最適化は、押し出し・穴(hole)・回転のみに対応する。それ以外の演算を含むプログラムは整えられない。しかも全体が、先に見たCADENAの専用言語(DSL)に縛られているため、その言語で表現できない構造は、そもそも候補になりにくい。
土台の性能を外部モデルに委ねている。 追加学習をしないのは長所だが、同時に、全体の性能が、借りてくる事前学習モデル(演算ジェネレーターとビジョン・言語アシスタント)の限界にそのまま縛られることを意味する。指揮がどれほど賢くても、使える専門家の実力以上のものは出てこない。
この設計を貫く原理は一つだ。何をするかを判断する側と、その結果を検証・採点して最善を守る側を切り分けること。 終える時点は監督が決めるが、実際に走らせて点数をつけ「保護された最善」を守る仕事は、別のコンポーネントに任せる。だから最終的な成果物は、監督が止めたその候補ではなく、採点が選び出した最善である。
この原則は3Dモデリングに限らない。技術メディアのONTLEも、AIエージェントを作るなかで似た教訓を得た。ONTLEのAI PMが顧客に「完了しました」と返信したのに、実際には抜けがあった「偽の完了」を経験し、ONTLEはPMの言葉ではなく、サーバーが直接実行しサーバーが判定するように方向を切り替えた。判定の権限を、行為者から切り離したのだ。もちろんCADFatherの「スコア」は、形が目標にどれだけ似ているかを測る幾何学的な尺度にすぎず、ONTLEの「業務完了」の判定とは種類が違う。また、CADFatherで終える判断は依然として監督の役目であり、ONTLEのように「完了」の判定そのものを行為者から切り離したわけでもない——実際に特徴が抜けているのに、監督がその差をささいな数値誤差と誤判定して止めてしまった事例が報告されている。それでも持ち込めるのは特定の指標ではなく、行為者の宣言を最終的な答えとして信じず、有効性の検証・採点・最善の保存を別に置くという構造だ。
ここから、自律エージェントを作る人がさらに持ち帰れるものをまとめると、こうなる。
スコアは、復元物が目標とどれだけ似ているかを数値ひとつに圧縮する。そのため「板がまるごと一枚抜けている」といった構造的な欠落は、数値だけでは捉えにくい。人が「あそこに柱が一本ないな」と気づく仕事を、数値が肩代わりするのは難しいのだ。だから監督はスコアだけでなく、目標と候補をレンダリングした画像もあわせて見る。
この手法は「ターゲット部品(part)」を単位として復元を説明する。ひとつの判断段階が部品全体を見て行われ、終了もまた枝ひとつではなく部品全体を終える。複数部品からなる組み立て体の全体をどう扱うかは、この記事が根拠にした範囲の外なので断定しない。
そうだ。リポジトリが公開されている——https://github.com/kulibinai/CADFather。