AIにプロンプトを投げると、アプリの最初の70%は驚くほど速くできる。画面は動き、データも保存される。「これは、いける」——そう思った瞬間が、いちばん危ない。
GoogleのAddy Osmaniが名づけた 「70%の罠」 だ。バイブコーディングは70%まで一気に走る。だが、残りの30%——エッジケース、セキュリティ、パフォーマンス——で、急に進まなくなる。「1つ直すと、別の場所が壊れる」。あの沼の正体は、これだ。
なぜ、最後の30%だけ難しいのか。
デモで動くことと、本番で耐えることは、別物だからだ。AIは「正常系」を速く作る。ユーザーが想定どおりに操作すれば、ちゃんと動く。だが本番には、想定外がいくらでもある。変な値が入力される。通信が途中で切れる。同時に大勢がアクセスする。悪意のある人が、わざと穴を突く。こうした「異常系」は、こちらが明示的に指示しなければ、AIの出力からはすっぽり抜け落ちやすい。
とくに怖いのが、セキュリティだ。見た目は完璧に動くアプリでも、認証の作りが甘く、本来見えてはいけないデータが誰でも見られる——そんなことが起こりうる。動いているからこそ、危うさが見えない。
だから、結論はシンプルだ。
プロトタイプや社内ツールには、バイブコーディングで十分。だが、外部のユーザーが触る本番環境には、エンジニアによるレビューが欠かせない。
これは「妥協」ではなく「原則」だ。速く作れることと、安全に出せることは、別の問いなのだ。
ではPdMは何をすればいいか。「これは70%で十分なものか、それとも残り30%まで必要なものか」を見極めることだ。アイデアの検証や、社内で使う道具なら、70%で止めていい。お金を払うユーザーが触り、データを預けるプロダクトなら、残り30%——つまりエンジニアの手——が要る。
「バイブコーディングはすごい」と無邪気に走り出すPdMと、「ここまではバイブ、ここからはプロだ」と線を引けるPdM。プロダクトを守れるのは、後者だ。70%の心地よさの先にある30%を忘れないことが、PdMの仕事の一部になる。
同じテーマのナレッジや、すぐ使える無料テンプレもどうぞ。