AI開発アンチパターン 2025年6月1日

「動いたからOK」が招く破滅：テストなき開発の末路

「動いた」 この言葉は、開発者にとって最も心地よい言葉の一つです。 しかし、vibe codingにおいて「動いた」は、**最も危険な言葉** でもあります。 なぜなら、「動く」ことと「正しい」ことは、**まったく別のこと** だからです。

川

川西智也

合同会社ロイヤルピース 代表

アンチパターン②「動いたからOK」

AI開発の罠：動作確認だけでは不十分

「動いた」

この言葉は、開発者にとって最も心地よい言葉の一つです。

しかし、vibe codingにおいて「動いた」は、最も危険な言葉 でもあります。

なぜなら、「動く」ことと「正しい」ことは、まったく別のこと だからです。

AI生成コード：「動く」と「正しい」の違い

「動く」コード:

  • 構文エラーがない
  • 実行時エラーが出ない
  • 期待した出力が得られる（テストしたケースで）

「正しい」コード:

  • すべてのエッジケースを処理
  • セキュリティが考慮されている
  • パフォーマンスが最適化されている
  • 保守性が高い
  • 他の部分と一貫性がある

AIが生成するコードは、「動く」ことはほぼ保証されます。しかし、「正しい」かどうかは まったく別の問題 です。

Tea事件の教訓

別記事で紹介したTea Dating App事件を思い出してください。

アプリは「動いて」いました。ユーザーは登録でき、投稿でき、コメントできました。

しかし、Firebase認証が設定されていませんでした。

結果:

  • 72,000枚の画像が流出
  • 13,000枚の身分証明書が流出
  • 4chanとBitTorrentで拡散
  • 被害者の位置情報がGoogle Mapsで公開

「動いたからOK」で本番にデプロイした結果です。

権限システム事件の教訓

別記事で紹介した権限システム事件も、同じパターンでした。

合格した項目:

  • 開発環境での動作 ✓
  • 単体テスト ✓
  • 統合テスト ✓
  • 初期QAテスト ✓

発覚した問題:

  • 非アクティブ化されたアカウントがバックエンドツールにアクセス可能

テストは「正常系」を確認していました。「動く」ことは確認できました。しかし、「正しい」かどうかは確認されていませんでした。

なぜAIは「動く」コードを書くのか

AIは「動く」コードを書くのが得意です。その理由を理解しましょう。

AIが学習したもの:

  1. 大量のコード例

    • GitHubのオープンソースコード
    • Stack Overflowの回答
    • チュートリアル、ドキュメント

  2. 「動く」コードの特徴

    • 構文的に正しい
    • 一般的なパターンに従う
    • エラーなく実行できる

AIが学習していないもの:

  1. ビジネスロジック

    • あなたのアプリ固有の要件
    • エッジケースの処理

  2. セキュリティ要件

    • 明示的に要求されない限り考慮しない
    • 「当たり前」のセキュリティ対策

  3. パフォーマンス最適化

    • 大規模データでの動作
    • 負荷時の挙動

AI生成コードの「動作確認」の限界

典型的な動作確認は、以下のようなものです。

よくある動作確認:

  1. ブラウザで画面を開く
  2. フォームにテストデータを入力
  3. 送信ボタンを押す
  4. 期待した結果が表示される
  5. 「動いた！」

確認できていないこと:

  • 空のデータを入力したらどうなるか
  • 非常に長いデータを入力したらどうなるか
  • SQLインジェクションを試したらどうなるか
  • 認証なしでAPIを叩いたらどうなるか
  • 1000人が同時にアクセスしたらどうなるか

「動作確認」は、表面的なチェック に過ぎません。

プロトタイプと本番の混同

vibe codingで最も危険なパターンの一つが、プロトタイプをそのまま本番にする ことです。

プロトタイプの目的:

  • アイデアの検証
  • UIの確認
  • フィードバックの収集

プロトタイプに許されること:

  • セキュリティの省略
  • エラー処理の省略
  • パフォーマンス最適化の省略

本番に必要なこと:

  • セキュリティ対策
  • エラー処理
  • パフォーマンス最適化
  • 監視、ログ
  • バックアップ

プロトタイプが「動いた」からといって、本番に使えるわけではありません。

Cursor CEO の警告

Cursor自身のCEO、Michael Truellはこう警告しています。

“If you close your eyes and you don’t look at the code and you have AIs build things with shaky foundations as you add another floor, and another floor, and another floor, things start to kind of crumble.” 「目を閉じてコードを見ずに、AIに不安定な基礎の上に階を増やさせると、崩れ始める」

「動いた」と思って次の階を建てる。また「動いた」と思って次の階を建てる。しかし、基礎が不安定なので、最終的には 崩れる のです。

Java創造者の警告

James Gosling（Java創造者）も同様の警告をしています。

“As soon as your [vibe coding] project gets even slightly complicated, they pretty much always blow their brains out.” 「vibe codingのプロジェクトが少しでも複雑になると、ほぼ必ず破綻する」

「動いた」状態で積み重ねていくと、複雑さが増すにつれて 破綻 します。

「正しさ」を確認する方法

「動いた」で終わらせず、「正しい」かどうかを確認する方法があります。

確認すべきこと:

  1. エッジケースのテスト

    • 空データ、大量データ、特殊文字
    • 境界値のテスト

  2. セキュリティテスト

    • 認証バイパスの試行
    • インジェクション攻撃の試行
    • 権限エスカレーションの試行

  3. 負荷テスト

    • 同時アクセスのシミュレーション
    • 大量データでの動作確認

  4. コードレビュー

    • 設計の妥当性
    • セキュリティの考慮
    • 保守性

  5. 静的解析

    • セキュリティスキャナー
    • コード品質チェック

この事例から学ぶべき教訓

「動いたからOK」から学ぶべきことは以下の通りです。

  1. 「動く」と「正しい」は別

    • 動作確認は表面的なチェックに過ぎない

  2. AIは「動く」コードを書くのが得意

    • しかし、セキュリティ、エッジケースは考慮しない

  3. プロトタイプと本番を混同するな

    • プロトタイプが動いても、本番には使えない

  4. 積み重ねると崩れる

    • 不安定な基礎の上に建てると破綻する

  5. 「正しさ」を確認する手順を持て

    • エッジケース、セキュリティ、負荷テスト

まとめ：重要ポイントの振り返り

  • 「動く」ことと「正しい」ことは 別
  • Tea事件、権限システム事件はすべて「動いた」が失敗
  • AIは「動く」コードを書くが、セキュリティは考慮しない
  • プロトタイプを本番にするのは 最も危険なパターン
  • 「動いた」で積み重ねると、最終的に 崩れる
  • 教訓：「動いた」で終わらせず、「正しい」を確認せよ

関連記事

AI開発アンチパターン

AIコード生成の限界：できることとできないこと

vibe coderに共通する問題があります。 **AIの能力を過大評価している** AIは万能ではありません。得意なことと苦手なことがあります。その限界を理解せずに使うと、必ず問題が発生します。 AIコーディングツールが苦手な領域を理解しましょう。
AI開発アンチパターン

Accept All症候群：差分を読まない開発の代償

AIが生成したコードの差分を読まずに「Accept All」をクリックする。vibe codingの提唱者Karpathyも推奨するこの開発スタイルは、なぜ危険なのか。累積する問題、隠れたセキュリティ脆弱性、そしてReplit事件の教訓から学びます。

実践的なスキルを習得しませんか？

ブログで学んだ知識を、研修で実践に変えましょう。

研修内容を見る 無料相談を申し込む