銀行向け会話型AI:うまくいく点と、破綻する点

銀行業務において会話型AIが実際に意味すること

マーケティング的な言い回しを取り除けば、会話型AIとはただこれだけだ。顧客が窓口係に話しかけるのと同じように、欲しいものをタイプするか話すかすると、ソフトウェアがその意図を理解し、回答するかタスクを実行する。電話の自動音声メニューも、「残高照会は2を押してください」もない。

CFPBは成熟度のはしごとしてこれを整理しており、各段階には意味がある。

• ルールベースのチャットボットは "decision tree logic or a database of keywords" によって動作するため、ユーザーは "limited to predefined possible inputs" 状態に置かれる。ボタンのメニューのようなものだと考えればいい。AIエージェントとルールベースのチャットボットの違いについてのこちらの解説を読んだことがあれば、これが一番下の段階だとわかるはずだ。
• NLUチャットボットは自然言語理解を使い、キーワードだけでなく自由記述の背後にある意図を認識する。NatWestは自社のCoraアシスタントについて、"through natural language processing and machine learning" によって問い合わせを処理していると説明している。
• LLMベースのエージェントが新たな最上段だ。CFPBは、銀行各行が "moving from simple, rule-based chatbots towards more sophisticated technologies such as large language models" にあると指摘している。

銀行業務においてLLMを安全にするのが検索拡張生成(RAG)、つまりグラウンディングだ。モデルは学習済みの重みではなく、銀行自身のナレッジベースから回答する。DBSはDBS Joyについて、"large language models with the bank's proprietary knowledge base" を統合していると説明しており、これにより "move beyond pre-programmed static answers to dynamic responses" ことができるとしている。Wells Fargoはさらに一歩進み、個人データが一切LLMに届かないようにアシスタントを設計している。

うまく構築されたフローの形はこうで、途中にある信頼度チェックが譲れない理由もここにある。

CFPBは限界についても率直だ。チャットボットは "may be useful for resolving basic inquiries, but their effectiveness wanes as problems become more complex" とされている。これは技術への批判ではなく、設計上の指針だ。実際に人々に好まれるツールとは、自分の限界を理解し、人間へと手を伸ばせるものだ。カスタマーサービスにおけるAIについての私たちのガイドではこの境界線を一般的な形で扱っているが、銀行業務ではその重要性がさらに増す。

すでにうまくいっている事例:大手銀行の導入実績

その証拠はベンダーの資料ではなく、銀行自身が公表している数字にある。以下は、いずれも一次情報である各行のニュースルームから引用したフラッグシップ導入事例だ。

いくつか際立つ点がある。まず、ユースケースは量が多くリスクの低い照会に集中している。Ericaは "in the next 7 days" の残高トレンドを知らせ、Enoは "a double charge, an abnormally large tip amount, or potential fraud" を能動的にアラートし、加盟店ごとのバーチャルカード番号を生成する。次に、賢い導入事例はAIを壁ではなく玄関口として扱っている。NatWestのCora+は要約付きで引き継ぎを行い、"the human agent can quickly understand what support the customer needs" ようにしている。

第三に、多言語対応はおまけではなく、本物の突破口だ。300万人以上のスペイン語話者のWells Fargo顧客がFargoを1億6000万回以上利用している。これほどのカバー範囲を人間だけでスタッフィングするのは途方もなくコストがかかるが、多言語の履歴で訓練されたエージェントであれば安価に実現できる。

経済合理性がこの急拡大を説明している。Juniper Researchは、銀行のチャットボットにより2023年までに世界全体で73億ドルの節約が生まれると予測しており、これは2019年の2億900万ドルから増加した数字で、8億6200万時間分の労働に相当し、対話の79%はモバイルアプリ経由だとしている。CFPBは1件の対応あたり0.70ドルの節約という単位数値を示している。自チームでこれらの数字を検証したい場合は、AI対人間のカスタマーサポートについての記事で比較を詳しく解説している。

顧客が実際にどう感じているか

ここはベンダーのページが触れない部分だ。実際の銀行顧客が話している場所を読むと、称賛の声よりもフラストレーションの声のほうが大きく、鋭く、具体的で、耳を傾ける価値がある。なぜなら、何を避けるべきかを正確に教えてくれるからだ。

最も怒りの声が大きい不満は、お金が絡む緊急事態であってもエスカレーションしないループだ。

"I've had fraud happening on my card this week and I've never had such an excruciating experience with a bank... I had to threaten to reach out to KiFid [the Dutch financial ombudsman] for them to allow me to speak to a human. Also the AI will occasionally pretend to be a person too. It's all horrible."

Bitterboule80 on r/bunq

これはまさに、CFPBが警告していた "doom loop" が不正利用のケースの中で現実になったものだ。この後に続くテーマも同様に一貫している。人々は目に見える人間を求めており、物事がシンプルでなくなった瞬間に信頼は崖から落ちるように失われる。あるフィンテック事業者は、自社の顧客を見ながらこう表現した。

"i've seen customers be fine with bots for simple stuff but get wary as soon as money or disputes are involved."

thepillowco on r/fintech

銀行ならではの不満の色合いさえも存在する。ボットが、すでに持っていた機能のダウングレードになってしまうというものだ。自分で明細をフィルタリングする代わりに "ask Erica" するよう仕向けられることについてのBank of America顧客の不満投稿は、会話型AIが優れた検索ボックスより自動的に上位互換になるわけではないことを思い出させてくれる。

これらのどれも「やめろ」と言っているわけではない。基準は信頼であり、失敗のパターンは具体的で回避可能だということを示している。これを実際にリリースしてきた実務者たちは、その解決策について意見が一致している。同じr/fintechのスレッドから。

"The key though is avoiding generic bots and keeping it rules-based, built for a specific domain/process/problem (especially in regulated areas like disputes), integrating with back-office data, and making handover to humans seamless."

これが、顧客自身の言葉によるレシピだ。引き継ぎを正しく行えるかどうかが、人々が我慢できる導入事例と、怒って離脱してしまう導入事例を分けている。

何を自動化し、何を人間に任せるか

では、その境界線はどこにあるのか。数多くの導入を見てきた私のルールはシンプルだ。照会は自動化し、意思決定はエスカレーションする。質問に答えることでお金が動いたり、商品が拒否されたり、法的権利が発生したりする場合は、人間が担当する。それ以外はすべてエージェントの領分だ。

左の列は、量と節約が集中している場所であり、まさにサポートチームの一日を食いつぶすTier-1の業務そのものだ。これは、優れたAIヘルプデスクエージェントがすでに得意としていることと綺麗に重なる。繰り返しの多い業務をデフレクトし、回答の一貫性を保ち、すべてを記録する。右の列は、誤った回答が規制上の問題になりうる領域であり、そうしたフローは意図を捉えたうえでルーティングするべきで、決して推測してはいけない。

私が最もよく目にする失敗は、デモで有能に見えたからという理由で、境界線を右方向に急いで押し広げようとし、ボットに異議申し立てや融資に関する質問を扱わせてしまうことだ。それが、前述のr/bunqのスレッドのような結果につながる。まずは狭い範囲から始めて左の列で実績を証明し、デフレクション率とエスカレーションの質の両方が維持できるとわかってから拡大するべきだ。

銀行業務が加わることで生じるコンプライアンス面

これが、銀行業務を一般的なサポートと分ける点だ。ここでの誤答は単に顧客をいら立たせるだけでなく、規制対象の金融機関が連邦法に違反する可能性さえある。CFPBはこれを率直に述べている。"poorly deployed chatbot can lead to customer frustration, reduced trust, and even violations of the law."

そのため、銀行のボットには一般的なサポートボットにはないコンプライアンス面が伴う。

各要素を見ていこう。

• PIIとカードデータの取り扱い。 Gramm-Leach-Bliley ActとFTC Safeguards Ruleは、顧客情報の通信中および保存時の暗号化と、30日以内の侵害通知義務を求めている。フローがカード番号に触れる可能性がある場合、PCI DSSはアカウント番号をマスキングし判読不能にすることを求める。だからこそ、トランスクリプトやログにおける匿名化はオプションではない。
• 自動化された意思決定に対する人間による審査。 EUの顧客に対しては、GDPR第22条が、法的または重大な影響を及ぼす "not to be subject to a decision based solely on automated processing" 権利を与えており、融資を拒否されるケースがその典型例で、さらに人間の介入を求める権利も伴う。
• EU AI法における高リスクの境界線。 附属書IIIの下では、"to evaluate the creditworthiness of natural persons or establish their credit score" に使われるAIは高リスクに分類され、人間による監視とログ記録の義務が発生する。ここで正確に言っておく価値がある。「残高はいくらですか」に答えるサポートボットが自動的に高リスクになるわけではなく、そのトリガーは与信スコアリングのユースケースだ。しかし、フローが与信の判断に影響を与える瞬間、その一線を越える。
• ベンダーに求められる基準。 ツールを購入する銀行は、統制が単に紙の上に存在するだけでなく実際に時間をかけて機能していることを検証するSOC 2 Type IIレポートを期待する。

これらすべてを貫く共通点は、顧客が求めていたのとまったく同じ設計パターンだ。グラウンディング、ログ記録、そして人間への退出経路。3つの異なる法的枠組みが、それぞれ独立してエスカレーション経路を義務付けている。ツールを評価しているなら、サポートチームのためのAIナレッジマネジメントについての記事が、承認済みナレッジ層をクリーンに保つ方法を扱っており、そこが正確性の出発点になる。

顧客を怒らせずに導入する方法

顧客の声とコンプライアンス面を組み合わせれば、進め方は明確になる。私なら順番にこう進める。

すべてをグラウンディングし、本番稼働前に証明する。 エージェントを承認済みのヘルプセンターとポリシードキュメントに限定することが、回答をでっち上げないようにする鍵であり、汎用ボットは "ill-suited for tasks that require logic, specialized knowledge, or current data" だとCFPBが述べるときに暗に求めている緩和策でもある。私はこれが手痛く失敗する現場を見てきた。ある有料顧客のボットが製品に関する主張をでっち上げ、実際の顧客に送ってしまったことがある。検索結果が空振りし、モデルが学習データからそのギャップを埋めてしまったからだ。修正すべきはより賢いモデルではなく、まずエージェントを何千件もの実際の過去チケットに対してシミュレーションし、顧客より先にハルシネーションが起きる箇所を把握することだ。

信頼度でゲートし、人間の存在を常に見えるようにする。 しきい値を設定し、それを下回った場合はエージェントがライブで返信する代わりに人間向けの下書きを作成するか、引き継ぐようにする。繰り返しの試行回数に上限を設け、doom loopを絶対に生み出さないようにする。銀行ボットのレビューで最も頻繁に挙げられる機能はシームレスなエスカレーションであり、それこそがr/bunqの顧客たちに与えられなかったものだ。

機密データはあるべき場所にとどめる。 金融・医療系のチームをオンボーディングする際、最大の関門は常にデータの取り扱いだ。あるバイヤーは、カード番号やパスワードを含むチケットデータが自社環境内にとどまるという保証を必要としていた。その答えは、エージェントが質問の種類と回答スタイルについて推論を行い、カスタムの保持期間とPIIの匿名化を備え、顧客データがモデルの学習に使われることは一切ないというものだ。これらは、セキュリティレビューがどのベンダーに対しても尋ねるべき質問だ。

Tier-1から始め、実績に応じて拡大する。 現実的なスコープとして、現場の担当者たちが繰り返し口にするのはTier-1デフレクションだ。サポート時間を食いつぶす「手数料はいくらですか」や「どうやって出金しますか」といった質問はエージェントに任せ、複雑な案件は人間に回す。拡大するのは初回対応解決率が維持できてからにする。これを中心にチームを編成しようとしているなら、スタートアップ向けのスケーリングガイドが良き相棒になる。

銀行・フィンテック向けサポートにeeselを試す

銀行、貸金業者、あるいはフィンテック企業として検討しているなら、eeselはまさに上記のパターンのために作られている。すでに運用しているヘルプデスクに組み込まれ、過去のチケットとヘルプドキュメントから学習し、承認済みのナレッジからのみ回答するため、台本を外れることなくTier-1の照会をデフレクトする。規制業界のチームにとって最も重要なのは、実際の顧客に一件でも返信する前に、何千件もの実際の過去チケットに対してエージェントをシミュレーションできる点だ。その後、信頼度ベースのルーティングとクリーンな人間への引き継ぎによって、段階的に自律性を高めていける。

すでに銀行規模での運用実績があり、融資比較プラットフォーム向けに月間10万件以上のドイツ語チケットをエージェントが処理しており、セキュリティ面ではSOC 2の統制、GDPRとEUデータレジデンシー、PIIの匿名化を備えている。料金は従量課金制で、解決したチケット1件あたり約0.40ドル、席数に応じた料金は発生しないため、まだ試している段階のプラットフォームに料金を払う必要はない。

eeselを試すのは無料で、コンプライアンスやシミュレーションの設定について誰かと一緒に確認したい場合はデモを予約することもできる。