先に結論
金融機関や士業法人が生成AIを使うとき、「モデルリスク管理の対象になるかどうか」だけを見て統制の要否を決めるのは危険です。統制が必要になる本当の理由は、規制があるからではありません。顧客の資産・秘密・権利に直接触れる業務にAIが入り込むからです。
規制の適用範囲と、実務上の説明責任は別の話です。ある業務が形式的にモデルリスク管理の枠の外にあっても、そこで顧客情報を扱い、対外文書を作り、金銭や法的判断に影響を与えているなら、「なぜこの出力を使ったのか」「誰が確認したのか」を後から説明できる状態にしておく責任は消えません。
だからこそ、生成AIの統制は「モデルを作っているか」ではなく、「顧客影響のある業務のどこに、どんな顔をして入り込んでいるか」で判断する必要があります。本記事は、AIツールの設定論ではなく、議事録・要約・文案といった個々のワークフローに対する統制の考え方を扱います。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
「規制対象外だから統制不要」という誤読
最初に解いておきたい誤読があります。「うちの使い方はモデルリスク管理の対象ではないから、統制はいらない」という考え方です。これは二つの点で危うい。
第一に、「モデルリスク管理」という言葉が指す規制上の範囲は、業態や所管当局によって異なります。銀行、保険、証券、貸金、士業では前提となる監督の枠組みも実務も違い、同じ言葉でも当てはまり方が変わります。自社の業務が具体的にどの規制の適用範囲に入るのか・入らないのかは、一般論で断定できるものではなく、所管当局の指針や顧問弁護士への確認によって初めて確定します。本記事も、特定の生成AI利用が規制対象か否かを断定するものではありません。
第二に、仮に形式的な適用範囲の外にあったとしても、それは「何をしてもよい」という意味ではありません。顧客に対して負っている説明責任、守秘義務、成果物への責任は、規制の線引きとは独立に存在します。規制は守るべき最低限を示すものであって、実務上の信頼を担保するものではないからです。顧客から「この報告書の数字はどうやって出したのか」「AIに私の情報を入れたのか」と問われたとき、規制の対象外であることは何の答えにもなりません。
つまり、統制の根拠を「規制があるから」に置くと、規制の隙間がそのまま無防備な穴になります。根拠を「顧客の資産・秘密・権利に触れているから」に置き直すと、規制の有無にかかわらず、守るべきラインが見えてきます。この置き換えが、金融・士業における生成AI統制の出発点です。
生成AIが業務に入る典型的な入口
生成AIは、多くの場合「大きな意思決定を任せるシステム」として堂々と導入されるわけではありません。むしろ、小さな「補助」の顔をして日常業務に入り込みます。問題は、その補助がいつの間にか成果物の一部になっていることに、現場も管理者も気づきにくい点にあります。
代表的な入口は次のようなものです。
- 議事録の作成・要約: 顧客との面談や社内会議の録音を文字起こしし、要点をまとめる。顧客の発言や意向が、要約の段階で微妙にずれても検知されにくい。
- 下調べ・リサーチ: 制度、判例の傾向、業界動向などの一次調査。AIの出力に事実誤りや古い情報が混じっても、そのまま提案の前提として流れていく。
- 文案・ドラフト作成: 顧客への説明文、契約条項のたたき台、報告書の下書き。「たたき台」のつもりが、手直しされないまま対外文書になる。
- 翻訳: 海外顧客とのやり取りや外国語資料の理解。ニュアンスの取り違えが、そのまま合意内容の齟齬につながることがある。
- コードを書かない自動化: 定型メールの生成、表計算の集計補助、分類やタグ付け。人手が減る一方で、判断の根拠が残らなくなる。
これらはすべて「あくまで補助」という前提で使われ始めます。しかし、要約が議事録として保存され、下調べの結果が提案書に載り、文案がそのまま送付されれば、生成AIの出力は補助ではなく成果物になっています。統制の設計は、この「補助が成果物に変わる境界」を業務ごとに見つけるところから始まります。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
なぜワークフロー単位で見るべきか
生成AIのリスクは、モデル単体の性能や安全性だけに宿るものではありません。リスクは業務の流れ、すなわちワークフローに沿って積み上がっていきます。
一つの業務を分解すると、誰かがプロンプトを作り、どの顧客情報を入力し、どの出力を採用し、誰がそれを修正し、最終的に顧客へどう説明したのか、という連鎖が見えてきます。この連鎖のどこか一つでも記録が欠けると、後から「なぜこうなったのか」を説明できなくなります。誤りが起きたとき、情報が漏れたとき、顧客に問われたときに、答えを再構成できない状態が、金融・士業にとって最大のリスクです。
ツール単位の管理、たとえば「どのAIサービスを許可するか」という発想だけでは、この連鎖を捉えられません。同じツールでも、議事録に使うのか、契約レビューに使うのか、審査補助に使うのかで、入れてよい情報も、必要なレビューの深さも、残すべき証跡もまったく違うからです。統制の単位をツールからワークフローへ移すことで、初めて「この業務では何を守るのか」を具体的に決められるようになります。
ワークフローごとの統制ポイント
業務ごとに、統制すべき論点は共通の型で整理できます。おおまかには、(1) 顧客情報を入れてよいか、(2) 出力を誰がレビューするか、(3) 根拠を残せるか、(4) 外部送信は可視化されているか、(5) 再現性をどう扱うか、の五つです。代表的なワークフローに当てはめると次のようになります。
横にスクロールして確認できます
| ワークフロー | 主な統制ポイント |
|---|---|
| 顧客相談メモ・議事録 | 入力してよい個人情報の範囲、要約の確認者、原本（録音・原メモ）の保存 |
| 契約・書類レビュー | AI出力を法的判断そのものとして扱わない、専門家によるレビュー記録を残す |
| 審査・与信の補助 | 入力データ、判断に使った根拠、最終承認者を記録する |
| 報告書・提案書作成 | 引用元の明示、数値の再確認、顧客提出前のレビュー |
| 下調べ・リサーチ | 情報源の確認、AI出力を一次資料として扱わない、鮮度の確認 |
| 社内FAQ・ナレッジ | 最新規程との整合、更新責任者、利用履歴 |
重要なのは、AIツールそのものの設定（アカウント管理やアクセス権）だけでなく、業務ごとに「入力禁止情報」「レビュー者」「保存場所」「ログ」「顧客への説明」を個別に決めることです。ツールの設定は入り口の一つにすぎず、成果物の質と説明責任を担保するのは、あくまでワークフローごとの取り決めです。
とくに顧客情報の入力可否は、業務ごとに線を引く必要があります。氏名・連絡先・取引内容・契約情報・営業秘密のどこまでを入れてよいのかは、使うサービスの契約条件（後述）と、その業務が持つ機微性の両方で決まります。「原則として個人情報や機微情報は入力しない。必要な場合は匿名化・マスキングし、承認を得る」といった業務単位のルールを、あいまいな社内通達ではなく、具体的な線として持っておくことが出発点になります。
士業に特有の論点
士業（弁護士・税理士・司法書士・行政書士・社会保険労務士など）では、金融機関以上に統制の根拠が「規制」ではなく「職業上の責任」に強く結びつきます。ここで扱うのはあくまで実務設計の観点であり、個別の法的判断ではありません。具体的な可否は、所属する士業団体の指針や顧問弁護士への確認によって判断してください。
論点はおおむね三つに整理できます。
- 守秘義務: 依頼者から預かった情報を、外部のAIサービスに入力することが守秘義務との関係でどう位置づけられるか。サービスが入力データを学習に使う設定か、どこに保管されるか、誰がアクセスしうるかによって、検討すべき事情が変わります。
- 成果物への責任: AIが作った文案や下調べをそのまま成果物にした場合でも、最終的な責任は資格者自身に残ります。AIの出力を「確認せずに採用した」ことが後から問題化しないよう、確認の事実を残す設計が要ります。
- 名義貸しに近い状態にならないか: 実質的な検討や判断をAIに委ね、資格者は形式的に署名するだけ、という状態に近づいていないか。AIはあくまで作業を補助する道具であり、専門的判断の主体を置き換えるものではない、という線を業務設計として保つ必要があります。
これらはいずれも「AIを使ってよいか・いけないか」という二択で答えの出る問題ではありません。どの情報を、どの業務で、どこまでAIに触れさせ、資格者がどこで判断と確認を差し込むか、という設計の問題です。そして繰り返しになりますが、具体的な線引きは団体の指針と顧問弁護士への確認を前提としてください。
レビュー体制の設計 — リスクで層を分ける
生成AIの出力をどこまで人が確認するか。理想を言えば全件を精査したいところですが、業務量を考えれば全件確認は現実的ではありません。全件確認を建前として掲げると、実際には形骸化し、かえって「確認したことになっている」危険な状態を生みます。
現実的なのは、リスクの高さで確認の層を分けることです。おおまかな考え方は次の通りです。
- 高リスク層（対外文書・金銭/法的影響あり）: 契約書、顧客提出物、審査・与信に関わる出力。専門家が内容を精査し、確認の事実と修正履歴を残す。ここは省略しない。
- 中リスク層（内部利用だが誤りが波及する）: 提案の前提となる下調べ、社内向け報告の要約。担当者が根拠を確認し、疑わしい点を潰す。抜き取りではなく主要部分の確認を行う。
- 低リスク層（機微性が低く、影響が限定的）: 定型的な社内メモ、公開情報の整理。軽い確認にとどめ、リソースを高リスク層に回す。
大切なのは、どの業務がどの層に入るかを事前に決めておくことです。層分けの基準が現場任せになると、忙しいときに高リスクの出力が素通りしてしまいます。「対外に出るか」「金銭・法的な影響があるか」「顧客の機微情報を含むか」といった問いで機械的に層を割り当てておけば、判断のばらつきを減らせます。レビューは「全部見る」でも「見ない」でもなく、「どこを必ず見るかを決めておく」設計だと考えるのが実務的です。
ログと再現性 — 「なぜその結論か」を後から説明する
生成AIには、従来のシステムと決定的に違う性質があります。同じ入力を与えても、出力が毎回同じとは限らないという点です。モデルの更新やパラメータ、時期によって、返ってくる内容は揺れます。この非再現性は、「後から検証する」ことを難しくします。
だからこそ、事後に説明するための記録を、出力そのものとは別に残す必要があります。「同じことをもう一度やれば再現できる」という前提が崩れている以上、そのときの状況を保存しておかなければ、判断の経緯を復元できないからです。
説明可能性のために残しておきたい記録の例は次の通りです。
- どの業務で、どのサービス（できればバージョンや利用時期）を使ったか
- どのような指示（プロンプト）を与えたか
- どの情報を入力したか（機微情報を含む場合はその旨と取り扱い）
- AIが返した出力と、そのうち採用した部分
- 誰がどこを修正・確認し、いつ承認したか
これらが揃っていれば、たとえ同じ出力を再現できなくても、「このときはこの入力に対してこの出力が返り、担当者がここを直して採用した」という経緯を説明できます。逆に、最終成果物だけが残っていて途中が欠けていると、誤りの原因も、情報の流れも追えなくなります。ログは監視のためというより、自分たちと顧客のために「説明できる状態」を用意しておく保険だと捉えるのが実態に合っています。
ベンダー・SaaSに聞くべき質問
自社でモデルを開発していなくても、外部の生成AIサービス（SaaS）を使う以上、そのサービスの取り扱いが自社の統制の一部になります。契約前・利用前に、少なくとも次の点を確認しておきたいところです。
- 入力データの学習利用: 入力した内容がモデルの学習・改善に使われるか。使われない設定・プランはあるか。既定値はどうなっているか。
- 保管期間と保管場所: 入力・出力がどこに、どのくらいの期間保管されるか。国内か国外か。
- 削除の可否: 保管されたデータの削除を求められるか。退会時にデータはどうなるか。
- ログの取り出し: 利用履歴や監査に使えるログを、自社側で取得・エクスポートできるか。
- サブプロセッサ: そのサービスがさらに委託している先（クラウド基盤や外部モデル提供者など）はどこか。再委託の範囲は開示されているか。
これらは、顧客情報を扱う業務でそのサービスを使ってよいかを判断するための最低限の材料です。回答があいまいなまま機微情報を入力するのは、外部送信のリスクを可視化しないまま拡大させることになります。契約条件は変わりうるため、一度確認して終わりではなく、更新時に見直す前提を持っておくと安全です。情報漏えいや外部送信の観点を含めて体制を見直したい場合は、セキュリティ事業の考え方も参考にしてください。
よくある誤解
最後に、金融・士業の現場で繰り返し見られる誤解を挙げておきます。いずれも、統制の根拠を「規制」や「ツールの体裁」に置いてしまうことから生まれます。
- 「社内利用だけなら問題ない」: 社内利用であっても、入力する情報が顧客の機微情報なら、外部サービスへの送信が起きています。成果物が対外に出れば、内部か外部かの区別は意味を持ちません。
- 「無料版でも有料版でも同じ」: 入力データの学習利用や保管の扱いは、プランによって異なることがあります。無料プランの既定値が業務利用に適しているとは限りません。
- 「AIが出した数字は根拠になる」: 生成AIは、もっともらしい数値や出典を作り出すことがあります。数値や引用は、必ず一次情報で裏取りをしてから根拠として扱う必要があります。
- 「規制がないから自由に使ってよい」: 規制の適用範囲外であることは、説明責任や守秘義務がなくなることを意味しません。統制の根拠は規制ではなく、顧客への責任にあります。
これらの誤解を一つずつほどいていくと、結局のところ問われているのは「AIを使うか使わないか」ではなく、「顧客に触れる業務のどこで、どう確認し、何を残すか」であることが分かります。
導入前に確認すること
生成AIをすでに使い始めている、あるいはこれから使う金融・士業法人が、まず着手したいのは「生成AIワークフローの棚卸し」です。AIツールの一覧を作ることではなく、顧客情報が入る業務、対外文書が出る業務、金銭・法的影響がある業務を洗い出し、そこにAIがどう関わっているかを可視化します。
具体的には、次のような問いを業務ごとに確認していきます。
- 顧客情報・個人情報・契約情報を、生成AIに入力している業務はどれか
- AIの出力を、顧客向け文書・審査・契約レビューに使っている業務はどれか
- それぞれに、最終確認者・修正履歴・承認ログは残っているか
- 顧客から「AIを使っているのか」と聞かれたときの説明の用意はあるか
- 入力してよい情報の範囲と、レビューの層分けは業務ごとに決まっているか
- 社員教育と定期的な点検（誰が・どの頻度で）は決まっているか
この棚卸しを一度きりで終わらせず、業務が変われば見直す前提で持っておくと、統制が実態からずれにくくなります。
この記事を読むべき人
- 顧客情報や機微情報を扱う金融機関・士業法人で、現場が生成AIを使い始めているが、統制の線引きが決まっていない経営者・管理者
- 「モデルリスク管理の対象ではないから統制はいらない」と社内で言われ、その判断に違和感を持っている責任者
- 議事録・下調べ・文案作成・要約といった「補助的な」AI利用が、いつの間にか成果物に入り込んでいることに気づいた実務担当者
- 生成AIツールの導入可否を、機能や価格ではなく「顧客への説明責任」の観点から整理したい方
- 顧問弁護士や所属団体に相談する前に、論点と確認すべき問いを自社で整理しておきたい方
よくある質問（FAQ）
Q. モデルリスク管理の対象外なら、生成AIの統制は不要ですか？ いいえ。統制の根拠は規制の適用範囲ではなく、顧客の資産・秘密・権利に触れているかどうかです。規制の対象外であっても、顧客情報を扱い対外文書を作る業務であれば、説明責任や守秘義務は残ります。なお、自社の業務が具体的にどの規制の対象になるかは、所管当局の指針や顧問弁護士への確認が前提です。
Q. 社内利用に限定していれば問題ないのでは？ 社内利用でも、入力する情報が顧客の機微情報であれば、外部サービスへの送信が発生しています。また、社内で作った要約や下調べが提案書・報告書に流れれば、実質的に成果物の一部になります。内部・外部の区別より、「何を入力し、成果物にどう反映されるか」で見るのが実態に合います。
Q. 無料版と有料版で統制の考え方は変わりますか？ 入力データの学習利用や保管期間などの扱いは、プランや契約条件によって異なることがあります。無料プランの既定値が業務利用に適しているとは限らないため、機微情報を扱う業務では、契約条件を確認したうえで使うサービス・プランを選ぶ必要があります。
Q. 生成AIが出した数値は、そのまま根拠資料に使えますか？ そのままでは推奨できません。生成AIは、もっともらしい数値や出典を生成してしまうことがあります。数値や引用は、必ず一次情報で裏取りをしたうえで根拠として扱ってください。
Q. 士業の守秘義務と生成AI利用は両立できますか？ 両立の可否や条件は、使うサービスの取り扱い（学習利用・保管・アクセス範囲）や入力する情報の性質によって変わり、一律には言えません。具体的な判断は、所属する士業団体の指針や顧問弁護士への確認を前提としてください。本記事は実務設計の観点を示すもので、個別の法的判断を示すものではありません。
Q. すべての出力を人がレビューするのは現実的ではありません。どうすればよいですか？ 全件確認は形骸化しやすいため、リスクの高さで層を分けるのが現実的です。対外文書や金銭・法的影響のある高リスク業務は必ず専門家が精査し、機微性の低い業務は軽い確認にとどめる、という割り当てを事前に決めておきます。
Q. どんなログを残せば「説明できる」状態になりますか？ どの業務でどのサービスを使い、どんな指示を与え、どの情報を入力し、どの出力を採用し、誰がどこを修正・承認したか、を残すのが基本です。生成AIは同じ入力でも出力が揺れるため、最終成果物だけでなく、経緯を再構成できる記録を出力とは別に保存しておくことが重要です。
Q. ベンダーやSaaSには何を確認すればよいですか？ 入力データの学習利用の有無、保管期間と保管場所、削除の可否、監査に使えるログの取り出し、そしてサブプロセッサ（再委託先）の範囲を確認します。回答があいまいなまま機微情報を入力するのは避けるべきです。
関連するGXOナレッジ
- 生成AI社内ガバナンス（利用統制・監査ログ・情報分類）
- AI導入可否アセスメント
- AI規制がリスクベースへ向かう時代、企業はAI台帳と責任分界をどう作るべきか
- AIガバナンス診断チェックリスト
- AI法制がリスクベースへ向かう時代、中小企業はAI利用をどう分類すべきか
- 規制業界でAIエージェントを使う前に作る、部署横断の責任分界と監査ログ
GXOが支援できること
金融・士業の生成AI利用を、顧客情報・レビュー・証跡まで含めてワークフロー単位で整理したい場合は、GXOの生成AI社内ガバナンスの考え方が参考になります。ツール名の管理ではなく、顧客影響のある業務フローを棚卸しし、入力可否・レビュー層・ログ・顧客説明を業務ごとに設計するところから始めます。発注前の論点整理から相談したい場合はAI開発・生成AI活用の発注前整理もあわせてご覧ください。
参考・出典
- 査読前のプレプリント（peer-review前）: Wang, Kang, Lin, Mao「Governing Generative AI Across Financial Institutions: An SR 26-2-Compatible Framework for Generative AI Risk Control」arXiv, 2607.04103 — 生成AIが「正式なモデルの境界の外」にありながら規制対象の業務に組み込まれる点を論じたプレプリント。査読を経ていないため、規制上の解釈としてではなく一つの論考として参照。 https://arxiv.org/abs/2607.04103 （確認日: 2026-07-10）
- NIST AI Risk Management Framework（GOVERN/MAP/MEASURE/MANAGEの4機能から成る任意適用のフレームワーク）: https://www.nist.gov/itl/ai-risk-management-framework （確認日: 2026-07-10）
- 経済産業省 AI事業者ガイドライン: https://www.meti.go.jp/policy/it_policy/ai_guideline/ （※2026-07-10時点でアクセス時にHTTP 403が返り本文未確認。一次資料として参照する際は最新版を各自ご確認ください）
- 個人情報保護委員会（個人情報保護法の所管当局）: https://www.ppc.go.jp/ （確認日: 2026-07-10）
※本記事は生成AIワークフローの統制に関する一般的な考え方を整理したものであり、特定の生成AI利用が規制の対象となるか、守秘義務等との関係で適法かを断定するものではありません。具体的な適用範囲や法的判断は、所管当局の指針および顧問弁護士・所属団体への確認を前提としてください。
