銀行でシャドーAIを止める方法

要約

• AIツールをブロックしてもシャドーAIは止まりません。承認済みのツールが回避策より速くない限り、従業員は許可されていないChatGPTやGeminiのアカウントに顧客データを貼り付けます。
• Community Bankは、許可されていない1つのAIツールが非公開の顧客情報を処理した事実を把握してから2日以内に、重要事象としてSECにForm 8-Kを提出しました。規制上の事象になるのに、情報漏えいもシステム停止も必要ありませんでした。
• 審査を経ていないAIツールが顧客データに触れると、GLBAと財務省の検査観点で直接的な不備が生じます。一方で2026年の当局共通ガイダンスは、決定論的でルールベースのワークフローをフルスコープのモデルリスク検証の対象から外しています。
• 統制された解決策は、アセスメント、検知、分類、測定可能な3〜5件のワークフローの選定、ガバナンス設計、導入、定着、モニタリングという順序で進みます。検査官が行内だけで経緯をたどれる監査ログも欠かせません。
• 決定論的なワークフロープラットフォームであるJinba Flowなら、オンプレミスで導入でき監査にも対応した承認済みの代替手段を従業員に提供でき、より軽いコンプライアンス上の手続きで済みます。

率直に言えば、受け入れがたい結論です。ブロックによってシャドーAIを止められた銀行はありません。AI利用を全面的に禁じる正式な方針を掲げる金融機関でも、従業員は無料のChatGPTやGeminiのアカウントに顧客データを貼り付けています。禁止しても、従業員がツールを探した理由そのものは消えないからです。消えるのは、承認された選択肢のほうだけです。検知は、露出がすでにどこにあるかを教えてくれます。しかし、それを塞ぐことはできません。塞ぐとは、回避策よりも速い承認済みの手段を従業員に渡すことです。本当の解決策は、ブロック対象ドメインのリストを長くすることではなく、統制されたAIプラットフォームです。

本記事では、シャドーAIとは何か、なぜ銀行ではそのリスクがより鋭い形で表れるのか、どの規制に関わるのか、どう検知するのか、そして従業員が実際に使う統制されたプラットフォームにどう置き換えるのかを解説します。

シャドーAIとは何か（シャドーITとの違い）

シャドーAIとは、従業員が承認されていないAIツールを業務に使うことです。悪意がなくても成立する内部脅威の経路です。調達や情報セキュリティのレビューを通さずに社員が未承認のソフトウェアを使う、従来のシャドーITの一部でもあります。ただし、データ漏えいのリスクははるかに鋭いものになります。やり取りそのものが露出だからです。ChatGPTやClaude、Geminiの無料の個人アカウントに機密データが貼り付けられる。融資担当者が与信ファイルを要約する。コンプライアンス担当のアナリストが疑わしい取引の届出の記述案を作る。審査担当者が申込者データの表計算ファイルの整形をチャットボットに頼む。こうした場面です。

シャドーITといえば、多くは経費精算に載る未承認のSaaS契約を指します。シャドーAIが意味するのは、非公開の顧客情報がすでに行外に出て、誰も内容を確認していない条件のもとで第三者に処理され、しかも銀行からは見えないモデルの学習用に保持されていることさえある、という事態です。露出の性質そのものが違うのであって、同じ問題が大きくなっただけではありません。シャドーAIを従来のシャドーIT対策の一項目として扱うと、必ずその緊急度を見誤ります。

なぜ銀行がシャドーAIの震源地なのか

チャットボットに文章を貼り付ける従業員は、どの業界にもいます。銀行が違うのは、その習慣が初日から規制上の事象になる点です。貼り付けられるデータ（氏名、社会保障番号（SSN）、生年月日、取引履歴、与信ファイル）は非公開の顧客情報です。これを失えば、証券関連法や州の情報漏えい通知法に基づく義務が発生します。マーケティング会社や小売業者が同じ形で負うことはない義務です。

参考になるのは、社名の分かっている実例です。Community Bank（CBFV）は2026年5月7日、Form 8-K Item 1.05に基づき、重要なサイバーセキュリティインシデントをSECに届け出ました。許可されていないAIアプリケーションを通じて、非公開の顧客情報（氏名、SSN、生年月日）が行内で処理されたためです。業務の停止はありません。ランサムウェアも、システム障害も、詐欺被害もありません。それでも同行は、発見から2日以内にこのインシデントを重要と判断しました。その後の対応も規制当局が想定する型どおりです。外部のサイバーセキュリティ専門家の起用、連邦法および州法に基づく顧客への通知、当局への説明、そして事後の統制強化です。従業員1人、未承認のツール1つ、そしてSECへの公開届出1件。これがシャドーAIを黙認することの実際のコストです。資料の中の抽象的なリスク項目ではありません。

2つ目の理由は構造的なものです。AIの導入を拒む金融機関でもシャドーAIは生じます。方針にかかわらず、従業員が自分の判断で動くからです。「うちではAIは使わない」という姿勢は露出を防ぎません。誰も手を伸ばせる承認済みの代替手段がないため、どこで起きているのかが見えなくなるだけです。

銀行におけるシャドーAIはどの規制に抵触するのか

最も明確で差し迫った露出は、グラム・リーチ・ブライリー法（GLBA）のセーフガード規則に関わるものです。GLBAのもとでは、顧客データに触れるAIツールはすべてサービスプロバイダーとして評価しなければなりません。つまり、そのツールが顧客情報に触れる前に、文書化されたセキュリティ評価と、書面によるデータ取り扱い条件が必要になります。調達部門が知らないまま使われている無料の消費者向けAIアカウントは、そのどちらも経ていません。審査を経ていないシャドーAIは、GLBA上の明確な不備です。漠然とした情報セキュリティ上の懸念ではなく、条文が特定できる規制上の不適合です。

その上に重なるのが、米財務省が2024年12月に公表した金融サービスにおける人工知能に関する報告書です。100を超える関係者の意見を踏まえたもので、第三者提供および生成AIの文脈でデータプライバシー、品質、セキュリティの基準を強化するよう求め、中小規模の金融機関で第三者依存のリスクが高まっていることを指摘しています。こうした機関ほど、AIガバナンスの専任機能を備えていない傾向があります。

対応策を組み立てる前に、もう1点押さえておくべきことがあります。すべてのAIツールが規制上同じ重さを持つわけではなく、その違いが何を作るべきかを左右します。

承認済みのCopilotそれ自体がシャドーAIのリスクになるのか

この点はシャドーAIの解説で省かれがちですが、銀行が対応策をどう設計するかを決める要素です。大規模言語モデルのツールを承認すること（融資担当者に法人向けのCopilotやチャットアシスタントを展開すること）だけで、ガバナンスの課題が自動的に片づくわけではありません。問題の場所が境界の内側に移るだけです。

当局共通のモデルリスク管理ガイダンスは2026年4月17日に全面改訂されました。SR 26-2とOCC Bulletin 2026-13が長らく使われてきたSR 11-7に取って代わっており、AI関連の文書がいまだに旧レターを引用している銀行は、古い枠組みで作業していることになります。改訂版のうち、ここで重要になる適用除外は2つです。ベンダーとの商談では、少なくともどちらか一方が見落とされています。

第1に、「モデル」の定義が狭くなりました。現在の定義が対象とするのは、統計学、経済学、金融理論を適用して定量的な推計値を出す複雑な定量的手法だけです。単純な算術計算、決定論的なルールベースの処理、そしてそうした理論的裏づけを持たないソフトウェアは、明示的に除外されています。ルールベースのワークフローツールは、そもそもモデルの定義の外側にあります。第2に、ガイダンスは生成AIおよびエージェント型AIについて「新しく、急速に進化している」ため「本ガイダンスの対象範囲には含まれない」と明記しています。対象外であることは、ガバナンスが不要という意味ではありません。これらのシステムには並行する枠組みが必要で、一般的にはNISTのAIリスクマネジメントフレームワークが使われます。ただし、SR 26-2に基づくフルスコープのモデルリスク検証を自動的に負うわけではありません。

Bridgeforceは、この点を端的にこう述べています。AIの用途が助言的な作業（要約や下書き）から、業務上・エージェント的な作業（ファイルの振り分けや処理の実行）へ移ると、必要な統制の水準が上がり、ガバナンスは暗黙の前提ではなく明示的なものにしなければならない、と。「メールの下書きを手伝う」から「どのファイルをエスカレーションするかを判断する」へと適用範囲が静かに広がったツールは、承認済みかどうかにかかわらず、当初の統制レビューの範囲を超えています。

この区別は、「統制されたプラットフォームの導入」が数年がかりのモデルリスク対応プロジェクトに聞こえる、という反論への最も実務的な答えになります。決定論的なルールベースの実行を土台にしたプラットフォームは、定義上モデルリスク検証を避けられます。固定された監査可能なルールが生み出すのは、確率的な推計値ではなく一貫した出力だからです。確率的なLLMの導入は生成AIの適用除外に該当します。モデルリスク検証は自動的には求められませんが、別途ガバナンス上の義務が生じます。多くの銀行にとって、承認を得やすいのは決定論的な道筋です。

シャドーAIを検知し、防ぐ手順

まず検知が先です。見えないものはガバナンスの対象にできませんし、使われていることを知らないツールの代替を設計することもできません。ただし検知は一連の流れの第1歩であって、到達点ではありません。これをゴールと取り違えることが、銀行のAI施策で最もよくある失敗です。

ステップ1：生成AIの正式なリスクアセスメントを実施する。銀行側のアセスメントは、露出の全体的な印象ではなく、3つの具体的な成果物を出すべきです。実際にレビューした統制とリスクをまとめたワークブック、発見事項と提言をまとめた経営層向けレポート、そして今後の安全で法令に沿った生成AIの利用を定めるポリシーのひな形です。構成は7つの対応領域に沿って整理します。AIポリシー、脅威環境、ベンダー管理、データ統制、AIモデル管理、システムの復旧力、コンプライアンスです。この構成は、NISTのAIリスクマネジメントフレームワーク、Microsoftのガイダンス、そして前述の財務省報告書に基づいています。

ステップ2：一般的なITリスクではなく、生成AI固有のリスク分類を整理する。NISTの生成AIプロファイル（NIST AI 600-1、2024年7月）は、この分野に固有のリスクとしてハルシネーション、データ漏えい、プロンプトインジェクションを挙げています。そのうえで、AIリスクマネジメントフレームワークの4つの機能（Govern（統治）、Map（マッピング）、Measure（測定）、Manage（管理））をこれらに適用できるよう拡張しています。ここが、シャドーAIを「また未承認アプリが増えた」と捉えるチームと、チャットボットが学習データを漏らすことはフィッシングで盗まれた認証情報とは別種の失敗だと理解しているチームとの差です。

ステップ3：従業員がすでに使っている先を洗い出す。ここが実務上の検知レイヤーです。従業員がどのAIドメインにどれくらいの頻度でアクセスしているかを、ネットワークとエンドポイントで可視化します。アセスメントに必要な証拠ではありますが、それだけでは違反の一覧が出てくるだけで、解決にはなりません。ここで止まる銀行は、問題が起きる様子を眺めるための高価な仕組みを作ったにすぎません。

ステップ4：検査官が実際に求めるファイル単位の監査証跡を用意する。2026年の検査対応で問われるのは6点です。分類、検証、モニタリング、ガバナンス、ベンダー管理、そして人による確認と判断の上書きを残すファイル単位の監査証跡です。検査官が求めるのは、ベンダーに問い合わせなくても1件ごとの判断の経緯をたどれる記録です。これは通常のベンダーリスクの問いを裏返します。「そのベンダーは信頼できるか」ではなく、「そのツールは、検査官が行外に問い合わせずに済むほど詳細な監査ログを出せるか」になります。この1問だけで、たいていのRFPのチェックリストより多くのベンダーがふるい落とされます。

ステップ5：金融機関の規模に応じて対応の水準を調整する。コミュニティバンク（小規模な地域金融機関）には、OCC Bulletin 2025-26のもとでリスクに応じた扱いが認められています。検証の頻度と範囲はリスクに基づいて決まり、年次のフルスコープ検証が自動的に求められるわけではありません。アナリスト支援型のワークフローを回している地方銀行に、メガバンク並みのモデルリスク管理プログラムを載せる必要はありません。ガバナンスの作り込みすぎにもコストがあり、銀行が身の丈に合った対応ではなく一律禁止に流れる理由の1つでもあります。禁止のほうが書き下ろす手間は少ないからです。それでも、効果はありません。

検知とアセスメントを合わせれば、露出がどこにあり、コンプライアンス上の義務がどれくらいの大きさかは分かります。分からないのは、ChatGPTにファイルを貼り付けていた融資担当者が、明日の朝から代わりに何をすればよいのかです。

AIツールのブロックが効かない理由

従業員をChatGPTに向かわせた動機は、情報システム部門がドメインをブロックしても消えないからです。与信ファイルは依然として要約が必要ですし、コンプライアンス上の記述にも初稿が要ります。従業員はスマートフォンや私物のノートPC、あるいはファイアウォールがまだ捕捉していない別のツールを見つけます。AIの導入を拒む銀行でもシャドーAIは生じます。従業員が自分の判断で動くからです。禁止が変えるのは露出が起きる場所であって、起きるかどうかではありません。

英国の規制当局のデータも参考になります。英国金融行為規制機構（FCA）とイングランド銀行の調査では、英国の金融機関の75%がすでにAIを利用しており、84%がAIへの取り組みについて責任の所在を定めていました。導入が統制に先行しています。多くの銀行が実際に管理しているのは、従業員がAIを使うかどうか（すでに使っています）ではなく、その利用が見えていて、レビューされ、ガバナンスの対象になっているかどうかです。ブロック一辺倒の方針は、導入の可否がまだ議論の余地があるかのように振る舞います。実際にはそうではありません。

ブロックが必要そのものを取り除けない以上、隙間を埋める唯一の方法は、回避策を選ぶ意味がなくなるほど速く、承認済みの代替手段を従業員に渡すことです。それは分厚いポリシー文書ではなく、統制されたAIプラットフォームです。

生産性を落とさずにシャドーAIを減らす

現在の銀行向けコンプライアンスガイダンスが言う「統制されたAI」とは、重要なAIのユースケースを稼働させる前に、責任者の指名、レビュー経路の定義、継続的なモニタリング、失敗時の代替手段、そして安全に動作していることを示す文書化された証拠がそろっている状態を指します。解決の軸を、ブロックされた経路ではなく承認された経路に置き換える考え方です。具体的な利点は、すでに責任者と文書がそろっているユースケースの承認が速くなること、そして内部監査、取締役会、検査官に示せる証拠が厚くなることです。

統制されたプラットフォームを支える運営モデルは4つの要素からなります。金融サービス業でのAI導入が実際にどう組み立てられているかに基づくものです。第1に、各ワークフローの業務上の成果について、技術的な機能だけでなく事業部門の責任者が説明責任を負います。第2に、コンプライアンスとリスクのレビュー担当者は、稼働後に呼ばれるのではなく、定められたチェックポイントに配置され、エスカレーションの経路も明確になっています。第3に、モデルとデータの管理者が、テスト、モニタリング、変更管理を継続的に担います。第4に、ヒューマン・イン・ザ・ループの基準が、何を、誰が、どの頻度で確認するのかを定めます。「どこかで人が見ている」という曖昧な保証ではありません。

ゼロから統制されたプラットフォームに至るのに、先に行内システムを刷新する必要はありません。すでにあるデータ連携、接続点、ログを改善する選択的な近代化のほうが、大がかりなインフラ刷新を待つよりも稼働までの時間を大幅に縮められます。着手は小さく順を追って進めます。全社一斉の展開ではなく、測定可能なワークフローを3〜5件選び、成功の定義は業務の言葉（処理時間、1件あたりの対応コスト、不良率、ロールレート、例外件数）で置きます。データサイエンスチーム以外の誰も評価できない曖昧な「モデル精度」の目標ではありません。

ここで、決定論的でルールベースのワークフロープラットフォームが、汎用のチャットアシスタントより適していると言える理由が出てきます。ルールベースの処理は2026年のモデルの定義の外側にあるため、そのアーキテクチャで作られた統制されたプラットフォームは、確率的なLLMよりも軽いコンプライアンス上の手続きで済みます。1年がかりのレビューを待つのではなく、数か月のうちに承認済みのツールを従業員に届けたい銀行にとって、これは構造上の優位です。「統制されたプラットフォームを導入する」が、長期のITプロジェクトの言い換えではなく現実的な近い将来の答えになるのも、そのためです。

ここで役に立つのが、この用途のために作られたプラットフォームJinbaです。JinbaはSOC 2 Type IIに準拠した、Y Combinator出資の規制業種向けワークフロービルダーで、そのアーキテクチャは設計段階から決定論的です。1つのワークフローのおよそ80%は、確率的な生成ではなく、固定された監査可能なルールで動きます。2026年4月の定義見直しが「モデル」としての負担から外したのは、まさにこの領域です。外部遮断環境を必要とする銀行向けにオンプレミスで導入でき、検査官が求める統制も標準で備えています。監査ログ、ロールベースのアクセス制御（RBAC）、シングルサインオン、Active Directory連携です。試験導入のあとに付け足すアドオンではありません。

シャドーAI対策で最も重要なのは、Jinbaが個人の生産性ツールではなくチームのためのプラットフォームだという点です。個人のChatGPTアカウントを使う融資担当者は一人で作業しており、その内容は誰にも見えません。AnthropicのClaude Coworkも、銀行が承認した場合であっても、個人のノートPCのためのAIであることに変わりはありません。Anthropic自身のドキュメントにも、監査ログがなく、規制対象の業務向けには作られていないと記されています。Jinbaは反対の前提に立っています。Jinba Flowは、技術者や準技術者のチームがワークフローを一度だけ作る場所です。たとえばKYC書類チェック、融資審査のレビュー、コンプライアンスのエスカレーション経路などです。Jinba Appは、残りの業務チームがその承認済みワークフローを、チャットインターフェースと自動生成されたフォームから実行する場所で、権限とログは常に紐づいています。この共有された権限管理付きのレイヤーこそが、「承認済みの手段を従業員に渡す」への本当の答えです。何百人もの従業員がそれぞれ自分でツールを見つけるのではなく、レビュー済みのワークフロー1本を何百人もが使えるようにします。

これは前述のガバナンスの手順を置き換えるものではありません。プラットフォームのガバナンスの水準は、その周りにあるレビュー経路、責任の所在、モニタリングの水準までです。運営モデルが先にあり、ツールはそれを実行します。

ポリシー、教育、承認済みツールへのアクセス

ポリシーはプラットフォームの展開とは別物ではありません。ワークブックと経営層向けレポートと並んで、リスクアセスメントが出すべき3つの成果物の1つです。ポリシーのひな形が役割を果たすのは、責任者の指名、レビュー担当者の設定、変更管理を担う管理者とセットになったときだけです。それが、署名後に誰も読まない文書ではなく、実務としての前述の運営モデルです。

承認済みツールに関する従業員教育と定着は、コンプライアンスの通達ではなく製品のローンチとして扱うべきです。チームがそのツールで実際に何をするかに沿った役割別の研修。日々使う人が、回避策に変わる前に使いにくさを申告できるフィードバックの仕組み。そしてワークフローの成功を定義したのと同じ業務の言葉（処理時間、例外件数、不良率）に照らしたKPIの測定です。承認済みのプラットフォームを展開しただけで、従来の回避策の代わりに使われているかを測らない銀行は、シャドーAIの問題を解決していません。環境にツールを1つ増やしただけです。

ガバナンスから導入までのテンプレート

銀行がそのまま使える、最初から最後までの順序です。

各フェーズは、検査官が提出を求める文書を生み出します。統制された展開は、ツールが動き出した時点では完了していません。その裏づけとなる記録がワークフローそのものと同じだけ強くなって、はじめて完了します。

トラブルシューティング：展開が止まったとき

承認済みのツールが回避策より遅い。プラットフォームの稼働後に従業員が黙ってChatGPTに戻っているなら、ワークフローの範囲が広すぎたか、チームが実際に扱う入力の形式に合っていなかった可能性が高いです。フェーズ4で選んだ測定可能な3〜5件のワークフローまで範囲を絞り直し、実際に使われている書類の種類に合わせて作り直してください。

コンプライアンスの承認に、フルスコープのモデルリスク検証と同じだけ時間がかかっている。フェーズ3の分類を確認してください。ワークフローが決定論的でルールベースであれば、レビュー担当者が旧SR 11-7の基準の習慣から、フルスコープの「モデル」と誤って分類している可能性があります。レビューの工程をもう1つ増やす前に、現行の定義に照らして分類を見直してください。

定着の指標に利用は表れているが、習慣にはなっていない。研修で一度使われただけで放置されたワークフローは、たいていKPIのベースラインがチームに伝わっていません。フィードバックの仕組みは、定着が止まってからではなく、初週から組み込んでください。

監査ログはあるが、判断の経緯をたどれない。ツールが使われたことは分かっても、何が確認され、誰が確認し、どの判断が上書きされたのかが分からない記録では、ベンダーに問い合わせずに1件の経緯をたどろうとする検査官を満足させられません。これはツールの不足ではなく、フェーズ5のヒューマン・イン・ザ・ループの基準の抜けです。ワークフローの設計段階で直してください。

よくある質問

個人デバイスからのアクセスを遮断すればシャドーAIは解決するのか。いいえ。デバイスの制限は入口を1つ塞ぎますが、管理下の端末に承認済みの手段がなければ、個人のスマートフォンや自宅のノートPC、管理外のブラウザタブに逃げます。仕事を終わらせたいという根本の必要は、どんなアクセス制限よりも長く残ります。

承認済みのAIチャットボットで十分なのか、それとも本格的なワークフロープラットフォームが必要なのか。承認済みのチャットボットは個人アカウントによる露出そのものは減らしますが、それだけではガバナンスの隙間は埋まりません。AIの用途が下書きから、振り分けや処理の実行といった業務そのものへ移るにつれて必要な統制の水準は上がり、監査ログもワークフロー単位のレビューのチェックポイントも標準で持たない汎用のチャットツールでは追いつけません。詳しくは、AIコンプライアンスツールの比較と銀行業務向けAIワークフローツールをご覧ください。

情報システム部門、コンプライアンス、事業部門のうち、シャドーAIへの対応は誰が担うべきか。1つの部署が背負うものではありません。事業部門の責任者が業務上の成果に説明責任を負い、コンプライアンスとリスクのレビュー担当者が定められたチェックポイントに入り、モデルとデータの管理者がテストとモニタリングを担います。情報システム部門だけが所有するツールは、規制上のレビューが抜けます。コンプライアンスだけが所有するツールは、実際に使われているかどうかが抜けます。

統制されたAIプラットフォームの展開は、フルスコープのモデルリスク対応と比べてどれくらいの期間がかかるのか。ルールベースのワークフローツールは現行のモデルの定義の外にあるため、そのアーキテクチャで作られたプラットフォームは、汎用のLLMの導入よりもはるかに速くレビューを通ります。コミュニティバンクにはOCC Bulletin 2025-26のもとでさらに余地があり、リスクの低いアナリスト支援型のユースケースには年次のフルスコープ検証が求められません。

何もせず、シャドーAIが広がらないことを期待した銀行はどうなるのか。Community Bankの事例がすでに記録に残っています。許可されていないAIアプリケーション1つが非公開の顧客情報を処理したことが、発見から2日以内に重要なサイバーセキュリティインシデントと判断され、SECへの届出、顧客への通知、規制当局とのやり取りにつながりました。この重要性の基準に達するのに、詐欺被害も業務停止も必要ありませんでした。何もしなければ露出が見えないままになる、ということはありません。銀行が自行のガバナンス体制からではなく、規制当局から知らされるようになるだけです。着手する準備が整っている銀行にとっては、無料のAI戦略アセスメントが最も早い第一歩です。