経営者向け：データ漏えいを防ぐAI安全導入で既存ベンダーを変更する前に見る引き継ぎ条件

先に結論：AI安全導入のベンダー変更は「AIそのもの」ではなく「データがどこを通り、誰が止められるか」の移管で判断する

AI導入を支援した既存ベンダーを変更したい。PoCは動いた。社内検索、議事録要約、問い合わせ回答、営業資料作成、コード生成、文書レビューなどの利用も始まった。ところが、次のフェーズで別会社に相談しようとすると、既存ベンダーから渡される資料は、提案書、簡単な構成図、プロンプト例、利用マニュアルだけ。データがどこに保存され、どの外部APIへ送られ、誰が管理者権限を持ち、ログを誰が確認し、個人情報や顧客情報を入れた場合にどう止めるのかが見えない。

この状態でベンダーを変えると、新しい支援会社は「AI機能の再現」から始めてしまいます。しかし、経営者が本当に引き継ぐべきものは、AI機能ではありません。引き継ぐべきものは、データ漏えいを防ぐための設計、運用、証跡、責任分界です。

AIを安全に導入する時のデータ漏えいリスクは、ChatGPTやLLMに情報を入力する場面だけではありません。社内文書をRAGに入れる。CRMやSFAをAIエージェントへ接続する。議事録AIが会議音声を外部処理する。開発支援AIがコードやログを読み込む。クラウドストレージの共有リンクをAI要約へ渡す。問い合わせ履歴や契約書をAIで分類する。AI機能付きSaaSが裏側で外部モデルを呼び出す。こうした経路のどこかで、データ所在、権限、ログ、契約、教育が曖昧だと、ベンダーを変更した瞬間に管理が切れます。

結論は次の10点です。

1. AIモデルやプロンプトだけでなく、入力データ、参照データ、出力データ、ログ、学習・保持設定を引き継ぐ
2. 個人情報、顧客情報、契約情報、技術情報、営業情報、認証情報を分類し、AIへ渡せる範囲を明文化する
3. AIアプリ、RAG、AIエージェント、AI機能付きSaaS、クラウド共有、開発環境を分けて棚卸しする
4. 管理者権限、APIキー、サービスアカウント、外部連携、削除権限、エクスポート権限を一覧化する
5. DLP、CASB、監査ログ、SIEM、ID管理、端末管理との接続状況を確認する
6. 既存ベンダーの成果物権利、編集可能形式、第三者共有可否、設定エクスポート可否を契約前に確認する
7. インシデント時の発見、停止、証拠保全、影響範囲確認、外部連絡判断を引き継ぐ
8. 新ベンダーが再調査する範囲と、既存ベンダーが引き渡す範囲を30日以内に分ける
9. 60日以内に高リスクデータ経路と過剰権限を潰し、90日以内に月次運用へ移す
10. 「AIを入れるか」ではなく「漏えいした時に止められるか、説明できるか、戻せるか」で判断する

本記事は、AIを安全に導入したい企業が、データ漏えい対策を含む既存ベンダー支援を別会社へ変更・併用・再設計する段階に絞ります。これから初回見積を取る記事ではありません。正式RFPを作る記事でもありません。AI導入済み、またはPoCから本番化へ進む会社が、既存ベンダーから何を回収し、何を新ベンダーに渡し、どこを再設計すべきかを見る記事です。

この記事を読むべき会社

この記事は、AI導入、生成AI活用、社内検索、RAG、AIエージェント、AI機能付きSaaS、議事録AI、文書要約、問い合わせ対応、コード生成、データ分析などを既存ベンダーと進めた後、データ漏えいを防ぐ安全設計を別会社へ移したい中小・中堅企業の経営者、CIO、DX責任者、情シス責任者、セキュリティ責任者、管理部門、法務向けです。

特に、次の状態なら本記事の検索意図に合います。

• AI導入支援を受けたが、データ漏えい対策の説明が「一般論」で止まっている
• 社内文書、顧客情報、問い合わせ履歴、契約書、営業資料、コード、ログをAIへ渡す設計になっている
• 既存ベンダーの説明だけでは、データがどこに保存され、どの外部サービスへ送られるか分からない
• RAGやAIエージェントの権限が強く、読み取り、検索、出力、外部送信の分離が曖昧である
• AI機能付きSaaSや外部APIの契約条件、学習利用、保存期間、サブプロセッサが確認できていない
• セキュリティ製品はあるが、DLP、ログ、ID管理、端末管理とAI利用がつながっていない
• 個人情報漏えいや顧客情報流出が疑われる時の初動が、AI導入プロジェクト側に組み込まれていない
• 既存ベンダーがプロンプト、画面、簡易マニュアルだけを持ち、設計根拠や運用証跡を出せない
• 次のベンダーに相談したいが、何を引き継げば再調査費を抑えられるか分からない

逆に、まだAI導入の候補選定前なら、見積前整理の記事が近いです。複数候補会社へ正式提案依頼を出す段階なら、RFP記事が近いです。権限設計そのものを深く見直す段階なら、データ漏えい権限設計の記事が近くなります。本記事は、既存ベンダー変更時の「AI安全導入の移管条件」に絞ります。

既存記事との違い：この記事は「AI安全導入の移管」に絞る

同じデータ漏えい領域でも、検索意図を分けないとカニバリが起きます。本記事は、AIを安全に導入するための既存設計を、既存ベンダーから新しい支援会社へどう引き継ぐかに絞ります。

本記事の主語は「AIを安全に使うためのデータ漏えい対策を、次の支援会社へ渡せるか」です。AI機能の便利さではなく、漏えいさせない、止められる、説明できる、改善できる状態の引き継ぎを扱います。

ベンダー変更前に見る50項目

まず、次の50項目を確認してください。すべて揃っていなくても構いません。ただし、空欄が多いほど、新ベンダーは再調査から始めるため、費用、期間、責任分界が膨らみます。

移管で最初に見るべきデータ経路

AI安全導入の引き継ぎで最初に見るべきものは、画面でもプロンプトでもありません。データ経路です。誰が、どの画面から、どの情報を入力し、どのAIまたは外部APIが処理し、どこに保存され、誰が出力を見て、どのシステムへ戻すのかを確認します。

たとえば問い合わせ対応AIなら、問い合わせ本文、顧客名、メールアドレス、契約情報、過去対応履歴、FAQ、社内ナレッジ、AI出力、オペレーター編集履歴、顧客送信文が関係します。既存ベンダーが「AIは問い合わせ回答を補助するだけです」と説明していても、実際には顧客情報と過去履歴を外部APIへ送っているかもしれません。

社内検索AIなら、社内規程、契約書、議事録、営業資料、設計書、ソースコード、障害報告書、顧客別提案書が検索対象になることがあります。検索対象の権限が粗いと、AIが本来見せてはいけない文書を回答へ混ぜる可能性があります。

開発支援AIなら、コード、エラーログ、APIキー、DB接続文字列、顧客ID、障害再現ログ、インフラ設定が混ざります。コード生成だけを見ていると、ログや設定ファイルに含まれる認証情報を見落とします。

経営者は、次の4分類でデータ経路を見てください。

この4分類がない移管資料は、AI導入資料としては不十分です。

既存ベンダーから必ず回収する資料

既存ベンダー変更でよくある失敗は、「成果物一式をください」とだけ依頼することです。一式という言葉は便利ですが、受け取る側も渡す側も範囲を曖昧にできます。AI安全導入の引き継ぎでは、資料名を指定して回収してください。

最低限、次の資料を求めます。

既存ベンダーがこれらを出せない場合、悪意があるとは限りません。単に、AI機能の実装を中心に支援していて、データ漏えい対策を移管可能な成果物として作っていなかった可能性があります。その場合は、新ベンダーに「既存資料レビュー」だけを依頼しても足りません。初回30日を、資料回収と不足診断に使う必要があります。

契約で確認するべきこと

AI安全導入の引き継ぎは、技術より契約で止まることがあります。既存ベンダーが作ったプロンプト、RAG設計、設定ファイル、評価シート、台帳、教育資料、ログ抽出手順を、新ベンダーへ共有できるとは限らないためです。

契約では、少なくとも次の点を確認します。

契約確認を後回しにすると、技術的には移管できるのに、資料や設定を渡せず再構築になります。AI導入では、契約、権限、データ所在が一体です。安い見積を選ぶ前に、引き継ぎ可能性を見てください。

AI安全導入で漏えいしやすい5つの経路

AI導入のデータ漏えいは、社員が生成AIへ機密情報を貼り付ける場面だけではありません。既存ベンダー変更時には、特に次の5経路を点検します。

1. RAGの参照範囲が広すぎる

社内検索AIや問い合わせ回答AIでは、RAGが便利です。しかし、参照範囲が部門、役職、顧客、案件ごとに分かれていなければ、AIが本来見せてはいけない情報を回答に混ぜる可能性があります。

移管時には、RAGがどの文書を読み、どの権限で検索し、回答時に権限制御をどう反映するかを確認します。単に「社内文書を検索できます」では不足です。

2. AIエージェントの操作権限が強すぎる

AIエージェントにSaaS操作、CRM更新、ファイル移動、メール送信、チケット更新、コード修正を任せる場合、読み取りと書き込み、送信、削除、権限変更を分ける必要があります。

移管時には、AIエージェントがどのAPIを呼び、どの操作を自動実行でき、どの操作で人の承認が必要かを確認します。高リスク操作が分かれていない場合、新ベンダーは権限再設計から入るべきです。

3. AI機能付きSaaSの外部処理が見えていない

CRM、チャット、議事録、文書管理、プロジェクト管理、開発支援、マーケティングツールにはAI機能が組み込まれています。社員はAIを使っている認識がなくても、裏側で外部モデルやサブプロセッサが処理している場合があります。

移管時には、SaaSごとのAI機能、学習利用、保存期間、管理者設定、無効化可否、ログ取得可否を確認します。

4. テスト環境やPoCに本番データを使っている

AI導入のPoCでは、精度を確認するために本番に近いデータを使いたくなります。しかし、個人情報、顧客情報、契約情報、障害ログ、ソースコードをそのまま使うと、PoC環境が漏えい経路になります。

移管時には、PoCで使ったデータ、保管場所、削除状況、マスキング方式、アクセス権限を確認します。PoCが終わったから安全、ではありません。

5. ログが残らない、または見られない

AI入力・出力ログは、プライバシーや機密性の問題から保存しない設計もあります。一方で、まったく残らなければ、漏えい疑い時に何が入力されたか分かりません。

移管時には、何を保存し、何を保存しないかを決めます。入力全文を残すのか、ハッシュや分類だけ残すのか、管理者だけが見られるのか、保存期間は何日か、削除手順は何かを確認してください。

30日・60日・90日の移管計画

AI安全導入のベンダー変更は、いきなり全面再設計しない方がよいです。最初の90日で、止めるべきリスク、引き継ぐべき資料、再設計する範囲、月次運用へ移す範囲を分けます。

30日目までに見るべきことは、完璧な再設計ではありません。「止めないと危ないもの」と「新ベンダーが調査し直すべきもの」を分けることです。60日目までに高リスク経路を潰し、90日目までに現場運用へ落とします。

経営会議で使う判断表

経営会議では、技術項目を細かく説明しても意思決定が進みません。次の表で、投資判断に変換してください。

この表でNG回答が多い場合、既存ベンダー変更は「会社を変える」ではなく「安全導入の再設計」に近いと考えてください。

新ベンダーへ最初に依頼する診断範囲

新ベンダーに最初から「AIを安全にしてください」と依頼すると、範囲が広すぎます。初回診断では、次の6点に絞るのが現実的です。

1. AI利用・データ経路の棚卸し
2. 個人情報・顧客情報・機密情報のAI入力可否整理
3. RAG・AIエージェント・外部APIの権限レビュー
4. DLP・ログ・ID管理・端末管理との接続確認
5. 既存ベンダー成果物と契約上の移管可否確認
6. 90日移管計画と緊急停止条件の作成

この6点を終えれば、次にやるべきことが見えます。逆に、ここを飛ばして新しいAI機能を作ると、既存ベンダー時代の漏えいリスクを引き継いだまま、機能だけ増やすことになります。

既存ベンダーへ聞く質問

既存ベンダーとの関係を悪くしないためにも、質問は責める形ではなく、移管に必要な確認として出してください。

この質問に答えられない場合でも、すぐにベンダー変更を決める必要はありません。回答できない項目を新ベンダーの初回診断範囲に入れ、再調査費を見積条件に含めます。

失敗するベンダー変更の共通点

AI安全導入のベンダー変更で失敗する会社には、共通点があります。

ベンダー変更は、既存ベンダーの不満を解消するイベントではありません。AI安全導入の責任分界を作り直す機会です。

引き継ぎ後に月次で見る運用項目

90日で移管が終わっても、データ漏えいリスクは終わりません。AIは、導入時よりも運用中に危なくなります。部門が新しいAI機能付きSaaSを契約する。既存SaaSにAI機能が追加される。RAGの参照文書が増える。社員が便利なプロンプトを共有する。AIエージェントに新しいAPIを接続する。退職者や異動者の権限が残る。こうした変化が毎月起きるからです。

そのため、ベンダー変更後は、次の項目を月次で確認してください。

月次レビューは、情シスだけの会議にしない方がよいです。少なくとも、DX責任者、情シス、法務、管理部門、利用部門の代表を入れます。AI導入の安全性は、技術設定だけでなく、業務上必要な例外、顧客説明、契約条件、社員教育で決まるためです。

経営者が月次で見るべき指標は、細かな技術ログではありません。次の5つで十分です。

1. 高リスクAI利用が増えていないか
2. 個人情報・顧客情報・機密情報がAI経路に入っていないか
3. 例外承認が期限切れのまま残っていないか
4. 漏えい疑い時に止められる責任者と手順が維持されているか
5. 新しいAI機能や外部API追加が契約・ログ・DLPに反映されているか

この5つを見れば、AI安全導入が「導入時の資料」で終わっているのか、「運用として回っている」のかが分かります。

見積を比較する時の費用分解

既存ベンダー変更時の見積は、総額だけで比較しないでください。データ漏えいを防ぐAI安全導入では、調査、設計、設定、教育、運用を分けないと、安い見積ほど後で追加費用が出ます。

見積は、次の単位で分けるべきです。

GXOに相談する企業には、最初に「移管診断」と「改善実装」を分けることを勧めます。初回から全部作り直すと、既存ベンダーの成果物を活かせる部分まで捨てることになります。一方で、資料レビューだけで終わると、実際のDLP設定、権限分離、ログ確認、社員教育まで進みません。

おすすめは、最初の30日を移管診断、次の60日を高リスク改善、91日目以降を月次運用に分ける形です。この分け方なら、経営者は「何にいくら払っているか」「どこまで終われば次に進めるか」を判断しやすくなります。

GXOに相談すべきタイミング

次のどれかに当てはまるなら、記事を読むだけで止めず、移管診断か契約前レビューから相談した方がよいです。

• 既存ベンダーがAI機能の説明はできるが、データ経路やログを説明できない
• RAG、AIエージェント、AI機能付きSaaSに顧客情報や社内文書を渡している
• PoCから本番化へ進めたいが、個人情報や顧客情報の扱いが曖昧
• 既存成果物を新ベンダーへ渡せるか契約上不安がある
• AI導入後のDLP、ID管理、ログ、月次監査がつながっていない
• 漏えい疑い時にAI機能を止める手順と責任者が決まっていない
• 見積はあるが、再調査、再設計、権限見直し、教育、運用が分かれていない

GXOでは、データ漏えいを防ぐAI安全導入について、既存ベンダー成果物レビュー、データ経路棚卸し、RAG・AIエージェント権限レビュー、DLP・ログ連携確認、契約条件レビュー、90日移管計画まで一体で支援できます。

まずは AI活用・AI社内ルールの相談 から、既存ベンダーの提案書、構成図、契約書、AI利用状況、懸念しているデータの種類を共有してください。

関連記事

• AI導入のリスク管理ガイド
• シャドーAI対策完全ガイド
• AIエージェント型ランサムウェアから考える、認証情報・権限・バックアップ設計
• 生成AIセキュリティはプロンプト対策だけでは足りない
• NIST AI RMFとCSF 2.0から作るAIガバナンス最小セット

参照した一次情報・公的情報

• NIST AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
• NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
• OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• 個人情報保護委員会「漏えい等の対応」: https://www.ppc.go.jp/personalinfo/legal/leakAction/