金融AIは社内で動かせば安全か?顧客情報と誤回答をどう管理する
日銀の2026年度調査と金融庁第1.1版、閉域での設計書検証を基に、情報管理・回答確認・共同基盤の運用分担について
金融庁のAIディスカッションペーパー第1.1版、日銀の2026年度調査、ローカルLLMの技術検証から、金融AIの配置と運用責任を読む。顧客情報の管理と誤回答への対応、共同基盤の計画と実際の成果を区別する。
ざっくり言うと
- 日銀の調査では利用中と試行中が分けられ、すべての金融機関の本番導入率ではない
- 顧客情報の扱いは設置場所だけでなく、利用目的と委託先の管理から確かめる
- 開発支援検証と顧客サービスを区別し、共同基盤でも利用範囲と変更・事故対応の責任を確かめる
本記事は公開資料に基づく一般情報であり、法的アドバイスではない。個別の情報の取扱いや契約の判断は、実際の業務と規程に即して弁護士等へ確認する必要がある。
何が起きているのか
日銀の2026年度調査から、利用の広がりと対象の範囲を読む
金融機関で生成AIを使う場面が広がると、顧客情報をどこまで入力できるかが問われる。外部のサービスへ情報を送らず、組織内でAIを動かす方法は、その問いに対する選択肢になる。ただし、情報が外へ出ないことと、回答が正しく、必要な人だけが参照できることは別に確かめなければならない。
の2026年度調査は、取引先金融機関150先を対象にしている。調査本文(外部サイト、新しいタブで開きます)によると、生成AIを利用中の先は79.3%、試行中は11.3%だった。「試行中」を含む広がりを、すべての金融機関が顧客向けサービスを本番導入した証拠にはできない。
同じ調査でも、文書作成や文字起こしなどの社内業務と、AIの回答を顧客へ直接提示する用途は分けられている。後者には慎重な姿勢が見られると報告している。導入の有無だけでは、どのデータを使い、誰の判断を支援し、誰に回答を届けているかは分からない。金融AIの現在地は、利用の広がりと業務ごとの条件を合わせて読む必要がある。
背景と文脈
金融庁と個人情報保護委員会の資料から、設置場所と情報管理を分ける
設置場所だけでは決まらない
ローカルLLMとは、を組織内の機器などで動かす構成を指す。モデルは入力に応じた文章を生成するが、文章が自然であることは内容の正しさを保証しない。自社設備で運用するの構成は、送信経路を管理する選択肢であり、それだけで誤回答や権限のない閲覧がなくなるわけではない。
のAIディスカッションペーパー第1.1版(外部サイト、新しいタブで開きます)は、個人情報を含む入力、外部事業者への委託、海外との関係などを分けて整理している。具体的な対応を一律に求める文書ではなく、今後の対話に向けた論点を提示する資料である。
顧客情報を生成AIのサービスへ入力する場面については、通常、提供者を個人データの取扱いの委託先として管理する必要があると説明する。サービスの選定や契約では、金融機関の指示なく追加学習に使われないことなどを確認する必要があるとしている。「だから禁止」「社内だから許可」と配置だけで判断するより、何のために処理し、誰がデータを扱うかを確認する説明になっている。
外部サービスを利用
委託先との関係を確認
- データ
- 取扱範囲・利用目的
- 提供者
- 契約・指示外学習
- 接続
- 送信先・管理条件
組織内で運用
自分たちの管理範囲を確認
- データ
- 参照範囲・閲覧権限
- 運用者
- 更新・障害対応
- 回答
- 根拠・誤りへの対応
金融庁第1.1版31〜32、36、38〜39頁を基に確認の視点を整理。左でも回答の確認は必要で、右でも外部委託があれば委託先管理が必要。どちらかを選べば他の責任がなくなる図ではない。
学習に使わないことの意味
個人情報保護委員会の2023年6月2日の注意喚起(外部サイト、新しいタブで開きます)は、個人情報を入力する際、その利用目的を達成するために必要な範囲かを十分に確認するよう求める。あらかじめ本人の同意を得ずに入力した個人データが、応答結果の出力以外の目的で扱われる場合には、法に違反する可能性があるとして、機械学習に利用されないことなどの確認も挙げている。
ここから、「学習に使わない」だけで情報管理が完了するとは言えない。利用目的に必要な入力か、誰が処理するか、どの範囲へ渡るかという確認が残る。金融庁の資料も、外国にある事業者との関係とサーバーの所在地を別に整理する。サーバーが国内にあるという一つの条件だけで、契約やデータの扱いを判断することはできない。
入力と参照の範囲を確認する方法として、同じ質問を違う権限の担当者が使う場面を検討できる。たとえば業務担当が自分の担当外の顧客文書を尋ねたとき、回答だけでなく引用や検索結果にも情報が混ざらないかを確かめたい。これは評価の例であり、実在する金融機関で漏えいが起きたという説明ではない。許可された文書だけを検索できたことと、そこから作った回答を業務に使えることも別に見る。
入力した情報の扱いを追う場合は、回答に残らなかった入力や、調査のために保存する利用記録も検討の対象となる。誰が見るか、何のために残すかを決めず、記録が多いほど安全だと評価するのは避けたい。確認担当が必要な部分を調べられる条件と、調査に関係のない顧客情報を広げない条件を合わせて考える。保存期間などの個別の扱いは、実際の業務と規程に即して確認する。
同様に、社内設置の構成でも、業務ごとの閲覧権限や運用の分担を決める必要がある。担当者が見られない文書をAIの回答経由で参照できるようになれば、外部送信を抑えていても情報管理の目的を満たさない。設置場所の選択は、処理と参照の範囲を決める仕事の一部として考えるべきである。
構造を読む
設計書の技術検証、共同基盤の計画、運用責任を確かめる
設計書の検証から分かること
NTTデータ先端技術の2026年4月14日の公表(外部サイト、新しいタブで開きます)は、NTTデータフィナンシャルテクノロジーと連携し、オンプレミスの閉域環境でローカルLLMを検証したと報告する。外部へデータを送信しない構成で、金融システムの開発に利用できるかを調べたである。
想定した用途は、整合性チェック、文書品質の向上、修正作業の迅速化であり、今回検証したのは設計書の整合性チェックだった。他の用途は今後の検証として記されている。企業はレビュー工程の削減を確認したと説明するが、公表ページには削減率や比較対象の詳しい数値は示されていない。成果の存在を否定する必要はなく、公表された範囲を越えて効果を広げないことが重要である。
設計書を確認する検証から、融資の可否や金融商品の案内をAIが安全に判断できると結論することもできない。利用する文書、誤りの影響、回答を受け取る人が異なるからである。検証を次の業務へ広げる際には、何を正しい指摘と数えるかを先に合わせたい。設計書同士の不一致を見つける例なら、どの記述が食い違い、修正が必要かをレビュー担当が確かめる。指摘を多く出しただけで精度の向上とせず、誤った指摘を調べ直す時間や、見落とした不一致も含めて比較する方法がある。AIが草案を作る時間と、人が確認を終える時間を分けることで、削減した工程の後へ負担が移っていないかを問える。
実際の業務へ移す際には、同じ処理がどの条件で再現できるか、誤りをどう発見し、誰が修正するかを確かめる必要がある。
今回公表された検証
設計書の整合性チェック
- 環境
- オンプレミス・閉域
- 対象
- システム開発文書
- 公表
- 企業による結果説明
業務への導入時
用途ごとに別途確認
- 評価
- 同じ業務で比較
- 確認
- 誤りの発見・修正
- 責任
- 更新・停止の担当
左は2026年4月14日のNTTデータ先端技術の公表に基づく。右は本稿の評価の視点であり、この検証で全項目が完了したことや、金融機関で本番稼働したことを示さない。
共同化で変わる費用と責任
NTTデータの2026年5月19日の発表(外部サイト、新しいタブで開きます)には、金融機関向けの共同生成AIプラットフォームを構築し、2026年度末に提供を開始する予定とある。入力・出力や利用記録などを管理する仕組みを含む計画である。この発表を読む際も、提供予定と実際の稼働を分けたい。
共同化によって設備や運用の仕事を共有できる可能性はあるが、誰が何を決めるかは残る。金融庁の資料は、開発者、維持管理者、複数の委託先などの責任の範囲を定める課題を紹介している。共同の基盤を利用することと、各機関の顧客情報やモデルの知的財産を自由に共有することは同じではない。契約や情報の取扱範囲を確かめず、連携の効果だけを見込むことはできない。
費用も、モデルの利用料だけで判断すると運用の仕事が見えなくなる。4月の検証はコストの見通しを立てやすくする狙いを説明しているが、誰もが安価に導入できるという比較結果ではない。本稿では、設備、更新、確認担当の時間、障害からの復旧まで含め、同じ業務を続けるための負担を比較する視点を提案する。
共同基盤の更新を考える場面でも、モデルを替えることと、参照文書を替えることは分けて評価したい。同じ入力でも出力が変わった場合に、どちらの変更が関係したかを確かめられる記録を残す方法がある。変更の通知を受けた担当と、その回答を日々利用する業務担当の間で、何を試してから利用を続けるかを相談する。参加機関ごとの規程が違うなら、共通の確認だけで済む範囲と、各機関で確かめる範囲も区別する。
参照できても正しいとは限らない
社内文書を検索し、見つけた情報を回答に利用するも、根拠を確認しやすくする方法になる。ただし、金融庁の資料は、参照資料の整備や業務設計が不十分だと、RAGを使っても虚偽の出力が残ると説明する。検索結果があることと、現行の規程に沿う回答ができたことは別である。
日銀の調査にも、情報管理や実務的ルールに取り組む一方、組織体制、外部事業者への依存、セキュリティなどで改善の余地や検討中の項目がある。利用数が増えた後にも、管理の仕事は続く。業務担当者が回答の根拠を確認できるか、古い資料やモデルの変更を誰が把握するかを、導入時だけでなく運用中にも確かめる必要がある。
誤回答を見つけた後も、文章を直しただけでは確認が終わらない場合がある。社内の下書きで止まったのか、担当者が業務に使ったのか、顧客へ届いたのかを分け、どこへ訂正を返すかを判断したい。利用を止める担当と、通常の業務を続ける担当が連絡できるかも、導入前に考える課題となる。ここで示すのは運用を検討する視点であり、特定の金融機関の事故や対応手順を報告するものではない。
同じ規程名でも改定前の説明が検索に残る場合、回答の根拠にした版と適用時点を示す方法が考えられる。根拠が揃わない質問は推測で埋めず、業務担当が原資料を確かめる相談へ戻すことも評価の対象にしたい。
関連ガイド
成果指標の設計(このサイトの記事)では、活動の量と、その結果生じた変化を分けて考える。AIの利用件数と、業務や顧客にとっての改善を読む際にも、この区別が役立つ。
この記事で使った統計の出典
- 1日本銀行 2026年度生成AIアンケート調査・本文2頁(2026年度) 出典を開く
- 2日本銀行『金融機関における生成AIの利用状況とリスク管理―2026年度アンケート調査結果から―』本文3頁(2026年度) 出典を開く
参考書籍
羽深宏樹の2023年刊『AIガバナンス入門: リスクマネジメントから社会設計まで (ハヤカワ新書)』(外部サイト、新しいタブで開きます)を関連読書として挙げる。早川書房の紹介(外部サイト、新しいタブで開きます)は、AIの便益とリスク、社会の設計を扱う本として説明している。書籍本体は未読であり、金融機関の本番運用や事故対応の効果を証明する資料としては用いない。
写真はAI生成によるサーバー室のイメージであり、実際の金融機関の設備を撮影したものではない。
残る問い
金融AIの導入で手間が減ったとき、誰のどの作業が減ったのかを確認したい。文書作成が速くなっても、確認担当者の修正や、顧客へ説明し直す時間が増えれば、組織全体の負担は変わっていないかもしれない。処理件数や利用回数だけでなく、同じ業務の確認時間、訂正、問い合わせまで追えるだろうか。担当者が増えた仕事を報告しやすい仕組みもなければ、効果の説明から負担が抜け落ちる。
共同基盤を使う場合には、モデルや参照文書の更新に誰が同意するかを確かめたい。ある機関で便利な変更が、別の機関の規程や顧客対応に合うとは限らない。更新を保留し、影響を確認し、必要なら以前の状態へ戻す判断を、参加機関は行えるだろうか。基盤の提供者が変更を通知することと、利用する機関が自分の業務への影響を把握できたことは、別に確かめる必要がある。
設置場所を決める議論を、誰が停止と説明を担えるかという問いまで続けたい。誤回答が顧客へ届いたとき、担当者が利用を止め、影響範囲を確認し、訂正を届けられるかが重要になる。地域金融の限られた人員でその仕事を続けるには、どの部分を共同化し、どの判断を各機関に残すべきだろうか。AIを置けたことより、顧客と担当者が困ったときに対応を続けられる条件を、導入の評価に含めたい。確認のために残した記録が、顧客の情報を必要以上に広げていないかも同時に問いたい。訂正の通知を送った後に、受け取った担当が古い回答を使い続けない条件まで確かめられるだろうか。
参考文献
AIディスカッションペーパー(第1.1版)の公表について — 金融庁 (2026). 2026年3月3日公表ページ
AIディスカッションペーパー 第1.1版 — 金融庁 (2026). 6、31〜32、36、38〜39、49頁・文書の位置づけ、情報管理、外部委託、誤回答
金融機関における生成AIの利用状況とリスク管理―2026年度アンケート調査結果から― — 日本銀行金融機構局 (2026). 2026年8月6日・本文2〜3、5、9頁・調査対象、利用と試行、用途、リスク管理
生成AIサービスの利用に関する注意喚起等 — 個人情報保護委員会 (2023). 2023年6月2日・2頁、個人情報取扱事業者の注意点
NTTデータ先端技術、ローカルLLM環境を利用した金融システム開発向け生成AI活用を検証 — NTTデータ先端技術 (2026). 2026年4月14日・検証の概要と今後の用途
金融機関向けに共同利用型のAI基盤を構築開始、業界横断でのAI活用を推進 — NTTデータ (2026). 2026年5月19日・構築と2026年度末提供開始の計画
読んだ後に考えてみよう
- 社内設置で減るリスクと、運用者が引き受ける仕事を区別できているか。
- 技術検証の結果を、どの業務とデータの範囲で利用できるか。
- AIの更新を保留したり、利用を止めたりする権限は誰が持つか。
この記事の用語
- オンプレミス
- 自社や組織内の設備を使い、システムを設置・運用する構成。外部への送信を減らす構成でも、閲覧権限や更新、回答の確認などの管理は必要である。
- クラウド
- ネットワークを使い、サーバーや保存領域などの共有された計算資源を必要に応じて利用する仕組みを指す。クラウドを使うことだけでは、情報を閲覧できる人や第三者へ提供する条件は決まらない。
- 技術検証(PoC)
- 特定の用途や条件で技術を実際に試し、実現可能性などを確かめること。検証の成功だけで、別の用途や本番運用の安全性・効果が確認されたとは言えない。
- 検索拡張生成(RAG)
- 関連する資料を検索し、取得した情報を言語モデルの回答生成に使う方法。検索対象の範囲、アクセス権、取得した資料と回答の対応は別途確認する。
- 大規模言語モデル
- 大量の言語データを学習し、入力に応じて文章などを生成するモデル。もっともらしい文章を生成することと、内容が事実であることは別に確認する必要がある。
新着コラムをメールで受け取る
週1-2本の社会構造分析コラムを配信します。登録は無料です。
活動を支える賛助会員
年会費5,000円で、ISVDの調査研究と情報発信を支えられます。自動更新はありません。




