経営者向け：データ漏えいを防ぐ権限設計RFPに入れるべき要件・評価軸・契約条件

先に結論：権限設計RFPは「権限を設計してください」では足りません

データ漏えいを防ぐために、AI導入、社内検索、RAG、AIエージェント、SaaS連携、顧客管理、問い合わせ管理、ファイル共有、業務アプリの権限設計を見直したい。見積前の整理は終わり、複数候補会社へ正式に提案依頼を出す。ここでRFPに「ユーザー権限を設計してください」「管理者権限を整理してください」とだけ書く会社は危ないです。

その書き方では、候補会社ごとに前提がばらばらになります。A社はロール設計だけを想定する。B社はID管理連携まで含める。C社はDLPやログを別費用にする。D社はRAGの参照権限を元文書権限に連動させない。E社はAIエージェントの送信、削除、API実行を高リスク操作として分けない。見積金額だけ見れば比較できますが、実際には比較できていません。

権限設計RFPで決めるべき結論は、次の10点です。

1. 対象を、人、外部委託先、管理者、サービスアカウント、APIキー、RAG、AIエージェントに分ける
2. 守るデータを、個人情報、顧客情報、契約情報、営業情報、技術情報、認証情報、経営情報に分ける
3. 操作を、閲覧、作成、編集、削除、承認、エクスポート、外部共有、権限変更、AI参照、API実行に分ける
4. RAGは、文書取り込み、除外文書、元文書権限、引用、回答ログ、再索引までRFPに入れる
5. AIエージェントは、読み取り、下書き、送信、削除、権限変更、外部API実行を別要件にする
6. DLP、ログ、ID管理、監査、例外承認、月次棚卸しを「任意提案」ではなく回答必須にする
7. 候補会社には、成果物、前提、除外範囲、追加費用条件を同じフォーマットで回答させる
8. 評価は金額だけでなく、権限対象、RAG・AI、DLP・ログ、テスト、運用、責任分界を100点で採点する
9. 契約には、成果物の所有権、設定情報の引き渡し、ログの扱い、秘密情報、再委託、事故時協力を入れる
10. 検収条件は、画面が動くことではなく、越権テスト、AI回答テスト、DLP検知、停止訓練で決める

本記事は、データ漏えいを防ぐ権限設計について、複数候補会社へRFPを出す段階の企業向けです。既存ベンダーを変更する引き継ぎ記事ではありません。見積依頼前に範囲と費用を整理する記事でもありません。正式な提案依頼、回答比較、契約、検収まで進める経営者向けに、RFPへ書くべき内容を整理します。

この記事を読むべき会社

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

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

• 権限設計の候補会社を比較したいが、RFPに何を書くべきか分からない
• 見積を数社から取ったが、含まれる範囲が違いすぎて比較できない
• RAGや社内検索AIで、元文書の権限をAI回答に反映できるか確認したい
• AIエージェントがSaaSやAPIを操作するため、送信、削除、権限変更を分けたい
• サービスアカウント、APIキー、外部委託先、退職者権限までRFPに含めたい
• DLP、ログ、ID管理、監査、例外承認が別費用にならないようにしたい
• 契約時に成果物、設定、ログ、テスト結果の引き渡しを明確にしたい
• 検収条件を、動作確認だけでなく、漏えい防止の権限テストで決めたい

既存ベンダーから権限設計を引き継ぐ段階なら、既存ベンダー変更の記事が近いです。まだ候補会社へ正式RFPを出す前で、範囲や費用を整理している段階なら、見積前の記事が近くなります。本記事は、候補会社へ同じ前提で回答させ、採点と契約まで進めるための記事です。

既存記事との違い：この記事は「RFPと提案比較」に絞る

本記事の主語は「候補会社に同じ前提で回答させ、採点し、契約と検収まで進めること」です。RFPは単なる見積依頼書ではありません。後から揉めないための比較基準であり、契約と検収の土台です。

RFPに書くべき目的文

RFP冒頭では、目的を曖昧に書かないことが重要です。「セキュリティ強化」「権限整理」だけでは候補会社の回答が広がりすぎます。次のように、漏えい防止、AI利用、証跡、停止まで目的に入れます。

目的文で「AI」「RAG」「外部共有」「APIキー」「停止」を入れておくと、候補会社は通常のユーザー権限だけでは足りないと理解できます。

RFPの対象範囲

RFPでは、対象範囲を「システム名」だけで書かない方がよいです。権限設計は、システム、データ、利用者、操作、AI、ログが絡みます。対象範囲は次の表で書きます。

この表をRFPに入れると、候補会社がどこまで含めるかを回答できます。逆に、対象範囲が「顧客管理システムの権限設計」とだけ書かれていると、RAG、AIエージェント、DLP、ログ、外部委託先、APIキーが抜けます。

必須要件：権限対象と操作権限

RFPでは、必須要件と任意提案を分けます。必須要件は、候補会社が「対応可、条件付き対応、不可、別費用」を明記すべき項目です。

候補会社の回答では「可能です」だけでは不十分です。成果物名、設定方法、制約、追加費用、検収方法まで回答させます。

必須要件：RAG・社内検索

RAGや社内検索AIを含む場合、RFPで最も抜けやすいのが参照権限です。元のファイル共有やSaaSで見えない文書を、AIが回答してしまうと漏えいになります。RFPでは次を必須要件にします。

RAG要件は、AIの精度とは別に評価します。精度が高くても、権限を超えた回答をするなら本番化できません。

必須要件：AIエージェント操作

AIエージェントがSaaSやAPIを操作する場合、RFPでは高リスク操作を分けます。候補会社には、どこまで初期対応し、どこから後続フェーズにするか回答させます。

AIエージェント要件をRFPに入れないと、候補会社は便利な自動化として提案しがちです。しかし、データ漏えい対策では、便利さよりも操作分離、承認、停止、ログが重要です。

回答フォーマットを指定する

RFPでは、候補会社に自由記述だけで回答させない方がよいです。比較できるよう、次のフォーマットを指定します。

このフォーマットがあると、提案書が読みやすくなります。候補会社の営業資料のうまさではなく、要件ごとの対応力で比較できます。

100点評価軸

提案書は、価格だけでなく100点で採点します。次の採点表をRFPに添付すると、候補会社にも何を重視しているか伝わります。

70点未満は、金額が安くても危険です。80点台は、抜けている項目の追加費用を確認します。95点以上なら、初期費用が高く見えても、後戻り費用を抑えられる可能性があります。

契約に入れるべき条件

権限設計RFPでは、契約条件まで意識しておく必要があります。提案段階で良く見えても、契約に成果物や引き渡しが入っていないと、後で運用できません。

契約条件は、法務だけに任せるものではありません。技術と運用の前提が契約に入っていないと、事故時に「契約範囲外です」となります。法的助言が必要な部分は専門家へ確認しつつ、RFP段階で論点を明示します。

検収条件

検収条件は、納品物があることではなく、漏えい防止のテストに合格することです。RFPに次の検収条件を入れます。

検収テストは候補会社に作らせるだけではなく、社内のデータオーナーが確認します。ベンダーが知らない顧客別事情、契約別事情、部門別事情があるからです。

RFPスケジュール

権限設計RFPは、短すぎると候補会社の回答が浅くなります。現実的には次の流れです。

急ぐ場合でも、質問回答と採点は省略しない方がよいです。権限設計は、候補会社の提案力よりも、前提の合意が重要です。

RFP本文テンプレート

RFP本文は、候補会社が読み替えできない粒度で書きます。長く書けばよいわけではありませんが、要件ID、回答形式、検収条件、除外範囲をそろえる必要があります。次のテンプレートを土台にすると、権限設計RFPの抜け漏れを減らせます。

RFP本文では、候補会社に「提案してください」と任せすぎないことが重要です。提案の自由度は任意提案で残し、必須要件では回答形式を固定します。これにより、提案の個性は見ながら、最低限の比較軸は揃えられます。

失格条件を先に書く

権限設計RFPでは、採点以前に失格にすべき条件があります。失格条件を書かないと、金額が安い提案や見栄えの良い提案に引っ張られ、あとで安全要件が抜けます。

失格条件は厳しく見えますが、RFPの目的は安い会社を探すことではありません。データ漏えいを防ぐ権限設計を任せられる会社を選ぶことです。失格条件を先に書くことで、候補会社も提案前に自社の対応範囲を判断できます。

提案書レビューで見るべき赤信号

提案書がきれいでも、中身が弱いことがあります。特に権限設計では、セキュリティ用語が並んでいても、実際の成果物、設定、テストが薄い提案があります。提案書レビューでは、次の赤信号を確認します。

提案書レビューでは、候補会社を責めるのではなく、契約前に曖昧さを潰す姿勢が重要です。質問に具体的に答えられる会社は、導入後の運用も現実的に進めやすいです。

候補会社への追加質問例

RFP回答後は、追加質問を必ず行います。提案書だけでは、制約、例外、追加費用、担当体制が見えにくいからです。

追加質問への回答が曖昧な場合は、採点を下げます。逆に、制約を正直に説明し、代替案を出せる会社は評価できます。RFPでは「何でもできます」と言う会社より、「ここは製品制約があり、ここは運用で補う」と説明できる会社の方が実務では強いです。

契約前レビューのチェックリスト

候補会社を選んだ後、契約前にもう一度RFPと提案書を契約書へ落とし込みます。RFPに書いてあっても、契約や注文書に入っていなければ、後から範囲外と言われることがあります。

契約前レビューは、法務だけでなく、情シス、セキュリティ、現場責任者、経営が一緒に確認します。法務は条項を見られますが、権限台帳やRAG権限テストの実務的な必要性は現場側が説明する必要があります。

検収シナリオ例

検収テストは、単発のチェックリストではなく、実際の業務シナリオに近づけます。候補会社へRFP段階でシナリオ例を渡しておくと、実装後の認識違いを減らせます。

検収シナリオは、会社ごとに変える必要があります。重要なのは、画面が動くかどうかではなく、漏えいにつながる操作が止まるか、止まらない場合にログで追えるかです。

RFP後の90日計画

RFPで候補会社を選んだ後も、すぐに全社展開しない方がよい場合があります。権限設計は、データオーナーの承認、SaaS制約、既存運用、現場例外が絡むため、90日で段階的に進めます。

RFP段階で90日計画を求めると、候補会社の実務力が見えます。提案書だけなら立派でも、90日計画が曖昧な会社は、導入後に社内調整で止まりやすいです。

見積内訳で必ず分ける項目

RFP回答の費用は、一式ではなく内訳で出してもらいます。権限設計は、調査、設計、実装、テスト、運用で必要な人が違います。内訳がないと、安い提案が本当に安いのか、単に重要項目が抜けているだけなのか判断できません。

RFPでは、候補会社に「初期費用」「月額費用」「任意追加費用」「前提ライセンス費」を分けて回答させます。特にDLP、ログ、RAG、AIエージェント、サービスアカウントは、製品ライセンスやSaaSプランの制約を受けます。見積内訳を分けないまま発注すると、契約後に「その機能は上位プランが必要です」「そのログは標準では取れません」となります。

発注後に揉めやすい論点

RFPで曖昧にすると、発注後に揉める論点があります。契約前に候補会社へ確認し、議事録や契約別紙に残しておきます。

権限設計のRFPでは、技術要件だけでなく、揉めやすい論点を先に出すことが品質です。候補会社がこれらの論点を嫌がる場合、導入後の運用でも同じ論点が残ります。

経営会議での最終判断

最後に、経営会議では採点表と費用だけを出すのではなく、「どのリスクを初期で潰し、どのリスクを後続フェーズに送るか」を説明します。

この説明ができると、権限設計RFPは単なるIT発注ではなく、経営としてのリスク管理になります。安い会社を選んだのか、高い会社を選んだのかではなく、どの条件で本番化するかを合意できます。

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

次のどれかに当てはまるなら、RFPを自社だけで作らず、RFP作成か提案書レビューから相談した方がよいです。

• 権限設計RFPを出したいが、要件IDや回答フォーマットを作れない
• 見積が複数あるが、RAG、AIエージェント、DLP、ログの範囲がそろっていない
• 候補会社の提案が良く見えるが、契約と検収に落とせるか判断できない
• AI回答やAIエージェント操作によるデータ漏えいをRFPにどう書くか分からない
• サービスアカウント、APIキー、外部委託先、退職者権限まで比較したい
• 安い提案を選んだ後の追加費用や責任分界が不安

GXOでは、RFP本文、候補会社回答フォーマット、100点採点表、契約論点リスト、検収条件表を作り、候補会社比較と提案書レビューを支援できます。

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