CAD操作のAI自動化
図面からモデル、そして検収まで通す

プロジェクト概要

金型設計の実務を、AIから直接CADを操作して進められるかを検証しているプロジェクトです。3D CADと2D CADの両方をAIから操作し、図面を読む、モデルを起こす、図面を描く、そして結果を検収する、という一連の流れをどこまで自律で通せるかを段階的に確かめています。

きっかけは、自分自身の実感でした。ある日、部品に穴をあけるという私にとっては単純な作業に、35分と12万トークンを消費していました。作業そのものが難しいわけではありません。何かがおかしい、と思ったのが出発点です。

時間を食っていたのは、作業ではなかった

まず、自分の作業ログを全部集計しました。5日間で38件、合計19.6時間。その内訳を見て手が止まりました。

手戻り・是正・復旧に費やした時間が13.8時間。全体の70%でした。

正味の新しい作業は5.8時間しかありません。しかも記録の25%は、クラッシュや再起動で計測そのものが失われて概算になっていました。

象徴的な失敗があります。15部品の組立モデルを15分で構築し、完了レポートを出したところ、指摘が返ってきました。部品点数も配置も違う。

このとき何が起きていたかを分解すると、原因は5つありました。作った側が検収項目を決めたため「作ったものが必ず通る検査」になっていたこと。部品表の正本の選定を間違えていたこと。省略した部分を報告に書かず、結論を過大に表現していたこと。手元にあった実物データを検証に使わなかったこと。そして干渉がゼロであることを配置が正しいことと取り違えていたこと。

構築そのものは速いのです。時間を食っていたのは、何が正しいかを確定させる前に作り始め、作ってから照合して壊す、というループでした。

これは自動化の設計を根本から見直すきっかけになりました。速く作る仕組みではなく、正しさを先に確定させる仕組みが要る。

つないだ構成

技術的には、AIとCADの間をつなぐところに手間がかかりました。

3D CAD側は公式のコネクタが用意されていますが、開発環境がLinux互換の仮想環境にあり、そのままではCADが待ち受けているアドレスに届きません。そこでWindows側で動く中継スクリプトを書き、標準入出力とHTTP通信を橋渡ししました。

2D CAD側はさらに厄介で、CADが32bit環境を要求する一方、既存のライブラリがその環境でビルドできませんでした。結局、依存ライブラリをゼロにして通信部分を手書きするという判断をしました。結果的にこれが正解で、余計な依存がない分、環境の変化に強くなりました。

さらに、2D CADのアプリケーションを起動せずに図面を読むオフライン経路も用意しました。コンソール版で中間形式に変換し、それを解析する流れです。実務の図面原本には一切書き込まないという制約を守るためでもあります。原本は複写してから触る、という原則は最後まで崩していません。

できるようになったこと

段階を踏んで、こういうことが通るようになりました。

3Dモデルを作り、断面を取り、2D CADの図枠に取り込み、寸法を入れ、表題欄に記入して保存するまでを人手ゼロで完走。逆方向、つまり既存の図面を読み解いてモデルを起こし、そこから図面を再作成する流れも、やり直しゼロで通りました。

実部品への適用も進みました。22点の部品を複製して組み立て、加工の3つの局面を再現したときは、配置行列が25箇所すべて一致しました。別のステーションでは部品20点の体積残差が1e-6%以下。設計変更の検討では、現行案に加えて改良案を4つ生成し、全件が検収に合格しています。

図面作成のほうも、原本と比較して寸法が全数一致し、説明できない差分がゼロの状態まで持っていけました。半径寸法、部分詳細図、断面の切り込み寸法、面取りを面に直接指す表現など、実務の図面が持っている要素を一つずつ実装していった結果です。

金型の動作を確認する動画を1コマンドで生成する仕組みや、CAD上で型の動きを再生するツールバーも作りました。設計の検討で「動かして見たい」場面は多く、これは素直に便利です。

一番の失敗
全部の検査に合格した図面が、加工できなかった

このプロジェクトで最も重要な出来事です。

図面を3枚納品しました。用意した検査ゲートは全て合格しています。寸法も表題欄も図枠も、すべて通りました。

しかし、その図面では加工ができませんでした。

致命的だったのは、投影図が1面しかなかったことです。加工する人が、二面幅があるのかないのかを確かめる手段がありません。あわせて、一般公差の注記も、面粗さの指示も、面取りの指示も抜けていました。

原因は、省略したことを明記しなかったから、ではありません。検査ゲートが、生成した図面の内部での辻褄しか見ていなかったからです。図面として成立しているかどうか、原本が持っている情報を漏らしていないかどうかを、誰も見ていませんでした。

これを一行にまとめました。

門は、門が見ている対象しか守らない。

同じ構造の失敗はもう一度起きています。外形の端面線が抜けたままの図面を3枚納品し、画面を見た人に指摘されました。寸法のゲートも表題欄のゲートも図枠のゲートも全部通るのに、描いた形そのものを見る門がなかったのです。

さらに情けない話もあります。人に出す前に自分で目視確認するための画像を出力する仕組みを作ったのですが、その画像に表題欄も注記も断面ラベルも描かれていませんでした。別の機会には寸法の数値だけが出ませんでした。確認するための道具が、確認すべきものを描いていなかったわけです。

検収を、作る側から引き剥がす

これらの失敗を受けて、仕組みを組み替えました。

まず着手前ゲートを設けました。作業を始める前に、何を正本とするか、何をもって合格とするかを登録します。この登録がない状態では、検収スクリプトは合格を出さず「要確認」で止まります。作ったものに合わせて合格条件を書く、という経路を物理的に塞ぎました。

次に、何が正しいかの定義を一箇所に集めました。検証で使ってよい判定方法と、信用してはいけない判定方法を台帳にして、検収スクリプトはその台帳の「正」の列だけを使って書く、というルールにしています。

この台帳には、実際に痛い目を見た判定方法が並んでいます。3Dモデルの表示用メッシュは実形状と違うので開口の有無を誤判定する。干渉解析の関数は面が重なっていても体積ゼロを返す。保存済みかどうかを示すフラグは保存要否の判断に使えず、これを信じたせいで編集内容が丸ごと消えた。図面ライブラリの角度取得関数は原本の120度を240度と返す。

共通しているのは、見た目や表示に基づく判断は原理的に信用できないということです。数値で照合できるものだけを合格の根拠にする、という方針に切り替えました。

作図のルールそのものも機械化しました。実際の図面21枚から616個の寸法要素を抽出してルール集を生成し、さらに366枚の図面から自社の作図の流儀を実測してプロファイル化しています。そのうえで、原本とこちらが作った図面を同じ物差しで測り、こちらが下回った項目を違反として検出するゲートを追加しました。先の失敗への直接の回答です。

数字で見た変化

手戻り率は、計測を始めた当初の70%から 15% まで下がりました。図面2枚を原本と一致するまで作り直す作業は、手作業なら240分と見積もっていたところを150分で完了しています。

品質を担保するための回帰テストは、2D CAD側44項目、パイプライン側33項目、着手前ゲート42項目、その他15項目まで積み上がりました。当初はそれぞれ11項目、12項目からのスタートです。テスト自体が正しく機能するかを確かめる変異テストも実施しています。

スクリプトは165本、検収の成績書は201件が蓄積されました。

まだ解けていないこと

正直に書いておくと、未解決の課題があります。

「その図面に投影図が何個あるか」を機械で正しく数えられません。

人が実物を数えた正解データ44枚に対して、最初の方式は10枚しか当たりませんでした。閾値を20通り以上振っても8〜18枚の範囲から出ません。方式を変えて34枚（77%）まで来ましたが、追試12枚では8枚と、事前に決めた合格基準の中間に落ちました。

ここで「77%出たから採用」とはしませんでした。不定として、採用の札を付けないことにしています。外した10枚のうち7枚に共通する特徴（主投影図が2個以上ある）まではわかっているので、そこが次の手がかりです。

関数名も変えていません。「投影図の数」という名前を名乗ってよいのは、人の正解と十分に合う方式が出てからだと考えています。測れていないものに、測れた名前を付けない。

そのほか、2D CADへの書き込み効率化は未着手ですし、開いている文書を再度開こうとすると無限に固まって強制終了しかなくなる、といった実装上の落とし穴も残っています。

このプロジェクトで得たもの

自動化というと実行を速くすることだと思いがちですが、このプロジェクトで効いたのは正しさを先に確定させることでした。作るのは速いのです。速いからこそ、間違った前提のまま作ると、その分だけ手戻りが増えます。

そして、検査を作る人と作業をする人が同じだと、検査は必ず甘くなります。自分で自分を採点する構造をどう壊すか、という設計そのものが仕事の中身になりました。これはCADに限らず、AIに何かを任せるときに必ず出てくる問題だと思っています。