「データの保管リージョンを日本国内に指定できること」という要件を文字どおり厳密に解釈すると、主要なクラウドサービスの多くが対象外になります。中間データ、メタデータ、冗長化データ、サポート対応時のログまで国外を一切経由しないことは、一般に保証されないためです。要件の意図は「外国政府による開示要求」「事業者による目的外利用」「紛争時の実効性」「規程との整合」の4つに分解でき、それぞれ別の手段で担保できます。そして確認は調達公告の前、RFIの段階で行ってください。
クラウドサービスの調達で、要件定義の段階で行き詰まる論点があります。セキュリティ対策基準に書かれた、データ保管場所に関する要求です。典型的にはこう書かれています。
データの保管リージョンを日本国内（東京・大阪等）に指定できること。準拠法および裁判管轄が日本国内であること。
意図は理解できます。しかし、この文言をそのまま必須要件として調達をかけると、応札できる事業者が極端に絞られるか、主要なクラウドサービスが軒並み対象外になります。
なぜ要件と仕様が噛み合わないのか
グローバルに提供されるクラウドサービスでは、主要なデータの保存先を特定の地域に指定する機能を持つものがあります。一方で、以下は指定の対象外となることが一般的です。
- 一時的な処理を行う際の中間データ
- サービスの機能提供に必要なメタデータ
- 障害時の可用性確保のための冗長化データ
- サポート対応時のログ
つまり「利用者が作成したデータの保存先は指定できるが、サービス全体として国外を一切経由しないことは保証できない」という状態です。要件を文字どおり厳密に解釈すると、満たせないサービスがほとんどになります。
準拠法・裁判管轄についても同様で、グローバル事業者の標準契約では日本法・日本の裁判所を指定できないことが多く、交渉の余地も限定的です。ここを必須要件に置いたまま進めると、実質的に選択肢が国内事業者に限られます。それが政策的な判断として意図されたものならよいのですが、多くの場合はそこまで議論されていません。
クラウド調達の要件整理、セキュリティ基準との整合確認、ベンダー選定の支援まで、発注者側の立場でご支援しています。構想段階からのご相談も承っています。
ITコンサルティング を見る →情シスコンサルティング要件の意図を4つに分解する
行き詰まったときは、要件そのものではなくその要件で守ろうとしているものに立ち返るのが有効です。国内保管要件の背後にあるのは、おおむね以下の4つです。
| 意図 | 実質的に効くのは何か |
|---|---|
| 1. 外国政府による開示要求への懸念 | 保管場所そのものより、事業者が開示要求にどう対応する方針か、暗号化の鍵を誰が管理しているか |
| 2. 事業者による目的外利用への懸念 | 契約条項で明示的に排除できる論点。保管場所とは独立している |
| 3. 紛争時の実効性への懸念 | 準拠法の指定だけでなく、国内法人との契約形態、サポート体制、SLAの内容でも担保できる |
| 4. 規程との整合という形式論 | 過去に定めた基準がそのまま残っており、当時の前提が現在のクラウド利用の実態と合っていない |
正直に言えば、4番目が実態であることも少なくありません。要件の出どころをたどると、数年前に策定された基準の条文がそのまま引き継がれているだけ、というケースです。この場合、要件を守ることが目的化しており、守ろうとしているリスクが特定されていません。
現実的な着地点
分解したうえで、次のような整理を提案することが多いです。
| 方針 | 内容 |
|---|---|
| 主要データの保管先指定は維持する | 機能として提供されているのだから、指定できるサービスを選ぶこと自体は妥当 |
| 「一切経由しない」水準は求めない | 代わりに、事業者が公開している情報をもとにどのデータがどこで扱われるかを文書として整理し、リスク評価の結果として記録する |
| 目的外利用の禁止は契約条項で担保 | 保管場所とは別の要件として明記する。多くの事業者が対応可能 |
| 第三者認証を代替の担保とする | 国際的なセキュリティ認証や、政府向けの評価登録制度への登録状況を統制水準の確認手段として使う |
| 再委託時の承認プロセスを明確化 | クラウド事業者の下請け構造まで含めた統制は、承認プロセスの設計で対応する |
公共分野の調達では、政府情報システムのためのセキュリティ評価制度（ISMAP）への登録状況が、統制水準を確認する実務的な手段になります。個別に監査を行うより現実的です。制度の位置づけはISMAPとはで整理しています。
調達公告の前に確認する
実務上、最も避けたいのは調達を公告してから要件の無理に気づくことです。この段階では要件を変えられず、不調になるか、要件を満たすと称した無理な提案が通ってしまいます。後者のほうが厄介で、契約後に「実は満たせていなかった」と判明します。
RFI（情報提供依頼）の段階で、「この要件は満たせるか、満たせない場合はどのような代替手段があるか」を事業者に問うのが正攻法です。回答を集めれば、要件の現実性が判断でき、必要ならセキュリティ基準側の改定手続きを並行して進められます。
RFIで聞く際は、機能の有無だけでなく「満たせない場合の代替案」を必ず併せて求めてください。○×の回答だけでは、なぜ満たせないのか、どこまでなら満たせるのかが分かりません。
基準側の改定も選択肢に入れる
基準は守るために作られたものであって、事業を止めるために作られたものではありません。前提が変わったなら基準を見直す、という判断も選択肢に含めておくべきです。
とはいえ、基準の改定は時間がかかります。組織によっては委員会の審議や上位規程との整合確認が必要です。だからこそ、調達スケジュールを引く段階で「改定が必要になる可能性」を織り込んでおくことが重要になります。要件定義の途中で必要性に気づいても、その時点から改定手続きを始めては間に合いません。
基準を改定する際は、削除するのではなく「何をもって代替とするか」を明記してください。単に要件を外すと、次に見直す担当者がなぜ外れたのか分からず、また同じ条文が復活します。
よくある質問
データの国内保管を必須要件にすると何が起きますか？
文字どおり厳密に解釈すると、主要なクラウドサービスの多くが対象外になります。利用者が作成したデータの保存先は指定できても、一時的な中間データ、メタデータ、冗長化データ、サポート対応時のログまで国外を一切経由しないことは一般に保証されないためです。応札できる事業者が極端に絞られます。
準拠法と裁判管轄を日本国内に指定することはできますか？
グローバル事業者の標準契約では指定できないことが多く、交渉の余地も限定的です。ここを必須要件に置いたまま進めると、実質的に選択肢が国内事業者に限られます。紛争時の実効性という意図であれば、国内法人との契約形態、サポート体制、SLAの内容でも担保できる余地があります。
国内保管要件の意図はどう分解できますか？
外国政府による開示要求への懸念、事業者による目的外利用への懸念、紛争時の実効性への懸念、過去に定めた規程との整合という形式論の4つです。開示要求は事業者の対応方針と暗号鍵の管理主体で、目的外利用は契約条項で、紛争時の実効性は契約形態やSLAで、それぞれ別に担保できます。
要件を満たせないと分かるのはいつが手遅れですか？
調達を公告した後です。この段階では要件を変えられず、不調になるか、要件を満たすと称した無理な提案が通ります。後者のほうが厄介で、契約後に実は満たせていなかったと判明します。RFIの段階で満たせるか、満たせない場合の代替手段は何かを事業者に問うのが正攻法です。
セキュリティ基準そのものを改定してもよいのですか？
前提が変わったなら見直すという判断も選択肢です。ただし改定には委員会の審議や上位規程との整合確認が必要で時間がかかるため、調達スケジュールを引く段階で改定の可能性を織り込んでおいてください。改定時は要件を削除するのではなく、何をもって代替とするかを明記します。
まとめ
国内保管要件を厳密に解釈すると、主要なクラウドサービスの多くが対象外になります。中間データ、メタデータ、冗長化データ、サポートログまで国外を一切経由しないことは、一般に保証されないためです。
要件の意図は開示要求・目的外利用・紛争時の実効性・規程整合の4つに分解できます。主要データの保管先指定は要件として維持しつつ、目的外利用は契約条項で、統制水準は第三者認証で、再委託は承認プロセスで担保するのが現実的な着地点です。
そして確認は調達公告の前、RFIの段階で行ってください。満たせるかどうかだけでなく、満たせない場合の代替手段まで併せて聞くこと。前提が変わったなら、基準側の改定も選択肢に入れておくべきです。