【クラウド法務】RFPを出したのに、なぜ“ベンダー主導の進め方”になるのか― 仕様は出したのに、決めるべきこと（主語・期限・証跡）が自社に残っていない構造 ―

※本記事は一般的な情報提供であり、個別案件の法的助言ではありません。

────────────────────────────

はじめに

────────────────────────────

「RFPはちゃんと出した。比較もした。稟議も通した。なのに、気づいたら“ベンダー主導”で進んでいる」

この違和感、情シス・IT部門の方なら一度は経験があるはずです。

典型的にはこういう状態です。

会議のアジェンダが、いつもベンダー側から出てくる

自社はレビューする側のはずなのに、判断材料が揃わず「お任せで…」になっていく

仕様の議論は進むのに、監査・取引先照会の話になると沈黙が増える

最後に残るのは「構成図」と「見積」だけで、説明責任（誰が・いつまでに・何を出す）が自社で言えない

そして導入後、監査・取引先・親会社からの質問で詰まります。

「障害や事故のとき、誰がどこまで対応する義務？」

「ログ提出は何営業日以内に出せますか？保全（削除停止）は誰が？」

「例外（暫定開放やCA除外）は期限管理してますか？」

RFPは“発注側が主導するための仕組み”のはず。

それなのにベンダー主導になるのは、担当者の頑張り不足ではなく、RFPが「構成（What）」中心で、「統制（Who/When/Proof）」が未設計のまま走り出す構造があるからです。

本記事では、なぜそうなるのかを

「共感 → 技術的な整理 → 法務の地雷 → 対策フレーム → 事例 → チェックリスト → 相談導線」

の順で整理します。

────────────────────────────

技術構成の“事実整理”：RFPで書きやすいのは「構成」、でも後で問われるのは「運用の主語」

────────────────────────────

RFPは通常、要求事項を列挙します。クラウド案件だと、たとえば次のような項目が並びます。

Azure Landing Zone（サブスク設計、ネットワーク、ポリシー）

Entra ID（条件付きアクセス、MFA、PIM、break-glass）

監視（SIEM、アラート、インシデント）

BCP（Azure Backup / Site Recovery）

運用（MSP/SOC、24/7、チケット対応）

ここまでが「構成の話」です。

ベンダーもここを最も得意とします。テンプレがあるからです。

一方で、導入後に必ず問われるのは、構成図に描かれない次です。

誰が（主語）：一次通知、封じ込め、ログ保全、ログ提出、対外説明の責任は誰？

いつまでに（期限）：何分以内に通知？何営業日以内に提出？復旧は何時間？

何を証拠に（証跡）：その主張の根拠は？抽出者記録は？保全記録は？

例外はどう扱う（暫定の出口）：暫定開放やCA例外の期限・解除条件・補償統制は？

つまり、RFPが「構成（What）」中心で作られるほど、

後から必要になる「統制（Who/When/Proof）」は未決定のまま進みます。

ここまでは技術の話。

ここからが法務・説明責任の話です。

“ベンダー主導”になる瞬間は、構成の議論が進む一方で、

統制（主語・期限・証跡）が決まらず、決めきれない側（発注側）が「判断を預ける」状態になったときに起きます。

────────────────────────────

2. RFPを出したのにベンダー主導になる理由（よくある5つの構造）

────────────────────────────

「RFPを出した＝主導できる」ではありません。

以下のどれかが欠けると、RFPがあっても主導権はベンダーに寄ります。

────────────────────────────

理由①：RFPが“比較仕様書”になっていて、「決裁すべき論点」が書かれていない

────────────────────────────

RFPは比較に向いている一方で、比較に寄せすぎるとこうなります。

どの製品／どの構成／どのサービスを使うか（比較しやすい）

その結果、社内として何を約束するのか（決裁が必要で比較しにくい）

たとえば、

「ログを取る」は比較できる。

でも「何営業日以内に提出できる体制にする」は、社内の覚悟・委託範囲・承認フローまで含むので、比較しにくい。

比較しやすい領域だけが先に決まると、後半は必ずこうなります。

「この辺は運用で調整しましょう（＝ベンダーの標準で進めましょう）」

これが“ベンダー主導”の入口です。

────────────────────────────

理由②：発注側に「決める人（A：最終責任者）」がいない／役割が固定されていない

────────────────────────────

RFPがあっても、発注側に次がないと主導できません。

最終的に“決める”役割（A）が固定されている

判断に必要な材料を揃える責任が誰にあるか決まっている

現場はレビューできても、決裁の主語が曖昧だと、最後はこうなります。

「ベンダーの推奨でいきましょう」

決裁の主語がない組織ほど、推奨が“決定”にすり替わります。

────────────────────────────

理由③：評価基準が「導入完了」中心で、「説明可能性（監査・事故）」が評価に入っていない

────────────────────────────

ベンダーは評価される項目に最適化します。

評価が「工期」「費用」「構成要件の充足」だと、当然そこに寄せます。

しかし導入後に必要なのは、次の能力です。

事故時に止める／残す／出すができる

監査で主語・期限・証跡が言える

取引先照会に期限付きで回答できる

これが評価項目に入っていないと、成果物（運用資料・台帳・証跡目録）は後回しになり、ベンダーの標準運用に乗せられやすくなります。

結果、ベンダー主導に見えます。

────────────────────────────

理由④：SOW（作業範囲）が“構成物”中心で、運用の義務（通知・提出・保全・記録）が書かれていない

────────────────────────────

RFPは出しても、契約・SOWで次が薄いと主導権はベンダー側です。

一次通知：何分以内に、誰へ、何を

ログ提出：何営業日以内に、どの形式で、誰の承認で

ログ保全：削除停止、隔離、抽出者記録を誰がやる

作業記録：実施者・時刻・内容を成果物として出す

例外台帳：暫定・除外の登録／期限管理／解除まで含む

SOWに書いていないことは、実務では「できれば」「別料金」「後日調整」になり、発注側が主導しにくくなります。

────────────────────────────

理由⑤：要件の“出口”がない（暫定が恒久化し、現実が提案書からズレる）

────────────────────────────

RFPで「ゼロトラスト」「標準化」「最小権限」を掲げても、導入・移行フェーズでは例外が出ます。

条件付きアクセスの除外

NSGの暫定開放

PIMを使わない常設特権

break-glassの運用逸脱

ログ保持の暫定短縮

これが「期限・解除条件・補償統制」を持たないと、現実は提案書からズレていきます。

ズレた瞬間から、ベンダーは「現実に合わせた運用」を提案し、発注側は追認になりがちです。

これも“ベンダー主導”に見える大きな原因です。

────────────────────────────

3. 法務・説明責任の地雷：ベンダー主導が「後で効く」ポイント

────────────────────────────

ベンダー主導そのものが悪いわけではありません。

問題は、“主導の結果”として 説明責任が自社に残るのに、説明できない状態になることです。

特に後から効く地雷は次の3つです。

────────────────────────────

地雷①：「対応可能」が社内外の“約束”に変換される

────────────────────────────

提案書・議事録・説明資料の「対応可能」は、後でこう問われます。

何営業日以内？

どの形式で？

誰の承認で？

義務？ベストエフォート？

言葉が約束に変わるのが、取引先照会・監査・事故後説明です。

曖昧な言葉が多いほど、後で苦しくなります。

────────────────────────────

地雷②：「SLA」と「約束された復旧（RTO/RPO）」が混ざる

────────────────────────────

提案ではSLAが前面に出がちです。

でも問われるのは「何時間で戻るか（RTO）」「どこまで戻るか（RPO）」で、これは自社の運用・手順・判断・テスト記録が要です。

ここを混ぜたまま進むと、説明が崩れます。

────────────────────────────

地雷③：委託・再委託が絡むほど、証跡が集まらず“期限内に答えられない”

────────────────────────────

SOC/MSP/海外SOCなど関係者が増えるほど、照会の回答は「材料集め」になります。

材料がSOWの成果物として定義されていないと、期限内に集まらず、説明が遅れます。

遅れは信用コストです。

────────────────────────────

4. “ベンダー主導”にしないための整理のフレーム（RFPの前後でやること）

────────────────────────────

ここからが実務の答えです。

RFPを活かして「発注側主導」を作るには、構成の前に “説明の設計” を置きます。

ポイントは、RFPを「構成要求」だけでなく「統制要求（成果物要求）」にすることです。

────────────────────────────

フレーム①：RFPの冒頭に「照会・監査・事故で答えるべき質問」を書く

────────────────────────────

RFPの最初に、こう書ける会社は強いです。

取引先照会：ログ提出は何営業日以内に可能か

監査：例外（暫定・除外）の期限管理と解除証跡を提示できるか

事故対応：最初の30分で止める／残す／出すの主語が定義されているか

委託：再委託（国外・海外SOC）の関与と監督責任が説明できるか

「この質問に答えられる状態を成果物として求める」

と書いた瞬間から、ベンダー提案の質が変わります。

────────────────────────────

フレーム②：タスク別RACIをRFP添付の“前提資料”にする

────────────────────────────

レイヤー分界ではなくタスク分界です。

最低限固定したいタスク

一次通知（何分以内、誰へ）

封じ込め（権限剥奪・通信遮断：判断者と実行者）

ログ保全（削除停止、隔離、抽出者記録）

ログ提出（期限、形式、承認、提出者）

復旧判断（BCP発動、切替の決裁）

対外説明（文面承認）

例外承認／延長／解除

これをRFPの前提にすると、ベンダー主導で“勝手に運用が決まる”状態を防げます。

────────────────────────────

フレーム③：成果物を「構成物」ではなく「説明物（Evidence）」で定義する

────────────────────────────

RFPで要求する成果物に、次を入れます。

証跡目録（Evidence Index：どこに何があるか）

ログ提出・保全パック（提出期限・形式・承認・抽出者記録・保全手順）

例外台帳（期限・解除条件・補償統制・解除証跡）

運用判断ログ（当時の判断を残すDecision Log）

監査用と事故対応用の資料の分離（混ぜない）

「構成図だけ」から「説明できる運用」へ移せます。

────────────────────────────

フレーム④：SOWで“お願い”を“義務”に変換する（ここが最後の砦）

────────────────────────────

RFPで書いても、契約に落ちないと実務で動きません。

SOWに最低限入れたい項目は次です。

一次通知：重大度基準＋通知期限

ログ提出：期限（何営業日以内）＋形式＋成果物

ログ保全：削除停止等の協力＋実施記録提供

特権アクセス：期限付き付与、付与理由、剥奪証跡

例外台帳：登録・棚卸し・解除まで作業範囲化

再委託（国外）：範囲と監督責任、情報移転の条件

契約終了時：アクセス剥奪証明、ログ引継ぎ、削除証明など出口

これがあると、ベンダー主導ではなく「契約主導」で進められます。

────────────────────────────

5. ケーススタディ（匿名化）：RFPを出したのに“標準メニュー”に乗せられたA社

────────────────────────────

（実務でよくある構図を匿名化しています）

背景

製造業A社（国内＋海外拠点）

Azure＋M365＋Entra ID 統合、SOC/MSP利用

RFPを出し、複数社比較して発注

起きたこと

提案はどこも立派な構成図（Landing Zone、SIEM、BCP）

比較基準も「構成」「価格」「工期」が中心

決めるべき“運用の主語・期限・証跡”は、後段の「運用設計で詰める」扱い

導入後、監査・取引先照会で「ログ提出期限」「例外台帳」「保全」の質問が集中

MSP/SOCの作業範囲はベストエフォートで、材料が期限内に集まらない

会議が増え、「結局どうする？」がベンダーの推奨頼みになった

立て直し（方向性）

タスク別RACIを作り、主語を役割で固定

例外台帳とログ提出・保全パックを整備（提出期限・承認者・形式を決定）

SOWを見直し、通知・提出・保全協力・記録提供を義務化

次回RFPでは「説明物（Evidence）」を成果物として要求に組み込んだ

結果

構成自体を大きく変えずに、照会・監査が荒れない状態へ寄せられた

ベンダー提案も「構成」だけでなく「説明可能性」を前提に変わった

────────────────────────────

6. 自社で確認できるチェックリスト（RFPを出しても主導権を失う兆候）

────────────────────────────

次のYESが多いほど、RFPがあってもベンダー主導になりやすいです。

□ RFPの要求が構成（サービス・機能）中心で、成果物（証跡・台帳・手順）が薄い

□ 評価基準が「工期・価格・構成」中心で、「説明可能性」が入っていない

□ 最終責任者（A）が役割として固定されていない

□ レイヤー分界で説明しており、事故対応タスク（止める/残す/出す）の主語が割れる

□ ログは集める前提だが、提出期限・形式・承認・保全（削除停止）が決まっていない

□ 例外（CA除外、暫定開放、常設特権）の台帳がない／期限がない

□ 委託（SOC/MSP）が絡むのに、SOWで通知・提出・保全協力が義務化されていない

□ 再委託（国外・海外SOC）の範囲と監督責任が説明できない

□ 「対応可能」「ベストエフォート」など曖昧語が資料に多い

□ 経営説明と監査説明が同じ資料で回され、言葉が約束になって怖い

YESが多い場合、RFPを強化するより先に「主語・期限・証跡」を固定するのが近道です。

────────────────────────────

7. まとめ：RFPで主導するには、構成の前に「説明の設計」を置く

────────────────────────────

RFPを出したのに“ベンダー主導”になるのは、発注側が弱いからではありません。

RFPが「構成（What）」中心で、「統制（Who/When/Proof）」が未設計のまま進む構造があるからです。

主導権を取り戻す鍵は、次です。

構成の前に、照会・監査・事故で答えるべき質問を固定する

タスク別RACIで主語を役割に落とす

証跡パック／例外台帳／証跡目録を成果物として要求する

SOWで“お願い”を“義務”に変換する

これが揃うと、ベンダー提案は「標準メニューの構成図」から、

「説明できる運用の提案」へ変わります。

────────────────────────────

8. 全国からのご相談について

────────────────────────────

山崎行政書士事務所では、Azure / M365 / Entra ID 等の技術構成と、契約・規程・監査対応をセットで整理し、

RFPを出しても主導権がベンダーに寄ってしまう状態を、責任分界（RACI）・証跡パック・例外台帳・SOW整合まで含めて立て直す「クラウド法務支援」を行っています。

RFPは出したが、運用の主語・期限・証跡が固まっていない

取引先照会（ログ提出・保全）で、委託先と自社の回答が割れる

「対応可能」が約束になってしまい、言葉が怖い

例外（暫定開放、CA除外、常設特権）が増えて説明が不安

次のRFPでは「説明できる成果物」まで要求に入れたい

といったお悩みがあれば、オンライン（全国対応）で初回のご相談を承っております。

お問い合わせの際に「RFPとベンダー主導の記事を見た」と書いていただけるとスムーズです。