はじめに

最近、あるCAD業務の自動化に関する相談を受けた。

内容としては、顧客から2D図面を受け取り、人間が3Dモデリングを行い、最終的に検図担当者がチェックする、という業務だった。

そして課題として挙がっていたのは、最終検図のコストが高いというものだった。

そこでチーム側では、

• CADファイルから寸法情報を取得できないか
• 中間成果物を解析できないか
• AIや構造解析で検図コストを減らせないか

という方向で調査を進めていた。

これは全く悪い動きではない。

むしろ、具体的な技術を見に行かないと、見えてこない論点は多い。

しかし、この手の案件で非常によく起きる問題がある。

それは、「技術的にできそう」が、そのまま「この方向で解こう」に変わってしまうということだ。

生成AIや自動化案件では、このズレによってPoCが死ぬことが非常に多い。

ただし重要なのは、技術探索そのものが悪いわけではない、という点である。

大事なのは、技術で前に進みながら、問題設定に戻り続けることである。

今回は、その話を書いてみたい。

技術で考えること自体は悪くない

AI案件や自動化案件では、抽象論だけで考えていると何も進まない。

実際、

• CADファイルには何が含まれているのか
• どんな形式で保存されているのか
• どこまで構造化されているのか
• AIで読み取れるのか
• APIはあるのか
• どの工程がデジタル化されているのか

を見に行かないと、現実的な論点が見えてこない。

なので、

• とりあえずAIに聞いてみる
• ファイル形式を調べる
• サンプルデータを見る
• 小さく実験する
• 可能性を列挙する

という動き自体は正しい。

問題は、その途中で、できそうだから、これが答えだになってしまうことである。

例えば今回のCAD案件でも、

• CADファイルから寸法が取れそう
• なら寸法チェックを自動化できそう
• なら検図コストを減らせそう

という流れに、自然と進みやすい。

しかし、本当に重要なのはそこではない。

本来戻るべき問いは、

• そもそも寸法ミスが主要な失敗なのか
• どの工程でミスが生まれているのか
• その確認コストは本当に全体ボトルネックなのか
• 手前工程で防いだ方が良いのか
• 人間作業をチェックする方向で良いのか
• そもそも人間がやる必要があるのか

という部分である。

つまり、技術探索と問題設定は別物なのである。

多くの仕事は「合理的に設計されたシステム」ではない

ここで重要なのが、業務そのものへの理解である。

自動化案件では、つい今見えている業務フローを「最適化対象」として扱ってしまう。

しかし実際の仕事は、そんなに綺麗ではない。

多くの業務は、

• その時代に使えたツール
• 過去にいた担当者
• 顧客との歴史
• 現場の例外対応
• 社内文化
• 教育コスト
• レビュー体制
• 納期
• 人員不足
• 過去の失敗

の積み重ねで成立している。

つまり仕事とは、綺麗に設計されたシステムというより、歴史的に魔改造されてきた塊

に近い。

例えば、「最後にベテランが全部目視確認している」という工程があったとしても、それが本当に最適解とは限らない。

単に、

• 過去のツールでは途中確認が難しかった
• 若手育成を兼ねていた
• 顧客側の入力品質が悪かった
• 中間成果物が標準化されていない
• 例外が多すぎた

といった理由で、そこに検図工程が集中しただけかもしれない。

つまり、今ある工程は、過去制約の化石である可能性があるのである。

だから、

「今ここで人が確認している」＝「ここをAIで置き換えるべき」

とは限らない。

問題設定に戻るとは何か

では、「問題設定に戻る」とはどういうことか。

単に「目的を考えましょう」という話ではない。

もっと具体的に、

• この仕事の成果は何か
• 顧客は何を欲しがっているのか
• 何が失敗なのか
• どの失敗が致命的なのか
• どの失敗が頻発しているのか
• どこで発生するのか
• どこで検知できるのか
• 何を減らせば成果に効くのか
• 誰がどの判断をしているのか
• その判断は構造化可能なのか
• そもそもその工程は必要なのか

を整理し直すことである。

今回のCAD案件でも、重要なのは単に「CADファイルから何が取れるか」ではない。

例えば、

• 要件自体が曖昧だから後工程でズレるのか
• 人間が3D化する時にズレるのか
• 検図担当ごとに判断基準が違うのか
• 致命的ミスと軽微ミスが混ざっているのか
• 実は可読性確認に時間を使っているのか
• 物理的成立性の確認が本質なのか

で、解き方は全く変わる。

しかも、そのどれもがまだ分からない段階で、「このファイル形式なら寸法取れそうです！」だけ深掘ると、問題設定より先にソリューションが固定化され始める。

ここが危ない。

PoCが死ぬ理由

PoCが死ぬのは、技術的に不可能だからだけではない。

多くの場合、技術的には動いたが、業務上意味が薄かったという形で死ぬ。

例えば、

• 精度は高いが、現場の確認工数は減らない
• 一部ケースしか扱えない
• 致命的ミスには効かない
• 例外処理が多すぎる
• 運用側の判断負荷が増える
• 顧客が本当に欲しい成果とズレている
• 現場の育成構造と衝突する
• データ揺れが大きすぎる
• 人間側の作業ルールが統一されていない

といったことが起きる。

つまり、技術は成立しているが、仕事として成立しない

のである。

特に生成AI案件や自動化案件では、

• AIが動いた
• ある程度読めた
• 判定できた

という時点で、かなり“進んだ感”が出る。

しかし実際には、

「その処理能力は、どの問題を、どれくらい解いているのか」

が整理されていないと、プロジェクトとしては危険な状態だったりする。

そしてこの状態のままPoCを進めると、

• なんとなく前進感はある
• なんとなく技術成果もある
• でも最終的に業務成果へ繋がらない

という、一番危険な状態になる。

「その作業を自動化する」が正解とは限らない

さらに重要なのは、今ある仕事のやり方自体が、最適とは限らないという点である。

例えば今回のケースでも、「人間が3Dモデリングしたものを検査する」という方向だけが答えとは限らない。

もしかすると、

• そもそも人間が3D化する必要がない
• ルールベースで生成できる
• 要件から半自動生成できる
• テンプレート化できる
• 一部クラスタだけ完全自動化できる

可能性もある。

つまり、“検図業務”という

本当は大きすぎる言葉で、一つの仕事として扱ってしまうと、自動化できなくなるのである。

実際には、

• 難易度が低い案件
• パターン化できる案件
• 人間判断が必要な案件
• 例外が多い案件
• 物理制約が厳しい案件

など、かなり性質が違う可能性がある。

しかし現場では、それらが全部「検図」という一言でまとめられていたりする。

だから本当は、「仕事を分類すること」自体が、最初の重要な仕事になる。

技術探索は、問題設定を深めるために使う

ここまで読むと、じゃあ技術調査なんて後回しにすべきなのかと思われるかもしれない。

しかしそうではない。

• 一回解いてみる
• 仮説を立てる
• 実験する
• AIに聞く
• 構造を見る
• ファイルを読む
• サンプルを触る

こと自体は非常に重要である。

なぜなら、

実際に触らないと、問題も見えてこない

からだ。

ただし、

重要なのは、技術探索によって問題設定を更新することであって、技術探索によって答えを固定する

ことではない。

技術で前に進む。しかし、常に戻る。

• これは何の問題に効いているのか
• 本当にそこがボトルネックなのか
• 業務成果に繋がるのか
• 他の解き方はないのか
• 今の工程は本当に必要なのか

を見直し続ける。その往復運動が重要になる。

結論

生成AIや自動化案件では、「できそう」という感覚が、非常に強い推進力になる。

そして実際、その感覚がないとプロジェクトは前に進まない。

しかし同時に、「できそう」が、そのまま問題設定を固定してしまう危険もある。

現実の業務は、歴史的経緯・社内文化・人材構成・ツール制約・例外運用の積み重ねでできている。

つまり、目の前に見えている工程そのものが、最適解とは限らない。だからこそ必要なのは、技術で解きながら、問題設定に戻り続けることである。

PoCとは、技術を証明する場ではない。本当は、「この仕事の本当の問題は何か」を、具体的に掘り当てていくプロセスなのだ。