こんにちは。CData Software Japan リードエンジニアの杉本です。
CData では「CData Connect AI」という生成AI と自社のビジネスデータを組み合わせて活用できるマネージドMCP プラットフォームを提供しているため、日々生成AI と自社のビジネスデータの悩みを多くのお客様からお聞きします。
例えば、生成AIで業務を変えようとするとき、よくこんな会話が起きます。
担当者：「案件データをAIで分析して、営業提案やアジェンダ作成を自動化したい」 上司：「それ、データが外に出たり、AI に学習されるんじゃないのか？」 担当者：「…検討します」
そしてプロジェクトが止まる……。現場担当者は「AI でより業務を効率化しよう！」「ビジネスをスケールさせよう！」と思っているにも関わらず、辛いところですよね。
この記事は、この「止まる」を「動かす」ための内容として整理したものです。
ビジネスデータは適切な設計のもとであればAIで活用できます。そのための条件を整理し、担当者が社内を説得するための武器を揃えてみました。
「AI からデータを守る話」ではなく「AI でデータを使いこなすための話」として読んでいただければと思います。
前提：何が目標なのかを明確にする
まず、目標を整理してみましょう。
多くの企業が生成AIに期待していることは「AIに社内データを賢く使わせること」です。具体的には：
これらはすべて、ビジネスデータをAIに渡すことを前提としています。
「データを入れないでAIを使う」では、この目標は達成できません。目指すべきは「適切にコントロールされた形でデータを活用する」ことです。
なぜ「止まる」のか：懸念の構造を理解する
社内でAI活用が止まる理由は、いくつかの性質の異なる懸念が混在したまま議論されているからであると考えています。
生成AI の企業導入を検討する際、情報システム担当者や経営層から最も多く聞かれる懸念が次のような声です。
「学習に使わないとは言っているが、データが外に出ていることには変わりない」
「完全ローカルのAIにすべきではないか？」
「ビジネスデータを外部に送信するリスクが心配だ」
「データが外に出るのが怖い」という感覚の背景には、性質の異なる3つの懸念が混在していると言えます。
これを分解せずに議論すると、技術的な説明が感情的な懸念に届かないという問題が起き「やっぱりなんか不安」といった声に繋がってしまいます。
この懸念を分解すると以下のようになります。
# | 懸念の種類 | 性質 | 対処のアプローチ |
|---|
① | データが外部に送信されること自体への抵抗感 | 感情的・文化的 | アーキテクチャの可視化と信頼構築 |
② | 送信したデータがAIモデルの学習に使われるリスク | 契約・技術的に防止可能 | 公式ポリシー・契約条項の提示 |
③ | 送信したデータが漏洩・悪用されるリスク | セキュリティガバナンスで管理 | SLA・DPA・暗号化仕様の提示 |
①の「感情的抵抗」は技術的な説明では解決しません。まず「その不安は正当だ」と受け止めることが先決です。その上で、②と③は具体的な手段で対処できることを示します。
ただし重要なのは、「対処できるから使っても安全」で止めないことです。安全が確認できたら、次は「どう使うか」の設計に進む必要があります。
前提条件①：「学習」と「推論」は別の話
ここからは少し前提条件の理解を擦り合わせてきましょう。
まず最初に、多くの混乱の原因となっている用語の区別を整理します。
学習利用（Training）
→ データでAI モデルのパラメータを書き換える
→ エンタープライズ契約で「禁止」されている
推論利用（Inference / MCP / RAG）
→ データをプロンプトやMCP・RAG で参照させ回答を生成させる
→ これが本来の「やりたいこと」
「個人情報を入力すると学習に使われる」という懸念は、個人向け無償サービス（ChatGPT 無料版等）のイメージが原因ですね。エンタープライズ契約ではこのリスクは契約上排除されており、別の製品カテゴリです。
個人向け無償サービス：デフォルトで学習利用あり（オプトアウト可）
エンタープライズ契約：デフォルトで学習利用なし（契約上の禁止義務）
つまり「個人情報をAIに入れると学習される」という懸念は、エンタープライズ契約下では契約上排除されています。
実際にOpenAI・ChatGPT の利用規約では「コンテンツ情報」の章で以下のように触れられています。
https://openai.com/ja-JP/policies/row-terms-of-use/
本コンテンツ使用。当社は、本サービスの提供、維持、開発、改善、適用法の遵守、当社の規約及びポリシー等の履行請求、及び本サービスの安全性の維持のために、本コンテンツを使用する場合があります。
ただし、直後に重要な留保があります。
使用停止。当社モデルの学習にお客様の本コンテンツを使用することを望まない場合、[この記事](https://openai.com/policies/how-your-data-is-used-to-improve-model-performance/)の手順に従って使用停止を要求できます。当社の本サービスはお客様の特定の目的にそって処理されるものですが、場合によっては、そのよりよく処理する能力が制限されうることにご留意ください。
エンタープライズ契約（ChatGPT Enterprise / API）では、このオプトアウトが契約上デフォルトで適用済みになっているのが、個人向けとの最大の違いです。このリスクを契約上で排除した別の製品カテゴリと言っても良いでしょう。
https://openai.com/ja-JP/business-data/
前提条件②：エンタープライズ契約での法的保証
「学習利用禁止」が口頭の説明ではなく「契約書に明記された法的義務」であることを確認します。
これらは「デフォルトで学習しない」というポリシー説明ではなく、契約上の義務として明記されているものです。特にAnthropicは"may not"（してはならない）という最も強い表現を使っています。
前提条件③：データの流れを正確に理解する
「外に出る」イメージの誤解を解くために、実際のデータの流れを確認します。
❌ 誤解：データがコピーされてAI 企業のサーバーに蓄積・保存される
✅ 実際：
社内データ・プロンプト
↓（TLS暗号化による一時転送）
LLM API（処理のみ・保存なし）
↓
テキスト回答のみ返却
これはメールやクラウドストレージでのデータ共有と本質的に同じ仕組みです。
本題：ビジネスデータを適切に活用するための設計
前提条件が整ったところで、本題に入りましょう。
ビジネスデータを実際にAI活用するための設計です。
ステップ1：データを分類する
すべてのデータを同じように扱う必要はありません。まず社内のデータを種別に整理し、AI への入力条件を決めます。
データの分類方法は各社の業種・規模・社内規程によって異なりますので、以下はあくまで一例です。自社に合った分類を社内で整理した上で、AI 利用ポリシーに反映させてください。合わせて法的根拠も確認しておくと良いでしょう。
データ種別 | 対象データの例 | AI入力の可否・条件の例 |
|---|
一般情報 | 公開済み製品情報・社内規程等 | 制限なし |
社外秘情報 | 内部資料・会議議事録等 | エンタープライズ契約下で可 |
個人情報 | 顧客氏名・連絡先・購買履歴等 | 利用目的の確認＋エンタープライズ契約 |
NDA対象情報 | 取引先との機密情報 | NDA範囲の確認＋エンタープライズ契約 |
ステップ2：アクセス制御とガバナンス基盤を整備する
契約やポリシー的なところをカバーしたとしても、ビジネスデータのアクセスにはユーザー毎の権限や監査ログなどに基づいたガバナンスの確保が必要不可欠です。
これらは様々なアプローチでカバーすることができますが、「CData Connect AI」を例にあげると、ビジネスデータをAIに渡すための「パイプ」であるとともに、ガバナンス基盤として以下の役割を果たします。
3層のガバナンス機能：
アクセス制御：部門・役職ごとにアクセスできるデータを管理者が制限
監査ログ：誰がいつどのデータをAIに渡したかの完全なトレーサビリティ
データフィルタリング：特定カラム（要配慮個人情報等）を除外・マスクした上でAIに渡す
これにより「個人情報は一切AI禁止」という過剰な自主規制をかけることなく、適切にコントロールされた形でビジネスデータをAI活用する基盤が整います。
ステップ3：社内利用ポリシーを策定・公表する
経産省・総務省「AI事業者ガイドライン」（第2部C 7）⑤、AI利用者U-7）i）は、AI利用者に対して以下を求めています。
https://www.meti.go.jp/press/2024/04/20240419004/20240419004.html
「このデータはこの目的でAIに渡してよい」という社内ルールを文書化・公表することが、組織的なガバナンスの観点から重要なステップとなります。
「完全ローカルLLM」との比較
ちなみに「外に出さなければ安全」という考えから、完全ローカルLLMを検討する場合があります。リスク比較は以下の通りです。
比較観点 | エンタープライズクラウドAI | 完全ローカルLLM |
|---|
データの外部送信 | あり（暗号化・DPA保証） | なし |
モデル精度 | 高い（GPT / Claude等） | 低〜中（モデルサイズ依存） |
導入・運用コスト | 月額サブスクリプション | GPU調達・インフラ・保守が高コスト |
セキュリティ更新 | ベンダーが自動対応 | 自組織で継続対応が必要 |
コンプライアンス対応 | DPA・SLA・監査ログあり | 自組織で整備が必要 |
データ活用の精度・柔軟性 | 高い | 低い（モデル能力の限界） |
ローカルLLMは「データが外に出ない」点では有利ですが、そもそも活用したいユースケースを達成できないリスクがあります。精度・コスト・活用範囲の観点でトレードオフを正直に評価した上で判断してください。
国内の金融機関・医療機関・官公庁でもエンタープライズクラウドAI は採用されており、これは「リスクを無視した」判断ではなく「リスクを適切に管理した」判断というのがポイントかなと思います。
提案フレームワーク全体像
【目標の設定】
ビジネスデータをAIで活用して業務効率化する
↓
【前提条件の整備】（守りの話：ここをクリアして先に進む）
条件①：学習利用と推論利用を区別する
→ エンタープライズ契約では学習利用は契約上禁止されている
条件②：契約上の法的保証を確認する
→ Anthropic、Google、Microsoft、OpenAIいずれも明記済み
条件③：データの流れを正確に理解する
→ 一時転送・保存なし・暗号化
↓
【活用条件の設計】（攻めの話：ここが本題）
Step 1：データを分類する
→ 種別・AI 入力可否・条件を社内ルールとして整理
Step 2：アクセス制御とガバナンス基盤を整備する
→ CData Connect AI による制御・ログ・フィルタリング
Step 3：社内利用ポリシーを策定・公表する
→ AI事業者ガイドライン要件への対応
↓
【PoC実施・効果の数値化・本採用稟議】
参考リソース一覧
日本の公的ガイドライン
ドキュメント | 機関 | URL |
|---|
AI事業者ガイドライン（第1.2版） | 経産省・総務省 | Link |
テキスト生成AIの導入・運用ガイドライン | IPA | Link |
生成AIサービスの利用に関する注意喚起 | 個人情報保護委員会 | Link |
個人情報保護法 制度改正方針 | 個人情報保護委員会 | Link |
各サービスの公式セキュリティポリシー
※各サービスの利用規約・ポリシーおよび公的ガイドラインは随時更新されます。最新情報は各機関・ベンダーの公式サイトをご確認ください。
おわりに
ここまでClaude と一緒に内容としてまとめていく過程の中で、私自身も各社の契約書やDPA、総務省のAI 事業者ガイドラインを一通り確認しました。
その中で感じたのは、思った以上に各AI 事業社はAI 利用者側が抱く懸念点に対して契約書でもしっかり明記しようという姿勢がありましたし、また国自身もリスクとして恐れすぎるのではなく、リスクをうまく受容できるように管理して利益を最大化できるようにしていこうという方針をしっかりと打ち出しているんだなという点です。
「怖い」「なんか嫌だ」という感情はなかなか避けようが無いものですし、それを単純に否定したところで相手は守りの姿勢に入ってしまいがちです。ただ、それを適切に言語化し、管理可能なリスクとして評価できるようにすることで、うまく付き合っていける道筋があると思います。
このまとめた内容が皆さんの会社のAI プロジェクト推進の一助になってもらえると嬉しいです。
