はじめに：「できます！」から始まる泥沼

AIと一緒に開発していると、ほとんどの要求に対して気持ちいいくらい前向きな答えが返ってきます。

「この機能、実装できる？」

「はい、できます！」

「このライブラリを使えばいける？」

「可能です。実装してみましょう！」

そしてコードを書き始める。

ところが、実際には動かない。

エラーを渡すと、

「原因が分かりました。修正します」

また動かない。

さらに修正する。

またエラー。

気がつけば、同じようなコード修正を何度も繰り返している。

AIコーディングで本当に怖いのは、AIがコードを書けないことではありません。

「そもそもその環境では成立しにくい実装」を、成立する前提のまま延々と修正し続けることです。

時間が溶ける。

AIの利用枠やトークンも溶ける。

そして最後には、最初より複雑になったコードだけが残る。

最近、実際の開発でこの泥沼に遭遇しました。

STEPファイル差分ビューアで起きたこと

開発していたのは、3D CADのSTEPファイルを読み込み、加工前後の形状を比較するビューアです。

やりたかったことの一つが、

加工前形状 − 加工後形状 = 削られた部分

を可視化すること。

つまり3Dモデル同士のブーリアン差分です。

Web環境上でCADデータを読み込み、メッシュ化し、JavaScript側でCSG演算を行えば実現できるのではないか。

AIに相談すると、

「CSG演算で差分メッシュを生成できます」

という回答でした。

そこで実装させました。

ところが画面に表示されたのは、期待していた「削られた部分」ではありません。

赤く塗られた加工前の粗材そのもの。

見た目だけなら、何か計算結果が表示されているようにも見えます。

しかし調べてみると、実際にはブーリアン演算が正常に成立していませんでした。

さらに問題だったのは、その失敗を表面上分かりにくくする実装が入っていたことです。

演算に失敗した場合、

元のモデルを代替表示する。

つまり画面上では何かが表示される。

でも、それは求めていた計算結果ではありません。

これでは「動いている」のではない。

動いているように見えるだけです。

「動いているフリ」が一番危ない

私はここがAI開発でかなり重要だと思っています。

エラーになって止まるなら、まだ分かりやすい。

問題なのは、

要求した処理には失敗しているのに、フォールバックによって何となく画面が成立してしまうこと。

例えば、

計算に失敗したので元データを表示する。

API取得に失敗したので仮データを表示する。

解析に失敗したのでデフォルト値を返す。

開発中の暫定処置としては、そうしたフォールバックが必要な場合もあります。

しかし、それを明示せずに「正常な結果」のように見せてしまえば話は別です。

特にCAD解析のように、結果そのものに意味があるシステムでは致命的です。

適当な結果を表示するくらいなら、エラーで止まった方がいい。

私はそう考えています。

なぜAIは「できます」と言ってしまうのか

ここでAIを責めてもあまり意味はありません。

LLMは、こちらが提示した要求に対して、成立しそうな実装方法を推論して提案します。

「JavaScriptでCSG演算したい」

と言えば、

利用可能なライブラリを探し、一般的な実装方法を組み合わせ、

「これならできそうです」

と答える。

しかし、

理論上実装できること

と、

あなたのデータ・実行環境・精度要求で安定して動くこと

は別問題です。

3D幾何演算なら、

メッシュ品質、共面、数値誤差、ポリゴン数、メモリ、処理時間など、実データを入れて初めて分かる問題があります。

だから最初にAIへ聞くべきなのは、

「できますか？」

ではなかった。

「できますか？」ではなく「どこで破綻しますか？」

最近は、ここを変えるようにしています。

例えば、

この機能を現在の構成で実装するとしたら、技術的に成立しない可能性のあるポイントを先に列挙してほしい。

特に処理速度、メモリ、数値精度、ライブラリの制約、実データ依存の問題を確認すること。

実現性が不明な部分については「可能」と断定せず、事前に検証すべきPoCを提示してほしい。

こう聞く。

つまり、

「どう作る？」の前に「どこで死ぬ？」を聞く。

これだけでも、かなり違います。

私が決めた「AI開発の撤退プロトコル」

今回の経験から、AIコーディングにいくつかルールを設けることにしました。

ルール1：同じ問題を2回直して解決しなければ、修正を止める

これは、

「2回失敗したら実現不可能」

という意味ではありません。

2回やって直らなかったら、

コード修正モードから原因究明モードへ切り替える。

というルールです。

以前の記事でも書きましたが、AIが何度修正してもエラーを解決できない場合、私はこう指示しています。

これ以上、推測でコードを変更するな。
原因を特定するために必要なログを取得できるようにしてくれ。

Stack Trace、入力値、処理結果、ライブラリから返された状態などを取得する。

そして、

現象ではなくRoot Causeを調べる。

ルール2：原因が分からないなら、最小構成でPoCする

さらに重要なのがこれです。

複雑なアプリ全体の中で検証し続けない。

例えば今回なら、

「STEPビューア全体を完成させながらCSGも実装する」

のではなく、

2つの単純な形状だけを使って、CSG差分が安定して成立するかを先に検証する。

最小コード。

最小データ。

最小機能。

ここで成立しないなら、本体へ組み込む意味はありません。

ソフトウェア開発でいう、

Fail Fast（早く失敗する）

です。

AI時代には、この考え方が以前より重要になったと感じます。

なぜならAIは、実装コードを猛烈な速度で生成できるからです。

間違った方向にも猛烈な速度で進めてしまう。

ルール3：フォールバックは「成功」に見せない

これは今回かなり痛感しました。

処理に失敗したとき、別のものを表示して画面を成立させる。

これ自体が悪いわけではありません。

ただし、

フォールバックしたことを必ず明示する。

例えば、

「CSG演算失敗：加工前形状を代替表示中」

と表示する。

あるいは開発中なら、潔くエラーで止める。

少なくとも、

本物の計算結果とダミー結果を同じ見た目で扱わない。

これはAIに明示的に指示しておいた方がいいと思います。

ルール4：成立しなければ、機能を捨てる

そして最後。

ログを取った。

原因も調べた。

最小PoCでも検証した。

それでも、現在の技術構成では安定して成立しない。

なら、

捨てます。

別のライブラリにする。

サーバー側へ処理を移す。

ネイティブ実装にする。

精度要求を変える。

あるいは、その機能自体を初期版から外す。

AIを使っていると、

「あと一回直せば動くのでは？」

と思ってしまいます。

AIも次々と新しい修正案を出してくる。

だから撤退しにくい。

でも製品開発で重要なのは、

実装した機能の数ではありません。

ユーザーが安心して使える機能がいくつあるかです。

動くかどうか分からない100の機能より、確実に動く1つのコア機能。

これはAI時代でも変わりません。

AIへの指示に「撤退条件」を入れておく

そこで私は、AIへの開発指示にも、最初から撤退条件を入れておくのが有効だと考えています。

例えばこんなルールです。

同一原因と思われる不具合に対して2回修正しても改善しない場合、それ以上推測でコードを変更しない。

必要なログ・状態・入出力を取得し、Root Causeの特定へ移行する。

実現性そのものに疑義がある場合は、最小構成のPoCで技術成立性を確認する。

PoCでも安定して成立しない場合、現在の方式に固執せず、代替方式・機能縮小・機能削除を提示する。

処理失敗時にダミーデータや元データを正常結果のように表示してはならない。フォールバックする場合は、それがフォールバックであることを明示する。

「何を作れ」だけではなく、

「いつ立ち止まれ」までAIに教えておく。

これが結構重要なのではないかと思っています。