先週、役員会の資料を作っていて、ふと立ち止まりました。「カスタマーサポートに生成AIを入れたい」という話を部内で進めていたのですが、経営陣への説明資料を書こうとすると、手が止まってしまうんです。
生成AIのカスタマーサポート活用については、AINOWの記事を読んで整理し直しました。記事では、生成AIができることとして「問い合わせへの一次対応」「オペレーターの回答・メール文面の作成支援」「FAQコンテンツの作成と改善」「問い合わせ内容の要約と応対メモの自動作成」「VOC（顧客の声）分析によるサービス改善」「新人オペレーターの教育とトレーニング支援」の6つが挙げられています。並べてみると確かに幅広い。ただ、稟議書に落とし込もうとすると、「それぞれの投資対効果はどうなるのか」という問いから逃げられません。
弊社は製造業で、カスタマーサポート部門は別組織になっています。自分の部署は営業DX推進ですから、横断的に連携して提案するかたちになります。関係部門の合意を取り付けることだけでも、相当なエネルギーがかかります。経営陣からは以前から「生成AIで効率化できないのか」と聞かれていて、そのたびに「検討中です」と返してきました。さすがにそろそろ具体的な答えを出さないといけない時期に来ています。
記事の中で気になったのは、「検証が不十分なまま導入すると、ハルシネーションによる誤回答や顧客情報の漏えいで、積み上げてきた信頼を一度に失いかねない」という部分です。これは稟議書に必ず書かなければならないリスク項目そのものです。うちのセキュリティ部門は非常に厳しくて、過去にクラウドサービスを導入しようとしたときも、データの保管場所と第三者への学習利用の有無を確認するだけで2カ月かかりました。生成AIとなれば、審査はさらに長くなるでしょう。
今月、部下の中から3名をパイロット検証メンバーに指名しました。いずれも営業支援や提案資料作成をメインにしているメンバーで、IT感度は高い方です。まず社内で許可されているAIツールを使って、FAQコンテンツの草案作成を試してもらいました。
結果は正直、まちまちでした。一人はうまく使いこなして「従来の半分以下の時間でドラフトができた」と報告してきました。ただ別の一人は、「生成された文章の事実確認に時間がかかって、トータルではあまり変わらなかった」と言っていました。これはハルシネーションのリスクをそのまま体験した話です。現場でそういう結果が出るのなら、導入時のオペレーション設計を丁寧に作り込まないと、かえって現場の負担が増えます。
24時間365日の問い合わせ対応が実現できるという点は、経営陣への説明で使いやすい切り口です。うちの営業系の問い合わせは平日昼間に集中していますが、休日の代理店からの連絡対応が常にボトルネックになっています。ここに生成AIを当てられれば、オペレーターの業務負荷を軽減しつつ、対応品質も落とさない可能性があります。投資対効果の試算に使える数字として、部下に問い合わせ件数のデータを月ごとに集めてもらっています。
ベンダー選定の基準については、まだ固まっていません。国内ベンダーか海外ベンダーかという論点も含めて、セキュリティ要件を満たせるかどうかが最初のフィルターになります。記事にある「活用法とリスク対策をセットで押さえること」は、ベンダーへのRFP（提案依頼書）を作る上でも芯になる考え方だと感じました。
稟議を通すためには、楽観的な数字だけ並べても役員には刺さりません。リスクと対策をセットで出して、「失敗してもここまで被害を抑えられる」という設計を見せる方が、うちの経営陣には響く。その構成で次の役員会に臨む予定です。
経営陣が必ず聞いてくること
生成AIのカスタマーサポート活用については、AINOWの記事を読んで整理し直しました。記事では、生成AIができることとして「問い合わせへの一次対応」「オペレーターの回答・メール文面の作成支援」「FAQコンテンツの作成と改善」「問い合わせ内容の要約と応対メモの自動作成」「VOC（顧客の声）分析によるサービス改善」「新人オペレーターの教育とトレーニング支援」の6つが挙げられています。並べてみると確かに幅広い。ただ、稟議書に落とし込もうとすると、「それぞれの投資対効果はどうなるのか」という問いから逃げられません。
弊社は製造業で、カスタマーサポート部門は別組織になっています。自分の部署は営業DX推進ですから、横断的に連携して提案するかたちになります。関係部門の合意を取り付けることだけでも、相当なエネルギーがかかります。経営陣からは以前から「生成AIで効率化できないのか」と聞かれていて、そのたびに「検討中です」と返してきました。さすがにそろそろ具体的な答えを出さないといけない時期に来ています。
記事の中で気になったのは、「検証が不十分なまま導入すると、ハルシネーションによる誤回答や顧客情報の漏えいで、積み上げてきた信頼を一度に失いかねない」という部分です。これは稟議書に必ず書かなければならないリスク項目そのものです。うちのセキュリティ部門は非常に厳しくて、過去にクラウドサービスを導入しようとしたときも、データの保管場所と第三者への学習利用の有無を確認するだけで2カ月かかりました。生成AIとなれば、審査はさらに長くなるでしょう。
部下への展開と現場の反応
今月、部下の中から3名をパイロット検証メンバーに指名しました。いずれも営業支援や提案資料作成をメインにしているメンバーで、IT感度は高い方です。まず社内で許可されているAIツールを使って、FAQコンテンツの草案作成を試してもらいました。
結果は正直、まちまちでした。一人はうまく使いこなして「従来の半分以下の時間でドラフトができた」と報告してきました。ただ別の一人は、「生成された文章の事実確認に時間がかかって、トータルではあまり変わらなかった」と言っていました。これはハルシネーションのリスクをそのまま体験した話です。現場でそういう結果が出るのなら、導入時のオペレーション設計を丁寧に作り込まないと、かえって現場の負担が増えます。
24時間365日の問い合わせ対応が実現できるという点は、経営陣への説明で使いやすい切り口です。うちの営業系の問い合わせは平日昼間に集中していますが、休日の代理店からの連絡対応が常にボトルネックになっています。ここに生成AIを当てられれば、オペレーターの業務負荷を軽減しつつ、対応品質も落とさない可能性があります。投資対効果の試算に使える数字として、部下に問い合わせ件数のデータを月ごとに集めてもらっています。
ベンダー選定の基準については、まだ固まっていません。国内ベンダーか海外ベンダーかという論点も含めて、セキュリティ要件を満たせるかどうかが最初のフィルターになります。記事にある「活用法とリスク対策をセットで押さえること」は、ベンダーへのRFP（提案依頼書）を作る上でも芯になる考え方だと感じました。
稟議を通すためには、楽観的な数字だけ並べても役員には刺さりません。リスクと対策をセットで出して、「失敗してもここまで被害を抑えられる」という設計を見せる方が、うちの経営陣には響く。その構成で次の役員会に臨む予定です。