バイブコーディングで作ったAIを、本番品質に立て直す — 「速く作れる」の後に残る仕事

動くものは、できてしまった。社内の誰かがバイブコーディングで組んだ業務AIかもしれないし、「AIで安く早く作れます」という会社に発注した納品物かもしれません。デモは動く。それらしい画面もある。けれど、これを本番に出していいと、誰も言い切れない。直そうにも、作った本人にも中身を説明できない。そして次の投資の話になると、前の失敗が頭をよぎって決められない——この記事は、その状態から立て直すための記事です。

先に立場を明かしておくと、私たち自身、日常的にAIにコードを書かせています。この速さは本物で、いまさら手放す理由はありません。ただ、受託の現場で「動くが本番品質ではないAI」の立て直しを引き受けてきた経験から、速く作れることが何を保証して、何を保証しないのかは、はっきり分かっているつもりです。バイブコーディングそのものを否定する記事ではありません。「作ってしまった後」の話をします。

本当のリスクは「AIが書くこと」ではない

バイブコーディングのリスクを啓発する記事は、すでにたくさんあります。トレンドマイクロは「本質的なリスクは、AIが安全性の低いコードを生成することではなく、人間が十分な検証なく本番導入することにある」と整理しています（バイブコーディングの本当のリスク, 2026）。数字も出ています。Veracodeが100を超えるLLMに80のコーディングタスクを解かせた実測では、生成コードの45%がセキュリティテストに不合格でした（2025 GenAI Code Security Report）。しかも新しく大きいモデルほど安全になる、という傾向は見られなかった——つまり「次のモデルを待てば解決する」問題ではありません。

ただ、こうした記事の多くは「これから作る人」への注意喚起です。検索してこの記事にたどり着いた方の多くは、もう作ってしまっているはずです。必要なのはリスクの一覧ではなく、ここからどうするかの順番だと思います。

「動くけど不安」の正体 — 生成されなかった3つのもの

バイブコーディングが速いのは、実装（コードを書く工程）が速いからです。ところがソフトウェアを本番で使い続けるために必要なものは、実装のほかに少なくとも3つあり、これらはプロンプトからは自動で生まれません。

仕様 — 何が正しい動作なのかの定義。「なんとなく良さそうに動く」と「この入力にはこう応答すると決まっている」の差です。仕様がないと、直すたびに別の何かが壊れ、壊れたことにも気づけません。

検証 — テストと評価。とくにAIシステムでは、精度を測る評価セットがないと「改善したつもりが悪化した」を検出できません。Veracodeの45%という数字が示すのは、生成されたものを検証なしで信じてはいけない、という単純な事実です。

運用 — 直せる構造と、見張る仕組み。責任の所在がプロンプトを書いた人・AI・レビュー担当の間で分散し、問題が本番で見つかったときには開発時の文脈が失われている——これはトレンドマイクロが指摘する典型的な失敗パターンです。

症状から、どれが欠けているかは大まかに引けます。

立て直しの順番 — 全部を作り直す前に

相談を受けたとき、私たちが「全部作り直しましょう」から入ることは、まずありません。作り直しは選択肢の一つであって、結論を先に決めると判断を間違えます。順番はこうです。

① 棚卸し。 コードは読める状態か。データ（学習・参照用の文書、設定、プロンプト）は手元にあるか。仕様書はなくても、要件のメモやチャット履歴のような「仕様の痕跡」は残っていないか。外注品なら、コード・データ・モデルの権利は自社にあるか。ここで「そもそも引き継げるものが何もない」と分かることもあり、それはそれで判断材料です。

② 守る線を決める。 品質改善より先に、事故だけは防ぎます。認証・認可は効いているか、外部入力の扱い、依存パッケージ、秘密情報（APIキーなど）の置き場所。バイブコーディング特有の攻撃面はセキュリティ専門会社の整理が参考になります（GMO Flatt Security, 2026）。本格的な監査は専門会社の領分ですが、最低線の点検だけでも「知らないまま運用する」よりずっとましです。

③ 測れるようにする。 ここが立て直しの中心です。実際の業務で来る入力を集めて、正解の基準を決め、いまのシステムに通す。すると「思ったより使える」のか「土台から駄目」なのかが数字で見えます。この物差しがないまま直し始めると、当て推量のループに入ります。作り方は評価セットの記事にまとめました。

④ 直すか、作り直すかを決める。 評価の数字と構造の健全さが揃うと、ようやくこの判断ができます。目安はこうです。

大事なのは、作り直す場合でも①〜③は無駄にならないことです。棚卸しした資産と評価セットは、次の開発の要件定義そのものになります。前回「なんとなく」で作って失敗したものを、今度は物差し付きで作れる。

立て直しの中身は、AIが書いたコードでも変わらない

正直に書くと、私たちが引き受けてきた立て直しは「AIが書いたかどうか」で難易度が変わったことはあまりありません。変わるのは欠落のパターンではなく量です。商社の文書検索では正答率38.8%の状態から評価セットを作るところから始めて93.6%まで、法令ナレッジでは合格率65%から約91%まで積み直しましたが、どちらも最初にやったのはコードを書くことではなく、測り方と土台（データ・検索・評価・運用の4層）を整えることでした。バイブコーディングで作られたものは仕様と検証の欠落が極端に出やすい、というだけで、処方は同じです。全体の診断の仕方はRAG精度の診断ガイドにあります。

二度目の失敗を防ぐ — 次に作るときの条件

立て直しの相談で一番よく聞くのは「次も失敗したらと思うと決められない」という言葉です。もっともだと思います。二度目を防ぐ条件は、実はシンプルです。

• 検収を評価セットで決める — 「なんとなく動く」ではなく「この評価セットで合格ラインを超えたら検収」と最初に合意する。作る側の私たちにとっても、これが一番健全です。
• 権利を最初に確認する — コード・データ・モデル・プロンプトの権利が自社に残る契約か。ここが曖昧だと、次の乗り換えも立て直しもできなくなります。
• 運用まで見積もりに入っているか — 納品後、誰が直すのか。精度が落ちたことに誰が気づくのか。PoC止まりの記事に書いた通り、ここが空欄のままの「安い」は、後で高くつきます。

「安くて速い」自体は悪ではありません。私たちもAIで速く作ります。違いは、仕様・検証・運用を最初から工程に入れているかどうかだけです。

立て直しチェックリスト（保存版）

• コード・データ・仕様の痕跡・権利の棚卸しをしたか。
• セキュリティの最低線（認証・入力・依存・秘密情報）を点検したか。
• 実際の業務入力で評価セットを作り、いまの品質を数字にしたか。
• 「直すか作り直すか」を、感覚ではなく数字と構造で判断したか。
• 次の開発で、検収基準（評価セット）・権利・運用の担い手を最初に決めたか。

症状を聞かせてください

「動くけど不安」「作った本人がいない」「外注品を引き継げるか分からない」——症状が分かれば、どこから立て直すか、当たりはつけられます。発注を前提としない30分のオンライン相談です。立て直しを含むサービスの形はAI/RAG精度設計サービスにまとめています。

参考文献

• Trend Micro (2026) バイブコーディングの本当のリスク — trendmicro.com
• Veracode (2025) 2025 GenAI Code Security Report — veracode.com（100超のLLM×80タスクで45%がセキュリティテスト不合格。2026年春の追試でも傾向は継続）
• GMO Flatt Security (2026) バイブコーディングのセキュリティリスク7選 — blog.flatt.tech

この記事は、AIツールを活用して作成し、Cognisant編集部がファクトチェック・編集・監修を行っています。掲載している数値は、出典を明記した公開調査と、実際の支援案件で計測した公開可能な実績です。