「顧客の情報をAIに入れて大丈夫なのか」──役員にそう問われて、明確に答えられる担当者は多くありません。この記事は、その問いに答える立場にある情報システム・法務・AI推進担当の方に向けて書いています。
はじめに言葉の整理をします。「AIセキュリティ」には3つの意味が混在しています。①企業がAIを利用する際のリスク対策、②AIを活用したセキュリティ製品、③AIモデルそのものへの攻撃と防御、の3つです。本記事が扱うのは①、なかでも判断がいちばん難しい「データを渡してよいか」の問題です。
結論を先に示します。
企業のAIセキュリティ対策の核心は、「ベンダーを信じるか」ではなく、「どの契約で・どのデータを・どの経路で渡すか」を設計することにある。「学習に使わない」という約束は、契約・言葉の範囲・法域・検証可能性の4つの層に分けて確認する。
「信頼できるかどうか」を議論している限り、答えは出ません。本記事では、この4つの層の中身と、機密情報・顧客データを守る「経路設計」の実務を、順を追って解説します。
結論：AIセキュリティは「信じるか」ではなく「設計するか」
改めて、本記事の結論です。
企業のAIセキュリティ対策の核心は、「ベンダーを信じるか」ではなく、「どの契約で・どのデータを・どの経路で渡すか」を設計することにある。「学習に使わない」という約束は、契約・言葉の範囲・法域・検証可能性の4つの層に分けて確認する。
対象は、クラウド型の生成AIとAIエージェントの業務利用です。読み終えたとき、「AIを使ってよいか」という漠然とした問いが、「このデータは、この契約・この経路なら渡せる」という設計の問いに変わることを目指します。
そのまま使える：役員への30秒回答
ご質問の「AIに顧客情報を入れて大丈夫か」は、契約と経路で答えが変わります。第一に、無料版と法人契約は別物で、法人契約では入力データを学習に使わせない条件を結べます。第二に、当社のデータを機密度で分類し、機密度に応じて使ってよい経路を決めれば、安全に使えます。いま、その分類と経路のルールを設計しています。
AIセキュリティリスクの全体地図──入力・出力・実行・運用
対策の前に、リスクの全体像を4つに整理します。自社の議論がどこで詰まっているのかを、まず特定してください。
入力側のリスク：データ漏洩と学習利用
入力したデータがベンダー側に渡り、保存され、場合によってはAIの学習に使われるリスクです。機密情報や顧客情報が関わるため、経営の意思決定論点としては最大です。本記事の主題はここです。
出力側のリスク：誤情報と権利侵害
AIの回答に誤り（ハルシネーション）や、他者の著作物に似た表現が含まれるリスクです。性質としては品質管理の問題で、出力を人が確認するプロセスで対処します。
実行側のリスク：AIエージェントへの攻撃
自律的に業務を遂行するAIエージェントは、「人が誤用する」リスクに加えて、「システム自体が騙される」リスクを持ち込みました。代表例がプロンプトインジェクション──AIが読み込む文書やメールの中に悪意ある指示を仕込み、データの持ち出しや不正な操作をさせる攻撃です。AIが業務の実行主体になるという転換そのものについては、AXとは？AIトランスフォーメーションの定義とDXとの違いで解説しています。
運用側のリスク：シャドーAI
従業員が、会社の許可していないAIサービスを業務で使ってしまう問題です。対策の主管は組織設計の話になるため、ガイドラインとガバナンスを主題とする続編で詳述しますが、先に要点だけ言えば、原因は従業員の規律ではなく「正規ルートの遅さ」にあります。
この4象限の根にあるのは、3つの構造変化です。第一に、AIベンダーにとって利用者のデータが「学習の燃料」という価値を持ち、預かる側に使う動機が生まれたこと。第二に、プロンプトが自由記述で、契約書でもソースコードでも何でも入ってしまう、事前のデータ分類が効きにくい入力口であること。第三に、AIが業務の実行主体となり、それ自体が攻撃対象になったこと。以降は、このうち意思決定の核心である入力側──「データを渡してよいか」を深掘りします。
「秘密を預ける」は電信の時代からの古典問題
実はこの問題、AIが初めてではありません。
19世紀、企業は電報で商取引を行うようになりました。そのとき直面したのが、「電信局員に商談の中身を読まれるのではないか」という、今とまったく同型の不安です。当時の解決策は3つありました。第一に、自衛の技術。企業は商用コードブック（符号帳）で文面を暗号のような符号に変えてから送りました。今日のマスキングや仮名化の先祖です。第二に、制度。通信の秘密が法律で保護されるようになり、日本でも憲法と電気通信事業法に受け継がれています。今日の契約・データ保護条項の先祖です。第三に、事業者の経済的インセンティブ。顧客の秘密を漏らす電信会社は信用を失い、市場から退場する──約束を守らせる最後の力は、この仕組みでした。
つまり「第三者に秘密を預けて仕事をする」という問題の解法は、150年前にほぼ出揃っています。技術・契約・法・インセンティブの組み合わせで管理する。生成AIは、この古典問題の最新形にすぎません。次章の「4つの層」は、この知恵をAI向けに並べ直したものです。
「学習に使わない」を4つの層で検証する
ベンダーは「入力データを学習に使いません」と言います。この約束をどう評価すべきでしょうか。「信じる／信じない」の二択ではなく、4つの層に分けて確認します。
層1：契約──無料版と法人契約は別物
まず、自社がどの契約で使っているかです。個人向けの無料プランでは、入力データの学習利用が初期設定で有効（利用者が設定で外す「オプトアウト」方式）になっていることが多い一方、法人向けプランやAPI契約では、学習に使わないことが契約条項として明記され、データ処理に関する取り決め（DPA）や保持期間の限定を結べます。
問うべきは「ベンダーが嘘をつくか」ではなく、「自社はどの契約に署名したか」です。ここが曖昧なまま「AIは危険だ」と議論している会社が、実は少なくありません。
層2：言葉の範囲──「学習しない」≠「保存しない」≠「人が見ない」
次に、約束の言葉が何を含み、何を含まないかです。「学習に使わない」は、多くの場合「保存しない」ことも「人間が見ない」ことも意味しません。不正利用の監視のために一定期間ログを保持する、安全性のレビューで担当者が内容を確認することがある──こうした条項は、学習利用とは別枠で存在します。
さらにその上位に、司法があります。米国では著作権をめぐる訴訟の証拠保全のため、裁判所がAI事業者に利用者ログの保持を命じた実例があり、ベンダーの約束の上に裁判所の命令が乗ることが実証されました。契約や規約を読むときは、「学習」「保存」「人的レビュー」「法的要請への対応」を、別々の項目として確認してください。
層3：法域──法律はベンダーの誠実さの上位に立つ
ベンダーがどれほど誠実でも、自分が従う法律を選ぶことはできません。米国の事業者には、政府が国外保存データの提出を求め得るCLOUD Act（2018年）が、中国の事業者には、国家の情報活動への協力を組織に義務づける国家情報法（2017年施行）が、それぞれ乗ります。
つまり「ベンダーを信頼できるか」という問いの一部は、そもそも企業の善意では答えられない、法域の問題です。データを渡す先を評価するときは、企業とあわせて、その企業が属する法制度を見る必要があります。
層4：検証の限界と、それでも約束が守られる理由
最後に、検証可能性です。SOC 2やISO 27001といった認証は、管理プロセスの第三者監査であって、「学習に使っていない」ことの技術的な証明ではありません。外部から完全に検証する手段は、現状ありません。
この残った不確実性を埋めるのが、経済的インセンティブの分析です。法人事業が収益の柱であるベンダーにとって、契約違反の発覚は事業の存亡に関わる損失であり、一顧客のデータから得られる学習価値をはるかに上回ります。約束を破る動機より、守る動機のほうが構造的に大きい──電信会社と同じ力学です。裏を返せば、この力学が働かない相手、たとえば無料サービスや収益基盤の弱い事業者ほど、約束の重みは軽くなります。
そのまま使える：ベンダー確認チェックリスト
契約・規約で確認すべき観点は次の6つです。製品を問わず使えます。
- 学習利用の有無とその方式（オプトアウトか、契約で不使用か）
- 入力データの保存期間と削除の扱い
- 人的レビューの範囲
- 準拠法・裁判管轄と、データの保管場所
- 法的要請（政府・裁判所）への対応方針
- 再委託先の有無とその管理
情報漏洩を防ぐ経路設計──データ4分類×許容経路マトリクス
4つの層を確認したら、次は自社側の設計です。原則はシンプルで、「送らない」を基本に、送るなら「分類してから、決められた経路で」。
なお、データを機密度で分類して扱いを変えるという規律は、政府の機密区分以来、数十年使われてきた情報管理の古典であり、AI向けの新発明ではありません。既存の情報資産管理規程があれば、その分類をそのまま土台にできます。
| データ分類 | 例 | 許容経路の目安 |
|---|---|---|
| 公開情報 | プレスリリース、公開済みのWeb記事 | 制約なし（無料版を含む） |
| 社内一般 | 一般的な社内文書、議事メモ | 学習不使用が契約された法人サービス以上 |
| 機密 | 営業秘密、未公開の財務・技術情報 | 専用テナント型以上 |
| 顧客個人情報・要配慮情報 | 氏名・連絡先、健康情報など | マスキング・仮名化のうえ専用テナント型以上、または自社ホスト型 |
経路の類型は4つです。①コンシューマ型（個人向けの画面から使う）、②法人契約型（学習不使用などを契約したサービス）、③専用テナント型（自社のクラウド契約の境界内でAIモデルを呼び出す方式）、④自社ホスト型（自社インフラでモデルを動かす）。
例示：専用テナント型には、大手クラウド事業者が法人向けに提供するAI基盤サービスがあります。製品名や提供条件は変化が速いため、選定時には必ず最新の一次情報（各社の規約・DPA）を確認してください。
顧客個人情報の法的整理──「委託」で収まる条件
日本の個人情報保護法では、学習に使わせず、保持も処理に必要な範囲に限定した利用であれば、クラウドAIの利用を「委託」の枠組みで整理しやすくなります。逆に、ベンダー側の学習利用を許すと、委託の範囲を超えて、第三者提供や目的外利用の論点が立ちます。個人情報保護委員会も、生成AIサービスの利用について注意喚起を出しています。
ここは条文解釈が絡むため、最終判断には必ず法務・専門家の確認を挟んでください。重要なのは、エンタープライズ契約がセキュリティだけでなく、法的整理の前提条件でもあるという点です。
技術の要点は3つ
第一に、ゲートウェイの一本化。全社のAI利用を一つの出入口に集約し、そこにDLP（個人情報や機密語句を自動で検知してマスクする仕組み）とログを置きます。ルールを人の注意力に頼らず、経路の構造で守らせる発想です。
第二に、社内ナレッジの活用はRAG（検索拡張生成。AIが回答のたびに自社の文書を検索して参照する方式）で行い、データ本体は自社のストレージに留めます。モデルにデータを覚え込ませる方式より漏洩面が小さく、削除やアクセス権限の管理も効きます。
第三に、生の顧客データでの学習・チューニングはしない。この3つで、入力側リスクの大半は構造的に抑えられます。
オープンソースAI・自社ホストという選択肢──「OSSなら安全」の誤解と使い所
「クラウドに預けるのが不安なら、自社でAIを動かせばよいのでは」。当然の発想で、実際に有力な選択肢です。ただし「自前で持つか、借りるか」は、オンプレミス対クラウドという情報システムの古典論争の反復であり、答えが二者択一ではなくワークロード別の使い分けに落ち着くのも、歴史のとおりです。
用語の整理：「オープンソース」と「オープンウェイト」は別物
はじめに用語から。世間で「オープンソースAI」と呼ばれるものの多くは、正確にはオープンウェイト──モデルの重み（学習済みパラメータ）が公開されているだけで、学習データや開発コードまで公開されているとは限りません。また、重みが公開されていても、利用条件を独自ライセンスで制限しているモデルが混在しており、従来のオープンソースの定義を満たすとは限りません。商用利用の可否は、モデルごとにライセンスを確認するのが原則です。
本質的な利点：データがどこにも出ない
セキュリティ上の最大の利点は明快です。自社インフラで動かせば、データが社外に一切出ません。学習利用のリスクも、前章までの法域リスクも、構造的に消滅します。閉域網やオンプレミスの要件がある業種にも適合します。
この観点で重要なのが、供給元の国籍の切り分けです。海外のホスト型サービスにデータを送ることと、公開された重みを自社インフラで動かすことは、リスク構造がまったくの別物です。後者では、データは出ていきません。残る論点は重みの出所やライセンスであって、法域リスクではない。供給元の国だけを理由に一律排除すると、コスト性能で有力な選択肢を捨てることになります。
それでも「OSSなら安全」ではない：守る主体が自社に移る
一方で、「オープンソースだから安全」という通説は誤解です。正確には、リスクが消えるのではなく、守る責任がベンダーから自社に移ります。
コストの本体はGPUではなく運用です。推論基盤の保守、次々に出る新モデルへの追随、モデルを動かす提供ソフトウェアの脆弱性管理。加えてOSS固有の論点として、重みの出所検証（配布経路で改変されていないか）と、ライセンス適合の確認が自社の仕事になります。「借りるリスク」が消えて「所有するリスク」が生まれる──この対価関係を理解したうえで選ぶものです。
使い所：全面自前化は誤答になりやすい
したがって、全面自前化は多くの企業にとって誤答です。効くのは部分自前化で、条件は3つ。①最高機密度データの処理、②大量・定型でコスト最適化が効くタスク、③閉域・オンプレミスの要件がある業務。前提はクラウドとの併用であり、それを実務で可能にする仕組みが、次章のゲートウェイです。
進化に遅れないための設計原則
セキュリティを固めるほど、もう一つの不安が顔を出します。「守りを優先して、競合に遅れないか」。この二律背反を解くのが、次の原則です。
「能力の所在」と「データの所在」を分離する
すべてを自社に閉じれば安全ですが、最先端のAI能力から取り残されます。競合が最新モデルで生産性を積み上げる間、自社だけ数世代前の能力で戦うことになる。逆に、無防備にクラウドへ流すのは論外です。解は、前章までの分類×経路の設計によって、「最先端の能力を、露出を限定して使う」こと。守りと速さは、経路設計によって両立します。
ゲートウェイによる抽象化──「企業版AI主権」
それを支えるのがゲートウェイです。アプリケーションや業務をモデルに直結させず、ゲートウェイ越しに使う構成にしておけば、モデルの提供元がどこであれ、新しいモデルへ短期間で差し替えられます。特定ベンダーへの構造的な従属を避けつつ、進化の速度には乗る──国の政策で言う「AI主権」（政府のAI戦略の中核概念。解説記事）の、企業版と言える設計です。
最大の漏洩経路は、高度な攻撃ではなく「遅い正規ルート」
最後に、忘れてはならない事実を。実際の情報流出の多くは、高度なサイバー攻撃ではなく、遅くて不便な正規ルートに痺れを切らした従業員の個人アカウント利用から起きます。速くて安全な公式の経路を先に用意することが、最強のセキュリティ施策です。この組織側の設計──ガイドラインとガバナンス──は、続編の記事で詳しく扱います。
直近の動向（最終更新：2026年7月）
- 法人向けプランでの「学習不使用・保持期間の限定」は、主要ベンダーで標準化が進んでいます
- 専用テナント型サービスと、企業利用に耐えるオープンウェイトモデルの選択肢は拡大傾向にあります
個別サービスの最新条件は、契約前に必ず一次情報（各社の利用規約・DPA）で確認してください。
AIセキュリティに関するよくある質問
Q1. AIセキュリティ対策は、何から始めるべきですか？
企業のAIセキュリティ対策の核心は、「ベンダーを信じるか」ではなく、「どの契約で・どのデータを・どの経路で渡すか」を設計することにある。「学習に使わない」という約束は、契約・言葉の範囲・法域・検証可能性の4つの層に分けて確認する。──実務の最初の一歩は、データの4分類と許容経路の決定です。
Q2. オプトアウト設定をすれば、無料版でも安全ですか？
学習利用は止められますが、保存・人的レビュー・法的要請への対応は残ります。業務利用であれば、学習不使用が契約条項になっている法人契約が前提です。
Q3. データセンターが日本国内にあれば安心ですか？
保管場所と法域の管轄は別問題です。データの物理的な所在が国内でも、事業者が外国法の適用を受ける場合、その国の提出要請などが及ぶ可能性があります。「どこに置くか」と「誰の法律が及ぶか」を分けて確認してください。
Q4. SOC 2やISO認証があれば信頼できますか？
認証は管理プロセスの監査であり、「学習に使っていない」ことの技術的な証明ではありません。判断材料の一つとして扱い、契約条項・経済的インセンティブとあわせて評価します。
Q5. 海外製・中国製のAIは使ってはいけませんか？
一律の禁止は合理的ではありません。見るべきは国籍ではなく経路です。法域リスクが乗るのはホスト型サービスへのデータ送信であり、公開された重みを自社インフラで動かす場合、データは社外に出ません。
Q6. オープンソースのAIなら安全ですか？
データを外に出さない点では構造的に有利ですが、「安全になる」のではなく「守る主体が自社に変わる」が正確です。基盤の運用、脆弱性管理、重みの出所検証、ライセンス確認の責任を自社が負います。
Q7. プロンプトインジェクションとは何ですか？
AIが読み込む文書・Webページ・メールなどに悪意ある指示を紛れ込ませ、AIに意図しない動作（情報の持ち出しや不正な操作など）をさせる攻撃です。自律的に動くAIエージェントを導入する際は、権限の限定と人の監督ポイントの設計が必須になります。
Q8. 生成AIに顧客情報を入力してもよいですか？
原則は入力しないことです。業務上必要な場合は、マスキング・仮名化を施したうえで、学習不使用と保持限定が契約された経路（専用テナント型以上）に限定します。法的整理には法務の確認を挟んでください。
Q9. 万一漏洩したら、責任は誰にありますか？
契約と経緯によりますが、顧客や社会に対する説明責任は利用企業が免れません。だからこそ、契約の確認と経路の設計を「事前に」行うことが、対策の中心になります。
まとめ：分類と経路を決めた企業だけが、安心してアクセルを踏める
AIセキュリティ対策の核心は、信じるか否かの二択ではなく、契約・データ分類・経路の設計にあります。「学習に使わない」を4つの層で検証し、4分類×経路のマトリクスを自社の規程に落とす──ここまでやった企業は、守りを理由に立ち止まる必要がなくなります。本記事のマトリクスとチェックリストは、そのまま社内資料としてお使いください。
一次資料・参考文献
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」
- 米国 CLOUD Act（Clarifying Lawful Overseas Use of Data Act、2018年）
- 中国 国家情報法（2017年施行）
- 総務省・経済産業省「AI事業者ガイドライン」
- 関連記事：AXとは？AIトランスフォーメーションの定義とDXとの違い
コメント