AIに開発を任せて分かった、バイブコーディングの落とし穴6つと防ぎ方
目次 ［非表示］
私たちは、実装の多くをAIコーディングエージェントに任せている会社です。速く作れることを実感している一方で、AIの「完了しました」をそのまま完了とは扱いません。別のAIと人が、差分・コマンドの結果・実際の挙動を確かめてから先へ進めます。
バイブコーディングで作られた公開Webアプリを調べた論文を読み、そこに示されたAIの限界は、私たちが日々の開発で見てきた穴と重なると感じました。この記事では論文の要点を短く確認したうえで、私たちが実際に何を見て、どう止め、どんなルールにしたのかを書きます。AIを使わないためではなく、使っているからこそ必要になった確認の話です。
この記事で分かること
- 公開Webアプリ200本を調べた論文の要点
- AIで開発する私たちが、実際の確認で止めた6つの落とし穴
- AIの速さを生かしながら、確認を省かないためのルール
- 社内ツールを使い始める前に聞きたい5つの質問
論文が示した3つの数字と限界
論文「Understanding the (In)Security of Vibe-Coded Applications」は、AIが書いたコミットとコード行がどちらも90%以上のオープンソースアプリを集め、公開中のWebアプリから無作為に200本を監査しました。
91.0%
監査した200本のうち、少なくとも1件の脆弱性が見つかった割合
1,186件
200本から確認された脆弱性の総数
65.77%
見つかった脆弱性のうちCriticalまたはHighの割合
多かった型は、アクセス制御の不備、インジェクション、認証の不備の3つです。論文は背景を、AIが以前の約束を保持・反映しきれない「記憶」、目の前の動作やエラー解消を優先する「目的」、明文化されていない安全要件や正しい技術前提を欠く「知識」の限界に整理しています。
数字の範囲：91.0%は特定の2種類のAIエージェントの痕跡から集めた公開アプリ200本で「脆弱性が見つかった割合」です。攻撃被害の割合でも、AIで作った全アプリへそのまま一般化できる数字でもありません。
AIに開発を任せて実際に見た6つの落とし穴
次の6例は、AIを使った開発の途中で私たちが実際に確認したものです。いずれもAIを責めるための例ではありません。出力を完成品ではなく確認対象として扱い、人の確認で先へ進めなかったから見つけられました。
1動かしていないテストの「全件合格」
起きたこと：「テストはすべて通った」と報告されたものの、実際にはテストを動かす環境がなく、1件も実行されていませんでした。
人の確認でどう止めたか：実行環境と実行ログを確かめ、報告ではなく手元で再現できた結果だけを合格としました。
2失敗しているのに「OK」
起きたこと：型チェックやテストが動かない状態にもかかわらず、作業結果は「OK」と報告されました。
人の確認でどう止めたか：人が同じコマンドを流し直して失敗を確認し、通過条件を満たしていないものとして戻しました。
3現実と違うモックでの合格
起きたこと：実際のサービスでは返らない値を返すモックが使われ、見かけ上はテストが通っていました。
人の確認でどう止めたか：本物の入出力条件とテストの前提を照合し、現実に起きない成功条件をテストから外しました。
4テストを通すための共通コード変更
起きたこと：目の前のテストを通すため、他の機能も使う共通コードまで書き換えられていました。
人の確認でどう止めたか：テスト結果だけでなく差分と影響範囲を見て、関係のない共通部分への変更を切り離しました。
5補助ツール都合の中核変更
起きたこと：補助的な確認ツールを作る依頼から、全利用者が通る中核部分まで変更が広がりました。
人の確認でどう止めたか：補助目的に対して影響が大きすぎると判断し、中核の変更を差し戻しました。
6有用な指摘に混ざる誤報
起きたこと：AIによるセキュリティ監査は有用な候補を出す一方、コード上は成立しない指摘も混ざりました。
人の確認でどう止めたか：指摘を結論にせず、人と別のAIが1件ずつコードを追い、成立しない候補を除きました。
論文の3つの限界と、私たちの経験の対応
論文の分類は、私たちの経験を振り返るための言葉としても使えます。ただし、すべてを一対一で説明できるわけではありません。無理なく対応づけられる範囲を表にしました。
| 限界 | 論文の説明 | 私たちが見た形 |
|---|---|---|
| 記憶 | 以前の約束を変更全体へ反映しきれず、後回しの作業も抜ける | 一部の結果だけで完了と判断すると、実行環境や実際の入出力といった前提が確認から落ちる |
| 目的 | 目の前で動くことやエラー解消が、安全性より優先される | テストを通すための共通コード変更や、補助ツールの都合による中核変更として現れた |
| 知識 | 明文化されていない安全要件や、正しい技術前提を取りこぼす | 現実には返らない値を前提にしたモックや、監査で実際のコード経路を確認しない指摘に表れた |
この整理から分かるのは、「AIに注意深く作ってと頼む」だけでは確認の代わりにならないことです。AIが何を見落としやすいかを前提に、実行結果、差分、実際の経路を別々に確かめる必要があります。
落とし穴を防ぐ6つのルール
1. 完了報告を実行結果に置き換える
「完了」「全部通った」は、同じコマンドを人または統括役が自分の環境で流し直すまで確定しません。言葉ではなく、再現できる結果を判定材料にします。
2. 既存ファイルの差分を必ず見る
テストが通っても、関係のない機能が守られたとは限りません。変更理由と差分を照らし、依頼範囲を越えた書き換えがないかを確認します。
3. 書いた会話にレビューを閉じない
同じ会話は、実装時の前提や思い込みを引き継ぎます。別の会話のAIと人が、前提を共有しすぎない状態で読み直します。
4. 補助ツールのために中核を変えない
確認を楽にする変更が、製品本体のリスクを増やしては逆効果です。中核に触れる案は止め、補助側で完結する方法を先に探します。
5. 安全の基準と最終判断は人が持つ
AIには探索や実装の手数を任せますが、何を満たせば出してよいかは人が決めます。根拠が足りないときに止めるのも人の役割です。
6. 判定は全組み合わせで確かめる
権限のような判定ロジックは、代表例だけでは境界条件を落とします。考えられる組み合わせを列挙してテストする方法を、技術ブログ第1弾で紹介しています。
セキュリティ監査でも、AIの指摘は「候補」
私たちの定期的なセキュリティ監査では、認可、認証、入力の注入、ファイル・外部通信の4観点に分けて確認します。AIは広い範囲を並列に探す役として有効ですが、指摘には誤報も混ざります。そのため、監査は候補を出したところから始まります。
AIが出した候補は、人と別のAIが1件ずつコードの経路を確かめ、インフラ設定と実データでも成立するかを裏取りしてから直します。修正後は挙動と既存機能への影響をテストで確認します。
ロフタルはISO/IEC 27001:2022（ISMS）認証を取得しています。初回登録は2024年1月19日、認証機関はJQA（日本品質保証機構）、登録番号はJQA-IM2071、登録範囲は「WEB、スマホ関連の受託開発及びノーコードデータベースサービス」です。認証は管理体制の事実であり、個々の実装に穴がないことを保証するものではありません。だからこそ、上の確認を繰り返します。
社内ツールを使い始める前の5つの質問
コードを読めるかどうかにかかわらず、利用開始前に次の5問を確認します。答えが曖昧なら、その場で安全だと解釈せず、確認できる人と根拠を探します。
確認する5問は、社外から接続できるか、機密情報を扱うか、見える範囲は正しいか、入力と秘密情報は安全か、直す・止める人はいるか、の順に見ていきます。図の補足にある観点（接続経路・データの種類・閲覧範囲・入力値と鍵・運用後の担当）を、それぞれの根拠と一緒に確かめます。
この5問は専門的なセキュリティレビューの代わりではなく、確認漏れを見つける入口です。すべてに答えられても安全の保証にはなりません。公開範囲、扱う情報、利用者が変われば、必要な確認も見直します。
基盤の上で作るという選択肢
社内ツールをAIで一から作る場合、認証、権限、入力の検証、秘密情報の扱いまで自分たちで設計し、確かめ続けます。既存の基盤を使えば、用意された機能を利用し、自社で設計・検証する範囲を減らせます。
ピジョンクラウドには、組織・ユーザーごとのテーブル閲覧・編集権限、データごとの閲覧・編集権限、IPアドレスによるアクセス制限、クライアント証明書（有料オプション）があります。認証や権限を一から作らずに済むことは、確認範囲を絞る助けになります。
ただし、基盤を使えば自動的に安全になるわけではありません。誰にどの権限を与えるか、接続元をどう制限するか、利用後に誰が見直すかという設定と運用の確認は残ります。
まとめ
この記事の要点
- AIの「完了」は、同じコマンドの再実行と差分確認を経て初めて完了になる
- AIの速さは、別のAIと人による反証、影響範囲の確認、最終判断と組み合わせる
- 自作でも既存基盤でも、安全の基準と設定・運用を確かめる人は必要になる
私たちはAIに実装の多くを任せています。だからこそ、AIが速く進めた分を無条件に受け取るのではなく、確かめる工程を開発の一部として扱います。「作れた」と「出してよい」の間に、再現できる証拠と人の判断を置く。それが、AIを継続して使うための現実的な分担だと考えています。
よくある質問
Q. AIで作ること自体を避けるべきですか？
私たちはAIに実装の多くを任せています。避けるのではなく、完了報告を再実行し、差分を見て、別のAIと人が確認する前提で使います。
Q. テストが通れば公開してよいですか？
テストだけでは決めません。テストの前提、実行ログ、既存ファイルの差分、影響範囲を確認し、安全の基準を満たすかを人が判断します。
Q. 既存の基盤を使えば確認は不要ですか？
不要にはなりません。一から設計・検証する範囲は減らせますが、権限や接続制限の設定、利用者の変更、運用後の見直しは残ります。
出典
- Junquan Deng, Zhiyu Fan, Ruijie Meng, Understanding the (In)Security of Vibe-Coded Applications（arXiv:2606.23130）
- ピジョンクラウドのセキュリティへの取り組み
- 権限判定を「全組み合わせ」で検証した話（技術ブログ第1弾）
- AIが自律的に脆弱性を突く時代──Anthropic Mythos と、中堅企業がいま着手すべき"レガシー刷新"（攻撃側の視点から見た関連記事）
データ管理、もっと簡単に。
Excel・Access・スプレッドシートの課題を、ノーコードのWebデータベース「PigeonCloud」が解決します。
月額5,500円〜（5ユーザー）、30日間無料でお試しいただけます。
