Amazon Connect オーケストレーションタイプのAIエージェントでエージェントアシスタント（手動検索・回答の推奨）を試してみた

はじめに

AWSのアップデート情報には明記されていませんが、Amazon ConnectのAIエージェントでオーケストレーションタイプがリリースされました。

Amazon ConnectにおけるオーケストレーションタイプのAIエージェントとは、大規模言語モデル（LLM）が会話の文脈全体を読み取り、「今何をすべきか（検索、要約、回答など）」を自律的に判断し実行する高機能なエージェントです。

従来の「手動検索」や「回答の推奨」といった単機能型とは異なり、状況に応じてツールを使い分けたり、MCPサーバーを利用したり、文脈を踏まえた自然な対話を行ったりすることで、顧客やオペレーターをより柔軟かつ強力に支援します。

以前、Amazon Connect AIエージェントのオーケストレーションタイプのプロンプト内容を確認し、手動検索・回答の推奨タイプと比較しました。
https://dev.classmethod.jp/articles/amazon-connect-ai-agent-orchestration-agent-assistance-prompt-analysis/

今回は、実際にAmazon Connect AIエージェントのオーケストレーションタイプでエージェントアシスタント（手動検索・回答の推奨）を試してみます。

前提条件

• Amazon Q in Connectが有効化されていること。
• ナレッジベースには、クラスメソッドのホームページのHTMLを保存しています。

セキュリティプロファイルの作成

AIエージェント用のセキュリティプロファイルを作成します。

AWSドキュメントには、どの権限を付与するとよいか記載がなかったため、今回はAdmin権限として全ての権限を付与しました。

AIエージェントの作成

AIエージェントを作成します。オーケストレーションタイプの場合、既存のオーケストレーションタイプのAIエージェントからコピーする必要があります。

AgentAssistanceOrchestratorからコピーします。

ロケールは「日本語」、Security ProfilesはAdmin権限のものを設定しました。

デフォルトのAIプロンプトであるAgentAssistanceOrchestrationのプロンプト内容は以下の記事で解説していますので省略します。

https://dev.classmethod.jp/articles/amazon-connect-ai-agent-orchestration-agent-assistance-prompt-analysis/

なお、デフォルトのAIプロンプトであるAgentAssistanceOrchestrationは、global.anthropic.claude-sonnet-4-5-20250929-v1:0を利用していました。

ツールは、以下の2つが用意されています。初期状態ではどちらもInsufficient（権限不足）と表示されます。

• GenerateNotes
• Retrieve

GenerateNotesは、AWSドキュメントに説明がなく、今回の手動検索や回答の推奨には関係ないため、解説を省略します。

Retrieveツールについては、アシスタントの関連付けが必要です。

Retrieveツールについては、アシスタントの関連付けが必要です。

これで保存して公開することで、AIエージェントの作成は完了です。保存後、各ツールのPermissionsはSufficientになります。

なお、セキュリティプロファイルの権限が不足していると、各ツールのPermissionsはInsufficientのままとなります。

RetrieveツールのInstruction TextとExample

RetrieveツールのInstruction Text（指示テキスト）は以下の記載でした。

Search the knowledge base using semantic search to find relevant information.

日本語訳：セマンティック検索を用いてナレッジベースを検索し、関連情報を取得してください。

Exampleは7つ定義されていました。それぞれの内容は以下の通りです。日本語訳にしています。

Example 1: 複数のメッセージパートとソースがある場合（良い例）

良い例 - 複数のメッセージパートとソースがある場合。
<message>
  <message_part>
    <text>これは回答の最初の部分です。</text>
    <sources>
      <sourceId>sampleSourceId_1</sourceId>
      <sourceId>sampleSourceId_2</sourceId>
    </sources>
  </message_part>
  <message_part>
    <text>これは異なるソースを持つ2番目の部分です。</text>
    <sources>
      <sourceId>sampleSourceId_3</sourceId>
    </sources>
  </message_part>
</message>

Example 2: 単一のメッセージパートとソースがある場合（良い例）

良い例 - 単一のメッセージパートとソースがある場合
 <message>
   <message_part>
     <text>保証に関する情報が見つかりました。最初の1年間の製造上の欠陥に対する部品交換が対象となります。</text>
     <sources>
       <sourceId>warranty_policy_2024</sourceId>
     </sources>
   </message_part>
 </message>

Example 3: ソースのないメッセージパート（悪い例）

これは避けるべき例です。

悪い例 - ソースのないメッセージパート（これは避けてください）:
 <message>
   <message_part>
     <text>保証について以下のことがわかりました:</text>
   </message_part>
   <message_part>
     <text>部品交換が対象となります。</text>
     <sources>
       <sourceId>warranty_policy_2024</sourceId>
     </sources>
   </message_part>
 </message>

Example 4: 引用後のメッセージパート外にあるテキスト（悪い例）

これも避けるべき例です。

悪い例 - 引用後のメッセージパート外にあるテキスト（これは避けてください）:
 <message>
   <message_part>
     <text>お客様の保証は、製造上の欠陥に対する部品交換を対象としています。</text>
     <sources>
       <sourceId>warranty_policy_2024</sourceId>
     </sources>
   </message_part>
   他に何か必要なことがあればお知らせください。
 </message>

Example 5: 引用なしで検索結果からの情報を提供すること（悪い例）

これも避けるべき例です。

悪い例 - 引用なしで検索結果からの情報を提供すること（これは避けてください）:
 <message>
 当社では、対象製品に対してメーカー保証期間終了後の延長保証を提供しています。
 </message>

Example 6: 引用があるメッセージとないメッセージが混在する場合（良い例）

良い例 - 引用があるメッセージとないメッセージが混在する場合:
<message>
  <message_part>
    <text>当社の返品ポリシーに基づき、ほとんどの商品は購入後30日以内であれば全額返金のために返品可能です。商品は元の状態で、レシートまたは購入証明書が必要です。</text>
    <sources>
      <sourceId>return_policy_2024</sourceId>
      <sourceId>customer_handbook_3_2</sourceId>
    </sources>
  </message_part>
</message>

<message>
電子機器に関する具体的な保証内容の詳細については現在調査中です。もう少々お待ちください。
</message>

Example 7: 結果がない場合の例

結果がない場合の例:
<message>
そのトピックに関する具体的な情報は持ち合わせていません。
</message>

Connectフロー

利用するConnectフローは以下の通りです。

「コネクトアシスタント」ブロックで、先程作成したAIエージェントを指定します。次のブロックでキューへ転送し、エージェントと接続します。

実際の挙動とログの確認

実際にこのエージェントアシスタント（オーケストレーションタイプ）を稼働させ、チャットでの検証を行いました。以下の操作フローとログから、プロンプトの指示がどのように実行されているかを確認します。

検証シナリオ

1. オペレーターが Amazon Q in Connect で「クラスメソッドメンバーズについて教えて」と手動検索を実行。
   • 
2. その後、顧客が「商品の返品方法について教えてください」と発言し、回答の推奨（自動トリガー）が動作。
   • 

ログ分析の結果、従来の「手動検索」イベント（TRANSCRIPT_QUERY_ASSISTANT）は出力されず、代わりにオーケストレーションタイプ特有と思われる TRANSCRIPT_AGENTIC_MESSAGE が主役となって動作していることが確認できました。

https://docs.aws.amazon.com/connect/latest/adminguide/monitor-q-assistants-cloudwatch.html#documenting-cw-events-ih

なお、Amazon Q in Connectのログ設定方法は以下の記事をご参照ください。

https://dev.classmethod.jp/articles/amazon-q-in-connect-cloudwatch-logs/

1. 手動検索実行時の挙動（所要時間：約16秒）

オペレーターが手動で検索を実行してから、最終的な回答が表示されるまでの流れです。

1. 状況の認識と一時応答

   • Event Type: TRANSCRIPT_AGENTIC_MESSAGE
   • 挙動: AIは {{$.transcript}}（会話履歴）とオペレーターの検索アクションを読み取り、「顧客がサービス概要を知りたがっている」と推論（Thinking）します。
   • 出力: プロンプトの指示通り、まずは「短い承認（Brief acknowledgment）」を出力し、オペレーターにAIが動いていることを伝えます。

     クラスメソッドメンバーズについて調べます。少々お待ちください。
     

2. ツールの選択と実行

   • Event Type: TRANSCRIPT_AGENTIC_MESSAGE
   • 挙動: 質問内容が「情報の検索」であるため、GenerateNotes（要約用）ではなく、ナレッジベース検索用の Retrieve ツールを選択して実行します。

     "toolName": "Retrieve",
     "toolInput": "{ \"retrievalQuery\": \"クラスメソッドメンバーズ\" ... }"
     

3. 回答の生成

   • Event Type: TRANSCRIPT_AGENTIC_MESSAGE (裏側で TRANSCRIPT_LARGE_LANGUAGE_MODEL_INVOCATION が動作)
     • TRANSCRIPT_LARGE_LANGUAGE_MODEL_INVOCATION：レスポンスの生成や会話コンテンツの処理のために大規模言語モデル (LLM) が呼び出されるとログに記録されます。LLM への入力と出力を記録します。
   • 挙動: 検索結果を受け取ったAIは、プロンプトの「HTMLフォーマット」指示に従い、Markdownを使わずにHTMLタグで整形された回答を生成しました。

     クラスメソッドメンバーズについてご説明いたします。<br><br>
     クラスメソッドメンバーズは、コンサルティングから...
     <b>主な特徴:</b><ul><li><b>コストダウン:</b> AWS利用費割引...</li>...</ul>
     

2. 回答の推奨（自動トリガー）時の挙動（所要時間：約25秒）

続いて、顧客が「商品の返品方法について教えてください」と発言し、AIが自動的に反応した際の挙動です。

1. トリガー検知と推奨の表示

   • Event Type: TRANSCRIPT_TRIGGER_DETECTION_MODEL_INVOCATION → TRANSCRIPT_RECOMMENDATION
   • 挙動: 顧客の発言を検知し、推奨記事（Intent）をオペレーターに提示します。オペレーターがこれをクリックすることで、次のエージェントアクションが開始されます。

2. 文脈の維持とオペレーターへの応答

   • Event Type: TRANSCRIPT_AGENTIC_MESSAGE
   • 挙動: AIは直前の会話（クラスメソッドメンバーズについての説明）を記憶しており、文脈を踏まえたメッセージを出力します。これがオーケストレーションタイプの大きな特徴です。

     クラスメソッドメンバーズについては先ほどご説明いたしましたので、返品方法について調べます。少々お待ちください。
     

3. ツールの実行（クエリの拡張）

   • Event Type: TRANSCRIPT_AGENTIC_MESSAGE
   • 挙動: 「返品」について検索を開始します。単なる「返品」ではなく、より確度の高い検索結果を得るために、AIが自律的にクエリを拡張しています。
   • 検索クエリ: "商品の返品方法 返品手続き"

4. 回答の生成

   • Event Type: TRANSCRIPT_AGENTIC_MESSAGE
   • 挙動: 検索結果をもとに、返品に関するポリシーや手順をまとめた回答が生成されます。

従来タイプと応答速度の違い

このように、手動検索と自動推奨が混在するシナリオでも、AIは一貫して「文脈を理解したアシスタント」として振る舞っていることが確認できました。

一方で、応答速度については以下の結果となりました。

• 手動検索: 約16秒
• 回答の推奨: 約25秒

従来の回答の推奨や手動検索のAIエージェントタイプは数秒で応答されますが、それと比べると、応答までの時間はかなり長くなる傾向にあります。

この応答速度の違いは、オーケストレーションタイプ特有の処理プロセスに起因しています。

従来タイプ（回答の推奨）は、「意図抽出 → クエリ生成 → 回答生成」という決まったパイプラインを通過するだけですが、オーケストレーションタイプは「自律型エージェント」として動作します。

具体的には、以下のステップを自律的に判断・実行するため、処理に時間を要します。

1. 思考（Thinking）: 会話履歴全体を読み込み、「今何をすべきか（検索すべきか、挨拶すべきか）」を推論します。
2. 一時応答: ユーザー（オペレーター）を待たせないよう、短い承認メッセージを出力します。
3. ツール実行: 必要に応じて適切なツール（検索など）を選択し、実行します。
4. 最終回答: ツールの結果と会話の文脈を組み合わせて、HTML形式で回答を生成します。

このように、単なる検索・要約マシンではなく、文脈を理解し自律的に行動する「アシスタント」としての複雑な処理を行っている分、応答時間は長くなりますが、その対価として「文脈理解」や「HTMLによるリッチな表現」といった付加価値が提供されています。

なお、このオーケストレーションタイプの詳細な挙動やプロンプトの仕組みについては、以下の記事にてデフォルトのAIプロンプトであるAgentAssistanceOrchestrationの内容をもとに解説しています。

https://dev.classmethod.jp/articles/amazon-connect-ai-agent-orchestration-agent-assistance-prompt-analysis/

最後に

今回は、Amazon ConnectのオーケストレーションタイプのAIエージェントを利用して、エージェントアシスタント（手動検索・回答の推奨）を試しました。

検証の結果、オーケストレーションタイプには以下の特徴があることが分かりました。

• 文脈を理解した自然な対話が可能
• HTMLタグを用いたリッチな回答生成が可能
• 応答速度は従来タイプと比較して遅くなる傾向がある

即時性が求められる場面では従来のタイプが適しているかもしれませんが、複雑な問い合わせや丁寧な対応が必要な場面では、オーケストレーションタイプが強力な支援ツールとなりそうです。

ぜひ、ユースケースに合わせて試してみてください。