バイブコーディングしたアプリが本当に動いているか、どうすればわかるのか？

アプリを作った。クリックして試した。ボタンは動いた。レコードは保存された。ダッシュボードは更新された。手応えを感じている。

しかし、そのコードを書いたのは自分ではないし、正直に言えば、おそらく読んでもいない。つまり実際にわかっているのは、一度、自分が、試した一つのことについて動いたということだけだ。それが本当に「動く」かどうかについては、あとはすべて信頼の話になる。

ほとんどの人がテストするのはハッピーパスだけだ

バイブコーディングしたアプリのテストは通常こう見える。ファイルを1つアップロードすると処理される。フォームを1つ送信するとレコードが表示される。ボタンを1つクリックするとワークフローが動く。それだけだ。それがテストのすべてだ。

怠けているわけではない。基盤となるロジックを書いていない人が行う手動テストの、自然な限界だ。想像できる失敗しか試すことはできず、コードを読めないなら、システムではなくデモをテストしていることになる。ハッピーパスは、AIが確実に最適化していた唯一の経路であり、そもそもそのプロンプトがそのアプリを生み出したシナリオだからだ。

問題は、実際の使われ方はハッピーパスに留まらないということだ。実際のユーザーはダブルクリックする。2つのタブを開く。戻るボタンを押して再送信する。ビルダー自身が、自分のアプリを一度だけ、想定した順序で丁寧にクリックして試すときには、そのどれも表面化しない。

実際に破綻するのは並行処理の場面だ

最も分かりやすい例は並行処理であり、何を確認すべきかを正確に理解していても、手動でテストするのは本当に難しい。

クレジット制の機能を想像してほしい。ユーザーが処理を開始するとクレジットが消費され、残高が尽きればチェックによってブロックされるはずだ。ここで、同じユーザーが5つのタブを開き、最初の課金チェックが完了する前に、同じ1秒以内に5つの処理を開始する場面を想像してほしい。チェックしてから減算するというロジックがこの重なりを処理できるように作られていない場合、5つの処理すべてが、どれも減算を記録する前に残高チェックを通過してしまう可能性がある。結果として、ユーザーは支払えないはずの処理を実行し、クレジット残高はマイナスになり、アカウントの状態は誰も想定していなかった形で狂ってしまう。

ボタンを一度クリックするだけでは、これを見つけることはできない。5つのタブを開くことを思いつき、クリックのタイミングを同じ1秒未満の中に合わせ、「残高を確認する」と「残高を減算する」が互いに競合し得る別々のステップだと知っている必要がある。これはテストの見落としではない。一度に一つずつクリックする手動テストでは、構造的に見つけられない種類のバグだ。バグは複数のことが同時に起きたときにしか存在せず、一人でテストしている人がその条件を意図的に、しかも再現可能な形で作り出すのは容易ではないからだ。

これはまさに、AI生成アプリに関する研究が、誰も想定していない失敗モードとして指摘するエッジケースそのものだ。AIは、尋ねられた特定の成功シナリオのための経路を作るのであって、同時編集や重複クリック、ステップ間のタイミングのずれのためには作らない。そして、その結果として生じる破損はエラーを出すわけではなく、数週間後にレポートや残高がおかしいと気づくまで、静かにそこに潜んでいる。

ほとんど誰もこれを検出できるテストを書かない理由

この種のバグに対する誠実な解決策は自動テストだ。単体テストや統合テストなど、人間の想像力と根気に頼るのではなく、5つの同時リクエストを機械的にシミュレートし、結果を確認できる仕組みだ。自動テストは疲れないし、エッジケースを忘れないし、月曜日に修正したものが火曜日に壊れていないかを確認するために、変更のたびに何度でも実行できる。

実際には、バイブコーダーがこれを持っていることはほとんどない。テストスイートを書くこと自体が独立した技術スキルであり、機能が動くことだけでなく失敗モードについて推論する必要があるため、アプリ自体を書くよりも難しいとさえ言える。頼めばAIエージェントはテストを書けるが、それでも誰かが頼むべきだと知り、テストが実際に何を確認しているのかを理解し、アプリが変化するのに合わせて更新し続ける必要がある。火曜日の午後にクライアントポータルを出荷する非技術系のビルダーにとって、それはあまりに高いハードルであり、速さを重視してバイブコーディングする技術系のビルダーでさえ、どうせ次のプロンプトで置き換えるコードのためにテストカバレッジを書くために手を止めることはほとんどない。

つまり、ほとんどのバイブコーディングしたアプリにおけるテストの現実的な状態は、最も何が問題になるかを推測する能力が最も低い人が、一度だけ行うハッピーパスのクリック確認だ。これが信頼のギャップだ。アプリが動くことを検証しているのではない。試した一つのことに基づいて、動くことを願っているだけだ。

「視覚的な確実性」が実際に意味すること

願うことに対する本当の代替策がある。それは「テストスイートの書き方を学ぶ」ことではない。リスクの高い部分を、そもそもロジックが隠されていない基盤の上に構築することだ。

視覚的な確実性とは、設定パネルを開けば、どのユーザーグループがレコードを見られるのか、ブロックがデータソースにどのフィルターを適用しているのか、ワークフローが順番にステップごとに何をするのかを、生成されたコードを1行も読まずに正確に確認できることを意味する。動作をテストしてその裏にあるルールを推測するのではない。ルールを直接読むのだ。

これは、信頼のギャップが最も高くつくカテゴリ、つまり課金ロジック、権限設定、同時アクセスするユーザーが関わるすべてのものにおいて、最も重要になる。Softrのようなプラットフォームは、権限、データ制限、ワークフローのステップを、信頼するために1行ずつ精査しなければならないAI生成コードではなく、視覚的で検査可能な設定として保持することでこれを実現している。あるクライアントが別のクライアントのレコードを見られるかどうかを知りたければ、データ制限ルールを開いて読めばいい。5つの同時ログインをシミュレートし、AIが競合状態を正しく処理してくれたことを願う必要はない。そのルールを強制しているのは、あなたのプロンプトのためにAIが書いた独自のチェックではなく、プラットフォーム自身のテスト済みインフラだからだ。

これは、あらゆるカスタム機能が設定パネルの中に収まってしまうという意味ではない。本当にカスタムなUIについては、1つのコンポーネントに限定され、プラットフォームの既存の権限とデータ層を通じて接続されるバイブコーディングブロックは、アプリ全体分の生成されたビジネスロジックとはまったく異なるリスクだ。「AIがこの一部分を間違えた」ことの影響範囲が、課金システム全体ではなく1つのブロックに限られるからだ。

結局残される分岐点

自分のアプリが週末プロジェクトや、誰もお金を払っていないプロトタイプなら、それを出荷して、ハッピーパスを一度クリックして試し、次に進めばいい。リスクは、実施した手動テストのリスクそのものだ。

それがクライアントポータルや予約システム、クレジット、残高、ロールが関わるものであれば、誠実な問いは「テストしたか」ではない。「間違っていたら痛手になる部分を実際に検証できるのか、それともAIの言葉を信頼しているだけなのか」だ。答えが「信頼している」であれば、それは以前にDay Twoの問題について書いた分岐点と同じであり、どちらの道を選ぶかは、あなたが誰であるかによって、どちらも正当だ。

コードを読める、あるいは学ぶ意志があるなら、別のビルダーに乗り換えるのではなく、本物のツールでそのギャップを埋めよう。Cursorは実際のコードベースの中で動作するため、並行処理のテストを依頼して、返ってきた結果を読むことができる。Replitはクラウド環境を提供し、テストスイートを実行することが後回しではなく、当たり前のループの一部になっている。どちらの場合も、ギャップはAIの能力ではなく、テストを依頼すべきだと知っているか、それが十分な出来かどうかを判断できるかにある。

それができず、間違った権限や負の残高が本当に問題になる種類のアプリを作っているなら、リスクの高い部分を、ルールを推測するのではなく読める基盤に移そう。それが実際に作っているアプリなら、クライアントポータル向けランキングを確認してほしい。間違った推測が最も高くつくのはそこだからだ。