IT部門のための「バイブコーディング統制術」 現場の工夫を殺さず組織を守るにはどうすべき？：久松剛のIT業界裏側レポート

生成AIの普及に伴って広がるバイブコーディング。現場主導の開発が進む一方、野良開発や仕様不全、セキュリティなどIT部門が直面するリスクが表面化しています。現場の工夫を生かしつつ組織を守る統制を深掘りします。

[久松 剛，エンジニアリングマネージメント]

この連載について

DX推進、生成AI技術の進化が加速する今、企業のIT部門は戦略的な役割への変化が求められ、キャリアの転換点に立たされています。この現状を変え、真に企業価値を高める部門となるには新たな戦略が必要です。

本連載では、博士としてインターネット技術を研究し、情シス部長、SRE、エンジニアマネジャーとしてIT組織の最前線を知る久松剛氏が、ニュースの裏事情や真の意図を分析します。一見関係ないニュースもIT部門目線の切り口で深掘りし、IT部門の地位向上とキャリア形成に直結する具体策を提示します。

「久松剛のIT業界裏側レポート」のバックナンバーはこちら

　生成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コールが発生する設計になっている場合、利用量の増加に比例してコストが増加します。

　先立ってClaudeの一部ユーザーに対するProプラン提供停止が話題になりましたが、サービス提供社による突然の不利益改変は今後も十分にあり得ます。

　一見すると、安価に構築されたツールが利用拡大とともに予期せぬコスト増を引き起こす構造です。短期的にはコスト削減に見えても、中長期的にはキャッシュアウトを増加させる要因になります。

人材要件の逆転

　この変化は人材要件にも影響を与えます。

　これまで価値があったのは「コードを書ける人材」でしたが、今後は「コードをレビューできる人材」の価値が高まります。設計の妥当性やセキュリティ、データ整合性を判断できる能力が求められます。

　ジュニアでも開発らしきことはできるようになりますが、その分シニアの負荷は増大します。この構造を理解せずに人材配置をすると、組織の生産性はむしろ低下します。

止まるリスクと復旧不能性

　もう一つ見逃せないのが、業務停止リスクです。

　外部APIの制限、モデルの変更、料金体系の変更などにより、ある日突然ツールが動かなくなる可能性があります。その際、誰も仕様を理解していなければ、復旧は極めて困難です。これはBCPの観点からも無視できないリスクです。

IT部門が取るべき現実的な対応

　IT部門ができることは限られていますが、最低限の統制は必要です。

　まず、利用範囲の明確化が不可欠です。個人の業務効率化や読み取り専用のツールは許可する一方で、書き込み系や顧客データを扱う処理、基幹システムとの連携は原則禁止とするなどの線引きが必要です。

　次に、最低限の開発ルールを設ける必要があります。バージョン管理やテスト環境の分離、作成者と責任者の明確化といった基本的な統制は外せません。

　さらに、法務やプライバシー対応も不可欠です。利用規約の確認フローやAI利用ポリシーの整備、プライバシーポリシーの改訂など、従来は開発と切り離されていた領域を統合する必要があります。

　最後に重要なのが教育です。どの情報をAIに入力してよいのか、何が違反になるのかを具体的に示さなければ、現場は判断できません。

　バイブコーディングは、内製化の民主化をもたらす一方で、統制の崩壊を招く可能性を持っています。重要なのは、この技術を使うかどうかではなく、統制できる状態で使えているかどうかです。

　現場にとっては、正式な開発プロセスを通すよりも、目の前の業務を解決することの方が優先されます。この構造がある限り、バイブコーディングを完全に止めることはできません。

　だからこそ、現場の創意工夫を前提としながら、どこまでを許容し、どこからを禁止するのか。その線引きと仕組みを設計できるかが、企業としての分岐点になります。

それは本当に「効率化」なのか

　そのツールが止まったとき、誰が直せるのでしょうか。

　そのコードは再現可能でしょうか。

　外部サービスとの契約や利用規約を守れているでしょうか。

　採用や問い合わせのプロセスにおけるAI利用を、説明できる状態にあるでしょうか。

　それは本当に「効率化」なのでしょうか。それとも、見えない負債を先送りしているだけなのでしょうか。

著者プロフィール：久松 剛氏（エンジニアリングマネージメント　社長）

　エンジニアリングマネージメントの社長兼「流しのEM」。博士（政策・メディア）。慶應義塾大学で大学教員を目指した後、ワーキングプアを経て、ネットマーケティングで情シス部長を担当し上場を経験。その後レバレジーズで開発部長やレバテックの技術顧問を担当後、LIGでフィリピン・ベトナム開発拠点EMやPjM、エンジニア採用・組織改善コンサルなどを行う。

　2022年にエンジニアリングマネージメントを設立し、スタートアップやベンチャー、老舗製造業でITエンジニア採用や研修、評価給与制度作成、ブランディングといった組織改善コンサルの他、セミナーなども開催する。

Twitter : @makaibito