Amazon Connect オーケストレーションタイプのAIエージェントでセルフサービスを試してみた
はじめに
Amazon ConnectのAIエージェントにはオーケストレーションタイプがあります。
Amazon ConnectにおけるオーケストレーションタイプのAIエージェントとは、大規模言語モデル（LLM）が会話の文脈全体を読み取り、「今何をすべきか（検索、要約、回答など）」を自律的に判断し実行する高機能なエージェントです。
従来の「手動検索」や「回答の推奨」、「セルフサービス」といった単機能型とは異なり、状況に応じてツールを使い分けたり、MCPサーバーを利用したり、文脈を踏まえた自然な対話を行ったりすることで、顧客やオペレーターをより柔軟かつ強力に支援します。
以前、Amazon Connect AIエージェントのオーケストレーションタイプのセルフサービスタスク向けプロンプト内容を確認し、セルフサービスタイプと比較しました。 今回は、実際にAmazon Connect AIエージェントのオーケストレーションタイプでセルフサービスを試してみます。
前提条件
- Amazon Q in Connectが有効化されていること。
- ナレッジベースには、クラスメソッドのホームページのHTMLを保存しています。
セキュリティプロファイルの作成
AIエージェント用のセキュリティプロファイルを作成します。
エージェントアプリケーションの接続アシスタントの表示のみ許可します。
AIエージェントの作成
AIエージェントを作成します。オーケストレーションタイプの場合、既存のオーケストレーションタイプのAIエージェントからコピーする必要があります。
SelfServiceOrchestratorからコピーします。
ロケールは「日本語」、セキュリティプロファイルは先程作成したものを設定しました。
デフォルトのAIプロンプトであるSelfServiceOrchestrationは、apac.amazon.nova-pro-v1:0を利用していました。
別のモデルを利用したかったため、SelfServiceOrchestrationのプロンプト内容は変えずに、モデルのみapac.anthropic.claude-sonnet-4-20250514-v1:0 (クロスリージョン)に変更したカスタムAIプロンプトを作成し、今回のAIエージェントに設定しました。
なお、デフォルトのAIプロンプトであるSelfServiceOrchestrationのプロンプト内容は以下の記事で解説していますので省略します。
デフォルトでは、以下のツールが用意されています。
- Complete
- Escalate
- Retrieve
Retrieveツールについては、アシスタントの関連付けが必要です。関連付けず、保存してもエラーにならない点に注意が必要です。もちろん、関連付けしない場合、実際の通話にて、Retrieveツールが選択されると回答はできません。
これで保存して公開することで、AIエージェントの作成は完了です。保存後、各ツールのPermissionsはSufficientになります。
なお、セキュリティプロファイルの権限が不足していると、各ツールのPermissionsはInsufficientのままとなります。
RetrieveツールのInstruction TextとExample
RetrieveツールのInstruction Text（指示テキスト）は以下の記載でした。
ちなみに、以前検証した、オーケストレーションタイプのAIエージェントのエージェントアシスタントタスク向けのRetrieveツールとは内容は異なりました。
Search the knowledge base using semantic search to find relevant information. Use the results of the RETRIEVE tool to provide an informed answer to the customer's query.
日本語訳：セマンティック検索を使用してナレッジベースを検索し、関連情報を探してください。RETRIEVEツールの結果を使用して、顧客の問い合わせに対して情報に基づいた回答を提供してください。
Exampleは2つ定義されていました。それぞれの内容は以下の通りです。日本語訳にしています。
Example 1
良い例
<message>
お客様の保証は、最初の1年間の製造上の欠陥に対する部品交換をカバーしていることがわかりました。また、メーカー保証期間終了後も、対象製品に対して延長保証を提供しております。
</message>
Example 2
結果なしの場合の例：
<message>
そのトピックに関する具体的な情報は持ち合わせておりません。
</message>
Connectフロー
利用するConnectフローは以下の通りです。
「顧客の入力を取得する」ブロックで、先程作成したAIエージェントを指定します。
実際の挙動とログの確認
実際に「オーケストレーションタイプ」と、比較対象として従来の「セルフサービスタイプ」のAIエージェントを稼働させ、同じシナリオ（同じモデル、同じ質問内容、チャネルはチャット）で検証を行いました。
検証シナリオ
- 顧客が「クラスメソッドについて教えてください。」と質問（ナレッジベースに情報がある質問）。
- 顧客が「福岡オフィスの住所を教えてください。」と質問（ナレッジベースに情報がない質問）。
- 顧客が「お願いします。」（または「オペレーターに変わってください」）とエスカレーションを要求。
1. オーケストレーションタイプの挙動
ログ分析の結果、従来のチャットボットのような単純な「検索→回答」ではなく、オーケストレーションタイプ特有の TRANSCRIPT_AGENTIC_MESSAGE イベントを中心に、AIが自律的に思考・判断して対話を進めている様子が確認できました。
① ナレッジベースに情報がある場合
AIは顧客の入力を受け取ると、まず「検索が必要」と判断し、顧客を待たせないために自律的に一時応答を発話します。その後、ツールを実行して回答を生成します。
- 一時応答
クラスメソッドについてお調べいたします。少々お待ちください。 - ツール実行:
Retrieveツールで "クラスメソッド" を検索。 - 最終回答: 検索結果（HTML）を読み込み、整形された回答を提示。
クラスメソッドについてご案内いたします。 クラスメソッド株式会社は、AWSの総合支援サービスを提供している企業です。主なサービスとして「クラスメソッドメンバーズ」というAWS総合支援サービスを展開しており、コンサルティングからシステム構築、運用保守代行まで幅広くサポートしています。 （中略） 本社は東京都港区の日比谷フォートタワー26階にあり、札幌にもオフィスを構えています。 他に何かお知りになりたいことはございますか。
② ナレッジベースに情報がない場合
「福岡オフィスの住所」について検索を行いますが、結果に関連情報が含まれていないことをAI自身が評価します。
- 一時応答
福岡オフィスの住所についてお調べいたします。少々お待ちください。 - 挙動: ハルシネーション（嘘の回答）を起こさず、「情報がない」と正直に判断。
- 最終回答: 謝罪と代替案（エスカレーション）をセットで回答しました。
申し訳ございません。現在、私が確認できる情報では福岡オフィスの住所が見つかりませんでした。東京の日比谷本社オフィスと札幌オフィスの情報はございますが、福岡オフィスについての情報は確認できませんでした。 詳しい情報につきましては、代表電話の0120-991-668（平日9時30分から18時30分）までお問い合わせいただくか、担当者におつなぎすることも可能です。いかがいたしましょうか。
③ エスカレーション
顧客が提案を承諾すると、AIはスムーズに有人対応への移行メッセージを生成しました。
- 最終回答
かしこまりました。それでは、担当者におつなぎいたします。少々お待ちください。
2. セルフサービスタイプの挙動
比較として、同じモデル（apac.anthropic.claude-sonnet-4-20250514-v1:0）を使用したセルフサービスタイプでも同様の検証を行いました。
こちらは TRANSCRIPT_SELF_SERVICE_MESSAGE イベントでログが出力され、「前処理」と「回答生成」の2段階でシステム的に処理が進みます。
① ナレッジベースに情報がある場合
- 前処理: 検索クエリの生成と同時に、待機中に流すためのメッセージ（パラメータ）を生成します。
- 生成されたパラメータ:
"クラスメソッドについて詳しく調べさせていただきます。少々お待ちください。" - ※オーケストレーションタイプとは異なり、AIが直接発話するわけではなく、Connectフローに渡すパラメータとして生成されます。
- 生成されたパラメータ:
- 回答生成: 検索結果を元に回答を生成します。
② ナレッジベースに情報がない場合
- 挙動: 検索結果に答えがないと判断した時点で、システムプロンプトの指示に従い処理を終了します。
- 最終回答: 「回答がありません」 のみが出力されました。
③ エスカレーション
- 挙動: 顧客の「オペレーターに変わってください」という発言に対し、前処理段階で即座に
ESCALATIONツールを選択し、処理を完了しました。
3. 応答速度と挙動の比較
顧客の発言終了から、最終的な回答（またはアクション）が完了するまでの時間を計測・比較しました。
| シナリオ | タイプ | 一時応答までの時間 | 一時応答から 最終回答までの時間 |
合計所要時間 |
|---|---|---|---|---|
| 1. ナレッジあり （検索＋回答生成） |
オーケストレーション | 約 3.0秒 | 約 12.5秒 | 約 15.5秒 |
| セルフサービス | (約 3.0秒)※ | 約 7.0秒 | 約 10.0秒 | |
| 2. ナレッジなし （検索＋回答なし判定） |
オーケストレーション | 約 3.5秒 | 約 8.5秒 | 約 12.0秒 |
| セルフサービス | (約 3.0秒)※ | 約 3.0秒 | 約 6.0秒 | |
| 3. エスカレーション （オペレーター転送） |
オーケストレーション | - | 約 3.0秒 | 約 3.0秒 |
| セルフサービス | - | 約 2.5秒 | 約 2.5秒 |
時間はログのタイムスタンプに基づく概算です。
※セルフサービスタイプには、AIが自律的に「少々お待ちください」と発話する機能はありません。表中の時間は比較のため、検索を実行する直前の処理（クエリ生成など）が完了した時間を記載しています。
なぜ速度と挙動に差が出るのか
1. 構造による速度差
オーケストレーションタイプは、LLMが「思考（Thinking）」を行い、自律的にツールを選択・実行し、その結果を元に回答を生成するという複雑なプロセスを経ます。一方、セルフサービスタイプは「前処理」→「回答生成」という決まったパイプラインで処理されるためオーバーヘッドが少なく、特に検索を伴う回答で5秒以上の差がつきました。
2. 「情報なし」の場合の決定的違い
最も挙動が異なるのが「ナレッジに情報がない場合」です。
- オーケストレーション: 「情報がない」と判断した後、文脈に合わせて「申し訳ありません、見つかりませんでした。担当者にお繋ぎしましょうか？」と丁寧な会話を生成するため、処理時間がかかります。
- セルフサービス: 答えがないと判断した時点でシステム的に処理を切り上げ、即座に「回答なし」ステータスを返すため、速いです。
まとめ
今回の検証から、オーケストレーションタイプのAIエージェントは以下の特徴を持つことが確認できました。
- 自律的な判断: 顧客の質問に対して「検索が必要か」「情報が見つかったか」「エスカレーションが必要か」を自律的に判断しています。
- 正直な回答: 検索結果に関連情報がない場合、ハルシネーション（嘘の回答）を起こさず、「情報がない」と正直に回答できています。
- プロンプトへの忠実性: 「まずは検索することを伝える（一時応答）」「解決できない場合はエスカレーションを提案する」といったシステムプロンプトの指示を忠実に守って動作しています。
特に、情報がない場合に無理に回答を作らず、スムーズに有人対応へ誘導できる点は、顧客体験の観点からも有用であると感じました。
