AIプロダクトが生き残るために設計したいのは、特定モデルの性能だけに頼らず、顧客理解、業務での使われ方、人を含む提供体験、改善を続ける運用を積み上げることです。現在の独自機能がモデルの標準機能になったとしても、顧客が使い続ける理由は何か。その問いから、次に確かめる対象を選びます。
AIを組み込んだサービスを開発していると、基盤モデルの進化が、自社の価値を失わせるように感じることがあります。ただ、機能が代替される可能性と、商品全体が不要になることは分けて考える必要があります。担当者も経営者も、個人で商品をつくる人も、まずは顧客の仕事のどこまでを支えているかを点検しましょう。
顧客理解 — 対話から得た文脈を判断に使う
顧客との対話から蓄積したいのは、要望の一覧に加え、なぜその要望が出たのかを説明できる情報です。誰が、どの場面で困り、何を試し、どの条件で判断を止めたのか。こうした一次情報を、商品を変える判断につなげます。
最近の行動と、その理由を聞く
欲しい機能を尋ねる前に、最近その仕事をしたときの流れを聞いてください。使った情報、手作業で補った箇所、判断に迷った理由をたどります。同じ要望でも、背景の制約が違えば、必要な提供方法は変わります。
- 状況 — 誰が、何を進めようとしていたか。
- 制約 — 必要な情報や権限、引き継ぎのどこで止まったか。
- 判断 — どの条件を満たせば、次の作業へ進めると考えたか。
- 反映 — 聞き取った事実をもとに、提供内容の何を変えるか。
記録には、実際の行動と、提供側の解釈を分けて残します。顧客固有の事情なのか、想定する顧客に共通する課題なのかも、別の顧客への確認が必要です。情報の量が増えたことだけで、独自の価値ができたとは判断しません。
蓄積する対象は、次の判断に必要な情報から選びます。記録を持っていても、商品や支援の改善に使われていないなら、誰が何を見直すために参照するかを決めるところから始めましょう。
使われ方 — AIの出力を顧客の仕事につなぐ
AIの出力が得られることと、顧客の仕事が完了することは同じではありません。入力の準備、出力の確認、修正、次の担当への受け渡しまで含めて、自社の商品がどこを担うかを整理します。
いまの機能が標準化したと仮定し、その機能を顧客が直接使う場合と、自社の商品を使う場合を比べてみてください。自社の商品には、顧客に必要な文脈をそろえる役割や、結果を次の行動につなぐ役割が残るでしょうか。残ると考える部分は、利用の実態で確かめる仮説です。
機能の操作から、前後の作業へ視野を広げる
- 利用前 — 顧客は何を探し、どのような形に整えて入力しているか。
- 利用中 — どこで迷い、誰に支援を求めているか。
- 利用後 — 出力を誰が確認し、何に使い、どの状態で完了するか。
比較する範囲をそろえ、準備や修正の手間が別の場所へ移っていないかを見ます。出力だけを比べると、顧客が使うための負担を見落とします。反対に、後工程まで支えているなら、その支援が顧客にとって必要なのかを聞き取れます。
業務に組み込まれていることだけで、選ばれ続けるとは限りません。利用が続いていても、役立っているのか、切り替えの手間で残っているのかは別です。最近役立った場面と、不便なまま使っている箇所を分けて確認してください。
提供体験 — 人が担う判断と関係を明確にする
顧客が相談できる相手がいること、事情を踏まえて対応してもらえること、判断に迷ったときの進め方が分かることも、提供する体験の一部です。ただし、人が関わるだけで信頼や価値が生まれると決めつけず、どの場面で何を引き受けるかを具体化します。
AI・提供側・顧客の分担を書く
AIが下書きや候補を出すなら、内容を確認する人と、採用するかを最終判断する人を決めます。提供側が修正まで担うのか、顧客が自分で確認するのか。扱えない入力や判断できない出力が出たとき、誰へ戻すかもそろえましょう。
- 説明する範囲 — 何を提供でき、どこから顧客の判断が必要か。
- 相談する場面 — 通常の操作で進めないとき、誰に何を伝えるか。
- 対応の範囲 — 料金に含む支援と、追加で相談する作業は何か。
- 引き継ぐ内容 — 担当が変わっても共有する、顧客の事情や過去の判断は何か。
人の支援が利用を支えているなら、その対応時間や費用も記録します。必要な支援を商品に含めるのか、顧客が自分で進められるよう設計を変えるのかを判断するためです。担当者の無理で成り立っている提供を、そのまま拡大しないことです。
信頼を考えるときは、約束した範囲を守れているか、できないことを説明できているかを確認します。顧客の反応が好意的でも、それが購入や継続の理由になっているかは、別に確かめる必要があります。
改善運用 — モデルの変化を試して取り込む
モデルの進化は、現在の機能を見直すきっかけにもなります。自社で作り込んだ処理を標準機能に任せられるなら、顧客の文脈を整えることや、利用後の支援に仕事を振り向ける候補になります。ただし、置き換えられるかは実際の業務で検証します。
変更前に、比べる対象と採用条件を決める
- 顧客の利用場面と必要な情報をそろえ、現在の方法でどこに負担があるかを記録する。
- 変更する範囲を絞り、出力の確認や修正、提供側の支援まで含めて比べる。
- 何が確認できれば採用し、どの問題が残れば見送るかを、試す前に決める。
- 試した結果と判断理由を残し、次に見直す担当者と時期を決める。
モデルの出力が良くなったことと、商品としての価値が増えたことは分けて確認します。顧客の仕事が進み、提供側も支援を続けられるかまで見る。確認や修正の負担が増えたなら、分担を変えるか、変更を見送る判断も必要です。
改善の材料には、継続利用している顧客の声だけでなく、使わなくなった理由や、期待と違った点も含めます。何を変え、どう確かめ、なぜ採用したかを残せば、次のモデル変更時にも比較の出発点として使えます。
残る価値の判断表 — 根拠から次の行動を選ぶ
現在の主要機能が標準化したと仮定して、次の項目を点検してください。各項目に「確認できた根拠」「未確認の点」「次の行動」を書き添えます。点数の合計で生存を予測するものではなく、追加開発の前に確かめる対象を選ぶための判断表です。
- 顧客理解 — 対話から得た固有の条件が、仕様や支援を変えた記録はあるか。根拠が要望の一覧だけなら、背景となる最近の行動を聞き直す。
- 使われ方 — 標準機能だけでは残る準備・確認・引き継ぎを、自社が支えているか。未確認なら、同じ業務範囲で利用を観察し、負担の違いを比べる。
- 提供体験 — 人の支援や最終判断の分担が、顧客の選ぶ理由になっているか。理由が不明なら、支援が必要だった場面と購入・継続の判断を確かめる。
- 改善運用 — モデルが変わっても、比較する材料と採否を決める担当者がそろうか。不足していれば、変更前の状態を記録し、試す範囲と判断条件を決める。
記録がない項目は、価値がないと断定せず未確認として扱います。まずは、前提が外れたら提供内容を変える必要がある項目を選び、確認する相手、方法、判断する時期を決めてください。残る価値の根拠があるなら、その提供を保ちながらモデルの活用を試す。根拠が弱いなら、顧客への確認を先に進めます。
利用者の便利さと購入者の判断を整理したい場合は、関連記事「AIプロダクトの機能を考える前に — 「誰が買い、何が変わるか」を決める」も参考になります。自社が提供する価値を、顧客に確かめられる仮説にするための記事です。