re:Invent 2025: Bank CenterCreditの規制対応ハイブリッドAI基盤とASR・RAG実装事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - BCC: Hybrid architecture for generative AI to meet regulatory needs (HMC324)
この動画では、Bank CenterCreditのMaxim GengとAWSのAleksandr Bernadskiiが、規制要件を満たすための生成AIハイブリッドアーキテクチャについて解説しています。カザフスタンの銀行である同行は、データ暗号化キーのオンプレミス保管という規制要件に対応するため、AWS Outpostsを導入し、External Key Store機能を活用した二重暗号化を実装しました。具体的な事例として、カザフ語・ロシア語・混合言語に対応したASRモデルのファインチューニングでは、8キロヘルツの実データを使用し、Named Entity Recognitionで個人情報を除去後、mel spectrogramに変換してAmazon SageMakerで学習を実施。混合言語で23%の精度向上と月400万テンゲのコスト削減を達成しました。また、AWS Bedrockを活用したハイブリッドRAG方式のHR-botでは、HRリクエストの70%を処理し、従業員満足度も高い結果を得ています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Bank CenterCredit のハイブリッドクラウド戦略と AWS Outposts による規制準拠アーキテクチャの構築
こんにちは。私の名前は Maxim Geng で、Bank CenterCredit の DevOps Technologies and Cloud Solutions の R&D 部門の責任者をしています。今回のプレゼンテーションのテーマは、規制要件を満たすための生成 AI のハイブリッドアーキテクチャです。
では始める前に、Bank CenterCredit についてお話しさせていただきたいと思います。当行はカザフスタンの銀行システムにおけるリーダー企業の一つです。20 の支店と 150 以上の営業所を持っており、300 万人以上のお客様にサービスを提供しており、個人のお客様にも法人のお客様にも幅広いサービスを提供しています。また、2024 年の Q1 に 2 つの Outpost ラックを導入しました。
では、なぜクラウドを使用することにしたのか、そして私たちの目標は何だったのかについてお話しします。当行の IT インフラはすべて自社のデータセンターにオンプレミスでホストされていましたが、ビジネスニーズの増加とオンプレミスソリューションの制限により、クラウドを使用してリソースをスケールすることにしました。異なるプロバイダーにはそれぞれの利点があるため、マルチクラウド戦略を選択しました。クラウドを使用することで、どのような目標を見ていたのでしょうか。まず、柔軟性とスケーラビリティです。次に、イノベーションと競争力です。3 番目に、信頼性とフォールトトレランスです。そして 4 番目に、経済効率です。
しかし同時に、銀行として、規制要件への準拠を確保する必要があります。 最初の要件は、データ転送とストレージを暗号化する必要があり、暗号化キーは銀行に保管する必要があるということです。2 番目の要件は、収集と処理の際に顧客データの匿名化を確保することです。これらの要件に基づいて、私たちは AWS Outposts を使用してクラウドへの取り組みを開始しました。AWS Outposts はオンプレミスに顧客データを保存するローカルプライベート AWS クラウドです。私たちはカザフスタンでこのソリューションを導入した最初の企業の一つで、自社のデータセンターにラックを配置することで、すべての必要な要件を満たしました。
このソリューションで、マネージド仮想マシン、Kubernetes クラスター、S3 ストレージなどの基本的なマネージド AWS サービスの探索と導入を開始しました。当行のアプリケーションアーキテクチャのコアレイヤーは Kubernetes ベースのマイクロサービスで構成されています。しかし、これらのワークロードは 20 以上のクラスター全体で実行されており、クラウドを使用してこれらのワークロードをどのように移行できるかを探索したいと考えていました。AWS Outposts 上でマネージド Kubernetes の探索と導入を開始し、その後、当行の内部銀行サービスと統合しました。その後、AWS および他のクラウドでこの同じデプロイメントアプローチを承認しました。
その結果、以下のような図が得られました。このスライドは、当行のデータセンターの Outposts、AWS クラウド、Azure クラウドに配置されている Kubernetes クラスターのマルチクラウドマイクロサービスアーキテクチャを示しています。これらすべてが、デプロイメント管理、ロギング、ロードバランシングのための集中管理ツールと組み合わされています。クラウド使用の要件に戻って、暗号化実装についてさらに詳しく説明しましょう。
暗号化については、AWS KMS 暗号化サービスを使用しました。External Key Store、つまり XKS という機能があり、この機能により、クラウド内で暗号化するためにローカルキーを使用することができました。つまり、AWS KMS のクラウドサーバーが私たちのローカルキーを使用できるようになったわけです。このソリューションにより、クラウド内のサービスでのデータ暗号化にローカルキーを使用することができました。また、XKS プロキシも使用しており、これはローカルキーをクラウド暗号化サービスに転送するために使用されます。私たちの場合、XKS プロキシは AWS Outposts に配置されています。
このケースは二重暗号化の原則に基づいています。クラウドでは、暗号化サービスである AWS KMS がデータキーを使用して AWS サービス内のデータを暗号化します。さらに、オンプレミスに配置されているルートキーが使用され、このキーは外部キーであり、より安全です。
銀行は AI と ML マネージド AWS サービス、および私たちのプロジェクト向けの GPU ワークロードに関心を持っていました。この暗号化実装に基づいて継続的インテグレーションを開始し、AI モデルトレーニング用のアーキテクチャを構築しました。 このスライドは、ACR モデル用のモデルトレーニングのアーキテクチャを示しています。これを実現するために、ステップ 1 で見ることができる S3 Outposts と S3 クラウド間の同期を行いました。その後、ステップ 2 に示されているように、データはクラウド上の EC2 GPU または SageMaker でトレーニングできます。処理されたデータは、ステップ 3 で S3 クラウドから S3 Outposts に転送し直すことができます。
最後に、ステップ 4 では、内部サービスと EKS 内のサービスが処理されたデータと直接やり取りできます。すべてのステージを通じて、データ処理、転送、ストレージの暗号化にローカルキーを使用しています。その後、AWS Bedrock という別の機械学習サービスとの統合を続けました。この場合、ローカルサービスと EKS Outposts 内のサービスが Bedrock API エージェントと直接やり取りできます。 プライベートエンドポイントはリアルタイムで使用される安全な接続を提供します。このソリューションにより、Bedrock で利用可能なすべての AI モデルを使用でき、ワークロードを任意のサイズにスケーリングできました。
混合言語対応 ASR モデルのファインチューニング：コールセンター録音データを活用した精度向上の実現
データ転送、準備、ストレージのすべてのステージを通じて、ローカルキーを暗号化に使用しています。このアーキテクチャ、統合、暗号化メカニズムの実装の結果として、AWS クラウドサービスを使用したプロジェクト向けの技術基盤を構築しました。以上です。ありがとうございました。Aleksandr がデータ匿名化と銀行での実装事例についてさらに詳しく説明します。 こんにちは。Aleksandr Bernadskii と申します。AWS のソリューションアーキテクトです。 次の 10 分間で、Bank CenterCredit、つまり BCC が Maxim が先ほど示したハイブリッドアーキテクチャの上に構築した 2 つの生成 AI ユースケースについてお話しします。始める前に、このプロジェクトでは私は単なるアドバイザーであり、ほとんどの素晴らしい仕事は銀行のデータサイエンスチームによって行われたことを認めなければなりません。残念ながら、チームのメンバーが本日は十分な人数で参加できませんでしたが、このチームの Daria がいます。Daria、あなたと素晴らしい同僚たちに敬意を表します。参加していただきありがとうございます。
本日は2つのケースについてお話しします。1つ目は ASR モデルのファインチューニングです。ASR は自動音声認識を意味しており、2つ目はBCC従業員をサポートするための社内HR チャットボットの実装です。まずはファインチューニングから始めましょう。 まず、銀行がカスタムモデルを作成することにした理由を説明します。その後、スキーマを示し、ファインチューニングが実際にどのように実行されたかについて説明します。その後、結果といくつかの定量的なメトリクスをお見せします。銀行がカスタムモデルを作成することにした理由は、一般的に2つあります。
カザフスタンの人口の大多数はカザフ語を話します。また、人口のかなりの部分がロシア語を話していますが、第3の選択肢もあります。いわゆる混合言語で、人がカザフ語とロシア語を同時に話す場合です。例えば、カザフ語で2語、ロシア語で1語というように。市場にはロシア語をかなりうまく処理できる ASR モデルがあることを想像できるでしょう。その中にはカザフ語でも動作できるものもあります。しかし、この混合言語に対応できるモデルは市場には存在しません。銀行がこのモデルを作成した最初の理由は、この混合言語に特化したモデルを作成することでした。
BCC はコールセンターの録音から得た実データを8キロヘルツの周波数で保存しています。これはストレージを節約したい場合には非常に良い周波数です。しかし、市場にある ASR モデルのほとんどは、商用であろうとオープンソースであろうと、16キロヘルツのトレーニングデータセットで学習されています。16キロヘルツで学習されたモデルが8キロヘルツのデータセットではうまく機能しないことを想像できるでしょう。
さらに、カザフ語は低リソース言語です。つまり、ASR モデル用のカザフ語言語トレーニングデータセットをウェブで検索すると、2つのデータセットしか見つかりません。どちらも16キロヘルツです。語彙と機能の点ではそれほど豊富ではありません。そこで Bank CenterCredit は、実際のコールセンターの録音データに基づいて、8キロヘルツと充実した語彙を備えた独自のカスタムデータセットを作成することを決定しました。これがこのアプローチを採用した2番目の理由です。
プロセスについてご説明させていただきます。最初、すべてのコールセンター録音は BCC データセンターのオンプレミスの Hadoop クラスタに保存されていました。各コールセンター録音ファイルは 2 つのチャネルに分割されていました。1 つはエージェント用、もう 1 つはカスタマー用です。その後、各チャネルは音声活動検出によって処理され、録音からすべてのノイズと無音が削除されました。音声のみを含むフラグメントはチャンクに分割され、各チャンクは実際のフレーズの長さに応じて 2 秒から 20 秒の可変期間を持っていました。
その後、各チャンクは speech-to-text モデル、つまり当時銀行が持っていた前のバージョンによって処理されました。これにより、オーディオファイルのテキスト表現が提供されました。これで、オーディオ録音とテキストの両方が揃いました。両方のデータ形式は Hadoop クラスタから Outposts に転送されました。重要な質問は、銀行がなぜ Outposts 上でパイプライン全体を実行しなかったのかということです。その理由は、BCC Outposts の構成に GPU がないからです。Outposts に GPU を提供することはできますが、BCC の Outposts の場合はそうではありませんでした。Speech-to-text モデルは GPU を必要とし、銀行は中程度のサイズのモデルと推論には十分な量の GPU を持っていますが、ファインチューニングには十分ではありません。
そのため、銀行は GPU パワーを使用して前世代の speech-to-text モデルを実行してテキストを生成し、その後、オーディオとテキストの両方を Outposts に転送しました。テキストファイルは、その後 Named Entity Recognition モデルで処理され、すべての個人情報、機密データ、および機密情報を特定しました。これは、このデータが銀行のセキュリティ境界の外に出ないようにするための内部セキュリティからの厳しい要件でした。そのようなデータが特定されたすべてのチャンクとファイルは、テキストファイルとオーディオファイルの両方を含めて、トレーニングデータセットから削除されました。
これで、銀行は XKS 内部キーを使用して暗号化され、すべての個人情報と機密データから削除されたオーディオファイルとテキストファイルを持っていました。これらは mel spectrogram と呼ばれる特別な形式に変換されました。この用語を聞いたことがない場合は、心配しないでください。次のスライドで説明します。Mel spectrograms は Outposts 上の S3 からリージョン内の S3 に転送され、外部キーで暗号化され、機密データがなく、すべての規制に完全に準拠していました。Mel spectrograms はオーディオでもテキストでもなく、非常に特定のものです。これについては説明します。
これらの mel spectrograms は Amazon SageMaker でのファインチューニングジョブのトレーニングデータセットとして機能しました。このファインチューニングジョブは、一定数のモデルアーティファクトを生成し、それらはオンプレミスに返され、その後ローカル GPU パワーを使用して推論用にホストされました。つまり、銀行はクラウド GPU をファインチューニングに使用し、その後モデルをオンプレミスに戻して、オンプレミスで推論用にホストしました。これがプロセスです。
メルスペクトログラムは、文字通りオーディオの画像です。データサイエンティストは、フーリエ変換を適用してから、その上にメルスケールを適用することで、オーディオファイルからこのフォーマットを生成できます。これにより、データサイエンティストはオーディオの双方向表現を得られます。X軸は時間を、Y軸は周波数を、色は振幅を表しています。これはデータサイエンティストがASRモデル用のデータセットを準備する方法のベストプラクティスであり、Bank CenterCreditはこれらのベストプラクティスに従いました。
ご覧の通り、3つの言語すべてで結果はかなり良好です。
Bank CenterCreditは3つの言語すべてで大幅な精度向上を達成しました。ロシア語では9%の改善、カザフ語では15%の改善が見られました。最も重要なのは、カスタムモデル開発の主な目標だった混合言語で最も大きな改善が得られたことで、混合言語で23%の精度向上に達しました。さらに、このモデルは銀行が以前使用していた商用ASRソリューションよりもコスト効率が高く、銀行は毎月400万テンゲの節約を実現できました。テンゲはカザフスタンの現地通貨です。現在、このモデルはコール後分析パイプラインの一部として機能しており、銀行はこのプロジェクトを成功と考えており、来年さらにスケールアップする計画を立てています。
ハイブリッド RAG を活用した HR チャットボットの導入と生成 AI プロジェクトの成果
次のケーススタディであるHR-botに移ります。Bank CenterCreditは複数の理由からHR-botの導入を決定しました。第1の理由はHR対応の品質と速度を向上させることでした。第2の理由は、社内でセルフサービス文化を促進することでした。第3の理由は、HR従業員をルーチン業務からより戦略的なイニシアティブに集中させることでした。もちろん、このチャットボットは内部および外部の規制に準拠する必要があり、つまり銀行の機密データがオンプレミスのセキュリティ境界の外に出てはいけないということでした。そのため、銀行はハイブリッドRAGと呼ばれるテクニックを使用しました。RAGはRetrieval-Augmented Generationの略です。RAGを使用することで、モデルに追加のコンテキストを提供し、モデルが標準では持っていない知識を提供します。この知識は銀行の内部HR方針で構成されています。
ご覧の通り、このスキーマでは、HR ナレッジベースは最初にローカル GPU パワーを使用して埋め込みモデルで処理され、その結果得られたベクトルは Outposts 上の PostgreSQL データベースに保存されました。PostgreSQL はベクターデータベースとして機能することができるためです。同じプロセスがユーザープロンプトにも適用されました。チャットボットはユーザーインターフェースを持っており、ユーザーがプロンプトを入力すると、それは埋め込みモデルに送られ、ベクトルに変換されます。そのベクトルは PostgreSQL に送られ、ベクター検索によってナレッジベースからの追加コンテキストを表す PostgreSQL ベクターデータベースから追加コンテキストが取得されます。この追加コンテキストは初期ユーザープロンプトに追加され、その後、プロンプトと追加コンテンツが Outposts からクラウドリージョンの AWS Bedrock に送信されます。Bedrock では、Claude Sonnet モデルがプロンプトと追加コンテキストを処理し、オンプレミスのチャットボットに返送される応答を提供します。
チャットボットの結果に関しては、銀行の評価によると、現在、HR リクエストの約 70% が HR-bot を通じて処理されており、これはかなり良い結果であり、確実に銀行が HR チームのワークロードを削減することができます。さらに重要なことに、銀行はチャットボットに対する従業員の満足度についてのフィードバックを収集し、そのフィードバックはほぼ肯定的でした。
それでは、このセッションの重要なポイントをお伝えしたいと思います。まず、プラットフォームに関しては、法的要件に準拠し、銀行のビジネスニーズに合わせてカスタマイズされた、セキュアなハイブリッドマルチクラウドプラットフォームを構築しました。次に、革新的なアプローチと高い競争力を実現する、柔軟でスケーラブル、かつコスト効率的なアーキテクチャを実装しました。GenAI プロセスに関しては、銀行は生成 AI モデル、特に ASR モデルのファインチューニングプロセスを実装しました。このプロセスは AWS Outposts を主要コンポーネントとするハイブリッドアーキテクチャに依存しており、内部および外部の規制に完全に準拠しています。銀行は、他のすべての GenAI タスクに対して同じアプローチを再利用する計画を立てており、ファインチューニングにはクラウド GPU リソースを活用し、その後、実際のモデルをオンプレミスで使用する予定です。
HR-bot に関しては、銀行は GenAI がルーチンタスクを自動化できることを実証する成功事例を作成しました。これは同様のプロジェクトの足がかりとなり、銀行は IT サポートや調達などの異なる機能領域に同じアプローチを実装する計画を立てています。本日のプレゼンテーションは以上です。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion