銀行におけるシャドーAI：検知・統制・置き換えの進め方

要約

• FINRAの2025年ガイダンスは、未承認の生成AI利用、すなわち無料のチャットボット、ブラウザ拡張機能、ベンダーツールに開示されないまま組み込まれたAI機能を、単なるIT部門の課題ではなく、サイバーセキュリティと監督上のリスクとして扱っています。
• シャドーAIのリスクは階層によって異なります。顧客データに触れるコンシューマー向けツールは禁止すべき水準のリスクを抱え、エンタープライズSaaSのAIはベンダーへの開示確認と契約上の統制が必要で、API接続型のツールには技術的な検知が求められます。
• 実効性のあるプログラムは、次の3つのステップを順に実行します。OAuth、エンドポイント、ネットワークのテレメトリーを横断して実際のAI利用を検知すること、AIの正式な定義と階層別ポリシーで統制すること、そして統制されていないツールを承認済みの代替手段に置き換えることです。
• AIインベントリの定期的な更新と、ベンダーの生成AI開示に関する契約条項は、一度きりの監査タスクではなく、不可欠な統制です。
• 監査可能でオンプレミスの代替手段を必要とする銀行には、Jinba Flowが権限管理された共有ワークフローを提供します。規制産業の企業向けに、ロールベースのアクセス制御（RBAC）、SSO、監査ログを組み込んでいます。

銀行におけるシャドーAIは、遠い将来のリスクではありません。要約を作らせるために借り手の財務情報を無料のチャットボットに貼り付ける融資事務チームの中に、社内規程の調査を手早く済ませようと個人のAIアカウントを使うコンプライアンス担当アナリストの中に、そしてIT部門が承認していないブラウザ拡張機能で顧客とのやり取りを処理するリレーションシップマネージャーの中に、すでに存在しています。これらはベンダー管理台帳にはいっさい現れません。それでいてFINRAの2025年ガイダンスにより、そのすべてが監督の対象範囲に入りました。

検査に耐える予防のフレームワークは、次の3つのステップを順に踏みます。第一に検知。実際に何が動いているのかを把握します。第二に統制。実際の業務に触れても機能する階層別ポリシーで管理します。第三に置き換え。空白が指摘事項になる前に、統制されていないツールを承認済みの代替手段へ切り替えます。本記事では各ステップを順に解説し、対応範囲を定めるためのリスク階層表を示したうえで、リスク部門やコンプライアンス部門がそのまま応用できるテンプレートで締めくくります。

シャドーAIとは何か、シャドーITと何が違うのか。

シャドーITは、より古くからある馴染みの問題です。承認を待つより速いという理由で、従業員が調達部門を通さずにファイル共有アカウントやプロジェクト管理ツールを立ち上げてしまいます。資産としては未承認ですが、その振る舞いはおおむね予測できます。データを保管するか、データを移動させるかのどちらかだからです。

シャドーAIの根本原因はこれと同じで、承認された経路より速いという点にありますが、リスクの性質は大きく異なります。生成AIツールは、従業員が入力したデータを保管するだけではありません。そのデータを取り込み、保持し、場合によっては公開モデルの改善に利用することがあります。FINRAの2025年次規制監督報告書はこの点を明示しています。コンシューマー向け生成AIツールに送られたプロンプトは、顧客の個人識別情報（PII）や自社の機密情報が流出する経路であり、その流出は、自社のプログラムで対処すべきサイバーセキュリティリスクとして扱われます。そのAI利用が会社の承認を受けたものか、従業員個人が選んだツールかは問われません。

銀行にとって、この違いは机上の議論ではありません。シャドーITはデータ侵害のリスクを生みます。シャドーAIはデータ侵害に加えて監督の不備というリスクまで生みます。リスク評価も記録もされず、自社のモデルリスク管理プログラムにも組み込まれていないAIのユースケースが、本番環境で稼働していることになるからです。

何がシャドーAIに当たるのか、その範囲はどこまで及ぶのか。

シャドーAIとは、銀行のデータや業務プロセスに関わる生成AI利用のうち、自社のAIガバナンスプログラムを通じて審査・承認・記録されていないものすべてを指します。その範囲は、多くのリスク部門が想定しているより広く、次のものが含まれます。

• 業務内容の下書き作成、要約、調査に使われるコンシューマー向けチャットボット（個人アカウントや無料プランのアカウント）。
• 正式なベンダー審査を経ずに、メール、文書エディタ、CRMツールにAI機能を組み込むブラウザ拡張機能やプラグイン。
• 承認済みのSaaSプラットフォームの内側で、いつの間にか有効化されたAI機能。たとえば、ベンダーが重要な変更として告知しなかったソフトウェア更新によって、電子署名ツールやCRMにAI要約機能が追加されるケース。
• 開発者や「市民開発者」であるビジネスアナリストが、表計算マクロや社内スクリプトから大規模言語モデルを直接呼び出すために使う個人のAPIキー。
• ベンダーによる再委託処理。銀行がすでに契約している第三者ツールが、内部に生成AIの層をひそかに組み込んでいるケース。

この最後の類型があるからこそ、FINRAのベンダーリスクに関するガイダンスは、企業に対して自ら進んで第三者ベンダーに生成AIを組み込んでいるかどうかを確認するよう求め、さらに自社や顧客の機密情報がベンダーのオープンソース生成AIツールに取り込まれることを禁じるよう、契約文言の更新を指示しています。従業員が誰一人としてシャドーAIを意図的に使っていない銀行でも、ベンダーが開示していないモデル統合を通じて、シャドーAIのリスクを抱えることがあります。

シャドーAIが単なるIT問題ではなく監督上の問題である理由

多くの銀行はまず、シャドーAIを利用規程違反としてITセキュリティ部門に回そうとします。しかしそれでは、リスクを実際より小さく見積もることになります。FINRAの規則は技術中立であり、規則3110（監督）は、監督体制に生成AIを用いる企業に対して、すでにテクノロジーガバナンス、データのプライバシーと完全性、AIモデルの信頼性を対象とする方針と手続きの整備を求めています。AIを自社で構築した場合でも、第三者ツールを利用している場合でも同じです。

FINRAは、この監督が全社レベルと個々の従業員レベルの双方で機能することを求めています。この2つ目の層こそ、シャドーAIを規制に直接結びつける部分です。監督者は、会社が審査した導入案件だけでなく、従業員による未承認のツール利用まで対象に含めることが期待されます。検査官が照会を始めるために、統制を外れた全社規模のAIプロジェクトを見つける必要はありません。業務に使われているアナリスト個人のチャットボットアカウントも、同じ監督義務の範囲に入ります。

AIについて正式で一貫した社内定義を持つことが、字面以上に重要なのもこのためです。FINRAは企業に対して、社内向けにも社外向けにも通用する定義を作成するよう助言しています。各事業部門が自らの利用状況を報告する際に、「AI」という言葉をそれぞれ違う意味で解釈しないようにするためです。共通の定義がなければ、銀行は検査官が最初に投げかける問いに正直に答えられません。ここではどのAIが動いているのか、そしてなぜそう言い切れるのか。

シャドーAIのリスク階層表

未承認のAI利用が、すべて同じリスクを抱えているわけではありません。一律に扱えば、リスクの低い業務を過剰に制限するか、本当に危険なケースを統制しきれないかのどちらかになります。FINRAの階層型ガバナンスモデルは、その拠り所となる構造を示しています。重いコンプライアンス審査を要しない低リスクのユースケース、禁止すべきユースケース、リスク低減策の文書化が必要なケース、本番環境で継続的に追跡すべき高リスクのケースという、4つの区分に分ける考え方です。

この4区分の構造に重ねて、シャドーAIの範囲をツールが銀行のデータにどう触れるかという観点で切り分けるなら、コンシューマー向けツール、エンタープライズSaaSツール、API接続型の連携という3つに分ける方法が実務的です。この階層モデルは、FINRAの階層別審査の考え方の上に組み立てた運用向けの整理であり、FINRAが公表した区分そのものではありません。

この表の目的は、点数付けそのものではなく、優先順位の切り分けです。顧客のNPIに触れるコンシューマー階層のユースケースは、自動的に禁止利用の指摘対象とすべきです。一方、顧客データを含まない社内議事録の整形など、実質的にリスクの低い処理を行うAPI接続型の社内ツールは、FINRAがAIインベントリへの記録すら不要としている低リスクの区分に置いて構いません。階層分けがあるのは、ガバナンスの労力を、実際にリスクのある場所へ振り向けるためです。

ステップ1：検知（誰かに指摘される前にAIインベントリを作る）

検知のステップがあるのは、見えないものは統制できないからです。そして現状、ほとんどの銀行は自社のAI利用の大半を把握できていません。フレームワークの中で最も地味な工程であり、先にポリシー文書を書くことを優先して飛ばされがちですが、それは順序が逆です。検知の仕組みを伴わないポリシーは、統制ではなく意思表明にすぎません。

検知は、3つの技術的な領域にまたがって行います。

OAuthとSSOの監査。コンシューマー向けとエンタープライズ向けのAIツールの多くは、「Googleでサインイン」「Microsoftでサインイン」という流れで導入されます。自社のIDプロバイダーに対するOAuth許可の一覧を確認すれば、従業員が会社の認証情報でどのAIツールに接続したかが浮かび上がります。検知の第一段階としては、最も速く安価な手段であることが多い方法です。

ブラウザとエンドポイントのテレメトリー。拡張機能の一覧やエンドポイント検知ツールを使えば、OAuthの流れをまったく経由していないAIブラウザ拡張機能やデスクトップクライアントを洗い出せます。OAuth監査では見落とす、個人アカウントによるチャットボット利用がこれに当たります。

ネットワークとAPI呼び出しのテレメトリー。API接続型の階層では、既知のモデル提供事業者のエンドポイント宛ての外向き通信を確認する必要があります。どの管理コンソールにも現れない可能性が最も高いのが、この類型だからです。開発者や市民開発者のアナリストがスクリプトからモデルを直接呼び出しても、SaaS側には痕跡がいっさい残りません。

このステップの成果物がAIインベントリそのものであり、FINRAがガバナンスプログラムの土台として繰り返し言及している文書です。洗い出したユースケースは、上の階層表とFINRAの4区分の両方に照らして分類します。低リスク（記録はするが詳細な審査は不要）、禁止（本番環境に存在しないことを確認済み）、リスク低減済み（リスクと統制を文書化）、高リスク（本番稼働中は継続的に追跡）の4つです。抜けのあるインベントリは、本来カバーすべきユースケースを監督プログラムが捉えられていないことを、銀行自身が記録として残す証拠になります。ガバナンスの統制が実際の業務プロセスとどう対応するかを詳しく見るには、当社のAIワークフローガバナンス実践ガイドをご覧ください。

ステップ2：統制（安全な活用を可能にする階層別ポリシーを作る）

インベントリができたら、ガバナンスは「これが見つかった」を「これがリスク判断であり、これが統制だ」に変える工程になります。一律のポリシーを1本書こうとする発想は、AIを全面禁止するにせよ、どこでも許可するにせよ、どちらの方向でも行き詰まります。全面禁止は、FINRAが重い審査を不要としている本当に低リスクな用途まで閉ざしてしまい、せっかくの階層分けを無駄にします。全面許可は、検知で見つかったものの中に、そもそも禁止区分に入れるべきものがあるという事実を無視しています。

ガバナンスのステップを適切に行うと、3つの成果物が生まれます。

AIの正式な定義。社内ポリシーと社外開示で一貫させ、トレーディングデスクにとっても、マーケティング部門にとっても、公開資料を読む検査官にとっても「AI」が同じ意味になるようにします。FINRAは、とくにマーケティングにおけるAI関連開示の正確さを、検査官が実際に提出を求めうるガバナンス上の成果物として明示しています。

リスクと低減策の文書。明らかに低リスクとも明らかに禁止とも言えないすべてのユースケースについて作成します。エンタープライズSaaSとAPI接続型の階層は、ここで最も多くの検討を要します。そのユースケースはどのデータに触れるのか、保持とアクセスにどのような統制があるのか、失敗した場合に何が起きるのか。こうした統制を立ち上げる銀行や信用組合は、多くの場合、エンタープライズ向けコンプライアンス自動化ツールと組み合わせて導入します。この種のツールには、監査ログとロールベースのアクセス制御があらかじめ備わっています。

監督範囲の拡張。個々の従業員のレベルまで広げます。FINRAの監督上の期待は、会社が承認した導入案件だけでなく、従業員による未承認のツール利用にも明示的に及ぶからです。実務上これは、ポリシーに実効性のある仕組みが必要だという意味になります。顧客データにアクセスできる担当者に対して既知のコンシューマー向けAIドメインを技術的に遮断すること、そして検知によって現場で新しいツールが見つかったときの明確なエスカレーション経路を用意することであり、署名済みの同意書だけでは足りません。

ベンダーに関する論点も、このステップに属します。生成AIを組み込んでいるかをベンダーに確認し、機密データがベンダーのオープンソースツールに取り込まれることを禁じる契約文言を加えるというFINRAのガイダンスは、調達上の対応であると同時に、ガバナンス上の対応でもあります。従業員が機能追加に気づくことを当てにするのではなく、エンタープライズSaaS階層のリスクを契約のレベルで閉じる措置です。

ステップ3：置き換え（統制された代替手段を導入する）

検知と統制は、可視性とポリシーの空白を埋めます。ただしそれだけでは、従業員がそもそも統制外のツールに手を伸ばした理由は消えません。AIを使えば、使わない場合より実際に仕事が速く終わったのです。FINRA自身の市場観測もこれを裏づけています。会員企業は生成AIの活用を慎重に進めており、使う場合も、要約、分析、規程の検索といった社内の効率化業務に、第三者のベンダー提供ツールを通じて用いるのが一般的です。この形こそ、シャドーAIが競合する承認済みの代替手段であり、銀行が事後に気づくのではなく、意図して再現すべきモデルです。

統制された代替手段は、シャドーAIの利用を生んだのと同じ現場の要求、すなわち技術者でない担当者にとっての速さと使いやすさを満たしたうえで、FINRAのガイダンスが求める統制も同時に満たす必要があります。具体的には、監査証跡、ロールベースのアクセス制御、そして理想を言えば、機密データをベンダーの公開モデルではなく自社の環境内にとどめられる導入形態です。オンプレミスが譲れない条件だとすでに判断している企業には、当社の銀行向けオンプレミスLLMプラットフォーム解説が導入の選択肢を整理しています。

フレームワークの中で、規制業務向けに設計された専用プラットフォームが自然な答えになるのが、この段階です。カテゴリー全体をほのめかすより、具体名を挙げて正直に説明する価値があります。銀行を含む規制産業の企業向けに作られたワークフロー自動化プラットフォームであるJinbaは、この空白に合致する選択肢の一つです。ワークフローは技術者または準技術者のチームが一度作り、ロールベースの権限管理、監査ログ、SSO、Active Directory連携、つまり検査官が必ず尋ねる統制を備えたうえで、業務チーム全体で共有されます。個人のアカウントでプロンプトを1件ずつ打つやり方とは対照的です。Jinbaのワークフローは、処理の大半をルールベースのロジックで実行し（Jinbaはこれを約80%の決定論的実行と説明しています）、生成AIは本当に判断が必要な箇所にだけ適用できます。また、データの所在に関する要件から外部モデルへの送信が一切認められない企業のために、オンプレミス導入にも対応しています。共有できること、権限が管理されていること、監査できること、そして自社インフラ内に導入できること。この組み合わせがあってはじめて、ツールの採用は正当な「置き換え」になり、ロゴが大きいだけの別の統制外ツールへの横滑りにならずに済みます。なぜ決定論的なワークフローが監査に耐えるのか、純粋な生成AIエージェントではそうならない理由も含めて、リンク先の記事が監査ログとコストの両面から詳しく論じています。Jinbaは、FINRAが企業の関心はすでにそちらへ向かっていると述べているベンダー提供型のカテゴリーにある選択肢の一つであり、他のベンダーと同じ基準で評価すべきです。すなわち、ガバナンスのステップで作成したリスクと低減策の文書に照らして判断します。

そのまま使えるシャドーAIガバナンスのテンプレート（自由に改変可）

以上の3ステップは、リスク部門やコンプライアンス部門が1回の作業セッションで作成し、そのまま検査に持ち込める1つの文書にまとめられます。盛り込むべき項目は次のとおりです。

1. AIの正式な定義。ポリシー、研修資料、社外開示で一言一句同じ形で使う1文。
2. 検知の記録。OAuthの許可状況、ブラウザとエンドポイントの調査結果、ネットワークテレメトリーの調査結果を、日付と担当者名付きで記載。
3. 階層の分類。見つかったすべてのユースケースを、コンシューマー／エンタープライズSaaS／API接続型の区分と、FINRAの低リスク／禁止／リスク低減済み／高リスクの区分に対応づける。
4. リスクと低減策の記述。低リスクに分類されなかったすべてのユースケースについて、触れるデータと実施中の統制を含めて記載。
5. 禁止利用に関する確認書。禁止対象のユースケースが現在本番環境に存在しないことを、日付入りで確認した記録。
6. ベンダー開示の記録。重要なベンダーごとに、生成AIを組み込んでいるかどうかと、機密データの取り込みを扱う契約条項を記載。
7. 監督責任の割り当て。個々の従業員レベルで誰がAI利用を監督するのか、また未承認のツール利用をどのようにエスカレーションするのか。
8. 置き換えのロードマップ。禁止対象、または現場の負担が大きいシャドー利用のケースごとに、置き換える承認済みツールまたはワークフローと、目標期日を記載。

常に最新の状態に保てば、このテンプレートはFINRAのガイダンスが暗に求めている証跡そのものになります。正式な定義、インベントリ、文書化された禁止利用チェック、そして個人のツール利用まで明示的に及ぶ監督の4点です。

全面禁止は機能するのか、それとも利用を水面下に押しやるだけなのか。

承認済みの代替手段も実効性のある仕組みもない禁止令は、そもそもシャドーAIを生んだ根本的な圧力を取り除きません。AIを使ったほうが仕事が速いという事実は変わらないからです。FINRAの階層型アプローチ自体が、その暗黙の答えになっています。禁止を一律に定めるのではなく、重い審査を要しない低リスクのユースケースと、本当に禁止すべきユースケースを切り分けています。一様な締め出しではなく、リスクの大きさに見合った構造です。社内メモを整形するアナリストと、顧客の口座情報を一般公開のチャットボットに貼り付けるアナリストを区別できないポリシーは、無害なケースを過剰に制限するか、より高い確率で、どちらの場面でも黙って無視されることになります。

長く機能する答えは、本記事が示してきた順序です。実際に何が起きているのかを検知し、FINRA自身のリスク段階モデルに沿った階層で統制し、現場の負担が最も大きい部分を、シャドーAIより自然に選ばれる承認済みツールで置き換える。この3つです。代替手段のない禁止は紙の上のポリシーにすぎず、ガバナンスのない置き換えは、名前が変わっただけで同じ未管理のリスクを抱えた新しいツールにすぎません。

導入時によくあるつまずき

インベントリが古くなる。検知は一度きりの監査ではありません。既存のSaaSツールには新しいAI機能が絶えず追加され、ベンダーの製品更新が正式な告知なしに生成AIを持ち込むこともあります。検知は単発のプロジェクトではなく、定期的に繰り返す運用にする必要があります。

事業部門ごとに階層の当てはめがばらつく。FINRAが推奨する正式なAIの定義がなければ、ある部門の「社内効率化ツール」は別の部門では「監督体制の中のAI」になり、同じユースケースでも誰に聞くかで分類が変わってしまいます。この揺らぎを防ぐのが、文書化された定義です。

置き換えのステップが飛ばされる。ガバナンス部門は、禁止と研修で十分だと考え、ポリシーと取り締まりで止まってしまうことがあります。本当に使える承認済みの代替手段がなければ、速さを求める根本的な需要は消えません。それは、まだ見つかっていない新しいシャドーツールとして再び現れます。

ベンダーへの開示確認を一度きりの質問で済ませる。生成AIを組み込んでいるかを一度尋ねただけでは、将来の製品更新までは押さえられません。機密データの取り込みを禁じる契約文言は、初回の導入審査のときだけでなく、ベンダーの製品変更後も有効であり続ける必要があります。

よくある質問

銀行の文脈で、シャドーITとシャドーAIは何が違うのですか。シャドーITは、調達部門の目が届かないところで行われる、あらゆる技術の未承認利用を指します。シャドーAIはそのうち、未承認のツールがプロンプトのデータを取り込み、場合によっては保持するケースです。FINRAはこれを、単なる資産管理の抜けではなく、独立したサイバーセキュリティおよび監督上のリスクとして扱っています。

承認済みのベンダーツールに内蔵されたAI機能も、シャドーAIに当たりますか。その生成AI機能が銀行に開示されず、審査も受けていないのであれば該当します。承認済みのベンダーとの取引関係が、そのベンダーが後から提供する機能まですべて覆うと考えるのではなく、既存ベンダーに生成AIの組み込みの有無を自ら確認するよう、FINRAのベンダーガイダンスが企業に求めているのはこのためです。

銀行の中で、シャドーAIのリスクに責任を負うのは誰ですか。IT部門、コンプライアンス部門、事業部門のいずれでしょうか。FINRAの規則3110の枠組みでは監督の領域に置かれ、これは通常、コンプライアンス部門とリスク部門の所管です。ただし技術的な検知作業、すなわちOAuth、エンドポイント、ネットワークのテレメトリーの確認には、ITセキュリティ部門のツールが欠かせません。責任者はAIインベントリを所管する部門とし、ITセキュリティ部門は検知の協力者と位置づけるのが妥当です。より広い論点として、どのAIコンプライアンスツールがその所管を実際に支えられるのかも、並行して整理しておく価値があります。

シャドーAIのインシデントが記録された場合、それは自動的に規制違反になりますか。リスクの本質は、単発のインシデントそのものよりも、それを捉えられたはずの監督プログラムが存在しないことにあります。検知・統制・置き換えのサイクルが機能し、インベントリが文書化されている企業は、検査の場で、まったく仕組みのない企業とは大きく異なる立場に立ちます。どちらにも、従業員が未承認のツールを使った時期があったとしても同じです。

AIインベントリはどのくらいの頻度で更新すべきですか。高リスクのユースケースを「本番稼働中」に追跡するというFINRAのガイダンスは、ある時点だけの監査ではなく、継続的な運用を前提としています。少なくともベンダー製品の更新時や新しいツールの導入時には検知を回すという定期的な運用にすることで、インベントリは過去のスナップショットではなく、証拠として使える状態に保たれます。