SaaSプラットフォームにAIアシスタントを追加した方法 — 壊さずに

私たちが話をするすべてのSaaSチームは、いずれ同じ一言を口にします。「ここにAIアシスタントを入れるべきだ」と。取締役会からの圧力のこともあれば、競合の新製品発表がきっかけのことも、本心からのこともあります。ただ、興味深いのはアイデアそのものではありません。アイデアはほとんど誰もが持っているのです。興味深いのは、その一言と、実際のユーザーが本当に頼りにする機能との間にある隔たりです。これは、その隔たりを乗り越えた、あるチームの物語であり、そこへ導いた地味な意思決定の記録です。

始める前に一言。クライアントは匿名化し、数字は丸めています。彼らは小規模で黒字のB2B SaaS企業で、社員は20人未満、業務チーム向けのワークフローツールを販売しています。特定できないよう十分に細部を変えていますが、プロジェクトの輪郭は実際に起きた通りです。数字は例示であり、監査を経たものではありません。図表を飾り立てるより、そのパターンをお見せしたいのです。

このプロジェクトを書き起こすのは、こうした取り組みが実際にどう進むのか、ほぼ完璧な例だからです。キックオフ資料が語った通りには進みませんでした。むしろそれ以上にうまくいきました。ただしそれは、最初のバージョンを捨てる覚悟があったからこそです。

状況：ひとつの衣装をまとった二つの問題

創業者が最初に連絡してきたとき、依頼はシンプルでした。「アプリにAIチャットボットが欲しい」と。多くのプロジェクトはここから始まり、そして多くが静かにおかしくなっていく地点でもあります。「AIチャットボット」は目標ではなく、形にすぎません。ですから私たちの最初の仕事は、そのチャットボットが解決すべき問題は何なのか、そしてそもそもそれが一つの問題なのかを見極めることでした。

一つではありませんでした。その依頼の下には、まったく異なる二つの痛みが潜んでいました。一つ目はサポート負荷です。二人のカスタマーサクセスチームが、繰り返される問い合わせに溺れていました。「これをエクスポートするには」「あの設定はどこ」「なぜレポートが実行されなかったのか」。受信チケットのおよそ60%は、すでにヘルプドキュメントのどこかに答えがある質問でした。二つ目の痛みはより静かで、より高くつくものでした。アクティベーション（定着）です。彼らのプロダクトには、3クリック奥に埋もれた本当に強力な機能があり、ほとんど誰も自力では見つけられませんでした。それを見つけたユーザーは何年も残り、見つけられなかったユーザーは最初の2か月で離脱しました。

同じ衣装、二つの問題。そしてそれらは異なる方向へ引っ張り合っていました。サポートボットは質問をそらして脇に退こうとします。アクティベーションのアシスタントは会話を始め、ユーザーが尋ねてもいないことへ促そうとします。もしこれらを切り分けずに「AIチャットボット」を作っていたら、両方の仕事を中途半端にこなすものができていたでしょう。

やり切れる規模まで絞り込む

二つの問題を前にすると、初日から両方をこなす壮大なアシスタントを作りたくなります。私たちはチームを説得して思いとどまらせました。ビジョンが間違っていたからではありません。6か月かける「何でもアシスタント」こそ、まさに納期に遅れ、期待外れに終わり、その後2年間みんながAIに神経質になる、そういうプロジェクトだからです。

そこで一つを選びました。サポート削減を最初に選んだのは、地味ですが決定的な三つの理由からです。明確で測定可能な指標があること——チケット数です。すでに存在するコンテンツを使うこと——ヘルプドキュメントと過去のチケットです。そしてうまくいかなくても、損失は小さいこと——良い答えを得られなかったユーザーは、これまで通りチケットを起票するだけです。低リスク、速いフィードバック、正直な指標。これはいつでも良い最初のAI機能です。

アクティベーションのアシスタントは消えたわけではありません。書面の上で、明確なメモとともに保留にしました。フェーズ2、検索基盤の実証が済んだらと。この一つの決断が、おそらくプロジェクトを救いました。四半期単位ではなく数週間で実際に到達できるゴールを、チームに与えたのです。

私たちが作り——そして削除した最初の試作

ここが多くの事例研究が省く部分です。私たちの最初に動いた試作は、控えめに言っても、良いものではありませんでした。私たちは当たり前のことをやりました。プロダクトのヘルプ記事を大規模言語モデルにつなぎ、チャットボックスを付け、ユーザーに質問させたのです。デモでは魔法のように見えました。しかし実地テストでは、非常に特定的で、非常に示唆に富む形で崩れ落ちました。

モデルは自信満々に間違っていました。半年前に名前が変わった設定について尋ねると、明るく古いメニュー経路をでっち上げました。上位プランの機能について尋ねると、それを使えない顧客に対して使い方を説明しました。どの答えも権威あるように聞こえ、それが間違った答えを、答えがないよりもたちの悪いものにしていました。丁寧に嘘をつくサポートボットはチケットを減らしません。より怒った問い合わせを生むだけです。

プロンプトの微調整でごまかすこともできました。代わりに私たちは、一歩後退のように感じられ、実は勝負のすべてだったことをやりました。最初の試作を捨て、厳格なルールを軸に作り直したのです——アシスタントは、出典を示せる情報源からのみ回答してよく、それができなければ「わかりません」と言わなければならないと。

私たちが実際に作ったもの

リリースしたバージョンは、試みる範囲を意図的に控えめにし、振る舞いを厳格にしました。内部的には検索に根ざしたアシスタントでした。ユーザーが何かを尋ねると、システムはまず整備された最新のナレッジベースを検索し、次にモデルに、見つかった内容だけから、出典へのリンクを添えて答えるよう求めます。出典がなければ、自信ある回答もなし——ただ人間へのきれいな引き継ぎだけです。

三つの設計上の選択が重労働のほとんどをこなしました。そのどれもが心躍るものではありません。それこそが要点です。AI機能が信頼されるか、静かに切られるかを決めるのは、たいてい地味な選択なのです。

巧妙さより根拠づけ

すべての回答は、実在する最新のドキュメントに紐づけられていました。私たちはモデルのチューニングよりも、ナレッジベースの整理と構造化に多くの時間を費やしました。地味ですが、プロジェクトの中で群を抜いてレバレッジの高い作業でした。優れた、よく手入れされたコンテンツに載った平凡なモデルは、古びた混乱に載った優秀なモデルに勝ります。

優雅な引き継ぎ

アシスタントは確信が持てないとき、推測しませんでした。そう告げ、ワンクリックで人間につなぐ道を差し出し——会話のコンテキストを引き継ぐので、ユーザーは同じことを繰り返さずに済みました。直感に反して、これがボットへの信頼を高めました。限界を認めるアシスタントは正直に感じられ、ユーザーは難しい40%で身を引くからこそ、簡単な60%を安心して頼ったのです。

誰が尋ねているかを理解する

プロダクトの中に存在していたので、アシスタントはユーザーのプラン、役割、アプリ内のどこにいるかを把握していました。ですから使えない機能を説明することはなく、「お探しのボタンは、今まさに開いている画面にあります」と言えました。このプロダクト認識こそ、マーケティングサイトに後付けした汎用チャットボットに対する、アプリ内アシスタントの本当の強みです。

1. 1
   ナレッジベースの整理と構造化

   すべてのヘルプドキュメントを監査し、古びたものを削り、残りをプランと機能でタグ付けしました。これが第1週で、最も重要な週でした。
2. 2
   検索基盤の構築

   まず検索、次に回答。モデルは常に精査済みの最新コンテンツしか見ず、出典に根拠づけできないものは拒否するよう指示されました。
3. 3
   プロダクトコンテキストの接続

   アシスタントをユーザーのプラン、役割、現在の画面につなぎ、回答を最適化し、使えない機能を指し示すことがないようにしました。
4. 4
   正直なフォールバックの設計

   「確信が持てません — 担当者につなぎます」という道筋を一級の機能として作り込み、会話コンテキストをすべてサポートチームへ引き継ぎました。
5. 5
   フラグの背後で10%のユーザーに提供

   一部のアカウントに静かに展開し、実際の会話を2週間観察し、壊れた箇所を直してから展開を広げました。

結果 — そして私たちを驚かせたもの

アシスタントが全員に公開されて約3か月後、状況は明確でした。丸めた例示的な数字をお見せします——小数点よりも方向性が大切です。

サポートの数字は私たちが約束したもので、そして期待に応えました。繰り返しのチケットの半分強がそもそも届かなくなり、二人のチームは本当に人間を必要とする案件に取り組む時間を取り戻しました。良い成果、まさにスコープ通りです。

しかし創業者を本当に驚かせた結果は、私たちがまったく最適化していなかったものでした。アシスタントは一日中「Xをするには」という質問に答えていたので、自然にあの埋もれた、定着につながる機能へとユーザーを導き続けていたのです——リテンションに結びついた、あの機能へ。私たちはまだアクティベーションのアシスタントを作っていませんでした。サポートボットが、ただ役に立ち、プロダクトを理解しているというだけで、その仕事の一部を副作用として静かにこなしていたのです。新規ユーザーはこれまでより数週間早くその機能を見つけていました。

次のチームに伝えたいこと

もしあなたが、同じ「AIアシスタントを追加すべきだ」という一言を見つめているSaaSチームなら、このプロジェクトから、その枠を超えてよく当てはまることがいくつかあります。

• 作る前に問題を切り分ける。「AIチャットボット」は、たいてい異なる設計を求める二つか三つの別々の仕事を隠しています。
• 間違った答えのコストが最も小さいユースケースから始める。サポート削減はほぼ完璧な最初の一手です。失敗しても現状維持に戻るだけです。
• 労力の大半を、モデルではなくコンテンツに割く。きれいで最新のデータへの根拠づけこそが、アシスタントを信頼できるものにします。
• 「わかりません」を失敗ではなく機能にする。正直な引き継ぎは、ボットが得意な部分をユーザーが頼りにする信頼を築きます。
• まずフラグの背後で小さな一部に提供する。実際の会話は、どんなデモも教えてくれないことを教えてくれます。

よくある質問