カスタマーサポートの自動化を進めるなかで、すでにコールフローとして作り込んできた注文照会や手続きの処理を、新しい会話AIでもそのまま活用したいと考える場面があります。2026年10月16日、AWSはAmazon Connect Customerにおいて、フローモジュールをagentic CX designerのData requestsとして利用できるようになったと発表しました。詳細はAWS What's Newの発表資料で確認できます。
この機能により、すでに実績のある業務ロジックをゼロから再構築することなく、会話フローのなかへ組み込めるようになります。発表では、会話の決まったタイミングで確実に呼び出す「Data request node」としての利用に加え、AIエージェントが必要だと判断した際に呼び出すツールとしての設定も可能です。発表での利用例としては、顧客プロフィールやケースの更新、問い合わせタスクの作成、さらにはプライベートネットワーク内のAWS Lambda関数を介して口座残高や保険金請求の状況を取得する構成などが挙げられています。
会話AIから呼び出すための前提とバージョン指定
既存のフローモジュールをそのままデザイナー上で選択できるわけではありません。Amazon Connect CustomerのData requests公式ドキュメントによると、あらかじめ管理者がConnect Customer側でモジュールを公開し、外部呼び出しを有効化しておく必要があります。未公開のモジュールや外部呼び出しが許可されていないモジュールは、選択候補のリストに表示されません。
また、呼び出すモジュールのバージョン管理にも配慮が必要です。設定時には「Latest」または「特定バージョン」のいずれかを選択します。Latestを選んだ場合は、モジュールが改修されて再公開された際に自動で最新版が適用される仕組みです。一方、特定バージョンを固定した場合は、モジュール本体が更新されても指定した番号の動作が保たれます。まずは特定バージョンで動作を固定して検証を進め、業務の更新タイミングに合わせて版を切り替えるといった運用設計が現実的です。
模擬応答による確認と実モジュール呼び出しによる検証範囲
設定を進めるうえで特に意識したいのが、デザイナー画面上でのテストと実環境での挙動の違いです。公式ドキュメントに明記されているとおり、リソースエディターやキャンバス上で行うテストでは、設定した模擬応答（モック）が返される仕組みになっており、実際のフローモジュールは呼び出されません。本物のモジュールが実行されるのは、実際の会話が発生したときのみです。
さらに、Data requestの設定が問題なく保存できたとしても、それは入力形式などの整合性が通ったことを示すのみで、参照先モジュールが実在しているかや公開状態であるかまでは検証されません。そのため、設定完了だけで安心せず、実環境を想定したテストケースで呼び出しが正しく成立するかを確かめる段取りが不可欠です。
加えて、処理の性質に応じた設計上の注意点もあります。たとえば顧客情報の更新やタスク作成のように状態を変更する処理は、会話の再試行によって同じ意図から複数回呼び出されるリスクへの配慮が必要です。二重処理を防ぐ冪等性の担保や、多重実行を防止する仕組みをモジュール側に設けておくことが公式資料でも推奨されています。また、非同期で呼び出す構成を採る場合はノード直後の失敗分岐が存在しないため、後続の会話ターンで結果が取得できなかった場合の案内をあらかじめ設計しておく必要があります。
小さく試す手順とデノフがお手伝いできること
国内のEC事業者がこの機能を試す場面を仮定すると、まずは更新を伴わない「注文照会」から着手するのが手堅い進め方です。注文番号を受け取って配送状況を返すモジュールを特定バージョンで接続し、デザイナー上での模擬応答による会話確認と、検証環境での実呼び出し確認を段階的に分けて実施します。その後、問い合わせタスクの起票といった更新処理へと対象を広げ、再試行時の重複防止や例外時のオペレーター転送を固めていく流れが考えられます。
デノフでは、デノフのサービス案内に掲載しているとおり、業務システムの設計・開発や、AI導入における業務の整理、対象業務の選定、ツールの接続支援を一貫して行っています。今回のAmazon Connectの新機能を活用する場合でも、既存の問い合わせ対応のどこをAIに任せ、どの既存APIやモジュールと接続すべきかの切り分けから、失敗時の応答を含めた検証計画の策定まで具体化が可能です。自社の顧客対応フローにAIを組み込む際の整理や連携設計について検討されている方は、デノフへの相談窓口よりお気軽にご相談ください。
