「AIで爆速プロトタイピング」の落とし穴

AIコーディング支援の普及によって、「プロンプトを投げるだけで動く画面が数分でできる」という体験は珍しくなくなりました。プロトタイピングとの相性の良さが盛んに語られる一方で、いわゆるバイブコーディング的にAIに丸投げして作ったプロトタイプには、業務システムにおいて軽視できない落とし穴があります。

AIが作る画面はUXが悪いことが多い

AIコーディング支援は、指示された機能を動く形にすること自体は得意です。しかし、フォームのエラーメッセージの出し方、入力補助、操作の導線、画面遷移時の状態保持といった、実際に使ってみて初めて気になる細部の作り込みは、指示に明示的に含めない限り粗くなりがちです。

一般的なコンシューマ向けアプリであれば、多少の使いにくさは慣れや代替手段で吸収されることもあります。しかし業務システムは、日々同じ画面を繰り返し操作する担当者の利用率がそのまま業務効率に直結するため、使いにくさがそのまま現場の不満・定着率の低下という形で跳ね返ってきます。「動く」ことと「使える」ことの間にあるギャップが、業務システムでは特に高くつきます。

「業務の理解」が欠落しやすい

AIは一般的なCRUD画面や承認フローのパターンについては豊富な知識を持っています。しかし、対象の業務特有の暗黙のルールや例外処理——「この条件のときだけ承認者が変わる」「この項目は特定の部署だけ入力が必須になる」といった、その組織固有の事情——までは、指示に明示的に書かれていない限り推測しようがありません。

結果として、AIに丸投げして作ったプロトタイプは「一般的な業務システムとしては動く」ものの「その組織の実際の業務には合っていない」ものになりがちです。プロトタイピングの本来の狙いが、動くものを介して業務理解のズレを洗い出すことにあるとすれば、土台になるプロトタイプ自体に業務理解の欠落があると、洗い出すべきズレが最初から歪んだ状態で議論が始まってしまいます。

本開発へのリファクタリングで困る

完全型プロトタイプを前提にする開発モデルでは、プロトタイピングで作った実装をそのまま製造フェーズに引き継ぎます。しかしAIが出力するコードは、必ずしも丁寧に書かれているとは限りません。命名の一貫性が取れていない、責務が分割されずに1つの関数に処理が詰め込まれている、エラーハンドリングが場当たり的、といったことが起こりがちです。

爆速で動く画面ができた時点では問題が見えにくいのですが、いざそのコードを土台に本番相当の実装へリファクタリングしようとすると、コードの意図を読み解くところから作業が始まり、想定していたよりも工数がかかることになります。プロトタイプ実装の質は、そのまま製造フェーズの立ち上がりの速さに直結します。

コード規約やドキュメントで補えるが、それは「爆速」ではなくなる

これらの問題は、事前にコード規約やREADME、設計方針をAIに与えて守らせることである程度は緩和できます。しかし、そうした前提を整備すること自体に時間がかかるため、「プロンプト一つで数分で動く画面ができる」という爆速プロトタイピングの触れ込みとはトレードオフの関係になります。規約整備に時間をかけるほど、プロトタイピングの最大の武器であるはずのスピードが目減りしていきます。

まとめ

AIによる爆速プロトタイピングは、検証したい仮説が業務理解を必要としない領域——見た目の確認、単純な操作性の検証など——であれば十分に威力を発揮します。一方で、業務システムのように「使いやすさが利用率に直結する」「暗黙の業務ルールを正確に反映する必要がある」領域では、スピードと引き換えに肝心な部分が犠牲になりやすいという注意が必要です。速さだけを見て飛びつくのではなく、何を犠牲にしてでもそのスピードを取りに行くのかを見極めることが求められます。