ジャーナル

AI機能を5週間で本番環境に出荷する

シリーズBのフィンテック企業は、Lovable で作ったプロトタイプがデモどまりで止まっていました。私たちは5週間で全ユーザーに出荷し、この機能に関するサポートチケットは60%減少しました。

oliver r.founding engineer··1 分で読了

この記事について. ひとつの案件をオープンに公開する記事です。シリーズBのフィンテック企業のプロダクトチームには、デモ映えはするものの出荷できずにいたAI機能がありました。私たちはこれを5週間で本番機能に作り直しました。全ユーザーに展開し、リリース後にこの機能に関するサポートチケットは60%減少しました。

プロトタイプはすでに存在していました。プロダクトマネージャーが週末を使って Lovable で作ったものです。本物らしく見えました。全社会議でのデモも好評でした。ところがそこから4か月間放置されました。本物らしく見えることと、信頼できることは、まったく別の仕事だからです。

開示事項: クライアント名は匿名化しています。5週間での展開と60%のチケット減少は、実際に達成した案件の数字であり、予測値ではありません。契約上、名前は出せません。ここで重要なのはロゴではなく、構築の中身です。

良いプロトタイプが本番化の手前で止まる理由

プロトタイプが答える問いと、本番環境が答える問いは違うからです。プロトタイプが証明するのは、きれいな入力に対して、創業者が操作すれば、そのアイデアが一度は動くということだけです。本番環境では、乱雑な入力に対して、深夜2時に、誰も見ていない状態で動き、顧客が機能の回答に異議を唱えたときに説明責任を果たせなければなりません。ほとんどの v0 や Lovable の構築物は、このギャップで力尽きます。アイデアが間違っていたからではありません。デモから、自分の名前を出せるものへの道筋がなかったからです。

AIプロトタイプをどうやって本番環境に持っていくのか

デモのUIではなく、実際の課題から始めます。自社プロダクトの中に、ストリーミング応答、正解が分かっているケースと照合するテストスイート、監査ログ、そして重要な場面での人によるレビューを備えた機能として作り直します。このフィンテック企業では、この道筋に5週間かかり、機能に関するチケットは60%減少しました。

実際に何を構築したのか

プロトタイプのチャットボックスからは始めませんでした。サポートキューから始めました。この機能に関する件数トップ3のチケットは、すべて同じことを指していました。ユーザーはサポートにメールしないと明確な答えを得られなかったのです。そこでまず、この3つの質問に答える機能を、後付けのウィジェットとしてではなく、自社のプロダクトとデザインシステムの中に構築しました。

  • ストリーミング応答 — スピナーではなく即応している感覚になるよう、回答が形になるにつれて文字が表示されていきます。
  • テストスイート — 変更のたびに正解が分かっている回答と照合し、あるプロンプトの調整が別のケースを気づかぬうちに壊すことを防ぎます。
  • 監査ログ — すべての応答を記録し、顧客が機能の回答に異議を唱えたとき、サポートが正確な入力と出力を取り出せるようにします。
  • プロダクト内UX — 誰かが貼り付けたチャットウィンドウではなく、プロダクトの一部として感じられるよう、自社のデザインシステムの中に構築しました。

we are

私たちは、止まっていたプロトタイプを、ストリーミング、テストスイート、監査ログ、ネイティブなプロダクト内UXを備えた出荷済み機能に作り直しました。

we aren't

汎用的なチャットボックスをプロダクトの上に置いて、それをAI機能と呼ぶようなことはしていません。

#サポートチケットが60%減少した理由

チケットから逆算して機能を構築したからです。サポート件数を最も押し上げていた3つの質問が、いまはユーザーが誰にもメールを送る前に、プロダクト内で機能が直接答える3つの質問になりました。監査ログを見れば、機能がどの質問に対応し、どの質問がいまも人に届いているかがわかります。同じログのおかげで、60%の減少が季節的な変動ではなく実際のものだと確認できました。リリース前8週間と比較して、チケット種別ごとに計測しています。

この減少が持続した理由は、テストスイートにあります。リリース前は、すべての変更を正解が分かっている回答と照合していました。ひとつのケースを直して別の2つを壊してしまうようなプロンプトの編集は、ユーザーに届く前に検知されました。これが、一度は動くデモと、毎回動く機能の違いです。プロダクトチームはこれを「出荷」と呼びます。私たちも同意見です。プロダクト開発への私たちのアプローチはこちら

出荷までどれくらいかかったか

プロトタイプから全ユーザー展開まで5週間です。1週目は監査ログとテストスイート。計測できないものは改善できないからです。2週目と3週目で、チケット上位3つの回答をプロダクト内に作り直しました。4週目はデザインシステムに沿ったUXとストリーミング。5週目は段階的な展開で、10%ずつユーザーを増やしながら、テストで見逃したものがないか監査ログを確認しました。一斉リリースはしていません。四半期がかりの作り直しもしていません。

デモしていたものが、出荷したものに変わりました。それがうまくいったとわかるのは、サポートキューのおかげです。

先方のプロダクト責任者の発言(要約)

これが、私たちのbuild-in-publicの事例の多くに共通する点です。勝因はモデルそのものではありません。テストスイート、監査ログ、レビューのゲート、経過を見守れる展開といった、その周りの地味な部分です。これが、プロトタイプをすべてのユーザーの前に出せるものに変えます。v0 や Lovable で作ったものがデモのまま先に進めずにいるなら、それはまさに私たちが埋めているギャップです。あなたが作っているものを教えてください

ジャーナルに戻る
build in publicproductai featurecase study

出荷してほしいものを、教えてください。

30分の通話を予約する