先に結論:RFPには「社員利用を管理してください」ではなく「漏えいを防ぐ運用成果物」を書く
情報漏えいの従業員利用管理を外部支援会社へ正式にRFPで依頼する段階で、「社員のAI・SaaS・クラウド利用を管理してください」とだけ書くと、提案は比較できません。ある候補会社は社内ルール本文と社員向け注意事項だけを提案します。別の候補会社は、AI・SaaS・クラウド利用台帳、許可・禁止・申請制区分、入力禁止情報の業務別判断表、外部共有チェック、社員教育、管理職FAQ、例外承認フロー、違反・ヒヤリハット記録、個人情報漏えいが疑われる時の初動、月次レビューまで提案します。どちらも「従業員利用管理」と呼べるため、総額だけでは判断できません。
RFPで明確にするべきなのは、お願いしたい雰囲気ではなく、候補会社が同じ前提で回答できる成果物、評価軸、責任分界、検収条件、契約条件です。
経営者がRFPに入れるべき結論は、次の10点です。
- 情報漏えいの従業員利用管理で達成したい目的を明記する
- 対象社員、対象部門、対象AI・SaaS・クラウド、対象データ、対象委託先を明記する
- 利用台帳、許可区分、入力禁止情報、外部共有、教育FAQ、例外承認、月次運用を成果物として分ける
- 候補会社に、診断方法、設計方法、教育方法、運用支援方法を同じフォーマットで回答させる
- 提案書の見た目ではなく、現場運用、リスク判断、初動設計、更新継続性で採点する
- 経営、情シス、管理部門、法務、現場、外部専門家、支援会社の責任分界を契約前に決める
- 個人情報漏えい懸念時の報告、証拠保全、影響範囲確認、専門家連携を運用要件に入れる
- 成果物権利、再利用、改変、次ベンダー共有、編集可能形式を契約条件に入れる
- 検収条件を「資料納品」ではなく、台帳、FAQ、教育、例外承認、月次レビューが使える状態にする
- 初期90日と月次運用を分け、追加費用条件をRFP段階で回答させる
この10点がRFPに入っていないと、候補会社は自社に都合のよい範囲で提案します。安い提案は社内ルール本文だけ、高い提案は運用まで含む。どちらが妥当かを判断できず、契約後に「利用台帳は別費用」「社員教育は別契約」「外部共有チェックは対象外」「月次レビューは保守契約が必要」「成果物の改変は不可」といった問題が出ます。
本記事は、情報漏えいの「従業員利用管理」をRFPに落とすための記事です。見積前に範囲を整理する段階ではありません。既存ベンダーから運用を引き継ぐ記事でもありません。複数候補会社へ正式に提案依頼を出し、回答書、採点表、契約条件、検収条件を揃える段階を対象にします。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
この記事を読むべき会社
この記事は、情報漏えい対策の社内ルール、生成AI利用ルール、AI利用規程、情報セキュリティ規程、個人情報取扱ルール、外部委託管理ルールに基づく従業員利用管理について、複数候補会社へ正式にRFPを出したい中小・中堅企業の経営者、DX責任者、情シス責任者、管理部門、法務向けです。
特に、次の状態なら本記事の検索意図に合います。
- 情報漏えいの従業員利用管理を外部支援会社へ正式に提案依頼したい
- 生成AI、AI機能付きSaaS、クラウド共有、外部委託先共有をRFP要件に入れたい
- 利用台帳、許可区分、入力禁止情報、外部共有チェックを成果物として指定したい
- 社員教育、管理職FAQ、理解度確認、受講履歴まで候補会社に提案させたい
- 例外承認、違反、ヒヤリハット、個人情報漏えい懸念時の初動、月次レビューを運用設計に含めたい
- 候補会社の提案書を、金額や見た目ではなく実務力で比較したい
- 経営、情シス、法務、管理部門、現場、支援会社の責任分界を契約前に決めたい
- 成果物の権利、再利用、改変、次ベンダー共有を契約条件に入れたい
- 契約後に「それは別費用です」が出ないよう、検収条件までRFPに書きたい
逆に、まだ社内で範囲や予算を決めていない段階なら、見積前整理の記事が近いです。すでに既存ベンダーと運用中で、別ベンダーへ移す段階なら、既存ベンダー変更の記事が近いです。本記事は、候補会社に同じ条件で回答させ、提案比較と契約条件を固めるための記事です。
この記事の商談設計
この記事で作りたい相談は、情報漏えいの従業員利用管理RFP作成、候補会社質問票、回答フォーマット、100点採点表、提案書レビュー、契約条件レビュー、検収条件整理、AI・SaaS・クラウド利用台帳、入力禁止情報判断表、外部共有チェック、教育FAQ、例外承認、個人情報漏えい初動、月次運用の実装伴走です。
売上への接続は、RFP作成支援から、候補会社比較、提案書レビュー、契約前レビュー、要件定義、利用台帳整備、情報漏えい社内ルール作成・改定、生成AI・SaaS利用ルール整備、社員教育、初動訓練、月次運用支援へ段階受注することです。
利益への接続は、RFP本文、候補会社回答フォーマット、100点採点表、契約論点リスト、検収条件表、利用台帳テンプレート、入力禁止情報判断表、外部共有チェック表、例外承認台帳を標準化し、毎回ゼロから比較・レビューしない高粗利の伴走支援へ接続することです。
主要CTAは AI活用・AI社内ルールの相談 です。
FREE DOWNLOAD
AI導入チェックリスト(PoC 失敗要因 10項目)
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
既存記事との違い:この記事は「RFPで候補会社を比較できる状態」に絞る
同じ情報漏えい領域でも、記事の役割を分けないとカニバリが起きます。本記事は、情報漏えいの従業員利用管理を候補会社へ正式提案依頼するRFP段階だけを扱います。
| 記事テーマ | 主な読者の悩み | 本記事との違い |
|---|---|---|
| 情報漏えいの従業員利用管理の見積前記事 | 見積依頼前に、要件・費用・運用範囲を整理したい | 本記事は範囲整理後に、複数候補会社へ正式RFPを出す段階 |
| 情報漏えいの従業員利用管理の既存ベンダー変更記事 | 作成済み・運用中の資料を別ベンダーへ移管したい | 本記事は移管資料ではなく、RFP本文、回答、採点、契約条件を扱う |
| 情報漏えい社内ルール作成RFP | 社内ルール本文、情報分類、個人情報漏えい初動をRFPに入れたい | 本記事は社内ルール本文ではなく、社員のAI・SaaS・クラウド利用管理に限定 |
| ChatGPT情報漏えい対策 | 生成AI入力や外部送信リスクを理解したい | 本記事は生成AIだけでなく、SaaS、クラウド共有、委託先共有、教育、例外承認までRFP化する |
本記事の主語は「情報漏えいを防ぐための従業員利用管理を、候補会社にどう提案させ、どう選ぶか」です。社員に配る注意事項の作り方だけではありません。候補会社がどの範囲を初期契約に含め、どの範囲を月次運用に分け、どの責任を自社、法務、情シス、外部専門家、支援会社で分けるかを比較するための記事です。
RFPの冒頭に入れる目的文
RFPの冒頭には、次のような目的文を入れてください。
当社は、生成AI、AI機能付きSaaS、クラウド共有、外部委託、リモートワークの利用拡大に伴い、個人情報、顧客情報、営業情報、技術情報、ソースコード、認証情報等の情報漏えいリスクを低減する従業員利用管理を整備したい。単なる注意事項や規程本文の作成ではなく、AI・SaaS・クラウド利用台帳、許可・禁止・申請制区分、入力禁止情報判断表、外部共有チェック、個人情報漏えい懸念時の初動フロー、社員教育、FAQ、例外承認、ヒヤリハット、月次レビューを含め、社員が日常業務で判断でき、事故時に経営・法務・情シスが動ける運用体制を構築することを目的とする。
この目的文があると、候補会社は「一般的な社内ルールを作ればよい」と解釈しにくくなります。情報漏えい対策は、禁止事項の列挙では足りません。営業が商談メモをAIで要約する、開発者がソースコードやログをAIへ入れる、人事が履歴書を要約する、CSが問い合わせ履歴をFAQ化する、管理部門が契約書を外部SaaSでレビューする、委託先が社内資料を外部クラウドにアップロードする。こうした現場の判断をRFPで対象にしなければ、納品後に使えない運用になります。
RFP冒頭では、特に次の5つを目的として明記してください。
| 目的 | RFPでの書き方 |
|---|---|
| 経営リスク低減 | 個人情報、顧客情報、機密情報、技術情報、認証情報の漏えい防止を目的にする |
| 現場判断の統一 | 社員がAI、SaaS、クラウド共有、委託先共有で迷わない判断表を作る |
| 事故時初動 | 漏えい疑い発見時の報告、証拠保全、経営報告、外部連絡判断を整える |
| 顧客説明 | 取引先からのセキュリティ質問票やAI利用確認に回答できる状態を作る |
| 継続改善 | 例外承認、ヒヤリハット、月次レビューで台帳・FAQ・ルールを更新する |
目的が曖昧なRFPでは、候補会社の提案がばらつきます。ある会社は法務文書を厚くし、別の会社は技術対策を厚くし、別の会社は研修を厚くします。どれも必要になり得ますが、経営者が求める優先順位と合っていなければ失敗します。
RFPに入れるべき50要件
情報漏えいの従業員利用管理RFPには、最低限、次の50要件を入れてください。すべてを初期契約に含める必要はありません。ただし、含めるか、対象外にするか、後続フェーズにするかをRFP上で明記する必要があります。
| 要件 | RFPに書く内容 | 候補会社に回答させること |
|---|---|---|
| 対象目的 | 漏えい防止、事故時初動、顧客説明、社員教育、継続改善 | 優先順位と設計方針 |
| 対象情報 | 個人情報、顧客情報、営業情報、技術情報、ソースコード、認証情報 | 分類方法と判断基準 |
| 対象部署 | 営業、開発、CS、人事、経理、管理、法務、経営 | 部門別ヒアリング方法 |
| 対象者 | 正社員、役員、業務委託、派遣、外部パートナー、委託先 | 対象者別のルール範囲 |
| 対象業務 | 商談、提案、開発、採用、顧客対応、請求、広報、経営会議 | 業務別の漏えいシナリオ |
| 対象AI | 生成AI、AIチャット、議事録AI、翻訳AI、コード生成AI、画像生成AI | AI利用棚卸し方法 |
| 対象SaaS | CRM、グループウェア、ストレージ、会計、人事、開発ツール | SaaS管理者と権限確認 |
| 個人契約AI | 個人アカウント、無料版、試用版、部門契約 | Shadow AIの扱い |
| クラウド共有 | 共有リンク、外部共有、期限、閲覧権限、ダウンロード | 共有ルールの作り方 |
| 委託先共有 | 外部パートナー、再委託、士業、BPO、開発会社 | 共有可否と削除確認 |
| 利用台帳 | AI・SaaS・クラウド、部門、用途、契約、管理者、見直し日 | 台帳項目と更新方法 |
| 許可区分 | 許可、条件付き許可、申請制、禁止、検証中 | 判断根拠の作り方 |
| 入力禁止情報 | 顧客名、個人情報、契約書、ソースコード、ログ、APIキー | 業務別判断表 |
| 外部共有チェック | 共有先、権限、期限、再共有、委託先利用 | チェック表と責任者 |
| 生成物利用 | 社内参考、顧客提出、外部公開、コード反映、契約判断 | 人による確認手順 |
| 持ち出し | 私物端末、USB、個人メール、私用クラウド、スクリーンショット | 禁止・例外条件 |
| アクセス権 | 権限付与、退職者削除、異動時変更、共有フォルダ棚卸し | 権限レビュー手順 |
| ログ | SaaSログ、AI利用ログ、ファイル共有ログ、管理者操作ログ | 確認対象と限界 |
| 事故初動 | 発見、報告、証拠保全、初動会議、外部連絡判断 | フローと責任者 |
| 個人情報漏えい | 報告要否、本人通知、委託先連携、再発防止 | 判断プロセスと外部専門家連携 |
| 顧客情報漏えい | 取引先報告、契約上の通知、営業対応、再発防止 | 顧客説明テンプレート |
| 技術情報漏えい | ソースコード、APIキー、設計書、ログ、脆弱性情報 | 開発・情シス連携 |
| 営業情報漏えい | 提案書、価格表、商談メモ、CRM情報 | 営業部門向けルール |
| 人事情報漏えい | 履歴書、評価、面談メモ、給与、採用AI | 人事部門向けルール |
| 経理情報漏えい | 請求、振込、会計SaaS、士業共有 | 権限と委託先管理 |
| 教育 | 全社員教育、管理職教育、部門別教育 | 教材構成と実施方法 |
| FAQ | AI入力、SaaS共有、委託先、事故時、顧客説明 | FAQ作成方法 |
| 理解度確認 | テスト、受講履歴、未受講者管理 | 証跡の残し方 |
| 例外承認 | 申請、承認、期限、条件、見直し日 | 例外承認台帳 |
| ヒヤリハット | 事故未満の不安事例、現場質問、迷った判断 | 記録と月次反映 |
| 違反対応 | 禁止AI利用、無断共有、誤送信、未承認外部提出 | 初動、記録、再教育 |
| 月次レビュー | 台帳更新、例外承認、FAQ改定、事故未満事例 | 会議体とアジェンダ |
| 年次改定 | 規程改定、ツール変更、組織変更、委託先変更 | 改定サイクル |
| 関連規程 | 個人情報、情報セキュリティ、就業規則、委託契約 | 整合確認範囲 |
| 法務確認 | 社内法務、顧問弁護士、個人情報保護専門家 | 法的助言との線引き |
| 情シス設定 | SSO、DLP、MFA、共有制限、ログ取得 | 文書作成との対象分離 |
| セキュリティ診断 | 脆弱性診断、設定監査、権限棚卸し | 初期範囲か後続か |
| 成果物形式 | Word、Excel、Google Sheet、Notion、PDF | 編集可能形式 |
| 成果物権利 | 改変、再利用、社内配布、次ベンダー共有 | 契約条項案 |
| 会議回数 | 経営、情シス、法務、現場、レビュー、説明会 | 回数・時間・参加者 |
| 修正回数 | 初稿、法務確認後、経営会議後、現場説明後 | 修正範囲と追加費用 |
| 納期 | 30日、60日、90日、段階導入 | スケジュール案 |
| 体制 | PM、規程担当、セキュリティ担当、教育担当、レビュー担当 | 担当者と責任 |
| RACI | 経営、情シス、法務、管理部門、現場、支援会社 | 責任分界 |
| 費用内訳 | 診断、設計、文書作成、教育、運用、月額支援 | 明細と前提条件 |
| 追加費用 | 部門追加、説明会追加、法務再確認、資料不足 | 単価と発生条件 |
| 対象外 | 法律意見、監査保証、技術実装、全契約改定 | 対象外の明記 |
| 秘密保持 | 共有資料、ヒヤリハット、事故情報、顧客情報 | 管理方法 |
| 再委託 | 再委託先、アクセス範囲、秘密保持、削除 | 再委託の可否 |
| 資料保管削除 | 契約中の保管、終了後の削除、返却、ログ | 証跡の出し方 |
この50要件をRFPに入れると、候補会社の差が見えます。強い会社は、どこまで初期契約に入れるか、どこを後続フェーズにするか、どこを自社側で担うべきかを具体的に説明できます。弱い会社は、一般的な規程文書、抽象的な研修、セキュリティ用語の羅列に寄り、社員が日常業務で判断するための成果物が出てきません。
候補会社への回答フォーマット
RFPでは、自由形式の提案書だけを出させないでください。候補会社は自社の得意分野を強調します。法務系は条文、セキュリティ系は技術、研修系は教育、開発系はツール導入に寄ります。比較するには、同じ項目に同じ粒度で回答させる必要があります。
| 回答項目 | 候補会社に書かせる内容 |
|---|---|
| 対応範囲 | 初期契約に含む範囲、含まない範囲、後続提案範囲 |
| 現状診断方法 | 確認資料、ヒアリング対象、棚卸し方法、診断成果物 |
| 利用台帳設計 | AI・SaaS・クラウドの台帳項目、管理者、更新頻度、見直し方法 |
| 許可区分設計 | 許可、条件付き許可、申請制、禁止、検証中の判断根拠 |
| 入力禁止情報判断表 | 業務別に何を入力禁止・要注意・許可にするか |
| 外部共有ルール | 共有リンク、社外招待、委託先共有、再共有の扱い |
| 個人情報漏えい初動 | 発見、報告、証拠保全、初動会議、外部連絡判断の設計 |
| 教育FAQ | 全社員、管理職、部門別FAQ、理解度確認の範囲 |
| 例外承認 | 申請、承認、期限、条件、見直し、月次反映 |
| 月次運用 | 会議体、アジェンダ、台帳更新、FAQ改定、報告書 |
| 体制 | PM、規程担当、セキュリティ担当、教育担当、レビュー担当 |
| スケジュール | 30日、60日、90日の成果物と意思決定ポイント |
| 費用内訳 | 診断、設計、文書作成、教育、月次運用、追加費用 |
| 契約条件 | 成果物権利、改変、社内配布、次ベンダー共有、再委託 |
| 検収条件 | 何をもって完了とするか |
| 前提・リスク | 社内資料不足、法務確認、SaaS設定、部門追加の扱い |
回答フォーマットを揃えるだけで、提案比較の質は上がります。候補会社が「当社は豊富な実績があります」と書いても、利用台帳、入力禁止情報判断表、外部共有チェック、事故初動フロー、例外承認台帳、月次レビュー表をどう作るのか答えられなければ、運用設計力は弱いと判断できます。
100点満点の採点表
情報漏えいの従業員利用管理RFPでは、提案書の見た目や総額だけで選ばないでください。次の100点満点の採点表を使うと、候補会社の比較が明確になります。
| 評価項目 | 配点 | 見るポイント |
|---|---|---|
| 目的理解 | 10 | 文書作成ではなく、漏えい防止、事故時初動、現場判断を目的にしているか |
| 現状診断力 | 10 | 情報資産、AI・SaaS、クラウド共有、委託先、既存規程、事故履歴を調査できるか |
| 利用台帳・許可区分 | 15 | AI・SaaS・クラウド利用台帳と許可・禁止・申請制区分を運用できるか |
| 入力禁止情報・外部共有 | 15 | 個人情報、顧客情報、技術情報、AI入力、クラウド共有を業務別に落とせるか |
| 個人情報漏えい初動 | 10 | 発見、報告、証拠保全、外部連絡判断、再発防止を設計できるか |
| 教育・FAQ・定着 | 10 | 全社員、管理職、部門別FAQ、理解度確認まで見ているか |
| 例外承認・月次運用 | 10 | 例外、ヒヤリハット、違反、月次レビューを運用に入れているか |
| 体制・実行力 | 10 | PM、規程、セキュリティ、教育、レビュー体制が明確か |
| 契約・権利条件 | 5 | 成果物権利、編集可能形式、次ベンダー共有、検収条件が明確か |
| 費用妥当性 | 5 | 総額ではなく、範囲と内訳に対して妥当か |
合格ラインは80点では甘いです。情報漏えいの従業員利用管理は、会社の信用、取引先説明、社員行動、事故時対応に関わります。90点未満は最終候補から外し、95点以上を契約候補にするくらいでよいです。
点数だけでなく、赤信号も見てください。次に当てはまる候補会社は、総額が安くても慎重に扱うべきです。
- 社員利用管理の話ではなく、規程本文や一般的なセキュリティ研修の話に寄っている
- AI・SaaS・クラウド共有・委託先共有の違いを分けていない
- 個人情報漏えい時の初動を「法務確認」とだけ書き、社内フローがない
- 教育を「説明会1回」で終わらせ、FAQや理解度確認がない
- 例外承認やヒヤリハットを月次改善に入れていない
- 成果物権利、編集可能形式、次ベンダー共有が曖昧
- 検収条件が「資料一式納品」だけ
- 追加費用条件が曖昧
RFPに入れるべき契約条件
契約条件をRFPに入れないと、提案段階ではよく見えても、契約後に運用資産として使えないことがあります。特に成果物権利、編集可能形式、次ベンダー共有、資料削除、再委託、検収条件は必ず明記してください。
| 契約条件 | RFPに入れる理由 |
|---|---|
| 成果物の改変可否 | 利用台帳、FAQ、例外承認台帳、初動フローは継続改定が必要 |
| 社内配布可否 | 全社員教育、社内ポータル掲載、管理職説明に必要 |
| 次ベンダー共有可否 | 将来の支援会社変更、監査対応、内製化で必要 |
| 編集可能形式 | PDFだけでは台帳やFAQを更新できない |
| 再委託の有無 | 顧客情報、社員情報、ヒヤリハットを扱うため管理が必要 |
| 秘密保持 | AI・SaaS利用実態、顧客情報、事故懸念を共有するため |
| 資料保管・削除 | 契約終了後の情報管理が必要 |
| 法的助言の範囲 | 支援会社の運用設計と弁護士判断を分ける |
| セキュリティ監査の範囲 | 文書作成、運用設計、技術監査を混同しない |
| 追加費用条件 | 部門追加、説明会追加、法務再確認、資料不足の扱いを明確にする |
| 検収条件 | 納品物名ではなく、使える状態を確認する |
| 契約終了時引き継ぎ | 台帳、FAQ、更新履歴、未決事項を残す |
RFPには、候補会社に契約条件への同意可否を回答させてください。「契約時に協議」とだけ書かれている場合は、後で揉める可能性があります。特に成果物権利と次ベンダー共有は、支援会社によって考え方が違います。
検収条件は「納品物がある」ではなく「使える状態」で見る
情報漏えいの従業員利用管理で、検収条件を「従業員利用管理資料一式の納品」と書くのは危険です。資料が納品されても、社員が使える状態になっていなければ従業員利用管理は完成していません。
検収条件は次のように書いてください。
| 成果物 | 検収条件 |
|---|---|
| 利用台帳 | 主要AI・SaaS・クラウド、部門、用途、契約形態、管理者、許可区分、見直し日が入っている |
| 許可区分表 | 許可、条件付き許可、申請制、禁止、検証中の判断根拠がある |
| 入力禁止情報表 | 業務別に入力不可・要注意情報が示されている |
| 外部共有チェック表 | 共有先、権限、期限、再共有、委託先利用の確認項目がある |
| 社員教育資料 | 全社員向けと管理職向けの説明が分かれている |
| FAQ | 現場質問に基づく実務例が含まれている |
| 理解度確認 | 受講履歴または確認フォームの運用方法がある |
| 例外承認台帳 | 申請者、用途、条件、期限、承認者、見直し日が入る |
| 事故時初動表 | 誤入力、漏えい懸念、誤共有、顧客指摘時の連絡先と初動がある |
| 月次レビュー表 | 台帳更新、FAQ改定、例外承認、ヒヤリハットを確認できる |
| 成果物権利一覧 | 改変、社内利用、次ベンダー共有の可否が明記されている |
検収条件が明確だと、候補会社も「何を作れば完了か」を理解できます。発注側も、納品後に「思っていたものと違う」と言いにくくなります。
個人情報漏えい初動はRFPで線引きする
個人情報保護委員会は、個人情報の漏えい等が発生した場合の対応について情報を公開しています。報告要否や本人通知の要否は個別事情で変わります。RFPで重要なのは、候補会社に法律判断を丸投げすることではありません。社員が誤入力、誤送信、誤共有、外部AIへの入力、委託先への過剰共有に気づいた時、社内でどこへ報告し、誰が初動を切り分け、どの段階で法務や外部専門家へつなぐかを決めることです。
RFPには、次の初動要件を入れてください。
| 初動項目 | RFPに書く内容 |
|---|---|
| 発見者の報告 | 何を、いつ、どこへ、どの様式で報告するか |
| 一次受付 | 情シス、管理部門、法務、経営の誰が受けるか |
| 証拠保全 | メール、ログ、共有リンク、AI入力履歴、SaaS操作履歴を消さない手順 |
| 影響範囲確認 | 対象情報、対象人数、対象顧客、委託先、外部サービスを把握する方法 |
| 外部連絡判断 | PPC、本人、取引先、委託先への連絡判断を誰が行うか |
| 社員への再周知 | 同じ事故を防ぐ教育やFAQに戻す方法 |
| ルール改定 | 禁止事項、例外承認、FAQ、台帳へ反映する方法 |
候補会社には、法的助言が必要な論点と、運用設計で整理できる論点を分けて回答させてください。「個人情報漏えい対応も可能です」とだけ書かれている提案は危険です。必要なのは、発見、受付、証拠保全、影響範囲確認、専門家連携、再発防止をつなぐ社内運用です。
RFPで候補会社に聞くべき質問
RFP本文とは別に、候補会社への質問票を付けてください。質問票は、提案書の弱点を見抜くために使います。
| 質問 | 見るポイント |
|---|---|
| 従業員利用管理と社内ルール本文の成果物をどう分けますか | 文書作成だけで終わらないか |
| AI・SaaS・クラウド利用台帳はどの項目で作りますか | 実利用、契約形態、管理者、見直し日まであるか |
| 許可・禁止・申請制の判断根拠をどう作りますか | 一般論ではなく自社業務に合わせるか |
| 入力禁止情報を業務別にどう整理しますか | 営業、開発、人事、管理などの違いを見られるか |
| クラウド共有や委託先共有をどう確認しますか | AI入力だけでなく外部共有まで扱えるか |
| 社員教育とFAQをどう作りますか | 現場質問やNG例が入るか |
| 例外承認とヒヤリハットをどう月次改善に戻しますか | 作って終わりにならないか |
| 法務確認や顧問弁護士との役割分担をどう考えますか | 法的助言を過剰に引き受けないか |
| 情シス設定やログ確認はどこまで対象ですか | 文書と技術設定の境界が明確か |
| 成果物は編集可能形式で納品されますか | 運用資産として使えるか |
| 契約終了時に何を引き継げますか | 次ベンダー共有や社内更新に耐えるか |
良い候補会社は、できる範囲とできない範囲を明確に分けます。弱い候補会社は、すべて「対応可能」と言いながら、成果物、担当者、検収条件が曖昧です。
RFPに入れるべきスケジュール
情報漏えいの従業員利用管理RFPでは、30日、60日、90日の段階計画を候補会社に出させてください。
| 期間 | 発注側が求めること | 候補会社に回答させること |
|---|---|---|
| 0-30日 | 現状診断、資料確認、部門ヒアリング、AI・SaaS・クラウド利用実態棚卸し | 診断方法、ヒアリング対象、初期課題の出し方 |
| 31-60日 | 利用台帳、許可区分、入力禁止情報、外部共有チェック、申請・例外承認フロー | 成果物サンプル、レビュー方法、修正回数 |
| 61-90日 | 社員教育、管理職説明、理解度確認、例外承認台帳、月次レビュー開始 | 周知方法、検収条件、初回月次レビュー |
| 91日以降 | 月次更新、問い合わせ対応、FAQ改定、台帳更新 | 月額支援範囲、追加費用条件、報告形式 |
このスケジュールを入れると、候補会社が初期納品だけを考えているのか、運用定着まで見ているのかが分かります。情報漏えいの従業員利用管理は、社員がAI・SaaS・クラウドを使い続ける限り更新が必要です。初回納品後の月次運用をRFP段階で確認してください。
RFP本文にそのまま入れられる要件サンプル
RFPを書く時は、抽象的な要望ではなく、候補会社が回答しやすい文章にしてください。たとえば、次の文面をそのままRFPに入れられます。
利用台帳
候補会社は、当社のAI・SaaS・クラウド利用実態を確認し、利用台帳の初版を作成すること。台帳には、サービス名、利用部門、利用目的、入力・共有情報、外部共有先、契約形態、管理者、承認状態、教育要否、次回見直し日を含めること。候補会社は、台帳項目、更新頻度、管理責任者、月次レビュー方法を提案書に記載すること。
入力禁止情報
候補会社は、営業、開発、管理、人事、法務、広報、CSなどの業務別に、AI・SaaS・クラウドへ入力または共有してはならない情報、条件付きで扱える情報、社内レビューが必要な情報を整理すること。判断表には、顧客情報、個人情報、契約書、営業資料、ソースコード、エラーログ、採用情報、問い合わせ履歴を含めること。
外部共有
候補会社は、クラウドストレージ、チャット、CRM、プロジェクト管理、議事録AI、委託先SaaSにおける外部共有の確認項目を作成すること。共有リンク、社外ゲスト、期限、権限、再共有、委託先利用、退職者・異動者対応を含め、初期確認と月次レビューの方法を提案すること。
教育・FAQ
候補会社は、全社員向け説明資料、管理職向け判断例、部門別FAQ、NG例、理解度確認、受講履歴管理の成果物と実施方法を提案すること。FAQは一般論ではなく、営業、開発、人事、CS、管理部門の実務質問を想定して作成すること。
例外承認・ヒヤリハット
候補会社は、例外申請フォーム、承認フロー、例外承認台帳、期限管理、ヒヤリハット記録表、月次レビューへの反映方法を提案すること。例外承認は口頭判断で終わらせず、申請者、用途、条件、期限、承認者、見直し日を記録できる形式にすること。
個人情報漏えい初動
候補会社は、個人情報漏えいが疑われる場合の社内初動フローを提案すること。発見者の報告、一次受付、証拠保全、影響範囲確認、法務・外部専門家連携、外部連絡判断、社員への再周知、ルール改定への反映を含めること。ただし、報告要否や本人通知要否などの法的判断は、社内法務または外部専門家との役割分担を明記すること。
失敗するRFPの共通点
情報漏えいの従業員利用管理RFPで失敗する会社には、共通点があります。
| 失敗パターン | 起きること |
|---|---|
| 「一式」とだけ書く | 候補会社ごとに範囲が変わり、比較不能になる |
| AI入力だけを見る | クラウド共有、SaaS、委託先経由の漏えいが残る |
| 教育を軽視する | ルールが社員に届かず、問い合わせが属人化する |
| 例外承認を入れない | 事業上必要な利用が口頭判断になる |
| 初動フローを入れない | 誤入力、誤共有、顧客指摘時に動けない |
| 成果物権利を入れない | 台帳やFAQを自社で更新できない |
| 検収条件が曖昧 | 納品後に「使えない資料」が残る |
| 月次運用を聞かない | 作って終わりになる |
RFPは候補会社を縛るためだけの書類ではありません。発注側が何を求め、何を自社で持ち、何を外部支援に任せるかを決めるための設計書です。
GXOに相談すべきタイミング
次のどれかに当てはまるなら、記事を読むだけで止めず、RFP作成か提案書レビューから相談した方がよいです。
- 情報漏えいの従業員利用管理を複数候補会社へRFPで依頼したい
- 候補会社の提案を、金額ではなく実務力で比較したい
- AI・SaaS・クラウド共有・委託先共有までRFPに入れたい
- 個人情報漏えい懸念時の初動を、社員利用管理とつなげたい
- 成果物権利、編集可能形式、次ベンダー共有、検収条件まで契約前に固めたい
- 文書作成だけでなく、SaaS、AI、権限、ログ、運用改善まで見てほしい
GXOでは、情報漏えいの従業員利用管理について、RFP本文、候補会社質問票、回答フォーマット、100点採点表、契約条件レビュー、検収条件整理、提案書比較まで一体で支援できます。
まずは AI活用・AI社内ルールの相談 から、現在のAI・SaaS・クラウド利用状況、既存ルール、候補会社へ出そうとしているRFP案を共有してください。
関連記事
- 情報漏えいの従業員利用管理を見積依頼する前に整理する要件・費用・運用条件
- 情報漏えいの従業員利用管理で既存ベンダーを変更する前に見る引き継ぎ条件
- 情報漏えい社内ルール作成RFPに入れるべき要件・評価軸・契約条件
- ChatGPTの社内情報漏えいを防ぐ3層ガイド
- Shadow 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/
- NISC: https://www.nisc.go.jp/





