経営者向け：情報漏えいの従業員利用管理で既存ベンダーを変更する前に見る引き継ぎ条件

先に結論：従業員利用管理のベンダー変更は「社員が何を使い、何に迷い、何を例外にしたか」の移管で判断する

情報漏えい対策の社内ルールを作った。社員向けに生成AIやクラウド共有の注意事項も説明した。既存ベンダーからは規程本文、研修資料、簡単なチェックリストが納品されている。ところが実運用に入ると、営業は商談メモをAIで要約し、開発はログやコード片をAIに貼るか迷い、人事は履歴書の要約、CSは問い合わせ履歴のFAQ化、管理部門は士業やBPOへの資料共有で判断に迷う。既存ベンダーは「ルール作成」はできたが、社員の実利用、例外承認、違反・ヒヤリハット、月次レビューまでは見ていない。

この状態で支援会社を変更する時、最も危ない判断は「社内ルールはあるので、次の会社には従業員利用管理だけ任せればよい」と考えることです。

情報漏えいの従業員利用管理は、規程本文とは別の運用品質で決まります。社員がどのAI・SaaS・クラウドを使っているか。会社契約、部門契約、個人契約、無料版、試用版がどこまで混ざっているか。誰が利用を申請し、誰が承認し、どの情報を入力・共有してはいけないと教育したか。例外承認は残っているか。違反やヒヤリハットはルール改定に反映されたか。業務委託、派遣、外部パートナー、委託先の利用は管理できているか。

これらを引き継がないままベンダーを変えると、新しい支援会社は社内ルール本文だけを読み、現場の実利用を知らないまま管理設計を作り直します。結果として、過去に社員へ説明した内容と新しい運用がずれたり、許可済みのAIやSaaSが台帳から漏れたり、例外承認の履歴が消えたり、個人情報漏えいが疑われる時の初動が再設計されないままになります。

経営者が見るべき結論は、次の10点です。

1. 社内ルール本文ではなく、社員利用実態と利用台帳を引き継ぐ
2. 生成AI、AI機能付きSaaS、クラウド共有、個人契約、委託先共有を分けて棚卸しする
3. 許可、禁止、申請制、例外利用の判断根拠を引き継ぐ
4. 教育資料、FAQ、受講履歴、未回答質問、問い合わせ履歴を引き継ぐ
5. 例外承認、違反、ヒヤリハット、個人情報漏えい懸念の記録を引き継ぐ
6. 利用申請フォーム、承認フロー、月次レビュー手順を引き継ぐ
7. 管理者権限、ログ確認、退職者・異動者・委託先の利用停止手順を確認する
8. 成果物の権利、第三者共有可否、編集可能形式を契約前に確認する
9. 既存ベンダーと新ベンダーの責任分界を30日以内に明文化する
10. 30日、60日、90日で、資料回収、差分診断、再設計、社員周知、月次運用へ移る

本記事は、情報漏えい対策の「従業員利用管理」に絞り、既存ベンダーを変更する前に何を引き継ぐべきかを整理します。社内ルール作成そのものの既存ベンダー変更ではありません。見積前整理でもRFPでもありません。作成済みまたは運用中の情報漏えい対策を前提に、社員のAI・SaaS・クラウド・委託先利用をどう移管するかが主題です。

この記事を読むべき会社

この記事は、情報漏えい対策の社内ルール、生成AI利用ルール、AI利用規程、情報セキュリティ規程、個人情報取扱ルール、外部委託管理ルールを作成済み、または作成中で、社員のAI・SaaS・クラウド共有・外部共有の利用管理を既存ベンダーから別会社へ変更・併用・再設計したい経営者、DX責任者、情シス責任者、管理部門、法務向けです。

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

• 情報漏えい対策の社内ルールはあるが、社員の実利用を管理できていない
• ChatGPT、Claude、Gemini、Copilot、議事録AI、AI機能付きSaaSの利用が部門ごとに広がっている
• AI・SaaS・クラウド共有・委託先共有の利用台帳が古く、実態と合っていない
• 既存ベンダーが規程本文中心で、教育履歴、例外承認、違反・ヒヤリハットまでは管理していない
• 社員からの「この情報をAIやSaaSへ入れてよいか」という問い合わせが属人的に処理されている
• 個人情報漏えいが疑われる時の社内初動が、教育・承認・月次レビューへ戻っていない
• 既存ベンダー変更後も、社員向けFAQ、教育、例外承認、月次更新を止めたくない
• 従業員利用管理の運用を引き継ぐ前に、成果物権利と資料共有可否を確認したい

逆に、これから情報漏えい社内ルールを初めて作る段階なら、見積前整理の記事が近いです。複数候補会社へ正式提案依頼を出す段階なら、RFP記事が近いです。既存ベンダーが作った社内ルール本文そのものを引き継ぐ段階なら、社内ルール作成の既存ベンダー変更記事が近いです。

この記事の商談設計

この記事で作りたい相談は、情報漏えいの従業員利用管理に関する既存ベンダー引き継ぎ診断、AI・SaaS・クラウド利用台帳の再整備、許可・禁止・申請制区分の見直し、教育履歴・FAQ整理、例外承認フロー再設計、違反・ヒヤリハット反映、個人情報漏えい初動フローの運用化、月次レビュー設計、契約前レビューです。

売上への接続は、初回診断から、利用台帳再整備、情報漏えい社内ルール改定、AI・SaaS利用ルール整備、社員教育、利用申請・例外承認フロー、個人情報漏えい初動訓練、月次レビュー運用へ段階受注することです。

利益への接続は、利用実態棚卸しシート、AI・SaaS利用台帳テンプレート、入力禁止情報判断表、教育履歴管理表、FAQ差分表、例外承認台帳、違反・ヒヤリハット記録表、90日移管計画を標準化し、毎回ゼロから運用設計しない高粗利の継続支援へつなげることです。

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

既存記事との違い：この記事は「従業員利用管理の移管」に絞る

同じ情報漏えい領域でも、検索意図を分けないとカニバリが起きます。本記事は、社員が日常業務でAI・SaaS・クラウド・委託先共有をどう使っているか、その運用を既存ベンダーから新しい支援会社へどう移すかに絞ります。

記事テーマ	主な読者の悩み	本記事との違い
情報漏えい社内ルール作成の既存ベンダー変更	規程本文、成果物権利、条文根拠、責任分界を引き継ぎたい	本記事は社内ルール本文ではなく、社員利用実態、教育、申請、例外承認、月次運用を扱う
情報漏えい社内ルール作成の見積前整理	これから初回作成する範囲と費用を決めたい	本記事は作成済み・運用中の従業員利用管理を移管する段階
情報漏えい社内ルール作成RFP	候補会社へ正式提案依頼を出したい	本記事は既存ベンダーからの資料回収と引き継ぎ条件を見る
ChatGPT情報漏えい対策	生成AI入力、学習、外部送信リスクを理解したい	本記事は生成AIだけでなく、SaaS、クラウド共有、委託先共有、教育履歴、例外承認まで扱う
AI利用規程の従業員利用管理ベンダー変更	AI利用規程に紐づく社員AI利用管理を移したい	本記事は情報漏えいを主語にし、個人情報、顧客情報、技術情報、委託先共有まで広げる

本記事の主語は「情報漏えいを防ぐために、従業員が何をどう使っているか」です。規程ファイルそのものではなく、社員利用管理の実態を次の支援会社へ渡せるかを確認します。

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

まず、次の45項目を確認してください。すべて揃っていなくても構いません。ただし、空欄が多いほど、新しい支援会社は社員利用実態の調査からやり直すことになります。

確認項目	見る理由	不足時のリスク
社内ルール最新版	従業員利用管理の基準になる	古いルールに基づいて運用する
情報分類表	個人情報、顧客情報、技術情報を分ける	入力・共有判断がばらつく
AI・SaaS利用台帳	利用中サービスを把握する	実利用が見えない
許可ツール一覧	使ってよいAI・SaaSを社員へ示す	現場判断がばらつく
禁止ツール一覧	使ってはいけないサービスを明確にする	無料版や不明サービスが残る
申請制ツール一覧	条件付き利用を管理する	例外が勝手利用になる
判断根拠	許可・禁止・申請制の理由を見る	新ベンダーが再判断する
利用部門一覧	部門ごとの実態を見る	高リスク部門が漏れる
利用目的一覧	要約、翻訳、コード、議事録などを分ける	用途別リスクが見えない
入力禁止情報表	個人情報、顧客情報、機密情報の扱いを管理する	社員が入力可否を判断できない
クラウド共有ルール	共有リンク、外部共有、期限、権限を管理する	期限なし外部共有が残る
委託先共有ルール	外部パートナー、士業、BPO、開発会社への共有を管理する	委託先経由の漏えいが残る
生成物レビュー基準	顧客提出物や公開物の確認責任を見る	誤情報や品質問題が残る
利用申請フォーム	新規利用の入口を見る	新しいサービスが台帳外に増える
承認フロー	誰が許可するかを見る	部門判断でばらつく
例外承認台帳	規程外利用の履歴を見る	過去の例外が消える
例外の期限	一時例外か恒久例外かを見る	例外が固定化する
社員向け教育資料	社員への説明内容を見る	ルールと教育がずれる
管理職向け教育資料	承認・例外・違反対応を見る	管理職判断がばらつく
教育受講履歴	周知証跡を見る	事故時に説明できない
理解度確認	社員が理解したかを見る	読んだだけで終わる
FAQ	社員が迷った論点を見る	同じ問い合わせが繰り返される
未回答質問	ルールの曖昧さを見る	新ベンダーが課題を把握できない
問い合わせ履歴	現場の困りごとを見る	運用改善の材料が消える
違反履歴	ルール違反の傾向を見る	再発防止ができない
ヒヤリハット	事故前の兆候を見る	ルール改定に反映されない
個人情報漏えい懸念	誤入力、誤送信、外部共有を確認する	初動改善ができない
初動フロー	発見、報告、証拠保全、外部連絡判断を見る	事故時に動けない
月次レビュー資料	運用改善の流れを見る	作って終わりになる
改定履歴	運用をどう変えたかを見る	同じ議論をやり直す
管理者権限	AI・SaaSの設定責任者を見る	退職・異動で管理不能になる
ログ確認手順	利用状況の確認方法を見る	問題時に追跡できない
退職者対応	アカウント停止と権限解除を見る	退職者アカウントが残る
異動者対応	権限変更を確認する	前部署の情報にアクセスできる
業務委託対応	社外協力者の利用を見る	委託先が規程外になる
派遣社員対応	雇用形態ごとの教育と権限を見る	周知漏れが起きる
顧客会議でのAI利用	議事録AIや要約AIの同意を見る	顧客信頼を損なう
個人契約AIの扱い	社員個人利用の境界を見る	シャドーAIが残る
端末持ち出し	私物端末、USB、個人メールを見る	技術的な抜け道が残る
成果物権利	台帳・FAQ・教育資料の改変可否を見る	新ベンダーへ渡せない
第三者共有可否	新支援会社へ資料共有できるか見る	移管資料が使えない
編集可能形式	Excel、Word、Notion等で更新できるか見る	PDFだけで運用できない
未決事項	残課題を把握する	重要論点が消える
引き継ぎ会議	既存ベンダーから説明を受ける	資料の意味が分からない
90日移管計画	変更時の混乱を抑える	運用の空白期間ができる

この表は、既存ベンダー変更のための棚卸し表です。社内ルール本文の品質だけでなく、社員利用管理の運用品質を確認するために使います。

利用台帳を引き継がないと、新ベンダーは従業員利用を管理できない

情報漏えいの従業員利用管理で最も重要なのは、AI・SaaS・クラウド利用台帳です。社内ルールに「会社が許可したサービスを利用する」と書いてあっても、許可されたサービスが台帳で管理されていなければ、社員は判断できません。

既存ベンダーから引き継ぐ利用台帳には、少なくとも次の項目が必要です。

台帳項目	引き継ぐ理由
サービス名	対象AI・SaaS・クラウドを特定する
契約形態	会社契約、部門契約、個人契約、無料版、試用版を分ける
利用部門	部門責任者を明確にする
利用目的	社内ルールの許可用途と対応させる
入力・共有情報	個人情報、顧客情報、技術情報、認証情報の有無を見る
出力物の利用先	社内利用、顧客提出、外部公開の違いを見る
管理者	設定変更、停止、問い合わせ対応の責任者
利用開始日	古い利用を棚卸しする
承認者	誰が許可したかを残す
次回見直し日	月次・四半期更新の起点にする

新しい支援会社に台帳を渡す時は、最新版だけでなく、更新履歴も渡すべきです。なぜそのAIを許可したのか、なぜ禁止したのか、どの条件で申請制にしたのかが分からないと、新ベンダーは同じ判断をやり直します。

教育履歴とFAQは「ルールが社員に届いたか」の証跡になる

情報漏えい対策は、社員が理解して初めて意味を持ちます。既存ベンダーが教育資料やFAQを作っていた場合、必ず引き継いでください。

見るべき資料は次の通りです。

資料	確認すること
社員向け説明資料	社内ルール本文と説明内容が一致しているか
管理職向け資料	承認、例外、違反、初動対応が説明されているか
部門別FAQ	営業、開発、人事、CS、管理部門の質問に答えているか
受講履歴	誰がいつ受講したか
理解度チェック	形式だけでなく理解を確認したか
未回答質問	ルール改定やFAQ追加が必要な論点
周知履歴	社内ポータル、説明会、メールなどの記録

教育履歴とFAQがない状態でベンダーを変えると、新しい支援会社は「社員が何を理解していて、何に迷っているか」を把握できません。結果として、同じ説明を繰り返したり、現場の質問に合わないFAQを作ったりします。

例外承認とヒヤリハットを引き継がないと、ルールは改善されない

従業員利用管理では、例外承認とヒヤリハットが重要です。ルール通りに運用できている情報だけでは、改善点が見えません。

例えば、営業部門が顧客名を匿名化して提案書の下書きにAIを使いたい。採用部門が応募者情報をAIへ入れずにスカウト文面を作りたい。開発部門が顧客固有コードを入れずに一般的なテスト観点を生成したい。CS部門が問い合わせ履歴を匿名化してFAQ候補を作りたい。こうした例外や条件付き利用の判断は、次の運用に活かせます。

引き継ぐべき項目は、次の通りです。

項目	内容
例外申請内容	誰が、何のために、どのサービスを使いたいと申請したか
承認者	部門長、情シス、管理部門、法務の誰が判断したか
承認条件	匿名化、レビュー、利用期限、ログ保存など
期限	一時例外か、見直しが必要か
結果	問題なく利用できたか、追加制約が必要だったか
ヒヤリハット	入力ミス、誤送信、誤出力、権利懸念など
改善対応	FAQ追加、ルール改定、教育追加、ツール停止など

この情報があれば、新しい支援会社は、理想論でルールを書き直すのではなく、実際に起きた迷いと事故前兆を踏まえて運用を改善できます。

個人情報漏えい初動の記録を運用改善へ戻す

個人情報保護委員会は、個人情報の漏えい等が発生した場合の対応について情報を公開しています。報告要否や本人通知の要否は個別事情で変わります。ベンダー変更時に見るべきなのは、法的結論そのものではなく、過去の漏えい懸念や誤入力が、社員教育・承認フロー・FAQ・月次レビューへ戻っているかです。

既存ベンダーからは、次の初動記録を回収してください。

初動記録	見る理由
発見者の報告内容	どの業務で、何が起きたかを見る
一次受付者	情シス、管理部門、法務、経営の誰が受けたかを見る
証拠保全	メール、ログ、共有リンク、AI入力履歴、SaaS操作履歴を確認する
影響範囲確認	対象情報、対象人数、対象顧客、委託先を把握する
外部連絡判断	PPC、本人、取引先、委託先への連絡判断プロセスを見る
社員への再周知	同じ事故を防ぐ教育に戻したかを見る
ルール改定	禁止事項、例外承認、FAQ、台帳へ反映したかを見る

この記録がないと、新しい支援会社は「事故時に何が詰まったのか」を把握できません。事故が起きていない会社でも、ヒヤリハットや問い合わせ履歴から初動フローを見直すべきです。

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

既存ベンダー変更では、感情的な不満より事実確認が重要です。次の質問をそのまま使えます。

1. AI・SaaS・クラウド利用台帳の最新版と更新履歴を提供できますか
2. 許可、禁止、申請制、例外利用の判断根拠はありますか
3. 社員教育資料、FAQ、受講履歴、理解度確認はありますか
4. 利用申請フォーム、承認フロー、例外承認台帳はありますか
5. 違反、ヒヤリハット、問い合わせ、未回答質問の履歴はありますか
6. 個人情報漏えい懸念や誤入力時の初動記録はありますか
7. 月次レビュー資料、改定履歴、次回見直し予定はありますか
8. 管理者権限、ログ確認手順、退職者・異動者対応はどこまで整理されていますか
9. 業務委託、派遣、外部パートナーの利用管理は対象に含まれていますか
10. 成果物のうち、当社が自由に改変・再利用できるものはどれですか
11. 新しい支援会社へ共有してよい資料と、共有できない資料はどれですか
12. 契約終了後、軽微な問い合わせや資料説明に対応できますか
13. 引き継ぎミーティングに参加できますか

この質問に答えられる既存ベンダーなら、完全変更ではなく、役割を分けて併用する選択肢もあります。例えば既存ベンダーに規程本文の法務寄りレビューを残し、新しい支援会社に利用台帳、教育、承認フロー、月次運用を任せる形です。

新しい支援会社に確認する質問

新しい支援会社には、「従業員利用管理をできますか」と聞くだけでは足りません。重要なのは、既存の社内ルール、利用台帳、教育履歴、例外承認を読み、次の運用へつなげられるかです。

候補会社には、次の質問をしてください。

1. 既存の社内ルールと利用台帳を対応表にできますか
2. 許可・禁止・申請制の判断根拠を再整理できますか
3. 社員教育履歴とFAQを見て、追加教育が必要な論点を抽出できますか
4. 例外承認、違反、ヒヤリハットをルール改定やFAQへ反映できますか
5. 新規利用申請、例外承認、インシデント報告のフローを再設計できますか
6. ChatGPT、Claude、Gemini、Copilot、議事録AI、AI機能付きSaaS、クラウド共有を横断して整理できますか
7. 管理者権限、ログ確認、退職者対応まで運用表にできますか
8. 法的助言が必要な論点と運用設計で整理できる論点を分けられますか
9. 個人情報漏えいが疑われる時の初動を、法務・情シス・経営へつなぐ形で設計できますか
10. 30日、60日、90日の移管計画を作れますか
11. 月次レビューと台帳更新を継続支援できますか

候補会社が規程本文だけを見て提案する場合、従業員利用管理の移管先としては弱いです。必要なのは、社員が実際にどう使い、どこで迷い、何を例外承認してきたかを読める会社です。

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

ベンダー変更は、いきなり新運用へ切り替えるのではなく、90日で安定化させるべきです。

期間	やること	成果物
1〜30日	既存資料回収、利用台帳棚卸し、教育履歴確認、例外承認・ヒヤリハット確認	移管診断表、資料不足一覧、リスク一覧、暫定対応方針
31〜60日	利用台帳再整備、許可・禁止・申請制区分の再設計、FAQ差分、初動フロー確認	新利用台帳、判断根拠表、FAQ差分表、初動フロー改定案
61〜90日	社員周知、管理職説明、例外承認運用、月次レビュー開始	教育資料、承認台帳、月次レビュー表、90日後改善計画

90日移管の目的は、既存ベンダーを責めることではありません。運用の空白期間を作らず、社員が迷った時の判断先を維持することです。

引き継ぎで削ってはいけない範囲

費用を抑えるために、すべてを初期移管に入れない判断はあり得ます。ただし、次の範囲は削らない方がよいです。

範囲	削ると起きること
利用台帳	実利用が見えず、ルールが空文化する
入力禁止情報判断表	社員がAI・SaaS・クラウド共有で迷う
教育履歴	誰に周知済みか説明できない
例外承認台帳	過去の条件付き利用が消える
ヒヤリハット記録	改善の材料が消える
個人情報漏えい初動	事故時に誰が何をするか分からない
成果物権利確認	新ベンダーが資料を使えない
月次レビュー	作って終わりになり、すぐ古くなる

削れるのは、eラーニング化、詳細なログ連携、自動ワークフロー化、多言語化、全部門同時展開などです。最初は手作業でも構いません。重要なのは、社員利用の実態、判断根拠、教育、例外、初動、更新サイクルを止めないことです。

部門別に見る引き継ぎポイント

従業員利用管理は、部門ごとにリスクが違います。

部門	引き継ぐべき利用実態	見るべきリスク
営業	商談メモ、提案書、CRM、議事録AI、要約AI	顧客名、価格、未公開提案の入力
CS	問い合わせ履歴、画面キャプチャ、FAQ化、委託先共有	個人情報、クレーム情報、顧客別事情
開発	ソースコード、ログ、APIキー、AIコーディング、外部開発会社	技術情報、認証情報、顧客固有仕様
人事	履歴書、評価、面談メモ、採用AI、外部媒体	個人情報、要配慮情報、採用判断
経理	請求、給与、振込、会計SaaS、士業共有	金銭情報、権限、外部委託
経営	役員資料、資金繰り、M&A、未公開情報	共有範囲、承認、閲覧権限

新しい支援会社には、全社共通ルールだけでなく、部門別のFAQと判断表を作れるか確認してください。

成果物権利と第三者共有を必ず確認する

既存ベンダー変更で見落としやすいのが、成果物権利です。台帳、FAQ、教育資料、判断表、月次レビュー表があっても、契約上、新しい支援会社へ共有できない場合があります。

確認すべき契約条件は次の通りです。

契約条件	確認すること
改変可否	自社や新ベンダーが内容を更新できるか
第三者共有	新しい支援会社へ渡せるか
社内配布	社員教育やポータル掲載に使えるか
編集可能形式	PDFだけでなく、Word、Excel、Google Sheet等で受け取れるか
テンプレート権利	ベンダー汎用テンプレートと自社成果物の範囲
契約終了後サポート	引き継ぎ説明や軽微質問に対応するか
資料削除	既存ベンダー側の保管・削除・返却の扱い

成果物権利が曖昧なまま新ベンダーに依頼すると、せっかく作った資料を使えず、再作成費用が発生します。ベンダー変更前に、資料の一覧と権利を確認してください。

資料が不足している時の見積条件

既存ベンダー変更でよくあるのは、「資料はあるはずだが、探すと足りない」という状態です。社内ルール本文はある。研修資料もある。ところが、誰が受講したか、どの質問が未回答か、どのAIを例外承認したか、月次レビューで何を直したかが残っていない。この場合、新しい支援会社に「運用引き継ぎ」を依頼しても、実際には調査と再設計から始まります。

見積条件では、資料不足を隠さず、次のように書き分けてください。

不足資料	見積に入れる作業	追加費用が出る理由
利用台帳がない	部門ヒアリング、SaaS管理画面確認、利用申請の再作成	実利用の棚卸しが必要
教育履歴がない	受講対象者整理、再周知、理解度確認の再実施	周知証跡を作り直す必要がある
FAQがない	問い合わせ履歴の収集、部門別FAQ作成	現場の迷いをゼロから拾う
例外承認台帳がない	過去例外の聞き取り、暫定例外リスト作成	条件付き利用が見えない
ヒヤリハット記録がない	過去トラブルの聞き取り、再発防止候補の整理	改善材料が消えている
初動フローがない	発見、報告、証拠保全、外部連絡判断の設計	事故時運用を新規設計する必要がある
成果物権利が不明	契約書確認、共有可否整理、再作成範囲の判断	新ベンダーが既存資料を使えない可能性がある

資料不足は恥ずかしいことではありません。問題は、資料が不足しているのに「引き継ぎだけで済む」と考えることです。新ベンダーの見積には、移管、再調査、再設計、再教育、月次運用を分けて入れてください。

移管診断は100点満点で見る

既存ベンダーを変更するかどうかは、感覚ではなく移管診断で判断します。次の100点満点で見ると、どこを先に補うべきかが分かります。

評価項目	配点	見るポイント
利用実態の可視化	15	AI、SaaS、クラウド、委託先共有の実利用が台帳化されているか
情報分類と判断表	15	個人情報、顧客情報、技術情報、認証情報の入力・共有判断があるか
教育・FAQ	15	社員教育、管理職教育、部門別FAQ、受講履歴が残っているか
例外承認・ヒヤリハット	15	例外、違反、事故未満事例が記録され、改善に使われているか
初動フロー	10	個人情報漏えい懸念時の発見、報告、証拠保全、外部連絡判断があるか
権限・ログ	10	管理者、ログ確認、退職者・異動者対応、委託先利用停止が整理されているか
成果物権利	10	改変、社内配布、第三者共有、編集可能形式が確認できているか
月次運用	10	台帳更新、FAQ改定、例外見直し、教育追加の会議体があるか

80点未満なら、ベンダー変更前に資料回収と再設計の予算を確保すべきです。90点以上なら、既存資料を活かした移管が可能です。95点以上なら、既存ベンダーを完全に切り替えるのではなく、役割分担でコストを抑えられる可能性があります。

重要なのは、点数を既存ベンダーの評価だけに使わないことです。点数が低い場合、既存ベンダーが悪いとは限りません。自社側で利用実態を共有していない、部門が勝手にSaaSを増やしている、例外承認を口頭で済ませている、教育履歴を残していないこともあります。移管診断は、責任追及ではなく、次の90日で何を直すかを決めるための道具です。

経営会議で確認する判断表

従業員利用管理のベンダー変更は、情シスや管理部門だけで決めると失敗します。社員のAI・SaaS利用は、営業効率、開発生産性、採用、顧客対応、委託先運用に関わるため、経営会議で判断すべき論点があります。

経営判断	確認すること	決めないと起きること
利用を止めるのか、安全に使わせるのか	禁止中心か、許可条件を整えるか	現場が隠れて使う
どの部門を優先するか	営業、CS、開発、人事、経理、経営の優先順位	全部中途半端になる
既存ベンダーを残すか	法務レビュー、教育、台帳運用の役割分担	全面変更で再作成費用が増える
月次運用を誰が持つか	情シス、管理部門、法務、現場責任者、外部支援	作って終わりになる
例外をどこまで認めるか	事業上必要な利用と禁止すべき利用の線引き	例外が属人化する
事故時に誰が止めるか	利用停止、社外連絡、顧客説明の承認者	初動が遅れる
どこまで外部委託するか	台帳更新、教育、FAQ、月次レビュー、初動訓練	予算と責任が曖昧になる

経営者が決めるべきなのは、細かいツール名ではありません。会社として、どの情報を守りながら、どの業務ではAIやSaaSを使わせるのか。事故時に誰が止めるのか。月次運用を社内で持つのか、外部支援を入れるのか。この判断がないままベンダーを変えても、支援会社が変わるだけで、社員の行動は変わりません。

既存ベンダーを変えるべきか、併用すべきか

既存ベンダー変更は、必ずしも全面変更が正解ではありません。次の表で判断します。

状態	判断
既存ベンダーが規程本文と法務整理に強いが、運用が弱い	既存ベンダーを法務寄りレビューに残し、新ベンダーに運用を任せる
既存ベンダーが教育とFAQに強いが、AI・SaaS台帳が弱い	教育資料を活かし、新ベンダーで利用台帳と承認フローを再設計する
既存ベンダーが資料共有に非協力的	契約権利と成果物回収を優先し、移管リスクを見積に入れる
既存ベンダーの成果物がPDFだけ	編集可能形式への変換と再設計費用を見込む
既存ベンダーが月次運用に対応できない	新ベンダーへ月次レビューと台帳更新を移す
既存ベンダーが事故時初動に弱い	法務・情シス・専門家連携を含む初動設計を追加する

「不満があるから全部変える」ではなく、「何を残し、何を移し、何を作り直すか」で判断してください。

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

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

• 既存ベンダーが作った資料のうち、何を新ベンダーへ渡せるか分からない
• 社員のAI・SaaS利用実態が台帳と合っていない
• 教育履歴、FAQ、例外承認、ヒヤリハットが散らばっている
• 個人情報漏えいが疑われる時の初動フローが、従業員利用管理に反映されていない
• 既存ベンダー変更後も、月次レビューと社員問い合わせ対応を止めたくない
• 新しい支援会社の見積に、調査、再設計、教育、運用が含まれているか判断できない

GXOでは、情報漏えいの従業員利用管理について、既存ベンダー成果物の棚卸し、利用台帳再整備、AI・SaaS・クラウド共有の判断表、社員教育FAQ、例外承認台帳、個人情報漏えい初動、月次レビュー運用まで一気通貫で支援できます。

相談の入口は、AI活用・AI社内ルールの相談 です。既存ベンダーを変える前なら、まず「何を回収し、何を残し、何を新ベンダーへ移すべきか」から整理できます。すでに新ベンダー候補がいる場合は、見積と提案内容を見て、移管漏れと追加費用リスクを洗い出せます。

関連記事

• 情報漏えい社内ルール作成の既存ベンダー変更: 情報漏えい社内ルール作成で既存ベンダーを変更する前に見る引き継ぎ条件・責任分界
• 情報漏えい社内ルール作成の見積前整理: 情報漏えい社内ルール作成を見積依頼する前に整理する要件・費用・運用条件
• 情報漏えい社内ルール作成RFP: 情報漏えい社内ルール作成RFPに入れるべき要件・評価軸・契約条件
• ChatGPT利用時の情報漏えい対策: ChatGPTの情報漏えいリスクを3層で防ぐ：入力・学習・外部送信の実務ガイド
• シャドーAIとAI台帳: 国内企業がAI台帳を作るべき理由：無料ツール乱立と情報漏えいを防ぐ
• 親ピラー: 生成AI社内ルール・ガバナンスの全体設計

参照した一次情報

• 個人情報保護委員会「漏えい等の対応」: https://www.ppc.go.jp/personalinfo/legal/leakAction/
• IPA「情報セキュリティ10大脅威」: https://www.ipa.go.jp/security/10threats/
• 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/

2026年7月8日時点で、上記4件はHTTP 200で確認しました。NISCは本制作時点でHTTP 403となったため、この記事では断定根拠として使わず、残余確認対象にしています。個人情報保護委員会の報告要否や本人通知の判断は、個別事情により変わります。本記事は法的助言ではなく、従業員利用管理のベンダー変更時に社内初動と専門家連携を設計するための実務ガイドです。