[Amazon Connect] Connectが東京リージョンに来たので、シドニーのコンタクトフローを移設してみました

1 はじめに

AIソリューション部の平内（SIN）です。

本日、東京リージョンで利用可能になったAmazon Connect（以下、Connect）では、コンタクトフローのエクスポート及び、インポートが可能です。（どちらも、現在ベータとなっています）

今まで、シドニーで運用していたインスタンスを、東京に移行するニーズも多くなるだろう、という事で、コンタクトフローの移設を試してみました。

2 移行対象のフロー

題材として、Lambda の実行を含んだフローで、２つのフローが連携して動作しているものを準備しました。

(1) １つ目のフロー

１つ目のフローでは、Lambdaを実行して、２つ目のフローに遷移させてます。

exports.handler = async function(event, context) {
console.log(JSON.stringify(event));
return { message: "Lambdaのメッセージです" };
}

(2) ２つ目のフロー

２つ目のフローでは、１つ目のフローで実行したLambdaの戻り値を、プロンプト再生した後、キューに入れています。

正常に動作すると、以下のような流れになります。

• 接続
• 「最初のフローです」
• 「２つ目のフローです」
• 「Lambdaのメッセージです」
• キューでの待機

3 エクスポート

問い合わせフローエディタの「保存」ボタンから「フローのエクスポート（ベータ）」を選択すると、コンタクトフローをJSON形式のファイルに出力することができます。

取得したJSONを開いてみると、各ブロックが配列で定義され、ブロックごとに振られたIDで、それぞれが接続されているようすを確認できます。また、別のフローや、Lambdaなどは、それぞれのARNで指定されています。

ARNには、リージョンや、ConnectのインスタンスIDが含まれていますが、東京リージョンに移すことで、この辺がどのようになるか確認していきたいと思います。

１つ目のフローの抜粋

{
"modules": [
{
"type": "SetVoice",
"parameters": [
{
"name": "GlobalVoice",
"value": "Mizuki"
}
],
・・・略・・・
},
{
"type": "SetLoggingBehavior",
・・・略・・・
},
{
"type": "Transfer",
・・・略・・・
"parameters": [
{
"name": "ContactFlowId",
"value": "arn:aws:connect:ap-southeast-2:**********:instance/d091242f-c757-4652-be7b-f9545cf8f8ef/contact-flow/f0cf67dc-81dd-4e06-a504-36251c248486",
"resourceName": "SampleSecond"
}
],
・・・略・・・
},
{
"type": "PlayPrompt",
"parameters": [
{
"name": "Text",
"value": "最初のフローです。",
"namespace": null
},
],
・・・略・・・
},
{
"type": "InvokeExternalResource",
"parameters": [
{
"name": "FunctionArn",
"value": "arn:aws:lambda:ap-southeast-2:**********:function:Relocation_hello"
},
{
"name": "TimeLimit",
"value": "3"
}
],
・・・略・・・
],
・・・略・・・
"type": "contactFlow",
"start": "9639752f-7319-4106-b6ba-5317779db283",
・・・略・・・
}

4 インポート

東京リージョンにインスタンスを上げ、先のフローをインポートしてみます。

(1) １つ目のフロー

問い合わせフローを新規に作成して、保存メニューから「インポート（ベータ）」を使用して、先のフローをインポートしてみます。

読み込んだフローを「保存して発行」とすると、エラーとなります。これは、２つ目のフローへの遷移ブロックがありますが、まだ２つ目のフローが読み込まれていないためのエラーのようです。 取り合えず、ここは「保存」としておきます。

(2) ２つ目のフロー

こちらも、「保存して発行」はエラーとなります。今度は、「キュー」が存在しないためです。ここも、一旦「保存」としておきます。

(3) キュー

キューについては、エクスポート・インポートが出来ないので、新規に作成する必要があります。

(4) 2つ目のフローの「保存して発行」

２つ目のフローに戻って、「保存して発行」をしてみましたが、やはりエラーとなってしまいました。恐らく、名前が同じでも、キューのARNが違うからだと思います。プロパティを開いて、選択リストの中からキューを選択しなおすことで、「保存して発行」が出来ました。

(5) 1つ目のフローの「保存して発行」

その後、１つ目のフローに戻っても、「保存して発行」はエラーでした。 こちらもフローのARNの違いでしょう。プロパティを開いて、選択リストの中からフロー名を選択し直する「保存して発行」が出来ました。

(6) Lambdaの移行

Lambdaのコードを東京リージョンにDeployして、Connectの東京リージョンのインスタンスにパーミッションを与えます。

「AWS Lambda関数を呼び出す」ブロックは、エラーとはなっていませんでしたが、リージョンが変化してARNが変わっているので、変更は必須です。

5 各種ID

ここで移設前と後の各種IDを確認してみると以下のようになっていました。

フロー内の各ブロックのIDは、そのままで、インスタンスIDがインポート先のインスタンスIDに書き換わっています。また、フローのIDは、新しく採番されています。

5 最後に

今回は、リージョン間のコンタクトフローの移行を試してみました。

インスタンスIDについては、インポートで書き換わるので気にしなくても良さそうですが、フローやキューのIDが新たに採番されることに注意が必要そうです。

なお、LambdaのARN書き換えは、必須となります。

多くの場所にLambdaを配置しているような場合は、幸い、エクスポートしたコンタクトフローが非常にわかりやすいJSON形式なので、シェルなどで一発変換してからインポートした方が効率的かも知れません。

弊社では、「Amazon Connect」の導入を検討している方を対象とした無料相談会を毎週開催中です。

また、音声を利用した各種ソリューションの導入支援を行っております。お気軽にお問い合わせください。

チャットボット開発支援

クラウド型コンタクトセンターサービス導入支援