すでに構築済みのSaaSにAI機能を追加する方法

いまどのSaaS創業者にものしかかる、特有の種類のプレッシャーがあります。取締役や顧客、あるいは自分自身の頭の中の声が、同じ三つの言葉を口にします。「AIが必要だ」と。製品はすでに動いています。人々はお金を払っています。それでも突然、ほかの誰もが持っているように見える何かが欠けているように感じられるのです。そこでスプリントを立ち上げ、APIをつなぎ、隅にチャットボットをリリースします。ところが一カ月後、誰も使っていません。問題は決してモデルではありませんでした。それを何に向けるかを決めることでした。

まっさらな新製品にAIを追加するのは、奇妙なことに簡単なほうです。失望させるユーザーもいなければ、尊重すべきデータモデルもなく、説明すべきサポートチームもいません。すでに存在するSaaSに——課金顧客がいて、確立されたワークフローがあり、信頼性で評判の製品に——AIを追加するのは、別の競技です。新しい機能はどれも、人々がすでに信頼しているシステムの内側に着地します。そして信頼こそ、前のめりすぎるAI機能が最も速く焼き尽くしてしまうものなのです。

私たちは少なからぬソフトウェアチームがこれをうまくやり遂げるのを支援し、いくつかが失敗するのも見てきました。成功するチームは、ほぼ決して技術から始めません。彼らはユーザーが繰り返し尋ねてくる一つのつらい問いから始め、そのうえで初めて、AIが最も安価で誠実な答えかどうかを問います。本ガイドはそのアプローチを書き起こしたものです。機能をどう選び、動いているものを壊さずにどう構築し、人々が実際に手を伸ばすようどうリリースするか。

後付けのAI機能の多くが失敗する理由

十分な数のSaaSダッシュボードを歩いて回ると、その墓場を見分けられるようになります。誰もクリックしない「✨ AIアシスタント」ボタン。誰でも書けそうな当たり障りのない三文を生み出す要約パネル。製品がすでに普通の検索ボックスでもっとうまく答えていた質問に答えるチャットボット。これらの機能はAIが弱かったから失敗したのではありません。問題を探し求める解決策だったから失敗したのです。

パターンはほぼ常に同じです。誰かが何かAIらしきものをリリースせよというプレッシャーを感じ、最も汎用的で最も目立つ選択肢——チャットボックス——に手を伸ばします。それが最もわかりやすく「AI」と読めるからです。しかしチャットボックスは白紙であり、白紙は、特定の仕事を片づけるために製品へ来た人々にとって、ひどいインターフェースです。彼らは会話したいのではありません。レポートを仕上げ、メールを下書きし、データをきれいにしたいのです。

二つ目の失敗様式はより微妙で、より高くつきます。たいていは正しい機能を、誤りが許されないワークフローへリリースしてしまうことです。精度90%の提案はデモでは素晴らしく聞こえます。請求書を送ったり人員のシフトを組んだりするのに人々が使うツールでは、10回に1回の自信たっぷりの誤りは「印象的なAI」とは読まれません。「この製品は信頼できない」と読まれるのです。既存製品の内側でのハードルはランディングページよりも高い。なぜなら、すでに獲得した信頼を使っているからです。

モデルではなく、問いから始める

良い知らせは、既存のSaaSは新製品が決して持たないものを手渡してくれることです。それは証拠です。ユーザーがどこでつまずくか、あなたはすでに知っています。彼らが毎日教えてくれるからです。最初の素晴らしいAI機能の原材料は、サポートの受信箱、解約アンケート、そして人々がそっと避けている自社製品の部分に転がっています。

ですから誰かがプロンプトを書く前に、その証拠を集めに行きましょう。直近二百件のサポートチケットを読み、繰り返し現れるものにタグを付けます。サポートチームに、どの質問に答えるのにうんざりしているか尋ねます。アナリティクスで、人々が速度を落とし、離脱し、いら立ってクリックする画面を見ます。そのどこかに、退屈で、言語の形をしていて、何度も何度も行われる仕事があります。そしてそれこそ、AIが得意とする仕事の形なのです。

これらの要望に共通するものに注目してください。どれも「チャットボットを追加して」ではありません。具体的で、埋め込まれており、具体的な結果で終わります。それがAI機能とAIおもちゃの違いです。機能はワークフローの中へ消え、一手間を省きます。おもちゃは脇に座り、価値を引き出すために余計な作業をするようユーザーに求めます。

AI候補をすばやく順位づけする方法

三つから六つのアイデアの候補リストができたら、計画会議で誰が一番大声で主張するかに帰着しない選び方が必要です。私たちは各候補を三つの率直な軸で、一から五で採点します。そして合計が最も高いものがたいてい勝ちます——少なくとも、正しい議論を始めます。

1. 1
   価値：ユーザーはどれほどこれを欲しているか?

   絶えず聞く要望に応え、ユーザーの時間を目に見えて節約するなら5点。チームの誰かが思いついた「あったらいいな」なら1点。
2. 2
   許容度：誤ったとき何が起きるか?

   誤りが安価で見つけやすいなら——どのみちユーザーが見直す下書きなら——5点。誤りが静かにデータや金銭、顧客関係を損なうなら1点。
3. 3
   実現性：実際にそれに与えるものがあるか?

   機能が必要とするデータをすでに使える形で持っているなら5点。持っていない、アクセスできない、あるいは散らかったデータに依存するなら1点。
4. 4
   掛け合わせ、そして常識で確認する

   三つを掛け合わせます。それから人間的な問いを立てます。勝者の最初のバージョンをおよそ一カ月でリリースできるか? できないなら、できるまで範囲を絞り込みます。

その真ん中の軸——誤りへの許容度——こそ、チームが飛ばしてしまう軸であり、プロジェクトを沈める軸です。機能が高価値で完全に実現可能であっても、なお最初の選択としてひどいことはあり得ます。自信たっぷりの誤った答えの代償が高すぎる、ただそれだけの理由で。最初のAI機能は、人間がループに留まり、誤りが顧客ではなく数秒で済む、どこか寛容な場所に生きるべきです。

製品の脇ではなく、中に組み込む

人々が愛するAI機能と、辛抱して使う機能とを分ける誤りはこれです。どこに置くか。本能は、新しく独立したAIの面——パネル、ページ、チャットの引き出し——を追加させます。リリースするきれいな方法に思えるからです。しかし独立した面は、やっていたことを離れ、別の場所へ行き、戻ってくるようユーザーに求めます。それらの一手ごとに、人は離脱します。

定着する機能とは、すでに作業が起きているまさにその場所に現れるものです。下書きボタンは返信ボックスの中にあり、サイドバーにはありません。抽出されたデータは、あらかじめ入力され編集可能な状態で、まっすぐフォームの項目へ流れ込みます。提案された優先度は、ユーザーがどのみち目を走らせるリストの中に、控えめなバッジとして現れます。AIは自らを宣言しません。ただ次のクリックを目に見えて楽にするだけです。職人技のすべてはそこにあります。

ここでも、既存製品があることは制約ではなく贈り物です。ユーザーがつまずく正確な瞬間、これから埋めようとする正確な項目、これから書こうとする正確なメールを、あなたはすでに知っています。その文脈を使いましょう。同じモデルでも、製品がすでに持つ周辺データを与えられれば、空のチャットボックスがかつて生み出せたものより十倍役立つものを生み出します。ユーザーが何を望むかを当てずっぽうしていないからです。すでに知っているのです。

人間をループに留め、それを明白にする

最初のAI機能では、最も安全で最も信頼されるパターンは、ほぼ常に行動せず、提案することです。AIが提案し、人間が承認します。AIがメールを下書きし、人がそれを送ります。AIが項目を埋め、人がそれを確認します。AIが優先度を示し、人が決めます。これは野心の欠如ではありません。後でより多くを自動化できるようにする実績を、こうして築くのです。

これには技術だけでなく設計の次元もあります。何かがAI由来で、人間の承認を待っている状態であることを、視覚的に明らかにしましょう。控えめなラベル、異なる背景、静かな自動操作ではなく明示的な「確認して送信」。ユーザーは、少しずれたAIの提案を、断りなく起きたAIの操作よりはるかに快く許します。前者は役に立つ同僚のように感じられ、後者はソフトウェアが暴走したように感じられます。

• AIの出力は、効力を持つ前にユーザーが編集できる下書きまたは提案として示す。
• 機械の推測を確定した事実と取り違えないよう、視覚的に区別する。
• 常にきれいな「結構です」を用意する——人が提案を退けて従来のやり方を続けられるように。
• AIが確信を持てないときはそう述べ、自信ありげな答えをでっち上げるのではなく、優雅に縮退する。
• 何が提案され、人がそれをどう扱ったかを記録する——それが後の精度データになる。

その最後の点が、静かに最も価値があります。ユーザーが提案を受け入れ、編集し、あるいは退けるたびに、あなたの機能が実際どれほど良いかを教えてくれているのです——デモではなく、現実の世界で、現実のデータで。そのフィードバックの輪こそ、機能がより自律的になる準備ができたか、どこでまだ人間の手をハンドルに添える必要があるかを判断する手立てです。

誰も警告してくれないエンジニアリングの現実

デモは簡単な20%です。本物のSaaSの中でAI機能を本番対応にするのは残りの80%で、その大半はモデルそのものとはほとんど関係のない、地味な作業です。これを最初に知っておく価値があります。動くプロトタイプに惑わされて、守れないリリース日を約束してしまわないように。

データの配管と文脈

モデルは、与えるものの分しか役に立ちません。難しいのは、既存のデータベースから正しい文脈を確実に集め、整形し、最新に保ち、どのユーザーが何を見てよいかを尊重することです。マルチテナントのSaaSでは、これが途方もなく重要です。ある顧客のデータを誤って別の顧客の答えに混ぜ込むAI機能は、バグではなくインシデントです。テナント分離は、AI層の奥まで貫かれていなければなりません。

コストとレイテンシ

AIの呼び出しはどれも費用と時間がかかり、その両方が利用量とともにスケールします。定額のSaaSサブスクリプションがスケールしない仕方で、です。十人のベータユーザーには喜ばれる機能が、一万人になると静かに利益率の問題になり得ます。どのモデルがどの仕事に合うかを早くから考える必要があります——サポートチケットを分類するのに、最も強力で最も高価なモデルは要りません——繰り返しの作業のキャッシュ、そして応答が一秒ではなく四秒かかるとき機能が何をするかも。

失敗と不幸な経路

現実のユーザーはゴミを貼り付け、間違ったファイルをアップロードし、三カ国語で書き、最悪のタイミングであなたの機能に到達します。AIプロバイダーは障害を起こします。応答は壊れた形で返ってきます。あなたの機能は、残りの製品を壊さずにそのすべてを処理しなければなりません。規則は単純で厳格です。AI機能の失敗が、中核のワークフローを道連れにすることは決してあってはなりません。静かに失敗し、手動の経路にフォールバックし、ユーザーが作業を続けられるようにすべきです。

値付け：機能か、アドオンか、物語のすべてか?

機能が動いたら、多くのチームをつまずかせるビジネス上の問いに直面します。どう課金するか。唯一の正解はありませんが、いくつかの誠実なパターンはあります。継続率を高め、価格を正当化する付加価値として、既存プランに織り込めます。機能が明白で測定可能な価値を届ける場合に効く、有料アドオンや上位ティアにできます。あるいは、基盤コストが消費とともに本当にスケールするなら、利用量で従量課金できます。

避けるべき罠は、AIが製品であるかのように機能を値付けすることです。ほとんどのSaaS企業にとって、AIは新しい製品ラインではありません——既存製品をより価値あるものにする新しい能力です。顧客は「AI」を買いたいと思って目を覚ますわけではありません。実際の問題が少しでも楽に解かれることを望み、その成果に対してお金を払います——裏に機械があろうとなかろうと。技術ではなく、成果に値付けしましょう。

小さな一つをリリースし、それから登る

戦略の全体は、単一のローンチではなく、一つの連なりに帰着します。ユーザーがすでに求めている、高価値で誤りに寛容な機能を一つ選びます。作業が起きる場所に埋め込みます。人間をループに留めます。フラグの後ろで顧客の一部にリリースします。彼らが実際どう使うかを観察し、粗いところを直し、それから広げます。その機能が元を取って初めて、次の、少し野心的なものに手を伸ばします。

これを何度かやると、静かに強力な何かが起こります。あなたの製品は「AIボタンを後付けしたソフトウェア」であることをやめ、顧客が気にかける特定の仕事において本当に賢いツールになります。それは、初週に印象的なチャットボットのデモをリリースし、その後半年を誰も使わない理由の説明に費やしたチームよりも、はるかに強い立場です。

よくある質問