AIで色を塗るのをやめるために、AIでソフトを作った週末

品質管理部門がAIで製品画像を色分けしていた。

周囲では、

「AIってそんなこともできるんだー」

と盛り上がっていたらしい。

私は別のことを考えていた。

「これは、再現できない。半年後に誰か地獄を見る運用ではないか？」

私は製品設備の設計者だ。

かれこれ20年近く、ミクロン単位の精度が求められる金型や設備の設計、そして3D CADデータと向き合っている。

設計の世界では、再現性は絶対条件だ。

同じ図面から、同じ部品が生まれなければならない。

変更が入れば履歴が残り、いつでも「あの時点の状態」に戻せなければならない。

それが崩れた瞬間、設計は管理ではなく賭けになる。

プロンプトを打って生成した画像には、その保証がない。

同じ指示を入力しても、出力は微妙にずれる。

「前回どんなプロンプトを使ったか」を完全に記録しておくことも難しい。

品質管理の正式文書として使い続けるには、構造的に無理がある。

問題は「面倒かどうか」ではない。

「再現できるかどうか」だ。

半年後、変更が入るたびに誰かが画面の前でプロンプトを打ち直す。

微妙に違う画像が出るたびに修正を重ねる。

それは新しいテクノロジーの活用ではなく、新しい形の手作業だった。

ある日、製品の品質取り決めに関する打ち合わせが開かれた。

議題の一つは、製品の各部位について「どれだけ重要か」「どこまで変更可能か」を分かりやすく示す資料を作ることだった。

方法は単純で、製品の各箇所を色分けする。

赤は重要。

黄色は条件付きで変更可能。

緑は比較的自由。

そういった情報を視覚的に共有しようという話だった。

正直に言うと、私はあまり乗り気ではなかった。

色分けしたところで管理が増えるだけではないか。

別の方法で運用した方が良いのではないか。

そんなことを考えながら、ささやかな抵抗も試みた。

「設計部門ではなく品質管理部門で色分けを担当してはどうでしょう」

面倒な作業を引き受けることになれば、誰かが「やっぱりやめませんか」と言い出すかもしれない。

それに、どの部分が重要で、どの部分を変更できるのか。

それを最終的に判断するのは客先との取り決めを管理している品質管理部門だ。

情報の所在地としても、論理的にはそちらの方が正しいはずだった。

しかし、その案は思いのほかすんなり承認された。

私の淡い期待は数分で消えた。

そして一つ問題が残った。

品質管理部門はCADを持っていない。

3Dモデルを見ることも編集することもできない。

では、どうやって色分けするのか。

その時点では誰も決めていなかった。

数日後の金曜日に打ち合わせ。

配布された資料を見て私は固まった。

そこには色分けされた製品画像が貼り付けられていた。

話を聞くと、製品画像を社内で許可されている生成AIへ投入し、

「この部分を赤に変更」

「ここを黄色に変更」

といった指示で作成したらしい。

後から聞くと、周囲では

「AIってそんなこともできるんだー」

と盛り上がっていたそうだ。

たぶんその時の私は聞こえていなかった。

頭の中では別のことを考えていた。

これ、本当に運用するのか。

頭の中で、設計変更のプロセスが最悪のシミュレーションを始める。

変更が入ったらどうする。

再現できるか。

色の定義が変わったらどうする。

製品が増えたらどうする。

プロンプトを叩いて、ガチャを引くように「惜しい画像」を修正する作業に、一枚あたり何時間かかったのだろう。

生成AIは「ゼロからイチ」を生み出すのは得意だ。

しかし寸法の決まった3Dモデルに対して「厳密な一貫性を保ち続ける」のは最も苦手な領域だ。

品質管理の文書に求められるのは、まさにその一貫性だった。

半年後には確実に誰かが溢れた業務で苦しむ。

そんな予感しかしなかった。

打ち合わせ中、私はずっと考えていた。

なぜこうなったのか。

色分け運用が決まった以上、最善の方法は何なのか。

品質管理部門が生成AIを使った理由は単純だった。

3Dモデルを自由に扱えないからだ。

設計部門ならCADで対応できる。

しかし色分けして画像を作り、管理部門へ送り、修正してもらい、再出力してまた送る。

考えただけで面倒だった。

必要なのはCADではない。

色分けに特化したツールだ。

品質管理部門が自分で色を塗り、保存し、後から再編集できるツール。

しかし既存のWebサービスは大抵クラウド前提だった。

モデルをアップロードする。

アカウントを作る。

サーバーへ保存する。

社内セキュリティを考えると避けたい。

思った以上にちょうどいいツールが存在しなかった。

なら作るしかない。

幸いにもその日は金曜日だった。

土日が丸ごと残っている。

AIを使った業務改善ツールを作った経験はある。

3Dモデルを扱うツールは未経験だ。

だが、このまま何もしなければ無駄なAI活用で時間だけが溶けていく未来が見えていた。

残業もせず真っ直ぐ帰宅した。

頭の中で仕様を整理する。

第一条件。

モデルデータはローカルで完結。

第二条件。

オフライン環境でも動作可能。

第三条件。

誰のPCでも使える。

そう考えると答えは自然に決まった。

ブラウザで動くWebアプリだ。

STEPファイルを読み込み。

色付けを行い。

色情報をJSONで保存。

再読み込みできる。

まずはそれだけでいい。

自宅では自由にAIを使える。

Gemini。

ChatGPT。

Claude。

無料枠の制限と戦いながら開発を始めた。

数時間後。

モデルの読み込みができた。

色付けもできた。

何とかなるかもしれない。

保存もできる。

再読み込みもできる。

気が付けば時計は深夜を回っていた。

金曜日が既に終わっていた。

明日も休みだから問題ない。

そう思った。

この時点ではまだ、本当に土日が消えるとは思っていなかった。

土曜日

問題があった。

STEPファイルを読み込んでいるはずなのに、モデルがSTLのような三角パッチの集合体になっていた。

レゴブロックで無理やり曲面を作ったように、カクカクした状態になってしまうのだ。

曲面を塗るだけで何十回もクリックが必要だった。

ならドラッグで塗ろう。

実装した。

隣接面の角度を判定し、平行であれば連鎖的に色付けさせよう。

実装した。

角度の許容値をスライダーで変更できるようにしよう。

実装した。

少しずつ使えるものになっていく。

そして疑問が湧いた。

なぜCADでは滑らかな曲面なのに、自分のツールではポリゴンになるのか。

AIに聞いた。

Three.jsの仕様だった。

さらに聞いた。

B-repという方法があるらしい。

OpenCascade.jsを使えば実現できるらしい。

検索すると出てくる。

「OpenCascadeは難しい」

「B-repは難しい」

「Three.jsだけでやる方が楽」

AIも同じことを言う。

しかし私は特に困らなかった。

難しいのは私ではない。

知った事かと、実際にコードを書くのはAIである。

頑張るのはそっちだ。

私はエラーメッセージを貼り付ける係である。

AIが

「難しいです」

と言うたびに、

「そうか、頑張れ」

と思っていた。

今思うと最低である。

迷わずOpenCascade.jsを導入した。

起動エラー。

貼り付ける。

修正。

読み込みエラー。

貼り付ける。

修正。

またエラー。

また修正。

何度繰り返したか分からない。

途中から、自分がAIへ指示しているのか、AIに指示されているのか分からなくなっていた。

だが確実に前進していた。

エラーの内容が変わる。

そしてモデルが表示される。

だが半信半疑だ。

本当に滑らかなR面となっているのか。

表示されていない箇所が無いか。

一つずつ、まんべんなく確認する。

破綻は無い。

円筒面も一つのフェイスとして認識されている。

ついに本来のCADデータとして扱えるようになった。

気が付けば土曜日が終わろうとしていた。

日曜日

ここからは欲望との戦いだった。

測定機能も欲しい。

二点間距離を測れるようにした。

Rのサイズと中心点も欲しい。

実装した。

断面表示も欲しい。

実装した。

フェイスごとのメモ機能も欲しい。

実装した。

気が付けば当初の目的を超え始めていた。

機能が増えるたびにUIが複雑になる。

そこでランチャーを実装した。

AIはESCキーを勧めてきた。

だが私は採用しなかった。

CAD利用者はCtrlキーを多用する。

Ctrl+右ドラッグで回転する。

その感覚に合わせるならスペースキーだ。

実際に使う人間の感覚を知っているのはAIではなく私だった。

最後の難関は複数パーツだった。

アセンブリを読み込むと位置がバラバラになる。

何時間も原因が分からなかった。

最終的に判明した原因は単純だった。

配置と回転を二重で適用していた。

気付けばすぐ直る。

気付くまでが長い。

設備の設計開発も同じだ。

不具合の原因を見極めるまでがとにかく大変だ。

日曜の夜。

ついに完成した。

オフライン動作。

ローカル保存。

STEP読み込み。

色付け。

メモ。

測定。

断面。

必要だったものは全て揃った。

私はGitHubへアップロードした。

月曜日

セキュリティ部門へ連絡した。

怪しい通信がないか確認してほしい。

社内利用できるか判断してほしい。

実際に確認してもらった結果、

通信なし。

ログイン不要。

外部送信なし。

完全ローカル動作。

問題なし。

そもそも最初から外部通信を行わない設計思想にしていたため、確認項目はソースコードの目視だけで済んだ。

その日のうちに社内利用許可が下りた。

金曜日の会議から三日後だった。

思いつきで始めたツールが社内ツールになっていく。

セキュリティ部門の承認が下りた翌日。

関連部署を集めて説明会を開いた。

正直、少し緊張していた。

この部門は普段、設備の設計に対してなかなかにボロクソ言ってくれる。

仕様の細部まで突いてくる。

代替案を求めてくる。

承認まで何度も往復する。

それが当然だと思っているし、そのやり取りで設計は良くなる。

だから今回も、どこかでダメ出しが来ると思っていた。

しかし説明が終わっても、反対意見は一つも出なかった。

質問はあった。

操作方法を確認するものだった。

「これ、自分たちで使えますか」

という問いかけだった。

「使えます」

と答えた。

それだけで会議は終わった。

いつもなら仕様の細部を突いてくるあの部門が、信じられないほどあっさりと引き下がった。

少し驚いた後で、理由はすぐに分かった。

彼らもまた、生成AIにプロンプトを打ち込みながら、

「何かが違う」

「こんな面倒なことをやりたかったわけじゃない」

と薄々感づいていたのだ。

彼らにとってAIでの画像編集は、CADを持たない者が苦肉の策で選んだ「仕方のない手段」だった。

自分たちが本当に困っていたことを、そのまま解決するものだったからだ。

文句をつける理由がなかった。

あの日、品質管理部門はAIで画像を編集していた。

私はAIでツールを作った。

どちらもAI活用だった。

けれど目指したものは違った。

AIに一回仕事をやらせることではない。

人が何度も同じ仕事を繰り返さなくて済む仕組みを作ることだった。

「AIってそんなこともできるんだー」

その言葉で思考を止めた先には、テクノロジーを使っているようでいて、毎回誰かが何時間もかけてプロンプトを打ち直す「新しい手作業」がある。

それが破綻するのは、感情の問題ではなく構造の問題だ。

後から気づいたことがある。

「再現できないものは、管理できない」

それは品質管理部門が、設計部門に何度も言ってきた言葉だった。

みんな同じ原則を知っていたのに、見えなくなっていた。

あの週末を使ったのは、その未来を変えたかったからだ。

ツールは一度作れば、ずっと動く。

もしあの日、

「AIってそんなこともできるんだー」

で思考を止めていたら。

あの週末は存在しなかった。

そして今も誰かの貴重な時間が、画面の向こうで静かに溶け続けていただろう。