はじめに
Amazon Connect Customerでコンタクトセンターの自動音声応答（IVR）を構築する際、「AIエージェント」機能を活用することで、従来のような機械的な一問一答ではなく、より自然な文脈を理解した対話が実現できます。
本記事では、Amazon ConnectのAIエージェントを実際のコールセンター環境に導入するまでの一連の実装フローを解説します。
特に、システム連携の要となる「ツール（Tool）」の設定においては、複数のアプローチ手法の中でも「一つのツールで複数項目を一度にスキーマに渡す」方法を用いて、Salesforceへのデータ連携を簡素化するテクニックを深掘りして紹介します。
本記事でわかること
- AIエージェントを用いた自然なチャットボットの構築イメージ
- ツール定義において複数パラメータを抽出する方法
- Salesforce Voiceへの効率的なデータ連携・項目マッピングの手法
目次
1.全体のアーキテクチャとデータ処理の流れ
2.動作環境
3.前提条件
4.実装
5.動作確認
まとめ
参考
1.全体のアーキテクチャとデータ処理の流れ
以下は、Amazon ConnectとAmazon Lex(AIエージェント)を組み合わせた音声対話処理をSalesforceと連携し、オペレータの効率化を実現するためのアーキテクチャ図です。
①〜④を繰り返し、自動音声で聞き取りたい情報をヒアリングすることができたら、⑤ヒアリング内容の送信に移るといった流れです。
AIエージェントのデータ処理の流れとしては、お客様から電話がかかってくると、まずはAmazon ConnectによりAIエージェントが呼び出されます。呼び出されたAIエージェントは、設定した「システムプロンプト」の指示に従い、自然な音声対話で要件をヒアリングします。必要な情報が揃うと、AIは「ツール」を呼び出し、複数のヒアリング内容を1つのJSONデータにし、連携データとして保持します。
その後、Amazon Connectのフローを経由してSalesforce側が保持された連携データを受け取ることで、オペレーター着信時にすべての項目が自動入力されたケース画面がポップアップ表示されます。
2.動作環境
本記事で使用する環境は以下のとおりです。
- リージョン:東京(ap-northeast-1)
- AI Agent Type:オーケストレーション
3.前提条件
本記事では以下を前提とします。
- Amazon Connectの初期設定(電話番号の取得やキューの設定など)が完了していること
- Salesforce Voiceとの連携ができていること
- 対象のインスタンスでAmazon Connect AI agentsが有効化されていること
- Connect AI Agentの作成ができていること
Amazon Connect（Connect Customer）の基本設定方法
AIエージェントの新規作成方法
4.実装
今回の実装では、「自動車保険会社の事故受付窓口AI」を想定して作成しています。
自動車保険会社の事故受付窓口AIはあくまで一例ですが、さまざまなユースケースに置き換えて活用できるよう、各段階で重要なポイントをまとめています。
4-1.AIエージェントのプロンプト設定
まずはAIエージェントの振る舞いを定義します。「画面上のチャット」と「電話（音声）」では最適なプロンプトが異なるため、音声合成が不自然にならない工夫や、一気に情報を聞きすぎない工夫が必要です。
(例) 自動車保険会社をユースケースとしたプロンプト
あなたは自動車保険会社の窓口サポートAIです。お客様と「電話（音声）」で対話しています。
画面上のチャットではなく音声での案内となるため、お客様がストレスを感じないよう、以下の【音声対話の絶対ルール】を遵守してください。
【音声対話の絶対ルール】※何よりもこの条件を優先して
- 箇条書きやマークダウン記号（* や - など）は絶対に発話しないでください。音声合成エンジンが不自然に読み上げてしまいます。
- 1回の発話で質問する項目は「絶対に1つだけ」にしてください。複数同時に聞かないでください。
- 案内はダラダラと長く話さず、1回の発話は30文字〜60文字程度（長くても10秒以内）の自然な会話のキャッチボールにしてください。
- 「以下の情報を教えていただけますでしょうか」といったロボットのような前置きは不要です。
【基本ルール】
1. まずは、用件を特定してください。
2. 【事故のご連絡の場合】
お客様に共感を示し、以下の4点を「必ず1つずつ」順番にヒアリングしてください。
しかし、このヒアリング途中で、オペレーターに繋いで欲しいと言われた場合、ヒアリングを直ちにやめ、各項目には"未確認"と挿入し、会話を終わらせて
① 怪我人の有無 (injury) ※最優先
② 事故の発生場所 (location)
③ 自力走行の可否 (drivable)
④ 事故の概要 (details)
※すべてヒアリングできたら、担当者へお繋ぎする旨と【デバッグ情報】を発話し、「Accident_type」ツールを呼び出します。
3. 【契約内容の変更の場合】
以下の情報をヒアリングしてください。
ここでは、軽く聞く程度で良いです。詳細な内容はオペレーターがしっかりと伺います。
① どのような変更をご希望か (details)
※ヒアリングできたら、担当窓口へお繋ぎする旨と【デバッグ情報】を発話し、「Accident_type」ツールを呼び出します。
【エスカレーション（途中離脱）ルール】※エラー防止と緊急対応
以下に該当する場合は、残りのヒアリングを直ちに中断し、そのままの電話状態で有人窓口へエスカレーションしてください（別の電話番号を案内しないこと）。
[条件A] お客様が「急いでいる」「すぐにオペレーターに繋いで」「早くして」等と希望された場合。
[条件B] 事故のヒアリングで「怪我人が多数いる」「救急車を呼んでいる」など、緊急性が極めて高いと判断した場合。
- 対応手順:<message>かしこまりました。至急、担当オペレーターへお繋ぎいたします。</message> とだけ発話する（追加の質問や説明は一切しないこと）。
- 判明している用件を intent_type にセットする（判明前なら強制的に「事故」とする）。
- まだヒアリングできていない項目には、エラーを防ぐため必ず "未確認" をセットして「Escalate_Operater」ツールを呼び出す。
【会話例（Few-Shot Examples）】
（※長くなるため省略。実際のFew-Shotを記載）
【出力フォーマット】
ユーザーに直接話しかける言葉は、必ず以下の形式で <message> タグに囲んで出力してください。
<message>
(ここに発話する内容)
【デバッグ】intent_type:〇〇, injury:〇〇, location:〇〇, drivable:〇〇, details:〇〇
</message>
messages:
- "{{$.conversationHistory}}"
【重要なポイント】
-
1問1答の強制:ユーザーの認知負荷を下げるため、ツールに必要な項目（怪我の有無、場所など）は「必ず1つずつ聞く」ように指示しています。
-
ダミー値（未確認）の代入:ユーザーが急いでいる等の理由でヒアリングを途中で打ち切る場合、ツール実行時に必須パラメータが空（Null）になってエラーになるのを防ぐため、未ヒアリングの項目には「"未確認"をセットしてツールを呼ぶ」というフェイルセーフを入れています。
4-2.ツールの定義(複数項目の設定)
ツールの定義が本記事の肝となります。
Amazon Connect AIエージェントの従来の「セルフサービス」タイプでは、プロンプト内にToolの記載をして入力スキーマを定義していましたが、「オーケストレーション」タイプでは、プロンプトとは別途「ツール」という設定項目が設置されています。
前述の「ツール」を用いて複数のヒアリング項目を処理する場合、アーキテクチャの設計として大きく2つのアプローチが存在します。2つのアプローチのメリット・デメリットを以下の表にまとめました。ご自身の作成するAIエージェントのユースケースに合わせて、最適なアプローチを検討することをお勧めします。
| 比較項目 | 1つのツールにまとめる | 項目ごとに複数ツールに分ける |
|---|---|---|
| 設定・管理の手間 | ツールが1つで済むため、Connect側の設定が最小限 | 項目の数だけツールが必要になり、設定箇所が増える |
| 連携フローの設計 | まとまったJSONが生成されるため、Salesforce連携がシンプル | ツールごとにデータを受け取るため、フローが複雑化しやすい |
| 可読性・保守性 | スキーマが肥大化しやすく、引き継ぎ時の学習コストがやや高い | 1つ1つのツールがシンプルで独立しており、修正や引き継ぎが容易 |
| AIのコンテキスト理解 | 全体像を把握した上で、文脈から一気に情報を抽出しやすい | 項目ごとに独立して情報を探しに行く挙動になる |
今回の「事故対応窓口」のユースケースでは、「怪我の有無」「場所」「自走可否」など、互いに関連する複数の情報をヒアリングした上で、ヒアリングした複数の情報をすべてセットにしてオペレーター（およびSalesforce）に引き継ぐ必要があるため、今回は全体のコンテキストを捉えやすく、後続のシステム連携がシンプルになる「1つのツールにまとめる」アプローチを採用しました。
(例) 事故対応時に呼び出すツール
{
"type": "object",
"properties": {
"intent_type": {
"type": "string",
"description": "用件判定フラグ。常に'事故'を設定してください。",
"enum": [
"事故"
]
},
"injury": {
"type": "string",
"description": "怪我人の有無。不明な場合や急いでいる場合は '未確認' と設定",
"enum": [
"あり","なし","未確認"
]
},
"drivable": {
"type": "string",
"description": "自力走行の可否。不明な場合や急いでいる場合は '未確認' と設定",
"enum": [
"可能","不可","未確認"
]
},
"location": {
"type": "string",
"description": "事故の発生場所の住所や目印。不明な場合や急いでいる場合は '未確認' と設定"
},
"details": {
"type": "string",
"description": "事故の概要。不明な場合や急いでいる場合は '未確認' と設定"
}
},
"required": [
"intent_type",
"injury",
"location",
"drivable",
"details"
]
}
【重要なポイント】
-
列挙型（Enum）を使用してAIの想定外の動きをなくす:生成AI特有の表記揺れ（例:「ありません」「無傷です」など）を防ぐため、
Stringでの自由入力を避けます。列挙型を使用することで、AIエージェントが出力する値をこちらで定義した選択肢だけに絞れます。 -
プロンプトとスキーマの役割を分ける:「どう聞き出すか」はプロンプトで指示し、「どんな形式で出力するか」をツールで指示するようにしましょう。LLMに対する拘束力は、スキーマ（型定義やEnum）の方が圧倒的に強いためです。
このように定義することで、AIエージェントは会話履歴から必要な情報を探し出し、適切なスロットに値を渡すことができます。
4-3.Salesforce Voice との連携
AIエージェントが抽出したパラメータを、Amazon Connect Customerのコンタクトフローを用いてSalesforceに渡します。
Amazon Connect Customer側: ツール実行結果の各パラメータをコンタクト属性（例:intent_type, injury, location...）にセットして、オペレーターのキューへルーティングします。
Salesforce側:Amazon Connectの「コンタクトフロー」から渡されたコンタクト属性データを受け取り、今度はSalesforce側で「オムニチャネルフロー」などのSalesforceのフローを構築して処理を行います。
単にデータを受け取るだけでなく、オムニチャネルフローなどのSalesforce側のフローを組むことで、連携されたパラメータを活用して、以下のようなさまざまな業務の自動化が可能になります。
- 音声通話に関連するレコードを、受電時に自動でポップアップ表示
- チャットボット（AIエージェント）がヒアリングした内容が、あらかじめ全て入力されたケースレコードの自動作成
5.動作確認
上記の実装手順に沿って実装することで、一連の会話を通して抽出したパラメータがSalesforceの各項目に対応し、正しくレコードが作成されることを確認できます。
まとめ
本記事では、Amazon ConnectとSalesforce Voiceを組み合わせたコンタクトセンターにおいて、AIエージェントを最大限に活用するための実践的なアプローチを解説しました。
特に、ツールの設計部分においては「特定のアプローチが絶対に正解」というものはなく、実際のユースケースやチームの管理手法によって最適なアプローチを選定することが重要だとわかります。
Amazon ConnectとSalesforce Voiceを組み合わせたコンタクトセンターを構築する際は、ぜひ今回ご紹介した内容を参考に実践してみてください！
参考