「動けばいい」で作ったものは、半年後に誰が直すのか──バイブコーディングを仕事で使うための8つのコツ

「こういうアプリが欲しい」と日本語で伝えるだけで、AI がコードを書いて、動くものができあがる。

バイブコーディングと呼ばれるこのやり方は、もう一部の実験ではありません。2025 年 2 月に AI 研究者アンドレイ・カーパシーがこの言葉を作り、同年には Collins Dictionary が「Word of the Year」に選出。2025 年末までに、世界で書かれるコードの 41% が AI 生成になったとされています。

社内でも、誰かが「試しに作ってみた」ツールが動いているかもしれません。そして——それは高い確率で、本番で使われ始めています。

この記事は「やめておけ」という話ではありません。やるなら、どこで痛い目を見るかを先に知っておこう、という話です。

数字で見る、いまの現実

セキュリティ企業の調査結果が、状況をよく表しています。

調査項目	結果
調査対象	公開稼働中の、バイブコーディングで作られたアプリ 5,600 件
見つかった重大な脆弱性	2,000 件超
外部に露出していた秘密情報	400 件
重大な欠陥を抱えたまま公開されていた割合	およそ 3 本に 1 本
AI 生成コードの欠陥率	人間が書いたコードの 2.74 倍

3 本に 1 本が、誰でも悪用できる状態で公開されていた。しかも「動いている」ので、作った本人は問題に気づいていません。

ここで強調したいのは、AI が無能だという話ではないということです。2.74 倍という数字も、裏を返せば人間が書いたコードにも欠陥はあります。問題は倍率そのものより、チェックする人がいないまま量産されるという構造にあります。

本当の危険は、コードの品質ではない

セキュリティベンダーの分析で、私がいちばん重要だと思った指摘があります。

バイブコーディングの本質的なリスクは、AI が安全性の低いコードを生成することではない。利用者である人間が、コードを十分に検証せずに本番環境に導入し、リリースしてしまうことにある。

さらにこう続きます。

最大のリスクの一つは、コードの所有者が存在しないことではなく、責任の所在が分散してしまうことである。

ここです。中小企業でいちばん深刻なのは、この 2 つ目だと思います。

「作った人が、責任者ではない」状態が生まれる。営業の誰かが自分の作業を楽にするために作ったツールが、いつのまにか部署全体で使われている。作った本人は「便利だから使ってもらってるだけ」のつもり。上司は「現場が勝手にやっていること」と思っている。誰も、それを保守する責任を持っていない。

そして半年後、その人が異動するか退職します。

技術的負債の記事で「あの人しか分からないシステムは変動金利型の借金だ」と書きました。バイブコーディングは、その借金を、これまでにない速さで作れるようにしたとも言えます。

いちばん大事な線引き:捨てられるか、捨てられないか

コツの前に、これだけは先に決めてください。そのコードは、捨てられるものか。

	捨てられるもの	捨てられないもの
例	一度きりの集計、試作、社内の実験	業務で毎日使うもの、顧客データを扱うもの、外部公開するもの
求められる品質	動けばいい	保守できること、安全であること
バイブコーディング	全面的に向いている	そのままでは危険
判断基準	明日消えても誰も困らないか	止まると業務が止まるか

バイブコーディングが素晴らしいのは、左側の領域です。今まで「わざわざ作るほどでもない」と諦めていた小さな道具が、数十分で手に入る。ここは全力で使うべきだと思います。

問題は、左側のつもりで作ったものが、いつのまにか右側に移ることです。試作のつもりが、毎日使われている。実験のつもりが、顧客の名前が入っている。

この移動が起きたことに、誰も気づかない。 これがバイブコーディング最大の落とし穴です。

仕事で使うための、8 つのコツ

1. 作る前に「これは捨てられるか」を宣言する

上の線引きを、作り始める前に決めます。捨てられないものだと分かっているなら、最初から検証の手間を織り込む。ここを曖昧にしたまま作ると、後から判断できなくなります。

2. 秘密情報を、そもそも置かない

パスワード、API キー、顧客データ。AI に渡すコードの中に書かない。これが最も効きます。

セキュリティの専門家が指摘している通り、いま重要なのは「危険なことを禁止する」より「漏洩しても被害が限定される設計にする」ことです。禁止は破られますが、そもそも置いていなければ漏れようがありません。

3. 動いた瞬間に手を止めて、AI 自身に点検させる

「動いた！」の直後がいちばん危ない瞬間です。そこで一度止めて、こう聞いてください。

「このコードのセキュリティ上の問題点を、深刻な順に挙げて。特に、外部から悪用できる箇所と、秘密情報が漏れる可能性がある箇所を」

書かせた AI に点検させるのは矛盾しているようですが、指示すれば実際に見つけます。研究でも、セキュリティを意識させるプロンプトを与えるだけで、危険なコード生成が大幅に減ることが示されています。聞かなかったから出てこなかっただけなのです。

4. データを壊す操作は、人が実行する

削除、上書き、本番データへの書き込み。これらを AI に自動実行させない。提案までは AI、実行は人。

ループの記事で書いた「ゲート」の考え方そのものです。取り返しがつく操作と、つかない操作の間に、必ず人を置く。

5. 「なぜこう書いたか」を説明させる

コードが読めなくても構いません。日本語で説明させて、その説明が理解できるかを見てください。

説明が腑に落ちないなら、それは後で必ず困ります。「なんとなく動いているけど、なぜ動いているか分からない」ものは、壊れたときに直せません。

6. 変更の履歴を残す

動いていたものが動かなくなったとき、戻せるかどうかが命綱になります。Git の記事で書いた通り、VS Code なら組み込みの機能で、ボタン操作だけで履歴を残せます。

バイブコーディングは試行錯誤が多いぶん、履歴の価値がいちばん高い使い方でもあります。

7. 公開範囲を、最初に絞る

「URL を知っている人しか来ない」は、セキュリティではありません。認証をかける、社内ネットワークからのみアクセスできるようにする、といった実際の制限をかけてください。

調査で見つかった 400 件の秘密情報の露出も、多くは「まさか見られると思っていなかった」ものだったはずです。

8. 保守する人を、最初に決めておく

これがいちばん重要かもしれません。

「誰が直すのか」を、作る前に決める。決められないなら、それは作ってはいけないものか、外に頼むべきものです。

責任の所在が分散するという問題は、技術では解決できません。名前を書いておくだけで防げます。

発注する側にも、注意点があります

もう一つ、中小企業でこれから増えると思われる問題に触れておきます。

「AI で作れるなら、安く早くできるはずだ」——この期待が、発注の場面で無自覚に働くケースです。

安く早く上がったものが、納品後にこうなることがあります。

改修できない——作った人以外に構造が分からない
監査に通らない——セキュリティ要件を満たしていない
運用コストが跳ね上がる——動かし続けるために人手が要る

発注した業務システムが現場で使われない理由の記事で書いた話と、根は同じです。安さの理由を確認せずに発注すると、支払いが後ろにずれるだけになります。

見積もりを見るときは、「この費用に、検証と保守しやすさの担保は含まれていますか」と一言聞いてみてください。答えられない相手なら、その分は後で自社が払うことになります。

まとめ

バイブコーディングはもう主流。2025 年末には世界のコードの 41% が AI 生成
一方で、公開中の AI 製アプリ 5,600 件の調査では約 3 本に 1 本が重大な脆弱性を抱えたまま稼働していた
本当の危険は AI の性能ではなく、検証せず本番に出すことと、責任の所在が消えること
最重要の線引きは「捨てられるものか、捨てられないものか」。そして左側のつもりが右側に移るのが最大の落とし穴
8 つのコツ：捨てられるか宣言する／秘密情報を置かない／動いた瞬間に点検させる／壊す操作は人が実行／説明させる／履歴を残す／公開範囲を絞る／保守する人を決める

バイブコーディングは、中小企業にとって間違いなく追い風です。今まで諦めていたものが作れるようになった。ただ、作れることと、任せられることは別でした。

Acetyl:Tech は、社内で作ったものを「業務で任せられる状態」にするところから支援しています。 動いてはいるけれど不安がある、というご相談も承ります。詳しくは「業務アプリ開発」のページをご覧ください。