経営者向け：情報漏えい社内ルール作成で既存ベンダーを変更する前に見る引き継ぎ条件・責任分界

先に結論：情報漏えい社内ルールの引き継ぎは「文書の納品」ではなく「判断できる状態」の移管で決まる

情報漏えい対策の社内ルールを既存ベンダーと作成している、または作成済みの会社が、別の支援会社へ変更する時に最初に確認すべきことは「最新版のWordファイルをもらえるか」ではありません。

本当に確認すべきなのは、次の8点です。

1. その社内ルールが、どの情報資産を守るためのものか
2. 個人情報、顧客情報、契約情報、営業情報、技術情報、ソースコード、AI入力データの分類が残っているか
3. ルール本文の各条項に、判断根拠、対象業務、対象部署、例外条件が紐づいているか
4. 生成AI、AIチャット、AI機能付きSaaS、外部委託、クラウドストレージ、メール、チャット、CRM、開発環境の扱いが分かれているか
5. 情報漏えいが疑われる時の初動、報告、証拠保全、本人通知、委託先連絡、経営報告の順番が決まっているか
6. 教育資料、FAQ、受講履歴、違反・ヒヤリハット記録、例外承認台帳が残っているか
7. 既存ベンダーの成果物を次ベンダーが編集・再利用・社内展開できる契約になっているか
8. 次ベンダーが、現状診断、改定、教育、月次運用までどこから責任を持てるか

この8点が見えないまま会社だけ変えると、新しいベンダーは「前提が分からないので作り直しです」と言います。既存ベンダーは「納品済みです」と言います。社内は「ルールはあるのに、誰も守り方を説明できない」状態になります。

情報漏えい社内ルールのベンダー変更で失敗する会社は、ルール本文だけを引き継ごうとします。成功する会社は、情報分類、判断基準、業務別の使い方、教育履歴、例外承認、事故時初動、契約上の成果物権利まで移管対象にします。

この記事を読むべき会社

この記事は、情報漏えい対策の社内ルール、生成AI利用ルール、AI利用規程、セキュリティ規程、外部委託管理ルールを既存ベンダーと作成している、または作成済みで、支援会社変更・併用・再設計を検討している中小・中堅企業の経営者、DX責任者、情シス責任者、管理部門、法務向けです。

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

• 既存ベンダーが作った情報漏えい社内ルールが抽象的で、現場が使えていない
• 生成AIやAI機能付きSaaSの利用が増え、旧ルールでは判断できなくなっている
• 既存ベンダーが法務文書寄りで、情シス・現場・AI利用の運用に弱い
• 既存ベンダーがセキュリティ技術寄りで、社内教育や例外承認の設計が弱い
• 成果物の編集権限、再利用権限、次ベンダー共有可否が契約上あいまい
• 個人情報漏えい時の報告判断、本人通知、委託先連絡の流れが社内で説明できない
• 社内ルールはあるが、AI入力禁止情報、顧客データ持ち出し、外部委託先共有、ログ確認の判断表がない
• 既存ベンダーから別会社へ変えたいが、何を引き継げばよいか分からない

逆に、まだ何も作っていない段階なら、見積前整理の記事が近いです。複数候補会社へ正式にRFPを出す段階なら、RFP記事が近いです。本記事は、既存ベンダーの成果物・判断根拠・運用資料を引き継ぎ、次ベンダーで再設計するかどうかを判断する段階に絞ります。

この記事の商談設計

この記事で作りたい相談は、情報漏えい社内ルールの既存ベンダー引き継ぎ診断、成果物権利チェック、情報分類棚卸し、AI入力禁止情報判断表、個人情報漏えい初動フロー、委託先共有ルール、教育FAQ、例外承認台帳、月次レビュー運用の再設計です。

売上への接続は、初回診断から、既存成果物レビュー、契約・権利確認、情報分類棚卸し、社内ルール改定、生成AI・SaaS利用ルール整備、社員教育、月次監査、インシデント初動訓練へ段階受注することです。

利益への接続は、移管診断表、情報資産棚卸しシート、条項別判断根拠表、AI入力禁止情報判断表、委託先共有チェックリスト、教育FAQ、例外承認台帳、90日再設計計画を標準化し、毎回ゼロから調査しない高粗利の伴走支援へ接続することです。

主要CTAは AI活用・AI社内ルールの相談 です。

既存記事との違い：この記事は「既存ベンダーから何を引き継ぐか」に絞る

情報漏えい、AI社内ルール、従業員利用管理は近いテーマが多いため、検索意図を分けます。

記事テーマ	主な読者の悩み	本記事との違い
情報漏えい社内ルールの見積前記事	初めて外部に見積依頼する前に、要件・費用・体制を整理したい	本記事は既存ベンダーの成果物をどう引き継ぐかが主題
情報漏えい社内ルールのRFP記事	複数候補会社へ正式に提案依頼するため、要件・評価軸・契約条件を揃えたい	本記事はRFP前に現成果物、権利、責任分界、欠落資料を棚卸しする
情報漏えい従業員利用管理記事	社員の日常利用、AI入力、SaaS利用、持ち出しを管理したい	本記事は社内ルール作成プロジェクト自体のベンダー変更が主題
ChatGPT情報漏えい対策記事	生成AI利用時の入力情報・学習・外部送信リスクを知りたい	本記事はAIだけでなく、個人情報、顧客情報、委託先、メール、クラウド、開発資料まで扱う

本記事の主語は「社内ルールの作成・改定プロジェクトを既存ベンダーからどう移管するか」です。情報漏えいの一般論ではなく、ベンダー変更時に何を受け取り、何を作り直し、何を契約で確認するかを扱います。

ベンダー変更前にまず集めるべき成果物

既存ベンダーから受け取るべきものは、社内ルール本文だけではありません。最低限、次の資料を一覧化してください。

成果物	引き継ぎで見るポイント	不足している時のリスク
社内ルール本文	最新版、改定履歴、承認者、適用開始日	どの版が有効か分からず、現場説明がぶれる
条項別判断根拠	なぜその禁止・許可・申請条件にしたか	次ベンダーが改定理由を説明できない
情報分類表	個人情報、顧客情報、契約情報、技術情報、営業情報、機密度	AI入力禁止や外部共有禁止を判断できない
業務別利用シナリオ	営業、CS、開発、管理、採用、経理などの利用場面	現場から「自分の業務ではどうするのか」と聞かれる
AI・SaaS利用一覧	利用中ツール、許可・禁止・申請制、管理者、ログ	シャドーAIや野良SaaSが残る
委託先共有ルール	外部委託、制作会社、開発会社、士業、BPOへの共有条件	委託先経由の漏えい時に責任分界が崩れる
教育資料・FAQ	社員向け説明、管理職向け説明、よくある質問	ルールはあっても定着しない
例外承認台帳	誰が、何を、なぜ例外承認したか	実態がブラックボックス化する
違反・ヒヤリハット記録	発生日、内容、再発防止、教育反映	同じ事故が繰り返される
インシデント初動フロー	検知、連絡、証拠保全、報告判断、顧客説明	事故時に経営判断が遅れる
成果物権利・再利用条件	編集、改変、次ベンダー共有、社内展開の可否	次ベンダーが資料を使えず作り直しになる

この一覧を見れば、既存ベンダー変更が「引き継ぎで済む」のか、「一部再設計が必要」なのか、「全面作り直しに近い」のかが見えます。

既存ベンダー変更で一番危ないのは「ルール本文はあるが、判断根拠がない」状態

情報漏えい社内ルールの移管で最も危ないのは、社内ルール本文はあるのに、判断根拠が残っていない状態です。

たとえば、ルール本文に「機密情報を外部AIサービスに入力してはならない」と書いてあっても、次の判断ができなければ現場では使えません。

• 顧客名を匿名化した営業メモは入力してよいのか
• 契約書の条項を要約する場合、社名を伏せればよいのか
• ソースコードやエラーログはどこまで入力してよいのか
• 採用候補者の職務経歴書をAIで要約してよいのか
• 社内議事録をAIで要約する時、参加者名や顧客名はどう扱うのか
• 有料版AI、法人契約AI、社内LLM、RAG、AI機能付きSaaSで扱いを変えるのか
• 委託先がAIを使う場合、自社ルールをどこまで適用するのか

既存ベンダーがこの判断表を作っていない場合、新しいベンダーは本文の言い換えではなく、情報分類と業務分類から作り直す必要があります。逆に、判断根拠が残っていれば、次ベンダーは短期間で改定・教育・運用へ進めます。

引き継ぎ診断の5段階

GXOで見るなら、既存成果物を次の5段階で診断します。

段階	状態	次にやること
レベル1	ルール本文だけがある	情報分類、業務別判断表、教育資料を作り直す
レベル2	本文と教育資料はあるが、判断根拠がない	条項別の根拠、対象業務、例外条件を補完する
レベル3	情報分類とAI/SaaS利用一覧はあるが、運用記録がない	例外承認台帳、ヒヤリハット、月次レビューを設計する
レベル4	運用資料はあるが、契約・権利・次ベンダー共有が不明	成果物権利、編集可能形式、委託先共有条件を確認する
レベル5	本文、判断根拠、教育、台帳、初動、契約条件が揃っている	次ベンダーで差分改定と月次運用へ移れる

経営者が見るべきなのは、既存ベンダーの良し悪しではありません。今の状態がレベルいくつなのか、次ベンダーへ渡せるものと作り直すものが何か、追加費用の原因がどこにあるかです。

情報漏えい社内ルールで必ず分けるべき情報分類

社内ルールの移管では、情報分類表があるかを確認してください。情報分類がないと、禁止事項だけが増え、現場は守れません。

最低限、次のように分けます。

情報分類	例	ルールで決めること
個人情報	顧客名、住所、電話番号、メール、従業員情報、採用候補者情報	AI入力、外部共有、委託先共有、漏えい時報告判断
顧客・取引情報	契約内容、商談メモ、見積、請求、問い合わせ履歴	部署外共有、AI要約、CRM連携、外部委託可否
技術情報	ソースコード、設計書、APIキー、ログ、脆弱性情報	AI入力禁止、開発委託、GitHub共有、権限管理
経営・財務情報	売上、原価、人件費、資金繰り、M&A、事業計画	AI分析、外部士業共有、役員会資料の扱い
営業・マーケ情報	ターゲットリスト、広告成果、顧客セグメント	AI活用範囲、外部ツール連携、代理店共有
現場情報	写真、日報、位置情報、作業記録、施工情報	クラウド保存、AI-OCR、委託先閲覧範囲
公開可能情報	Web掲載済み情報、公開資料、採用ページ情報	利用許可範囲、出典確認、誤引用防止

この分類がないと、「情報漏えいを防ぎましょう」という抽象論に戻ります。ベンダー変更時は、既存ベンダーが分類を作っているか、実際の業務データに当てはめているかを確認してください。

AI時代の情報漏えい社内ルールで追加すべき論点

従来の情報漏えい対策は、メール誤送信、USB持ち出し、ノートPC紛失、クラウド共有設定、委託先管理が中心でした。今は、生成AIやAI機能付きSaaSの利用が加わります。

社内ルールのベンダー変更では、既存ルールが次の論点を扱っているかを見ます。

• ChatGPT、Claude、Gemini、Copilotなどへの入力情報
• 法人契約AIと個人アカウントAIの扱い
• AI機能付きCRM、MA、議事録、チャット、ドキュメントツールの扱い
• RAGや社内検索AIが参照するデータ範囲
• AIに要約させる議事録、契約書、問い合わせ履歴の匿名化基準
• 開発者がAIコーディングツールへ入力するコード、ログ、エラー情報
• AI出力を顧客資料、契約書、採用連絡、広告に使う時のレビュー
• 委託先がAIを使う場合の事前申請、ログ、再委託、成果物確認

既存ルールが「外部サービスへの機密情報入力は禁止」とだけ書いている場合、AI時代の運用には足りません。禁止だけではなく、法人契約AIなら何が可能か、匿名化すれば何が可能か、承認があれば何が可能か、ログを残せば何が可能かまで分ける必要があります。

個人情報漏えい時の初動フローは社内ルールに含める

情報漏えい社内ルールを作るなら、平時の禁止事項だけでなく、漏えいが疑われる時の初動も含めます。

個人情報保護委員会は、個人情報の漏えい等が発生した場合の対応について情報を公開しています。法的な報告要否や期限判断は個別事情で変わるため、社内ルールでは「誰が、何を、いつ、どの資料で判断するか」を決めておくことが重要です。

既存ベンダーから引き継ぐ時は、次の流れが文書化されているかを確認してください。

1. 漏えい疑いを発見した社員が、何分以内に、誰へ、どのチャネルで報告するか
2. 情シス、管理部門、法務、経営、外部専門家の初動会議をどう開くか
3. 端末、メール、チャット、クラウド、AIサービス、ログの証拠保全をどう行うか
4. 個人情報、顧客情報、機密情報、技術情報のどれに該当するかを誰が分類するか
5. 個人情報保護委員会、本人、取引先、委託先、保険会社、顧問弁護士への連絡要否をどう判断するか
6. 社外説明の文面を誰が作り、誰が承認するか
7. 再発防止策を社内ルール、教育、権限、ログ、委託契約へどう反映するか

この初動フローがない社内ルールは、事故時に使えません。ベンダー変更時は、社内ルール本文の美しさよりも、初動の責任者、判断資料、連絡先、証拠保全、経営報告の流れがあるかを見てください。

既存ベンダーに必ず確認する質問

既存ベンダーへ感情的に「引き継ぎ資料をください」と言っても、必要な資料は出てきません。次のように、具体的に質問してください。

質問	確認したいこと
社内ルール本文の最新版、改定履歴、承認履歴はありますか	どの版が有効か
各条項の判断根拠、参照した公式情報、社内ヒアリング結果はありますか	改定時に根拠を追えるか
情報分類表と業務別判断表はありますか	現場が使える形か
生成AI、AI機能付きSaaS、クラウド共有、委託先共有の扱いは分かれていますか	AI時代の漏えい対策になっているか
教育資料、FAQ、受講履歴、理解度確認はありますか	定着状況を移管できるか
例外承認、ヒヤリハット、違反記録、月次レビューの台帳はありますか	運用実態が見えるか
個人情報漏えい時の初動フロー、連絡先、判断基準はありますか	事故対応に使えるか
成果物は編集可能形式で受け取れますか	次ベンダーが改定できるか
成果物を次ベンダーへ共有してよい契約ですか	権利・守秘義務で止まらないか
未完了課題、保留論点、既存ベンダーが対応できなかった論点は何ですか	次ベンダーの初期見積に入れるか

この質問に対して、既存ベンダーがすぐ回答できない場合、成果物はあってもプロジェクト管理が残っていない可能性があります。その場合は、新ベンダーに「引き継ぎ前提」ではなく「現状診断前提」で見積を依頼した方が安全です。

契約で確認する成果物権利

社内ルール作成のベンダー変更では、成果物権利の確認が重要です。ルール本文を社内で使うことはできても、次ベンダーへ共有できるか、改変できるか、教育資料として再利用できるかは契約次第です。

最低限、次の項目を確認してください。

• ルール本文の著作権、利用権、改変権
• Word、PowerPoint、Excel、Notion、Google Docsなど編集可能形式での納品有無
• 次ベンダー、顧問弁護士、社労士、セキュリティ会社、監査人への共有可否
• 社内教育、グループ会社展開、委託先説明への再利用可否
• テンプレート部分と自社固有部分の区分
• 既存ベンダーのノウハウ部分を削除しないと共有できない範囲
• 解約後のデータ削除、資料返却、秘密保持、アクセス停止
• 既存ベンダーが管理しているクラウドフォルダ、SaaS、フォーム、教育システムの管理者移管

ここが曖昧だと、新ベンダーが資料を見られず、結局作り直しになります。ベンダー変更の費用が膨らむ原因は、技術不足よりも、成果物権利と編集可能形式の不備であることが少なくありません。

新ベンダーへ渡すべき引き継ぎパッケージ

新ベンダーへ渡す時は、資料をばらばらに送らず、次のパッケージにまとめます。

パッケージ	内容
1. 現行ルール	本文、改定履歴、承認履歴、適用範囲
2. 判断根拠	公式情報、社内ヒアリング、業務別リスク、採用しなかった案
3. 情報資産	情報分類、部門別データ、AI/SaaS利用一覧、委託先一覧
4. 運用資料	教育資料、FAQ、受講履歴、例外承認、月次レビュー
5. 事故対応	初動フロー、連絡網、報告判断、証拠保全、説明テンプレート
6. 契約・権利	既存契約、成果物権利、共有可否、解約条件、残作業
7. 未解決論点	現場からの不満、曖昧な条項、ルール違反、今後のAI利用計画

この7パッケージがあれば、新ベンダーは初回診断で全体像を把握できます。逆に、本文だけしかない場合は、情報分類と業務ヒアリングから再開することになります。

90日で再設計する実務スケジュール

既存ベンダー変更は、1日で終わりません。経営判断としては、90日で再設計する前提が現実的です。

期間	やること	成果物
1〜2週目	既存成果物、契約、権利、編集可能形式、管理者権限を確認	移管診断表、資料不足一覧
3〜4週目	情報分類、AI/SaaS利用、委託先共有、事故初動を棚卸し	情報資産表、AI入力禁止情報判断表、委託先共有表
5〜6週目	ルール本文と判断根拠を改定	改定案、条項別根拠表、例外条件表
7〜8週目	教育資料、FAQ、管理職向け説明、例外承認フローを作る	教育資料、FAQ、例外承認台帳
9〜10週目	インシデント初動訓練、報告判断、証拠保全手順を確認	初動フロー、連絡網、訓練メモ
11〜12週目	経営承認、全社展開、月次レビュー体制を開始	公開版ルール、月次レビュー表、改善バックログ

重要なのは、最初の2週間で「引き継げるもの」と「作り直すもの」を分けることです。ここを曖昧にしたまま新ベンダーへ発注すると、後から「これは別費用です」が出ます。

ベンダー変更をやめた方がよいケース

既存ベンダーに不満があっても、すぐ変更しない方がよいケースもあります。

• 現行ルールの承認直前で、変更すると社内合意が崩れる
• 既存ベンダーが法務・個人情報保護に強く、新ベンダーがAI・情シスだけに強い
• 成果物権利が未整理で、次ベンダーへ資料共有できない
• 事故対応中で、責任分界を変えると証拠保全や説明が混乱する
• 既存ベンダーのクラウド環境や教育システムに資料が残っており、管理者移管が終わっていない

この場合は、いきなり切り替えるのではなく、既存ベンダーを残したままGXOのような第三者が診断・補完・レビューに入る方が安全です。ベンダー変更は目的ではありません。情報漏えい社内ルールを、社員が使え、事故時に説明でき、経営が責任を持てる状態にすることが目的です。

ベンダー変更した方がよいケース

一方で、次の状態なら変更または併用を検討すべきです。

• 既存ベンダーがルール本文だけを納品し、教育・運用・例外承認に関与しない
• 生成AI、AI機能付きSaaS、RAG、AIエージェント、開発AIツールの扱いを説明できない
• 個人情報漏えい時の初動や報告判断を「法務に確認してください」で止める
• 情報分類や業務別判断表がなく、現場質問に答えられない
• 成果物がPDFだけで、編集可能形式がない
• 契約上、次ベンダー共有や改変ができない
• 月次レビュー、例外承認、ヒヤリハット反映の運用設計がない

この場合、既存ベンダーの成果物を否定するのではなく、足りない部分を明確にして次ベンダーへ移管します。移管診断を挟むことで、無駄な作り直しと追加費用を減らせます。

経営者が最後に見るべき判断表

最後は、次の表で判断してください。

判断項目	はい	いいえ
最新の社内ルール本文と改定履歴がある	差分改定で進める	版管理から作り直す
条項別の判断根拠がある	次ベンダーが短期で改定できる	情報分類と業務ヒアリングから再設計
AI/SaaS/委託先共有の扱いが分かれている	AI時代の運用へ移れる	AI入力禁止情報判断表を作る
教育資料・FAQ・受講履歴がある	定着改善へ移れる	教育設計から作る
例外承認・ヒヤリハット・月次レビューがある	運用改善へ移れる	台帳とレビュー体制を作る
個人情報漏えい時の初動フローがある	訓練と改善へ移れる	初動フローを優先して作る
成果物権利と次ベンダー共有が明確	移管できる	契約確認が先

「はい」が5個以上なら、既存成果物を活かして新ベンダーへ移管できます。「はい」が3〜4個なら、移管診断と部分再設計が必要です。「はい」が2個以下なら、ベンダー変更というより、情報漏えい社内ルールの再構築と考えた方が現実的です。

部門別に確認すべき引き継ぎ論点

情報漏えい社内ルールは、管理部門だけで作ると現場に刺さりません。既存ベンダー変更時は、部門別に「この部署では何が漏えいリスクになるか」「どの場面でAIやSaaSを使うか」「誰が例外承認するか」を確認します。

部門	よくある漏えいリスク	引き継ぎで確認する資料
営業	顧客名、商談メモ、見積、契約条件、価格表をAIや外部ツールに入力する	CRM利用ルール、商談メモの匿名化基準、提案資料レビュー基準
カスタマーサポート	問い合わせ履歴、苦情、個人情報、画面キャプチャを外部共有する	問い合わせデータ分類、FAQ作成時の入力禁止情報、委託先共有条件
開発・情シス	ソースコード、ログ、APIキー、設計書、脆弱性情報をAI開発ツールに入力する	AIコーディング利用ルール、ログマスキング基準、開発委託先ルール
管理・経理	請求、給与、振込、財務、従業員情報をクラウドやAIで処理する	個人情報分類、会計SaaS権限、外部士業共有ルール
人事・採用	履歴書、職務経歴書、評価、面談メモをAIで要約する	採用情報のAI利用基準、保存期間、面接資料共有範囲
マーケティング	顧客リスト、広告成果、セグメント、Web行動データを外部ツールへ連携する	MA/広告ツール連携表、個人関連情報の扱い、代理店共有ルール
経営	M&A、資金繰り、事業計画、未公開情報を資料化する	役員会資料の保管・共有・AI利用基準

既存ベンダーの成果物に部門別の視点がない場合、ルールは現場の例外処理に負けます。たとえば営業は「顧客名を伏せればAI要約できるのか」を聞き、開発は「エラーログに個人情報が混ざっていたらAIに貼れないのか」を聞き、人事は「候補者情報をAIで整形してよいのか」を聞きます。ここに答えられない社内ルールは、禁止事項としては存在しても、運用ルールとしては機能していません。

新ベンダーへ移管する時は、部門別の質問リストを作り、既存ルールで答えられるもの、追加判断が必要なもの、経営判断が必要なものに分けます。この作業を先にやると、改定範囲が明確になります。

追加費用が膨らむ典型パターン

ベンダー変更で予算が膨らむ時、原因は「新ベンダーが高い」だけではありません。多くの場合、既存成果物の前提が不足しているため、調査と再設計が増えます。

追加費用の原因	起きること	先に防ぐ方法
編集可能ファイルがない	PDFから作り直し、改定履歴も追えない	Word/PowerPoint/Excel/Docs原本を移管条件に入れる
判断根拠がない	条項ごとに法務・情シス・現場へ再ヒアリングが必要	条項別根拠表を既存ベンダーへ依頼する
情報分類がない	AI入力禁止、外部共有、委託先共有を全部再設計する	情報資産棚卸しを先に実施する
教育履歴がない	誰が理解しているか分からず、再教育が必要	受講履歴、理解度確認、FAQを移管する
例外承認が残っていない	実態とルールのズレが分からない	例外承認台帳と月次レビューを作る
契約上の共有可否が不明	新ベンダーへ資料を渡せず、作り直しになる	成果物権利と次ベンダー共有可否を確認する
管理者権限が既存ベンダー側にある	教育ツール、クラウド、フォーム、台帳にアクセスできない	管理者権限移管リストを作る

経営者は、見積金額だけで判断しないでください。安い新ベンダーでも、既存成果物が引き継げなければ結果的に高くなります。高い新ベンダーでも、移管診断、情報分類、教育、月次運用まで含んでいれば妥当な場合があります。

見積を見る時は、次の3つに分けると比較しやすくなります。

1. 移管診断費用: 既存成果物、契約、権利、情報分類、運用状況を確認する費用
2. 再設計費用: 不足している判断表、教育、初動フロー、委託先ルールを作る費用
3. 運用費用: 月次レビュー、例外承認、教育更新、ヒヤリハット反映を続ける費用

この3つを混ぜた見積は比較できません。既存ベンダー変更では、安く見える一括見積より、移管診断、再設計、運用が分かれている見積の方が経営判断に使えます。

委託先・外部パートナーの扱いを社内ルールに入れる

情報漏えい社内ルールは、社員だけを対象にすると不十分です。中小・中堅企業では、制作会社、開発会社、広告代理店、BPO、士業、採用代行、コールセンター、保守会社など、外部パートナーが顧客情報や社内情報に触れる場面が多くあります。

既存ベンダー変更時は、委託先に関する次のルールがあるか確認してください。

• 委託先へ渡してよい情報と渡してはいけない情報
• 委託先が生成AIや外部SaaSを使う場合の事前申請
• 再委託の可否と事前承認
• 委託先の担当者変更時のアクセス停止
• 契約終了時のデータ返却、削除、証明
• 顧客情報、個人情報、技術情報の保管場所
• 委託先で漏えい疑いが発生した時の連絡期限と証拠保全
• 委託先に渡す教育資料、禁止事項、FAQ

たとえば開発会社にログ調査を依頼する場合、ログに個人情報やAPIキーが混ざることがあります。広告代理店に顧客リストを渡す場合、外部広告ツールや分析ツールへアップロードされることがあります。士業へ資料を渡す場合、クラウドフォルダの共有範囲が広がることがあります。

既存ルールに委託先の扱いがないなら、社内だけを締めても漏えいリスクは残ります。ベンダー変更を機に、委託先共有ルールを社内ルール本文、委託契約、発注書、NDA、教育資料に反映してください。

AI利用を禁止するだけでは現場が迂回する

情報漏えい対策として「AI利用禁止」と書くだけでは、現場は守りません。便利なAIを完全に禁止すると、個人アカウント、無料ツール、ブラウザ拡張、スマホアプリ、外部SaaSのAI機能へ流れます。これがシャドーAIです。

既存ベンダーが作ったルールに「生成AIへの機密情報入力禁止」だけが書かれている場合、次ベンダーでは次のように分解してください。

利用区分	例	管理方法
許可	公開情報の要約、社内で作った一般文の言い換え、テンプレート作成	利用例をFAQ化し、教育で周知
条件付き許可	顧客名を伏せた議事録要約、匿名化した問い合わせ分類、社内資料の構成案	匿名化基準、レビュー者、保存場所を決める
申請制	契約書、顧客情報、採用情報、開発ログ、社内RAGへの接続	目的、入力情報、ツール、ログ、責任者を申請
禁止	APIキー、パスワード、未公開財務、個人情報原本、脆弱性情報の外部AI入力	技術的制御、教育、違反時対応を明記

この区分があると、社員は「何でも禁止」ではなく「この場合は使える」「この場合は申請する」「これは絶対に入れない」と判断できます。ベンダー変更時は、既存ルールがAI利用を現実的に管理しているか、単に禁止しているだけかを見てください。

月次レビューで見るべき指標

情報漏えい社内ルールは、公開した月が完成ではありません。月次で見直さないと、AIツール、SaaS、委託先、業務フローが変わり、すぐ古くなります。

月次レビューでは、次の指標を見ます。

指標	見る理由
新規利用AI/SaaSの件数	シャドーAI、野良SaaSを早期に把握する
例外承認の件数と理由	ルールが厳しすぎる部分、現場に合っていない部分を見つける
ヒヤリハットの件数	事故になる前の運用弱点を見つける
教育未受講者数	社内展開の穴を把握する
委託先追加・変更件数	外部共有ルールの更新漏れを防ぐ
権限棚卸し未完了件数	退職者、異動者、委託終了者のアクセス残りを防ぐ
AI入力禁止情報に関する質問件数	FAQや判断表の不足を把握する

既存ベンダーが月次レビューを設計していない場合、新ベンダーはここを補完するべきです。情報漏えい対策は、年1回の規程改定だけでは追いつきません。小さな質問、例外、ヒヤリハットを毎月拾い、ルール、教育、FAQ、権限、委託契約へ戻す運用が必要です。

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

GXOに相談すべきタイミングは、既存ベンダーを変えるかどうかを決めた後ではありません。変える前です。

次の状態なら、先に相談してください。

• 既存ベンダーの成果物が妥当か判断できない
• 社内ルール本文はあるが、AI・SaaS・委託先共有の判断に使えない
• 成果物権利や次ベンダー共有可否が契約上分からない
• 個人情報漏えい時の初動フローが社内で説明できない
• 情シス、法務、管理部門、現場のどこが責任を持つか決まっていない
• 既存ベンダーに何を依頼し、新ベンダーに何を依頼すべきか分からない

GXOでは、情報漏えい社内ルールの既存ベンダー引き継ぎ診断、成果物権利チェック、AI入力禁止情報判断表、委託先共有ルール、教育FAQ、例外承認台帳、月次レビュー体制まで、実務で使える形に整理します。

相談先は AI活用・AI社内ルールの相談 です。既存ベンダーを責めるためではなく、引き継げるもの、作り直すもの、経営判断が必要なものを分けるために使ってください。

内部リンク

• 生成AI・AI社内ルール全体の親ピラー: 生成AI社内ルール・ガバナンス
• ChatGPT・生成AI利用時の情報漏えいリスク: 社内 ChatGPT で起きる情報漏えいリスクと対策
• AI台帳とシャドーAI対策: 国内企業がAI台帳を作るべき理由
• AI利用規程の既存ベンダー変更: AI利用規程の社内ルール作成で既存ベンダーを変更する前に見る引き継ぎ条件
• 相談導線: AI活用・AI社内ルールの相談

参照した一次情報・確認日

• 個人情報保護委員会「漏えい等の対応」: 2026-07-08 HTTP 200確認
• IPA「情報セキュリティ10大脅威」: 2026-07-08 HTTP 200確認
• NIST Cybersecurity Framework: 2026-07-08 HTTP 200確認
• OWASP Top 10 for LLM Applications: 2026-07-08 HTTP 200確認
• NISC: 2026-07-08 HTTP 403確認のため、本文の断定根拠には使わず残余確認扱い

この記事は法的助言ではありません。個人情報漏えいの報告要否、本人通知、契約責任、損害賠償、監督官庁対応は、個別事情に応じて弁護士、個人情報保護の専門家、セキュリティ専門家と確認してください。GXOの役割は、情報漏えい社内ルール、AI・SaaS利用判断、移管資料、教育、例外承認、月次運用を、経営と現場が使える形に整理することです。