Upgrade to Pro — share decks privately, control downloads, hide ads and more …

生成AIを活用した機能を、顧客に提供するまでに乗り越えた『4つの壁』

 生成AIを活用した機能を、顧客に提供するまでに乗り越えた『4つの壁』

「pmconf 2024の落選セッションお披露目会」の登壇資料
https://product-deepdive.connpass.com/event/333654/
#落選お披露目

生成AIが急速に進化する中で、多くの企業がその可能性を模索しています。しかし、実際に顧客に価値を提供するまでの道のりは決して平坦ではありません。Flyleでは、生成AIを活用した複数の機能を展開する過程で、以下の 4つの壁 に直面しました。

1️⃣ 価値の壁 - 生成AIが本当に顧客の課題を解決できるのか?
2️⃣ 実現の壁 - 技術的・コスト的な課題をどうクリアするか?
3️⃣ セキュリティの壁 - 顧客が安心して利用できる環境とは?
4️⃣ 運用の壁 - AIの進化にどう適応し続けるか?

本セッションでは、これらの壁をどのように乗り越え、顧客に価値を届けたのかを具体的な事例を交えてお話しします。生成AIの導入・運用を考えている方のヒントになれば幸いです。

#生成AI #プロダクトマネジメント #AI活用 #落選お披露目

Toshiaki Arai

January 28, 2025
Tweet

More Decks by Toshiaki Arai

Other Decks in Technology

Transcript

  1. • 2014~2020:株式会社ビズリー… • HR系プロダクトの開V • エンジニア・デザイナー新卒の採用人u • HR系プロダクトのプロダクトマネージャ‘ • 2020~:株式会社フライ

    • 共同創業 / 取締役 CTO(POも兼任4 • 現在の主な業p • 組織づく • 新規事業の仕込g • プロダクト全体の中長期戦略策– • そのÆ • 2児のÉ • Xアカウント名:toshi_moz 自己紹介
  2. Flyleの変遷 2020.2 コロナ禍で創業 2022.5 プレシリーズAラウ ンドで3億円を資金 調達 2021.5 シードラウンドで 8100万円資金調達

    2022.9 業務委託を含め、従 業員が20名に 2023.7 顧客ニーズプラットフォーム へ方向転換、DX EXPOなど の展示会に出展 現在 日本のエンタープライズ企 業への導入が拡大中 2021.6 製品版リリース 2022.3-10 顧客セグメンテーション、ロードマッ プ・スコアリング機能、Salesforce 連携機能をリリース 2022.12 サーベイβ版を リリース 2023.8 生成を活用した機能 をリリース 2024.4 レポート・ダッシュ ボード機能のリリース 2023.4-7 生成AIを活用した機 能のPOCを開始 現在 顧客ニーズプラットフォームと して必要な機能の拡充 フィードバックマネジメント プロダクトマネジメント 顧客ニーズプラットフォーム 2020.12 β版リリース ↑ここから生成AIへの取り組みが本格化
  3. 『4つの壁』 1. 顧客価値の壁 「生成AIを“どう使うか”よりも“何 の課題を解決するか”。顧客にとっ て本当に価値がある機能をどう見 極めるか。」 2. 実現の壁 「どのモデルを選び、どのように

    コストを抑え、サービスとして実 際に動かせるか。ビジネスと技術 を両立させる現実解を探る。」 3. セキュリティの壁 「顧客が心配するのはデータ漏え い・学習利用・リージョン制限。 安心して使える環境をどう整える か。」 4. 運用の壁 「リリース後が本番。モデルの アップデートやベンダーロックイ ンなど、変化に追随する体制が不 可欠。」
  4. 事例1: 実際の苦労 / どのように乗り越えたか 顧客のペインに対して、生成AIを使うことが本当にベストか? 何でもできそう→何をするかの特定が困難  個人で試行錯誤している時の全能感(なんでも できるじゃん!!‰ 

    アイデアはたくさん出てくるが、ワクワク状態 だと実務レベルで使えるまでには大きなギャッ プがあることを認識できなz  難しいことをさせようとするとプロンプトが複 雑になり、ユースケースも狭まる 従来通りの課題検証→特定の業務に特化  生成AIが使えるとはいえ、課題&価値設計のプロ セスは大きく変わらなz  顧客の業務とペインを把握することかÔ  業務とペインの中から、特にレバレッジの効き そうなものを特¸  改善の幅はどれくらいあるÄ  ハルシネーション、出力の曖昧さをどこまで 許容できるÄ  間違いが許容できない業務(数値計算、 など)は人によるレビューが必要、など
  5. 事例2: 実際の苦労 / どのように乗り越えたか 顧客は生成AI機能に無限の期待値を抱いてないか? 顧客の問い「実際の精度ってどうなの?」 ž 価値検証も含め会社としても積極的に販売を 行ってい‘ ž

    顧客は精度を懸念しており「PoCプラン」を 提供し‘ ž 顧客の期待:今までの人による判断とまったく 同じように、生成AIにも判断させたo ž 生成AIには正確なコンテキスト把握({商品} は{カテゴリ}だから〜、など)が難しo ž PoCの結論として、本契約にはいたらず。。。 期待値のすり合わせは丁寧に ž 生成AIに対する顧客のリテラシー、期待値を正 しく把握し、できる/できないを丁寧に伝えr ž 『人の評価との一致率』のような単純な目標 を設定するのは危 ž “PoC”受注は、実際のアウトカムよりも生成AIの 精度について目がいきが4 ž 現在は本契約前のトライアルで、実際の顧客の VOCをもとに分析結果を確認してもらうプロセ スを導入
  6. 事例3: 実際の苦労 / どのように乗り越えたか 新しい顧客セグメントの開拓時にはプロンプトの調整が必要 異なるセグメントで成果がまちまちに ¤ 初期の顧客検証は「ソフトウェア開発」が主 だったが、非IT製品を扱う企業へも展開展‰ ¤

    生成AIの出力結果がソフトウェア開発寄り˜ ¤ 例)化粧品を扱う会社において、「ログイン できない」よりも「肌荒れしてしまった」を クリティカルとして分類したf ¤ プロンプトをカスタマイズすればそれぞれのセ グメントに対して調整できるが、顧客に委ねる と極端に精度が落ちるリスクがある プロンプト調整機能 + CSの支援 ¤ 「SaaSとしてまんべんなく価値提供する」 vs「顧客のワークフローにヒットさせるf ¤ このギャップを把握した上で、プロンプトに カスタマイズ性を持たせ) ¤ 顧客の期待を満たすように、CSがプロンプトを 調整すr ¤ CSもプロンプトエンジニアリングの基礎知 識が必( ¤ うまくいったケースは開発にも連携し、その 後の機能改善にも活かす
  7. 事例1: 実際の苦労 / どのように乗り越えたか コスト試算の結果、ビジネスとして成立するか? 価値は出せるが、赤字になるリスク k データ量や生成頻度にもよるが、価値検証~実際 に提供後にどの程度コストがかかるかシミュ レーションが必v

    k 利益率も考慮した最終的な価格が高すぎて、顧 客が検討もできない状況になっていない„ k コストが爆発するような機能が提供されていな いか お金をかけずにすむ部分を見つける k 各生成AIモデルの精度・料金比較は必Ù k 異なるモデルの組み合わせも検討すÖ k 従来の機械学習手法での代替可能性を探Ö k 例)翻訳とかであれば生成AIを使う必要があ るのか、なê k スタートアップであれば、プラットフォームが 提供する無料のクレジットで検証できることÒ k Azure OpenAI Serviceを利用しており、無料 クレジットでたくさん検証させていただいた
  8. 事例2: 実際の苦労 / どのように乗り越えたか 安定して顧客に価値提供できる基盤はあるか? レート制限、可用性における課題 ˆ APIを利用するためのレートはお金をかければ簡 単に緩和できるものではなく、利用状況に応じ て段階的に緩和されs

    ˆ レート上限→特定の顧客がリソースを使ってい る間、他の顧客に大きな影響が出ないかg ˆ 今後、価格変動などプラットフォーム側の影響 を大きく受けるリスクはないか? 可能な限り先手先手でリソースを確保した ˆ リソース上限緩和のためのアプローÆ ˆ グローバルにおいて、あらゆるリージョンを 使えるよう» ˆ 各リージョンにおけるレートの上限緩和を常 に申Ô ˆ 直近ではエンタープライズプランを検討 (レート上限が大幅に緩和される¥ ˆ レート上限に引っかかった場合の内部的なリト ライ処理や、処理中であることを顧客に伝える UXの工夫も必要
  9. 事例3: 実際の苦労 / どのように乗り越えたか そのプロンプトは最適か? プロンプトエンジニアリング沼と品質保証 l 文言一つで出力結果が大幅に変わり、その出力 が良いかどうかは人間が判断する必要があv l

    自分たちでは結果の判断が難しい場合y l 与える情報の取捨選択が必s l コンテキストを増やせばコストも増えv l 「このケースはうまくいくけど、こっちがうま くいかなくなった」との戦い データセットの準備と地道な試行錯誤 l 生成AIのポテンシャルを最大引き出すため、プ ロンプトエンジニアリングの知識はMUS® l 品質を確認するための、VOCを想定したデータ セットを作成(これも生成AIを活用)し、プロ ンプト変更後の結果を確¦ l プロンプトの変更は非常にナイーブなので、可 能であれば事前に顧客のデータでも検証し、評 価をしてもらう
  10. 事例1: 実際の苦労 / どのように乗り越えたか 「自社のデータがモデルの学習に利用されるのではないか?」 機密情報を学習されることへの懸念 © 過渡期の中で、顧客側も生成AIの利用ポリシー 策定が追いついていな ©

    前向きな商談がいきなり失注になることˆ © プラットフォーム側の規約、サービス提供者と しての配慮を、どのように顧客に伝えるš © そもそも、データがプラットフォーム側に残る こともNGとなる場合ˆ © Azure OpenAI Service:内部的には30日間 ログが残る(OFFにするには申請が必要) 規約や事例など、説明材料を準備 © プラットフォームの規約を正しく解釈し、齟齬 なく顧客に伝わる表現にすX © 顧客に共有できる事例があれば活用すX © 「あの会社さんもつかっているのか」と安心 材料になることˆ © プラットフォーム側への粘り強いオプトアウト 申請→最近承認された!
  11. 事例2: 実際の苦労 / どのように乗り越えたか 「国外にリクエストを送りたくないのですが。。。」 データの越境移転に関する企業のポリシー u 自社の情報が含まれるリクエストを国外に出せ ないことが社内で規定されていk u

    可用性確保のために増やしたリージョンが使え な‡ u 大量の分析を国内リージョンのみに任せるの は限界がある 企業の要求に応じたリージョン設定 u まずは、各リージョンにおける「処理」と 「データ保存」の実態を正しく把握す· u 処理能力が許容するのであれば、特定の企業の み日本リージョン内で処理するオプションを提 ® u 顧客のAzure リソースを利用するオプションプ ランを提 u ただしこれは後で廃止することに(後述)
  12. 事例1: 実際の苦労 / どのように乗り越えたか モデルのアップデート作業が確実に、且つ高頻度で発生する 古いモデルは次々と利用不可になる q モデルのアップデートは作業は不可避、この作 業を怠ることで大きなインシデントにつながˆ q

    モデルのアップデートによって出力結果も変わ るため、事前に検証が必要 移行スケジュールの策定は最優先で q スケジュールを正しく把握し、以降スケジュー ルを事前に組む→その時期においては最重要タ スクとなˆ q CSや顧客と事前に連携し、出力結果に違和感が あるようならすぐに報告してもらÉ q サービス提供者側でアップデート作業を完結で きるようにしておく(顧客側のリソースを利用 するオプションはメンテナンスが大変)
  13. 事例2: 実際の苦労 / どのように乗り越えたか 生成AI界隈の動きを監視して、うまく波にのる 世の中のアップデートの犠牲になるリスク { プラットフォームを利用する以上、常にベン ダーロックインのリスクを考慮すj {

    プラットフォームや競合製品によって、提供価 値が代替されてしまうかe { 「プラットフォーム側でできるので、解約し ます」と言われてしまうのでは? 日々の情報収集、処理層の切り出し { 他のプラットフォームでできる事を正しく把握 し、なにかあればプラットフォームを乗り換え られる準備をしておÐ { Flyleでは月一でハッカソンを実施、新しいモ デルなどを実際に触って試すことe { こんなことやられたら嫌だな、これは自社独自 の価値だな、を問い続ける