フィジカルAI 2026年7月28日

2D図面から「動かせる3Dモデル」を生成——renueの新機能が示す設計AIの次の一手

何の話か：図面AIが「形状」から「機構」へ踏み込んだ

2026年7月、renue社が自社の図面AI「Drawing Agent」に追加した新機能「可動アセンブリ」が静かに注目を集めている。

一言で言えば、2D図面から3Dモデルを生成するだけでなく、そのモデルを「動かせる状態」で出力する機能だ。組立図に描かれた回転矢印、関節表、部品表といった情報を読み取り、「どの部品が、どの部品に対して、どの軸で、どこまで動くか」という機構情報を抽出する。部品を個別のリンクとして分割し、関節の種類・軸・可動域を設定した3Dモデルとして生成する。

これだけ聞くと「便利な自動化ツールが一つ増えた」という印象になる。だがもう少し深く見ると、これは設計AIが踏み込んだ段階の変化として読める。

なぜ今これが重要か：「静的モデル生成」の次へ

これまでの図面AIが主にやってきたことは、2Dの形状情報を3Dに変換することだった。いわば「見た目の再現」だ。

今回のアップデートが異なるのは、図面に含まれる「意味」を読もうとしている点だ。関節はどこか、どう動くか、可動域はどこまでか——これらは形状情報ではなく機構情報であり、従来は人間が読み解いて手動で入力していた情報だ。

製造業でAIが実務に入り込んでいく際に、「形状の再現」よりもはるかに難しいのが「機能の理解」だ。ボルト穴がある位置を検出することと、その穴がどういう機構の一部であるかを判断することは、難易度がまるで違う。今回のDrawing Agentの機能追加は、その難しいほうへ踏み出した試みだ。

機能の中身を具体的に見る

発表内容から確認できる事実を整理する。

対応する可動方式は「回転関節」と「直動関節」の2種類で、蝶番のような単一関節に加え、複数の関節が直列につながる機構にも対応している。生成されたモデルはWebブラウザ上のビュワーでスライダーを操作することで、読み取った可動域の範囲内で実際に動きを確認できる。複数の関節を持つ場合は関節ごとに挙動を確かめられる。

注目すべきは、生成前に関節の種類・軸・可動域を画面上で確認・修正できる点だ。AIが読み取った結果をそのまま出力するのではなく、人間が最終確認してから生成に進める設計になっている。これは「AIが間違える」ことを前提にした、正直な設計だと思う。

出力形式はSTEP、GLB、STLの3種類。さらに可動情報を持つモデルについては、ロボット開発向けのURDF形式と、物理シミュレーション向けのMJCF形式のパッケージとしても出力できる。URDF/MJCF出力には、質量・重心・慣性テンソル・関節の可動域制限といった情報も含めることができ、シミュレーション環境へのデータ移行を支援するとしている。

検証機能も組み込まれている。AIが関節をサンプル姿勢まで実際に動かし、動作中に接合面が離れないかを自動で確認する。回転中心の位置ずれや、図面に記載された関節がモデルに存在しない場合も検出できるという。これらは既存の検証機能（寸法照合、穴径の幾何検証、部品間の干渉測定）と併せて実行され、合否が機械的に判断できない項目は「未検証」として表示される。

AIおじさんの見方：「検証まで込み」の意味

ここから少し解釈の話をする。

今回の機能で実は一番重要だと思うのは、URDF/MJCF出力でも、関節の自動認識でもなく、「AIが自分でモデルを動かして検証する」という部分だ。

生成だけするAIと、生成して検証までするAIは、実務上の信頼性が全然違う。前者は「出力を人間が全部チェックする必要がある」ツールであり、後者は「AIが一次検証を終えた状態で人間に渡す」ツールだ。この差は、実際に製造現場で使えるかどうかに直結する。

もちろん、AIが検証した≠正しい、ではある。「接合面が離れないか」「回転中心がずれていないか」という特定の検証項目について合否を出しているだけで、それ以外の問題を見つける保証はない。発表でも「機械的に合否を判断できない項目は『未検証』として表示する」と明記されている。この正直さは信頼に値する。

URDF/MJCF出力についても補足しておく。これは単なる「対応フォーマットが増えた」という話ではなく、ロボット開発のパイプラインに直接接続できるようになった、という意味だ。ロボット開発者が図面からURDFを手作業で作成する作業は、それなりに手間がかかる工程だ。そこをAIが自動化できるなら、設計から検証・シミュレーションまでのサイクルが短縮できる可能性がある。ロボット開発向けとMJCFの物理シミュレーション向けを両方カバーしているのも、意図的な選択だろう。

構造として見る：設計AIが「検証プロセスのパーツ」になっていく流れ

少し広い視点で見ると、このニュースはある流れの一部として読める。

設計AIの進化の方向が、「1回の生成で完成品を出す」から「人間のワークフローの中に入り込み、部分的に自動化・検証を担う」へと変わりつつある、という流れだ。

今回の機能も同様で、AIが機構情報を読み取り→3Dモデルを生成し→自動検証を実行し→未検証項目を明示して人間に渡す、というプロセスになっている。AIが全部やるのではなく、AIが「ここまでは確認した」という状態を作って人間に渡す形だ。

これは設計の文脈だけの話ではなく、AIが実務に入り込む際の一般的なパターンになりつつある。全自動化を目指すより、「人間とAIの責任分界点を明確にした半自動化」のほうが、現場での信頼を得やすい。

実務的な示唆：誰が何を考えるべきか

ロボット開発に関わる設計者・エンジニアにとっては、「図面→URDF」という変換コストが下がるなら、検討に値するツールだ。ただし、入力となる2D図面の品質が重要になる。組立図の書き方が曖昧だったり、関節表が省略されていたりすれば、AIの読み取り精度は下がる。「AIが使えるかどうか」の前に「図面がAIに読める形になっているか」を問い直す必要がある。

製造現場でのCAD作業を担う実務者には、「生成前に確認・修正できる」というUI設計がどこまで使いやすいかが、実際の採用可否を左右するだろう。AIの読み取り結果を修正するUIが直感的でなければ、「AIが出した案を確認する手間」が新たな工数になりかねない。

製品・ツール選定に関わる立場の人は、今後同種のツールを評価する際の軸を持っておくといい。それは「何を生成できるか」だけでなく、「どの検証をAIがやって、どの検証を人間に委ねているか」だ。この分担が明示されているツールは、実務での使い方を設計しやすい。

次に問題になること

正直に言えば、今後の論点がいくつか残る。

一つは入力図面の多様性への対応だ。今回の機能は「組立図上の回転矢印や関節表、部品表」を手掛かりにすると説明されているが、現実の図面はバラつきが大きい。古い図面、略式で書かれた図面、社内ルールで独自記法が使われている図面——これらに対してどこまで対応できるかは、発表資料からはわからない。実際に使い込んでみて初めて見えてくる部分だ。

もう一つは精度保証と責任の所在だ。AIが生成・検証したモデルをもとにロボットを設計・製造した場合、そのモデルに誤りがあったとき誰が責任を取るのか。これは法的・契約的な問題でもあり、製造業での実用化が進むにつれて避けて通れない論点になる。「未検証」と表示する誠実さは評価できるが、その「未検証」部分を人間がどう担保するかのプロセスは、ユーザー側が設計しなければならない。