ドコモSMTBネット銀行が電話・チャット両チャネルで実践する Amazon Connect Customer AI agents による応対高度化

本ブログは株式会社ドコモSMTBネット銀行 カスタマーサービス部 CS・DX企画グループ 中﨑 敬太様のご協力のもと執筆しました。

コンタクトセンターへの生成 AI 導入は、すでに「試してみる」段階を越えつつあります。導入から数年が経ったコンタクトセンターでよく伺うのは、FAQ の回答精度が思ったほど伸びないという悩みです。窓口を増やすたびに開発が必要になる、利用量が増えたときのコストが読めない、といった二周目の課題もここに重なります。

株式会社ドコモSMTBネット銀行（以下、ドコモSMTBネット銀行）は、生成 AI による自動応対をすでに本番で運用していました。その基盤を Amazon Connect Customer AI agents に移し、2026 年 9 月から電話とチャットの両チャネルで応対を開始しました。本ブログでは、なぜ基盤を移したのか、そして本番導入に向けて何を作り込んだのかをご紹介します。

同社カスタマーセンターにおける AI 活用のあゆみは、2026 年 6 月 26 日の AWS Summit Japan 2026 において、カスタマーサービス部 CS・DX企画グループの中﨑 敬太様が「銀行カスタマーセンターにおける AI 活用の実践と進化」として講演されています。本ブログはその概略を振り返りながら、Amazon Connect Customer AI agents の採用に至る判断と、導入に向けた検証の内容を整理したものです。

ドコモSMTBネット銀行のカスタマーセンター

ドコモSMTBネット銀行は 2007 年 9 月に開業したインターネット専業銀行です。モバイルアプリを通じた個人・法人向けサービスに加え、2020 年には邦銀で初めてフルバンキングの BaaS（Banking as a Service）を提供し、多様な業界のパートナーへ銀行機能を提供しています。

同社は 2017 年に「クラウドファースト」の方針を決定し、2018 年にコールセンターシステム、2025 年には勘定系システムを AWS 上に構築することを発表してきました。電話基盤として Amazon Connect Customer を採用したのは 2018 年で、今回の取り組みはその延長線上にあります。

カスタマーセンターでは、電話、お問合せフォーム、チャットの各チャネルを運用し、お客さまからのお問合せを受け付けています。

第 1 世代と第 2 世代で見えたこと

同社が生成 AI の検討を始めたのは 2023 年下期。問題意識は 2 つありました。

ひとつは、ボイスからノンボイスへの移行が頭打ちになっていたこと。問い合わせに占める比率はボイスとノンボイスで 4 対 6 まで進みましたが、そこから先が動きません。IVR（自動音声応答）をさらに作り込む方向では、この壁を越えられないという判断がありました。もうひとつは、目的別に用意した窓口に目的外の入電が多数寄せられていたことです。結果として一次解決率が低下し、オペレーターの負荷も増していました。

そこで 2024 年 8 月、一部の受付窓口で生成 AI（SaaS）による PoC を、実トラフィックを流す本番運用として開始しました。ここで下した割り切りが、その後の展開を支えました。回答文の生成は行わず、コールリーズンの判定と、事前に用意した FAQ の提示だけに機能を限定したのです。生成させなければハルシネーションは起きません。リスクを運用で抑えるのではなく、設計で消しにいった判断でした。あわせて、入力データのオプトアウト機能により自動学習を排除し、個人情報の取り扱いにも配慮しています。

2024 年 10 月には他社の対話型 AI プラットフォームを採用して本格開発に着手し、窓口別の「フロー」を用意してコールリーズン判定で振り分ける構成へ拡張しました。2025 年 6 月に受付窓口と FAQ を広げて本格導入した結果、問い合わせ対応の自動化率が大きく向上し、顧客利便性の向上と運営コストの最適化を両立しています。

図 1 カスタマーセンターにおける生成 AI 適用の変遷

継続課題として残ったのは FAQ 回答精度の向上です。お客さまの照会内容と生成 AI が提示した FAQ を突き合わせて検証し、ヒット率を上げていく地道な改善が要ります。チャットへの展開にも余地がありました。従来のシナリオ型チャットボットでは、お客さまからの多様なお問い合わせへの柔軟な対応や自然な対話の実現に課題がありました。

Amazon Connect Customer AI agents を選んだ理由

第 2 世代の運用を通じて、同社は 3 つの課題を明確に持っていました。Amazon Connect Customer AI agents の採用は、この 3 つに対応する判断です。

自社の AWS 環境内で構築できる

当時は外部の SaaS を利用する構成だったため、お客さまごとの状況に応じた応対を作り込むうえで制約がありました。Amazon Connect Customer AI agents は、すでに稼働している Amazon Connect Customer の環境に AI サービスを追加する形で構成できます。発信者番号やお客さまの属性といった、既存のコンタクトフローで扱っている情報を、そのまま応対の判断材料として使えます。

応対の処理が自社アカウントの中で完結することも、金融機関としては見過ごせない点です。ログの保管やアクセス制御は既存の統制の枠組みをそのまま適用でき、外部サービスとのデータ受け渡しについて個別に整理する手間がなくなります。

AI に任せる範囲とフローで案内する範囲を使い分けられる

従来の構成では、応対の分岐を追加するたびに「開発」が必要でした。Amazon Connect Customer では、意図の理解や FAQ の選択のように自律的な判断を AI agents に任せ、決まった手順どおりに実行したい決定論的な処理はコンタクトフローで組む、という分担ができます。どちらか一方に寄せるのではなく同じ基盤の上で組み合わせられることが、窓口を増やしていく際の開発負荷の軽減につながります。

通話時間とチャット数を基にした料金体系

トークンベースの料金体系では、利用量が増えたときのコストを事前に見積もりにくく、既存の仕組みとの単純比較も困難でした。AI agents は Amazon Connect Customer の料金体系に沿って通話時間とチャット数を基に課金されるため、コンタクトセンターの運用計画と同じ単位でコストを扱えます。

アーキテクチャ

図 2 カスタマーセンターの構成（ダイジェスト版）

構成の中心は Amazon Connect Customer AI agents と、それを呼び出すコンタクトフローです。お客さまが電話をかける、あるいは Web サイトからチャットを開始すると、コンタクトフローが AI agents に処理を渡します。AI agents は自社の FAQ を登録したナレッジベースを参照し、ご用件に応じた回答や次のご案内を返します。

AI agents に持たせているツールは 3 つの役割に分かれます。お客さまの発話や入力からコールリーズンを分類する処理、ナレッジベースから該当する FAQ を検索する処理、検索結果をもとに回答内容を組み立てる処理です。組み立てた結果はコンタクトフローに戻され、フロー側が音声での読み上げ、SMS による Web サイト URL のご案内、有人エージェントへの転送、電話予約のご案内へと振り分けます。

先に挙げた役割分担は、この構成にそのまま表れています。たとえば事故受付のように確実な取り扱いが求められる用件は、AI が分類した時点でフロー側の専用経路に載せます。AI agents の応答が得られない場合に有人転送へ縮退させる経路も、同じ考え方でフロー側に用意しました。

なお、ツールの実行結果をコンタクトフローに返して以降のルーティングをフローに任せるこの形は、Amazon Connect Customer のセルフサービスとして提供されている構成です。

PoC で確かめたこと

2026 年 1 月、Amazon Connect Customer AI agents の PoC を実施しました。通話とチャットの両チャネルに対応でき、回答精度は 95% 以上を確認できました。

差がはっきり表れたのは、お客さまの質問が曖昧なケースです。

「キャンペーンについて知りたいんだけど」という問い合わせに対して、同社の従来の構成では複数あるキャンペーンにかかる FAQ のうち、お客さまが本当に知りたいのがどのキャンペーンに関するものか掘り下げることはできませんでした。

AI agents では「どのようなキャンペーンについて、お知りになりたいですか？」と聞き返し、「定期預金のキャンペーンです」という回答を受けてから該当する FAQ を選びます。有人オペレーターが自然に行っている用件の深掘りが、そのまま自動応対の中で成立します。

PoC は、ドコモSMTBネット銀行と AWS が課題管理表で論点を往復しながら進めました。曖昧な質問の聞き返しをどの条件で発生させるか、FAQ の信頼度が低いときに複数候補を提示するか、キーワードによって専用フローへ遷移させるか。こうした論点を、実際にプロンプトを修正して挙動を確認しながら決めています。プロンプトは Amazon Connect Customer の管理画面から編集できるので、試行のサイクルを短く回せました。

応答時間をどう縮めたか

自動応対では、回答が正しいことと同じくらい、待たされないことが体験を左右します。本番導入に向けて、Amazon Connect Customer AI agents の応答時間を検証しました。

お客さまが 1 回発話してから回答が返るまでに、AI agents は 2 回の推論と 1 回のナレッジ検索を行います。発話を分類して FAQ 検索ツールを呼ぶ判断が 1 回目の推論、検索結果から回答の引数を組み立てるのが 2 回目の推論です。この間はお客さまが待っている時間になります。

図 3 お客さまの 1 発話に対する処理の流れ（オレンジは待ち時間の主因となる LLM の推論）

検証で得られた知見は 2 点です。

1 点目は、所要時間が AI agents の出力トークン数にほぼ比例することです。AWS の検証環境で推論時間を出力トークン数で割ると、チャネルや構成を問わず 1 トークンあたり 15〜21 ミリ秒に収まりました。入力側であるナレッジ検索の結果件数を削っても、所要時間はほとんど変わりません。短縮の余地は、LLM に書かせるトークンを減らすことにありました。

2 点目は、AI agents が書いている内容の大半が固定値だったことです。フローに返す引数を項目ごとに分解すると、SMS の定型文や URL のプレフィクス、復唱の定型句など、約 9 割が問い合わせ内容によらない固定値でした。可変なのは FAQ の識別番号と、お客さまのご用件を復唱する部分だけです。

そこで、固定値はコンタクトフロー側で組み立て、AI agents には可変部だけを書かせる構成に見直しました。お客さまに提示される内容は変えないまま、応答時間を短縮できます。ここでも判断の主体をどちらに置くかという線引きが働いています。

なお、ここで示した数値は AWS の検証環境での測定値です。ナレッジベースの内容やコンタクトフローの構成によって変わるため、実際の短縮幅はご自身の環境で測ることをおすすめします。

運用開始後の改善

適切な応対を維持するには、稼働後もプロンプトの調整と精度のモニタリングを続ける必要があります。ドコモSMTBネット銀行は第 2 世代の運用でも、お客さまの照会内容と生成 AI が提示した FAQ を突き合わせて検証し、ヒット率を上げる改善を積み上げてきました。この地道な作業をどれだけ続けやすくできるかが、基盤を移した後のテーマになります。

Amazon Connect Customer には、この改善サイクルを支える機能があります。電話とチャットのやり取りは録音・文字起こしされ、すべてが会話分析の対象になります。そのうえで、AI agents が担当した自己解決のやり取りも、有人オペレーターと同じ枠組みで採点できます。セルフサービスインタラクションのパフォーマンス評価では、「お客さまのご用件は AI agents で解決できたか」といった基準を自然言語で評価フォームに定義しておくと、生成 AI が会話を自動で採点し、スコアの根拠とトランスクリプト上の該当箇所まで示します。意図の理解に繰り返し失敗している、お客さまの感情が悪化している、有人転送に至っている、といった観点も評価の対象にできます。

この仕組みを使うと、集計されたダッシュボードで傾向を掴み、気になるコンタクトに降りて録音とトランスクリプトを見ながらやり取りをターンごとに追う、という進め方ができます。どの発話で意図を取り違えたのか、どの FAQ が選ばれたのかが分かるため、直すべきはプロンプトなのかナレッジベースなのかを切り分けられます。生成 AI が下書きした評価を人が確認して確定する運用から始め、精度を確かめながら自動化を広げることもできます。

安定稼働を確認しながら、こうした仕組みを段階的に運用へ組み込んでいくことが次の段階になります。

今後の展開

2026 年 9 月から、電話とチャットの両チャネルで Amazon Connect Customer AI agents による応対を開始しました。まずは安定稼働を優先し、その先ではパーソナライズ機能の追加を検討しています。お客さまごとの状況に応じた自己解決の手段を広げていくことが次のテーマです。

Amazon Connect Customer のセルフサービスは、AI エージェントが複数ステップにまたがって推論し、必要なツールを自ら選んで会話を継続するエージェンティックセルフサービスへと進化しています。今回構築した基盤の上に、こうした機能を段階的に取り込んでいけます。

ドコモSMTBネット銀行からのコメント

今回の取り組みについて、ドコモSMTBネット銀行 執行役員の半田 英二様からは、以下のようなコメントをいただきました。

「当社のカスタマーセンターは、お客さまの『困った』に最短でお応えすることを大切にしてきました。今回の Amazon Connect Customer AI agents の導入は、その姿勢を自動応対の領域へと広げるものです。電話とチャットのどちらでも AI がご用件を的確に汲み取り、必要なときにはオペレーターが引き継ぐ。この組み合わせによって、お客さまの利便性と応対品質を両立させていきます。今後も最先端のテクノロジーを積極的に取り入れ、くらしと金融の境目のない体験の実現に取り組んでまいります。」

本件のシステム開発を担当されている、システム開発部の室 良樹様からは、以下のようなコメントをいただきました。

「今回はカスタマーセンター全体の要件を改めて整理し、電話とチャットの両チャネルを Amazon Connect Customer に集約しました。AI に委ねる領域とコンタクトフローで作り込む領域を分けることで、新しい機能や窓口を同じ基盤に追加していける構成としています。応答時間についても、AWS と共同で処理時間の内訳を切り分け、改善箇所を見極めてまいりました。担当のテクニカルアカウントマネージャーをはじめ、継続的な技術支援をいただいた AWS に感謝いたします。今後もこの基盤の上に最先端のテクノロジーを取り込み、お客さま一人ひとりに応じた応対を広げてまいります。」

まとめ

ドコモSMTBネット銀行の取り組みで一貫していたのは、意図の理解のように自律的な判断は AI agents に任せ、確実性が求められる経路や定型文の組み立てといった決定論的な処理はコンタクトフローに寄せるという役割分担です。この線引きが、回答精度だけでなく応答時間と開発負荷にも影響していました。基盤の選定も、すでに稼働している自動応対の実績と残った精度課題を出発点にしています。

生成 AI 導入の二周目に入ったコンタクトセンターへの示唆は 2 つあると考えています。どこまでを AI に任せるかを決めてから基盤を選ぶこと。そして、運用開始後の改善を前提に設計しておくことです。プロンプトを管理画面から編集でき、お客さまのフィードバックを観測できる構成にしておけば、稼働後の精度向上を運用の中で回していけます。

Amazon Connect Customer AI agents については、製品ページと管理者ガイドで機能と設定方法を確認できます。コンタクトセンターの応対高度化についてご相談があれば、担当の AWS メンバーまでお気軽にお声がけください。