生成AIの進化により、非エンジニアでもコードを書き、簡易的なツールを作れるようになった。これまでIT部門や外部ベンダーに開発を依頼していた小規模な業務改善ツールが、現場主導で次々と生まれている。
この変化は一見すると前向きなものに映る。内製化が進み、開発コストが下がり、業務改善のスピードが上がる。しかし、この状況を「開発効率の向上」としてだけ捉えるのは危険である。
実際に起きているのは、開発の民主化と引き換えに、統制や責任、安全性の前提が崩れるという構造変化である。バイブコーディングは単なる開発手法ではなく、ガバナンスの問題を引き起こすものとして捉える必要がある。
バイブコーディングで企業に何が起きているか
業務の現場では既にいくつかの変化が顕在化している。小規模なツール開発は確かに容易になり、Microsoft Excelの延長のような感覚で、簡単な業務支援ツールが短時間で作られるようになった。プロトタイプの作成速度は飛躍的に向上し、「まず作ってみる」が現実的な選択肢となった。
一方で、その限界も明確である。大規模なシステム開発には依然として不向きであり、設計や仕様を絞り込む能力がなければ、すぐに破綻する。AIが生成するコードは一見それらしく動くが品質や一貫性は保証されない。開発の裾野は広がったものの、品質や持続性は確保されていない状態にある。
AIがもたらした内製化の構造変化
マクロの視点で見ると、生成AIは内製化コストを劇的に引き下げた。ノーコードやローコードの延長線上にあるこの流れは、「誰でも作れる」を現実のものとしている。
株式市場においてはAIによる効率化への期待が先行している。一方で企業の実務では、統制されていない開発が増加している。この期待と現場の乖離の中で発生しているのが「シャドー開発」である。
従来のシャドーITは、無断でSaaSを導入するというものであった。しかし現在は、システムそのものを現場が勝手に作る状況に変わりつつある。これは影響範囲が桁違いに大きい問題である。
技術と運用のギャップ
バイブコーディングにおける最も大きな誤解は、「作れること」と「運用できること」が同じであるという認識である。
現場で作られるツールの多くは、バージョン管理がされておらず、テストも十分ではない。開発環境と本番環境が分離されていないケースも多く、いきなり本番で実行されることもある。
さらに問題なのは、コードの再現性である。生成AIに依存した開発では、プロンプトが実質的な仕様書になる。しかし、そのプロンプトが残されていなければ、同じコードを再現できない。さらに、利用するAIモデルの更新によって、同じプロンプトでも異なるコードが生成される可能性がある。これは「仕様書が存在しているにもかかわらず再現できない」という、従来の開発では想定されていなかったリスクである。
結果として、「コードはあるが誰も理解していない」「動いているが直せない」という状態が生まれる。これは従来の技術的負債よりも深刻である。
さらに深刻なのは、「なぜその処理が存在するのか」という意図が失われる点である。従来の技術的負債は「読みにくいコード」であった。しかしバイブコーディングによって生まれる負債は、「意図そのものが消失している状態」である。
コードが動いていたとしても、その背景にある業務要件や判断理由が説明できなければ、修正も再設計もできない。これは単なる保守性の問題ではなく、事業継続の問題に直結する。
セキュリティの質的变化
セキュリティリスクも変質している。従来は人間のミスによって生じる脆弱性が中心であったが、現在はAIが生成する「もっともらしい危険なコード」が問題になっている。認証処理の簡略化やエラーハンドリングの無効化、機密情報のハードコードなどが典型例である。
これらは一見すると正しく動くため、レビューをしなければ見逃される。初心者が書いた危険なコードとは異なり、「それっぽい」コードであるために検知が遅れがちである。
管理対象の変化とガバナンスの再設計
これまでの開発管理は、ソースコードと仕様書を対象としていた。しかしバイブコーディングの時代には、それだけでは不十分である。
管理すべき対象は、プロンプトと生成履歴、利用したモデルといった「生成プロセス」に広がる。「どのような指示」で「どのAIを使い」「いつ生成されたのか」を追跡できなければ、再現性も説明責任も確保できない。ガバナンスはコードの管理から、開発行為そのものの管理へとシフトする。
対外リスクとしての利用規約違反
バイブコーディングが引き起こす問題は社内だけにとどまらない。外部との関係においても重大なリスクを生む。特に問題となるのが利用規約違反の自動化である。APIのレート制限を無視したアクセスや、クロール拒否（robots.txt）を無視したWebスクレイピングなどが、非エンジニアによって無自覚に実行される可能性がある。
AIは合法性和契約条件を考慮せず、動くコードを提示する。その結果、意図せずDoSに近い挙動を引き起こすこともあり得る。従来は一部の技術者に限られていたリスクが、組織全体に拡散している点が重要である。これは「違反の民主化」とも言える現象である。
個人情報とプライバシーの再定義
採用や問い合わせ対応においては、さらに深刻な問題が発生する。履歴書や問い合わせ内容には、個人情報や機密情報が含まれる。これらを生成AIに入力した場合、外部サービスへのデータ送信が発生する可能性がある。しかし、多くの企業ではAI利用を前提としたプライバシーポリシーが整備されていない。「AIを利用する場合があります」といった曖昧な記述では不十分である。
必要なのは、どの処理にAIが使われるのか、外部送信があるのか、データが保存されるのかといった処理フローの明示である。さらに、応募者や利用者からの同意取得の方法も見直す必要がある。AIが評価に関与する場合、その透明性は極めて重要である。
コスト構造の落とし穴
バイブコーディングはコスト削減の手段として語られる傾向があるが、実際にはコスト構造が変化しているだけである。開発コストは確かに下がるが運用コストは増加する。増幅したツールの引き継ぎやバグ修正、仕様変更のたびに発生する再生成作業に加え、AI利用料の積み上がりが発生する。
加えて見落とされがちなのが、AIの利用コストがランニングコストとして発生する点である。ツールの開発時だけでなく、実行のたびにAPIコールが発生する設計になっている場合、利用量の増加に比例してコストが増加する。
一見すると、安価に構築されたツールが利用拡大とともに予期せぬコスト増を引き起こす構造である。短期的にはコスト削減に見えても、中長期的にはキャッシュアウトを増加させる要因になる。
人材要件の逆転
この変化は人材要件にも影響を与える。これまで価値があったのは「コードを書ける人材」であったが、今後は「コードをレビューできる人材」の価値が高まる。設計の妥当性やセキュリティ、データ整合性を判断できる能力が求められる。
ジュニアでも開発らしきことはできるようになるが、その分シニアの負荷は増大する。この構造を理解せずに人材配置をすると、組織の生産性はむしろ低下する。
止まるリスクと復旧不可能性
もう一つ見逃せないのが、業務停止リスクである。外部APIの制限、モデルの変更、料金体系の変更などにより、ある日突然ツールが動かなくなる可能性がある。その際、誰も仕様を理解していなければ、復旧は極めて困難である。これはBCPの観点からも無視できないリスクである。
IT部門が取るべき現実的な対応
IT部門にできることは限られているが、最低限の統制は必要である。
まず、利用範囲の明確化が不可欠である。個人の業務効率化や読み取り専用のツールは許可する一方で、書き込み系や顧客データを扱う処理、基幹システムとの連携は原則禁止とするなどの線引きが必要である。
次に、最低限の開発ルールを設ける必要がある。バージョン管理やテスト環境の分離、作成者と責任者の明確化といった基本的な統制は外せない。
さらに、法務やプライバシー対応も不可欠である。利用規約の確認フローやAI利用ポリシーの整備、プライバシーポリシーの改定など、従来は開発と切り離されていた領域を統合する必要がある。
最後に重要なのが教育である。どの情報をAIに入力してよいのか、何が違反になるのかを具体的に示さなければ、現場は判断できない。
バイブコーディングは、内製化の民主化をもたらす一方で、統制の崩壊を招く可能性を持っている。重要なのは、この技術を使うかどうかではなく、統制できる状態で使えているかどうかである。
現場にとっては、正式な開発プロセスを通すよりも、目の前の業務を解決することの方が優先される。この構造がある限り、バイブコーディングを完全に止めることはできない。
だからこそ、現場の創意工夫を前提としながら、どこまでを許可し、どこからを禁止するのか。その線引きと仕組みを設計できるかが、企業としての分岐点になる。
