バイブコーディングの差は、どこで出るのか

AI で誰でもコードを書けるようになった。

だから、誰でも高度なアプリケーションを作れるようになった。そう見える。そう語られることも増えた。

でも、現場で起きていることは少し違う。

AI によって「書く」ことのハードルは確かに下がった。実装の速度も上がった。これまでなら作れなかった人が、動くものを作れるようになった。

がしかし、それは「誰でも同じ品質のものを作れるようになった」という意味ではない。

むしろ逆だ。

実装の見た目が平準化したことで、品質の差は見えにくくなった。そして見えにくくなった分、差はむしろ広がっている。

差が消えたんじゃない。差が出る場所が移っただけだ。

実装が平準化すると、勝負は前と後ろに移る

AI が消したのは「実装」という、いちばん見えやすい差だ。残ったのは二つ。

• 前 — 設計・要件の解像度。何を作るべきか、どんな制約があるか。
• 後 — 判定力。出てきたものを読んで、良し悪しを見抜けるか。

見えやすい差が消えて、見えにくい差だけが残った。だから一見みんな同じに見えて、中身は前より開いている。

具体例がある。あるベンダー納品の SQL。文法はきれいで、ちゃんと動く。でも id を String に cast していて、既存の複合インデックスが効かない。両端ワイルドカードの ILIKE をインデックスなしで回す。動く。けれど設計は穴だらけ。

「SQL が書けない」んじゃない。「インデックス設計を意識していない」だけだ。AI は聞かれた範囲で最適化する。トレードオフの判断は、問う側が知らなければ出てこない。

これはセキュリティでも、まったく同じ

セキュリティも実装じゃない。設計と判定だ。問いは二つになる。

① セキュリティの設計要素を、要件に埋め込めるか

「いい感じに API 作って」では、AI は動くものを返す。でも、こう問わなければ埋めてくれない。

• このエンドポイントは誰がアクセスできる？所有者チェックは？（IDOR）
• テナント分離はどこで効かせる？
• 信頼境界の入力検証は？
• secret はどこに置く？

明示しなければ、AI は埋めない。id を cast したあの SQL と同じ構図だ。言われた範囲で、きれいに、穴を残す。

② アウトプットを、セキュリティの目でレビューできるか

出てきたコードを読んで「この認可チェック、本当に効いてる？」と返せるか。これは実装力じゃなく判定力だ。読めない人が AI の出力を承認すれば、整った穴がそのまま本番に出る。

問題は、コードがキレイに出ること

昔のバグは汚かった。今のバグは整っている。

AI が吐くコードは読みやすく、動き、レビューを通りやすい。だから危ない。認可チェックが「ない」ことは、きれいなコードの中では見えない。IDOR はエラーを出さない。動いてしまう。

見た目の整い方と、中身の安全性は、別物だ。

つまり、セキュリティの差も拡大する

実装が平準化した分、セキュリティの質は「設計に埋め込めたか」「出力を判定できたか」に収束する。

それを持っている個人と、そうでない個人で、出てくるものの安全性は前より開く。バイブコーディングは、セキュリティの差を縮めない。広げる。

だから、既知パターンの確認は「最低限」になる

ここで効いてくるのが、既知の脆弱性パターンを機械的に当てるスキャン（SAST / SCA）だ。

• 設計力や判定力がなくても、既知の穴は拾う
• 「最低限の土台」を全員に保証する
• vibe-coded なコードがいくら整って見えても、当てれば既知の穴は出る

ただし、これはあくまで土台だ。SAST は既知パターンしか見ない。認可バイパス、IDOR、ビジネスロジックの穴は、パターンじゃないから拾えない。そこは reasoning ——人、あるいは AI エージェント——の仕事として残る。

層で整理するとこうなる。

実装が誰でもできる時代に、差が出るのは設計と判定だ。セキュリティはその縮図にすぎない。

既知パターンを当てるのは、もう「やってある前提」の土台。その上で、設計に埋め込み、出力を判定できる個人が、安全なものを作る。

AI は道具の天井を上げた。でも引き出せる高さは、相変わらず使う人の知識に縛られている。