金融機関のローカルLLM導入。FISC基準・金融庁の考え方と国内事例
金融機関が生成AIをオンプレミスや閉域網に置く判断は、漠然とした不安からではなく、FISC安全対策基準と金融庁の監督スタンスから論理的に導くことができます。結論を先に述べると、規制が求めているのはデータを行内に閉じ込めること自体ではなく、外部委託管理・データ管理・監査証跡・モデルリスク管理という統制であり、それを最も素直に満たせる構成としてオンプレ/閉域網のローカルLLMが選ばれています。本記事では、FISC第14版と金融庁AIディスカッションペーパー第1.1版という2つの一次文書を実装要件に翻訳し、あおぞら銀行・常陽銀行の先行事例と、地銀・信金規模で現実的な構成・導入ロードマップまでを通しで整理します。
この記事の要点
- FISC安全対策基準第14版（2026年3月25日公表）と金融庁AIディスカッションペーパー第1.1版（2026年3月3日公表）は、いずれも「オンプレミスでなければならない」とは書いていません。求めているのは説明責任と統制です
- あおぞら銀行は金融・行内特化のオンプレミス型LLM「あおぞらLLM」で行内ベンチマークの応答精度を従来比130%に高め、常陽銀行は外部から完全に隔離されたオンプレ環境で稟議書自動生成など5業務の実証を進めています
- 現実的な構成は「公開情報系はクラウド法人契約LLM、顧客情報・与信・事務規定はオンプレ/閉域網のローカルLLM」という二層の振り分けです
- 導入はミニ検証→行内PoC→本番の段階制が基本で、リスク管理・監査部門はPoCの設計段階から巻き込む必要があります
金融機関で「とりあえずクラウドAI」が通らない理由
金融機関が扱うデータの機密性は、他業種とは質が違います。顧客情報・与信情報・事務規定には、個人情報保護法に加えて銀行法・監督指針・守秘義務が重なり、与信判断の根拠や事務規定そのものが競争力の中核でもあります。だからこそ、汎用のクラウドSaaSに全社一律で投げる発想には無理があります。
ただし「クラウド全面禁止」も誤解です。金融庁はクラウド利用そのものを否定しておらず、FISCも外部委託・クラウド利用を前提にした管理基準を持っています。生成AIのクラウドサービスにしても、法人契約やAPIでは入力データが学習に使われない契約が主流であり、「クラウドAI＝必ず学習される」と一括りにするのは不正確です。この線引きは「Claudeの法人契約・個人プランでの学習利用の線引き」で整理しています。
問題の本質は、どのデータを、どこで処理し、誰が説明責任を負うかという設計にあります。ここを詰めずに一律クラウドへ振ると、監督上の説明責任と統制が崩れます。逆にここさえ設計できていれば、公開情報系はクラウド、機密情報系はオンプレという振り分けが成立します。
FISC第14版と金融庁AIディスカッションペーパーが求めるもの
金融向けの実装を設計するうえで、根拠となる一次文書は2つあります。FISC（金融情報システムセンター）の「金融機関等コンピュータシステムの安全対策基準・解説書」第14版と、金融庁のAIディスカッションペーパー第1.1版です。
FISC第14版は2026年3月25日に公表され、政府機関・業界団体がAI・生成AIについて公表したガイドラインや報告書を分析し、安全対策の基準項目に反映しています（FISC公表資料）。金融庁のAIディスカッションペーパーは、第1.0版（2025年3月）に続く第1.1版が2026年3月3日に公表され、モデルリスク管理・説明可能性・データ準備や外部委託を主要な論点として整理しています（金融庁 公表ページ）。
これらの文書を「規制文書」のまま読んでも実装には動けません。実装要件に翻訳すると、次の対応になります。
| 規制・指針が求めること | 実装要件への翻訳 |
|---|---|
| 外部委託管理（FISC） | クラウド/ベンダー利用時の責任分界と監査権の確保。学習非利用の契約明記 |
| データ管理（FISC） | 顧客情報・与信情報の保存場所と越境の管理。閉域/オンプレでの保持 |
| システム監査（FISC） | 推論の入出力ログ・アクセス証跡の取得と保管 |
| モデルリスク管理（金融庁DP） | モデルインベントリの整備、本番投入前の検証、継続的な性能監視 |
| 説明可能性（金融庁DP） | 推論過程の文書化と第三者レビュー体制 |
ここで押さえるべき核心が一つあります。いずれの文書も「オンプレミスでなければならない」とは書いていません。求めているのは説明責任と統制であり、オンプレ/閉域網はそれを満たすための手段であって目的ではありません。この順序を取り違えると、統制設計を後回しにして箱だけ作ることになります。
金融機関のローカルLLM国内事例（あおぞら銀行・常陽銀行）
規制の翻訳を実際にやり切った例が、すでに国内に出ています。
あおぞら銀行はneoAIと共同で、金融・行内特化のオンプレミス型LLM「あおぞらLLM」を開発しました（2025年4月）。法人・リテール業務の事務規定管理業務を想定したベンチマークを設計し、破滅的忘却を防ぐ継続事前学習を行うことで、行内ベンチマークの応答精度が従来比130%（従来の約1.3倍）に達したとしています。狙いは、クラウドAPI型では達成不可能な厳格なセキュリティレベルの確保です。数字よりも「行内固有の知識に正しく基づいて答えられるか」を精度の軸に置いている点が重要です（neoAI プレスリリース）。
常陽銀行は、松尾研発のAthena Technologiesと、外部ネットワークから完全に隔離されたオンプレミス環境でローカルLLMの実証を進めています（2025年7月）。対象は次の5業務です。
- 稟議書・報告書等の自動生成
- 類似の過去事例の抽出・比較によるデータ処理の効率化
- 財務・会計の専門文書の日英翻訳
- 文書内の機密情報の自動検出・匿名化
- 融資審査の参考資料の自動生成による審査支援
2つの事例に共通するのは、入口が行内文書のRAGと事務照会の一次回答である点です。ゼロから何かを創作させるのではなく、行内に蓄積された文書資産を検索・要約・照会する用途から始め、生成の華やかさよりも行内知識への正確な接地を評価しています。事例を横断して見える共通パターンは『ローカルLLM国内導入事例2026。8社から見える共通パターン』で詳しく扱っています。
金融向けローカルLLMの典型構成（閉域網・RAG・監査ログの4層）
先行事例の構成を一般化すると、金融向けは次のレイヤーに落ち着きます。図解にすると4層です。
- 行内ネットワーク/閉域網（外部から隔離）
- 推論基盤: オンプレGPUサーバ、またはVPC・専用線で閉じたクラウド閉域網
- RAG基盤: ベクトルDB＋行内文書（事務規定・過去事例・審査資料）
- 認証・アクセス制御・監査ログ層
そのうえで、全部をオンプレに寄せる必要はありません。データの機密性で処理場所を振り分ける二層構造が現実的です。
| データ区分 | 処理場所 | 用途の例 |
|---|---|---|
| 公開情報・一般業務 | クラウド法人契約LLM（学習非利用・監査ログ確保） | 市場情報の要約、社内向け一般調査、定型文の下書き |
| 顧客情報・与信・事務規定 | オンプレ/閉域網のローカルLLM | 融資審査の参考資料、事務照会、行内規定のQA |
設計で落としてはいけないのが、ログ・監査証跡・アクセス制御です。具体的には次の4点です。
- 推論の入出力ログの保管（誰がいつ何を尋ね、何が返ったか）
- プロンプト・出力に含まれる機密の検出とマスキング（常陽銀行の事例で機能化されている領域です）
- ロールベースのアクセス制御（部門・役職単位で参照範囲を絞る）
- モデル更新の検証記録（モデルインベントリと本番投入前の検証ログ）
これらは金融庁DPのモデルリスク管理・説明可能性の要請にそのまま対応します。統制の証跡を後から作ることは難しいため、最初から証跡が出力される設計にすることが要点です。
なお、規制・ガイドラインが処理場所を規定するという構図は金融に限りません。同じ論点の業種別の整理は『医療機関のローカルLLM。3省2ガイドラインと院内オンプレAIの現在地』、『自治体のローカルLLM。LGWAN閉域・DS-920・「源内」から読む現実解』で扱っています。
費用と導入ロードマップ（ミニ検証→行内PoC→本番）
費用レンジは規模で大きく変わり、地銀と信金でも前提が違います。PoC〜本番の実額の内訳は『ローカルLLM導入費用の実額内訳。PoC300万円〜本番1,500万円の中身を開示する』、3年TCOと損益分岐点は『オンプレLLMは本当に安いのか。3年TCOと損益分岐点を正直に計算する』で個別に扱っているため、ここでは意思決定の順序を示します。
段階は3つです。まずミニ検証（限定データ・短期間）で、行内文書RAGが事務照会に耐えるかを確認します。次に行内PoCで、撤退基準を先に決めてから精度・運用負荷を検証します。そのうえで本番に移行します。積み上がった期待を一気に本番へ載せるのではなく、各段階でGo/No-Goを判断する進め方が、結果として最も早く着地します。撤退基準の決め方は『ローカルLLMのPoCで300万円溶かす前に。始める前に決める撤退基準』で、導入後にシステムを誰が維持するかという運用体制の論点は『導入したローカルLLM、誰が維持するのか』で解説しています。
金融特有のポイントとして、リスク管理・監査部門はPoCの設計段階から巻き込んでください。金融庁DPがモデルリスク管理と説明可能性を求める以上、検証の設計そのものが後の監督対応の証跡になります。精度が出てから監査部門に見せる進め方では、統制要件を満たすために作り直しになりやすいためです。検証項目・ログ取得・レビュー体制を最初の設計に織り込むほうが、総コストは下がります。
導入前チェックリスト（金融機関向け）
検討を先に進める前に、次の項目が埋まっているかを確認してください。いずれも本記事で整理した規制要件・先行事例から導かれる論点です。
- 対象業務とデータ区分（公開情報系／顧客情報・与信・事務規定）を整理した
- クラウド利用部分について学習非利用・監査権を契約で確保する前提がある
- 推論の入出力ログ・アクセス証跡の取得と保管を設計に織り込んだ
- プロンプト・出力に含まれる機密の検出・マスキングの要否を確認した
- ロールベースのアクセス制御（部門・役職単位の参照範囲）を決めた
- モデルインベントリと本番投入前検証の記録方法を決めた
- リスク管理・監査部門をPoCの設計段階から巻き込む体制にした
- PoCの撤退基準を先に決めた（決め方はこちら）
まとめ
- 金融機関がローカルLLMを選ぶ根拠は感覚論ではなく、FISC第14版（2026年3月25日公表）と金融庁AIディスカッションペーパー第1.1版（2026年3月3日公表）から導けます
- 規制が求めるのは説明責任と統制であり、オンプレ/閉域網は目的ではなく手段です。「クラウド全面禁止」も「クラウド＝学習される」も誤解です
- 規制文書は外部委託管理・データ管理・監査・モデルリスク管理・説明可能性という実装要件に翻訳して扱います
- 先行事例（あおぞら銀行・常陽銀行）の入口はいずれも行内文書RAGと事務照会であり、行内知識への正確な接地を精度の軸に置いています
- 構成は閉域網＋オンプレ/閉域推論＋RAG＋監査ログの4層で、公開情報系はクラウド・機密情報系はオンプレの二層振り分けが現実的です
- 導入はミニ検証→行内PoC→本番の段階制で進め、リスク管理・監査部門はPoCの設計段階から巻き込みます
よくある質問
Q. FISC基準でクラウドAIは使えますか？
使えます。FISCは外部委託・クラウド利用を前提にした管理基準を持っており、金融庁もクラウド利用そのものを否定していません。条件になるのは、責任分界と監査権の確保、入力データが学習に使われないことの契約明記、データの保存場所と越境の管理といった統制です。実務上は、公開情報・一般業務はクラウド法人契約LLM、顧客情報・与信・事務規定はオンプレ/閉域網という二層の振り分けが現実的です。
Q. 金融機関が生成AIをオンプレミスに置くのはなぜですか？
FISC第14版と金融庁AIディスカッションペーパーが求める外部委託管理・データ管理・監査証跡・モデルリスク管理という統制を、最も素直に満たせる構成だからです。ただし規制文書のいずれも「オンプレミスでなければならない」とは書いておらず、オンプレ/閉域網は説明責任と統制を満たすための手段であって目的ではありません。
Q. FISC安全対策基準第14版では生成AIはどう扱われていますか？
FISC「金融機関等コンピュータシステムの安全対策基準・解説書」第14版は2026年3月25日に公表され、政府機関・業界団体がAI・生成AIについて公表したガイドラインや報告書を分析し、安全対策の基準項目に反映しています。実装面では、外部委託管理（責任分界・監査権・学習非利用の契約）、データ管理（保存場所と越境の管理）、システム監査（入出力ログ・アクセス証跡）に翻訳して扱うのが実務的です。
Q. 金融庁のAIディスカッションペーパーとは何ですか？
金融庁が金融機関のAI利活用に関する論点を整理した文書で、第1.0版（2025年3月）に続き、第1.1版が2026年3月3日に公表されています。モデルリスク管理・説明可能性・データ準備や外部委託が主要な論点で、実装面ではモデルインベントリの整備、本番投入前の検証、継続的な性能監視、推論過程の文書化と第三者レビュー体制が対応します。
Q. 金融機関のローカルLLM導入事例はありますか？
あります。あおぞら銀行はneoAIと共同で金融・行内特化のオンプレミス型LLM「あおぞらLLM」を開発し（2025年4月）、継続事前学習により行内ベンチマークの応答精度を従来比130%に高めました。常陽銀行は松尾研発のAthena Technologiesと、外部から完全に隔離されたオンプレ環境で稟議書自動生成・機密情報の自動検出など5業務の実証を進めています（2025年7月）。他業種を含む事例の共通パターンは『ローカルLLM国内導入事例2026』で整理しています。
Q. 地銀・信金の規模でもローカルLLMを導入できますか？
規模ごとの段階設計をすれば可能です。いきなり本番構築に入るのではなく、限定データ・短期間のミニ検証で行内文書RAGが事務照会に耐えるかを確認し、撤退基準を決めた行内PoCを経て本番へ進む段階制が基本です。費用の実額はフェーズで大きく変わるため、『ローカルLLM導入費用の実額内訳』を参考にしてください。
Q. ローカルLLM導入で監査対応に必要なログ・証跡は何ですか？
4点です。推論の入出力ログの保管（誰がいつ何を尋ね、何が返ったか）、プロンプト・出力に含まれる機密の検出とマスキング、ロールベースのアクセス制御、モデル更新の検証記録（モデルインベントリと本番投入前の検証ログ）です。これらは金融庁DPのモデルリスク管理・説明可能性の要請に対応するもので、後から証跡を作ることは難しいため、最初から出力される設計にすることが要点です。
主な参考資料: FISC 安全対策基準・解説書 第14版、金融庁 AIディスカッションペーパー（第1.1版）、あおぞら銀行×neoAI プレスリリース、常陽銀行×Athena Technologies 導入事例
TodoONadaでは、ローカルLLM/生成AIの導入判断からPoC・構築までを支援しています。金融機関の場合は、FISC・金融庁DPの要件を実装要件に翻訳し、監査部門を巻き込んだ検証設計まで含めて伴走します。まずは30万円・2週間のミニ検証で、行内文書RAGが事務照会に耐えるかを確かめるところを起点にできます（サービス内容はローカルLLM導入支援をご覧ください）。検討段階のご相談も歓迎します。
この記事に関連するサービス
TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。
- ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
- Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。
出典・参照
- Claudeの法人契約・個人プランでの学習利用の線引き （2026年7月5日確認）
- FISC公表資料 （2026年7月5日確認）
- 金融庁 公表ページ （2026年7月5日確認）
- neoAI プレスリリース （2026年7月5日確認）
- Athena Technologies 導入事例 （2026年7月5日確認）
