「見た目8割、実態1割」——AIプロトタイプの完成度に、エンジニアはなぜ騙されるのか

「これと同じ動きのアプリを、明日までに作れますか」——依頼の背後にある誤解

あるエンジニアが投稿した記事には、非エンジニアがAIツールで組んだプロトタイプを見せ、「同じものを本番で」と依頼してくる場面が描かれています。投稿者は、この依頼が今はまだ単発の出来事だが、近い将来当たり前になるはずだと述べ、その先のエンジニアの評価のされ方に危機感を覚えると書いていました。

私たちの現場経験でも、これはまったく他人事ではありません。むしろAI-Path自身が「動くものを見せる」ことを営業の核に据えている会社です。構想策定の段階で実際に動くプロトタイプを作り、それを叩き台に議論する進め方で、商談の成約率は9割を超えています。だからこそ、この「見た目の完成度」がどれほど強い説得力を持つかを、誰よりも実感しています。強い説得力を持つということは、それだけ誤解も生みやすいということです。

生成AIは「動く画面」を作るのが、異常なほど得意

なぜ見た目は8割まで一気に到達するのに、実態は1割にとどまるのでしょうか。理由は、生成AIが最も得意とする領域と、本番システムが要求する領域がずれているからです。

生成AIは、画面遷移・入力フォーム・一覧表示といった「見えるもの」を作るための学習データを大量に持っています。ボタンを押せば動く、入力すれば反映される——ここまではAIにとって難易度の低い作業です。ところが本番運用に必要な要素、たとえば同時アクセスへの耐性、権限ごとのデータ分離、異常系の処理、監査ログの保存といった「見えないもの」は、学習データ上も評価されにくく、AIが自発的に作り込むことはほとんどありません。頼まれていないことはやらない、というのがAIの基本的な性質だからです。

キーマンズネットの記事でも、生成AIが作ったコードをエンジニアがレビューすると、確認すべき観点として仕様適合・セキュリティ・保守性・テスト容易性・例外処理・依存関係・パフォーマンスがあらかじめ整理されていないと、評価そのものが属人化すると指摘されています。これは私たちの実感とも一致します。観点を決めずに「動いているかどうか」だけで見てしまうと、見た目の完成度に引きずられてしまうのです。

残りの1割に何が含まれているか——私たちが評価に使っている7つの観点

私たちがAIプロトタイプを評価する際に確認しているのは、まさにこの7つの観点です。それぞれ具体的に見ていきます。

仕様適合は、画面が動くことと、業務要件を満たすことは別だという当たり前の確認です。見た目通りに動いていても、発注ロットの丸め方や承認フローの分岐といった業務固有のルールが抜け落ちているケースは珍しくありません。セキュリティは、権限のないユーザーが他部署のデータを見られないか、入力値をそのままデータベースに流し込んでいないかといった観点です。保守性は、AIが一度に大量生成したコードに、半年後に別の担当者が手を入れられるかどうかを見ます。

テスト容易性は、単体テストやシナリオテストを後から書き足せる構造になっているかです。例外処理は、通信が途切れた、想定外の文字列が入力されたといった状況でシステムが落ちずに済むかを確認します。依存関係は、使用しているライブラリのライセンスや料金体系、更新停止のリスクを洗い出す作業です。パフォーマンスは、開発時の少人数のテストではなく、実際の利用規模でも耐えられるかを見ます。これらは特別な発想ではなく、コードレビューの基本そのものです。

ただし正直に言えば、AIが生成したコードに対してこの7観点を機械的に当てはめるだけでは足りません。私たち自身、自社の議事録AIやAIPLAの開発で、テナント間のデータ漏れを自社内で検知して是正した経験や、権限周りの設定不備を検出して封鎖した経験があります。「動いているように見えたが、実は特定の条件でだけ穴が空いていた」というパターンは、見た目のレビューだけでは気づけません。

「ライブラリのコスト地雷」——動いたのに本番で16万円請求された話

見た目8割・実態1割のギャップが最も分かりやすく表面化するのが、コストです。開発環境では無料で使えていたライブラリが、公開環境に切り替えた途端に課金対象になっているケースがあります。本番リリースのタイミングで「16万円払ってください」と請求が来て初めて気づく、という事故は珍しくありません。

私たちの現場では、こうした「ライブラリのコスト地雷」を事前に洗い出し、該当するものは自前の実装に差し替えてから本番に出すという工程を挟むようにしています。VibeCodingの速さの裏側には、こうした本番コストを先読みする地味な作業が隠れています。見た目が動いた瞬間の高揚感だけで進めてしまうと、この工程がまるごと抜け落ちてしまうのです。

この非対称性は、私たちAI-Path自身にとっても他人事ではない

ここで誤解のないように言っておきたいのですが、私たちは「非エンジニアが作ったプロトタイプは価値が低い」と言いたいわけではありません。むしろ逆です。動くものを見せて議論を前に進めるというやり方自体は、AI-Pathが最も大切にしている進め方でもあります。

だからこそ、この見た目と実態のギャップを説明する責任は、私たちのような「動くものを見せる」を強みにしてきた側にこそあると考えています。プロトタイプの価値を否定せず、しかし本番投入にはもう一段の作業量が必要だと、具体的な根拠を持って説明できるかどうか。ここで曖昧に濁してしまうと、「エンジニアは大したことをやっていないのに高い」という不信感につながりかねません。私たちが7つの観点を明文化しているのは、まさにこの説明責任を果たすためです。

私たちが自社のAIPLA開発で徹底しているのも、この「見えない実装」の部分です。本番環境をいきなり書き換えるのではなく、先にステージング環境で修正し、回帰テストが通ってから本番に反映する二段階の運用にしています。さらに顧客の自社環境へ移行する前には、意図的に攻撃を仕掛けるレッドチームアタックを実施し、本番にはIP制限を入れます。見た目のうえでは地味な工程ですが、この積み重ねこそが「見た目8割」と「実態1割」の差を埋める作業そのものです。

非エンジニアの内製を止めない、けれど無制限にもしない——ガードレールの引き方

私たちは、非エンジニアがAIを使ってプロトタイプを作ること自体は積極的に推奨しています。ただし、内製を進めてもらう際には、あらかじめ引いておくべき一線があります。私たちが顧客の内製担当に伝えているのは、まずデータベースを直接いじらないものに留めるということです。自分のブランチをどれだけ汚しても、データベースにさえ直接触れなければ大きな事故にはなりません。

もう一つは、メインブランチへの直接マージを避け、プルリクエストを上げる運用にすることです。プルリクエストを上げれば、AIがその中身を確認してレビューし、妥当性を判断してくれます。人が全件を目視するのではなく、AIによる一次レビューと人間による最終確認を組み合わせる形です。これにより、非エンジニアが安心してAIコーディングを試せる範囲と、本番に踏み込む前に人の目を通しておきたい範囲とを、明確に分けることができます。

「小さく始める」着地点——全社展開の前にパイロットを置く

見た目8割のプロトタイプを見せられたとき、もう一つ有効なのが「いきなり全社展開ではなく、範囲を区切ったパイロットに落とす」という着地点です。私たちがある建材メーカーとそのグループ会社で進めた検図AI(図面チェック)の導入では、全社一斉ではなく、まず2つの工場に限定したパイロットとして先行させました。図面記載ミスをチェックする検図自動化プロトタイプ自体はすでに完成しており、報告会も実施済みでしたが、本番として全社に広げる前に、限定した現場で実際の図面・実際の担当者に触ってもらう工程を挟んだ形です。

見た目が完成しているプロトタイプほど、「もう全社に展開できるはずだ」という期待が先行しがちです。しかし本番システムとしての実装量が伴っていない段階でこの期待に応えようとすると、無理な工数圧縮につながります。範囲を区切ったパイロットを一段挟むことで、残りの1割に何が含まれているかを、限定した現場で先に洗い出すことができます。

見積もりの罠を避けるための具体的なチェックリスト

プロトタイプを見せられてPoCの見積もりを依頼された際、私たちが実際に確認する項目は次の通りです。まず、権限やデータの見える範囲が、部署や取引先ごとに分かれる設計になっているか。次に、想定外の入力やエラー時にシステムがどう振る舞うか定義されているか。そして、本番投入前にステージング環境での回帰テストを通す工程が組み込めるか。最後に、使用しているライブラリやAPIが本番規模のアクセス量でも無償の範囲に収まるか。

これらは一見地味な確認項目ですが、抜け落ちたまま本番投入すると、後から取り返しのつかない事故につながります。見た目が完成しているプロトタイプに対して、この4項目を確認するだけで、バイブコーディングを本番移行する際の実装工数の見積もり精度は大きく変わります。私たちの経験では、この4項目の確認だけで、当初見積もりから工数が1.5倍以上に膨らむケースがしばしば見つかります。

「バイブ清書」的な代行サービスと、伴走型のAI-Pathの立場の違い

@ITの記事では、非エンジニアが生成AIで作ったソースコードを、エンジニアが意図を踏まえて本番利用できる状態に仕上げる「バイブ清書」というサービスが紹介されていました。プロトタイプで止まりがちな問題に代行という形で応えるアプローチで、需要があるのはうなずけます。

私たちのスタンスは、これとは少し違います。清書を後工程で請け負うのではなく、プロトタイプを作る段階から本番設計を織り込んで伴走することを基本にしています。理由は単純で、後から清書する形では、なぜその設計になったのかという意図の共有が難しくなるからです。プロトタイプの段階から一緒に手を動かしていれば、「思っていたのと違う」というズレを防ぎながら、本番に必要な観点を最初から積み上げていくことができます。製造業でAI導入がPoC止まりになりやすい理由についても、この「設計を後回しにする」構造が根っこにあると私たちは考えています。

エンジニアの役割は消えるのか、変わるのか

persol-xtechの記事は、AIがコードを書く時代のエンジニアの役割について、コードを書くことからAIエージェントに的確な指示を与える役割へと変化していくと述べています。私たちの現場感覚では、これは半分正しく、半分は言葉が足りないと感じます。

指示を与える役割は確かに重要になりますが、その指示の質を決めているのは、結局のところ「本番で何が起きるかを知っている」という経験です。見た目8割のプロトタイプを見て、残りの1割に何が含まれているかを言い当てられるかどうか。これはAIに指示を出す技術というより、システムが壊れる瞬間を何度も見てきた者だけが持てる勘所です。エンジニアの仕事は消えるのではなく、コードを書く比重が減り、この勘所を発揮する比重が増えていくというのが私たちの見立てです。

私たちの見解

見た目8割、実態1割というギャップは、AIの性能不足が原因ではありません。生成AIが得意な領域と、本番運用が要求する領域が単純にずれているだけです。このずれを埋めるのは、AIをより賢くすることではなく、人間が「何を確認すべきか」を明文化しておくことだと私たちは考えています。

私たち自身、「動くものを見せる」ことを強みにしてきた会社だからこそ、この見た目の説得力がどれほど強いかを痛感しています。だからこそ、プロトタイプの価値を否定せず、しかし本番投入に必要な工数を具体的な根拠とともに説明する責任があると考えています。AIは壁打ち相手であり、判断は人間がする——この基本姿勢は、プロトタイプの評価という場面でも変わりません。

よくある質問

Q. 非エンジニアがAIでプロトタイプを作ること自体をやめさせるべきですか。 A. いいえ。むしろ推奨しています。ただしデータベースを直接触らせない、メインブランチに直接マージさせずプルリクエスト経由にするといった一線は、事前に引いておく必要があります。

Q. 見た目が完成しているプロトタイプを、社内でどう評価すればよいですか。 A. 仕様適合・セキュリティ・保守性・テスト容易性・例外処理・依存関係・パフォーマンスの7観点で確認することをお勧めします。見た目だけで判断せず、この観点を明文化しておくことが評価の属人化を防ぎます。

Q. 「バイブ清書」のような代行サービスを使うべきですか。 A. 選択肢としては有効です。ただし後工程での代行になるため、設計意図の共有が難しくなる場合があります。可能であればプロトタイプの段階から本番設計を織り込める伴走先を選ぶことをお勧めします。

Q. ライブラリのコスト地雷はどう見つければよいですか。 A. 開発環境と公開環境で料金体系が異なるライブラリ・APIがないか、本番相当のアクセス量を想定して事前に確認します。該当するものは自前実装への差し替えを検討します。

まず試すなら

1. 社内で使っているAI生成コードの評価観点を7項目(仕様適合・セキュリティ・保守性・テスト容易性・例外処理・依存関係・パフォーマンス)で明文化する。 見た目だけで判断する属人的な評価から抜け出す第一歩です。
2. 非エンジニアの内製ガードレールを1つ決める。 「データベースは直接いじらない」「メインブランチへの直接マージを禁止しプルリクエスト経由にする」など、まずは1つで構いません。
3. 本番投入前に、ライブラリ・APIの料金体系を確認する工程を追加する。 「動いたから完成」ではなく「本番コストまで含めて完成」という基準に揃えます。

自社のAIプロトタイプにどれだけ「見えない実装コスト」が眠っているか、把握できていない企業は多くいらっしゃいます。私たちは無償の業務プロセス診断(BPR)を実施しており、AIプロトタイプの評価基準の整備を含めた現状の棚卸しをお手伝いしています。まずは無償の業務診断で、見た目と実態のギャップがどこに眠っているかを明らかにしませんか。

参考リンク

• AI時代に感じた危機感と、エンジニアがこれから考えるべきこと（Zenn）
• 素人がAIに作らせたコード、プロが見ると何点？エンジニアレビューで分かる危険性（キーマンズネット）
• バイブコーディングの"プロトタイプで止まりがち"問題に「バイブ清書」が切り込む（＠IT）
• バイブコーディングとは？「AIがコードを書く」時代におけるエンジニアの価値と生存戦略（persol-xtech）