結論：統制は「方針」ではなく「工程」に埋め込む
生成AIの社内ルールを一枚の方針書にまとめても、業務は変わりません。実際に事故が起きるのも、後から説明できなくなるのも、方針の文言ではなく日々のワークフローの一工程です。生成AIを使った業務は、ざっくり見ると一発の「AIに書かせる」作業に見えますが、分解すると次の流れでできています。
入力 → 前処理 → 生成 → レビュー → 確定 → 保存 → 顧客提供。
統制とは、この各工程に「どんなチェックを、誰が、どこまで入れるか」を割り付ける作業です。入力工程でマスキングを効かせ、生成工程で根拠提示を求め、レビュー工程で二重チェックの範囲を決め、保存工程で証跡を残す。工程ごとに担当と確認内容が決まっていれば、正式な統計モデルでなくても、顧客説明・審査・契約解釈に影響する文章を後から再現・説明できます。逆に、方針だけあって工程に落ちていないと、便利に回っている運用ほど事後の説明で詰まります。
この記事は、金融・保険・士業のワークフローを工程に分け、各工程にどの統制を実装するかを具体化した実務メモです。工程分解や要件整理から相談したい場合は、生成AIの業務適用範囲を発注前に整理するや生成AI社内ガバナンスの設計をご利用ください。
なお、生成AIがモデルリスク管理（MRM）や金融庁の監督上の枠組みの対象になるかどうかは、業態・商品・利用のされ方で異なります。本稿は適用範囲を断定しません。自社の生成AI利用が規制・監督の対象に入るかは、所管当局の公表資料と顧問弁護士に確認してください。士業の守秘義務や成果物責任の範囲も、所属する会・連合会の会則や指針、顧問弁護士の判断が優先します。
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
この記事を読むべき人
- 銀行・信金・信組・証券・保険会社、保険代理店、税理士/会計士/社労士/司法書士などの士業法人
- コンプライアンス・法務・内部監査・情報システムの責任者
- 「モデルは管理しているが、ChatGPTやCopilotの業務利用は実態が見えない」という会社
- 現場が便利に使い始めており、管理部門が全体像を把握しきれていない会社
- PoCは動いたが、監査証跡・顧客説明・保守で本番化が止まっている会社
- 生成AIの利用規程は作ったのに、現場の作業手順まで落ちていない会社
この記事の根拠と最新性
本稿の主な根拠は次の情報で、いずれも2026年7月10日にアクセスを確認しています。価格・罰則・法制度・前提条件は時期によって変わるため、判断の直前に公式情報をあらためて確認してください。arXivの2点は査読前のプレプリントであり、確定した規範ではない点に注意してください。
- arXiv（プレプリント）Governing Generative AI Across Financial Institutions（2607.04103）
- arXiv（プレプリント）Agent Security Meets Regulatory Reality（2606.29142）
- NIST AI Risk Management Framework（Govern / Map / Measure / Manage）
- OWASP GenAI Security Project（プロンプトインジェクション、機微情報漏えい等の脅威分類）
- 経済産業省 AI事業者ガイドライン
- 個人情報保護委員会
金融機関で生成AIガバナンスをどう設計するかはプレプリント2607.04103が、規制対応と自律エージェントのセキュリティ現実のギャップは同2606.29142が扱っています。統制の共通言語としてはNIST AI RMFの4機能、脅威の分類にはOWASP GenAIを土台にし、国内の説明責任は経済産業省のガイドラインと個人情報保護委員会の考え方に寄せると、社内説明と監査対応の語彙がそろえやすくなります。いずれも本稿の工程分解の枠組みとして参照するもので、条項や数値をそのまま引用する使い方はしていません。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
生成AIワークフローを7つの工程に分解する
統制の対象を「生成AIそのもの」に置くと、話がツール選定に流れます。対象を「業務の工程」に置き換えると、どこに穴があるかが具体的に見えます。金融・保険・士業で頻出するワークフローは、次の7工程に分解できます。
横にスクロールして確認できます
| 工程 | やっていること | 抜け・誤りが起きる典型 |
|---|---|---|
| 1 入力 | 顧客情報・案件情報・原メモをプロンプトに入れる | 要配慮個人情報・営業秘密を素のまま外部SaaSへ渡す |
| 2 前処理 | 参照させる社内資料・過去事例を指定する | 古い規程・別顧客の資料を混ぜる、参照範囲が無限定 |
| 3 生成 | AIに下書き・要約・指摘を作らせる | 根拠のない断定、事実の欠落、もっともらしい誤り |
| 4 レビュー | 人が内容を確認・修正する | 誰も見ない、体裁だけ見て中身を見ない |
| 5 確定 | 採用版を決め、承認する | 承認者が不明確、AI下書きと確定版の区別がない |
| 6 保存 | プロンプト・出力・承認記録を残す | 個人のチャット履歴に消える、後から再現できない |
| 7 顧客提供 | 顧客へ送付・提示・説明する | 未レビュー版が流出、自動送信に近い運用 |
穴は一か所ではなく、工程ごとに違う顔で現れます。入力工程の穴は情報漏えい、生成工程の穴は誤った説明、保存工程の穴は説明責任、顧客提供工程の穴は事故の外部流出です。だからこそ「AIに気をつける」ではなく、工程ごとに別々の統制を当てる必要があります。
工程ごとに何を実装するか
1 入力：マスキングとデータ分類を先に決める
最初に決めるのは「AIに渡してよいデータ」と「渡してはいけないデータ」の線引きです。顧客情報・要配慮個人情報・営業秘密・契約情報・資格情報を、渡してよい／マスキングして渡す／渡してはいけない、の3分類で管理します。氏名・生年月日・口座番号・病歴などは、入力前に置換・削除する運用を工程に組み込みます。外部SaaSに素のデータを渡す前に、学習利用がオフか、保存期間はどうか、越境や再委託があるかを確認します。ここはOWASP GenAIが挙げる機微情報漏えいの受け皿になる工程です。
2 前処理：参照データを限定する
生成AIに社内資料を参照させる場合、「何を参照させたか」が出力の質と説明可能性を左右します。参照先を最新版の規程・約款・商品説明に限定し、古い版や別顧客の資料が混ざらないようにします。参照範囲を無限定にすると、出力の根拠を後から追えなくなります。参照した資料のバージョンと日付を、可能な範囲で記録に残します。
3 生成：根拠の提示を求める
生成工程の統制は「もっともらしい誤り」を減らすことです。プロンプトの段階で「根拠となる社内資料の該当箇所を併記させる」「不明な点は断定せず不明と書かせる」といった指示を標準化します。数値・条件・前提は、AIの出力をそのまま信じず、人が原典から確認する前提で設計します。生成物は「下書き」であって「確定」ではない、という位置づけを工程上ではっきりさせます。
4 レビュー：二重チェックの範囲を決める
「人が最後に見る」だけでは統制になりません。何を、どの深さで見るかを決めて初めてレビューです。顧客に届く文章や判断に近い所見は、作成者とは別の人が確認する二次チェックを定義します。二次チェック者が見るのは、表現の適否だけでなく、根拠と原典の一致、禁止表現の有無、事実の欠落です。全部を同じ深さで見ると回らないので、後述のリスク層で確認の深さを変えます。
5 確定：承認者と責任分界を明確にする
採用版を誰が承認したかを工程に残します。AIの下書きと、人が確定した版を区別できるようにし、確定版には承認者と日時を紐づけます。判断に近い業務では、AIの出力を結論にせず、判断者が根拠を見て独立に結論を出し、AIは論点整理に使う、という分界を確定工程で担保します。
6 保存：ログを再現可能な形で残す
保存工程の統制は「後から説明できる状態」を作ることです。プロンプト、出力、採用/修正の履歴、承認者、日時を、個人のチャット履歴ではなく業務記録として残します。同時に、要配慮個人情報や契約情報を含むログの保存期間と削除ルールを決めます。残しすぎも漏えいリスクになるため、保存と削除はセットで設計します。
7 顧客提供：提供前の確認を必ず挟む
顧客へ届く直前に、確定版であること、禁止表現がないこと、承認済みであることを確認する工程を挟みます。自動送信に近い運用は、この工程を飛ばすため事故が外部に出ます。誰が最終確認して送るか、送付記録をどう残すかを決めます。
全件レビューは不可能：リスクで層を分ける
すべての生成AI出力を同じ深さで確認するのは現実的ではありません。全部を厳格にすると現場が使えず隠れ利用が増え、全部を自由にすると事故ります。出力の性質を層に分け、層ごとに確認の深さを変えます。
横にスクロールして確認できます
| 層 | 生成AIの役割 | 例 | 確認の深さ |
|---|---|---|---|
| L1 読むだけ | 社内文書・公開情報の要約・検索 | 社内規程FAQ、公開資料の要約 | 機微情報を入れない指導、学習利用オフの確認 |
| L2 社内文書を書く | 稟議・議事録・所見の下書き | 上申書の文案、面談メモ要約 | 作成者の自己確認、根拠併記、下書き保存 |
| L3 顧客向けに書く | 顧客への説明文・案内文の生成 | 保険説明、契約案内、回答文 | 二次チェック、禁止表現ルール、提供前確認、ログ保持 |
| L4 判断に近い | 審査コメント・契約レビュー補助 | 与信所見、約款リスク指摘 | 人の独立判断を必須化、根拠開示、監査証跡、例外処理 |
同じ「生成AIで効率化」でも、社内メモの要約（L2）と、顧客に届く保険説明（L3）と、与信所見（L4）を同じ扱いにしてはいけません。L3・L4に人的コストを集中させ、L1・L2は軽くする。この層分けが、レビュー工程の深さと、保存すべき証跡の粒度を決めます。まず自社の利用がどの層に当たるかを棚卸しするところから始めます。
業務別の当てはめ
7工程と4層を、金融・保険・士業で頻出する業務に当てはめると次のようになります。どの業務も「入力のマスキング」と「保存の証跡」は共通で必要になり、L3・L4はさらにレビューと確定が重くなります。
相談記録・面談メモの要約（L2）
要約の過程で事実が落ちたり、ニュアンスが変わったりします。原文（録音・原メモ）を必ず残し、AI要約は補助と明示します。要配慮個人情報を含むため、入力工程で素の音声・氏名を外部SaaSへ渡さない運用を先に決めます。
稟議・上申文の作成（L2）
根拠なしの断定が入りやすい業務です。数値・条件・前提は人が原典から転記し、AIは文章整形に限定します。承認者が内容の妥当性を見られるよう、根拠資料へのリンクを併記させます。
顧客説明文・案内文（L3）
誤った説明は、説明義務や不当表示の問題につながりうる領域です。適用の有無や程度は業態・商品で異なるため、断定的な利回り表現や確実性を示す表現、比較優良誤認を招きうる表現の扱いは、所管当局の公表資料と顧問弁護士に確認したうえで禁止表現ルールに落とします。提供工程で二次チェック者が確認し、承認記録を残します。
契約・約款レビュー補助（L4）
AIの指摘は「気づきの一覧」であって法的判断ではありません。最終解釈は担当者・有資格者が行い、AIが見落とした論点・誤指摘した論点を記録します。顧客の契約情報・営業秘密を扱うため、入力工程のデータ分類はL3以上に厳格にします。
審査補助・所見の下書き（L4）
与信・引受・受任可否に関わる所見は、根拠の説明可能性が要になります。AIの出力をそのまま所見にせず、判断者が根拠データを見て独立に結論を出し、AIは論点整理に使います。判断の主体は人に残します。
社内FAQ・回答テンプレ（L1〜L3）
社内利用ならL1ですが、そのまま顧客回答に転用されるとL3になります。テンプレ段階で「社内向け」と「顧客提示可」を分け、顧客提示版はレビュー済みのものだけを使います。
再現性の問題と、それでも説明責任を果たす方法
生成AIには、同じ入力でも出力が毎回わずかに揺れるという性質があります。金融・士業のように後から説明を求められる業種では、これが「なぜこの文面・この指摘になったのか」を語りにくくします。出力の一言一句を固定することはできませんが、次を工程で残せば「なぜそう判断したか」は説明できます。
- 入力：どのデータを、どこまでマスキングして渡したか
- 前処理：どの資料（版・日付）を参照させたか
- 生成：どのプロンプトで、どんな指示（根拠併記・断定禁止）を与えたか
- レビュー：誰が、何を基準に、どこを修正したか
- 確定：誰が、いつ、どの版を承認したか
説明責任の核心は「AIの出力を再現すること」ではなく、「人がどの根拠で採否・修正・承認を決めたか」を再現することです。出力が揺れても、採用の判断過程が残っていれば、検査・監査・顧客照会に対して筋の通った説明ができます。逆に、便利さだけを追ってこの過程を残さないと、成功しているように見える運用ほど事後に説明できません。
実装の順序：いきなりツールを買わない
工程と層が見えたら、すぐに全社ツール導入に走らないことが失敗回避の第一歩です。順序は「棚卸し → 1工程で回す → 広げる」です。
- 棚卸し：どの部署が、どの業務で、どのツールを、どの層で使っているかを一覧化する。現状のシャドー利用を可視化するだけでも、監査・検査の準備が一段進みます。
- 1つの業務・1つの工程で回す：リスクの低いL2業務を1つ選び、入力のマスキング・生成の根拠併記・保存の証跡だけを先に実装して回します。ツールは既存の契約範囲で十分なことが多いです。
- 測ってから広げる：工数削減・手戻り・事故未遂・費用・利用率を測り、続ける/広げる/やめるを判断してから対象業務を増やします。
最初から高機能なツールを契約すると、統制が工程に落ちないまま利用だけが広がり、後から禁止事項を増やす悪循環に入ります。先に工程の統制を作り、それを支えるツールをあとから選ぶ順序が安全です。ツールの是非やアーキテクチャの相談は、AI導入可否のアセスメントで工程設計と一緒に整理できます。
委託先・SaaSに聞く質問
生成AIワークフローを外部ベンダーやSaaSに委ねる場合、「できますか」ではなく、工程ごとの前提を同じ様式で問うと、金額差・責任範囲差・保守思想の差が見えます。
横にスクロールして確認できます
| 問う対象 | 具体的な質問 | 評価で見ること |
|---|---|---|
| 入力・データ | 入力データの保存期間、学習利用の有無、越境・再委託の有無 | 顧客説明・監査に耐えるか |
| 参照・前処理 | 参照させたデータの記録が残るか、参照範囲を限定できるか | 出力の根拠を追えるか |
| 生成 | 根拠併記や不明時の挙動を制御できるか | もっともらしい誤りを抑えられるか |
| レビュー・確定 | 人の承認を必須にできるか、承認者と日時を残せるか | 責任分界が明確か |
| 保存・監査 | ログ・根拠・承認・修正履歴を再現可能に残せるか | 事故後に再現・説明できるか |
| 権限 | 読み取り・書き込み・送信・削除・外部API操作の分離 | 過剰権限を避けているか |
| 費用・停止 | 初期・月額・API従量・保守・改善・解約時対応、費用暴走時の停止 | TCOと停止条件が明確か |
自律的に操作するエージェントを使う場合は、権限分離と操作の監査可能性がさらに重くなります。エージェントの責任分界はAI営業支援エージェントの設計や、法務の観点を整理したAIエージェント導入で法務が確認すべき5つの責任分界も参考になります。入力・保存まわりのセキュリティ設計はセキュリティ事業で扱います。
よくある誤解
- 「人が最後に見るから大丈夫」：見る、と、何をどの深さで見る、は別物です。二次チェックの範囲（根拠一致・禁止表現・事実欠落）を決めないと、体裁だけ通って中身の誤りが流れます。
- 「社内利用なら統制不要」：社内向けの回答テンプレがそのまま顧客回答に転用されれば、工程としてはL3です。利用の層は「どこで使うか」ではなく「どこに届くか」で決まります。
- 「AIの出力は根拠になる」：生成AIの出力は下書きであって、判断の根拠ではありません。根拠は原典と、人が採否を決めた過程にあります。出力をそのまま所見や説明に貼ると、根拠がブラックボックス化します。
- 「ログを取れば説明できる」：出力ログだけでは足りません。どの入力を、どうマスキングし、どの資料を参照し、誰がどの根拠で承認したか、という採否の過程が残って初めて説明できます。
発注前チェックリスト
工程設計を外部に依頼する前に、自社で埋めておくと見積と提案の質が変わります。
- 対象業務を7工程（入力〜顧客提供）に分解し、各工程の担当を書き出しているか
- AIに渡すデータを、顧客情報・要配慮個人情報・営業秘密・契約情報・資格情報で分類しているか
- 各業務がL1〜L4のどの層かを判定し、レビューの深さを変えているか
- L3・L4で人が承認・独立判断する工程を決めているか
- プロンプト・参照資料・出力・承認者・日時を再現可能な形で残せるか
- 費用上限・停止条件・復旧手順・顧客説明の担当を定義しているか
- 候補ベンダーへ、同じ様式（データ・参照・生成・レビュー・監査・費用）で回答を求めるRFPになっているか
経営者が見るべき判断軸
経営者は、生成AIの統制を「IT投資」ではなく「説明責任の設計」として見た方が判断を誤りません。同じ導入でも、売上を増やす業務か、粗利を守る業務か、事故損失を避ける業務かで責任の重さが変わります。
横にスクロールして確認できます
| 経営判断 | 確認する質問 | 見るべき点 |
|---|---|---|
| どの工程に近づけるか | AIを判断のどこまで近づけるか（L1〜L4） | 顧客影響・審査影響の大きさ |
| 利益への効き方 | 工数削減か、手戻り削減か、事故予防か | 効果が測れる指標があるか |
| リスク低減 | 情報漏えい・誤説明・過剰権限・監査不備を防げるか | 証跡と承認が工程に設計されているか |
| 実行可能性 | 現場が毎日回せる承認・ログ・教育があるか | 隠れ利用を生まない運用か |
90日で本番化可否を判断する運用計画
いきなり全社導入を決めず、90日で「進める条件がそろうか」を見極めます。
横にスクロールして確認できます
| 期間 | 実施内容 | 確認する成果 |
|---|---|---|
| 1〜30日 | 生成AI利用の棚卸し、7工程への分解、L1〜L4分類、データ分類 | 隠れ利用・危険な運用・重複コストが見える |
| 31〜60日 | L2〜L3の1業務で、入力マスキング・根拠併記・承認・ログ付きの小規模検証 | 工数・品質・事故未遂・費用・利用率が測れる |
| 61〜90日 | 本番化条件、監査、教育、月次レビューの設計と判断 | 継続・拡張・停止の判断材料がそろう |
最初の30日は現状把握とリスクの見える化に集中します。ここで工程に落ちていない生成AI利用を全部台帳に載せるだけでも、内部監査・検査対応の準備が進みます。
FAQ
Q. 正式な統計モデルではないので、統制の対象外ではないですか。 A. 対象になるかどうかは業態・商品・利用のされ方で異なり、本稿では断定しません。ただし、正式なモデルでなくても、出力が顧客に届いたり判断に影響したりする工程では、後から説明を求められます。規制・監督の対象に入るかは所管当局の公表資料と顧問弁護士に確認しつつ、実務としては工程単位で証跡を残すのが安全です。
Q. 全件レビューは人手的に無理です。どうすればよいですか。 A. 全件を同じ深さで見る必要はありません。出力をL1〜L4の層に分け、顧客に届くL3と判断に近いL4に二次チェックと承認を集中させ、L1・L2は軽くします。層で確認の深さを変えるのが現実解です。
Q. 同じ入力でも出力が変わります。説明できるのですか。 A. 出力の一言一句は固定できませんが、入力・参照資料・プロンプト・修正・承認の過程を残せば、「人がどの根拠で採否を決めたか」は説明できます。再現すべきは出力ではなく判断過程です。
Q. 士業・金融の実務で生成AIを使い始めるとき、最初に決めるべき統制はどこですか。 A. ツール契約ではなく棚卸しからです。どの部署が、どの業務で、どのツールを、どの層で使っているかを一覧化し、リスクの低い1業務・1工程で統制を回してから広げます。
Q. どのデータをAIに入れてよいか分かりません。 A. 入力工程で3分類（渡してよい／マスキングして渡す／渡してはいけない）を先に決めます。氏名・生年月日・口座番号・病歴・契約情報・営業秘密は、入力前に置換・削除する運用を工程に組み込みます。学習利用の有無や保存期間はSaaS側にも確認します。
Q. 士業の守秘義務との関係はどう考えればよいですか。 A. 守秘義務や成果物責任の範囲は、所属する会・連合会の会則や指針、顧問弁護士の判断が優先します。本稿では断定しません。実務としては、顧問先情報を入力工程でどう扱うか、成果物のレビューと承認を誰が担うかを工程で決めておくと、確認・説明がしやすくなります。
Q. ログさえ残せば監査は通りますか。 A. 出力ログだけでは不足しがちです。入力のマスキング、参照した資料の版、承認者と根拠まで残して初めて、検査・監査・顧客照会に筋の通った説明ができます。
導入前に、自社で整理しておく論点
- 生成AIを使っている業務を7工程に分けたとき、どの工程が誰の担当か決まっていない箇所はどこか
- 現在その業務は、どのSaaS・Excel・メール・チャット・紙・口頭で回っているか
- 顧客情報・要配慮個人情報・営業秘密・契約情報・資格情報は、どの工程で混入するか
- 失敗した時に、売上・利益・信用・法務・監督官庁対応へどの影響が出るか
- すでに契約しているベンダー・SaaS・開発会社・保守会社との責任分界は工程単位で明確か
- 出したい成果物は、工程分解表・データ分類表・RFP・利用規程・PoC計画・費用試算のどれか
これらを工程単位で答えられる会社は、導入可否の判断が速くなります。答えられない箇所こそ、外部の第三者診断で工程を整理すべき論点です。
あわせて読みたい記事
- 士業の生成AI利用ルール整備ガイド2026（守秘義務・顧問先情報の線引き）
- 情報漏えい社内ルール作成のRFP要件・評価軸・契約条件
- AIエージェント導入で法務が確認すべき5つの責任分界
- 生成AI社内ガバナンスの設計（利用統制・監査ログ・情報分類）
- AI導入可否のアセスメント
まとめ：統制は工程に、深さは層に
金融・保険・士業の生成AI統制は、方針書や利用規程を掲げるだけでは動きません。入力・前処理・生成・レビュー・確定・保存・顧客提供という工程ごとに、誰が何をどの深さで確認するかを実装して初めて、後から「なぜそうしたか」を説明できます。全件は見られないので、出力をL1〜L4の層に分け、顧客に届くものと判断に近いものへ確認を集中させます。まずは棚卸しで工程とツールを可視化し、リスクの低い1業務・1工程で回してから広げてください。工程・データ・権限・費用・承認・ログ・契約条件を1枚に並べられない場合は、導入前に工程の整理と統制設計の支援を受ける価値があります。
参考・出典
いずれも2026年7月10日にアクセスを確認。一次情報（公的機関・標準）とプレプリント（査読前）を区別して記載します。プレプリントは確定した規範ではなく、参照時点の議論として扱ってください。
- （プレプリント／査読前）arXiv: Governing Generative AI Across Financial Institutions（2607.04103） https://arxiv.org/abs/2607.04103
- （プレプリント／査読前）arXiv: Agent Security Meets Regulatory Reality（2606.29142） https://arxiv.org/abs/2606.29142
- （一次・標準）NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- （二次・コミュニティ標準）OWASP GenAI Security Project: https://genai.owasp.org/
- （一次・公的機関）経済産業省 AI事業者ガイドライン: https://www.meti.go.jp/policy/it_policy/ai_guideline/
- （一次・公的機関）個人情報保護委員会: https://www.ppc.go.jp/personalinfo/
