経営者向け：データ漏えいを防ぐ権限設計を見積依頼する前に整理する範囲・費用・本番化条件

先に結論：権限設計の見積は「人数と画面数」では決まりません

データ漏えいを防ぐために権限設計を見直したい。AI導入、社内検索、RAG、AIエージェント、SaaS連携、顧客管理、問い合わせ管理、ファイル共有、業務アプリの権限を整えたい。経営会議では「まず数社に見積を取ろう」と決まる。そこでベンダーに、利用人数、対象システム、ざっくりした機能一覧を渡す。

この時点で見積が崩れます。

権限設計の費用は、利用人数だけでは決まりません。誰が何を読めるか。誰が書けるか。誰がエクスポートできるか。誰が外部共有できるか。AIがどの文書を参照できるか。AIエージェントが送信、削除、承認、権限変更をできるか。サービスアカウントやAPIキーがどこまで操作できるか。例外承認を誰が持つか。ログで追えるか。DLPで止められるか。退職者、外部委託先、旧ベンダーの権限をどう扱うか。これらが曖昧なまま見積を取ると、初期費用は安く見えても、本番化直前に追加調査、追加設計、追加テスト、運用設計が発生します。

見積依頼前に経営者が決めるべきことは、次の10点です。

1. 権限設計の対象を、ユーザー、部門、外部委託先、サービスアカウント、AI、APIに分ける
2. 守るデータを、個人情報、顧客情報、契約情報、営業情報、技術情報、認証情報、経営情報に分ける
3. 操作を、閲覧、作成、編集、削除、承認、エクスポート、外部共有、権限変更、AI参照、API実行に分ける
4. RAGや社内検索は、文書単位、部署単位、顧客単位、案件単位の参照権限を見積条件に入れる
5. AIエージェントは、読み取り、下書き、送信、削除、権限変更、外部API実行を別費用で見積もる
6. DLP、ログ、ID管理、監査、例外承認を「後で考える」ではなく初期条件に入れる
7. PoC、本番化、運用、月次監査、教育、初動対応を分けて見積もる
8. 低予算で始める場合でも、権限台帳、データ分類、ログ方針、停止手順は削らない
9. 本番化条件を、画面が動くことではなく、権限テスト、ログ確認、DLP検知、権限剥奪訓練で定義する
10. 見積依頼前に、初期範囲、後回し範囲、やらない範囲を1枚で説明できる状態にする

本記事は、データ漏えいを防ぐ権限設計について、見積依頼前に整理すべき要件、費用、本番化条件を扱います。既存ベンダーを変更する引き継ぎ記事ではありません。複数候補会社へ正式RFPを出す記事でもありません。まだ見積依頼前、または見積は取ったが比較できない経営者向けに、権限設計だけを深掘りします。

この記事を読むべき会社

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

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

• 権限設計を外部へ相談したいが、何を見積条件として渡せばよいか分からない
• AI導入やRAG導入の話が進んでいるが、誰がどの文書を読めるか整理できていない
• 顧客情報、契約書、問い合わせ履歴、営業資料、開発情報をAIやSaaSで扱う可能性がある
• 見積にDLP、ログ、ID管理、権限テスト、例外承認が含まれているか判断できない
• 初期費用を抑えたいが、削ると危ない権限設計の項目が分からない
• 外部委託先、退職者、旧担当者、サービスアカウント、APIキーの管理が曖昧
• AIエージェントがメール、CRM、ストレージ、チケット管理、社内DBを操作する可能性がある
• 情シス、法務、現場、経営の確認順が決まっていない
• 個人情報漏えい疑い時に、誰の権限を止め、どのログを確認するか決まっていない

既存ベンダーから別会社へ権限設計を移す段階なら、既存ベンダー変更の記事が近いです。候補会社へ正式なRFPを出す段階なら、RFP記事が近くなります。本記事は、見積依頼前に権限設計の範囲と費用条件を整理するための記事です。

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

本記事の主語は「権限設計を見積依頼する前に、どこまでを初期費用に含めるか」です。既存権限を移管する方法でも、正式RFPの文言でもありません。検索意図を分けるために、本文でも見積前の判断表、費用分解、削ってはいけない項目に集中します。

見積前に最初に作るべき権限対象リスト

見積依頼前に、まず「誰の権限を設計するのか」を分けます。ここが曖昧なままだと、ベンダーは人間ユーザーだけを見積もり、サービスアカウント、AI、API、外部委託先が別費用になります。

この表を作らずに見積を取ると、「ユーザー権限設計一式」という曖昧な項目になります。安く見える見積ほど、RAG、AIエージェント、DLP、ログ、APIキー、例外承認が含まれていないことがあります。

守るデータを分類しないと権限費用は決まりません

権限設計は、ユーザーを増やす作業ではありません。守るデータに合わせて、誰にどの操作を許すかを決める作業です。見積前に、最低限次の分類を作ります。

データ分類がないまま権限設計を頼むと、ベンダーは一般的なロールを作ります。一般的なロールは、漏えいを止めるには弱いです。たとえば「営業部」は顧客情報を見られる、という設計だけでは、担当外の顧客、退職予定者、派遣社員、外部営業支援会社、営業AIの参照範囲まで決まりません。

見積依頼前の段階では、完璧な情報分類規程までは不要です。ただし、少なくとも「AIへ渡してよいデータ」「AIへ渡す前にマスキングするデータ」「AIへ渡さないデータ」「社外共有禁止データ」「ログ保存が必要なデータ」は分けます。

操作権限を分ける：閲覧できることと外へ出せることは違います

権限設計の見積でよくある失敗は、「閲覧可」「編集可」「管理者」の3区分だけで考えることです。データ漏えいを防ぐには、操作をもっと細かく分けます。

見積前にこの操作分類を渡すと、ベンダーの見積は現実に近づきます。逆に、この分類を渡さないまま「権限設計をお願いします」と頼むと、実装後に「外部共有制御は別途」「AI参照権限は別途」「DLP連携は別途」「監査ログは別途」になりがちです。

RAG・社内検索の権限設計は別項目で見積もる

RAGや社内検索AIでは、「社内文書を検索できる」こと自体が危険になります。人間がフォルダ階層で探す時には偶然見つからなかった文書でも、AIは質問に対して要約して出してしまいます。権限設計を見積もる時は、RAGを通常の画面権限と分けて扱います。

見積前に整理するRAG権限の論点は次です。

RAG権限は、あとから追加すると高くなります。最初に文書を全部取り込んでから権限を直すより、初期の取り込み範囲と除外範囲を決めてから進める方が安く、漏えいリスクも下がります。

AIエージェントの操作権限は「便利機能」ではなく高リスク項目です

AIエージェントがSaaSやAPIを操作する場合、権限設計の見積はさらに複雑になります。AIが読むだけならまだしも、メール送信、CRM更新、ファイル共有、チケット起票、請求データ作成、顧客への返信、権限変更、API実行を行うなら、人間の権限設計とは別に設計します。

低予算のPoCでは、AIエージェントの権限を読み取りと下書きに限定するのが現実的です。送信、削除、権限変更、外部API実行まで初期に入れるなら、費用だけでなく、承認フロー、ログ、テスト、停止手順も増えます。見積比較では、ここを含む見積と含まない見積を同列に並べてはいけません。

見積費用は8つに分ける

権限設計の見積を「一式」で見ると、安いか高いか判断できません。最低限、次の8つに分けて見ます。

この8分解で見積を比較すると、単価の安さではなく、抜け漏れが見えます。たとえばA社は初期費用が安いがテストと運用が薄い。B社は高いがRAG権限とDLP連携まで含む。C社はAIエージェントの送信・削除を本番化条件に入れている。こうした違いを経営判断できます。

初期範囲を小さくする時に削ってよいもの、削ってはいけないもの

予算を抑えて始めること自体は悪くありません。問題は、削ってよい項目と削ってはいけない項目を混同することです。

小さく始めるなら、範囲を削ります。安全装置を削ってはいけません。権限設計で一番危ないのは、初期費用を下げるために、ログ、DLP、停止手順、管理者分離、サービスアカウント管理を後回しにすることです。

見積依頼前に作る1枚資料

ベンダーに最初に渡す資料は、長い要件定義書でなくてもかまいません。ただし、次の1枚は作るべきです。

この1枚があるだけで、見積の精度は大きく変わります。ベンダーは、調査が必要な部分、初期に実装する部分、運用で対応する部分、後回しにできる部分を分けて提案できます。経営者も、安い見積が本当に安いのか、単に範囲が抜けているだけなのか判断しやすくなります。

本番化条件は「権限テスト」で決める

権限設計の本番化条件を、画面が動くことやログインできることにしてはいけません。データ漏えいを防ぐ目的なら、本番化条件は権限テストで決めます。

見積依頼前にこのテストを提示すれば、ベンダーは「どこまで確認するか」を見積に入れられます。逆に、テストを決めずに本番化すると、事故が起きてから「その操作はログに残していません」「その共有はDLP対象外です」「AI回答の根拠は分かりません」となります。

責任分界を見積前に決める

権限設計は、ベンダーだけで完結しません。社内のデータオーナー、情シス、法務、現場責任者、外部委託先、SaaS提供会社が関係します。見積前に責任分界を決めないと、ベンダー見積に含まれる範囲が曖昧になります。

データの重要度をベンダーに丸投げしてはいけません。ベンダーは設計と実装の支援はできますが、どの顧客情報が営業上重要か、どの契約条件が社外秘か、どの人事情報をAIに読ませてはいけないかは、社内が判断する必要があります。

安い見積を選ぶ前に見る危険サイン

権限設計の見積で、次の表現が出てきたら注意が必要です。

安い見積を否定する必要はありません。ただし、何が含まれ、何が含まれないかを確認せずに選ぶと、結果として高くなります。権限設計では、初期の見積に安全装置が含まれているかが重要です。

見積依頼前にベンダーへ聞く質問票

見積前に候補会社へ聞く質問は、機能の有無だけでは足りません。権限設計では、相手がどこまで漏えい防止の実務を想定しているかを見ます。次の質問に具体的に答えられない場合、初期費用は安くても、本番化前に追加費用が出る可能性があります。

この質問票は、ベンダーを困らせるためのものではありません。むしろ、良いベンダーほど早い段階で範囲を分けたがります。権限設計は曖昧なまま請けると、ベンダー側にもリスクがあります。見積前に質問することで、双方の前提をそろえられます。

社内稟議で説明すべき費用対効果

権限設計は、売上を直接増やす機能ではないため、社内稟議で後回しにされがちです。しかし、AI導入やSaaS連携が進むほど、権限設計を後回しにした時の損失は大きくなります。経営者は、単なるセキュリティ費用ではなく、事業継続と追加費用抑制の観点で説明する必要があります。

稟議では、次のように説明すると伝わりやすくなります。

費用対効果を説明する時は、「漏えいをゼロにする」と言い切らない方がよいです。現実的には、漏えい確率を下げ、漏えい疑い時に早く止め、影響範囲を説明できる状態を作ることが目的です。権限設計の見積前整理は、事故を完全に消す魔法ではなく、事故時に会社が説明できる構造を作るための投資です。

90日で進める場合の現実的なロードマップ

権限設計を一気に全社展開しようとすると、現場確認、SaaS制約、既存データの例外、外部委託先の契約確認で止まります。見積前には、最初の90日でどこまで進めるかを決めておくと、費用が現実的になります。

このロードマップを見積条件に入れると、ベンダーは「初期診断だけ」「設計まで」「本番設定まで」「運用監査まで」を分けて提案できます。経営者は、まず診断だけを発注するのか、90日で本番化まで進めるのか、月次監査まで含めるのかを選べます。

見積比較の採点表

複数社から見積を取る場合、金額だけで比較すると失敗します。権限設計では、含まれる成果物とテストの厚みを点数化します。

100点満点で採点し、70点未満の見積は、金額が安くても危険です。80点以上でも、DLPやログが別費用なら、本番化前に追加予算を見込むべきです。95点以上の見積は高く見えることがありますが、権限台帳、RAG権限テスト、AIエージェント操作分離、停止手順、月次監査まで含むなら、後戻り費用を抑えられます。

月次運用まで見積に入れる理由

権限設計は、初回設定で終わりません。社員の異動、退職、外部委託先の追加、SaaSの新機能、AIの利用範囲拡大、RAGの文書追加、APIキーの更新によって、数か月で崩れます。見積前に月次運用を入れるかどうかで、総費用と安全性が変わります。

月次で見るべき指標は次です。

月次運用を初期見積に入れない場合でも、少なくとも運用設計だけは作るべきです。運用設計がない権限設計は、時間が経つほど実態とずれます。

見積依頼前の段階で月次確認者、確認日、差分の承認者だけでも決めておくと、初期設計が運用で崩れにくくなります。

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

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

• 権限設計の見積を取りたいが、ベンダーへ渡す条件を整理できていない
• AI導入、RAG、AIエージェント、SaaS連携が絡み、普通のユーザー権限では足りない
• 既存のSaaSやファイル共有の権限が複雑で、どこから直すべきか分からない
• 見積はあるが、DLP、ログ、RAG権限、AIエージェント操作、サービスアカウントが含まれているか判断できない
• 低予算で始めたいが、削ってはいけない権限設計項目を決めたい
• 本番化条件を、精度や画面ではなく、漏えい防止の観点で作りたい

GXOでは、初回相談で、対象データ、利用者、操作権限、AI参照範囲、サービスアカウント、DLP、ログ、本番化条件を整理し、見積依頼前に必要な1枚資料と費用分解を作る支援ができます。

相談先は 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-07-09に公式ページのHTTP 200を確認しました。この記事は一般的な実務整理であり、個別の法的判断、事故報告要否、契約解釈は、顧問弁護士、個人情報保護委員会の公開情報、関係当局、契約書を確認してください。