Vibeコーディングで現場のAIツールを作る時代——「動く」と「使える」の間にある深い溝

プログラミング経験ゼロの現場担当者が、ChatGPTに「こういうツール作って」と頼んだら、それっぽいコードが出てきた。動かしてみたら、動いた。——これが「Vibeコーディング」と呼ばれる現象の正体だ。

外注すれば数十万〜数百万円かかっていた業務ツールが、自然言語の指示だけで数時間で形になる。中小企業にとって、これは革命的なコスト破壊に見える。実際、建設現場の安全管理や日報集計、写真整理など、「ちょっとしたツール」を自前で作る事例が増えている。

だが、ここで一つ問いたい。「動く」ことと「使える」ことは、同じだろうか？

最近発表された複数の研究が、この問いに冷徹な数字で答えている。結論から言う。Vibeコーディングは強力だが、今のまま現場に放り込むと事故が起きる。特に安全に関わる領域では、致命的な落とし穴がある。

—

85%は動く。だが「正しく動く」かは別の話

最近公開された研究では、Vibeコーディングで生成された450件のPythonスクリプトを対象に、信頼性と安全性が実証評価された。結果はこうだ。

• 約85%のコードが実行可能だった
• しかし、その多くにロジックの欠陥が潜んでいた
• 防御的プログラミング（異常値や想定外入力への対処）がほぼ欠如していた

「動く」のと「正しく動く」のは全く違う。たとえば建設現場で、鉄骨の荷重計算ツールをVibeコーディングで作ったとする。入力値が想定範囲内なら正しい答えが出る。だが、誰かが単位を間違えて入力したとき、エラーも出さずにそのまま計算結果を返す。これが「防御的プログラミングの欠如」だ。

外注で作ったツールなら、入力値チェック、エラーハンドリング、ログ出力が当たり前に入る。Vibeコーディングで生成されたコードには、それがない。見た目は完成品、中身は試作品。ここが最大の盲点だ。

—

「昨日まで動いていたのに」——AIコードのドリフト問題

もう一つ、現場で見落とされがちな問題がある。ドリフトだ。

同じプロンプトを同じAIに投げても、1ヶ月後には違うコードが出てくる。AIモデルは定期的に更新される。学習データも変わる。その結果、以前は正しく動いていたコードが、再生成すると微妙に挙動が変わる。これがドリフトだ。

この問題に対応するため、「VibeDrift」というオープンソースツールが開発された。AI生成コードの品質変化を定量的に測定するためのものだ。

これが意味することは明確だ。Vibeコーディングで作ったツールは、作って終わりではない。定期的に「まだ正しく動いているか」を確認し続ける必要がある。

中小企業の現場で、これができるか。正直、難しい。だからこそ、Vibeコーディングで作っていいものと、作ってはいけないものの線引きが重要になる。

—

セキュリティはさらに深刻——安全なコードはわずか23.8%

さらに厳しいデータがある。

「SecureVibeBench」という新しいベンチマークで、LLMベースのコーディングエージェントが生成するコードのセキュリティが評価された。105のC/C++セキュアコーディングタスクを対象にした結果がこれだ。

• 最も優秀なエージェントでも、正確かつ安全なコードを生成できたのはわずか23.8%

4回に1回も当たらない。これはセキュリティの話だ。バッファオーバーフロー、メモリリーク、インジェクション脆弱性——プロのエンジニアが必ずチェックする項目を、AIは7割以上の確率で見落とす。

もちろん、建設現場の業務ツールでC/C++を使うケースは少ない。Pythonやスプレッドシート連携が主戦場だろう。だが、この数字が示す構造は同じだ。AIは「動くコード」は得意だが、「安全なコード」は苦手。この事実は言語を問わない。

—

じゃあ、中小企業はVibeコーディングを使うなという話か？

違う。むしろ逆だ。使い方を間違えなければ、これほど中小企業に有利な武器はない。

ポイントは「どこに使うか」の選別だ。

Vibeコーディングが向いている領域：

• 日報の自動集計、写真の自動整理など、間違えても人命に関わらない業務
• データの可視化、簡易なダッシュボード作成
• 社内向けの通知ボット、チェックリスト生成
• 「今まで手作業でやっていた30分の作業」を自動化する小さなスクリプト

Vibeコーディングを避けるべき領域：

• 構造計算、荷重計算など安全に直結する計算処理
• 顧客情報や個人情報を扱うシステム
• 外部公開するWebアプリケーション
• 法的な記録として使われるデータ処理

この線引きさえできれば、Vibeコーディングのコスト破壊力は凄まじい。従来、外注で50万〜300万円かかっていた「ちょっとした業務ツール」が、現場の担当者が半日で作れる。しかも、現場の人間が作るから、現場のニーズにぴったり合う。外注先に仕様書を書いて、修正依頼を3回出して、2ヶ月待つ——あの地獄がなくなる。

—

「レビューできる人」が最大のボトルネックになる

とはいえ、一つだけ解決すべき問題がある。生成されたコードをレビューできる人間が、中小企業にはいないということだ。

大企業なら社内にエンジニアがいる。コードレビューの文化もある。中小企業にはそれがない。Vibeコーディングで作ったツールが「なんとなく動いている」状態で運用され続け、ある日突然おかしな結果を出す。そのとき、誰が原因を特定できるのか。

ここに、新しいビジネスの種がある。「Vibeコーディングで作ったツールのレビュー・監査サービス」だ。コードを書く仕事は減る。だが、コードを見る仕事は増える。しかも、中小企業が大量にVibeコーディングを始めれば、その需要は爆発的に増える。

1件あたり数万円のレビューサービスが成立する可能性は十分にある。地方のITベンダーにとって、これは既存の受託開発に代わる新しい収益源になり得る。

—

で、結局どうすればいいのか

まとめる。

1. Vibeコーディングは使え。ただし「間違えても死なない領域」から始めろ。 日報集計、写真整理、社内通知。ここから始めれば、リスクはほぼゼロでコスト削減効果は大きい。

2. 安全・セキュリティに関わる部分は、絶対にVibeコーディングだけで済ませるな。 85%動くは、15%壊れるということだ。安全率が求められる領域で、その確率は許容できない。

3. 作ったら終わりにするな。 AIモデルのドリフトで、昨日まで正しかったコードが明日壊れる可能性がある。月1回でいい、動作確認の仕組みを入れろ。

4. レビューの仕組みを外部に持て。 社内にエンジニアがいないなら、外部のレビューサービスを使え。コード生成のコストが下がった分、レビューに金をかけるのは合理的な投資だ。

Vibeコーディングは、中小企業にとって間違いなく武器になる。だが、武器は使い方を間違えれば自分を傷つける。「動いた」で喜ぶのではなく、「これは本当に正しく動いているか」と疑える現場こそが、この技術の恩恵を最大限に受け取れる。

技術のコストが下がったとき、価値が上がるのは「判断力」だ。何に使い、何に使わないか。その判断ができる中小企業が、次の10年を生き残る。

—