Conversational AI x Agentive Technology
Designing Agentive Technologyという本を読みました。面白かったので、手持ちの事例を交えながら理解を深めてみます。
本書では、Agentive Technologyとは何か、それを通じて人のために働くAIをどうデザインするか、その方法論が記載されています。2017年5月に公開された書籍なので、少し例が古いですが、本書で語られている本質はまだまだ実現できていないことが多く、これからのサービス設計にも非常に役に立ちます。
今、所属しているLINEのAI事業においても、ビジョンとして"より自然な体験"を作り出すことを強調しています。究極の自然さとは、その存在を意識することなく、ユーザーに必要な情報を提供したり、ユーザーに変わって何かアクションをすること、ここに行き着くのではないかと思います。
本書では、これを実現するための技術をAgentive Technologyと呼び、そのような指向を持ったサービスをAgentiveと定義し、そしてそのAgentは"人のために働くAI"であるとしています。
この"人のために働くAI"のサービスデザインについて、本書の中では多くの事例を交えながら明らかにしています。このポストでは本書の内容を参考に、LINE AI事業で展開しているコールセンター向けの対話AIサービス LINE AiCallの事例を交えながら紹介していきます。
Agentiveとは何か
Agentiveなサービスや機能は、ユーザー理解に基づき、ユーザーのために何らかの仕事を実行します。
この仕事を実行する主体がAgentであり、Agentの主な役割は以下の通りです。
1. セットアップ
ユーザーは特定のタスクをAgentに委任し、そのタスクを実行するために必要な権限と設定を与える (e.g. ユーザー理解のためのユーザーデータへのアクセス権限など)
2. 実行 (モニタリングと通知)
決まった時間やユーザーの状態変化、もしくはユーザーからのアクションなど、何らかのトリガーによってタスクが実行される。タスクが実行中、Agentは自身の実行状況をモニタリングし、ユーザーは必要に応じていつでもその状況を知ることができる。タスクが無事に完了したり、もしくは何らか問題が発生した時はユーザーに通知する
3. 例外への対応
例外に対応し、そのフィードバックを元に、Agentの実行時の振る舞いを最適化する
4. ハンドオフとテイクバック
想定外の状況になり、タスクが実行できない場合、Agentはそのタスクが実行できる誰か(ユーザーや他のオペレーター)に引き継ぐ。Agentが実行できる状態に回復した場合、実行に主体をAgentに戻す
優れたAgentは、それがうまく動作している間は、ユーザーの"目"は離れています。そして、何らかの理由でユーザーのアクションが必要な時だけ、Agentはユーザーの注意を引きます。(もちろん、Agentを一時的に止めたり、強制的に動作を変えたりなど、ユーザーがAgentを制御するためのインターフェースは用意されるべきです)
また、Agentは、単に、定義されたインプットからアウトプットまでのプロセスを自動化するだけのものではありません(= Not Automation)。一方で、アウトプットを認識し、考え、次のインプットを生み出すという、人のタスク処理を便利にするだけのものではありません(= Not Assistant)。
むしろ、あるタスクにおいて、それらの全体のプロセスをユーザーに変わって、ユーザーのために実行するものです(=Agent)。
以上が概要です。
次の章からは、LINEのAI事業で展開しているコールセンター向けの対話AIサービス、LINE AiCallを事例として1つずつ深掘りしてみます。
コールセンター対話AIにおけるAgentの定義
コールセンター向けの対話AIサービス、LINE AiCallの場合、タスクの委託元はオペレーターであり、LINE AiCallはコールセンターオペレーターのAgentです。オペレーターに変わって顧客からの問い合わせに答える、という構図ですね。
従って、Agentを管理するのは、オペレーター自身もしくはその企業です。一方で、そのAgentが応対する相手は、顧客です。この構図に沿って、前章の1~4を図に書くと、以下のようになります。
Agentが関わる相手がオペレーター(企業)と顧客の2つあるため、少し複雑ですが、1つずつみていきます。
1. セットアップ
対話AIにおいて、セットアップは、顧客に応対する対話シナリオの設計であり、その応対に必要なデータアクセスなど、一連の対話の実装、そしてその対話シナリオを実行するための初期設定まで含めた全てです。対話設計自体は、それ自身が巨大なテーマであり、ここでは書ききれないため省略します。(機会があればまた書いてみたいと思います)
ただし1つだけ、本書でも触れられており、対話AIにおいても非常に重要な要素があるため紹介したいと思います。それは、能力と制限を適切に伝えることです。
LINE AiCallにおいて、実際に能力と制限を伝達するのは、顧客から問い合わせがあった際の、初めの応答メッセージです。そして、この一番初めのメッセージの中で、能力と制限を端的に伝える必要があります。
<LINE AiCallにおける能力と制限の例>
a) 能力 ・・・ レストランの予約、宅配便の集荷依頼など
b) 制限 ・・・ 人間ではないため、全ての質問に柔軟に対応できないこと
当然、説明が冗長ですと顧客はいらいらして、Agentとの会話をクローズしてしまいます。一方で、これらを正しく伝えないと、顧客を混乱させたり、人間のオペレーターとの対応の違いにがっかりさせてしまいます。
この最初のメッセージにおいて、能力と制限として何をどう伝えるかを決めた上で、それに沿って必要十分は対話シナリオを実装していくべき、と言えるぐらいに、最初のインタラクションは非常に重要なポイントだと思います。
2. 実行(モニタリングと通知)
LINE AiCallであれば、実行のトリガーは、顧客からの問い合わせ(架電)です。
Agentが顧客からの問い合わせを適切に対応している間は、タスクの委託元であるオペレーターやその企業は、基本的にAgentへの注意を向けていません。しかし、一方で、オペレーターが必要に応じて状況を知れるよう、Agentは現状の動作について、常に見える状態にしておく必要があります。
累積のコール数、その瞬間に応対している電話の接続数、顧客とAgentのリアルタイムの対話内容、エラーが発生した状態など、必要に応じて、その状態をモニタリングすることができるようにします。
Agentは自身の状態をユーザーからいつでも見れるようにする一方、特定のイベントについては、Proactiveにユーザーに通知します。タスクの完了、より良い応答の提案、何かしらのエラーや、エラーに近づいた時のアラート、などです。
ユーザーがAgentのことを絶対的に信頼しているのであれば、常時の可視化はなくとも、最低限の通知だけでも良いかもしれません。しかし、その信頼関係を築くためには、Agentの状態を透明にして、その管理者がAgentの働きについて確認し、信用に至るまでのプロセスが必要になります。
LINE AiCallでも、一度、信用されればコール状態のモニタリングはあまり見られないことが多いです。しかし、その信用を獲得するため、もしくはトラブルなどで一度信用を失ったあと、その信用を取り戻すためには、その動作を可能な限り可視化して、適切に動作していることを伝える必要があります。
これは、対話AIに限った話ではりませんね。つまり、状態の可視化と通知を行うことで、Agentの動作を適切に把握することができ、それが結果的にAgentへの信頼に繋がる、ということです。
3. 例外への対応
一般的に話として、委託されたタスクをこなす中で、様々な例外がおきます。
例えば、ルンバであればソファーの下に入ってスタックするのも例外の1つであり、それを引っ張り出して動作可能な場所におくことで自動的に掃除を再開する、というもその例外への対応の1つです。
しかし、対話AIにおける例外への対応は主に2つの観点になります。
3-1. "ユーザーから見た好ましくない動作"に対してのチューニング
簡単な例から始めるため少し話が逸れますが、Google Photosの例を考えてみます。Google Photoには自動的にアルバムを生成してくる機能があります。例えば、その日の異なる年の写真を集める、などですね。この自動生成されたアルバムの通知が届くわけですが、ユーザーがそのアルバムを見ているのあれば、継続的にアルバムを生成するのが良いでしょう。一方、ユーザーが全く見ないのであれば、生成する頻度を下げたり、アルバム化する軸、例えば写っている人で集める、など、動作を変えてユーザーが好む動作を探る必要があります。
この例であれば、ユーザーが保存した写真を見てもらうためにアルバムを作る、という単純なタスクですので、ユーザーのリアクションからアルバム生成の挙動を変化させるフィードバックループを実装するのは割と容易だと思います。
一方で、対話AIの場合、状況はもっと複雑です。LINE AiCallでは、Agentと顧客の対話は多くのインタラクションがあり、その会話を経て聞き取る内容、聞き取って処理する内容も複雑です。
その中での例外は、音声認識で特定の項目が認識できなかった、顧客からの特定の発話の意図理解ができなかったなど、様々です。それらの全ての例外に対して、自動的なフィードバックループ、つまり、原因理解と、その原因を改善するためのコンポーネントの特定(音声認識、意図理解、etc)し、エラーを解消し、その改善されたモデルを検証し、安全にデプロイする、という一連のプロセスを実行するのが理想です。
ただしこのためには、ユーザー行動の適切なデータ化、それに対するモデルの改善、モデルのデプロイと、MLOpsが実装されている必要があります。(MLOpsは、Agentの全体設計において非常に重要なファクターですが、それ自体が壮大で、また現時点で詳細をかける自信がないので割愛します)
3-2. "潜在的な要望"への対応
先のGoogle Photosの例であれば、ユーザーはもっと多くのアルバムを自動生成して欲しいと思っている、という場合です。
これが一番難しいですね。基本的なアプローチとしては、提案です。上のGoogle Photoの例のようにアルバム自動生成の数を少し増やすぐらいであれば、あまりユーザーに不快感を与えないかもしれません。（提案を増やして、その結果、見られる割合が減れば頻度を下げる、という形で比較的簡単に改善サイクルがまわせます）
対話の場合はさらに難しいですね。例えば、LINE AiCallでAgentが顧客と会話している際、私はこんなことも答えられますよ、といきなり言われたら鬱陶しいだけです。正しいアプローチは、ユーザー理解に基づいて提案をすること、だと思います。
上記のポストにも書いたのですが、ユーザーの嗜好、例えば、レストランの予約において、タバコを吸わない人には初めから禁煙席と提案する、などですね。Agentが受けられる要望が喫煙席/禁煙席だけであれば、1つ聞けばすみますが、それが何十もある場合、1つ1つ聞けませんよね。
従って、これに対する解決策は、ユーザー理解に基づいて、顧客が言わなくともAgentから提案することです。ただし、このような提案は、顧客とAgentの長い関わりを持って初めて可能になるものです。したがって、非常に難しくすぐに実現できるものではありません。その一方で、適切な提案ができた時には一気に信頼感が高まるはずです。
以上が例外への対応です。ただし、この章に記載した内容は予め想定された例外です。一方で、実際には事前に想定しないケースが起こること多々があります（実際にはとても多い）。その想定外のケースにどう備えるか、次の章に記載します。
4. ハンドオフとテイクバック
想定外のエラーが起きたとき、Agentが任されたタスクをそのまま継続するのは難しくなります。その際、ユーザーにコントロールを移すか、もしくはオペレーターや他のAgentに再度、委譲することになります。
LINE AiCallの場合、オペレーターに繋ぐのが通常です。LINE AiCallが答えられない要求、応答できない要求の場合、確実にオペレーターに繋ぎます。業務として適用される対話AIの場合、この確実なハンドオフ、つまりオペレーターへの転送が一番重要な要素です。
そのために、オペレーターへのハンドオフの手段があることと、その具体的な方法を伝えることが重要です。とても当たり前のことですが、応答できない要求を顧客が発話した場合に、"オペレーターに繋ぎましょうか?"、と伝えるなどです。
ハンドオフ手段を用意することは、Agent自体がそのタスクの全ての要求を完了できない中で、少なくともタスクの実行をストップさせない必要不可欠な要素です。
例えば、コールセンターの応対でLINE AiCallが90%の対応ができたとしても、残り10%をハンドオーバーなしで対応が終わってしまうと、顧客の満足度は劇的に下がります。それよりも、LINE AiCallが80%の対応だったとしても、残り20%を確実にオペレーター転送できた方が、トータルの満足度は圧倒的に高くなります。
また、一度ハンドオフされた状況においても、イレギュラーな対応が終われば、ユーザー体験を低下させずに、また自動応答にテイクバックできると理想です。
残念ながら、LINE AiCallでもまだテイクバックは実現できていません。
オペレーターから再度Agentに切り替えるだけであれば、どの状態の対話シナリオにテイクバックするかを定義することで、技術的には問題なさそうに思います。しかしながら、顧客の視点では、オペレーターからAgent(自動応対)への単純な切替は、大きくUXを損ねてしまいます。
もし、顧客からみた時に、オペレーターへのハンドオーバーを意識させず、Agentとオペレーターがシームレスにつながれば、UXを損ねずにテイクバックは実現できそうです。
その場合、Agentからオペレータにハンドオーバーするのではなく、Agentを制御しているソフトウェアに変わって、オペレーターが手動でAgentを操作する (Agentを通じてユーザーと会話する)、という形式ですね。まさにAgentが、ソフトウェアとヒューマンオペレーターのハイブリッドで動作する、というイメージです。
顧客に不快感を与えることのないテイクバックが実現できれば、オペレーター業務を最小化し、コスト削減効果を最大化することができると思っています。
まとめ
Designing Agentive Technologyについて、主にコールセンター向けの対話AIサービスLINE AiCallを事例として、4つの項目に分解して考察してみました。
この本で説明されているAgentについて、本が出版された当時であれば、狭い範囲のユースケースでしか実現できなかったかもしれません。
しかしながら、LINEでも取り組んでいるBig Modelの実用化や、その他周辺技術の発展で、ユーザーとのインタラクションを通じて、ユーザーのタスクを代行するAgentの設計思想は、その適用範囲が拡大していくと考えています。
このポストで記載した内容は、コールセンター 向け対話AI LINE AiCallに関係した内容で、本書のごく一部です。本書には、その他多くの事例やトピックが記載されていますので、Agentive Technologyについて興味があればぜひ読んでみてくださいませ。
この記事が気に入ったらサポートをしてみませんか？