この記事で分かること
- 生成AIに入力してはいけない情報の「3＋1区分」（未公表重要事実・営業秘密・個人情報・自社の非公開経営情報）と、その理由
- 一般向けサービス・法人契約・オンプレ等、利用環境による扱いの違いと確認すべき公式仕様のポイント
- 迷ったときに使える判定フローチャートと、実務でよくある3つのケースの当てはめ方
- 社内規程に盛り込むべき項目（許可ツール・禁止情報・ログ・レビュー体制・Audit Trail）と違反時の対応
結論：判断軸は「情報の性質」×「利用環境」の2つ。迷ったら入力しない
生成AI（Generative AI）を金融実務で使うときの機密管理は、突き詰めると2つの軸で判断できます。1つ目は「その情報がどの区分に属するか」です。①未公表の重要事実、②営業秘密・取引先機密、③個人情報、そして④自社の非公開経営情報――この「3＋1区分」に該当し得る情報は、原則として外部の生成AIサービスに入力しない、というのが保守的かつ実務的な出発点になります。
2つ目は「どの利用環境か」です。同じ情報でも、入力内容が学習に使われ得る一般向けサービスと、契約で学習利用が明確に否定されている法人向け環境とでは、リスクの水準がまったく異なります。ただし、法人契約であれば何を入れてもよいわけではありません。守秘義務やインサイダー情報の管理は、AIベンダーとの契約とは別の問題として残るからです。
そして最も重要なのは、最終的な可否を決めるのは本記事ではなく、皆さんの会社の規程だという点です。本記事は判断の枠組みと社内ルールの設計方法を整理するものであり、個別の適法性判断は必ず自社の法務・コンプライアンス部門に確認してください。
なぜ金融実務ではAI利用ルールが特に必要なのか
生成AIの多くはクラウド型のサービスであり、プロンプトに入力した文章は社外のサーバーに送信されます。サービスや契約形態によっては、入力内容がモデルの学習（トレーニング）に利用されたり、一定期間ベンダー側に保持されたりする場合があります。つまり「AIに聞く」という行為は、情報管理の観点では「社外の第三者に情報を渡す」行為と同じ枠組みで考える必要があるのです。
金融実務がとりわけ慎重さを求められるのは、扱う情報の機密の密度が高いからです。M&Aや決算に関わる未公表情報はインサイダー取引規制の文脈に触れ得ますし、顧客の資産・取引情報は個人情報保護法制の対象になり得ます。取引先から預かる資料の多くは秘密保持契約（NDA）で守られています。ルールがないまま利用を放置すると、判断が個々の担当者に委ねられ、悪意のない一回の入力が会社全体の信用問題に発展しかねません。
規制当局もこの領域への関心を高めています。金融庁は2025年3月に「AIディスカッションペーパー」を公表し、2026年3月には第1.1版へ改訂して、金融機関等におけるAIの活用実態とリスク管理・ガバナンスの論点を整理しています。禁止ではなく「健全な利活用の促進」が基調である点も重要で、「使わない」ではなく「安全に使う仕組みを作る」ことが実務の方向性といえます。生成AIの業務活用の全体像は金融実務での生成AI活用入門で解説していますので、本記事はその中の機密管理を深掘りする位置づけです。
守るべき情報の「3＋1区分」
入力可否の判断で核になるのが、次の4つの情報区分です。前半の3つは法令・契約に直接関わる区分、最後の1つは法令上の義務がなくても守るべき自社情報です。
① 未公表の重要事実（インサイダー規制の文脈）
上場会社の決算情報、M&A、業務提携、増減資などの未公表情報は、金融商品取引法のインサイダー取引規制における「重要事実」に該当し得ます。該当性の判断そのものが専門的な論点であるため、実務では「該当し得る情報はそもそも社外のシステムに出さない」という保守的な線引きが基本です。生成AIへの入力が直ちに規制違反となるかどうかは状況によりますが、情報管理体制の観点からは、伝達経路を1つ増やす行為自体がリスクと評価され得ます。インサイダー規制と大量保有報告書など開示制度の全体像はインサイダー規制と大量保有報告の基礎で整理しています。
② 営業秘密・取引先機密（守秘義務契約の対象）
不正競争防止法上の「営業秘密」として保護されるためには、秘密管理性・有用性・非公知性の3要件を満たす必要があるとされています。学習利用の可能性がある外部サービスへ無造作に入力する運用は、この秘密管理性の評価に悪影響を与え得るという指摘があります。また、デューデリジェンス（DD）の対象会社資料のように取引先から預かった情報は、NDAにより利用目的と開示範囲が契約で制限されているのが通常です。AIベンダーという「第三者」への提供が契約上許されるかは、契約文言の解釈問題であり、担当者の独断で判断すべきではありません。
③ 個人情報（個人情報保護法の文脈）
顧客や従業員の氏名・口座情報・取引履歴などは個人情報保護法の規律を受けます。個人情報保護委員会は2023年6月2日付で「生成AIサービスの利用に関する注意喚起等」を公表し、あらかじめ本人の同意を得ることなく個人データを生成AIに入力し、それが応答の出力以外の目的（学習等）で取り扱われる場合には、同法の規定に抵触する可能性があることを注意喚起しています。「名前を伏せたから大丈夫」と自己判断するのは危険で、匿名加工情報・仮名加工情報の要件は厳格です。個人データを扱う用途は必ず法務に確認してください。
④ 自社の非公開経営情報（＋1の区分）
予算、未公表の業績見込み、組織再編案、人事情報、システム構成などは、法令で直接保護されていなくても、漏えいすれば競争上・信用上の損失につながる情報です。法律要件に該当するかを一つずつ吟味するより、「社外秘」ラベルの付く情報はまとめて入力禁止区分に置く方が、現場が迷わないルールになります。
利用環境で扱いは大きく変わる（2026年8月1日時点）
同じ情報でも、どの環境の生成AIに入力するかでリスクは大きく変わります。確認すべきポイントは主に3つ、「学習利用の有無」「データ保持期間と場所」「管理者によるログ・統制機能」です。
一般向けの無料サービスや個人アカウントでは、設定やプランによって入力内容がモデル改善（学習）に利用される場合があります。業務情報の入力は避け、そもそも業務利用自体を許可制にするのが一般的です。
法人契約では、入力データを基盤モデルの学習に使わないことを契約や公式仕様で明示する例が主流になっています。たとえばMicrosoftはMicrosoft 365 Copilotについて、プロンプト・応答・Microsoft Graph経由のデータを基盤モデルの学習に使用しないと公式ドキュメントに明記しています。AnthropicもCommercial Terms of Serviceにおいて、商用サービスの顧客コンテンツをモデルの学習に使用しない旨を定めています。ただし、これらの仕様・契約条件は変更され得ます。本記事の記載は2026年8月1日時点の公式ページの確認に基づくものであり、導入時・更新時には必ず各社の最新の公式ドキュメントと自社の契約書を確認してください。
オンプレミスや閉域網での運用は、データが自社統制下に置かれる点で最も保守的な選択肢ですが、それでもアクセス権限の設計やログ管理といった社内統制は別途必要です。環境の種類にかかわらず、「未公表の重要事実は入力しない」のような情報区分側の禁止は維持するのが実務的です。
判定フローの実践例：よくある3つのケース
図1のフローを、実務で頻出する3つの場面に当てはめてみます。
ケース1：公表済みの有価証券報告書を要約・分析させる → 利用可（条件付き）
すでにEDINETで公表された有報は公開情報であり、Q1〜Q4はいずれも「いいえ」です。残る論点はQ5のみ、つまり会社が許可したツールかどうかです。許可ツールであれば、出力の数値を原文と突合するレビューを前提に、有効な活用場面といえます。
ケース2：DD中の対象会社資料をアップロードして要約させる → 入力不可
売り手からNDAのもとで開示された資料は、Q2（取引先機密）とQ4（契約上の守秘義務）に該当し得ます。さらに対象会社が上場企業であれば、案件の存在自体がQ1の未公表重要事実に触れ得ます。フローの早い段階で複数回「はい」に到達するため、法人契約の環境であっても入力すべきではなく、例外を検討する場合は案件責任者と法務の明示的な承認が必要です。
ケース3：顧客リストを渡して営業メールの文面を作らせる → 入力不可
顧客の氏名や属性を含むリストは個人データに該当し得るため、Q3で止まります。メール文面の生成自体は有用な用途なので、顧客を特定できる情報を除いた「架空の宛先・属性パターン」でひな形を作らせ、実際の宛名は社内システム側で差し込む、という切り分けが現実的な代替策になります。
社内規程（AI利用ガイドライン）に入れるべき項目
ルールは「禁止の列挙」だけでは機能しません。現場が迷わず使えるよう、次の要素をセットで規程化するのが実務的です。
| 項目 | 規定する内容の例 |
|---|---|
| 許可ツールの特定 | 利用してよいサービス・プランをホワイトリスト方式で列挙し、個人アカウントでの業務利用を禁止する |
| 禁止情報の定義 | 本記事の3＋1区分をベースに、自社の具体例（商品名・帳票名）まで落とし込む |
| 利用ログ・Audit Trail | 誰が・いつ・何の業務で利用したかを追跡できる記録（監査証跡）を残し、定期的に点検する |
| 出力のレビュー体制 | AI出力をそのまま顧客提出物・開示資料に使うことを禁止し、人によるファクトチェックを必須にする |
| 教育・研修 | 入社時・年次で判定フローの演習を行い、判断に迷った場合の相談窓口を明示する |
| インシデント報告ルート | 誤入力に気づいた際の報告先と初動手順を定め、自己申告を不利に扱わない方針を明記する |
| 定期見直し | 各サービスの仕様・契約変更や法令・当局文書の更新に合わせ、少なくとも年1回は規程を見直す |
特に見落とされがちなのがAudit Trail（監査証跡）です。金融機関では「使ってよいか」だけでなく「使ったことを後から説明できるか」が問われます。法人向けプランの多くは管理者向けのログ機能を備えているため、ツール選定の段階でログの取得範囲と保存期間を確認しておくと、規程の実効性が大きく変わります。
Model Risk と Human-in-the-Loop の考え方
機密管理と並ぶもう1つの柱が、出力の誤りに対する統制、いわゆるモデルリスク（Model Risk）管理です。生成AIは事実と異なる内容をもっともらしく出力すること（ハルシネーション）があり、金融庁のAIディスカッションペーパーでも、リスク管理・ガバナンスの構築は主要な論点として整理されています。
実務の原則はHuman-in-the-Loop（人間の関与）、つまり最終判断と成果物の責任は常に人間が持つという設計です。AIの出力は「下書き」または「たたき台」として扱い、数値は原典と突合し、法令・契約に関わる記述は専門部署の確認を経る。この役割分担を明文化しておくことで、「AIがそう言ったから」という責任の空白を防げます。AIモデルの検証・レビューの具体的な進め方はAIモデルレビューの実務で詳しく解説しています。
違反（誤入力）が起きたときの対応
どれだけルールを整えても、誤入力をゼロにはできません。重要なのは初動です。
第一に隠さず直ちに報告すること。時間が経つほど対応の選択肢は減ります。第二に事実の特定です。何の情報を・どのサービスの・どのアカウントで・いつ入力したかを確定します。第三にベンダー側での削除可否の確認です。法人契約では入力履歴の削除やデータ保持期間の設定が可能な場合があります。第四に影響評価と法定対応の検討です。個人データの漏えいに該当し得る場合は、個人情報保護法上の報告・通知義務の要否を法務・コンプライアンス部門が判断します。取引先機密であれば、契約上の通知義務の有無も論点になり得ます。最後に再発防止として、規程・研修・システム制御（DLPツールによる入力制限など）のどこに穴があったかを検証します。
制度設計上のポイントは、自己申告を過度に処罰しないことです。報告した人が損をする制度では誤入力は隠され、会社は最も知りたい情報を失います。
面接での答え方（30秒回答例）
Q：業務で生成AIを使う際、機密情報の扱いで何に気をつけますか？
「情報の性質と利用環境の2軸で判断します。未公表の重要事実、取引先の機密、個人情報、自社の非公開情報は、原則としてAIに入力しません。利用する場合も、会社が許可した学習利用のない法人環境に限定し、出力は必ず原典と突合してから使います。判断に迷う情報は入力せず、法務・コンプライアンスに確認するのが基本動作だと考えています。」
よくある質問（FAQ）
Q. 顧客名を伏せ字にすれば、顧客データを入力してもよいですか？
A. 自己流のマスキングでは不十分な場合があります。氏名を伏せても、他の情報と照合して個人を識別できる状態であれば個人情報に該当し得ますし、個人情報保護法の匿名加工情報・仮名加工情報には厳格な加工基準と義務が定められています。「伏せ字にしたから大丈夫」と現場で判断せず、加工の方法と可否を法務・コンプライアンス部門に確認してください。
Q. 法人契約で「学習に使わない」と明記されていれば、何を入力しても問題ありませんか？
A. 学習利用の有無は論点の1つにすぎません。学習に使われなくても、NDAで第三者提供が制限された情報の入力は契約違反となり得ますし、未公表の重要事実は情報管理体制の観点から入力しない運用が保守的です。また、ベンダー側でのデータ保持期間や不正利用監視のためのアクセスの有無など、学習以外のデータ取扱いも契約・公式仕様で確認する必要があります。
まとめ
生成AIの機密管理は、「情報の性質（3＋1区分）」と「利用環境」の2軸で判定する、というシンプルな枠組みに整理できます。未公表の重要事実・営業秘密・個人情報・自社の非公開経営情報は原則入力しない。利用環境は学習利用の有無・データ保持・ログ機能を公式仕様と契約で確認する。そして許可ツール・禁止情報・Audit Trail・レビュー体制・報告ルートを規程としてセットで整備する。この骨格ができていれば、生成AIは金融実務の強力な武器になります。禁止一辺倒でも野放しでもなく、「安全に使う仕組み」を先に作ることが、これからの実務者・管理部門に求められる標準スキルです。
出典・参考（2026-08-01確認）
- 金融庁「AIディスカッションペーパー（第1.1版）～金融機関等におけるAIの活用実態と健全な利活用の促進に向けた初期的な論点整理～」（2026年3月3日公表） https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日公表） https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- Microsoft Learn「Microsoft 365 Copilot と Microsoft 365 Copilot Chat でのエンタープライズ データ保護」 https://learn.microsoft.com/ja-jp/copilot/microsoft-365/enterprise-data-protection
- Anthropic「Commercial Terms of Service」 https://www.anthropic.com/legal/commercial-terms
※本記事は教育目的の一般的な解説であり、法務・税務・投資助言ではありません。個別の適法性・契約適合性の判断は、必ず自社の法務・コンプライアンス部門にご確認ください。各サービスのデータ取扱い仕様は2026年8月1日時点の公式ページの確認に基づくものであり、変更される場合があります。設例は理解のための仮設例です。