RFPの“クラウド利用条件”は嫌がらせじゃない

――発注者の事情を知ると、提案がラクになる

「RFPに“クラウドは日本国内リージョン限定”とか　“外国に個人データを出しちゃダメ”って書いてあるけど、　こんなの現実的じゃないよ…嫌がらせか？」

クラウド案件のRFPを見た受注側から、そんなため息が漏れる場面、よくあります。

• 使えるクラウド事業者が限定されている

• データ保管場所にやたらこだわっている

• 再委託や海外拠点を細かく聞かれる

• 「マルチテナントは原則禁止」みたいな条件がさらっと書いてある

受注側から見ると、“縛り”にしか見えないかもしれません。

でも、発注者側の社内を見ていると、あのクラウド利用条件は決して嫌がらせではなく、

「発注側の社内事情＋法律＋監査」の結果しかたなく、ああいう書き方になっている

ということが分かってきます。

今回は、

• RFPに出てくる“クラウド利用条件”はどこから生まれているのか

• 受注側として、どう読めばいいのか

• どう提案に落とせば「分かっている会社」に見えるのか

を、発注者視点＋クラウド法務の視点で整理してみます。

1. RFPに出てくる「クラウド利用条件」って、具体的には何？

まずは、よくある“クラウド利用条件”をざっくり分類してみます。

よく見る条件の例

• データ保管場所・国外移転系

  • 「個人情報は日本国内のデータセンターで保管すること」

  • 「国外のクラウド環境に個人データを保存しないこと」

  • 「海外への第三者提供・委託が発生する場合は事前承諾」

• クラウド事業者・サービス種別の指定

  • 「パブリッククラウドは◯◯社のみ利用可」

  • 「SaaS利用時は、当社が承認したサービスに限る」

  • 「マルチテナントSaaSは原則不可、別テナント・専用環境を要望」

• アクセス・認証まわり

  • 「ID連携（SSO）必須」

  • 「すべての管理者アカウントで多要素認証必須」

  • 「外部からのアクセスはVPNまたはゼロトラスト基盤経由」

• 再委託・運用体制

  • 「運用・監視の再委託先を開示すること」

  • 「海外拠点によるオフショア開発・運用は原則不可」

  • 「再委託先の変更には事前承諾を要する」

• ログ・監査・インシデント対応

  • 「アクセスログを◯年間保管すること」

  • 「インシデント発生から◯時間以内に一次報告」

  • 「監査・説明要求に応じること」

受注側からすると、

「そこまで指定されると、うちの標準クラウド構成がそのまま出せない…」

と感じる項目ばかりかもしれません。

でもこれ、発注側の「気分」ではなく、かなり具体的な事情から出ていることが多いのです。

2. なぜ発注者は、あえてクラウド利用条件を細かく書くのか

発注者側の事情を、大きく4つに分けてみます。

① 個人情報保護法・業界ガイドラインのプレッシャー

• 個人情報保護法の改正

• マイナンバー・医療情報・金融情報などのガイドライン

• 海外クラウド利用に関する注意喚起

このあたりを受けて、発注企業の個人情報保護担当・法務・監査部門は、

「個人データがどこにあって、誰が見られるのか」「委託なのか、第三者提供なのか、国外移転なのか」

を、これまで以上にハッキリさせざるを得なくなっています。

その結果、

• 「個人データを海外リージョンに置くのは、現時点では社内承認が通らない」

• 「マルチテナントSaaSに預けると、説明・監査が大変すぎるので原則NG」

といった社内ルールが先にできあがり、それがそのままRFPに流れ込んでいるわけです。

② 監査・親会社・金融機関からの要求

上場企業・金融系・大企業グループでは、

• 親会社のガバナンス

• グループ全体のセキュリティ基準

• 監査法人からの指摘

などから、

「クラウドはここまで」「この条件を満たしていないベンダとは契約しない」

という**“最低ライン”**が決まっていることが多いです。

RFP担当者自身も、本当は柔軟にやりたいものの、

「ここを緩めると、あとで監査に怒られる」

のが分かっているので、あらかじめ条件として明記せざるを得ない、という事情があります。

③ 過去の事故・ヒヤリハットの“反省”

現場で実際にあったインシデントや「ヒヤリ」が、そのままRFPの条件になることもよくあります。

• 過去に退職者アカウントが生きていて問題になった

• 海外拠点のベンダーからのアクセス経路が把握できていなかった

• ログがすぐ消えるSaaSを使っていて、事故調査で困った

こういう経験をすると、

「次のシステムからは、ここだけは絶対条件にしよう」

という形で、かなりピンポイントな“クラウド条件”が生まれます。

④ 誰かが「リスクを引き受ける」ための根拠が欲しい

最後に、発注側の決裁プロセスの事情があります。

• 新システムを入れるとき、情報システム責任者や個人情報保護管理者が、「このリスクなら受け入れ可能」と判断して決裁します。

そのときに、

• クラウド事業者はどこか

• 海外移転があるか

• ログ・監査はどうなっているか

• 障害・漏えい時の対応はどうか

といった材料がないと、“責任を引き受ける”判断ができないのです。

だから、RFPの段階で

「こういう条件なら、そのリスクは受けられます」

という“線引き”をしておきたい。それが、クラウド利用条件になっています。

3. 受注側が誤解しがちな3つのポイント

発注側の事情が分かると、RFPのクラウド利用条件を見たときの受け止め方も変わってきます。

よくある誤解を3つだけ。

誤解1：

「“日本国内のみ”と書いてある＝海外要素は一切ダメ」

現実には、

• 業務データ・個人データの保管は日本リージョン限定

• ただし、クラウド事業者の運用上のログやメタデータまで完全にゼロにはできない

というケースがほとんどです。

にもかかわらず、受注側が

• 「海外要素が少しでも入るので、御社条件には合いません」と即ギブアップ

• あるいは、逆に「全部国内です」と言い切ってしまい、後で矛盾が出る

という両極端な対応をしてしまうことがあります。

発注側が知りたいのは、

「どのデータが」「どの程度」「どんな目的で」海外に行くのか「それに対して、どんな契約・対策になっているか」

であって、

• すべてゼロ

• すべてNG

という単純な話ではないことが多いのです。

誤解2：

「マルチテナント禁止＝専用環境でないと絶対ダメ」

RFPに「マルチテナント利用は原則不可」と書かれていても、

• 個人情報を扱うコア部分だけ専用環境に

• それ以外はマルチテナントSaaSを利用

• リスクが高い部分については追加の契約・監査・設定でカバー

という折衷案が通ることもあります。

ところが、

• 受注側が標準SaaSプランだけしか提案しない

• あるいは、「専用構成にしたらこの価格です」とだけ出して終わり

という提案になってしまうと、発注側からすれば「選択肢がない」状態になってしまいます。

誤解3：

「再委託の制限＝海外オフショアが嫌いなだけ」

再委託・海外拠点利用の制限は、

• 個人情報保護法上の委託・第三者提供

• 業界規制での“委託先管理”

• 情報漏えい時の説明責任・監査のしやすさ

といった事情から来ています。

発注側としては、

「どの会社が」「どの国で」「何の作業をしているのか」

が追える構造になっていれば、絶対に海外はダメ、というわけでもありません。

にもかかわらず、

• 実態として海外メンバーが関わっているのに、それを隠して提案

• 逆に、「一切関わらせない」前提で無理な見積もりをして自滅

というケースも少なくありません。

4. RFPのクラウド利用条件を「読み解く」コツ

受注側としては、RFPの条件を見て即「あきらめる／無視する」のではなく、

「この条件は、何を守りたい結果なのか？」

を読み解くところから始めると、提案の幅が広がります。

コツ1：

「守りたいもの」を言葉にしてみる

• 個人情報を海外に出したくないのか

• 業務継続性を確保したいのか

• 監査対応をシンプルにしたいのか

• 再委託先の数を増やしたくないのか

条件から逆算して、

「このRFPを書いた人たちは、何を一番怖がっているのか」

を仮説でいいので言葉にしてみると、提案の組み立て方が変わってきます。

コツ2：

「A案（完全準拠）＋B案（現実的オプション）」の2段構えにする

• A案：RFP条件に可能な限り忠実に従った構成

• B案：一部条件を緩める代わりに、別の対策でリスクを下げる構成

という2案を出すのもひとつの手です。

例：

• A案：日本リージョン専用／専用環境／フルマネージド

• B案：一部マルチテナント利用＋厳しめのアクセス制御＋追加ログ＋年次報告

こうしておくと、発注側も

「A案は理想だが高い。B案はリスク説明を聞いたうえで採用可能か」

という**“選択の議論”**ができるようになります。

コツ3：

「条件そのもの」を疑うより、「条件の背景」を聞いてみる

質疑応答の場などで、

• 「この条件は守れません」と突き返すよりも、

• 「この条件で一番気にされているポイントはどこでしょうか？」

と、背景を聞いてみると、案外「ここさえ守ってくれればOK」という“真の条件”が見えてくることもあります。

もちろん、すべての発注者が丁寧に教えてくれるわけではありませんが、少なくとも

「発注側の事情を理解しようとしているベンダー」

として、印象はまったく変わります。

5. やってはいけないRFPクラウド条件への対応

逆に、これは危ない…という対応パターンも整理しておきます。

NGパターン1：

「大丈夫です」「問題ありません」だけで押し切る

• 条件を読んでいるのか読んでいないのか分からない

• 何がどう「大丈夫」なのか説明がない

• 後から構成や契約を見たら、全然条件を満たしていなかった

発注側としては、一番不安になるパターンです。

NGパターン2：

条件を完全スルーして“いつもの構成”だけ提案

• 提案書が、会社標準のクラウド構成のコピペだけ

• RFPに書いてある条件との関係が何も説明されていない

「うちはいつもこの構成なので」という気持ちは分かりますが、発注側からすると

「この会社、RFPちゃんと読んでるのかな…」

という印象になります。

NGパターン3：

後出しで「実は海外拠点で運用しています」

• 提案時には国内だけのように書いておき、

• 契約や実装の段階で「実は海外拠点も関わります」と判明

これは、発注側法務・情シスからすると完全にアウトです。

• 最悪、案件そのものが白紙に戻る

• その後の別案件でも声がかかりにくくなる

というリスクがあるので、「どこまでなら海外が関わるのか」は最初から正直に出したほうが、結果として話が早いことが多いです。

6. 山崎行政書士事務所がお手伝いできること

山崎行政書士事務所では、発注側・受注側の両方のクラウド案件に関わってきた経験を活かして、

• RFPに書かれているクラウド利用条件を「法律・ガイドライン・発注者社内ルール」の観点から読み解くサポート

• 受注側が出す提案書について、クラウド構成・データ保管場所・再委託・ログ・インシデント対応などの説明パートを、発注者に伝わりやすく書き直すお手伝い

• RFP条件に対して

  • A案（条件完全準拠）

  • B案（現実的オプション＋リスク説明）をどう設計するかの整理メモ作成

• その内容と整合したクラウド利用規程・情報セキュリティチェックシート・契約条項案の整備

などを行っています。

「RFPのクラウド条件を読むと、いつも『うちの標準構成じゃムリだ』で思考停止してしまう」

「正直に実態を書いたほうがいいのは分かるけど、どう表現すれば発注側に伝わるのか分からない」

という受注側の会社さんに対して、発注者の“中の人目線”も踏まえた現実的な落としどころ探しを一緒にお手伝いできます。

静岡県内のシステム開発会社・クラウドベンダーの方で、実際のRFPや提案書の現物を見ながら整理したい、というご相談も歓迎です。

RFPのクラウド利用条件は、決して受注側をいじめるための“嫌がらせ”ではなく、

「発注側が社内や法律と折り合いをつけるための、ギリギリのライン」

であることがほとんどです。

その事情を少しだけ理解してもらえれば、条件を「壁」として見るのではなく、

「発注側が本当に守りたいポイントを当てにいくヒント」

として使えるようになります。

その視点を提案書に織り込める受注会社は、クラウド時代の案件でも**“長く付き合いたい相手”**として選ばれやすくなります。