ドイツのネット銀行が、AIをUIに「組み込まずに」決済トラブルSLAを48→85%に改善した話 - AWS Summit Hamburg 2026 レポート
ベルリンオフィスの小西です。
AWS Summit Hamburg 2026のセッションレポート第2弾。今回はベルリン発のネオバンク N26 による「Zero Human Touch: How N26 Automated Payment Disputes with AI」（直訳: 人手ゼロ - N26はいかにして決済の異議申し立て対応をAIで自動化したか）のセッションをまとめます。
N26側からはCarolina Tavares氏（Lead Product Manager, Cards）とAlexander氏（Lead Software Engineer）が登壇し、チャージバック処理のAI自動化について、プロダクト視点と技術視点の両面から語られました。
規制の厳しいだろう金融業界でAIを本番投入するまでの組織的なハードル含めた話は刺激が多かったです。
N26とは
N26はドイツ・ベルリン発のネオバンク（モバイル専業銀行）です。ヨーロッパを中心に展開しており、2024年末時点で約480万のアクティブ顧客、年間トランザクション額は1,400億ユーロ規模になっています。
自分がドイツに移り住んだ頃は「英語で使えるドイツのネット銀行アプリ」はほぼここ一択でした。UIも洗練されていて今でも大変お世話になっています。
課題: チャージバック処理がパンクしていた
チャージバックとは
チャージバック（Chargeback）はカード決済に対する異議申し立て（dispute）の処理のことです。大きく2種類あります。
- Unauthorized: カードの不正利用。いわゆる詐欺。判断基準が比較的明確
- Authorized: 顧客自身が決済を承認したが、何かしら問題が発生したケース。例えば「通販で椅子を買ったのに届かない」など
個人的な話になりますが、以前あるローカルスーパー前の路上ATMで預金を引き出したところ、その日の夜中に10万円近く某国から不正に引き落とされる事件がありました。すぐN26のチャットサポートに連絡、その後1営業日内に返金その他の対応してくれて、大変感動した覚えがあります（その頃はAI自動化ではなかったと思いますが）。
今回のセッションはAuthorized chargeback、つまり 顧客が自分で決済したけど問題があった 場合の処理を自動化した話です。こちらのほうが証拠の確認や判断が複雑で、自動化のハードルが高いらしいです。
導入前の状況
2024年12月時点で、N26のオペレーションチームはバックログに埋もれていました。
ユーザーがアプリから異議申し立て（dispute）を行うと、ケースがバックログに積まれ、アナリストが手動でレビューするまで放置される。アナリストはまず提出書類を確認し、英語以外の書類は翻訳し、Mastercardの基準と照合し、足りない書類があれば顧客に再提出を依頼し...というやり取りを何度も繰り返す。
結果、顧客はお金が戻ってくるかも分からないまま何日も待たされてしまう。銀行を一番頼りにしたい場面で顧客体験が悪いのはまずい、ということで改善プロジェクトが発足したとのことです。
目標は 主要プロセスの70%をエンドツーエンドで自動化する こと。ユーザー数が増えてもオペレーションチームを比例して増やさなくて済むスケーラビリティの確保が狙いです。
ドメイン理解から始めた
Alex氏のチームはもともとチャージバックのUI提出フローと一部の自動化ルール（不正利用系）を担当していました。ただ、Authorized chargebackのような複雑な判断をルールベースでカバーするのは限界がある。
そこでまず取り組んだのが、関係者を集めたドメイン（領域）理解のセッションです。Backend、AI/Data Science、そして毎日手作業でチャージバックを処理しているオペレーションチームのアナリストを集め、フローのマッピングやユースケースの洗い出しを行いました。
この結果、システムを4つのサブドメインに整理しています。
- Customer Dispute Journey: 顧客がアプリ上でチャージバックを申請し、証拠をアップロードするフロー
- Workflow Automation: チャージバック提出を各状態（受付、審査中、完了等）に遷移させるオーケストレーション
- AI Decisioning: 提出された証拠をMastercardの基準に照らして評価し、構造化された判定結果を返す
- Back Office: ケース履歴の管理、監査証跡、オペレーション上の可視性
Domain-Driven Design（DDD）のコンテキストマップを使ってこれを整理したとのこと。各コンテキスト間の関係性（Customer-Supplier、Published Language、Anti-Corruption Layer等）も定義され、設計にたっぷり時間を割いたんだなという印象でした。
AIの組み込み方 — UIに直接組み込まなかった理由
チャージバック処理をAIで自動化するとなると、まず思いつくのは 顧客がアプリ上でAIとやり取りして解決する 形でしょう。Alex氏も「AIをUIの提出フローに直接組み込んで試したい誘惑はあった」と語っていました。
ただ、N26は規制下の金融機関です。顧客の多言語のフリーテキストをそのままLLMに投げて判断させるのはリスクが高く、出力の監査もしにくい。N26が選んだのは、顧客とAIの間に明確な境界を設け、構造化されたワークフローの中にAIを判定エンジンとして組み込むアプローチ でした。
AIが受け取るのは以下の3つです。
- 異議申し立て対象のトランザクション情報
- 顧客がアップロードした書類
- チャージバック質問票への回答
これに加えて、Mastercardのチャージバック基準と、各基準を満たすために必要な証拠のリストをAIに渡します。AIはこれらを照合して、4つの判定のいずれかを返します。
- Accept: 全証拠がMastercard基準を満たす → 返金処理へ
- Reject: 却下基準に該当 → 理由の詳細と共に顧客へ通知
- Feedback Required: 追加書類が必要 → 顧客に具体的な書類を指定して再提出を依頼
- Human Specialist: 複雑すぎるケース → 人間のアナリストへエスカレーション
LLMにフリーテキストを生成させるのではなく、構造化された判定結果を出力させる設計です。監査可能性（auditability）が求められる金融の規制環境に則しています。
安全性の担保
規制業界のため安全性は3つのレイヤーで担保しています。
AI Guardrails: 判定リクエストがAIに到達する前にバリデーションルールを通す。顧客の自由テキスト入力や不適切な書類をここでフィルタリングします。
Controlled Rollout: 全顧客に一気に展開せず、特定のサブセットや特定のチャージバックタイプから段階的にロールアウト。問題が起きた場合のblast radius（影響範囲）を限定する狙いです。
Traceability: 全チャージバック提出についてモデルの出力、提出された証拠、AIの推論過程、モデルバージョンを記録。監査対応だけでなく、このデータがモデル改善のフィードバックループにもなります。
アーキテクチャ
技術的に興味深いのはバックエンドとAI判定エンジンの疎結合設計です。
顧客がN26アプリでチャージバックを提出すると、Kotlinバックエンドが受信。Workflow Automationが状態遷移を管理し、AI処理が必要と判断した段階でSQSキューにリクエストを投入します。
Lambda関数がこれを受け取り、Amazon Bedrock上のモデル（※セッション最後のAWS側パートでAnthropicのOpusモデルという点に言及されてましたが、自分の聞く限りN26側からモデルは明示されていなかった）で判定を実行。
構造化された結果をSQSキューに返し、Kotlinバックエンドが受け取って業務処理を続行します。顧客データはS3バケットから参照する形です。
非同期通信にしたことで、疎結合、リトライ対応が可能になり、バックエンドがビジネスプロセスの主導権を握ったままAIの判定能力を活用できる構成になっています。AIサービスが落ちてもバックエンド側は影響を受けにくい形。
段階的なロールアウト
N26はモデルの展開を4段階に分けています。
Phase 1: Feasibility Validation
LLMが証拠の分析やチャージバック判断に使えるかをまず検証。結論としては「使える。ただし非構造化データをそのまま投げても有用な結果は返ってこない。チャージバックのドメイン知識も必要」。
Phase 2: Shadow Mode
本番環境でAI判定エンジンを動かすが、結果は実際のケースに適用しない。人間のアナリストと一緒に出力を評価し、モデルを改善していくフェーズです。
Phase 3: Recommender Mode
AIの判定と推論をアナリストに提示する段階。アナリストは参考にしつつ自分で最終判断を下す。これだけでもアナリストの作業効率は上がったとのこと。
Phase 4: Live Decisioning
AIの判定を実際に適用。ただしここで全件投入ではなく、段階的にケース数を増やしながらアナリストと共にモニタリング。
前回のドイツ鉄道の記事でも自律レベルモデルの話がありましたが、N26もやはり段階的に信頼を積み上げるアプローチを取っています。
学んだこと
Alex氏が共有してくれた3つの学びが下記です:
Lesson 1: まずインプットを直せ。 導入前は自由テキスト1つとファイルアップロードだけのUIで、不完全な提出が多くアナリストとの何往復ものやり取りが発生してた。これをチャージバックタイプごとに専用UIフローに変え、必要な証拠を明確に要求する形に。AIに良い判断をさせたいなら、モデルのチューニングより先にインプットの品質を上げろ、という話。
Lesson 2: AIコントラクトを初日から定義する。 先述の「とりあえずAIをUIに直接つないで試そう」という誘惑に対して、N26はリクエスト/レスポンスの構造（AIコントラクト）を最初に明確に定義した。判定リクエストにはMastercardの基準と証拠を、レスポンスには4つの判定結果を、というインターフェースを先に決めた。これにより、バックエンドチームはデータの構造化と提出に集中し、AI/Data Scienceチームはモデル改善に集中でき、互いに並行で進められた。
Lesson 3: 一番難しかったのは技術ではなく組織。 Backend、AI/Data Science、Platform、Operationsを1つのプロダクトチームとして機能させることが最大の課題だった。"One product team. AI became an engineering capability — not a separate technology" というメッセージが印象的。
成果
数字で見える成果が出ています。
- SLA遵守率: 48% → 65%（Recommender導入時） → 85%超（Full automation）
- 顧客満足度: 38% → 51%超
- エンドツーエンド自動化率: 60%以上のチャージバックが人間の介入なしで処理
- バックログは完全に解消
顧客満足度について補足すると、チャージバックの承認率が上がったわけではなく、同じ判定基準のまま、プロセスが速くなり透明性が上がったことで満足度が改善した、という点が強調されていました。
最後に
前回のドイツ鉄道の事例がインフラ運用のAIエージェント化だったのに対し、こちらは顧客向けプロダクトのバックエンドにAIを組み込んだ事例。方向性は違いますが、段階的ロールアウト、人間との協業、トレーサビリティの重視といった共通点が多くあった印象です。
AWS Summit Hamburgの他のセッションレポートも書いているので、よければあわせてどうぞ。
