VoC対応エージェントビルダー
入る
最近、ムーンライトチームはVoC応対プロセスをエージェントと共に処理しています。この記事では、その過程で何を問題として見て、どんな構造で解いたかをまとめてみます。
このプロジェクトを始めたきっかけは、小さなチームで数多くのVoCを処理し、チームメンバーの疲労感が蓄積されており、これをどのようにより効率的に余裕ができるかという問題解決方法を悩んでいます。
実際のVoCの応対は、答えた文を書くことで終わりません。問い合わせを読んで、ポリシー文書を確認し、コードベースを見て、必要に応じてDBを照会しますが、判断が難しい場合は、その状況をよく知っているチームメンバーに再び質問する必要があります。言い換えれば、VoCの応対は、書き込みよりも照会と判断に近い仕事です。
最近、さまざまなAI機能を備えた顧客応対自動化ツールがあります。ただし、チームに必要だったのは、一般的な回答ジェネレータではなく、私たちのサービスのポリシー、コード、データ、コンテキストに近づきながら、実際のチームメンバーのように照会してクエリできる方法が必要でした。
どんな問題がありましたか？
問題は3つでした。
まず、少数のチームが毎日10件以上の着信VoCを処理しながら、時間とコンテキスト切り替えのコストを一緒に費やす必要がありました。
第二に、チームメンバーごとに持っているコンテキストが異なり、確認する根拠と回答方法にも違いがありました。必要な根拠をどこで確認する必要があるのかすぐに思い出せない場合は、他のチームメンバーに再び質問する必要がありました。
第三に、回答の自動化を試みても、一般的なAI回答機能だけでは内部コンテキストにアクセスすることが困難でした。実際の操作では、自然な文章よりも根拠のある答えがより重要だったため、この限界が明らかでした。
それで、私たちが解決しようとした問題は2つありました。 1つは少ない人員でより多くのVoCを余裕ができる運用効率の問題であり、もう1つは実際のサービスコンテキストと内部根拠を反映する品質の問題でした。
この目的のために、ムーンライトチームはVoCを収集し、必要な根拠を探索し、ドラフトを作成し、最後に人が検収する処理フローを構築しました。
エージェントVoC処理フロー
このプロジェクトを進めながら、まず集中したのは応対過程を構造化することでした。
最初に悩んだのは「何を先に見るのか」でした。実際のチームメンバーが応対する際に繰り返し踏む順序をまとめてみると、概ね下の流れを見せました。
- 既存の会話履歴を確認する
- ポリシー文書の確認
- コードベースの確認
- 必要に応じてDB検索
- 回答ドラフトの整理
最初の目標は、このフローをエージェントが再現できるようにすることでした。
2番目の目標は、責任を依然として人に持たせることです。自動発送は品質とセキュリティの面で負担があったため、探索とドラフト作成はエージェントが引き受け、最終判断は人がするように構成しました。よく言うヒューマンであるザ・ループ方式です。
そのため、このプロジェクトは単純な回答ジェネレータではなく、VoCを収集し、根拠を探索し、ドラフトを作成し、人の検収を経て発送する処理フローを作成する作業に近かった。
Moonlight VoC処理フロー
お問い合わせ
- 顧客の問い合わせがVoCチャンネルに入ります。
- 顧客の問い合わせはWebフックで受け取り、欠落回復のために周期的な照会を補助的に使用します。
- 対応するVoCが処理対象であるかどうかを判断します。
- 処理対象の場合は、人が行っていたフローと同様の順序で根拠を探索します。
- 埋め込まれた既存の会話の照会
- コードベースとポリシー文書の照会
- 必要に応じてデータベース照会 - ナビゲーション結果とテンプレートに基づいて回答草案を作成します。
- ドラフトをスラックに渡します。
7. 担当者がスラックの要約と詳細を確認した後、Send、Retry、Denyボタンで処理方式を選択します。
エージェンティックフローを適用した結果
この構造を適用した後で最も大きく変わったのは、チームメンバーが応対過程の最初から最後まで直接行う必要がないということです。以前は問い合わせを読んで、どんな根拠を確認するかを判断し、必要な情報を見つけて草案を整理する過程を人がすべて引き受けなければなりませんでした。一方、現在では、全体の問い合わせの50％程度は、繰り返しの照会とドラフト作成段階をエージェントが先に処理し、担当者はスラックで最終判断するだけです。
この変化は応答速度だけの問題ではなかった。チームメンバーごとに違ったコンテキスト差を減らし、「これは誰に尋ねなければならないのか」に対する費用も一緒に下げることができました。特に、既存の会話履歴、ポリシー文書、コードベース、データ照会を1つのフローにまとめることで、根拠を見つけるプロセス自体をより一貫して作成することができました。
そこで、このプロジェクトは回答を自動的に送るシステムというよりも、VoC応対過程で繰り返されたナビゲーションとドラフト作成コストを削減する運用ツールとして位置づけられました。
MoonClawとの接続
基本的なVoC収集、基礎探索、ドラフト作成、検収、出荷は、前述のVoC処理フローだけに戻ります。ただし実際に運営してみると、このフローだけで終わらない場合があります。ドラフトを少し手に入れる必要がある場合もあり、現在の問い合わせに関連するプロジェクトの文脈をもう一度確認する必要がある場合もあります。エージェントがやってきた根拠が今の基準でも合うかどうか、また会いたい場合もあります。
こんなとき上で一緒に書いているのがMoonClawです。 MoonClawはVoC処理フロー自体に代わるツールというより、その上で動作するスーパーバイザーエージェントに近いです。通常、VoC処理フローはほとんどの問い合わせを処理し、追加の確認や修正が必要な瞬間にのみMoonClawと会話しながら結果をトリミングする方法です。
たとえば、チームメンバーはMoonClawに、「この回答で支払いポリシーの部分だけを最新のコードで再確認してください」と尋ねることができます。あるいは、エージェントが参照する根拠が現在の運用コンテキストでも依然として有効であるかどうか、特定の表現が実際の方針と矛盾しないかどうかをもう一度確認することもできます。言い換えれば、VoC処理フローがデフォルトパスである場合、MoonClawはその上で例外状況または追加のクエリを受け取るパスと見なすことができます。
この構造が与える最大の利点は操作の柔軟性です。
- 独立エンジン：VoC対応フローは、親エージェントなしで24時間の安定したルーチン作業を処理します。
- インタラクティブ強化：複雑な判断や修正が必要な場合にのみ、MoonClawを介してエージェントと話し合い、結果をトリミングします。
- 文脈の共有：MoonClawはプロジェクト全体のコンテキストを握っているので、単純なVoC処理を超えて、サービス全体の更新方向に合った応対を保証できます。
親エージェントとの疎接続により、ルーチン処理は自動化され、複雑な問題はエージェント間のコラボレーションに解放される拡張可能な運用構造を揃えました。
仕上げ
今回の構築で最も大きく得たのは、エージェンティックシステムが人の仕事をどのように分けて取ることができるのかという感覚でした。人の仕事を丸ごと置き換えるのではなく、探索、根拠収集、ドラフト作成、承認に分けて、そのうち繰り返し可能な部分をまずシステムに任せる方法が効果的であることを確認しました。
逆に最後まで人に残さなければならないことも明らかでした。顧客に実際に出荷するかどうかを決定すること、例外の状況でどのような文脈をより反映するかを判断すること、間違った応対に対して責任を負うことは依然として人の分け前でした。だから今回のプロジェクトは人を取り除く自動化ではなく、人が責任を維持したまま繰り返し作業を減らす構造を作る作業に近かった。
結局のところ、このプロジェクトはVoCオートメーション自体よりも、実際の運用業務をエージェントシステムにどのように移行できるかを実験したケースです。ムーンライトチームには、この経験が単純な応対自動化を超えて、今後他の運営領域を扱う際にも適用できる基準となりました。