「見た目は問題ない」バグ：AIで作ったアプリのサイレント障害を見つける方法

あなたのAIアプリビルダーがお問い合わせフォームを作った。名前を打ち込み、送信を押し、感じのいい完了メッセージを見て、次の作業に移った。一週間後、友人にそのページの話をすると、誰か入力した人はいるのかと聞かれる。確認しに行く。送信が3件、何かしらの保留状態のまま放置されている。どれ一つとして、あなたの受信トレイには届いていない。

これはAIで作ったアプリでもっともよくある障害のかたちで、しかも多くの人が心配しているものではありません。赤いエラーメッセージを吐くバグは見つけやすい — AIビルダーが2分で直してくれます。危険なのは、画面は問題なく見え、ユーザーは終わったと思い込み、あなたはそれを1ヶ月気づかない、というバグです。

この記事は、そういうバグを捕まえるためのチェックリストです。「QAエンジニアのようにテストする方法」ではなく — ただ、見た目は動いているAIで作ったアプリで、本物のユーザーが痛い目に遭う5つの場所を挙げるだけです。

1. 何かを送信して、それが本当にどこかへ届いたか確認する

AIビルダーがフォームを作ったら、一つだけ問いましょう。データはどこへ行くのか？抽象的にではなく — 文字どおり、送信したあとにどこへ見に行けるのか？

驚くほど多くのこうしたフォームが、メールを送ることも、データベースに保存することも、誰かに通知することもなく、ただ「ありがとうございます！」を返すハンドラーに送信しています。フォームは丁寧な見せかけにすぎません。だから、こうします。

「ZZZ TEST」のような、偽物だがすぐ分かる名前でテスト送信する。
ダッシュボード、データベース、受信トレイ、スプレッドシート — 送信が届くはずの場所を開く。
そこに「ZZZ TEST」のエントリーが、正しいタイムスタンプ付きであることを確認する。

1分以内に見つけられないなら、たとえ送信を祝ってくれたとしても、フォームは壊れています。私は、有料のランディングページの「お問い合わせ」フォームが、メール送信のステップが一度も配線されていなかったせいで、3週間にわたってリードをゼロ件しか集めなかった例を見ました。ページは完璧に見えていました。

2. 自分なら絶対に通らない経路を試す

あなたは、自分のアプリが何をするかを知っています。それが作られるのを見ていたからです。毎回同じ順序でボタンをクリックする。本物のユーザーはそうしません。

いちばん奇妙に感じる経路を選びましょう。

送信を、速く2回連続で押す。
何かをしている途中でページを再読み込みする。
ログインなしの、プライベートウィンドウで開く。
アポストロフィ入りの名前を打つ（O’Brien は定番の破壊者です）。
数値を求めるフィールドに数値を打つが、マイナスかゼロにする。

何かが目に見えて壊れたら、それは本物のバグです — でも少なくとも、それは騒がしいバグです。「見た目は問題ない」版は、2回目のクリックで重複レコードができたのに、画面からはそれが分からないときです。データベースを見に行き、タイムスタンプが2秒違いの「ZZZ TEST」行が2つないか探しましょう。見つかったら、フォームには重複防止のガードが必要です。

3. 一日待ってから、戻ってくる

AIが生成したコードの多くは、アプリが再デプロイや再起動されるとリセットされる一時的なメモリを使います。アプリは、開発者が「インメモリの状態」と呼ぶものにデータを保持している — デモには問題ないが、本物のものには最悪です。

このテストは過酷で、簡単です。データを入力し、タブを閉じ、24時間待って、戻ってくる。データが消えていたり、ぐちゃぐちゃになっていたりすれば、その保存は本物ではありません。あなたのAIビルダーはおそらく、平たい言葉でこう伝える必要があります。「このデータはサーバーの再起動を生き延びる必要がある」。ほとんどのビルダーは、促されればデータベースに切り替えます。一部は、頼まないと切り替えません。

このテストの、もっと速い版を実行することもできます。チャットでビルダーにこう尋ねるのです。「このフォームのデータはどこに保存されていて、再デプロイを生き延びますか？」答えに「メモリ内」「セッション」「この実行の間だけ」といった言葉があれば、どのユーザーよりも先にバグを見つけたことになります。

4. 自分ではない一人に見せる

あなたは、自分のアプリが何を意味するか知っています。あなたが設計した。ボタンに名前をつけた。ラベルがあなたにとって自明なのは、あなたが書いたからです。

何も説明せずに、友人に見せましょう。「Xをやってみて」と言う。その人を観察する。手伝わない。3つのことが起きます。

予想しなかった場所をクリックして、アプリが意外なことをする。
書いたときには自明に思えたラベルで、行き詰まる。
やってほしかったことをやるが、あなたが想像した半分のステップで、ある画面をまるごと飛ばす — ときには、その画面を埋めてもらうことをアプリが当てにしていた画面を。

そのどれもが本物のバグです。どれもエラーを吐きません。友人は「へえ、かわいいね」と言って、ノートPCを返してくるでしょう。そしてあなたは、その人の表情から分かるはずです — 継ぎ目などないと思っていた場所で、その人が30秒間、迷子になっていたことが。

5. それが送るメールを、スマホで読む

アプリがメールを送るなら — 確認、パスワードリセット、請求書 — それを一通スマホで開き、もう一通を普段使っているのとは別のメールクライアントで開きましょう。AIで作ったアプリは、デスクトップの Gmail では美しく見えるのに、Android の Outlook ではノイズのように見えるメールを生成しがちです。

同じ理屈が、PDFの領収書、ダウンロードできるエクスポート、「このリンクを共有」ボタンにも当てはまります。アプリの外、現実の世界へ出ていくものは、AIビルドでもっともテストされていない部分です。それはまた、ユーザーがもっとも目にする部分でもあります。私の知るある創業者は、美しい決済フローを出荷しましたが、その領収書PDFは、iPhone では真っ黒な四角一つでした。誰も文句を言いませんでした — ただ、買うのをやめただけです。

「動いている」についての、居心地の悪い真実

AIアプリビルダーで作るとき、「動いている」が意味するのは「私のマシンで、私のブラウザで、私の正確なクリックで、作った日に動いた」です。それは、聞こえるよりもずっと小さな主張です。

本物のアプリは、次のときに動きます。

別の人が使う。
データがデモより長く残り続ける。
アプリを通る経路が、あなたの想定していないものだ。
出力が、あなたがテストしていないデバイスで読まれる。

良いものを出荷するために、ソフトウェアテスターになる必要はありません。ただ、アプリの存在を誰かに告げる前日に、この5つのチェックを一度やればいいのです。約20分かかります。それで、放っておけば有料ユーザーに届いていたサイレントバグの10件中9件を捕まえられます。

1つだけする時間しかないなら、最初のをやってください。何かを送信する。反対側でそれを見つける。AIで作ったアプリのほとんどは、見た目は問題ありません。コツは、それが本当に問題ないことを確かめることです。

これが響いたなら、次にやるべきは、紙を一枚前にして、あなたのアプリが 決して 黙って失敗してはいけない3つのこと — フォーム、メール、決済、あなたにとってのそれが何であれ — を書き出し、それぞれを上記のチェックで一つずつ歩いてみることです。今の20分が、後々たくさんの安眠の夜を買ってくれます。