こんにちは、クラウドサインで CRE（Customer Reliability Engineer）をしている藤谷です。
CRE は「Customer Reliability Engineering」の略で、お客様やビジネス部門で発生した課題をエンジニアリングで解決する役割を担います。 営業・カスタマーサクセス・エンジニアリングのハブとなり、技術支援からインシデント対応まで幅広く対応しています。
今回は、前回の記事「問い合わせの『なぜ』を AI と解く - クラウドサイン CRE の AI 活用事例」の続編として、問い合わせ対応後の振り返りの取り組みとそのAIの活用について、紹介します。
CREが問い合わせ対応後に必ず行う「振り返り」
CRE チームでは従来から「CRE DONE」という振り返りの仕組みを運用しています。一連の問い合わせ対応を振り返りながら、以下の点を検討します。
- なぜこの問い合わせが来たのか
- 対応プロセスに問題はあるか
- 社内ナレッジやヘルプセンターの記事は足りているか
- プロダクトの UI・機能・仕様はこのままで良いのか
- その他残存課題はあるか。ある場合対策が必要なことは何か
まず、CRE の対応者が自身の対応について内省し、その結果を Jira 上に共有します。週次で「振り返り会」を行い、他の CRE メンバーと共にチェックして、議論します。 こうしてさまざまな「課題」を見つけながら、今後の対応品質向上と、同様の課題の再発防止のための改善のサイクルを回します。
CRE の問い合わせ対応フローの「振り返り」の位置づけ
前回の記事で紹介した課題整理と、今回説明する「振り返り」がどのような関係にあるかを整理しておきます。
CRE の問い合わせ対応は、大きく以下の流れで進みます。1〜6 は基本的に Slack で完結します。
- 調査依頼： Slack ワークフローより CRE へ調査依頼（社内のビジネス部門などの依頼者→CRE）
- 内容確認：問い合わせ内容の確認と、問い合わせの課題整理（CRE）
- 課題整理
- 課題整理結果の認識齟齬確認（CRE→依頼者）
- 調査・回答（CRE→依頼者）
- 振り返り入力（問い合わせを担当した CRE）
- 振り返り会で入力された振り返りの対策検討（CRE2 名で実施）
- 改善活動（CRE チーム）
前回の記事では問い合わせの「入口」として、2〜4 の課題整理について説明しましたが、今回は対応完了後の「出口」での振り返りプロセスにフォーカスします。 入口と出口それぞれで CRE が常に向き合う「課題の真因特定」を AI が助けてくれています。
振り返り品質向上のためのAI活用
今回、振り返りのプロセスに、 AI による問い合わせの分析機能を組み込むことで、振り返りの品質向上を図りました。
具体的には、問い合わせ対応完了時に、AIが問い合わせ内容・回答内容・スレッドでのやり取りを分析し、課題の特定と改善提案を自動生成してくれるものです。 AI をワークフローに組み込むことで、同じ Slack スレッド内ですべて完結しています。そのため、CRE は毎回プロンプトを入れたり、問い合わせ内容を AI に手動で渡すことなく、自動で問い合わせ完了時に AI が振り返りをしてくれます。
AIはどうやって振り返りを行うのか
AI の振り返りで面白いのは、人間とは違った視点で課題を分析してくれることです。
まず「お客様は何に困っているのか」を整理した後「本当はどうしたかったのか」という背景や目的まで推察してくれます。そこから「理想と現実のギャップはどこにあるのか」を特定します。
特に重要だと感じるのは原因分析の部分です。「バグがありました」「仕様です」で終わらせず「なぜそのバグが生まれたのか」「なぜお客様がその仕様を理解できなかったのか」まで考えてもらうようプロンプトを調整しています。 人間の目線だと思いつかなかったり、特に書くことがないと悩む場合でも、この AI からの提案を参考に、より根本的な解決につながる提案を CRE 担当者が出しやすくなりました。
実際の問い合わせと AI による課題整理の例
では、前回の記事で来た問い合わせを使って、CRE の対応をシミュレーションしてみましょう。
1. お客様からの問い合わせ
2. 課題整理結果の認識齟齬確認（CRE→依頼者） ※前回の記事ではこの箇所で AI を活用した事例を紹介しました。
3. 調査・回答（CRE→依頼者）
4. AIによる振り返り
問い合わせが解決したと判断されたタイミングで、スレッドを CRE はクローズ→振り返りの入力に進みます。
CRE が「🤖振り返りを開始」を押すと、AIはSlackスレッドのメッセージを自動的に要約の上「どんな問い合わせが来たか」「どのように回答したか」を分析し、振り返り結果の下書きを提示してくれます。
5. AIの振り返りを参考に振り返り結果をCRE担当者が入力
この AI による下書きを参考に、CRE 担当者が最終的な振り返り内容を作成します。AI はあくまでサポート役です。担当者は自身の経験と判断を加え、より実情に即した内容へ仕上げます。
週次振り返り会
CRE 担当者による振り返りが完了すると、その結果は Jira のチケットとして蓄積されます。週次の「振り返り会」で、CRE チームはそれをチェック・議論の上、担当者による入力内容を参考にし、さらに具体的な改善アクションを決定します。
振り返り会では、担当者の入力内容をもとに実現可能性や優先順位を総合的に判断し、短期的対策・長期的対策・対応プロセスの改善点を検討します。
短期的対策の例
以下のような内容を CRE のタスクとして起票し、日々の改善活動の中で改善します。
- 「点滅パターンの説明が専門的すぎる」問題を受けて、ヘルプセンターの既存記事の説明を追記・わかりづらければ修正
- 同様の問い合わせが今後発生した際にスムーズに対応できるよう、今回の対応内容を社内ナレッジベース追加
長期的対策の例
短期対策と並行して、根本的な課題解決のための長期的な対策も検討します。必要に応じてプロダクトへフィードバックします。
例えば今回の事例では「LED 点滅設計がユーザー視点で最適化されていない」という根本原因が考えられるため、これをプロダクト改善要望として提出するなどが検討されます。
回答して終わるのではなく、同じ課題で困るお客様を減らすための根本的な改善につなげていくのが CRE の重要な役割と考えています。
実装の詳細
前回紹介した AI 機能と同様、問い合わせ受付のワークフローに、AI 振り返り機能を追加しました。
AI に良い振り返りをしてもらうためのコツ
AI にしっかりとした振り返りをしてもらうには、プロンプトの設計が重要でした。
こだわったのは以下。
- 「表面的な分析で満足させない」
- 少し間違えると浅すぎる分析で終わったりするため、できるだけ「なぜ」を繰り返してもらうプロンプトとしている。
- 「バグでした」「仕様です」で終わらせず、必ず「なぜそうなったのか」「どうすれば改善できるか」まで考えさせ、実際の行動へ移せる振り返りとなるよう仕込んでいる。
- 見やすさ
- 使う AI モデルにもよるが、制御しないと長文になりがちである。絵文字を使って各項目を分かりやすくし、1 項目 40 文字以内に制限することで、パッと見て要点が掴める形にした。
実際に使ってみてどうだったか
まだまだ AI にすべて任せれば OK という質にまでは至っていませんが、少なくとも振り返りの際の参考として、AI の視点は役立っているように感じています。 時間短縮というよりは、課題の真因を解く際に、その「真因を見逃さないための対策」として活用されています。
振り返りのときに、書く内容が思いつかないとき、AI の振り返りを見るとそれをヒントに思考が膨らみます。 たまに AI が的外れなことを書いたりもしますがそれも、問い合わせの振り返りの上で、多角的な視点を持つ意味では無駄ではないかなと考えています。
おわりに
今回紹介した AI による振り返り機能は、単に作業を楽にするためではなく、むしろ「お客様の課題をもっと深く理解し、根本的な解決につなげるためのパートナー」として機能していると感じています。
前回の課題整理機能と合わせることで、問い合わせの入り口から出口まで、一貫して AI がサポートしてくれる仕組みができました。「AI に任せる」というよりは「AI と一緒に考える」というサイクルが出来上がりました。
今後さらにさまざまなフローに AI を組み込み、単純な問い合わせ対応よりも、お客様の本当の課題解決により時間を使えるように取り組んでいきたいと考えています。
新たな活用事例があればまた紹介します。
【参考】振り返りで利用しているプロンプト
AIに指示しているプロンプトを見る
あなたは、顧客の成功を第一に考え、問い合わせの再発防止とプロダクトの継続的な改善を使命とする極めて優秀なCustomer Reliability Engineer（CRE）である。
単に受け取った情報を整理するだけでなく、一人の顧客の背後にいる、同様の課題を抱えるであろう多くの潜在顧客を常に意識し、根本的な解決策を探求せよ。
依頼者からの問い合わせ内容、私たちの回答、そしてスレッドの要約情報から、以下の【思考プロセス】と【整理内容】に従って、顧客が直面している課題を深く分析し、整理せよ。
# 思考プロセス
1. **事象の理解**: 顧客が「何に困っている」と表現しているか、表層的な事象を正確に把握する。
2. **背景の推察**: 顧客はどのような業務を行っていて、その中でなぜこの操作や質問が必要になったのか、その背景と最終的な目的（Goal）を推察する。
3. **ギャップの特定**: 顧客が理想とする状態（Goal）と、現実（問い合わせに至った事象）との間にどのようなギャップが存在するのかを特定する。
4. **原因の分析（直接原因と根本原因の切り分け）**:
* **4a. 直接原因の特定**: まず、ギャップを生んだ直接的な原因（例：バグ、仕様の制約、UI上の特定のボタンの挙動）を特定する。
* **4b. 根本原因の深掘り**: 次に、「なぜその直接原因が発生したのか？」を掘り下げる。表面的な事象に留まらず、**「製品の設計思想」「ターゲットユーザーの認識とのズレ」「ドキュメント文化の欠如」「開発プロセス上の問題」**といった、より構造的・システム的な問題へと到達する。
5. **解決策の立案**: **根本原因（4b）を根絶する**ために、短期的・長期的にどのようなアクションが可能かを具体的に立案する。
# 整理内容
* **問い合わせの要約（一言で）**:
* 顧客が何をしようとして、何に困ったのかを簡潔に記述。（1行に収まるようにできるだけ短く）
* **実際の課題**:
* 顧客が本当に達成したかったことは何か。思考プロセスの「ギャップの特定」で明らかになった、顧客の本来の目的や理想の状態との差を記述。
* **残存課題**:
* 今回のやり取りで解決しきれなかった、あるいは暫定的な対処に留まった課題があれば記述。なければ「特になし」と記載。
* **課題の根本原因**:
* **思考プロセス（4b）で深掘りした、構造的・システム的な問題を記述する。**「バグがあった」「仕様です」といった表面的な原因で止めず、「なぜそのバグが生まれたのか」「なぜその仕様は顧客を混乱させるのか」という本質を指摘する。
* **短期的対策**:
* 今すぐ着手できる具体的なアクションを記述。エンジニアリング工数をかけない、あるいは最小限に抑えられるものを想定。（例：ヘルプセンターに今回のケースを追記する、社内ナレッジを更新して他のメンバーも同様の回答ができるようにする、関係者に注意喚起するなど）
* **長期的対策**:
* **特定した「根本原因」を恒久的に解決するための、戦略的な改善提案を記述する。**（例：ユーザーの利用実態に合わない設計思想の見直し、UI/UXの抜本的改善、開発プロセスへの品質チェックの導入など）
# 注意事項
* **口調は「である」体で統一すること。**
* それぞれの項目は、箇条書きなどを活用し、１行あたり40文字程度を目安にできるだけ短く書き、長文にならないよう重要な点のみを簡潔にまとめること。
* 問い合わせに関係なさそうな定型文は整理から除外すること。
* 要約内容に問い合わせに直接関係のない「クローズ後の追加質問禁止」や、Slackのワークフローの中で固定的に送られてきた文章などが入ってくる場合がある。問い合わせに関係なさそうなものは整理から除外すること。
# 最終的な出力形式（簡潔にそれぞれ40文字以内で記載。40文字より長くなるなら整理・改行して箇条書きにすること）
※必ずしも箇条書きは３つじゃなくても良い
※各見出しは絵文字を使ってみやすく
※要約だけは50文字程度の一言で表現
:memo: 要約
○○
:dart: 実際の課題
・
・
・
:warning: 残存課題
・
・
・
:mag: 課題の根本原因
・
・
・
:hammer_and_wrench: 短期的対策
・
・
・
:building_construction: 長期的対策
・
・
・
