本記事では、Amazon ConnectとAWS Systems Manager Change Calendarを組み合わせ、コールフローを修正することなく営業時間の変更や休業日の設定を柔軟に行う方法をご紹介します。本ソリューションを導入することで、Amazon Connectのコールフローの修正工数を削減し、運用負荷を大幅に下げることが可能となります。
1. 概要
1.1 Amazon Connectを利用する目的と背景
-
背景
一般消費財製造業では、電話による注文受付や問い合わせ窓口の需要が高く、コールセンターの効率的な運用がビジネスの成長を左右します。 -
Amazon Connectの優位性
- 完全クラウドベースのため、従来型コールセンターより導入コストや運用負荷を大幅に削減。
- AIを活用した音声認識(Contact Lens for Amazon Connect)やチャットボット(Amazon Lex)の連携など、サービス拡張性が高い。
- AWSサービス(Lambda, S3, DynamoDBなど)との連携が容易で、サードパーティ製CTIとの統合もスムーズ。
1.2 AWS Systems Manager Change Calendar の役割と概要
-
Change Calendarの目的
- メンテナンスウィンドウやイベント発生時の変更管理を行い、誤ったタイミングでのリリースや設定変更を防止する。
- オペレーショナルチームが設定したカレンダーに基づいて、自動的にリソースの変更や処理実行を制御できる。
-
今回のユースケース
- コールフローを直接修正することなく、Change Calendarのカレンダー設定に従いコールセンターの「開局(On)」/「閉局(Off)」を切り替える。
- 休日やシーズンキャンペーン時に合わせて営業時間を動的に制御することが可能になる。
1.3 コールフローを修正せずに営業時間を動的に切り替える意義
-
メリット
- コールフローの再デプロイやバージョン管理が不要となり、運用負荷を大きく低減。
- 休日・イベント時の営業時間の変更をChange Calendarで一元管理できる。
-
ビジネスインパクト
- 急な営業時間変更にも迅速に対応可能。
- 運用チーム・システムチーム間の連携を最小限に抑えながら、企業全体の顧客対応品質を維持。
2. 詳細
ここではAWS Systems Manager Change Calendarと(Amazon Connect)をどのように連携させるか、具体的な手順や構成例を示します。
2.1 全体アーキテクチャのイメージ
-
Amazon Connectのコールフロー
- 電話がかかってきた際にLambda関数を呼び出して「現在の営業時間状態」を取得。
- 営業中ならエージェントにつなぐ、閉局中ならガイダンスを再生する。
-
Lambda関数
- AWS SDKを使用してAWS Systems Manager Change CalendarのAPIを呼び出し、現在のカレンダー状態を判定。
-
AWS Systems Manager Change Calendar
- 休日や営業時間外を反映したカレンダーを用意し、オンコールウィンドウ(Open)かクローズウィンドウ(Closed)かを管理。
2.2 構築・設定方法のステップバイステップ
ステップ1: Change Calendar の作成
-
AWSマネジメントコンソールから作成
- [Systems Manager] → [Change Calendar] → [Create calendar] に移動
- 休日や営業時間外となる時間帯をカレンダーとして定義
-
アクセス権限の設定
- Change Calendarを参照できるIAMロールまたはユーザーに紐付け(後述のIAM設定で詳細説明)
以下はCloudFormationテンプレート例(抜粋)です。AWS::SSM::Calendar
リソースは現状存在しないため、カレンダーを自動化する場合はAWS CLIまたはAPIを使用して登録・更新します。参考としてYAMLサンプルを示します。
# 休日を設定する例
aws ssm create-calendar \
--name "HolidayCalendar" \
--content "iCal形式の文字列" \
--description "休業日カレンダー"
--content
には iCal フォーマットで期間を指定します(たとえば "BEGIN:VCALENDAR ... END:VCALENDAR"
)。
ステップ2: IAMロールの作成・権限設定
- LambdaがChange CalendarのAPI(
ssm:GetCalendarState
など)にアクセスできるよう、以下のポリシーをアタッチ。 - サンプルのポリシードキュメント例(JSON):
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"ssm:GetCalendarState"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
実際はCalendarごとのResource ARNを指定することを推奨します。セキュリティの観点からリソースを絞り込むほうが望ましいです。
ステップ3: Lambda関数の実装
- Lambda関数にて、
GetCalendarState
APIでCalendarの状態を取得し、開局/閉局を判定します。サンプルコードは以下の通りです。
import json
import boto3
import os
ssm = boto3.client('ssm')
def lambda_handler(event, context):
calendar_names = os.environ['CALENDAR_NAMES'] # 環境変数で1つ以上のカレンダー名を指定
response = ssm.get_calendar_state(
CalendarNames=[calendar_names]
)
state = response['State'] # OPEN or CLOSED
# コールフローに渡す戻り値を生成
if state == "OPEN":
return {
"statusCode": 200,
"body": json.dumps({"open": True})
}
else:
return {
"statusCode": 200,
"body": json.dumps({"open": False})
}
-
ポイント
- 複数のカレンダーを組み合わせて状態判定を行うことも可能。たとえば営業カレンダーとメンテナンスカレンダーを両方参照して、どちらも
OPEN
なら最終的にOPEN
、いずれかがCLOSED
ならCLOSED
にするといったロジックを実装できます。
- 複数のカレンダーを組み合わせて状態判定を行うことも可能。たとえば営業カレンダーとメンテナンスカレンダーを両方参照して、どちらも
ステップ4: Amazon Connectのコールフロー連携
-
Lambda関数をAmazon Connectにインテグレーション
- Amazon Connectのマネジメントコンソールでコンタクトフローのブロック編集を行い、「Invoke AWS Lambda function」を配置。
- 上記で作成したLambda関数を呼び出し、応答を取得する。
-
応答内容に応じたフロー制御
- 戻り値が
open: true
ならエージェントに転送するルートへ。 -
open: false
なら営業時間外ガイダンスを再生した後、コールを切断またはボイスメールに転送。
- 戻り値が
2.3 システム連携・API活用の実例
-
EventBridgeやCI/CDパイプラインと連携
- 営業時間外など、変更を行わない期間にデプロイを止めるワークフローを組むことも可能。
-
ECサイトと連携
- サイト上の「電話受付中」表示を自動で切り替える。
- Lambdaの結果をAPI Gateway経由で返却し、フロントエンドアプリやCMSと連携することで、コールセンターの運営状況を可視化。
3. 注意点
3.1 運用上のメリットとデメリット
-
メリット
- コールフロー自体を頻繁に編集しなくてもよい。
- カレンダー情報を一元管理できるため、将来的なスケジュール管理が容易。
-
デメリット
- カレンダー定義ミス(休業日の日付や時刻のズレ)をした場合、正しく営業時間が反映されないリスク。
- システム利用者がカレンダーの操作方法を理解していないと、結果的に運用事故につながる可能性。
3.2 想定されるエラーや注意すべき制限事項
-
API制限
-
GetCalendarState
APIの呼び出し回数が多いとレートリミットに達する可能性があります。頻繁にステータスを取得する場合はキャッシュやメモリ内保持を検討してください。
-
-
タイムゾーン設定
- 祝日や休日の定義でタイムゾーンを誤ると、意図しないタイミングでコールセンターが閉局するリスクがあります。
-
Amazon ConnectのLambda呼び出しタイムアウト
- 初期設定のLambda呼び出し時間が長すぎたり、逆にタイムアウトが短すぎたりすると応答に失敗する場合があります。2~3秒でレスポンス可能な設計が望ましい。
3.3 マルチチャネル(電話・チャットなど)連携時の考慮事項
- 電話以外にもChatチャネルを運用している場合、それぞれのフローで同様にLambda呼び出しを行い、営業時間外の場合のチャットメッセージなども適切に返す設計が必要です。
- Amazon Lexとの連携など、音声合成・チャットボットとの連携でも同様のロジックを使って営業時間ステータスを判定できます。
3.4 実運用に入れる前の検証・モニタリング
-
検証
- テスト用にカレンダーを短い時間単位(例: 1時間単位)で設定し、正しく開局・閉局を切り替えられるか検証する。
-
モニタリング
- Amazon CloudWatchメトリクスやAmazon Connectの標準メトリクスで、呼量や接続失敗の有無をモニタリングし、営業時間判定の不整合を早期発見する。
4. まとめ
4.1 導入効果と今後の拡張性
-
導入効果
- コールフローの修正なしで営業時間を柔軟に変えられるため、運用コストが低減。
- のように曜日・祝日・セール期間などが頻繁に変わる業態において、柔軟性を最大限に活かせる。
-
今後の拡張性
- AI/MLを活用したコール予測や問い合わせ内容予測と組み合わせ、繁忙期の営業時間延長を自動化するなど、高度な運用が期待できる。
- 別AWSサービスとの連携(Amazon Pinpointでのキャンペーン連絡やSNS連携など)もシームレスに行える。
4.2 追加リファレンス
- AWS公式ドキュメント: Amazon Connect
- AWS公式ドキュメント: AWS Systems Manager Change Calendar
- AWSブログ: Amazon ConnectとLambda連携のベストプラクティス
4.3 本ソリューションがもたらすビジネスインパクトや利便性
-
ビジネスインパクト
- 運用担当者がカレンダーを編集するだけで即座に営業時間の変更が可能となり、顧客満足度向上やオペレーション効率化につながる。
-
利便性
- 担当者間の連携負荷を削減し、現場のオペレーターやマネージャーも容易にシステムを利用・管理できる。
本記事では、AWS Systems Manager Change CalendarとAWS Lambdaを活用してコールフローの修正を行わずに営業時間を変更する仕組みを解説しました。非エンジニアでも対応できる柔軟なアーキテクチャを導入することで、業務効率の向上と顧客満足度の最大化に寄与します。運用監視の徹底や権限管理の適切な設定を行った上で、検討しましょう。