CTOの佐藤彬大です。AIエンジニアの方と話すと、最初に聞かれるのは「図面のどこがそんなに難しいのですか」という問いです。

この記事では、SAKUJIの図面解析がいま何を解けていて、何がまだ解けていないかを、設計の構造に沿って書きます。書くのは構成の名称と課題までで、モデルの中身や学習方法には触れません。

生成AIだけでは、精度が頭打ちになりました

SAKUJIの初期版は、図面を画像として生成AI（VLM）に渡し、記号を見つけて数えさせる構成でした。短期間で動くものが作れる反面、数量を数え上げる段階で誤差が大きく、同じ図面でも結果が揺れました。

私が参画して最初に出した大きな判断は、この構成のままでは目標精度に届かない、というものでした。原因は個々の工夫の不足ではなく、推論に向かない問題まで推論に任せていた構造にありました。

いまは4つの層に分けて、それぞれ得意な方法で解いています

再設計後のSAKUJIは、図面を次の4層で処理します。

1. ベクター決定論層。CADから出力された図面には、線や文字の座標が残っています。座標があるものは、推論ではなく計算で読みます。
2. ラスター検出層。画像としてしか読めない部分は、機械学習の検出器で記号を見つけます。
3. 凡例理解層。図面ごとに異なる凡例（記号と品目の対応表）をLLM/VLMで読み、品目として正規化します。
4. 人による確認層。AIが確信を持てない箇所は人に回し、確認の結果を次の精度改善に戻します。

一言でいえば「推論で解かなくてよい部分を、推論に投げない」設計です。

解けているのは、凡例から数量と根拠までを一本でつなぐことです

ベクター図面であれば、凡例欄から品目を定義し、図面上の記号を検出して品目に割り当て、数量と根拠位置（図面のどこを数えたか）まで出す流れが動いています。根拠位置が残るので、人は数え直すのではなく、確認するだけで済みます。

精度の測り方も変えました。最終的な数量の誤差ではなく、「記号を見つけられたか（検出率）」と「見つけた記号に正しい品目を付けられたか（記号分類率）」で測ります。誤差は結果であり、原因はこの二つのどちらかにあるからです。

改修案件で凡例が省略されていても、利用者が凡例表を登録し、図面上の記号を囲めば解析できます。

解けていないのは、スキャン図面、凡例の自動特定、大規模物件の3つです

1. スキャン図面。現場で受け取る図面の多くは紙をスキャンしたもので、座標がありません。第1層が使えず第2層だけで読むことになり、ここはまだ目標の精度に届いていません。
2. 凡例の自動特定と記号登録の連携。凡例欄の位置を見つける工程は、まだ利用者の指定に頼る場面が残っています。利用者が登録した記号をAI側の参照として使う連携も途上です。形は同じで添え字だけが違う記号を区別することも、難しい問題として残っています。
3. 大規模物件での動作安定性。ページ数が多い物件では処理時間が伸び、安定性が落ちます。大手の積算部門が扱う案件はこの規模なので、ここがエンタープライズ水準との差です。

11月から1月は、この差を埋めることに集中します

外部のVLM APIに依存する検出を減らし、自社モデルへ移行する判断は既に下しました。その理由は、代表が別の記事で書きます。アーキテクチャと精度の責任は、私が負います。

解きたい問題は上に書いた通りで、隠していません。未解決の3つのどれかに「自分ならこう解く」と思った方は、一度話しましょう。

AIエンジニアの募集ページはこちら