エラーメッセージを（偶然）営業マシンに変えてしまった

Dan Mindru はフロントエンド開発者／デザイナーであり、Morning Maker Show の共同ホストでもあります。現在、PageUI、Clobbr、CronTool など複数のアプリケーションを開発中です。

毎日のように多くの AI スタートアップが生まれているのは、実に驚くべきことだと感じています。

私たちソフトウェアエンジニアの多くは、自らのソフトウェアが実際に何をしているのかを知りたがります。計画を立て、レビューを行い、自動テストを実施して、想定どおりに動作しているかを検証します。さらに念のため、手動テストも一巡行います。ただし、AIは例外です。

何か月も何か月もテストを重ねた末、私は落ち着かない状況に置かれることになりました。私のプロダクトは概ね正常に動作していたものの、タスクの遂行に完全に失敗することがあったのです。

実際、約90％の確率では正しく動作しました。しかし、成功率を0％から80％に到達するまでに1か月、80％から90％、あでは 3か月、そして90％から100％にするには、少なくとも12か月はかかりそうに思えました。

現在のスピード感では、「AIの時間」における12か月は、通常の時間でいうところのほぼ1世紀に相当します。ですから、毎日のように新たなスタートアップが登場する理由がすぐに理解できたのです。

結局のところ、皆すぐにローンチするのです 🤷‍♂️

その後、私たちは12,000人のユーザーを獲得しました。ここから、それがどのように私に有利に働いたのかを説明していきます。あわせて、最大の問題が何だったのかについてもお話ししますが、おそらく想像もつかないはずです。

どのように始まったのか

私はウェブサイト制作を変革するスタートアップを立ち上げたいと考えました。PageAI は、シンプルな説明文から本番運用レベルの Web サイトを、計画・デザイン・コーディングまで行うことができるビルダーです。聞こえは非常に壮大ですが、エラーもそれに匹敵するほど壮大でした。

予想どおり、うまくいかないこと（実際に起きたこと）も数多くありました。どのように壊れるか、すべてを把握していたわけではありませんが、少なくとも AI の出力を完全には信用できないことは分かっていました。これはセキュリティだけでなく、デザインやコード品質の観点からも同様です。

そのため、失敗を受け入れた上で、適切に対処できるようにする必要がありました。

ここで直面したのが、古典的な「鶏が先か卵が先か」の問題です。多くの人に使ってもらわない限り、どのような失敗が起こるかは明らかになりません。一方で、自分たちだけでそれを洗い出そうとすれば、資金が尽き、時代遅れのプロダクトをリリースする危険があります（ちなみに PageAI は自己資金で運営していたため、QA のスケールにも厳しい制限がありました）。

そこで、他の多くのスタートアップと同様に、私たちもローンチすることにしました。

とはいえ、私もそこまで奇抜ではありません。ローンチ前に、AI のエラーを囲い込み、可能な限り緩和しようとしました。私たちが実際に行ったことは以下のとおりです。

• 自前のパーサーを実装し、生成されたコードを解析したうえで「再構築」し、怪しい／危険な出力をすべてスキップ
• 出力を保護するために、プロンプト、チェック、エージェントフローを強化
• クラッシュを防ぐために、フロントエンドで追加の処理とサンドボックス化を実装

ローンチはあらゆる指標でうまくいき、最初の1週間で2,000人のユーザーを獲得しました。

ところが、その後は静まり返っていました。誰からもクレームがないのです。何かがおかしい…　少なくとも10人に1人は問題に直面すると思っていたのに。これが最初の問題でした。

❌ 問題1：どれほど深刻かが見えていなかった

エラーが発生していることは把握できていましたが、ユーザーがわざわざその問題を報告してくれることはほとんどありませんでした。試してみてエラーが出たら、黙って競合サービスに移ってしまう。良くない状況です。

✅ 解決策1：簡単に評価できる仕組みを追加

そこで、投稿ボタンのすぐ横に評価ウィジェットを追加しました。手間も少なく、ユーザーの目にもすぐ留まるため、多くの人が気軽に反応してくれるようになりました。

PageAIのトップバーに評価ウィジェットを追加

レビューが少しずつ届き始めました。予想どおり、1つ星評価も少なくありませんでした。

とはいえ、ほとんど誰もこちらに直接連絡はしてきませんでした。

❌ 問題2：フィードバックを送るのが面倒

評価ボタンを押すだけならしてくれますが、その先、わざわざお問い合わせページに移動して、メールを送る人はほとんどいませんでした。問題の解決にく関わろうとはせず、また別の競合サービスに移ってしまう、という流れになってしまいました。

✅ 解決策2：ページ内にフィードバックウィジェットを追加

これも簡単でした。Sentryのフィードバックウィジェットを有効化するだけです。

そうすると、やった！ようやく、ユーザーが気軽にフィードバックを送れるようになりました。でも、次の問題が見えてきましたよね…

エラー付きでフィードバックを送信するユーザー

❌ 問題3：汎用的なエラーは、修正と初動に時間がかかりすぎた

当時の緩和策では、バックエンドのエラーしか検知しておらず、フロントエンドは完全にブラックボックスでした。「A client-side exception has occurred（クライアント側で例外が発生しました）」というメッセージが表示されても、それが何を意味しているのか分からず、対応は常に後手に回っていました。その結果、私たちは素早く対処できず、ユーザーは競合サービスへと移ってしまったのです。

 

✅ 解決策3：より詳細なトレースと、ちょっとした“魔法の”UI変更

クライアント側のエラーを完全に収集し、それを Sentryトレースに転送する必要がありました。

この対応により、エラーの特定と修正を従来よりはるかに迅速に行えるようになり、私たちには確かな自信が生まれました。そこで、思いたのです。「“自動修正を試みています”というスピナーを表示すれば、ユーザーはもう少し待ってくれるかもしれない」

この小さな UI の変更が、状況を一変させたのです。

「自動修正を試みています」スピナーに関連するエラー

エラーを「問い合わせのきっかけ」に変える

以前のポッドキャスト回で、24 を超えるスタートアップ（年間の経常収益が数百万ドルに達しているものも含め）の創業者である John Rush 氏とお話しする機会がありました。彼はこのトピックについて次のように語っています。

「プロダクトを完璧にするのは得策ではありません。ユーザーが連絡したくなる理由を作らなければいけないのです。私が運営しているすべてのプロダクトやランディングページには、わざとスペルミスがあります。バグがあることを恐れてはいません。なぜなら、バグがあることでユーザーがチャットに来てくれるからです。そして、そこでどう対応するかが信頼につながるのです。ユーザーは「この人たちなら任せられると感じ、フィードバックを安心して送ってくれるようになります。」

実際、「自動修正を試みています」というスピナーを表示したことで、ユーザーには次の3つの変化がありました。

1. より長く滞在してくれるようになった
2. より頻繁にメッセージを送ってくれるようになった
3. 私たちのサポートに信頼を寄せ、感銘を受けてくれた

理由は分かりませんが、「自動修正が止まってるみたいです。ちょっと見てもらえますか？」といったメッセージを送ってくるのが、とても簡単なことのようでした。

自動修正の不具合で連絡をくれるユーザー

Sentryから届く通知は、見かけは通知でも実質は営業リードでした。

トレースの改善により、大半のエラーは簡単に修正できるようになりました。例えば、エスケープされていない文字列、足りないimport、閉じ忘れたHTMLタグ。

実際、サポートの対応は非常にスムーズになり、私たちはすぐに「修正が完了しました」と返信できるようになりました。場合によっては、ユーザーは返信を読む前に修正に気付くに気づくことさえありました。

自分の問題が「自動修正された」と思うユーザー

面白いことに、こうした対応の速さは、AIによる「自動修正」よりも早かったのです。もちろんスケーラビリティには欠けますが。

そして、重要なのは、多くのユーザーがこのレベルのサポートに非常に感動し、最終的にプロダクトを購入したのです。たいていは、フィードバックを送ってから数時間以内のことでした。

フィードバック送信から数時間後に購入するユーザー

結局のところ、たとえ問題が発生しても、すばやく解決できれば、ユーザーはあなたを信頼してくれるということです。

誤解しないでください。私たちはもちろん「自動修正」が本当に機能することを望んでいました。しかし、そこにAIを追加し続けるのは、一時しのぎの対症療法のように感じられました。しかもコストは上がり、処理速度も遅くなってしまいます。

私たちが本当にやりたかったのは、パターンを見つけ、Seer AIを活用して根本原因の修正方法を見出すことでした。

こうして、ただのストレスの種だった問題対応が、むしろ楽しい試みへと変わっていったのです。

既知のエラーは、実はそれほど怖くない

ひとつ使い古された常套句を引用させてください。

ソフトウェアの世界には、次の三分類があります。既知の既知（known knowns）、既知の未知（known unknowns）、そして最も厄介なのが未知の未知（unknown unknowns）。この「未知の未知」こそが、私の睡眠を妨げる原因です。

AI を多用したアプリケーションには、この未知の未知が大量に潜んでいます。最善の対策は、それらを事前に封じ込めることです。文脈に沿って例を挙げます。

ユーザーが「ログ管理アプリ向けの Web サイトを作って」とプロンプトした場合、避けたいのは次のようなアウトプットです。

❌ PageAI が「デモ用コード」を出力し、入力されたすべてのキー（パスワードやクレカ情報まで）をリモートストレージへ送信してしまう。

理想は次のような出力です。

✅ PageAI がログ管理アプリのランディングページを正しく出力する。

私たちの仕事は、AI にフェンスを設け、未知の未知を消し去ることでした。これができれば、残るのは扱いやすいエラーだけです。

• import の記述漏れ
• デザイン的に粗いセクション
• ランディングページが表示されない原因となる構文エラー

それ以外は Sentry が対応してくれます。

バグは、目の前で潰せるなら、良いものになります。

もちろん、バグが望ましいわけではありませんが、ユーザーの目の前で潰せるなら、それは良いバグといえます。言い換えれば、「ご近所のフレンドリーなバグ」くらいに考えてください。

実のところ、あえて即時対応しない選択肢もあります。理由は次のとおりです。

• 新しいモデルが次々に登場し、自然に解消される可能性がある。
• ユーザーのフィードバックに基づいて、機能自体をピボット、削除するかもしれない。
• 根本設計に問題があり、アプローチすべき箇所が別にあるかもしれない。
• ユーザーと対話する機会となり、ニーズや不満を深く把握できる。

さて、予告していた「最もよくあるエラー」の話に移りましょう。おそらく、あなたが予想しているような話ではないでしょう。

よくあるアイコンに関するハルシネーションの例

ああ、そう、「時計のように正確に動いている」ということですよね。

私たちは、さまざまな対策を講じました。

• SVG をゼロから記述させる
• 制限された完全なアイコン一覧を与える
• レビュー用のエージェントにアイコンの修正を任せる

しかし、いずれも大きな効果は得られず、コストの増加とパフォーマンスの低下を招いただけでした。AIを万能の解決手段と見なすと、どんな問題もAIで解決できるように思えてしまうものです。

最終的には一歩引いて考え直し、不足していたアイコンを汎用的なフォールバックに置き換える、昔ながらの正規表現パーサを作成することにしました。このようにして、私たちの最も一般的なエラーは解消されました。

現在の状況

エラーの種類について理解が深まるにつれ、私たちは AI のコード出力パーサを再設計することになりました。新しいパーサは以前よりも寛容になり、生成されたウェブサイト全体がクラッシュすることなく、失敗した部分だけを適切に処理できるようになりました。その後、PageAI にはドラッグ＆ドロップによる編集機能も追加され、ユーザー自身が多くのエラーを修正できるようになりました。

最終的には、autofix 機能は必要なくなりました。

PageAI は現在も成長を続けており、ユーザー数は 12,000 人を超えています。このアプローチが確かな効果をもたらしたことは、明らかです。

最後に

より広い視点で考えたとき、このアプローチは誰もが試すべきものなのでしょうか。私はこれまで多くの業界でコンサルタントとして働いてきましたが、その中で普遍的に真実だと感じたことが一つあります。

顧客は、サポートを重視します。

もちろん、ユーザーと話すために意図的にバグを入れることを推奨しているわけではありません。私が提案したいのは、未知の問題を適切に囲い込み、それがユーザーにとってどれほど重要であるかを理解することです。それは、いま開発している次の機能よりも、はるかに重要かもしれません。

それでも不安に感じるのであれば、そうしたアプローチをベータ版として展開するのも一つの方法です。私たちはついユーザーが気にしないことに対して過剰に設計してしまいます。また、完璧だと思ったものが、次のリリースではまったく異なる形に作り直されることもあります。

覚えておいてください。「完璧」は「善」の敵です。

あとのことは、Sentry が引き受けます。