はじめに 英国最大級の銀行である NatWest Group にとって、一貫したカスタマーエクスペリエンスの提供はビジネス上の優先事項であると同時に、規制上の要件でもあります。カスタマーエクスペリエンス業務を中断なく維持することは、事業継続と災害復旧の義務を果たすための基盤です。 NatWest は当初、AWS のヨーロッパ (ロンドン) リージョンに Amazon Connect Customer で カスタマーエクスペリエンスプラットフォームを構築しました 。Amazon Connect Customer は単一リージョンのアーキテクチャの場合も、少なくとも 3 つのアベイラビリティーゾーン (AZ) でアクティブ-アクティブ-アクティブ構成で稼働し、さらに各 AZ は 1 つ以上のデータセンターで支えられています。このマルチ AZ 設計により、大多数のケースにおける Amazon Connect Customer の利用で高いレジリエンスと可用性を達成しています。一方、さらに最高レベルのレジリエンスが必要な場合や、厳格なコンプライアンス要件および地理的冗長性を満たす必要がある場合に向けて、Amazon Connect Customer は Amazon Connect Customer Global Resiliency (ACGR) を提供しています。NatWest は厳格なコンプライアンスとレジリエンス要件を持つ金融機関として、 AWS と連携して Amazon Connect Customer Global Resiliency (ACGR) を導入し、Amazon Lex を活用した会話 AI 体験を含む、完全なアクティブ-アクティブのマルチリージョンカスタマーエクスペリエンスプラットフォームのアーキテクチャへの変革を実現しました。本記事では、その実現までの道のり、構築した自動化ユーティリティ、克服した課題、そして得られた教訓を紹介します。 「NatWest にとって、レジリエンスはオプションではなく、毎日何百万人ものお客様にサービスを提供するための基盤です。Amazon Connect Customer Global Resiliency と Amazon Lex Global Resiliency によるマルチリージョンコンタクトセンターへの移行は、リージョン障害時でもサービスを中断させないために不可欠でした。この変革により、お客様からの信頼を守り、自信を持ってスケールし、大手金融機関に求められるレジリエンス基準を満たせるようになりました。」 ビジネスコンテキストと推進要因 NatWest の Amazon Connect Customer インスタンスは月間 300 万件以上の音声通話を処理し、重要な銀行業務を支えています。お客様はこのシステムを不正行為の報告、影響を受けたカードのブロック、緊急資金へのアクセス、その他の時間的制約のあるリクエストの解決に利用しています。さらに、カスタマーエクスペリエンスプラットフォームは 26 の異なるサービスと連携しており、必要な時に有人エージェントが対応できるようエージェントのスケジューリングを支援するワークフォース管理、不正防止のための音声バイオメトリクス認証、定型的なリクエストをセルフサービスで処理する会話 AI などが含まれます。これらのミッションクリティカルな業務の性質と、金融サービスの可用性に対する規制上の厳しい監視を踏まえると、あらゆるシナリオでのサービス継続性の維持は譲れない要件です。 本取り組みの主な推進要因は以下のとおりです。 規制コンプライアンス: 英国の金融規制当局は、目標復旧時間 (RTO) の定義を含む、実証可能な事業継続・災害復旧 (BCDR) 能力を要求しています 単一リージョンへの依存軽減: ロンドンの単一リージョンに限定された運用では、万一リージョン障害が発生した場合、サービス継続性に関する厳格な規制要件を持つ組織にとって課題となります お客様の信頼保護: お客様は、特にストレスの高い状況において、銀行サービスへの中断のないアクセスを期待しています ミッションクリティカルな業務: NatWest のカスタマーエクスペリエンスプラットフォームは、機密性の高い銀行取引の主要チャネルであり、サービス継続性がお客様の成果に直結します ソリューションアーキテクチャ NatWest は AWS ヨーロッパ (ロンドン) リージョンの既存のコンタクトセンターを拡張し、AWS ヨーロッパ (フランクフルト) リージョンに完全に同期されたレプリカを作成しました。両リージョンはアクティブ-アクティブ構成で同時に稼働します。つまり、エージェントとお客様からの通話はどちらのリージョンでも処理可能です。一方のリージョンで障害が発生した場合も、もう一方を通じてトラフィックが流れ続け、お客様やエージェントが体感できる影響はありません。このアーキテクチャは 2 つの主要な AWS 機能を活用しています。 Amazon Connect Customer Global Resiliency (ACGR) ACGR により、組織は 2 番目の AWS リージョンに Amazon Connect Customer のレプリカインスタンスを作成できます。NatWest が活用した主な機能は以下のとおりです。 自動構成レプリケーション — Amazon Connect Customer リソースのネイティブな準リアルタイム双方向レプリケーション。リージョン間で一貫したエクスペリエンスを提供するために不可欠です。 Traffic Distribution Groups (TDG) — 設定可能な割合に基づいて、電話番号とエージェントのトラフィックを ACGR インスタンス間で分配します。 グローバルエージェントサインイン — エージェントはグローバルサインイン URL を使用して ACGR インスタンス間で認証を行い、代替リージョンに容易に移動できます。 レプリカのリザーブドキャパシティ — 制約なくトラフィックを移動できるよう、2 番目の AWS リージョンにキャパシティを予約します。 Amazon Connect Customer Global Resiliency は会話 AI レジリエンスにも対応しており、Lex V2 ボットをリージョン間で準リアルタイムにレプリケートします。これにより、対話型音声応答 (IVR) とセルフサービス体験の一貫性を、アクティブ-アクティブデプロイメント全体で保つことができます。 図 1: AWS ヨーロッパ (ロンドン) と AWS ヨーロッパ (フランクフルト) リージョン間で Amazon Connect Customer Global Resiliency を使用した NatWest のマルチリージョンアーキテクチャ。Traffic Distribution Groups が通話とエージェントを両リージョンにルーティングする様子を示しています。 カスタム自動化ユーティリティ ACGR は Amazon Connect Customer と Amazon Lex の構成レプリケーションをネイティブに処理しますが、NatWest は Traffic Distribution Groups を大規模に管理するための運用ツールの必要性を認識しました。6 つの TDG 管理ユーティリティと 1 つの Amazon Lex 有効化ユーティリティを開発し、ネイティブの Amazon Connect Customer API を使用してカスタム自動化機能を構築しました。すべてのユーティリティは複数の環境 (dev、test、preprod、prod) にわたる CI/CD パイプラインステージとして実装され、効率的なリージョン切り替えを可能にしています。 ユーティリティ 目的 エージェントの TDG への関連付け エージェントを Traffic Distribution Group (TDG) に追加 電話番号の関連付け 電話番号を TDG にリンク エージェントの TDG からの関連付け解除 エージェントを TDG から削除 TDG 更新 ロンドンとフランクフルト間のトラフィック分配率を変更 TDG 一覧表示 すべての TDG と現在のトラフィック分配状況を表示 Amazon Lex Global Resiliency (ALGR) ボット有効化 Lex V2 ボットの Amazon Lex Global Resiliency をリージョン間で有効化 各ユーティリティは環境パラメータとインスタンスパラメータを受け取り、手動の構成変更なしにすべてのデプロイメントステージで一貫した運用を可能にしています。 導入の道のり NatWest は 20 週間で実装を完了し、その後 3 か月間のフェーズ分けした番号ポーティング期間を設けました。 フェーズ 期間 主なアクティビティ フェーズ 1: 計画と現状把握 1〜4 週 運用準備の要件分析、チーム編成、サービスクォータのレビュー、AWS Well-Architected レビュー フェーズ 2: 開発環境のセットアップ 5〜8 週 Dev 環境での ACGR 設定、シングルサインオンの検証、Terraform パイプラインの更新 フェーズ 3: テストとプレプロダクション 9〜16 週 非レプリケートリソースの処理、TDG テストシナリオ、モニタリングの設定、ステージング環境での検証 フェーズ 4: 本番デプロイ 17〜20 週 サービスクォータの調整、本番環境での ACGR 有効化、段階的なトラフィック移行 フェーズ 5: 番号ポーティング 本番後 3 か月間にわたる電話番号の TDG への段階的なポーティング 「非本番環境で開始したことで、統合の問題、特に非レプリケートリソースに関する問題を、お客様への影響が出る前に早期に発見できました。」 「Amazon Connect Customer Global Resiliency はコアのコンタクトルーティング機能をリージョン間で自動レプリケートする強力な基盤を提供してくれますが、マルチリージョン戦略の真の成功は責任共有モデルの理解と実践にあります。NatWest にとってそれは、Amazon Connect Customer の境界を超えるすべてのものに対してオーナーシップを持つことを意味しました。AWS が管理する部分と自社が管理する部分を明確に分離することで、運用上および規制上の期待に応える、レジリエントで再現性のある、厳密に管理されたグローバルアーキテクチャを構築できました。」 技術的な課題とその解決方法 非レプリケートリソース Amazon Connect Customer Global Resiliency (ACGR) は責任共有モデルで運用されます。AWS は、リージョン間で音声トラフィックをルーティングするために必要な特定の Amazon Connect Customer 構成リソースを自動的にレプリケートしますが、DynamoDB や AWS Lambda など Amazon Connect Customer のリソース境界外にあるリソースについては、お客様が外部でレプリケーションパイプラインを維持する必要があります。 NatWest のマルチリージョンデプロイメントでは、この責任共有モデルによりいくつかの主要コンポーネントの準備が必要でした。 サーバーレスインフラストラクチャ: AWS Lambda 関数は、環境間で一貫した Infrastructure-as-Code (IaC) デプロイメントを維持するため、拡張された Terraform CI/CD パイプラインを使用してレプリカリージョンに独立してデプロイが必要でした。 静的コンテンツ: オーディオプロンプトや静的アセットを含む Amazon S3 のコンテンツは、S3 クロスリージョンレプリケーションを使用してリージョン間で効率的にレプリケートしました。これにより、元のバケットとレプリケーション先のバケット間でオブジェクトが自動的に同期されます。 リアルタイムストリーミング: Nuance Gatekeeper の音声バイオメトリクス機能の統合などをサポートするため、各リージョンに個別の Amazon Kinesis Video Streams の構成が作成されました。これらは ACGR の自動レプリケーション範囲外のためです。 言語と語彙リソース: Amazon Lex カスタム語彙と Amazon Connect Customer カスタム語彙の両方とも、リージョン間で同期するための外部のレプリケーションパイプラインが必要でした。これらのリソースは標準的な ACGR および ALGR のレプリケーション範囲を超えており、お客様側でオーケストレーションの管理が必要です。 カスタム Contact Control Panel (CCP) の修正 NatWest は Amazon Connect Customer Streams API を使用して構築されたカスタム CCP を運用しています。チームは認証ロジックをリージョンに依存しない形に適応させ、エージェントがアクティブなリージョンに容易に接続できるようにしました。 メトリクスとモニタリング NatWest が ACGR をデプロイした当時、Amazon Connect Customer はネイティブな統合クロスリージョンメトリクスビューを提供していませんでした。このギャップに対処するため、NatWest はカスタムの Amazon CloudWatch ダッシュボード と Amazon QuickSight レポートを構築し、両リージョンの運用メトリクスを単一の運用ビューに統合しました。 現在、ACGR は統合されたエージェントメトリクスとコンタクトメトリクスをネイティブに提供しており、効率的なコンタクトセンター運用のための統合コンタクト検索ページも含まれています。 セキュリティに関する考慮事項 セキュリティは AWS とお客様の間の責任共有で実現されます。NatWest は ACGR 実装全体を通じて以下のセキュリティベストプラクティスを適用しました。 NatWest は EU のデータレジデンシーコンプライアンスを維持するためにフランクフルトをレプリカリージョンとして選択しました。これは組織の規制上の義務における重要な要件です。NatWest は転送中および保存時のすべてのデータを AWS マネージドキーで暗号化し、暗号化キー管理のさらなる制御がポリシー上必要な場合にはカスタマーマネージド KMS キーを適用しています。 すべての自動化ユーティリティと Lambda 関数は最小権限の IAM ロールで動作し、各オペレーションに必要な最小限の権限にスコープされています。ロールを設定する際は、IAM ベストプラクティスガイドを参照して、実装が AWS のセキュリティ推奨事項に従っていることを確認してください。チームはリージョン間のトラフィック切り替え時の認証失敗を防ぐため、本番デプロイ前に非本番環境で ID プロバイダーの設定を検証しました。 NatWest は両リージョンで AWS CloudTrail を有効化し、構成変更とリージョン切り替えイベントの完全な監査証跡を維持しています。これにより、コンプライアンスとトラブルシューティングの目的ですべてのアクティビティを追跡できます。 「セキュリティと規制コンプライアンスは、AWS でのクロスリージョン実装の基盤でした。EU データレジデンシー要件を満たすためにフランクフルトを選択し、転送中および保存時のデータの暗号化の徹底、包括的な CloudTrail 監査により最小権限の IAM を適用することによって、レジリエンスや俊敏性を損なうことなく厳格な規制要件を満たすことができました。厳密な本番前検証により、最高のセキュリティ基準を維持しながらスムーズなリージョン間トラフィック切り替えを実現しました。」 2 番目の AWS リージョンの依存サービス設定の一環として、NatWest は定期的に代替リージョンへのトラフィック切り替えを実施し、設定が正確でビジネスが 2 番目のリージョンで一貫して運用されることを確認しました。この取り組みは設定が常に同期されていることを検証し、リージョン切り替えが発生した場合にビジネスが一貫したエージェントおよびお客様体験を提供できると確証を得るために不可欠でした。NatWest はこのフェイルオーバーテストを四半期ごとに実施し、ランブックを最新の状態に保ち、リージョン切り替えへの自信を維持しています。 成果 この実装により、レジリエンス、コンプライアンス、運用全体にわたって測定可能な改善が実現しました。 ほぼ瞬時の RTO — Traffic Distribution Groups により、Recovery Time Objective を 30 分超からほぼ瞬時に短縮しました。手動介入なしに通話が自動的に再ルーティングされます。 負荷下でのフルキャパシティ — シミュレーションされたリージョン障害テスト中に 3,500 件以上の通話のフルキャパシティを維持しました。 規制コンプライアンス — コンプライアンス義務を満たす、文書化されテスト済みのマルチリージョンアーキテクチャを実装し、BCDR 要件を達成しました。 エージェント体験の簡素化 — 単一のグローバルサインイン URL により、3,500 人以上のエージェントが必要に応じてリージョンや ACGR インスタンス間をスムーズに移動できるようになりました。 運用オーバーヘッドの削減 — 自動構成同期が手動のマルチリージョンデプロイメントに取って代わり、エンジニアリングチームを反復的な管理タスクから解放しました。 エンドツーエンドのサービス継続性 — 両リージョンで 26 の統合サービス全体の継続性を維持し、リージョン切り替え時も依存するアプリケーションが正常に動作し続けました。 得られた教訓 NatWest の事例に基づき、同様の実装を計画するチームに以下をお勧めします。 1. 非本番環境で開始 — レプリケートされていないリソースにおける統合の問題を本番環境に到達する前に発見する 2. SAML/SSO の早期検証 — ACGR レプリカ作成とグローバルサインインの開始前に、ID プロバイダーの設定を完了しテストする 3. すべての統合を監査 — Amazon Connect Customer と統合するすべてのサービスを文書化し、開始前にレプリケートされる対象とされない対象を分類する 4. 本番稼働前にモニタリングを構築 — 本番トラフィックの移行前にクロスリージョンの運用ダッシュボードを整備する 5. 定期的な障害注入テストを実施 — 定期的なフェイルオーバー訓練を予定し、トラフィックの再ルーティング、エージェントのサインイン、 すべての統合サービス (NatWest の例では 26 のサービス) がシミュレーションされたリージョン障害時に正しく機能することを検証する。NatWest は四半期ごとに障害注入演習を実施し、現実的な条件下で RTO 目標を検証しています。 6. 段階的なトラフィック移行を実施 — ハードカットオーバーではなく、TDG 更新ユーティリティを使用してレプリケート先リージョン (フランクフルト) のトラフィック割合を徐々に増加させ、ロールアウトを制御 7. 各フェーズゲートで AWS Well-Architected レビュー を適用し、信頼性の柱およびレジリエンスレンズに照らしてアーキテクチャ決定を検証 まとめ NatWest による Amazon Connect Customer Global Resiliency と Amazon Lex Global Resiliency の実装は、大規模な金融機関がオペレーションの簡素さを犠牲にすることなく、金融規制基準を満たすコンタクトセンターレジリエンスを実現できることを示しました。AWS ネイティブのレプリケーション機能と、目的に応じた自動化ユーティリティ、そして規律あるフェーズアプローチを組み合わせることで、NatWest は単一リージョンアーキテクチャを完全にレジリエントなマルチリージョンコンタクトセンターへと変革し、規制要件を満たしつつカスタマーエクスペリエンスを保護しました。 この取り組みには 20 週間の集中的なエンジニアリング作業が必要でしたが、その結果、完全なリージョン障害にも、お客様が体感できる影響なしに、手動介入せずとも耐えられるアーキテクチャを確立しました。 次のステップ Amazon Connect Customer コンタクトセンターにマルチリージョンレジリエンスを組み込む準備はできましたか？まずは Amazon Connect Customer Global Resiliency のドキュメント と Amazon Lex Global Resiliency ガイドをご確認ください。また、 AWS Well-Architected 信頼性の柱 を活用して現在のアーキテクチャを評価し、実装開始前にレジリエンスのギャップを特定することもできます。 筆者について Prateek Guleria は NatWest の DevOps リードです。自動化の実行、CI/CD パイプラインの開発・実装の監督、AWS プラットフォーム上のクラウドインフラの維持を担当しています。 Srinath Chandrasekharan は NatWest のリリーストレインマネージャーです。プログラム実行の戦略的オーケストレーターとして、すべてのテクノロジーデリバラブルがビジネスおよびテクノロジー OKR に直接整合する形で、正確に計画・同期・実行されることを確保しています。 Baraa Elkosh はイギリス・ロンドン拠点の AWS シニアテクニカルアカウントマネージャーです。エンタープライズ顧客と連携してクラウド導入を加速させ、コンタクトセンターのモダナイゼーションと AI 統合を専門としながら、大規模な運用安定性を確保しています。 Abhay Kumar は NatWest のエンジニアリングディレクターです。コンタクトセンタープラットフォームのアーキテクチャ、開発、保守、品質、セキュリティを担当しています。 Kapil Arora は NatWest のプリンシパルエンジニアで、ソフトウェア業界で 21 年以上の経験を持ち、多彩な技術的バックグラウンドが特徴です。ソフトウェアエンジニアリング、ソリューション設計、データエンジニアリング、クラウドエンジニアリング、DevOps、コンテナ化、AI エージェントおよびエージェンティックアプリケーションフレームワークにわたる経験があります。 Manoj Srinivas はアメリカ・ワシントン州シアトル拠点の Amazon Web Services のプロダクトマネージャーです。Amazon Connect Customer Global Resiliency の開発を推進しており、これは企業が事業継続性とコンプライアンスのために AWS リージョン間でシームレスに Amazon Connect Customer を運用できる機能です。仕事以外では、旅行とサッカーを楽しんでいます。 Abilashkumar P C  はロンドン拠点の Amazon Web Services の Applied AI シニアスペシャリストソリューションアーキテクトです。サーバーレステクノロジーを活用したコンタクトセンター全体で、レジリエントな AI 搭載ソリューションの設計・構築を顧客と共に行っています。 Prabhakar Rajasekar はドイツ・アーヘン拠点の Amazon Web Services WWSO の Applied AI ソリューションアーキテクトです。顧客のデジタルトランスフォーメーションを支援する傍ら、庭や森で子どもたちと過ごす時間を大切にしています。 本記事は 2026 年 7 月 9 日 に公開された「 How NatWest built multi-region resilience with Amazon Connect Customer 」を翻訳したものです。 この記事はテクニカルアカウントマネージャーの高橋が翻訳しました。

はじめに「AIを導入すれば生産性が上がるらしいが、私たちのチームはどこから手をつければいいのだろう？」と悩んだことはありませんか？既存のレガシープロジェクトをAI主導型プロジェクト（AI-driven...

この記事で学べること CI/CDと自動テストの違いを1文で説明できるようになる GitHub Actions、AWS CodePipelineはCI/CDそのものではなく「実現手段」だとわかる Continuous DeliveryとContinuous Deploymentの違いを正確に区別できる AIでコード生成が速くなるほど、なぜCI/CDの基本が重要になるのか理解できる はじめに 最近、AI駆動開発でコード生成の速度が上がるにつれ、「CI/CD」「自動テスト」「GitHub Actions」といった言葉が混同して使われる場面をよく見かけます。AIによって実装スピードは上がりましたが、そのぶん変更量や見落としも増えやすくなりました。コードを速く書けるようになったからこそ、品質を担保するプロセスの理解はより正確であるべきだと思い、この記事を書きました。