バイブコーディングで作った業務アプリが、
半年後に誰も直せなくなる

生成AIに「勤怠の申請アプリを作って」と話しかけるだけで、動くものが出てくる。バイブコーディングと呼ばれるこの作り方は、2026年にはもう珍しい話ではなくなりました。実際、動きます。問題は動かないことではなく、半年後に誰も直せなくなることです。本記事では、いま実際に何が起きているのかをデータで確認したうえで、「動いた」と「運用できる」の間にある距離を整理します。内製をやめる必要はありません。線を引く場所の話です。

まず、実際に何が起きているのか

Symbiotic Securityが2026年6月に公表した調査が、この問題をはっきり数字にしています。公開されているバイブコーディング製アプリ1,072件を調べたところ、98%にあたる1,046件で、少なくとも1つの脆弱性が見つかりました。うち173件（16%）は、重大度が最も高い分類です。検出総数は6,185件、1アプリあたり平均5.9件でした。

内訳のうち、業務で使うアプリとして深刻なものを挙げます。

• 172件——認証なしでデータを削除できる状態だった
• 172件——認証なしでデータを書き換えられる状態だった
• 39件——データベース全体が誰でも読める状態だった
• 34件——メールアドレス・パスワード・トークンといった列が漏れていた

原因は、作った人の不注意というより仕組みの側にあります。調査は、こうしたコード生成の仕組みが動くアプリは作るが、「誰がどのデータを読み書きできるか」を決める行単位のアクセス制御を設定しないと指摘しています。画面は完成して見える。裏側のAPIには鍵がかかっていない。作った本人には、その差が見えません。

出典: Symbiotic Security「We scanned 1,072 vibe-coded apps: 98% had security flaws」（2026年6月2日）

失敗の形には、決まったパターンがある

トレンドマイクロの分析は、生成されたコードに繰り返し現れる問題を整理しています。頼んでいない依存ライブラリが勝手に組み込まれる。デモ用の危険な既定設定が、そのまま本番に持ち込まれる。平文の資格情報やテスト用トークンが残る。正常系だけが書かれていて、エラー処理・認証の例外・流量制限が抜けている。

そして5つ目に挙げられているのが、技術ではない問題です。責任の所在が拡散する。指示を書いた人、生成したAI、レビューした人、サービスの持ち主。誰がこのコードの持ち主なのかが、はっきりしなくなる。同記事は、根本の原因を「人間が十分に検証しないまま本番へ入れてしまうこと」だと結論づけています。

出典: トレンドマイクロ「バイブコーディングの本当のリスク」（2026年4月23日）

これは一部の不注意な人の話でもありません。Tricentisが6か国2,501名を対象に行った調査では、未テストのコードを本番環境へ投入している企業が世界で約6割、日本では65.6%にのぼりました。理由は、速度を優先する圧力と、生成されるコード量に検証が追いつかないことです。

出典: Tricentis Japan「グローバル企業の60%が未テストコードを本番環境へ投入」（2026年6月5日）

「動いた」と「運用できる」の間にある距離

ここが本質です。「動いた」は正常系が通ったという意味でしかありません。想定した手順で、想定したデータを入れたら、想定した画面が出た。それだけです。

業務で使うということは、この先に一式が付いてきます。誰が見てよくて誰が見てはいけないのか。間違ったデータが入ったらどうなるのか。消してしまったものを戻せるのか。仕様が変わったとき、どこを直せば安全なのか。動かなくなったとき、誰がいつ気づくのか。バイブコーディングが飛ばすのは、まさにこの部分です。飛ばしても最初は動くので、飛ばしたことに気づきません。

半年後に誰も直せなくなる、4つの条件

私たちが見るかぎり、破綻するアプリには共通する条件があります。4つ揃うと、ほぼ確実に手が付けられなくなります。

条件	何が起きるか
作り直せない	手作業の修正が混ざり、指示の履歴も残っていない。同じものをもう一度作れない
壊れたことに気づけない	テストも監視もない。誰かが「使えない」と言ってくるまで分からない
中身を誰も知らない	生成されたコードを読んだ人がいない。直そうとしても、影響範囲が読めない
作った人がいない	異動・退職で担当が消える。引き継ぎ資料は、動くアプリそのものしかない

3つ目は、いま業界で理解負債と呼ばれているものです。コードの品質とは無関係に発生します。AIが完璧に美しいコードを書いていても、読んでいない人が運用している限り、負債は積まれていきます。

内製をやめる必要はない。線を引けばいい

ここまで書くと「やはり素人が作るべきではない」という話に見えるかもしれませんが、そうは思いません。現場の人が自分の困りごとを自分で解決できるようになったのは、間違いなく良いことです。問題は、全部を同じ基準で扱っていることにあります。

使う範囲	必要なもの
自分だけが使う道具	特になし。壊れたら作り直せばよい
部署内で共有する	作り直せること（指示と手順を残す）、消えたときに困らないこと
社外・顧客データ・お金が絡む	認証と権限、バックアップ、テスト、担当者の明示。ここから先は「業務システム」です

一番下の段に上げるときだけ、作り方を変える。この線引きさえあれば、内製の勢いを止めずに事故を防げます。内製化のロードマップでも書いたとおり、段階を飛ばさないことがすべてです。

まず、社内にいくつあるか数える

線を引くにも、対象が分からなければ始まりません。バイブコーディング製のアプリは情シスを通らずに生まれるため、台帳に載っていないのが普通です。心当たりを探すなら、次のあたりから当たると出てきます。

• アプリ開発プラットフォームやクラウドサービスの請求明細——部署の経費で個人契約されていることが多い
• 業務で共有されているURL——チャットに貼られたリンクが、そのまま社内システムになっている
• 「あれ便利だよね」と呼ばれているもの——名前が付いていないアプリほど、台帳から漏れます

見つけたら、まず前掲の3段階のどこに当たるかを判定します。いきなり止める必要はありません。ひとり情シスのように少人数で見ている組織ほど、全部を審査しようとすると回らなくなります。一番下の段に該当するものだけを拾う。それで大半のリスクは落ちます。

よくある質問

Q1. 作った本人に直させればよいのでは？

本人が作れることと、本人が直せることは別です。生成されたコードを読んでいない場合、影響範囲が読めないまま修正することになり、直したつもりで別の場所を壊します。まず「作り直せる状態」に整えるほうが、結果的に早くなります。

Q2. 社内だけで使うアプリなら、認証は不要では？

社内向けのつもりでも、アプリの実体がインターネット上に置かれていれば、URLを知っている人は誰でも到達できます。前掲の調査で「認証なしでデータを削除できる」状態が172件見つかったのは、まさにこの思い込みが原因です。社内向けかどうかは、置き場所ではなく設定で決まります。

Q3. 内製をやめて全部外注に戻すべきですか？

おすすめしません。作るコストが下がった恩恵は本物で、それを手放すと元の速度に戻るだけです。分けるべきは「誰が作るか」ではなく「どこまでの品質を求めるか」です。

外に頼むなら、何を頼むのか

もし外部に相談するとしたら、頼む内容は「代わりに作ってください」ではないほうがいいと考えています。すでに動くものがあるなら、それは資産です。捨てて作り直すのは、たいてい無駄が大きくなります。

頼むべきは、自分たちで安全に作り続けられる状態にすることです。権限とバックアップを入れる。壊れたら気づく仕組みを置く。作り直せる形に整える。そのうえで、次からは自分たちで回せるようにする。私たちが現場にAIチームを配置する形にこだわっているのは、この種の仕事が、外から仕様書を受け取って納品するやり方では成立しないからです。

まとめ——速さを捨てずに、壊れ方を変える

バイブコーディングが悪いのではありません。作るコストが劇的に下がった一方で、運用するコストは何も下がっていない。この非対称に、まだ多くの組織の運用が追いついていないだけです。

1,072件の98%という数字は、たまたま不注意な人が集まった結果ではなく、標準的な作り方が標準的に生む結果です。だとすれば、個人の注意力ではなく、仕組みで防ぐしかありません。作る速さはそのままに、壊れ方だけを変える。線を引くとは、そういう意味です。