目次
アーキテクチャ全体像 🚀
顧客端末 ─▶ Route 53 ─▶ Amazon Connect インスタンス
│ │
│ ├─ キュー設定（営業時間判定）
│ └─ コンタクトフロー（Check Hoursブロック）
▼ │
FAQ/IVR ←───────────────┘
こんな感じで、営業時間に応じてオペレーター対応かFAQガイダンスに振り分けるイメージです。
1. 概要 👍
“オペレーション時間”機能って、要は定義した営業日・営業時間だけコールを受け付けて、それ以外は自動ガイダンスに切り替える仕組みです。
- 営業時間内 → オペレーター
- 営業時間外 → 自動IVR or 留守番ガイダンス
ユースケースとしては…
- EC注文前後の問い合わせ
- 定期購入プランの変更や解約
- キャンペーン案内
みたいな場面で「営業時間忘れて夜中にかかってきても大変だよね？」って問題をスマートに解決できると思います。
2. 詳細設計 🛠️
2.1 活用パターン
-
パターンA：キュー設定
キューに直接営業時間カレンダーを紐付けて、一律制御。 -
パターンB：フロー内ブロック
コンタクトフローの任意箇所に時間判定ブロックを入れて、細かく分岐処理が可能。
2.2 設定箇所①：キュー設定
- コンソール → 連絡先キュー → 対象キュー
- 「営業時間」タブでカレンダーを選ぶだけ。ラクチンですよね？
- 保存しておしまい！
CloudFormation例
Resources:
SupportQueue:
Type: AWS::Connect::Queue
Properties:
InstanceId: !Ref ConnectInstance
Name: "CustomerSupportQueue"
HoursOfOperationId: !Ref BusinessHoursJP
2.3 設定箇所②：コンタクトフロー内ブロック
- コンソール → Contact flows → フロー編集
- 「Check hours of operation」ブロックをポイッと配置
- カレンダー選んで、Within／Outsideの分岐先を設定するだけ！
<CheckHoursOfOperation
HoursOfOperationARN="arn:aws:connect:…:hours-of-operation/BusinessHoursJP"
IfWithinHoursBranch="InsideFlow"
IfOutsideHoursBranch="OutsideFlow"/>
フロー設計は少し慣れが必要だけど、時間外の対応をめっちゃ柔軟に作れるのが魅力です。
2.4 祝日カレンダー自動更新 Lambdaサンプル 🎉
import boto3, requests, datetime, json
CONNECT_ID = "abcdefgh-1234-5678-..."
HOURS_ID = "hours-01"
API_URL = "https://holidays-jp.github.io/api/v1/date.json"
def lambda_handler(event, _):
holidays = requests.get(API_URL).json()
config = []
for d in holidays:
date = datetime.datetime.fromisoformat(d)
config.append({
"Day": date.strftime("%A").upper(),
"StartTime": {"Hour":0, "Minute":0},
"EndTime": {"Hour":0, "Minute":0}
})
boto3.client("connect").update_hours_of_operation(
InstanceId=CONNECT_ID,
HoursOfOperationId=HOURS_ID,
Config=config
)
EventBridgeで月次トリガーすれば、祝日カレンダーはほぼメンテナンスフリーかなと思います。
3. 比較分析：キュー vs. フロー内ブロック 🔍
| 観点 | キュー設定 | フロー内ブロック |
|---|---|---|
| 難易度 | ★★☆☆☆（ポチポチ設定するだけ） | ★★★★☆（フロー設計が必要） |
| 運用性 | ★★★★☆（即時反映で楽） | ★★★☆☆（流れをデプロイする必要アリ） |
| 拡張性 | ★★☆☆☆（起動／停止のみ） | ★★★★★（複雑な分岐OK） |
| 保守性 | ★★★☆☆（シンプルで見通し良し） | ★★☆☆☆（ブロック増えると管理大変） |
| テスト容易性 | ★★★★☆（時間判定だけテスト可） | ★★★☆☆（フロー全体の結合テスト必須） |
それぞれメリット・デメリットがありますが、「なるべくラクしたい！」ならキュー設定、「柔軟性重視！」ならフロー内ブロックかなと思います。
4. テスト・検証計画 ✅
-
単体テスト
- 平日・祝日・時間外で分岐動作チェック
-
結合テスト
- IVR → キュー → オペレーターまでシナリオ実行
-
シナリオテスト
- 祝日API更新後の動作確認
-
負荷テスト
- ピーク時間の同時着信数チェック
「テスト大事！ミスるとお客さんに怒られますよね？」ってことで、しっかりやりましょう。
5. 注意点＆運用設計 ⚙️
-
二重判定に注意：キューとフロー両方設定すると意図しない分岐に…
-
多言語対応：最初に言語判定してからカレンダー判定すると分かりやすいです
-
モニタリング：
- CloudWatch メトリクス
QueueAbandonedCountやContactFlowErrorCountを監視 - 営業開始後10分で通話数が極端に少ないときはアラートを飛ばすと安心
- CloudWatch メトリクス
6. まとめ＆拡張ポイント 🌱
-
キュー設定
- 簡単・即時反映だが拡張性は控えめ
-
フロー内ブロック
- 柔軟性バツグンも保守とテストがちょっと大変
今後の拡張アイデア
- AIチャットボット：Lex＋Pollyで時間外にも会話対応！
- セルフサービスポータル：API連携で折り返しリクエストやFAQ表示
- BI連携：QuickSightで時間帯別通話トラフィックを可視化
ぜひ自社要件に合わせてカスタマイズしてみてください！