先に結論：RFPには「規程を作る」ではなく「漏えいを防ぎ、事故時に動ける状態」を書く
情報漏えい社内ルール作成を候補会社へ正式にRFPで依頼する時、「情報漏えい対策の社内ルールを作成してください」とだけ書くと、提案は比較できません。ある候補会社は規程本文と禁止事項を作ります。別の候補会社は情報分類、生成AI入力禁止情報、委託先共有、個人情報漏えい時の初動フロー、社員教育、FAQ、例外承認台帳、月次レビューまで提案します。どちらも「社内ルール作成」と呼べるため、安い提案が本当に安いのか、高い提案が過剰なのかを判断できなくなります。
RFPで明確にするべきなのは、文書名ではありません。会社として、どの情報を守り、どの業務で判断させ、どの事故時に誰が動き、どの成果物を検収し、契約後にどう更新するかです。
経営者がRFPに入れるべき結論は、次の10点です。
- 情報漏えい社内ルールで防ぎたい経営リスクを明記する
- 対象情報、対象業務、対象部署、対象AI・SaaS、対象委託先を明記する
- 規程本文、情報分類表、AI入力禁止情報判断表、委託先共有ルール、事故初動フローを成果物として分ける
- 社員教育、FAQ、理解度確認、管理職判断例をRFP要件に入れる
- 例外承認、ヒヤリハット、違反対応、月次レビューを運用要件に入れる
- 候補会社に同じ回答フォーマットで、診断方法、設計方法、体制、費用、前提条件を回答させる
- 提案書の見た目ではなく、実務判断、事故時初動、運用継続性、契約条件で採点する
- 成果物権利、編集可能形式、次ベンダー共有、再委託、秘密保持、資料削除を契約条件に入れる
- 検収条件を「社内ルール一式納品」ではなく「現場が判断でき、事故時に動ける状態」にする
- 初期作成と月次運用を分け、更新責任を契約前に決める
この10点がないRFPは、候補会社が自社に都合のよい範囲で提案できます。規程本文だけなら安く見えます。セキュリティ診断を厚くすれば高く見えます。研修会社なら教育中心になります。法務系の支援会社なら条文中心になります。経営者が欲しいのは、禁止事項の紙ではなく、社員が迷わず判断でき、個人情報や顧客情報の漏えい懸念が出た時に説明可能な運用です。
本記事は、情報漏えい社内ルールを複数候補会社へ正式にRFPで依頼し、提案比較、契約条件、検収条件まで揃えたい会社向けです。まだ社内で範囲や予算を整理していない段階ではありません。既存ベンダーの成果物を別会社へ移す段階でもありません。
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
この記事を読むべき会社
この記事は、情報漏えい対策の社内ルール、生成AI利用ルール、AI利用規程、セキュリティ規程、個人情報取扱ルール、外部委託管理ルールについて、複数候補会社へ正式に提案依頼を出したい中小・中堅企業の経営者、DX責任者、情シス責任者、管理部門、法務向けです。
特に、次の状態にある企業に役立ちます。
- 情報漏えい社内ルール作成を候補会社にRFPで依頼したい
- 規程本文だけでなく、情報分類、AI・SaaS利用、委託先共有、事故初動まで含めたい
- 候補会社の提案を、金額や資料の見た目ではなく実務力で比較したい
- 生成AI、AI機能付きSaaS、クラウド共有、外部パートナー経由の漏えいリスクをRFPに入れたい
- 個人情報漏えいが疑われる時の報告、本人通知、取引先説明の社内初動を整理したい
- 社員教育、FAQ、例外承認、ヒヤリハット、月次レビューを作って終わりにしたくない
- 成果物の改変、社内配布、次ベンダー共有、編集可能形式を契約条件に入れたい
- 契約後に「それは別費用です」と言われないよう、検収条件までRFPに書きたい
逆に、まだ見積依頼前に何を依頼するか整理していない場合は、見積前整理の記事が近いです。既存ベンダーが作った成果物を別会社へ移す段階なら、既存ベンダー変更の記事が近いです。本記事は、正式に候補会社を比較するためのRFPに絞ります。
RFPの冒頭に入れる目的文
RFPの冒頭には、次のような目的文を入れてください。
当社は、生成AI、AI機能付きSaaS、クラウド共有、外部委託、リモートワークの利用拡大に伴い、個人情報、顧客情報、営業情報、技術情報、ソースコード、認証情報等の情報漏えいリスクを低減する社内ルールを整備したい。単なる規程本文の作成ではなく、情報分類、入力禁止情報判断表、委託先共有ルール、個人情報漏えい時の初動フロー、社員教育、FAQ、例外承認、ヒヤリハット、月次レビューを含め、社員が日常業務で判断でき、事故時に経営・法務・情シスが動ける運用体制を構築することを目的とする。
この目的文があると、候補会社は「規程を1本納品すればよい」と解釈しにくくなります。情報漏えい対策は、禁止事項の列挙では足りません。営業が商談メモをAIで要約する、開発者がソースコードをAIに入れる、人事が履歴書を要約する、CSが問い合わせ履歴をFAQ化する、委託先が社内資料を外部SaaSにアップロードする。こうした現場の判断をRFPで対象にしなければ、納品後に使えないルールになります。
RFP冒頭では、特に次の5つを目的として明記してください。
横にスクロールして確認できます
| 目的 | RFPでの書き方 |
|---|---|
| 経営リスク低減 | 個人情報、顧客情報、機密情報、技術情報、認証情報の漏えい防止を目的にする |
| 現場判断の統一 | 社員がAI、SaaS、クラウド共有、委託先共有で迷わない判断表を作る |
| 事故時初動 | 漏えい疑い発見時の報告、証拠保全、経営報告、外部連絡判断を整える |
| 顧客説明 | 取引先からのセキュリティ質問票やAI利用確認に回答できる状態を作る |
| 継続改善 | 例外承認、ヒヤリハット、月次レビューでルールを更新する |
目的が曖昧なRFPでは、候補会社の提案がばらつきます。ある会社は法務文書を厚くし、別の会社は技術対策を厚くし、別の会社は研修を厚くします。どれも必要になり得ますが、経営者が求める優先順位と合っていなければ失敗します。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
RFPに入れるべき50要件
情報漏えい社内ルール作成RFPには、最低限、次の50要件を入れてください。すべてを初期契約に含める必要はありません。ただし、含めるか、対象外にするか、後続フェーズにするかをRFP上で明記する必要があります。
横にスクロールして確認できます
| 要件 | RFPに書く内容 | 候補会社に回答させること |
|---|---|---|
| 対象目的 | 漏えい防止、事故時初動、顧客説明、社員教育、継続改善 | 優先順位と設計方針 |
| 対象情報 | 個人情報、顧客情報、営業情報、技術情報、ソースコード、認証情報 | 分類方法と判断基準 |
| 対象部署 | 営業、開発、CS、人事、経理、管理、法務、経営 | 部門別ヒアリング方法 |
| 対象者 | 正社員、役員、業務委託、派遣、外部パートナー、委託先 | 対象者別のルール範囲 |
| 対象業務 | 商談、提案、開発、採用、顧客対応、請求、広報、経営会議 | 業務別の漏えいシナリオ |
| 対象AI | 生成AI、AIチャット、議事録AI、翻訳AI、コード生成AI、画像生成AI | AI利用棚卸し方法 |
| 対象SaaS | CRM、グループウェア、ストレージ、会計、人事、開発ツール | SaaS管理者と権限確認 |
| 個人契約AI | 個人アカウント、無料版、試用版、部門契約 | Shadow AIの扱い |
| クラウド共有 | 共有リンク、外部共有、期限、閲覧権限、ダウンロード | 共有ルールの作り方 |
| 委託先共有 | 外部パートナー、再委託、士業、BPO、開発会社 | 共有可否と削除確認 |
| 情報分類表 | 公開、社内、限定、機密、個人情報、認証情報 | 分類項目と例示 |
| AI入力禁止情報 | 顧客名、個人情報、契約書、ソースコード、ログ、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利用設計 | 生成AI、AI機能付きSaaS、クラウド共有、個人アカウントの扱い |
| 入力禁止情報判断表 | 業務別に何を入力禁止・要注意・許可にするか |
| 委託先共有ルール | 外部パートナー、再委託、士業、BPO、開発会社への共有条件 |
| 個人情報漏えい初動 | 発見、報告、証拠保全、初動会議、外部連絡判断の設計 |
| 教育FAQ | 全社員、管理職、部門別FAQ、理解度確認の範囲 |
| 例外承認 | 申請、承認、期限、条件、見直し、月次反映 |
| 月次運用 | 会議体、アジェンダ、台帳更新、FAQ改定、報告書 |
| 体制 | PM、規程担当、セキュリティ担当、教育担当、レビュー担当 |
| スケジュール | 30日、60日、90日の成果物と意思決定ポイント |
| 費用内訳 | 診断、設計、文書作成、教育、月次運用、追加費用 |
| 契約条件 | 成果物権利、改変、社内配布、次ベンダー共有、再委託 |
| 検収条件 | 何をもって完了とするか |
| 前提・リスク | 社内資料不足、法務確認、SaaS設定、部門追加の扱い |
回答フォーマットを揃えるだけで、提案比較の質は上がります。候補会社が「当社は豊富な実績があります」と書いても、情報分類表、AI入力禁止情報判断表、事故初動フロー、例外承認台帳、月次レビュー表をどう作るのか答えられなければ、運用設計力は弱いと判断できます。
100点満点の採点表
情報漏えい社内ルール作成RFPでは、提案書の見た目や総額だけで選ばないでください。次の100点満点の採点表を使うと、候補会社の比較が明確になります。
横にスクロールして確認できます
| 評価項目 | 配点 | 見るポイント |
|---|---|---|
| 目的理解 | 10 | 規程作成ではなく、漏えい防止、事故時初動、現場判断を目的にしているか |
| 現状診断力 | 10 | 情報資産、AI・SaaS、委託先、既存規程、事故履歴を調査できるか |
| 情報分類・判断表 | 15 | 個人情報、顧客情報、技術情報、AI入力禁止情報を業務別に落とせるか |
| AI・SaaS・委託先対応 | 10 | 生成AI、クラウド共有、外部委託、再委託まで扱えるか |
| 個人情報漏えい初動 | 10 | 発見、報告、証拠保全、外部連絡判断、再発防止を設計できるか |
| 教育・FAQ・定着 | 10 | 全社員、管理職、部門別FAQ、理解度確認まで見ているか |
| 例外承認・月次運用 | 10 | 例外、ヒヤリハット、違反、月次レビューを運用に入れているか |
| 体制・実行力 | 10 | PM、規程、セキュリティ、教育、レビュー体制が明確か |
| 契約・権利条件 | 10 | 成果物権利、編集可能形式、次ベンダー共有、検収条件が明確か |
| 費用妥当性 | 5 | 総額ではなく、範囲と内訳に対して妥当か |
合格ラインは80点では甘いです。情報漏えい社内ルールは、会社の信用、取引先説明、社員行動、事故時対応に関わります。90点未満は最終候補から外し、95点以上を契約候補にするくらいでよいです。
点数だけでなく、赤信号も見てください。次に当てはまる候補会社は、総額が安くても慎重に扱うべきです。
- 規程本文の話ばかりで、情報分類表や判断表が出てこない
- AI・SaaS・クラウド共有・委託先共有の違いを分けていない
- 個人情報漏えい時の初動を「法務確認」とだけ書き、社内フローがない
- 教育を「説明会1回」で終わらせ、FAQや理解度確認がない
- 例外承認やヒヤリハットを運用に入れていない
- 成果物権利、編集可能形式、次ベンダー共有が曖昧
- 検収条件が「社内ルール一式納品」だけ
- 追加費用条件が曖昧
RFPに入れるべき契約条件
契約条件をRFPに入れないと、提案段階ではよく見えても、契約後に運用資産として使えないことがあります。特に成果物権利、編集可能形式、次ベンダー共有、資料削除、再委託、検収条件は必ず明記してください。
横にスクロールして確認できます
| 契約条件 | RFPに入れる理由 |
|---|---|
| 成果物の改変可否 | 情報分類表、FAQ、例外承認台帳、初動フローは継続改定が必要 |
| 社内配布可否 | 全社員教育、社内ポータル掲載、管理職説明に必要 |
| 次ベンダー共有可否 | 将来の支援会社変更、監査対応、内製化で必要 |
| 編集可能形式 | PDFだけでは台帳、FAQ、判断表を更新できない |
| テンプレート再利用 | 支援会社の汎用テンプレートと自社成果物の権利を分ける |
| 再委託の有無 | 事故情報、顧客情報、社員情報を扱うため管理が必要 |
| 秘密保持 | AI利用実態、顧客情報、ヒヤリハット、事故情報を共有するため |
| 資料保管・削除 | 契約終了後の資料保管、返却、削除証跡が必要 |
| 法的助言の範囲 | 支援会社の運用設計と弁護士判断を混同しない |
| セキュリティ監査の範囲 | 文書作成と技術監査を混同しない |
| 追加費用条件 | 部門追加、説明会追加、法務再確認、資料不足を明確にする |
| 検収条件 | 納品物名ではなく、使える状態を確認する |
| 契約終了時引き継ぎ | 台帳、FAQ、未決事項、更新履歴を残す |
RFPには、候補会社に契約条件への同意可否を回答させてください。「契約時に協議」とだけ書かれている場合は、後で揉める可能性があります。特に、成果物の改変と次ベンダー共有は重要です。情報漏えい社内ルールは一度作って終わりではありません。AIサービス、SaaS、委託先、組織、取引先要求が変わるたびに更新します。自社で更新できない成果物は、経営資産になりません。
検収条件は「社内ルール一式納品」では足りない
情報漏えい社内ルール作成で、検収条件を「社内ルール一式の納品」と書くのは危険です。規程本文が納品されても、社員が判断できず、事故時に動けず、月次で更新できなければ、情報漏えい対策としては不十分です。
検収条件は、次のように書いてください。
横にスクロールして確認できます
| 成果物 | 検収条件 |
|---|---|
| 社内ルール本文 | 目的、対象者、対象情報、禁止事項、例外、違反、改定が明記されている |
| 情報分類表 | 個人情報、顧客情報、営業情報、技術情報、認証情報、公開情報の例示がある |
| AI入力禁止情報判断表 | 業務別に入力不可、要注意、条件付き可、許可の判断例がある |
| SaaS・クラウド共有ルール | 外部共有、共有リンク、期限、権限、削除の基準がある |
| 委託先共有ルール | 委託先、再委託、士業、BPO、開発会社への共有条件がある |
| 個人情報漏えい初動表 | 発見、報告、証拠保全、初動会議、外部連絡判断、再発防止の流れがある |
| 教育資料 | 全社員向けと管理職向けが分かれ、現場例が含まれている |
| FAQ | AI入力、誤送信、外部共有、委託先、事故時の質問例がある |
| 理解度確認 | 受講履歴または確認フォームの運用方法がある |
| 例外承認台帳 | 申請者、用途、情報分類、条件、期限、承認者、見直し日が入る |
| ヒヤリハット記録 | 事故未満の事例を月次レビューへ反映する項目がある |
| 月次レビュー表 | 台帳、FAQ、例外、事故未満事例、規程改定の確認項目がある |
検収時には、候補会社に「社員がこのルールで判断できるか」を説明させてください。例えば、営業担当が顧客名を伏せた商談メモを生成AIに入れたい場合、人事担当が履歴書を要約したい場合、開発者がログをAIに貼り付けたい場合、委託先が共有リンクで資料を受け取りたい場合に、どの表を見て、誰へ相談し、どの条件で許可されるかを確認します。
個人情報漏えい時の初動をRFPに入れる
個人情報保護委員会は、個人情報の漏えい等が発生した場合の対応について情報を公開しています。報告要否や本人通知の要否は個別事情で変わります。RFPで求めるべきなのは、支援会社に法的結論を断定させることではなく、社内で誰が、何を、いつ、どの資料で判断し、必要に応じて法務・弁護士・個人情報保護専門家へつなぐかを設計することです。
RFPには、最低限次の初動フローを含めてください。
横にスクロールして確認できます
| 初動項目 | RFPで求める内容 |
|---|---|
| 発見者の報告 | 漏えい疑いを見つけた社員の報告先、報告様式、期限 |
| 一次受付 | 情シス、管理部門、法務、経営の誰が一次判断するか |
| 証拠保全 | メール、ログ、共有リンク、AI入力履歴、SaaS操作履歴の保存 |
| 影響範囲確認 | 対象情報、対象人数、対象顧客、委託先、再委託先 |
| 外部連絡判断 | 個人情報保護委員会、本人、取引先、委託先への連絡要否判断 |
| 社外説明 | 顧客説明文、FAQ、再発防止説明の作成と承認 |
| 再発防止 | 社内ルール、教育、権限、SaaS設定、委託先管理への反映 |
この初動フローがないRFPは、平時の禁止事項だけになります。事故時に誰も動けない社内ルールは、経営者にとって不十分です。
AI・SaaS・委託先を分けて書く
情報漏えい社内ルールRFPでは、AI、SaaS、委託先共有を一括りにしないでください。漏えいリスクの発生点が違うからです。
横にスクロールして確認できます
| 領域 | 典型的な漏えいリスク | RFPで求める成果物 |
|---|---|---|
| 生成AI | 顧客情報、個人情報、契約書、ソースコード、ログを入力する | AI入力禁止情報判断表、許可・禁止区分、FAQ |
| AI機能付きSaaS | SaaS内AIが顧客情報や社内文書を処理する | 利用サービス台帳、管理者確認、利用条件整理 |
| クラウド共有 | 共有リンクの外部公開、期限なし共有、権限過多 | 共有リンクルール、権限棚卸し、削除手順 |
| 委託先共有 | 外部パートナー、再委託、士業、BPOへの情報共有 | 委託先共有チェックリスト、削除・返却確認 |
| 開発・保守 | ソースコード、ログ、APIキー、障害情報の共有 | 開発情報の取り扱いルール、認証情報禁止表 |
候補会社には、各領域を同じ深さで扱えるかを回答させます。AIだけに詳しくても、委託先共有が弱ければ漏えい対策として足りません。セキュリティ設定に詳しくても、社員教育やFAQが弱ければ現場に定着しません。
業務別のRFP要件
情報漏えい社内ルールは、業務によって重点が違います。RFPでは、全社共通ルールだけでなく、業務別の判断例を求めてください。
横にスクロールして確認できます
| 業務 | RFPで求める判断例 | 候補会社に見たい力 |
|---|---|---|
| 営業 | 商談メモ、提案書、CRM情報、顧客名をAIや外部SaaSで扱う条件 | 顧客機密と営業効率の両立 |
| CS | 問い合わせ履歴、画面キャプチャ、クレーム、FAQ化の扱い | 個人情報と再発防止の整理 |
| 開発 | ソースコード、ログ、APIキー、エラー情報、AIコーディング | 技術情報と認証情報の区別 |
| 人事 | 履歴書、評価、面談メモ、採用AI、外部媒体 | 個人情報と採用判断の整理 |
| 経理 | 請求、給与、振込、会計SaaS、士業共有 | 権限と外部委託の管理 |
| 経営 | 未公開情報、資金繰り、M&A、役員資料 | 共有範囲と承認の厳格化 |
部門別の判断例がないと、社員は「この場合はどうするのか」と迷います。迷った社員は、自己判断でAIやSaaSに入力するか、怖くて使わなくなるかのどちらかです。どちらも経営にとってよくありません。
RFPに入れる質問票
候補会社へは、次の質問票をRFPに添付してください。
横にスクロールして確認できます
| 質問 | 見たいこと |
|---|---|
| 規程本文以外に、どの判断表・台帳・FAQを成果物にしますか | 運用成果物の具体性 |
| 生成AI、AI機能付きSaaS、クラウド共有、委託先共有をどう分けますか | AI時代の漏えい対策への対応力 |
| 個人情報漏えいが疑われる時の初動フローをどこまで支援できますか | 法務・情シス・経営の連携設計 |
| 社員教育、管理職教育、FAQ、理解度確認をどう設計しますか | 定着支援の具体性 |
| 例外承認、ヒヤリハット、月次レビューをどう運用に入れますか | 作って終わりを避ける力 |
| 成果物は編集可能形式で納品されますか | 次回改定や内製化への配慮 |
| 成果物の改変、社内配布、次ベンダー共有は可能ですか | 契約後の自由度 |
| 法的助言、セキュリティ監査、SaaS設定代行との責任分界をどう置きますか | 断定リスクと対象外の明確化 |
| 初期費用と月次運用費を分けて提示できますか | 見積比較のしやすさ |
| 契約後90日で何を改善指標として見ますか | 継続改善の設計力 |
回答が抽象的な会社は、提案も抽象的になります。特に「貴社の状況に応じて柔軟に対応します」という回答だけで、具体的な成果物名、会議体、判断表、検収条件がない場合は注意が必要です。
費用内訳は5つに分ける
情報漏えい社内ルールRFPでは、総額だけで比較してはいけません。次の5つに分けて回答させてください。
横にスクロールして確認できます
| 費用区分 | 内容 | 比較ポイント |
|---|---|---|
| 現状診断 | 情報資産、AI/SaaS、委託先、既存規程、事故履歴の棚卸し | どこまでヒアリング・資料確認するか |
| ルール設計 | 規程本文、情報分類、判断表、初動フロー、委託先共有 | 成果物の粒度 |
| 教育設計 | 教育資料、FAQ、理解度確認、管理職説明 | 社員定着まで含むか |
| 契約・検収整理 | 成果物権利、責任分界、対象外、検収条件 | 契約後の揉め事を減らせるか |
| 月次運用 | 例外承認、ヒヤリハット、FAQ改定、台帳更新、月次報告 | 作って終わりを避けるか |
安い提案は、現状診断と月次運用が抜けていることが多いです。高い提案は、技術診断や研修が厚く、RFP目的に対して過剰な場合があります。費用内訳を分けることで、削ってよいものと削ってはいけないものを判断できます。
安い提案で抜けやすい項目
安い提案が悪いわけではありません。ただし、安い提案では次の項目が抜けやすいです。
- 情報資産棚卸し
- AI入力禁止情報判断表
- SaaS・クラウド共有ルール
- 委託先共有チェックリスト
- 個人情報漏えい時の初動フロー
- 顧客説明や社外連絡の承認フロー
- 社員教育FAQ
- 管理職向け判断例
- 例外承認台帳
- ヒヤリハット記録
- 月次レビュー表
- 成果物の編集可能形式
- 次ベンダー共有
- 契約終了時の資料削除
これらが抜けているなら、安いのではなく、範囲が狭いだけです。RFP比較では、金額の横に「含まれる成果物」と「含まれない成果物」を並べてください。
契約前レビューで確認する10項目
候補会社を1社に絞る前に、契約前レビューで次の10項目を確認してください。
- RFPに書いた対象情報、対象部署、対象AI・SaaS、委託先が提案範囲に入っているか
- 規程本文以外の情報分類表、判断表、FAQ、初動フロー、台帳が成果物に入っているか
- 個人情報漏えい時の報告要否判断を、法務・外部専門家へつなぐ前提で設計しているか
- 法的助言、セキュリティ監査、SaaS設定代行が対象外なら明記されているか
- 成果物の改変、社内配布、次ベンダー共有が可能か
- PDFだけでなく、編集可能形式で納品されるか
- 追加費用条件が明記されているか
- 検収条件が「使える状態」になっているか
- 月次運用の範囲と費用が初期契約と分かれているか
- 契約終了時の資料返却、削除、引き継ぎが明記されているか
契約前レビューをせずに発注すると、納品後に「これは対象外」「これはPDFだけ」「これは月額契約が必要」「これは法務の責任」といった話になります。RFPで比較する段階で、契約後の揉め事を先に潰すべきです。
30日、60日、90日の進め方
情報漏えい社内ルール作成は、いきなり全社展開しようとすると重くなります。RFPでは、30日、60日、90日の段階成果物を求めると比較しやすくなります。
横にスクロールして確認できます
| 期間 | 目的 | 成果物 |
|---|---|---|
| 30日 | 現状診断と初期方針 | 情報資産棚卸し、AI/SaaS棚卸し、委託先共有確認、RACI、初期リスク一覧 |
| 60日 | 社内ルールと判断表 | 社内ルール本文、情報分類表、AI入力禁止情報判断表、委託先共有ルール、事故初動フロー |
| 90日 | 教育と運用開始 | 社員教育資料、FAQ、理解度確認、例外承認台帳、月次レビュー表、改善計画 |
候補会社には、この段階計画を出させてください。強い会社は、30日で何を決め、60日で何を作り、90日で何を定着させるかを具体的に出せます。弱い会社は、納品物名だけを並べます。
RFP文面サンプル
RFPには、次のような文面を入れると候補会社の回答が揃います。
本RFPでは、情報漏えい社内ルール本文の作成に加え、情報分類表、AI入力禁止情報判断表、SaaS・クラウド共有ルール、委託先共有チェックリスト、個人情報漏えい時の初動フロー、社員教育資料、FAQ、例外承認台帳、ヒヤリハット記録、月次レビュー表を成果物候補とする。候補会社は、各成果物について初期契約に含む範囲、対象外とする範囲、後続フェーズとする範囲、費用、前提条件、検収条件を回答すること。
候補会社は、法的助言、個人情報保護法上の最終判断、セキュリティ監査、SaaS設定代行、全委託契約の改定が本提案に含まれるか否かを明記すること。含まれない場合でも、社内法務、顧問弁護士、個人情報保護専門家、情シス、外部ベンダーへ接続するための判断フローを提案すること。
成果物は、社内で継続更新できる編集可能形式で納品すること。成果物の社内配布、改変、次ベンダー共有、将来の改定利用の可否を回答すること。契約終了時の資料返却、削除、削除証跡、未決事項の引き継ぎ方法も回答すること。
この程度までRFPに書くと、候補会社は曖昧な提案を出しにくくなります。
GXOに相談すべきタイミング
次のどれかに当てはまるなら、RFPを自社だけで作り切るより、要件整理や提案書レビューから相談した方がよいです。
- 候補会社に何を聞けばよいか分からない
- 規程本文、セキュリティ診断、社員教育、AI利用ルールのどこまでを初期範囲にすべきか迷っている
- 個人情報漏えい時の初動を、法務・情シス・経営でどう分けるか決まっていない
- 生成AIやAI機能付きSaaSの利用が広がっているが、社内の実態が見えていない
- 委託先や外部パートナーへの情報共有が多く、どこまでルール化すべきか分からない
- 候補会社の提案書を受け取ったが、金額差の理由を判断できない
- 成果物権利、編集可能形式、次ベンダー共有、検収条件を契約に入れたい
GXOでは、情報漏えい社内ルール作成そのものだけでなく、RFP作成、候補会社質問票、採点表、提案書レビュー、契約前の責任分界整理、AI・SaaS利用ルール、委託先共有ルール、個人情報漏えい初動、社員教育FAQ、月次運用まで一気通貫で支援できます。
相談の入口は、AI活用・AI社内ルールの相談 です。RFPを出す前なら、まず「何を候補会社に聞くべきか」から整理できます。すでに提案書がある場合は、100点採点表で比較し、契約前に潰すべき論点を洗い出せます。
関連記事
- 情報漏えい社内ルールの見積前整理: 情報漏えい社内ルール作成を見積依頼する前に整理する要件・費用・運用条件
- 情報漏えい社内ルールの既存ベンダー変更: 情報漏えい社内ルール作成で既存ベンダーを変更する前に見る引き継ぎ条件・責任分界
- 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となったため、この記事では断定根拠として使わず、残余確認対象にしています。個人情報保護委員会の報告要否や本人通知の判断は、個別事情により変わります。本記事は法的助言ではなく、RFPで社内初動と専門家連携を設計するための実務ガイドです。
