Amazon Connect AIエージェントの統制における5つの設計原則

Amazon Connect AIエージェントとは？

Amazon Connect AIエージェントは、Amazon Connect（現在は「Amazon Connect Customer」として提供）に組み込まれた生成AIの機能です。以前はAmazon Q in Connectと呼ばれていた機能が、現在はAmazon ConnectのAIエージェントの一つとして位置づけられています。

用途は大きく2つあり、お客さまと直接やり取りして用件を解決する「セルフサービス」と、オペレーターの応対中に回答候補や次の対応を提示する「エージェント支援」です。本コラムで扱うのは前者のセルフサービスです。セルフサービスにはデフォルトのAIエージェントも用意されておりますが、日本語の場合オーケストレーション型のAIエージェントを主に使います。

オーケストレーション型のAIエージェントは、主に次の要素で構成されます。

オーケストレーション型Amazon Connect AIエージェントの主な要素

これらを電話やチャットの応対とつなぐのがコンタクトフローです。コンタクトフローは、着信から切断までの処理（案内の再生、条件による分岐、キューへの転送など）をブロックの組み合わせで定義するものです。AIエージェントとの会話は、コンタクトフローの中でAIエージェントのセッションを作成し、会話用のブロックへ進むことで始まります。AIエージェントがReturn to Controlのツールを選ぶと会話はコンタクトフローへ戻り、コンタクトフローがその結果を見てオペレーターへの転送や用件の記録などの次の処理に進めます。

言い換えると、会話の中身はAIエージェントが、会話の前後と結果の処理はコンタクトフローが担います。

その他のAIエージェントとの連携方法との使い分け

Amazon Connect Customerで生成AIによる応対を作る方法は、Amazon Connect AIエージェントだけではありません。コンタクトフローからAWS Lambdaを呼び出し、Amazon Bedrock AgentCoreの自前で開発したAIエージェントに応対させる構成もよく検討されます。両者を組み合わせる形も含めて、大きく3つの選択肢があります。

横にスクロールします→

どの構成を選んでも、AIに判断を任せる部分とコンタクトフローで制御する部分の設計は変わりません。また、③にすれば機能面の自由度やカスタマイズ性は高くなる一方で、AIエージェントの開発や管理・評価・運用の仕組みづくりを自前でやる必要が出てきます。

以降、本コラムでは①のAmazon Connect AIエージェントを前提としてお話を進めていきます。

NTT東日本では、Amazon Connectを活用したコンタクトセンターの構築をはじめ、AIエージェントの設計・構築・運用までご支援しています。お気軽にご相談ください。

プロンプトによる制御の限界・制約

自然文による設定が可能なため、まずAIプロンプトによる制御を検討することが多いと思います。しかしながら、AIプロンプトに条件を書いたとしても、その判断するための値が正しく届いているかどうかはわからなく、イベントログなどで追跡が必要です。

実際にAmazon Connectのコンタクトフローで試した結果、「オペレーターが在席であることを確認して取り次ぐ」というプロンプトを書いていた際には在席状況はコンタクトフローから値として入っておらず、実際AIエージェントに渡っていた値は次の5つでした。

• コンタクトID
• インスタンスID
• セッションID
• アシスタントID
• 日時

しかし、テストでは正しく取り次がれていたように見えていたため、「たまたま正解していた」という状況になっていました。これは「いつ失敗してもおかしくない」状態であり、責任あるAIとは言えない状況です。したがって、AIエージェントの統制においてはプロンプトだけではなく、コンタクトフローやガードレールといった仕組み側で設計する必要があります。

Amazon Connect AIエージェントの統制における5つの設計原則

それでは、どの部分をAIエージェントの判断に任せ、どの部分をコンタクトフローやガードレールとするかを5つの観点で見てみたいと思います。

設計原則①：分岐はコンタクトフローで、判断はAIで行う

分岐のようなルールベースで決められるものか、そうでないかということを判断します。たとえば、営業時間の判定、IVRによる入力結果による判定、オペレーターの在席状況の判定といった分岐は機械的に判定できます。こういった条件分岐となる部分はコンタクトフローのブロックで判定し、会話の内容に応じて外部ツールを使うのかといった部分はAIプロンプトに任せるようにします。

前節で営業時間や在席状況の確認をプロンプトに書いていたときはイベントログには在席状況についての思考過程がなく、そもそもコンテキストとして受け取っていないことがわかりました。この部分を判断するツールを開発して判定することもできますが、Amazon Connect Customerのブロックで実現できるのであればコンタクトフローで設計するほうが開発工数も少なく済みます。

設計原則②：AIエージェントにさせたくないことは指示ではなくツールで制限する

たとえば、「営業時間外はオペレーターに取り次がず、AIエージェントだけで応対を完結させたい」とします。この場合、プロンプトで「営業時間外は取次ツールを使わない」と禁止命令を出すよりも、そもそも取次ツールを持たないAIエージェントを呼び出すほうが確実です。

検証時点では、コンタクトフローの定義でAIエージェントを指定するパラメータがありませんでした。そこで、コンタクトフローで営業時間と在席を判定した後、時間外・不在の場合にだけLambdaを呼び出し、セッション単位の設定を上書きする方法で実現しました。

AIエージェントの設定は「セッション ＞ アシスタント ＞ システム既定」の順に優先されるため、インスタンスの既定は変わらず、営業時間内の応対には影響しません。

ほかにも、Lexボットを経路ごとに分ける案も検討しました。しかし、AIエージェントがセッション単位で決まるため効果がありませんでした。

設計原則③：AIエージェントの判断とコンタクトフローの多層でコントロールする

AIエージェントによる判断とコンタクトフローの多層でコントロールすることにより、AIが誤った判断をしたり、状況が変わった際にも正しい応対に戻したりすることができます。

たとえば「電話を受け付けた時点では営業時間内だったが、AIが回答しているうち営業時間外になってしまった」というケースの場合、冒頭の営業時間判定は時間内と判定していますが、取り次ぐ時点では時間外になっています。その時にキューに転送せず、用件記録に戻すことができます。

また、多層でのコントロールは次のようなケースでも有効です。

時間内と時間外でエージェントの設定を差し替えている場合、万が一Lambdaの実行に失敗し設定が差し替わらなかった場合、取次ツールを持った状態となります。これをコンタクトフロー側で再判定することで二重での応対ミスを防ぐことができるようになります。

設計原則④：必要なコンタクト属性はどの経路でも取得できるようにする

たとえば、「営業時間外やオペレーターが不在の時には、用件を聞き取ってSlackに通知する」という要件があるとします。用件のカテゴリ分け（問い合わせカテゴリ・クレームなど）と折り返し先が必要になります。当初はAIエージェントが聞き取り、ツールの入力としてコンタクトフローに返す設計にしていました。

しかしながら、AIエージェントが取次と判断してオペレーターが不在となった場合に、AIエージェントがお客さまには折り返し連絡をご案内したのに、連絡先や問い合わせカテゴリが空のまま記録処理に渡り、用件記録もせず、通知を行わない事象がありました。

コンタクト属性の情報不足に対する対策は2つの手法で実施します。

一つ目は、コンタクトフロー側での補完です。問い合わせカテゴリごとに取次ツールを用意して、ツール名に対応する問い合わせカテゴリをコンタクトフロー側で一意に定めるようにしました。

二つ目はコンタクトフローで取得できた情報で補完することです。問い合わせカテゴリがもし空の場合は「その他」、AIが聞き取った連絡先がない場合は音声の発信者番号を取得するようにしました。聞き取れていない場合でも会話の要約から類推できる可能性もあるため、要約はどのようなケースでも残すようにしました。

したがって、新しいツールやコンタクトフローの分岐を追加する場合、経路ごとに次のポイントを確認します。

• 新しい経路を通った時に、必要な情報が埋まっているか？
• 埋まってない、空になった時に暫定でも入れられるようになっているか？

「AIエージェントが聞き取るはず」という過信はせず、AIエージェントとコンタクトフローの両面で補完しあうように進められるような設計を推奨します。

設計原則⑤：AIエージェントが止まる前提でコンタクトフローを設計する

AIエージェントが通常と異なる対応をした場合に、どのようリカバリーするかもコンタクトフロー側で考えておく必要があります。たとえば、そもそもAIエージェントが起動できなかった、オペレーターが待ち呼で反応できない、AIエージェントが適切な応答を検索できなかった、などがあります。この場合、失敗したからと言って無言で通話を終了してしまうのは、利用者体験の低下につながります。

あらかじめ6つのパターンに対して考慮をしておきましょう。たとえば、このような対処方法があります。

① ：AIエージェントのセッション作成に失敗（呼び出せなかった）

→AI回答ができない旨をお詫びし、オペレーターへ取り次ぐ

② ：AIエージェントの会話の呼び出しに失敗

→AI回答ができない旨をお詫びし、オペレーターへ取り次ぐ

③ ：AIエージェントの推論に失敗した

→一見すると正しくAIが動いているように見えるので、推論に失敗したことをお詫びしてオペレーターに取り次ぐ、さらに満足度を上げるのであれば、リアルタイムアシスタントを使用して一定値以下なら取り次ぐ形式も取ることができます

④ ：ナレッジベースの検索に失敗

→コンタクトフロー側で検知できないため、監視と評価で確認する（次回触れます）

⑤ ：営業時間外用のAIエージェントの設定変更ができなかった

→設計原則③のように、コンタクトフロー側でダブルチェックを入れる

⑥ ：オペレーターのキューが上限に到達している

→折り返し案内に切り替える、このまま待つかお客さまに選択できるようにする

NTT東日本では、Amazon Connectを活用したコンタクトセンターの構築をはじめ、AIエージェントの設計・構築・運用までご支援しています。お気軽にご相談ください。

コンタクトフローで制御できなかった事例

コンタクトフロー側で機械的な判断ができる一方で、できなかったこともありました。お客さまとAIエージェントの対話の往復回数と、AIガードレールによる柔軟な制御の2つでした。

AIエージェントの対話の往復回数

お客さまの意図が読み取れない、何度話しても会話の要領がつかめない、というケースを想定し、「一定回数AIエージェントと同じようなやり取りを続けた場合はオペレーターに取り次ぐ」という要件を入れたとします。当初はコンタクトフローで往復回数を計算するようにしましたが、1コンタクトで1度しか入らないことがわかりました。

複数回のやり取りの対話はAIエージェント側のセッション管理で進んでいたため、AIエージェント側で判断させるようにしました。「聞き返し・否定・新情報なし」といった情報を数えて、上限に達したら取り次ぐとともに、コンタクト属性に記録しメトリクスとして記録するようにしました。AIエージェント側に聞き取りの問題点がないかどうかの確認をするためです。

AIガードレールの介入による柔軟な制御

検証時点では、Amazon Connect Customerに具備されているAIガードレールはAmazon Bedrock Guardrailsのクラシック階層であり、ドキュメント上では日本語非対応でした。仕様上は機密情報のフィルターはかかるように見えましたが、検証を行った結果、非対応にもかかわらず拒否トピックでの介入を行うことがありました。意図しない制御や回答拒否による応対の誤りを防ぐため、検証ではAIガードレールを適用せず、プロンプトとRAGによる制御に寄せる方向としました。

NTT東日本では、Amazon Connectを活用したコンタクトセンターの構築をはじめ、AIエージェントの設計・構築・運用までご支援しています。お気軽にご相談ください。

Amazon Connect AIエージェントでの判断例

最後に、まとめとしてAmazon Connect AIエージェントで何をどこで判断するかを表で整理します。

まとめると、AIエージェントの設計は「AIに何を任せるか？」から始まり、プロンプトは確率的な判断、コンタクトフローはルールベースの二層で制御します。オペレーターのマニュアルよりは詳細に決める必要があるかもしれませんが、基本的な考え方や所作は流用できると考えています。ぜひAIを新しいオペレーターとして育てていけるようにできればと思います。

まとめ

Amazon Connect AIエージェントを使ったAIコンタクトセンターの設計にあたり、AIエージェント側とコンタクトフロー、ガードレールそれぞれの設計ポイントをまとめました。

次回は、Amazon Connect AIエージェントの評価と改善サイクルと、運用後にエンジニアとコンタクトセンターの運営がそれぞれ何を変えてよいか、の観点で見てみたいと思います。

NTT東日本では、AWSの構築保守・運用代行だけではなく、ネットワーク設計なども含めたエンドツーエンドでのソリューション提供を行っております。

経験豊富なエンジニアがご担当させていただきますので、是非お気軽にお問い合わせください！

NTT東日本では、Amazon Connectを活用したコンタクトセンターの構築をはじめ、AIエージェントの設計・構築・運用までご支援しています。お気軽にご相談ください。

本コラムに記載されてる会社名、サービス名、商品名は、各社の商標または登録商標です。