生成AIを使ったチャットボットは、質問を詳しく入力するほど、意図に沿った回答を得やすくなります。しかし、コンタクトセンターのオペレーターは、お客さまと会話をしながら複数のシステムを操作しています。長い質問文を入力し、AIが回答を生成するまで待つ。日常的な生成AIの利用なら問題のない待ち時間でも、お客さまを保留にしている数十秒は、現場にとって重い意味を持ちます。

若林さんは、Compassが生まれた背景をこう振り返ります。

「たくさん正確な文章で質問すれば、正しい回答にはたどり着きやすい。でも、保留中にそんな長い時間は待てないし、お客さまと話しながら長い文章を打つのも、現実的ではないんです」

コンタクトセンターでツールを使う以上、正しい回答が得られるだけでは不十分です。そのツールを使うことで保留時間や通話時間が短くなるのか。オペレーターがよりスムーズに応対できるようになるのか。実際のセンター運営の改善につながって初めて、導入する意味が生まれます。

「AIがどれだけ賢いか」ではなく、現場で本当に使えるか。Compassの開発は、この視点から始まりました。

コンタクトセンターでは、商品やサービスに関する情報が、顧客管理システムや履歴入力システム、ナレッジシステム、FAQシステム、Excelでまとめられた資料など、複数のシステムや資料に分散していることが少なくありません。検索する言葉が少し違うだけで情報が見つからなかったり、反対に多くの検索結果が表示されてしまったり、「結局どの画面に答えがあるのか分からない」ということもあります。

ベテランのオペレーターであっても、いくつもの画面を切り替えながら必要な情報を探すのは簡単なことではありません。冒頭で紹介したような光景は、決して特別なことではなく、多くのセンターで日常的に起きているといいます。若林さんが話してくれたのは、そんな現場で起きる連鎖でした。

• 繁忙時になると、複数のオペレーターから同時に質問が上がる
• SV（スーパーバイザー、管理者、以下同様）は「あっちでも、こっちでも」呼ばれ、一人ずつ対応していく
• その間、オペレーターは回答を待ち、その先ではお客さまも保留で待つことになる

オペレーターだけが困っているわけではありません。オペレーターが必要な情報へたどり着けないことが、SVの負荷になり、最終的にはお客さまを待たせることにもつながる。この連鎖をどうすれば変えられるのか。それがCompassの重要な開発テーマになりました。

こうした課題に対してCompassが出した一つの答えが、短い言葉からでも、短時間で必要な回答へたどり着けるようにすることでした。若林さんが開発初期のコアとして語ったのが、「短い質問に、5秒で答える」という考え方です。

• 長い文章で状況を説明して入力はしない
• お客さまとの会話の中から得たキーワードなどを入力する
• そこからCompassが意図を捉え、必要なナレッジを探し、回答を提示する

一般的な生成AIの使い方をコンタクトセンターへそのまま持ち込むのではなく、オペレーターが応対しながら使うことを前提に、使い方そのものを設計したのです。

「ちょっとした単語を入力するだけでも、お客さまならこう聞くだろうという質問を想定して、短い時間で回答が返ってくる形にしたかったんです」

背景にあるのは、単なる操作性へのこだわりではありません。

• 検索にかかる時間を減らす
• 保留時間や通話時間を減らす
• オペレーター自身で解決できる範囲を広げる
• SVへ質問が集中する状態を減らす

Compassが目指したのは、生成AIによる”便利な検索”ではなく、センター運営そのものを止めない検索体験でした。

スピードだけでなく、返ってくる回答そのものの「言葉づかい」にも工夫があります。一般的なFAQやナレッジは、情報を正確に記録することを目的とした「説明文」としてまとめられていることが多く、オペレーターはその内容を、お客さまに伝わる話し言葉にいったん変換する必要があります。話すことに不慣れなオペレーターの場合、内容そのものは理解できても、それをどう言葉にすればよいか考える時間がかかってしまうことも少なくありません。

Compassでは、AIが生成する回答自体が、そのままお客さまへの説明としても使える文章になるよう設計されています。ナレッジの内容をオペレーターが都度言い換える必要が少なく、回答をほぼそのまま読み上げるだけで、お客さまへの案内になる場面もあるといいます。

一方、生成AIをお客さま対応に利用するときには、もう一つ大きな課題があります。それは「その回答を、そのまま信じてよいのか」という課題です。生成AIである以上、誤った回答を生成する可能性を完全になくすことはできません。コンタクトセンターの場合、その回答がお客さまへの案内に使われるため、これは特に重要な問題です。

そこでCompassでは、AIが生成した回答だけではなく、回答の根拠となった元のナレッジも同じ画面上に表示する設計を採用しました。さらに、元資料のどの箇所を参照したのかも確認できるようにしています。

「AIの回答と、その回答の根拠になった元のナレッジを並列で表示しています。元の資料にこう書いてある、ということをその場で確認できるようにしたかったんです」

• AIが答えを出したから、そのまま使う
• そうではなく、オペレーター自身が根拠を確認し、自分で判断したうえで案内する
• AIに判断を任せるのではなく、人が判断するためにAIを使う

この考え方にも、コンタクトセンターでの利用から逆算したCompassの特徴が表れています。

実際のコンタクトセンターには、これまで蓄積してきたさまざまなナレッジがあります。

• Wordで作成されたマニュアル
• Excelの一覧表
• PowerPointの商品資料

形式もつくり方も、一様ではありません。Compassでは、こうした資料についても、テキストや表、画像などの情報を処理し、生成AIが扱いやすい形に変換して活用する仕組みを取り入れています。

インタビューでは、「既存のナレッジを使うために、利用者側で資料をすべてつくり直す必要があるのか」という点についても尋ねました。若林さんからは、「人が見て理解できるようにつくられた一般的な資料であれば、その内容をナレッジとして読み取れるよう工夫している」という説明がありました。

新しいAIを使うために、これまで蓄積した情報資産を捨てるのではない。すでにセンターにあるナレッジを、どうすればより使える状態にできるのか。技術だけではなく、実際の導入や運用を見据えた発想です。

Compassの開発背景を聞いていく中で、繰り返し登場したのが、本当に必要なものを絞り込むという考え方でした。開発では「Working Backwards」という手法が取り入れられています。これはAmazonなどが実践してきた開発手法で、「今ある技術で何ができるか」ではなく、「顧客が本当に困っていることは何か」から逆算してプロダクトを考える、という発想です。世の中にある製品を見て、「競合にこの機能がある」「このツールにも、この機能がある」と、機能を積み上げる考え方とは異なります。

• まず、コンタクトセンターで何が起きているのか
• そこで誰が困っているのか
• その課題を解決するために、最初に絶対に必要な価値は何なのか

そこから逆算してプロダクトを考えていきました。

「世の中のソフトウェアが持っている機能をリストアップして、全部充足していくという考え方ではないんです。本当に”これだけは必要だ”というものをまず作る、という考え方です」

開発前には、実際のコンタクトセンターとも継続的にコミュニケーションを取りながら、現場で起きている課題を整理しました。そのうえで、最初のプロダクトで届けるべき価値を絞り込んでいったといいます。

Compassは、技術から出発して「この技術を何に使おう」と考えたサービスではありません。現場の困りごとからスタートし、その課題を解決するために必要な技術を選んでいった。その順番が、Compassの設計思想を特徴づけています。

では、開発する中で大変だったことは何だったのでしょうか。若林さんに尋ねると、少し意外な答えが返ってきました。

「これができたら便利だよね、というものはいくらでもあります。私としても、あれもこれもできればもちろんうれしい。でも、限られた開発リソースでやる以上、まず何に集中するのかを絞らないといけないんです」

そして若林さんは、開発者として感じる”歯がゆさ”についても話してくれました。

「あえてこの機能はつけていない、というものもいっぱいあります。そこは自分の中では歯がゆいところでもあります」

便利そうなものをすべて搭載すれば、機能は増えていきます。しかし、それによって本当に解決したかった課題がぼやけてしまえば、本末転倒です。だからこそ、「何ができるかではなく、何を解決するのか。その優先順位を崩さない」というCompassの設計思想につながります。

若林さんの言葉からは、Compassの機能だけでは見えてこない、プロダクトづくりの葛藤も垣間見えました。

こうしてつくられたCompassを、実際にセンターで働くSVなどに見てもらうと、若林さんにとって印象的な反応が返ってきたといいます。

「SVさんやセンター管理を担う方々からは、すごく評判がいいというか、”これだったら使えそう”と言っていただくことがあります」

特に評価されているのが、画面を見ただけでも「コンタクトセンターでどう使うものなのか」をイメージしやすいこと。また、従来の検索環境で必要な情報になかなかたどり着けなかった人ほど、短い言葉から必要な回答が表示されることへの反応も大きかったそうです。

最新技術を使っていることではなく、「これなら現場で使える」と思ってもらえること。実際のコンタクトセンターから出発したCompassにとって、その言葉は大きな手応えの一つになっています。

インタビューの最後に、少し視点を変えて尋ねてみました。なぜ、「Compass」という名前をつけたのでしょうか。若林さんは、こう答えました。

「迷うオペレーターさんに、正しい道を指し示す。広い海の中で、”こっちだよ”と進む方向を示すようなイメージですね」

コンタクトセンターでは、オペレーターが応対の中で、「どう答えればいいのか」や「どの情報を見ればいいのか」と迷う場面があります。そんなとき、必要な情報へ進む方向を示す存在になりたい。だから、「Compass」。

約1時間にわたって開発の背景や設計思想を聞いた最後に語られたその言葉は、Compassがこれまで目指してきたものを、とてもシンプルに表しているように感じました。

• 生成AIを使うことそのものが目的なのではない
• オペレーターが迷ったとき、必要な情報へすばやくたどり着ける
• それを自分で確かめ、自信を持ってお客さまへ案内できるようにする

コンタクトセンターで働く人の「道しるべ」になる。Compassという名前には、そんな開発チームの思いが込められています。もし、貴社のセンターにも「もう少し早く答えが見つかれば」「SVがもっと落ち着いて対応できれば」と感じる瞬間があるなら、それはCompassが向き合ってきた課題と、同じかもしれません。

ここまでご紹介してきたように、Compassは「生成AIを使う」ことではなく、「現場のオペレーターが迷わず、自信を持ってお客さまに応対できること」を目指してつくられたプロダクトです。日々のセンター運営の中で近い課題を感じている方は、ぜひ実際の画面や活用イメージを見てみてください。記事だけでは伝わりきらない部分も、きっと感じていただけるはずです。