Amazon Connect Analytics Data Lake を試してみた！

はじめに

Amazon Connect Analytics Data Lakeとは、Amazon
Connectのさまざまな種類のデータを一元的にクエリする場所として使用する機能です。

データには、問い合わせレコード、Contact Lens会話分析などが含まれており、これらに対してSQLクエリを実行して分析を行うことができます。

本記事では、Amazon Connect Analytics Data Lake（以下 ADL）を使って、Athena＋QuickSightでの可視化を行うまでの構築手順・検証結果をまとめます。

これは2025年4月時点での情報です。
機能が追加されることが予想され、UIも変更される可能性があります。

全体アーキテクチャと目的

• 利用構成：Connect → Analytics Data Lake → Glue Catalog → Athena → QuickSight
  

• 目的：

  • ADLを活用して何がどこまでできるのかを検証
    • Athenaのクエリで取得可能な情報の範囲
    • QuickSightでどのようにグラフ化・可視化できるのか確認

前提

ADLを使用する前に、以下の設定を行っておく必要があります。

• Amazon Connectインスタンスの作成

構築手順（データの共有〜QuickSight連携）

データ共有の追加（Amazon Connect側）

• Amazon Connectインスタンス > 分析ツール > データレイクから「データ共有の追加」
  • 共有するAWS account IDを記述
  • 例：データ型 Contact record、Agent queue statistic recordなどを選択
    

Resource Access Manager (RAM) の招待承諾

• 自分と共有 > リソースの共有
• 注意点
  • 同一アカウント内で共有する場合もRAMでの共有承諾が必要

Lake Formation の設定

• Data Lake Administrator に操作ユーザー（IAM）を明示的に登録する必要があります
• AdministratorAccess や AWSLakeFormationDataAdmin だけでは不十分です

注意
AWSLakeFormationDataAdmin ポリシーをIAMユーザーにアタッチしたままだとLake Formation許可エラーが発生するのため、事前に外しておくことを推奨します。[1]

データベース・リソースリンクテーブルの作成（Lake Formation）

• Databasesを作成
• Resource linkとして共有用のテーブルを作成
  • Resource link name
    • 任意の文字列
  • Destination catalog
    • 自アカウントID
  • Database
    • 作成したデータベース名
  • Shared table's region
    • Amazon Connectインスタンスを作成しているリージョン
  • Shared table
    • データ共有の追加で追加したレコードが表示される
  • Shared table's database
    • Shared tableを選択すると自動的に追加される
  • Shared table's catalog ID
    • Shared tableを選択すると自動的に追加される
      
• テーブルが作成されたことを確認
  

Athena接続

• 上記で共有したテーブルをAthenaで参照可能になる

• 出力先S3を設定してクエリを実行
  

• 実行結果
  

QuickSight利用のためのLake Formation設定

• QuickSightユーザーのアクセス許可

  • Lake Formationで作成したテーブル(connect_record)を開き、「Actions」から「Grant」を選択
    
  • principals
    • QuickSightユーザーのARN
    • 以下のAWS CLIコマンドによってARN情報の取得が可能

      aws quicksight list-users --aws-account-id [Account_id] --namespace default
      

  • LF-Tags or catalog resources
    • 「Named Data Catalog resources」を選択
  • Catalogs
    • 特に設定していなければデフォルト
  • Databases
    • 作成したデータベース
  • Tables
    • 作成したテーブル
  • Resource link premissions
    • Describe

  
  

• QS Userの権限が新規に作成されていることを確認
  

• データへのアクセス権限を追加

  • 「QuickSightユーザーのアクセス許可」と同じような手順で設定
  • 「Table permissions」は「Select」のみ許可
    
    
    

QuickSightを利用した可視化

• データソースを選択
  • Athenaを選択
    
• データソース作成
  • データソース名
    • 任意の文字列
  • Athena ワークグループ
    • 特に設定していなければ、「primary」
      
• テーブルの選択
  • カタログ
  • データベース
  • テーブル
    
    

検証項目と結果

エージェントごとの応対時間と保留時間の相関

• QuickSight：散布図
  X軸：応答時間の平均
  Y軸：保留時間の平均
  色：エージェント
  

エージェントステータス毎の時間集計

• 使用するクエリ

  • エージェント毎の各ステータスで開始時間と終了時間の差を集計

  SELECT
  agent_username,
  transition.state,
  SUM(
    CAST(
      date_diff(
        'second',
        transition.state_start_timestamp,
        transition.state_end_timestamp
      ) AS BIGINT
    )
  ) AS total_duration_sec
    FROM
  amazon_connect_test.connect_record cr
    CROSS JOIN UNNEST(agent_state_transitions) AS t (transition)
    WHERE
  transition.state IS NOT NULL
    GROUP BY
  agent_username, transition.state
    ORDER BY
  agent_username, total_duration_sec DESC;
  

• QuickSight：積み上げ棒グラフ
  X軸：agent_username
  Y軸：total_duration_sec
  色（凡例）：state
  

※今回はデータ量が少ないため傾向が見えづらいが、本来は各エージェントが「どのステータスにどれだけ時間を使っているか」を一目で把握できる

• QuickSight：ヒートマップ
  X軸(列)：agent_username
  Y軸(行)：state
  色の濃さ(値)：total_duration_sec
  
  ※各エージェントのステータス毎の傾向がわかり、どのステータスで時間がかかっているのか把握しやすい

コンタクト属性の抽出と集計

• 目的

  • コンタクトフロー内のどこまで到達できたのかを把握して傾向を知りたいなど
    • コンタクト属性に到達を確認できるキーを定義していない
    • よって内部で定義されていたキーを用いて実現可能かテストした

• コンタクト属性内の任意のキーの抽出

  • 使用するクエリ

  SELECT
    attributes['postcallTranscribeEnabled'] AS transcribe_enabled,
    COUNT(*) AS count
  FROM
    amazon_connect_test.connect_record
  WHERE
    attributes['postcallTranscribeEnabled'] IS NOT NULL
  GROUP BY
    attributes['postcallTranscribeEnabled']
  ORDER BY
    count DESC;
  

  • 実行結果
    

• コンタクト属性の一覧表示

  • 使用するクエリ

      SELECT
        contact_id,
        attributes
      FROM
        amazon_connect_test.connect_record
      WHERE
        attributes IS NOT NULL
        AND cardinality(attributes) > 0;
  

  • 実行結果
    

結論：Amazon Connect Analytics Data Lakeを使うことの優位性

• Amazon Connect側からLake Formationへのデータの連携が簡単！
  • Glue定義済＋構造化済＋S3連携済み
• Athenaによるクエリ実行からQuickSightなどのBI連携もしやすい

参考記事

• [アップデート]Amazon ConnectでゼロETLを利用した分析ができるようになりました
• [1] Set up AWS Lake Formation
• Amazon Connect 分析データレイク

感想

Amazon Connect から ETL の構築を行うことなく、分析までスムーズに進められるということで、実際に使用してみました。

Lake Formation の設定などでは少しつまずく部分もありましたが、一度設定を済ませてしまえば、Athena や QuickSight を用いて簡単に分析ができるようになりました。

フロー内の情報やコンタクトレコードを内部的に取得し、可視化までできることにとても驚きました。

特に IAM や Lake Formation 周りの権限設定には注意が必要だと感じたので、環境構築時にはあらかじめ確認しておくことをおすすめします。