Amazon Connect 標準データテーブル機能を利用してLambda実装無しを実現

1. はじめに

これまで「電話番号に応じて着信先を変える」「VIP顧客を判定する」といった処理には、外部のテーブルを参照するためにDynamoDBなどのDBとLambda関数を組み合わせることがありました。
Amazon Connectに「データテーブル (Data Tables)」機能が登場しており、ユースケースによってはLambdaのコード管理不要になりそうです。

・公式ドキュメント
Create and configure data tables

2. 内容整理

• Lambda不要で直接参照・更新が可能
  フロー内の「データテーブル (Data Table)」ブロックを使用することで、Lambda関数を介さずに直接データの「読み取り (Read)」や「書き込み (Write)」が可能です。
• シンプルな構成
  Lambdaのコード管理やIAM権限の設定、DynamoDBのキャパシティ管理といった外部リソースのメンテナンスが不要になります。
• 構造化データの管理
  データテーブルはメタデータ（列/属性）と値（行）で構成されています。特定のレコードを一意に識別するための「プライマリキー（主属性）」を設定でき、単一キーだけでなく、複数の属性を組み合わせた複合キー（例：言語＋部署）による検索もサポートしています。
• 即時反映
  データテーブルへの変更は即座にフローやAPIに反映されます。
• 運用担当者向けのUI（管理画面）
  DynamoDBなどの操作は技術的な知識が必要ですが、データテーブルはAmazon Connectコンソール画面でアクセスでき、コードを書かない運用担当者でも操作がしやすいです。
  ※「Views（ビュー）」機能と組み合わせることで、カスタムのUI画面を作成できるみたいですが、筆者は作り方がわかりませんでした。

ユースケース例

Amazon Connect内で設定に影響を与えるデータを保存・管理
◦ キュー割り当て、営業時間、スキルマッピング、エスカレーションルールの管理
◦ 言語、所在地、VIPステータスによるルーティングの変更
◦ 緊急プロトコルの起動

3. 作業の前提条件

• セキュリティプロファイル権限
  ルーティングにデータテーブルが存在しますので、任意の項目にチェックを付けます。

• アクセス確認
  ルーティング > データテーブルにアクセスします。
  

4. 検証内容

• シナリオ
  特定の電話番号（VIP）から電話がかかってきたら、専用のキュー（Queue）に着信。それ以外は一般窓口キューへ着信。

データテーブル設定

ステップ1：データテーブルの作成

• 名前: VIP_Routing_Rules（任意）
• タイムゾーン: Asia/Tokyo
• ロックレベル: 任意
  

設定補足

1. タイムゾーン (Time Zone)
   この設定は、データテーブル内で「時間に関連する動的な値」を扱う際に、どの地域時間を基準にするかを定義します。
   テーブルの評価（Evaluate）を行う際、リクエストにタイムゾーンが含まれていない場合、ここで設定したタイムゾーンがデフォルトとして使用されます。
   例えば、「日付」や「時間帯」によってルーティングを変えるような高度な設定を行う場合、この設定が UTC のままだと、日本時間（JST）と9時間のズレが生じ、意図した通りに動作しない可能性があります。

2. ロックレベル (Lock Level)
   この設定は、複数の管理者が同時にデータテーブルを編集しようとした際の「排他制御（衝突防止）」の範囲を決定するみたいです。

• Data table（データテーブル）
  データテーブル自体のロックバージョンです。楽観的ロックとテーブルバージョン管理に使用されます。テーブルのメタデータまたは構造が更新されるたびに変化します。
• Primary value（プライマリの値）
  特定のプライマリ値セット(レコード)に対するロックバージョンです。これは、表にプライマリ属性がなくてもデフォルトレコードを含みます。記録レベルのロックに使用されます。
• Attribute（属性）
  特定の属性のためのロックバージョンです。ValueLockLevelがATTRIBUTEの場合、属性の値が変わるとこのバージョンも変わります。他のロックレベルについては、属性のプロパティが直接更新された場合にのみ変わります。
• Value（値）
  特定の値のロックバージョンです。個々の数値が変更されるたびに変化します。最も細かいロッキング制御に使用されます。
• None（なし）
  ロックを行いません。

ステップ2：属性追加

テーブルができたら「属性を追加」を選択します。

• プライマリ属性 (検索キー):
  ◦ 名前: PhoneNumber
  ◦ タイプ: テキスト
  ◦ プライマリ属性として使用：チェック
• その他の属性 (取得したい値):
  ◦ 名前: TargetQueueARN
  ◦ タイプ: テキスト

タイプは次から選択できます。

1. 単一のテキスト、数字、またはブール(はい/いいえ)属性
2. テキストまたは数字の一覧

Point: データテーブルに値を追加した後は、プライマリ属性への追加やそこからの削除はできません。プライマリ属性を追加またはそこから削除するには、すべての値とデフォルト値を削除してください。

ステップ3：レコード追加

「レコードを追加」からテスト用の電話番号と、着信先のキューARNを登録しておきます。

フロー設定

ステップ1：①データテーブルブロック

ドキュメントでは、データテーブルの読み取り/書き込みを選択できるように記載がありましたが、検証で確認した時点ではそのような項目は無く、読み取り専用でした。
◦ データテーブル: VIP_Routing_Rules
◦ クエリ名: GetQueue （名前は任意。あとでこの名前を使用する。）
◦ プライマリ属性
　▪ 属性名を選択: PhoneNumber
　▪ 属性キーを入力: $.CustomerEndpoint.Address （システム属性の顧客の電話番号）
◦ クエリ属性: TargetQueueARN

ステップ2：②コンタクト属性を確認するブロック

データテーブルブロックの結果として、TargetQueueARNの値が取得できたかどうかを確認します。
確認する属性
◦ 名前空間: データテーブル
◦ キー: GetQueue.TargetQueueARN （GetQueueはステップ1で定義したクエリ名）

チェックする条件
◦ 条件: 次で始まる:
◦ キー: arn:aws (ARN形式でキュー情報を登録しているため)

ステップ3：③作業キューの設定ブロック

キュー別 / 動的に設定
◦ 名前空間: データテーブル
◦ キー: GetQueue.TargetQueueARN （GetQueueはステップ1で定義したクエリ名）

全体のフローイメージ

※取得した値をプロンプトの再生ブロックで動的に読み上げたい場合など、設定を直接記載する場合は$.DataTables.[クエリ名].[列名]となります。

着信動作

データテーブルに登録した電話番号から架電・作成したフローを実行し、想定のキューに着信すれば成功です。

5. サービスクォータ

テーブル — インスタンスあたり合計100個
属性（列） — テーブルあたり100個
値（セル） — テーブルあたり1000個
テキスト値の文字数制限 — TEXT型は5000文字、TEXT_LIST型は1000文字。
（2025/12/10時点）

DynamoDBは数百万行のデータを扱えますが、Connectのデータテーブルは大規模なデータ管理の利用には向きません。
今回検証した特定番号からの着信先キュー決定は、少数であれば活用もできそうといったところでしょうか。

6. その他

検証時はすべてのデータテーブルの設定を把握できませんでしたので、活用する場合はもう少し詳細を追う必要があります。

その他の活用例として、運用緊急時にコンタクト属性の値を変更したり、緊急ログインユーザーをオンラインにしたりすることで、フロー確認ブロックで分岐を変えて緊急アナウンスを流す、といったフローを過去に作成したこともありました。
今回のデータテーブル機能で、ブール値の変更をすればフロー動作を変えることができるので、より便利に運用ができそうです。