当社は様々なクラウドサービスの代理店を行っていますが、その事業の中の顧客サポート業務をAzure OpenAIを使って改善してみました。まだベータ版の本番運用を始めたばかりですが、早速成果が上がっているのでブログにしています。
3行サマリー
- 当社は各種クラウドサービスの代理店業務やコンサルティング業務の中で、Slack Connect を使った顧客サポートを行なっていますが、この顧客サポートを「クオリティを落とさずに効率よく対応できないか」という課題に取り組んでいました。
- 今回、Azure OpenAI Service と過去3000件の顧客対応記録を使って「過去の類似チケット」と「回答の下書き」を自動生成するようにシステムを構築しました。
- 100点満点（≒お客様にそのまま提示できる）のアウトプットは出ませんが、サポートエンジニアの対応を補助する情報を出力することができ、顧客サポート対応の効率が上がったというフィードバックが得られました。
ご好評いただいているSlack顧客サポート
当社は各種クラウドサービスの代理店業務やコンサルティング業務の中で、Slack Connect を使った顧客サポートを行なっています。当社とご契約する際、両社の Slack を Slack Connect で繋ぎます。そして、お客様目線では購入製品等に関する問い合わせをSlackを通じて行えます。その製品について詳しいエンジニアと直接やりとりし、Slackを通じたスムーズなコミュニケーションを行えるという点が、ご好評いただいているポイントです。
一方、当社側ではSlackで質問された投稿に対して「起票しました」スタンプを押します。すると、iPaaS（Workato）がタスク管理システムにチケットを自動で作成し、社内の顧客サポート専用チャンネルに通知します。その後、その質問に回答するために最も適切なメンバーがアサインされ、質問に対して回答を行います。また、エンジニアが立候補して対応することもあります。
このような仕組みのおかげで、当社目線ではSlack上で多くのサポート業務を完結させ、「社内ユーザー体験の向上」や「業務効率化」を実現してきました。また、「タスクの抜け漏れの防止」という効果も発揮しています。ちなみに当社ではこの一連の業務のことを社内用語で「ASK対応」と読んでいます。
ご好評いただいているが故の嬉しい悲鳴
一方で、物事には必ず2面性があるもので、その顧客サポートの負荷が一部エンジニアに重くのし掛かっているという側面もあります。ASK対応が得意なメンバーは社内で「ASKの神」や「ASKの貴公子」と呼ばれ、社内外から絶大な信頼を集める一方で、日々多くの問い合わせに追われています。
また、会社全体で見ると、顧客サポートに関わる時間の比率が増えると、新製品検証や新プロジェクト等にかける時間が相対的に減ってしまうという側面があります。当社は新しいものを素早く試して、お客様より先に地雷を踏み抜いた上で新しい価値を創出し、その知見をお客様に還元することを大事にしています。そのため、検証などの時間を確保するために、エンジニアは高いクオリティでのサポートと、対応時間の削減の狭間で日々戦っています。
2021年から蓄積した3000件の対応記録を使った業務改善
そこで、ASK対応のクオリティを落とさずに、対応時間を削減するために、Azure OpenAI Service と過去3000件の顧客対応記録を使って「過去の類似チケット」と「回答の下書き」を自動生成するようにシステムを構築し、運用を開始しています。新しいシステムのフローは以下のような流れです。
当社のユーザー（サポートエンジニア）目線の実際の画面は以下の通りです。まず、以下のようにお客様から質問が来たとします。すかさず当社のメンバーが「起票ボタン」を押します。
すると、iPaaS（Workato）がトリガーされて、過去の類似チケットを探索して、回答の下書きと共に出力します。
このように「類似チケット」と「回答の下書き」を表示することで、以下のような効果があると考えています。
?類似チケット
- 過去の問い合わせ記録と全く同じ質問が来た場合は「類似チケット」を参照し、仕様変更の可能性を担当者で精査した後、そのまま参照して回答できる可能性があります。
- 過去の問い合わせ記録と類似の質問が来た場合は「類似チケット」を参照し、調査の切り口等を参考にしながら問い合わせに対応することができるようになり、調査の方向性や、回答の粒度・クオリティを他の質問と揃えることができる。
?回答の下書き（AIの回答）
- 「回答の下書き」はそのままお客様に出せるものではないが、ゼロから回答を作るよりは圧倒的に効率よく回答文を作成することができるようになる可能性がある。
アーキテクチャや構築のポイント解説
アーキテクチャや構築方法の全てを解説すると文量が凄まじくなるので、今回のブログではポイントに絞って解説し、詳細は別の機会としたいと思います。
?AIのモデルはベースモデルを利用
AIのモデルはGPT-3.5-turbo-16kのベースモデルを利用しています。GPT-4も試しましたが、コストパフォーマンスも考えて、現時点ではGPT-3.5-turbo-16kのベースモデルを採用しています。また、Fine-tuningは行わず、検索（RAG）だけで実装しています。「Fine-tuningで出力の型式を合わせると、より回答の下書きが使いやすくなるのか？」という点は今後の検討課題です。
?データ整備（構築段階）
構築において、まず過去のASKの対応記録を抽出し、個人情報や顧客固有の情報を削除する等の加工処理をしたデータセットを作成しました。現状はGoogleのスプレッドシートで管理しており、「チケット名」「質問」「回答」「URL」というセットで管理しています。個人情報は予め定められた場所のみで管理し、必要以上に流通させないように気にかけて社内の仕組みを構築しているため、 Azure Blob Storage にアップロード前には全て精査されます。
辛かった点としては、「チケット名」「質問」「チケットURL」に関しては3000件の構造化されたデータセットとしてチケット管理システム（Asana）上に存在していたのですが、「回答」に関してはSlack上に点在している状況だったことです。そのため、僕が夜な夜な手作業で集めてきましたｗ（はい、アナログ野郎と呼んでください。）といっても、早くリリースしたかったので、大半の「回答」はブランクのままリリースしており、日々更新を続けています・・・
?データ整備（ライフサイクル管理）
新しい質問がきたらWorkatoが自動で追記するようにしていますが、そのデータをAzureに上げる前の編集・加工は手でメンテナンスをしています。この部分もChatGPTやWorkatoにやらせて完全自動化させたいなとは思いつつ、手作業でやることでAI開発のインプットがたくさん得られているので、自動化の塩梅については今後の検討課題としています。
?フィードバックの収集
エンジニアはこのシステムの実行結果に対するフィードバックを送れるようにしています。このケースは何故良いアウトプットだったのか？悪いアウトプットだったのか？を分析する際や、品質の評価に活用していく方針です。
?Web検索は未実装
今回の実装では検索の対象範囲は過去の問い合わせ記録（3000件）だけでしたが、今後は情報検索の部分でWeb検索は絶対に組み込みたいと考えています。時間の都合で、そこまで作り込む前にリリースしてしまいましたが、特にクラウドサービスに関する問い合わせでは各ベンダーのサイトを参照して回答することが多いので、急いで対応したいと考えています。
フィードバックや筆者の感想
こからは、実際に受けたフィードバックや筆者がやってみての感想をまとめています。
類似チケットは40点
Azure OpenAIのアウトプットのうち、「類似チケット」の部分ですが、あえて点数づけをするとしたら、筆者主観で【40点】という点数をつけました。40点とした理由は以下の通りです。
- 全く同じ質問が来ることは稀であるが、3回に1回ぐらいのペースで「対応に参考となるチケット」が表示されるため、その投稿を参考にしながら対応を行うことができる。（3回に1回でも超嬉しいというフィードバックあり）
- 過去の対応記録を参照してから回答すると、対応のクオリティや方向性の平準化が見込めるというフィードバックが得られたため。
- 過去の問い合わせ記録を参照することで、埋もれていた知見を発掘するキッカケとなった事例が生まれたため。
- DBにない問い合わせには対応ができないため。（当然ではあります。）
回答の下書きは10点
Azure OpenAIのアウトプットのうち、「回答の下書き」の部分ですが、あえて点数づけをするとしたら、筆者主観で【10点】という点数をつけました。10点とした理由は以下の通りです。
- お客様に出せるクオリティの回答が表示されることはほぼない。
- 10回に1回ぐらい対応に参考となる回答の下書きが表示されるため、その投稿を参考にしながら対応を行うことができる。（回答で伝えたかったことの一部を代弁してくれるなど）
前提として、現在は過去記録のうち、回答部分のデータベース整備が追いついていない状況であり、実質的にはChatGPTに質問しているのとほぼ変わりません。この点に関しては、アップデート後に再度評価したいと考えています。
40点で嬉しい業務を見つけることが大事
今回構築したシステムは、自社データを参照しているとはいえ、虚偽の情報を出したり、関係ない情報を出してきたりもします。しかし、それでも本番環境でリリースできた要因としては、「40点の成果物でもあってくれたら嬉しい場所」にアウトプットを配置したからです。
もし、お客様に直接回答を見せるようなデザインの場合や厳密さが求められる出力の場合は、相当高得点を叩き出さないとリリースはできなかったと思いますが、現状出せる精度を勘案して、適用する業務を決めていくことは重要なことだと感じました。
AOAIを業務プロセスに組み込み、ユーザーがプロンプトを入力せずに使えるようにしたのが肝
ChatGPT（AOAI）をユーザーに与えてもゴリゴリに使いこなせるのは一部のだけのケースが多いと思っています。最初は面白がって遊ぶかもしれませんが、そこから業務でゴリゴリ活用できるところまでには高いハードルがあります。やはりChatGPTをうまく活用するには、ユースケースを見極めて、プロンプトを工夫（プロンプトエンジニアリング）する必要があるので、ユーザーの力量に深く依存します。
今回のアプローチでは、ユーザーにプロンプトを入力させることなく、自然と活用させるようなフローとすることを目指しました。ChatGPTを無理やり使いたい病と線引きが難しいですが、相性が良さそうな場所に刺しにいくと価値を出しやすいと思いました。
情報を再利用可能な状態にして、活用が難しいテキストデータを価値に変える！
今回の取り組みを通じて過去の情報を再利用可能な状態とするということは、情報システムの構築においてすごい大事なことだと再認識しました。過去の情報を蓄積するするだけでは価値は生まれません。特にテキストデータは埋もれてしまうので、情報量の割には利活用が難しいと考えています。テキスト生成AIの活用により、圧倒的に活用の機会が増えたと実感しています。
また、再利用可能な状態とするためには、ある程度構造化した状態で保管することが大事だと感じました。AsanaやSlackって、それぞれの投稿とかチケットがユニークなURLが振られていて、かつ、一定の構造化されたデータになっているため、今回のケースでは活用しやすかったです。
おわりに
今回のシステム構築を経て、ChatGPTは「おもちゃ」ではなく、業務改善するツールに近づいてきたなという実感を強く得ました。また、顧客サポート業務と生成AIは非常に相性が良いのかと思います。まだ、ロードマップとして積んでいる改修タスクが大量にありますが、伸び代しかないので今後の検証やアップデートも楽しみです。ちなみに、今回構築したシステムのフロント部分はWorkato職人のShunsukeに作ってもらいました。この場を借りてお礼を言いたいと思います！
