「AIがボンネットを溶接した」?!——バイブコーディングの”その先”にある、誰も語らないバイブコーディング リスク
AIでコードを書く時代となりました。
私自身もこの数ヶ月コードを書いていません。
Cursor、Claude Code、Copilotなど、ツールの進化は凄まじく、いくつかのプロンプトでアプリが動作するのはめんどくさがり屋の私にとってもありがたい限りです。
ですが、最近よく考えることがあります。
それは「このままAIに書かせていて、自分自身にとって本当に良いのか。また、アプリケーションの継続的に拡張していけるのか。」ということです。
2026年1月、CIOに掲載されたある記事が、バイブコーディングの未来に対して強烈な警鐘を鳴らしています。
タイトルは 「AI sealed the hood shut. Soon nobody will be able to fix code when it breaks」で、著者はAikido SecurityのCISO・Mike Wilkes氏です。
この記事の主張を一言でまとめるなら、
「AIはコーディングを自動化したんじゃない。コードの”整備可能性”を奪った。」
ということです。
そうなればエンジニアとしては許せないですね。
目次
燃料噴射エンジンの比喩が刺さる
Wilkes氏はこんなたとえ話から始めています。
かつて内燃機関の時代、自動車の修理屋は基本的な工具さえあれば、どんなメーカーのどんなモデルでも直せました。ところが燃料噴射エンジンが登場してから、もう誰もボンネットを開けなくなりました。
AI生成コードに起きていることは、まさにこれと同じようなことであると述べられています。
コーディングという行為は消えていない。でも、書かれたコードを理解し、修正し、保守する能力、つまり「整備可能性」が失われつつあるということです。
バイブコーディングやAI駆動開発で「動いた！」と喜ぶのは簡単です。
ですが、そのコードが半年後にバグを起こしたとき、自分で直せるでしょうか？
AIに「直して」と頼んで、さらに複雑になったコードの面倒を見られるでしょうか？
Wilkes氏は『禅とオートバイ修理技術』を引用して、機械との関係を失ったとき、私たちは「品質」そのものとのつながりも失うのだ、と述べています。
データが示す現実：5社に1社がAI生成コードで重大インシデント
Aikidoが発表した「2026 State of AI in Security & Development」の調査結果は非常に衝撃的です。
- 5社に1社がAI生成コードによる深刻なセキュリティインシデントを経験済み
- 約70%の組織がAIアシスタント由来の脆弱性を発見している
さらに深刻なのが、責任の所在が曖昧な点です。
「AI起因のブリーチが発生したとき、誰が最終責任を負うのか？」という問いに対して、回答はエンジニアリング部門、セキュリティ部門、ベンダーに分散しています。
つまり、ガバナンスが自動化のスピードに追いついていないということです。
バイブコーダーの多くは個人開発や小規模プロジェクトです。
そのコードがサービスとして公開された瞬間、この問題は自分ごとになります。
ジュニア開発者が「抽象レイヤーの住人」になっている
Wilkes氏が指摘する構造的な問題があります。
今のエントリーレベルのエンジニアは、ほぼ完全に抽象レイヤーの上でしか仕事をしていません。
コードを出荷するスピードは速いですが、システム、ネットワーク、障害モードに触れる経験が圧倒的に少ないです。
これが意味するのは、AIの出力に対して「それ、おかしくない？」と疑問を持てる人間が減っているということです。
バイブコーディングの文脈でいえば、こうです。
AIが生成したコードを「動いたからOK」で通す。なぜ動いているのか分からない。なぜ壊れたのかも分からない。AIに聞いても、AIは別の「もっともらしい」コードを生成するだけ。この繰り返しで、コードベースは誰にも理解できない状態になっていく。
記事の中でも「人間がループに入っているのは、バスの下に投げ込まれるためだけだ」と辛辣に表現されています。
LLMは「次のトークンを予測しているだけ」という原点
記事では医療分野の事例にも触れられています。
LLMをNPC（ノンプレイヤーキャラクター）のように使って、臨床の現場で医療専門家に助言を囁かせるような試みが実際に進んでいます。
LLMの初期ドキュメントではメンタルヘルスプログラムには絶対に使うなと警告されていたにも関わらずです。
LLMの問題解決アプローチは「最も確率の高い次のトークンを予測する」ことであり、うつ病や自殺が話題になれば、モデルは自殺を最も論理的な結果として提案しうるため、警告されていました。
バイブコーディングにも同じ原理が当てはまります。
AIは「正しいコード」を書いているわけじゃなく、「もっともらしいコード」を生成しているだけです。
この違いを理解しているかどうかで、開発者としてのリスク管理能力は大きく変わります。
ツールを増やすほど、インシデントが増える逆説
直感に反するデータがあります。
Aikidoの調査によれば、セキュリティインシデントを経験した組織ほど、より多くのベンダーツールを運用していました。
ツールが多ければ安全、というわけじゃなく、むしろ「ツールスプロール（ツールの無秩序な増殖）」自体がリスクになる可能性があります。
皆さんも経験はないでしょうか？
Cursor、Copilot、Claude Code、v0、Bolt、次々と新しいツールが出てきて、全部試したくなる。でも、ツールを増やすたびにワークフローは複雑になり、どのAIがどのコードを生成したのか追跡できなくなるといったことを。
Wilkes氏の言葉を借りれば、薬が病気より悪い場合があります。
「デジタル・ポテトファミン」——モノカルチャーの恐怖
記事の中で特に興味深いのが「デジタル・ポテトファミン（ジャガイモ飢饉）」の概念です。
iOSユーザーの大半は常に最新バージョンのOSを使っていて、もし脅威アクターがAI生成のマルウェアで最新iOSの脆弱性を突いたら、世界中のiPhoneが一斉にブリック（文鎮化）する可能性があります。
一方、Androidは数多くのOEMバリアントとバージョンが存在するため、このような「モノカルチャー攻撃」に対して自然免疫を持っています。
バイブコーディングの世界でも、みんなが同じAIモデル、同じフレームワーク、同じパターンでコードを生成していれば、同じ脆弱性が大量に複製されるリスクがあります。
AIは良いパターンも悪いパターンも等しく増幅します。
取締役会が問うべき4つの質問
Wilkes氏は、組織のガバナンスが本物かどうかを試す4つの質問を提示しています。
- 過去90日間で、ガバナンスポリシーによってAI生成コードがブロックされた実例を見せられるか？
- AI生成コードが人間のレビューなしに本番環境に到達できないことを証明できるか？
- 本番環境のどの部分がAI生成なのかトレースできるか？
- AIツールが触れてはいけないシステムは何で、誰がそれを強制しているか？
個人開発のバイブコーダーにとっても、これを自分に問いかける価値はあります。
自分のプロジェクトで、AIが生成したコードとそうでないコードを区別できるか？ セキュリティ上重要な部分（認証、決済、個人データの扱い）にAI生成コードをそのまま使っていないか？という観点は非常に重要だと感じます。
バイブコーダーとして、どう向き合うか
この記事から学べることは多いです。
でも「だからバイブコーディングをやめろ」という話ではないです。
ポイントは 「AIに任せること」と「自分で理解すること」の境界線を意識的に引く ことだと思います。
AIが生成したコードをブラックボックスのまま受け入れるのではなく、少なくとも何をやっているか説明できるレベルまでは理解し、バグが出たときに、AIに丸投げする前に自分で仮説を立てられる程度には、基礎体力を維持するのが重要ではないでしょうか。
Wilkes氏の締めくくりの言葉が、すべてを物語っています。
「もしその質問に答えられないなら、あなたが持っているのはガバナンスではない。よくできたフィクションだ。」
バイブコーディングの楽しさを享受しながら、コードとの「関係性」を失わないこと。
それが、AIがボンネットを溶接した時代を生き抜くための唯一の方法だと思います。
