株式会社Nexadata代表取締役の槍田です。

最初のSAKUJIは、私が一人で、VLM APIをつないで作りました。図面を画像として渡し、「この記号は何個あるか」を聞く。それだけで、積算担当者が何時間もかけていた拾い出しが、形になりました。

その私たちが、VLM APIへの依存を減らし、自社モデルへ移る判断をしました。この記事では、なぜその判断に至ったかを、ビジネス側の視点で書きます。技術の中身は、CTOの記事に譲ります。

VLM APIで始めたのは、正しい判断でした

生成AIのAPIは、学習データも、モデルの運用も要りません。要件が固まっていない段階で、動くものを数週間で顧客の前に置けたのは、APIがあったからです。

おかげで、顧客の声を先に取れました。改修案件では凡例が省略された図面が多いこと、精度そのものより手直しの手間が嫌われること。これは作ってから分かった事実で、机上では出てきませんでした。

ぶつかったのは、速度、コスト、安定性の三つの壁です

1. 速度。VLMへの問い合わせは、ページ数と品目数の掛け算で増えます。しかもその多くは「この品目はこの図面に無い」という答えで終わります。ページ数の多い物件ほど無駄な問い合わせが積み上がり、処理時間が伸びました。
2. コスト。問い合わせ回数が、そのまま原価になります。セルフプランは専門工事会社が無理なく使える価格に設定しているので、物件が大きいほど原価が価格に近づく構造は、事業として持ちません。
3. 安定性。同じ図面でも結果が揺れます。同時に投げられる問い合わせの数には提供元の上限があり、混み合えば遅くなります。モデルの更新も、私たちの手の外で起きます。自分たちで制御できない変数が、プロダクトの中心にある状態でした。

この三つは、工夫で小さくはできても、構造としては消えません。

踏み切れたのは、データが貯まる構造ができたからです

自社モデルには学習データが要ります。建設図面と、その正解（どこに、何が、何個あるか）の組です。これは世の中に転がっていません。

SAKUJIにはおまかせプランがあります。利用者の図面を、社内の積算チームが人の手で拾い出すプランです。このプランは売上であると同時に、正解データが毎日増える仕組みでもあります。

加えて、利用者や協力いただく企業から、学習に使ってよい図面を提供いただく動きを進めています。必要な規模には、目処が立ちました。

11月から1月、自社モデルへの移行はCTOが率います

アーキテクチャと精度のオーナーはCTOの佐藤です。私が持つのは、要件の定義と現場での検証、そして学習データを集めてくる営業側です。

VLM APIを捨てるわけではありません。凡例の読み取りのように生成AIが得意な層は残し、記号の検出のように回数と速度が効く層を、自社モデルに寄せます。

この移行を一緒にやるAIエンジニアを探しています。学習データを自分たちで作れる環境は、そう多くないはずです。正解データを作る積算チームの仕事は、次の記事で書きます。

CEO/CTO直下で図面を読むAIを開発する中核メンバー - 株式会社Nexadataのデータサイエンティストの採用 - Wantedly

■このポジションについて SAKUJIの中核である「図面を読むAI」を、CTOと一緒につくるポジションです。AIチームはまだ少人数で、あなたは中核メンバーの一人として、モデルの方...

https://www.wantedly.com/projects/2602819?post_id=1100354&post_location=in_content