サービスチームは状況確認の電話を減らしたい。債権回収チームは延滞が深刻化する口座を減らしたい。営業チームは申込途中で離脱した顧客に対応したい。コンタクトセンターの責任者は、新人が実際の通話を早く適切に処理できるようにしたい。どれもAIの活用候補ですが、必要なシステムや人員はそれぞれ異なります。
最初のAIユースケースは、顧客タイプ、業務、記録システムを一つずつに絞った仕事です。予算を決める前に、実行準備が整っているか確認できる範囲にします。
銀行のAI活用候補は、事業価値、信頼できる情報へのアクセス、誤回答がもたらす影響、成功をどう確認するかを比べて優先順位をつけます。担当者にとって重要で、現在の人員とシステムで管理できる業務から始めましょう。
こうすれば、製品を選んだり詳細な事業計画を作ったりする前に、複数の提案を比べられます。
銀行で最初に取り組むAIユースケースとは
検討できるほど業務を具体化します。「顧客サービスを改善する」だけでは決めることが多すぎます。「本人確認後、特定の融資商品の申込状況に関する問い合わせに回答する」なら、対象顧客、業務、境界が明確です。
準備状況を確認する4つの視点
• 事業価値：どの遅延、反復作業、機会損失を解消しますか。推測ではなく、実際の問い合わせと担当者の業務を見ます。大量の着信には異なる問題が混在しており、提案したユースケースに当てはまるのは一部かもしれません。現状の対応工数を測る作業は別途必要です。電話業務については、銀行における音声AIのROIガイドで、業務変化とコストの結びつけ方を説明しています。
• 情報とアクセス：回答の根拠はどこにありますか。情報が最新か、システムが想定したアクセスを許可するか、誰が維持するかを確認します。サンプルデータを使ったデモだけでは、これらの疑問は解消されません。
• 影響と統制：回答が誤っていたり、同じ処理が二重に実行されたりすると、何が起こりますか。AIエージェントが実行できること、人が介入する条件、誤りの修正方法を決めます。
• 成功の証拠：業務が正しく完了したことを示す記録は何ですか。申込フォローなら、通話が完了した記録より、不足書類が正しい申込に届いた確認のほうが有用です。
AIが本当に必要かも確認します。固定のステータスメッセージや分かりやすいフォームで解決できるなら、その方法とも比べます。さまざまな質問の解釈、関連情報の検索、対話対応が価値を生む場面で、AIエージェントを活用する意味があります。
ユースケースで定める証拠は、評価結果を測るだけのものではありません。完了した業務に対してベンダーへ支払う根拠にもなります。完了の定義を示せなければ、どの商用モデルでも価格を決められません。
比較に値する銀行のAI活用候補
以下の例は、電話による営業、債権回収、顧客サービス、行員支援という必要能力ごとに整理しています。全社的なプログラムではなく、範囲を絞った業務として記載しています。「回収を改善する」ではなく、「初期延滞の特定区分にある顧客と支払計画を合意する」のような形です。これらは説明用の例であり、顧客導入事例でも、普遍的な適合性の順位づけでもありません。自社の準備状況に照らして候補を絞ってください。
候補業務：電話営業：申込を開始したが完了していない顧客に連絡する 目指す結果：顧客が申込を完了するか、支援できる担当者につながる 必要な準備：連絡への同意記録、最新の申込状況、承認済みスクリプト、必要な説明事項 人による対応・延期理由：助言の依頼や脆弱性の兆候は、資格を持つ担当者へ引き継ぐ。同意記録が不完全なら延期する
候補業務：電話営業：特定した休眠顧客層に具体的なオファーを案内する 目指す結果：顧客の反応または配信停止を確認し、結果を対象層に記録する 必要な準備：検証可能な適格性ルール、配信除外リスト、承認済み条件、停止手段 人による対応・延期理由：連絡時点で確認できない情報に適格性が左右されるなら延期する
候補業務：債権回収：定義した初期延滞区分で督促し、支払計画に合意する 目指す結果：顧客が計画に合意するか、適切な担当部署と話す 必要な準備：最新の延滞情報、許可された連絡時間と頻度上限、承認済み困難者対応スクリプト 人による対応・延期理由：脆弱な顧客、異議申立て、困難事例は直ちに担当者へ。延滞情報の更新が遅れる場合は延期する
候補業務：顧客サービス：認証済み顧客の申込状況や残高の問い合わせに回答する 目指す結果：顧客が正確で最新の状況と次の手順を受け取る 必要な準備：信頼できる状況データ、本人確認、承認済み説明 人による対応・延期理由：異議や不明確な状況は引き継ぐ。記録が古い、またはアクセスできない場合は延期する
候補業務：顧客サービス：不足している申込書類や本人確認書類をフォローする 目指す結果：依頼した書類が正しい申込の審査に届く 必要な準備：正確な不足書類情報、承認済み連絡手順、安全な提出経路 人による対応・延期理由：書類の受理可否や例外は担当者が判断する。提出後も督促が止まらないなら延期する
候補業務：従業員向けAIコパイロット：通話中の担当者に根拠資料付きの方針と次の手順を提示する 目指す結果：担当者が初回対応で正確に解決し、不要な引継ぎを減らす 必要な準備：正本となる方針情報、アクセス権、誤案内を報告する手段 人による対応・延期理由：発言の責任は担当者が負う。どの版が正式か判断できないなら延期するこの4つの視点はリテール銀行以外にも当てはまります。与信・申込業務でAIを検討する貸し手も、通話中に担当者を支援するコンタクトセンターも、同じ問いに直面します。回答の根拠は何か、例外を誰が受け取るか、業務完了を示す記録は何か。業務内容は異なっても、準備状況の確認方法は変わりません。
業務全体を見ます。状況確認には本人確認や遅延理由の質問が伴うことがあります。書類の督促を受けた顧客が、必要書類を提出できない事情を説明することもあります。
営業電話が苦情や、エージェントに回答が許されていない質問に変わることもあります。初期延滞の電話から経済的困難が分かり、次の対応を変える必要が生じる場合もあります。業務量を評価する際は、こうした通常の例外も含めてください。工数とリスクはまさにそこにあります。
候補が複数残る場合は、それぞれに必要なシステムを確認します。銀行向けAIエージェントには、顧客対応を最後まで処理するものもあれば、振り分けや下書きで止まるものもあります。機能一覧ではなく、自社の連携能力と照らし合わせてください。
上記は説明用の候補です。稼働中の類似業務については、Dyna.Aiが公開しているシンガポールでの債権回収効率化事例と、AIコンタクトセンターで重要な機能をご覧ください。
今は見送るべきAIユースケース
信頼できる情報源、許可されたアクセス、責任を持つ担当者を確認できない場合は候補を保留します。これらは業務の稼働そのものに関わるため、潜在価値の大きな見積もりだけでは解決しません。
「人によるレビュー」も実務として定義する必要があります。例外を受け取る部署、受け取る情報、担当者が不在の場合の対応を明確にします。モデルリスク管理指針をすでに活用している銀行には、参考となる枠組みがあります。米連邦準備制度の現行の省庁間モデルリスク管理指針（SR 26-2）は、実効的な異議検証、妥当性確認、責任者の文書化について、AIエージェントにも直接応用できる期待事項を示しています。
直接の利用者以外への影響も考慮します。従業員が誤った社内案内を信頼すれば、顧客にも影響します。NIST AIリスク管理フレームワークは、利用状況に応じてAIリスクを考えるための任意の参考枠組みです。
与信や本人確認に関わる候補の一部は、EU AI法で高リスクに分類され、特定の義務が課されます。他の規制当局も期待事項を公表しています。インドネシアのOJKは2025年に銀行向けAIガバナンス指針を発表し、香港金融管理局（HKMA）はDyna.Aiも参加した生成AIサンドボックスを実施しました。
要件を確定する前に、自社の免許に適用される枠組みを特定します。一つの規制に合わせた業務でも、別の規制への対応が必要な場合があります。
延期する候補には、「申込記録が安定して更新されるようになったら再検討する」のように、具体的な前提条件を記録します。機会を残しながら次の手順を明確にできます。
有望なAI候補をどう優先するか
初期延滞の督促と申込状況の問い合わせを比較する銀行を考えてみます。延滞口座で支払計画に合意できれば、状況を回答するより価値が大きいため、債権回収が最初の候補に見えるかもしれません。しかし、それだけでは決められません。
この例では、延滞データは毎日更新され、銀行は連絡可能な時間帯、頻度上限、困難者対応スクリプトを承認済みです。一方、申込状況のシステムは最新の状態を安定して取得できません。
脆弱な顧客の確認と困難者対応の経路が整っていることを条件に、初回評価では初期延滞の督促を選びます。合意した支払計画を口座記録と照合し、顧客が計画を守ったかも確認できます。
条件を逆にしてみましょう。延滞データの更新が回収業務より遅く、前日に支払った顧客にも連絡する可能性があります。一方、申込状況の記録は最新で、承認済みのアクセス経路があります。この場合、1件あたりの価値が小さくても、申込状況の問い合わせがより適した最初の候補となるかもしれません。
選択は銀行の準備状況に従い、準備状況が同等の場合に価値で決まります。両方の準備が整っているなら、削減できる負担と新たに必要となる連携、担当者レビュー、例外対応、継続保守を比べます。利用可能な予算内で意味のある改善に進みやすい候補を選び、もう一方は次の投資候補として残します。
安全そうでも停滞しやすい選び方
こうした議論では、よく見られるパターンが3つあります。どれも案を即座に却下する理由ではありませんが、初回評価を数か月遅らせがちです。
最も印象的なデモから始める
サンプルデータのデモで分かるのは技術の可能性であり、自社の記録が対応できるかではありません。デモでは確認できない情報源、権限、責任者を基準に候補を評価してください。
最大の削減見込みから始める
削減額が最も大きい候補は、対象範囲が広く、データも整っていないことがよくあります。責任者と最新情報源が明確な小さな候補なら、より早く行動につながる結果を得られます。
パイロット成功を準備完了の証拠とみなす
人が常時監督し、選別済みデータを使い、ベンダーのエンジニアが同席したパイロットでは、本番で依存する条件をまだ検証できていません。両者の違いは、銀行のAIをパイロットから本番へ移す方法で詳しく説明しています。
AIユースケースの優先順位づけ：簡易ブリーフに含める項目
業務、技術、リスクの担当者が検討できる短いブリーフに選択内容をまとめます。書面にすることで、優先順位の議論を責任ある意思決定に変えられます。以下は、申込状況問い合わせを想定した記入例です。
業務と利用者：一つの融資商品の申込状況に関する、認証済み顧客からの問い合わせ
現在の課題：申込システムにある情報を担当者が繰り返し取得・説明している。記録から件数と対応工数を確認する
目指す改善：担当者が情報を探す作業を減らし、顧客が正しい状況と次の手順を得る
情報と権限：承認済みの状況項目を読み取る。申込内容や融資判断は変更しない
例外：本人確認の失敗、異議、苦情、記録不足は指定のサービス部署へ引き継ぐ
収集する証拠：情報源との回答照合、顧客の理解、再問い合わせ、担当者工数、引継ぎ品質
説明責任：評価前にサービス責任者とシステム責任者を指名し、業務を停止できる担当者を合意する記入済みのブリーフは、意見の食い違いを早めに明らかにします。一方のチームが状況報告を期待し、別のチームが与信判断の説明を期待しているなら、提案範囲はまだ定まっていません。
説明責任を文書化することは、規制当局の方向性にも沿っています。たとえばMAS FEAT原則は、AI支援による結果に至った経緯を説明できることを求めています。責任者が記録されていなければ、後から再構成するのは困難です。
銀行のAIは従業員向けと顧客向けのどちらから始めるべきか
従業員向け業務が先になる場合
従業員が情報源を確認し、行動前に回答を修正できるなら、従業員支援は有用な最初の範囲になります。適切なアクセス制限と使いやすい確認手順は必要です。移行の全体像は、銀行のエージェンティックAIがパイロットから本番へ進む過程をご覧ください。
顧客向け業務の準備が整っている場合
顧客向け業務も、範囲が明確で信頼できる情報に基づき、対応できるサービスチームがあるなら候補になります。利用者が誰かだけでリスクを測らず、これらの条件を直接比較してください。
AIユースケースから評価へ：基準値、コスト、指標
構築前に基準値を定める
候補を決めたら、基準値を定め、連携、担当者レビュー、例外対応、初回評価で過小見積もりされがちな保守まで含めて総コストを見積もります。
機能一覧ではなく、自社の業務でベンダーを比べる
複数のベンダーが対応可能なら、機能一覧ではなく選定した業務で比較します。ブリーフに記載した例外を各社に実演してもらうと、提案の違いが明確になります。
Dyna.Aiは銀行向けAIエージェントを構築しています。適切な製品は選定した業務によって異なります。営業フォロー、初期延滞の督促、サービス問い合わせなどの電話業務にはDyna VoiceGPT、通話中に承認済み情報を必要とする担当者にはAIナレッジパートナー、本人確認や申込フォローには本人確認・書類処理、自社チームが業務を設定・拡張する場合にはエージェント構築環境が候補です。
Dyna.Aiに相談する際は、選定した業務、その情報源、現在扱っている例外をお持ちください。適合性、連携、評価で実証すべきことを具体的に話し合えます。