経営者向け：データ漏えいを防ぐ権限設計で既存ベンダーを変更する前に見る引き継ぎ条件

先に結論：権限設計のベンダー変更は「アカウント一覧の引き継ぎ」ではなく「漏えいを止める権限構造の移管」です

データ漏えい対策のために権限設計を見直したい。既存ベンダーが作ったAIシステム、社内検索、RAG、AIエージェント、業務アプリ、SaaS連携、ファイル共有、顧客管理、問い合わせ管理を別会社へ引き継ぎたい。ところが、既存ベンダーから出てくる資料は、管理画面のスクリーンショット、ユーザー一覧、ロール名、簡単な構成図だけ。誰がどの顧客情報を読めるのか。AIがどの文書を検索するのか。サービスアカウントがどのAPIを実行できるのか。退職者、外部委託先、旧管理者の権限は残っていないのか。DLPやログで過剰権限を検知できるのか。ここが分からないままベンダーを変える会社は、移管後にデータ漏えいリスクを抱えます。

権限設計の引き継ぎで見るべきものは、単なるユーザー一覧ではありません。見るべきものは、読み取り、書き込み、送信、削除、エクスポート、共有、権限変更、外部API実行、AI参照、AI出力、ログ閲覧、DLP例外、緊急停止の構造です。

結論は次の10点です。

1. ユーザー一覧ではなく、業務、データ、操作、ロール、例外、承認、ログをつなげた権限台帳を引き継ぐ
2. 管理者権限、外部委託先権限、退職者権限、サービスアカウント、APIキーを最初に棚卸しする
3. RAGは「社内文書を検索できる」ではなく、文書単位、部門単位、顧客単位、案件単位で参照権限を確認する
4. AIエージェントは、読み取り、下書き、送信、削除、権限変更、外部共有を分けて引き継ぐ
5. DLP、CASB、ID管理、SIEM、監査ログと権限設計がつながっているかを見る
6. 既存ベンダーが権限変更できる状態をいつ止め、誰へ移すかを移管計画に入れる
7. 契約上、設定、ロール定義、権限表、ログ、テスト結果を新ベンダーへ共有できるか確認する
8. 引き継ぎ後は、権限を増やす前に、過剰権限、例外権限、共有リンク、旧APIキーを減らす
9. 検収条件は、画面が動くことではなく、権限テスト、ログ確認、DLP検知、停止訓練まで含める
10. 権限設計は一度作って終わりではなく、月次で差分を見ないとすぐに崩れる

本記事は、データ漏えいを防ぐ権限設計について、既存ベンダーを変更、併用、再設計する前に見る引き継ぎ条件を扱います。AI安全導入全体の移管条件ではありません。初回見積前の要件整理でも、正式RFPの書き方でもありません。主語は「権限」です。誰が、何を、どこまで、どの証跡つきで扱えるかを移管できるかに絞ります。

この記事を読むべき会社

この記事は、AI導入、社内検索、RAG、AIエージェント、AI機能付きSaaS、顧客管理、問い合わせ管理、ファイル共有、業務アプリ、データ基盤、開発環境などで、データ漏えいを防ぐ権限設計を既存ベンダーから別会社へ引き継ぎたい中小・中堅企業の経営者、CIO、DX責任者、情シス責任者、セキュリティ責任者、管理部門、法務向けです。

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

• 既存ベンダーが作ったAI・システムの権限設計を別会社に見直してほしい
• ユーザー一覧はあるが、ロールごとに何ができるか分からない
• 管理者、外部委託先、退職者、旧担当者、サービスアカウントの権限が残っていないか不安
• RAGがどの文書を読んでいるか、部署や顧客ごとに分かれているか確認できない
• AIエージェントがSaaSやAPIを操作するが、送信、削除、権限変更が分離されていない
• DLPやログはあるが、権限変更、外部共有、大量出力、例外承認を追えるか分からない
• 既存ベンダー変更時に、設定やログを渡してもらえるか契約上不明
• 新ベンダーに相談したいが、何を引き継げば再調査費を抑えられるか分からない
• データ漏えい疑い時に、誰の権限を止めればよいか社内で即答できない

AI導入全体の移管条件を知りたい場合は、データ漏えい安全導入の既存ベンダー変更記事が近いです。複数候補会社へ正式RFPを出す段階なら、RFP記事が近いです。本記事は、既存ベンダー変更時に権限設計だけを深く見る記事です。

既存記事との違い：この記事は「権限設計の移管」に絞る

同じ「権限」という言葉でも、初期設計、RFP、運用監査、既存ベンダー変更では検索意図が違います。本記事では、既存ベンダーから権限設計をどう回収し、どの順番で止め、どの順番で新ベンダーへ渡すかを扱います。

既存ベンダーから回収すべき権限資料

権限設計の移管で最初にやることは、現状の権限構造を可視化することです。ユーザー一覧だけでは足りません。次の資料を既存ベンダーから回収します。

この10資料がそろわない場合、新ベンダーは権限設計を引き継ぐのではなく、再調査から始める必要があります。経営者は、見積の安さより「何が回収でき、何が再調査になるか」を先に見てください。

権限台帳は5つの軸で作る

権限台帳は、ユーザー名とロール名を並べるだけでは使えません。データ漏えいを防ぐための権限台帳は、少なくとも次の5つの軸で作ります。

この5軸がない権限台帳は、監査や事故対応で使いにくいです。たとえば「営業部ロール」と書いてあっても、顧客別の提案書を見られるのか、全顧客の契約書をエクスポートできるのか、AIがその文書をRAGで参照できるのか、ログに残るのかが分からなければ、漏えい対策としては不十分です。

移管前に止めるべき権限

既存ベンダー変更では、新ベンダーへ権限を渡す前に、止めるべき権限があります。移管作業を急ぐあまり、旧権限と新権限が重なったままになると、一時的に漏えいリスクが上がります。

優先して止めるべき権限は次の通りです。

止める順番を決めずに移管すると、業務停止を恐れて全部残す判断になりがちです。権限設計のベンダー変更では、「残す権限」より先に「止める権限」を決めます。

RAG参照権限の引き継ぎ

RAGの権限設計は、通常のファイル共有より難しいです。人間がファイルを開く権限と、AIが検索して回答へ混ぜる権限は同じように見えて、実務上は別物だからです。人間なら見落とす情報でも、AIは複数文書から要約して回答します。1つの回答に、顧客Aの契約条件、顧客Bの問い合わせ履歴、社内の価格表、未公開の営業資料が混ざると、本人は意図していなくても漏えいになります。

移管時には、RAGについて次を確認します。

既存ベンダーが「RAGは社内限定なので安全です」と説明する場合、そこから先を必ず聞いてください。社内限定でも、部門間、役職間、顧客間、案件間の権限差がなければ、社内漏えいは起きます。

データ別に権限を分ける

権限設計の引き継ぎで失敗しやすいのは、システム別、画面別、部署別だけで権限を見てしまうことです。データ漏えいを防ぐには、データの種類ごとに、誰が、どの操作を、どの条件でできるかを見る必要があります。

この表を作ると、新ベンダーへ渡すべき情報が明確になります。たとえば、契約書の読み取り権限は法務と担当役員に限定するが、RAGが契約書全文を読むなら、AIの回答にも同じ制限が必要です。問い合わせ履歴はCSが読めても、全件エクスポートは管理者承認にする。障害ログは開発が見ても、個人情報や認証情報が混ざるため、AIへ渡す時はマスキングする。この粒度まで決めないと、権限設計は「部署別ロール」で止まり、実際の漏えい経路を塞げません。

既存ベンダーへの質問票

既存ベンダー変更前には、感情的に「資料を全部ください」と依頼するのではなく、権限設計に必要な質問を出します。質問票にしておくと、回答できない項目がそのまま新ベンダーの再調査範囲になります。

この質問票で重要なのは、回答の有無だけでなく、回答の粒度です。「あります」では不十分です。どこにあり、誰が管理し、いつ更新され、どの形式で渡せるかまで確認します。回答がPDFやスクリーンショットだけの場合、新ベンダーは再入力や再設計に時間を使います。CSV、JSON、設定エクスポート、管理画面の権限エクスポート、ログ検索クエリの形で渡せるほど、移管費用は下がります。

AIエージェント操作権限の引き継ぎ

AIエージェントの権限は、読み取り権限だけではありません。AIがCRMを更新する。メール下書きを作る。チケットを閉じる。ファイルを移動する。カレンダーを変更する。SaaSの顧客情報を編集する。開発環境でコードを変更する。こうした操作は、データ漏えいだけでなく、誤送信、誤削除、誤更新、権限誤付与にもつながります。

移管時には、AIエージェントの操作を次のように分けます。

既存ベンダーから新ベンダーへ移す時は、AIエージェントの権限をいったん読み取り中心に戻す判断もあります。便利さは落ちますが、移管直後は責任分界が揺れやすいため、高リスク操作を止めた状態で再検証する方が安全です。

サービスアカウントとAPIキーは人の権限より危険なことがある

経営者が見落としやすいのが、サービスアカウントとAPIキーです。人のアカウントは退職や異動で気づきますが、サービスアカウントは誰にも紐づかず、長期間残ります。しかも、AI連携、RAG取り込み、夜間バッチ、SaaS同期、ログ転送、外部API呼び出しで強い権限を持っていることがあります。

移管時には、次の質問を既存ベンダーへ出します。

1. サービスアカウントはいくつありますか
2. それぞれの用途、作成者、管理者、最終利用日、権限範囲は何ですか
3. APIキー、秘密鍵、Webhook、OAuthアプリはどこで管理していますか
4. 旧ベンダーだけが見られる管理画面やシークレットストアはありますか
5. キーローテーションの手順と停止時の影響は分かりますか
6. 契約終了時にどのキーを失効し、どのキーを再発行しますか

サービスアカウントは「誰が使ったか」ではなく「何が使ったか」を追う必要があります。ログが人の名前でなくシステム名だけになっている場合、事故時の原因追跡が難しくなります。

DLP・ログ・ID管理と権限設計をつなげる

権限設計は、設定画面だけで完結しません。DLP、CASB、ID管理、MFA、端末管理、SIEM、監査ログとつながって初めて、漏えいを止め、検知し、説明できます。

既存ベンダー変更時には、これらの連携設定が誰の管理下にあるかを確認します。AIアプリ側の権限は新ベンダーへ移したが、DLPやログは旧ベンダーが設定したまま、という状態は危険です。運用で見ている人がいなければ、設定が存在しても実質的には機能していません。

契約で確認するべきこと

権限設計は技術だけでなく、契約で止まることがあります。既存ベンダーが作ったロール定義、権限表、設定ファイル、RAGメタデータ、AIエージェント操作定義、ログ抽出手順を、新ベンダーへ共有できるとは限りません。

契約上、次を確認してください。

契約確認を後回しにすると、権限設計のレビューはできても、設定変更やログ確認ができないことがあります。新ベンダーへの相談前に、契約で出せる資料と出せない資料を分けてください。

90日移管計画

権限設計の移管は、いきなり全権限を作り直すのではなく、90日で段階的に進めます。

この90日計画で重要なのは、権限を増やす作業より、不要な権限を減らす作業を先に置くことです。新ベンダーに早く作業してもらうために強い管理者権限を渡すと、旧ベンダー、新ベンダー、社内管理者、サービスアカウントが同時に強い権限を持つ期間ができます。この期間こそ漏えいリスクが高くなります。

移管会議で決める責任分界

権限設計のベンダー変更では、技術作業よりも責任分界が曖昧なまま進むことがよくあります。既存ベンダーは「現在の設定は説明できるが、変更後は責任を持てない」と言う。新ベンダーは「調査には管理者権限が必要」と言う。社内担当は「業務停止は困るので、今の権限を残したい」と言う。法務は「ログや個人情報をどこまで渡してよいか確認したい」と言う。この状態で移管を始めると、誰も止める判断をしないまま強い権限が残ります。

移管会議では、次の責任分界を決めます。

この会議で大事なのは、「誰が作業するか」ではなく「誰が止める判断をするか」です。漏えいリスクが高い権限を見つけた時、旧ベンダーが止めるのか、新ベンダーが止めるのか、社内情シスが止めるのか、経営者が承認するのか。ここが決まっていないと、危険な権限ほど残ります。

また、移管会議の議事録には、残したリスクを明記します。たとえば「営業部の一部共有リンクは顧客対応のため30日だけ残す」「旧ベンダーの閲覧専用アカウントは移管作業のため14日だけ残す」「RAGの契約書フォルダは権限テスト完了まで検索対象から外す」といった形です。リスクを残すこと自体は悪ではありません。悪いのは、残したリスクの期限、承認者、確認日がないことです。

権限剥奪と再付与の実例

権限移管では、すべてを一度に止めると業務が止まります。一方で、業務影響を恐れて何も止めないと、旧権限が残ります。実務では、剥奪、暫定付与、再付与の3段階で進めます。

1. 旧ベンダー管理者権限

旧ベンダーの管理者権限は、移管初日にいきなり全部止めるのではなく、作業計画に合わせて段階的に下げます。まず、ユーザー追加、権限変更、ログ削除、外部連携変更を停止します。次に、閲覧専用権限へ下げます。最後に、移管完了後にアカウントを停止します。どうしても旧ベンダーの協力が必要な場合は、作業日時、作業内容、承認者、ログ確認者を決めたうえで一時権限にします。

2. 新ベンダー調査権限

新ベンダーへ最初からフル管理者権限を渡すのは避けます。初期調査では、閲覧専用、ログ閲覧、設定閲覧、エクスポート不可の権限から始めます。設定変更が必要になった段階で、作業単位の一時権限を発行します。新ベンダーの担当者ごとに個別アカウントを発行し、共有アカウントは使わせないことが重要です。

3. サービスアカウント

サービスアカウントは、停止すると業務バッチやAI連携が止まることがあります。まず最終利用日と実行元を確認します。使われていないものは停止候補にします。使われているものは、用途別に分割し、読み取り専用、書き込み可、管理操作可を分けます。旧ベンダーが管理していたキーは再発行し、保管場所を顧客管理のシークレット管理へ移します。

4. RAG参照権限

RAGは、文書を取り込み直すより先に、検索対象のメタデータと権限連動を確認します。全件検索になっている場合は、いったん高機密フォルダ、契約書、個人情報を含む文書、障害ログを除外します。そのうえで、部門別、顧客別、案件別に再付与します。RAGの便利さより、誤回答で機密情報を混ぜないことを優先します。

5. 外部共有権限

外部共有リンクは、棚卸しだけでなく期限設定が必要です。期限なしリンク、誰でも閲覧できるリンク、退職者が作ったリンク、旧ベンダーが作ったリンクを抽出します。業務上必要なものだけ、相手、期限、目的、承認者を付けて再発行します。共有リンクをそのまま引き継ぐと、移管後も旧経路が残ります。

このように、権限移管は「全部止める」か「全部残す」ではありません。経営者が見るべきなのは、業務影響を抑えながら、強い権限をどれだけ早く短時間化できるかです。

検収条件

権限設計の移管は、ログインできる、画面が動く、AIが回答する、だけでは検収できません。次の条件を検収に入れます。

この検収条件を満たさないまま「移管完了」とすると、見た目は新ベンダーへ移ったのに、旧権限や過剰権限が残り続けます。

検収では、スクリーンショットだけでなく、実際に低権限ユーザー、外部委託先ユーザー、管理者、サービスアカウントを使ったテスト結果を残します。権限設計は説明資料ではなく、実際の挙動で確認するものです。

月次で見るべき権限KPI

権限設計は、移管完了後に放置するとすぐ崩れます。新しい社員が入る。外部委託先が増える。SaaSが増える。AI機能が追加される。RAGに文書が追加される。AIエージェントに新しいAPIをつなぐ。こうした変化が毎月起きるため、経営者は細かなログではなく、月次の権限KPIを見ます。

このKPIを月次で見ると、権限設計が「作った時だけ正しい」状態から抜けられます。GXOの支援では、月次レビューで増えた権限、残った例外、止めるべきサービスアカウント、RAGの追加文書、AIエージェントの高リスク操作を確認し、次月の改善に落とします。

経営者が見るべき赤信号

次の状態があるなら、ベンダー変更前に止まって確認してください。

• 既存ベンダーが「管理者権限は弊社で管理しています」と言うが、一覧を出せない
• ロール名はあるが、読み取り、書き込み、削除、エクスポート、共有が分かれていない
• RAGの参照文書が「社内共有フォルダ全部」になっている
• AIエージェントが外部送信、削除、権限変更を自動実行できる
• サービスアカウントやAPIキーの作成者、用途、最終利用日が分からない
• DLP例外や許可リストが増えているが、承認履歴がない
• 監査ログはあるが、権限変更や外部共有の検索方法が分からない
• 旧ベンダーがログや設定をPDFでしか出さない
• 契約終了時の削除証跡、ログ引き渡し、設定エクスポートが契約にない
• 新ベンダーへ強い管理者権限を渡さないと調査できないと言われている

赤信号があるから即中止ではありません。しかし、追加見積、再調査、契約確認、緊急停止を前提にした方がよいです。

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

次のどれかに当てはまるなら、既存ベンダー変更前に相談した方がよいです。

• 権限設計がブラックボックスで、既存ベンダーしか説明できない
• RAGやAIエージェントの権限が強く、漏えい時に止める順番が決まっていない
• 外部委託先、退職者、旧管理者、サービスアカウントの棚卸しができていない
• DLP、ログ、ID管理、AI利用がつながっていない
• 新ベンダーへ何を渡せば調査費を抑えられるか分からない
• 契約上、設定、ログ、権限表を共有できるか不明

GXOでは、データ漏えいを防ぐ権限設計について、既存ベンダー成果物レビュー、権限台帳作成、RAG参照権限テスト、AIエージェント操作権限分離、DLP・ログ連携確認、契約条件レビュー、90日移管計画まで一体で支援できます。

相談先は AI活用・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/

2026年7月9日時点で、上記の公式ページが閲覧可能であることを確認しています。本記事は法的助言ではなく、権限設計、ベンダー変更、移管計画、検収条件設計の実務ガイドです。個別の法的判断は、顧問弁護士、個人情報保護、セキュリティ、契約実務の専門家と確認してください。