契約実務

BtoBクラウドの責任分界点—第5回：クラウドの調達

2022.02.02更新

クラウドサービスの利用は民間企業に限りません。世界各国のあらゆる政府機関、行政組織、教育機関、 NGOなどの公的機関がクラウドサービスの利用を加速しており、日本においても、たとえば、デジタル庁が政府のクラウドサービスの利用環境である「ガバメントクラウド」の整備・運用を進めています。

本記事では、こういった公的機関がクラウドサービスを利用するにあたっての調達・選定に関する論点に焦点を置いて解説していきますが、本記事で挙げる論点の多くは民間企業にも共通します。

クラウドサービスの性質

「クラウドサービス」についておさらいすると、「クラウドサービス」とは、1. インターネット経由で、2. 従量課金制で提供される、3. オンデマンドの 4. ITリソース、いわゆるIaaS (Infrastructure as a Service)などと呼ばれているサービスを指します。

各要素をより詳しく説明しますと、

「インターネット経由」で利用できるということは、クラウドサービスはいつでもクラウド事業者のウェブサイトにアクセスすることで利用できることを意味します
「従量課金制で提供される」クラウドサービスは、利用した分だけしか料金が発生しないため、コストの最適化が図れます
「オンデマンド」のクラウドサービスは、必要な時に必要な分だけ利用者の判断で利用できます
「ITリソース」とは、すべての利用者に対して同一に提供されるストレージや仮想サーバなどのサービスを指します

こうしたクラウドサービスの要素は、利用者が自己のニーズに合う形で特製化された物理的資産を保有していた従来のオンプレミスモデルから大きく異なりますが、クラウドサービスを利用することによって、従来のITでは得られなかったコスト最適化やデジタルトランスフォーメーション(DX)などの大きなメリットをもたらすことが可能になります。クラウドサービスを利用することのメリットについては本連載の第2回目をご参照ください。

クラウドサービスの調達方法

従来のオンプレミスモデルのITの場合は特製化されたシステムアプリを “作ってもらう” ので、特に公的機関が調達する際には、データセンター、ハードウェア、サーバ等について詳細に要件を定義し、それら要件を満たした完成物をベンダーに “納品” してもらいます。

これに対して、クラウドにおけるITリソースの確保は、すべての利用者に同一で提供されているITリソースにインターネット経由でアクセスすることにより実現されます。システムアプリごとの特製化は、ITリソースそのものではなく、利用者側で必要なITリソースを “選定” した上で、利用者がそれらITリソースを適切に設定・管理し、組み合わせて使うことにより実現されます。

とはいえ、クラウドにおいてITリソースを確保する方法は複数あり、この選択肢はホームセンターでの買い物に例えると分かりやすいです。

たとえば、ホームセンターではさまざまな材料やツールを売っていますが、これはクラウド事業者が多種多様なサービスを提供しているのと同じです。また、ホームセンターの従業員が家に来て材料やツールを使って何かを “作る” ようなことをしてくれないのと同様に、クラウド事業者もクラウドサービスを使ってシステムアプリを構築してくれるわけではありません。

そこで、ホームセンターで買った材料やツールを「モノ」に作り上げるには、三つの選択肢が考えられます。

材料やツールを自ら確保し、自分自身で作る
材料やツールの確保は自ら行うが、作業をしてくれる業者を別に起用する
業者と契約し、材料やツールの確保を含めたすべての作業を依頼する

この例を、クラウド上で稼働するシステムアプリの場合に当てはめると、次のようになります。

クラウドサービスのみを調達し、自らシステムアプリを構築する〜これは、組織内にクラウドサービスを使いこなせるノウハウがある場合の選択肢です
クラウドサービスを独自で（つまり、分離して）調達し、システムアプリの設計やクラウド環境の構築などについてシステムインテグレーション(SI) 事業者などの支援を得る〜これは、現在ノウハウがなくても、たとえばいずれ自走する戦略を描いている場合に有力な選択肢です
クラウドサービスを独自で（分離して）調達せず、SI事業者に特製化されたシステムアプリをクラウド上で “作って” もらうか、既定のサービスとしてクラウド上で稼働しているいわゆるSaaS(Software as a Service)やPaaS(Platform as a Service)と呼ばれたりするサービスを “選定” する〜これは、クラウドに関してのノウハウがなく、クラウドサービスを選定することから設計・構築までのすべてを第三者に依拠する場合の選択肢です

公的機関による支出には透明性および公平性を担保するために調達プロセスを経る必要がありますが、クラウドサービスに関連する調達を形成し、契約を規定するにあたっては、上記のうちどのモデルを想定しているのかを念頭に置くことが重要になります。

クラウドサービスの調達方法

クラウドサービスの調達における論点

クラウドサービスの調達においては、どの調達モデルを採用するにせよ、共通する論点が複数あります。

（ア）責任分担

クラウドでは、クラウド事業者がすべての利用者に同一で提供しているサービスを、利用者側で必要なITリソースを “選定” した上で、それらITリソースを利用者が適切に設定・管理することにより、利用者が特製化されたシステムアプリを構築していきます。クラウドではクラウド事業者側での対応とクラウドサービス利用者側での対応とで2層構造あるので、特に注目されるセキュリティに関しては責任が分担されます。責任分担に対する考え方については、本連載の第4回目もご参照ください。

（イ）要件定義

要件定義とは、調達の対象となるモノについて、必要な機能や要求を定めていくプロセスを指します。クラウドでは、自己のニーズに合わせて “作ってもらう” 資産を “納品” してもらうのではなく、市場で提供されている既定のサービスのうち自己のニーズにあったシステムアプリの形に組み上げることが可能なサービスを “選定” することになりますが、この違いは要件定義にも影響を及ぼします。

（ウ）料金

物理的資産を固定金額で調達していた従来のITとは異なり、クラウドでは従量課金制がサービスの本質と言えます。

（エ）契約・利用規約

自己のニーズに沿って “作ってもらう“ 従来のITとは異なり、クラウドサービスはすべての利用者に対して同一サービスとして提供されます。クラウドでは、民間企業、公的機関であるかに関わらず利用者ごとにサービスが特製化されないということを反映して、利用条件も個々の利用者ごとに異なる合意をするのではなく、等しく同じ合意が成立すべきということになります。

これら（ア）〜（エ）の4つの論点については、上述した各購入モデルにおいて整理が異なってくるので、購入モデルごとに解説していきたいと思います。

クラウドサービスのみを調達する場合

クラウドサービスを使いこなせる深いノウハウがあるのであれば、クラウドサービスのみを調達し、設計、移行、構築、運用のすべてを内製化することが考えられます。

（ア）責任分担

この場合、クラウドサービスの提供に関する責任はクラウド事業者に分担され、クラウドサービスを適切に利用する責任は利用者に分担されます。たとえば、セキュリティに関する責任については、クラウド事業者がハードウェア、ネットワーク、施設等のインフラの保護について責任を負う一方で、利用者は提供されるクラウドサービスを活用して適切なセキュリティ対策を実施し、安全なシステムアプリを構築する責任を負います。この責任分担は、クラウドサービスの要件定義やサービス利用規約に反映されます。

（イ）クラウドサービスの要件定義

従来の物理的なIT資産を購入するための要件定義においては、ラック・サーバの種類やデータセンター間の距離等、ハードウェア・ソフトウェア・ネットワークの構成や施設・設備等の要件を固定する方式が取られています。しかし、クラウドでは自己のニーズにあったモノを “作ってもらう” のではなく、自己のニーズにあったサービスを“選定”します。よって、要件どおりの完成物を納品させるだけのこの方式はクラウドには馴染みません。

したがって、クラウドサービスを選定するにあたっては、どのようなシステムアプリでも構築できるITリソースを利用できるよう、高い評価水準の要件を定義し、かかる要件を満たすクラウド事業者を選定することが望ましいです。この要件には、仮想サーバ、データ保存、暗号化などのサービスや機能のみならず、障害が起こっても稼働を継続できるよう複数のデータセンター群が活用できるといったサービスの提供方法も含まれます。

クラウドの世界では、業界標準やベストプラクティスをとり込む形での認証制度が発達しています。たとえば、上述したクラウド事業者のインフラの保護に関する責任については、ISO 270001といった第三者による認証やSOCレポートと呼ばれる監査報告書が高水準を満たしている国際的な証跡となります。さらに、日本においては、政府情報システムのためのセキュリティ評価制度(ISMAP)が適切な認証制度であると考えられます。クラウドサービスを選定するにあたっての要件定義においては、これらの認証を盛り込むことが重要です。

高水準の要件を満たしたクラウドサービスは一つとは限りません。要件に照らし合わせた結果、複数のクラウド事業者が要件を満たすことが確認できたら、すべてを “選定” することも可能です。そうすることにより選択肢が増えて柔軟性も増すことが、従来のITではなかったクラウドサービスのメリットの一つです。

なお、一般的な競争入札による調達の場合、応募する事業者に入札価格を提示させ、その入札価格を比較した上で事業者一社を落札者に指定することで競争性を担保しますが、上述した“選定” する方法の場合、競争性は価格ではなく技術やサービスの継続性等の面で担保することになります。

（ウ）従量課金制と予算管理・確保

クラウドサービスのメリットの一つにコストの最適化が挙げられますが、これを実現するためには、クラウドサービスを従量課金制で利用することが理想的です。さらに、クラウド事業者はスケールメリットを活かして継続的に定価を下げる傾向にあるので、利用者として値下げの恩恵を受けるためには、従量課金のベースとなる単価価格についてクラウド事業者がウェブページで公開している定価を参照することが望ましいです。

公的機関においては、従量課金制に関連して予算管理が必ずといっていいほど課題になります。

公的機関は原則として割り当てられた年度予算内でしか支出を行えません。従来のITでは契約金額を固定して支出を予算内に収めていましたが、クラウドでは、クラウド事業者が提供するサービスを活用して予算管理を実施することが望ましいです。たとえば、利用量をモニタリングし予算を超えそうになった時点でアラートを発信するサービスを活用すれば、アラートが出た時点で利用を抑制するガバナンスを効かせて予算範囲内での利用に留められます。

翌年度以降の予算の確保も公的機関にとっては重要な事柄ですが、クラウド事業者はサービスまたは機能ごとに単価を公開しており、利用金額を見積るサービスも提供しています。そのようなサービスを活用すればシステムアプリ構築にかかるクラウドサービスの料金を見積ることが可能になり、予算を確保することができます。

（エ）利用規約

クラウドサービスは、すべての利用者に対して同一サービスとして提供されています。サービスは汎用であるという性質を反映し、利用条件も個々の利用者ごとに異なる合意をするのではなく、等しく同じ利用規約の下に合意が成立すべきということになります。

なお、システムやサービスを利用できる能力のことを指す「可用性」についても同じことが言えます。通常、クラウド事業者はサービスごとに可用性に関するService Level Agreement (SLA)を規定していますが、このSLAはすべての利用者に対して同一のものが適用されます。

クラウド事業者の標準的利用規約やSLAを受け入れることは、特に公的機関にとっては高いハードルになり得ます。しかし、海外ではたとえ公的機関であっても、クラウドサービスがすべての利用者に対して同一のサービスとして提供される性質を踏まえ、クラウド事業者の利用規約をもとにサービスを利用する傾向にあります。

クラウド事業者の利用規約について懸念がある場合は、クラウド事業者に対して利用規約の内容についての背景を掘り下げることが推奨されます。そうすることにより、従来のITにはみられなかった条件がクラウドサービスについては必要である理由が理解できるようになるはずです。なお、クラウドサービスの性質を踏まえた利用規約の内容については、本連載の第3回目で解説しています。

（オ）国内における事例

日本政府によるクラウドサービスのみを調達する実例としては、2021年10月に実施された「デジタル庁におけるガバメント・クラウド整備のためのクラウドサービスの提供」の公募が挙げられます。

この公募は、ガバメントクラウドの整備を進めるデジタル庁が、ガバメントクラウドで利用されるクラウドサービスを募集し、選定された事業者と直接契約を締結するという取り組みでした。この取り組み自体が日本政府にとっては初めてのものでしたが、公募の方法にも上述した特徴が見られます。

たとえば、クラウドサービスの要件については300を超える項目から構成される「基本事項及びマネージドサービスの技術要件詳細」が規定され、公募公告においては、応募したクラウド事業者のうち、デジタル庁によってクラウドサービスの提供が可能と判断された事業者すべてと契約を締結するものとされています（下線部は筆者らが付記）。応募の条件に入札価格の提示が含められておらず、入札価格によって一の“落札者”を決していないことがこの公募の独特な点です。

技術要件詳細においては、サーバ、ストレージ、データベースなどのサービスについてだけでなく、バックアップやアカウント管理の機能に加えて、予算管理・確保の観点から必要となる使用量の可視化などについても記載があります。さらには、ISMAP登録はもちろんのこと、価格がオンライン公開されていることや値下げ傾向にあるといった実績も求められ、クラウドサービスの要素を反映した要件定義であると言えます。

契約的には、政府が定めた「基本契約書」を締結することが公募を通じて選定されたクラウド事業者に求められており、この「基本契約書」においては、クラウドサービスの従量課金制のメリットを最大限活かすために単価契約の形態がとられています。公共部門では総額を以って契約する「総価契約」が原則ですが、特例として、「単価契約」の活用が認められています。「単価契約」とは、契約上の数量が確定できないものについて、単価を契約の主目的とし、実績数量を乗じて得た金額の代価を支払うことができる契約形態を意味します。

また、本公募においては、政府様式の「基本契約書」とは別に「個別契約」の締結も想定されています。調達仕様書に記載されているとおり、この「個別契約」にはクラウドサービスの提供にあたっての詳細な条件が定められ、応募要領においては、応募するクラウド事業者がこの「個別契約」の雛形を提出することが求められています。

設計構築等についてSI事業者の支援を得る場合

クラウドサービスを独自で(分離して)調達しつつ、SI事業者から設計や構築に関する支援を受ける場合、当事者については、クラウド事業者と利用者に加えてSI事業者が加わり、業務については、クラウドサービスの提供の他にSI事業者の業務が加わります。したがって、クラウドサービスのみの調達の場合と比較して、各当事者による業務や責任の明確化・棲み分けが重要になってきます。

（ア）責任分担

この場合の役割分担は、クラウド事業者がクラウドサービスを提供し、利用者がそのサービスを活用し、SI事業者が利用者によるクラウドサービスの活用を支援するというイメージになり、責任もこの役割に応じて分担されます。

クラウド事業者は同一のサービスを提供しているので、SI事業者の関与によって責任範囲が変わるわけではありません。他方で、利用者に分担される責任については、SI事業者が利用者のクラウドサービスの活用の支援に入ることで、SI事業者がその責任の一部を負担することが想定されます。この責任分担については、SI事業者と利用者との間の合意に基づくことになります。

（イ）クラウドサービスと支援業務の要件定義の区別

クラウド事業者が提供するクラウドサービスは汎用なので、SI事業者が支援に入る場合であっても、クラウドサービス自体の要件が変わることはありません。

他方で、SI事業者が提供する支援業務については、利用者と事業者との間で個々に合意に至る必要があり、業務の内容によっては、従来のITのように固定された要件定義になることも考えられます。SI事業者の業務については、システムアプリの設計やクラウド環境の構築といった技術的な支援はもちろんのこと、特に公的機関に対しては、請求代行に加えて、予算超過リスクに留意し適切に予算管理を実施するための役務が含まれることが多くあります。

この場合の要件定義において重要なのは、クラウド事業者に適用されるクラウドサービスの要件定義と、SI事業者に適用される支援業務の要件定義が明確に区別されていることです。

（ウ）クラウドサービスの従量課金制と支援業務の料金

料金については、クラウドサービス自体は従量課金制で利用することが望ましい一方で、SI事業者が提供する業務については、業務の内容によっては固定金額で調達することが望ましい可能性があります。

（エ）クラウドサービスの利用規約と支援業務の契約

クラウドサービスはクラウド事業者の標準的利用規約に基づいて利用される、という考え方がSI事業者の関与によって変わるわけではありません。これは、SI事業者としても、クラウド事業者に分担される責任をクラウド事業者に代わって負うことが困難であるからです。

もちろん、SI事業者は自らが提供する業務について責任を負う必要があり、その責任を反映する契約の形態としては、請負契約や準委任契約が考えられます。いずれにせよ重要なのは、要件定義と同様に、クラウドサービスと支援業務に関する契約の内容が区別されている必要があるという点です。

この区別は場合によっては複雑になるかもしれません。

たとえば、可用性に関するSLAを見てみましょう。利用者としては、自己ニーズに合うかたちで構築されるシステムアプリについて、クラウド事業者がサービスごとに規定するSLAより高い水準の可用性を求める必要があるかもしれません。こういったより高い水準の可用性は、SI事業者に対して設計・構築を支援してもらい、障害が起こっても機能・稼働を継続できるようあらかじめ予備装置を複数のデータセンターで運用するなど、システムアプリの構築を通して担保してもらうことが考えられます。

この場合、二つのSLAが存在することについて留意が必要です。一つ目はクラウド事業者が規定するSLA、すなわち “選定する” クラウドサービスそのものに係るSLAであり、もうひとつは、SI事業者に担保してもらうSLA、すなわちSI事業者に “作ってもらう” システムアプリ全体に係るSLAです。

このように、SI事業者が関与する場合はSLAが二つ存在しうるので、可用性については、要件定義および契約において、何について可用性を求めようとしているのか、そして誰に対してSLAを課そうとしているのかを明確にする必要があります。

（オ）国内における事例

クラウドサービスを分離して調達しつつも、SI事業者に一定の支援を求めた事例としては、総務省が2020年に実施した「第二期政府共通プラットフォームにおけるクラウドサービスの提供等に関する業務」に関する調達が挙げられます。

本案件における調達および契約書に関しては内閣官房IT総合戦略室・総務省行政管理局が詳細な報告書を公開していますので、詳細についてはかかる報告書をご参照ください。なお、第二期政府共通プラットフォームはガバメントクラウドの整備・運用に伴って廃止されると報道されていますが、クラウドサービスの調達方法が「設計構築等についてSI事業者の支援を得る場合」のモデルとして参考になるので、本記事においては本案件を紹介しています。

本案件の調達では、総務省がSI事業者を通じて（つまり再販を通じて）クラウドサービスを確保した他、SI事業者に対してアカウント管理や請求代行の支援業務を依頼しています。これは政府がクラウドサービスを分離調達した早い時期の事例ですが、上述したクラウド事業者、利用者およびSI事業者の役割分担が要件定義や契約書に反映されている事例でもあります。

たとえば、要件定義については、仕様書の中で、SI事業者の業務内容を別紙1において「請負者のサービス提供条件」と規定し、SI事業者としては関与しない・できないクラウドサービスの提供について別紙2において「クラウトサービスの条件」と規定し、明確に区別しています。

また、契約的にも責任分担に対して配慮しており、クラウドサービスの再販に関連してSI事業者が総務省に対して負う責任が利用規約に基づいてクラウド事業者がSI事業者に対して負う責任の範囲に限定されることが、契約上でも明記されています。

さらに、料金についても、クラウドサービスの提供とその他業務に関する料金が区別され、前者については月々の利用実績に基づく従量課金制、後者については月額固定とされています。

なお、本件の調達においては、入札事業者に対して入札価格の提示が求められ、入札価格を考慮した総額評価方式によって落札事業者一社が選ばれています。クラウド事業者はすべての利用者に適用される定価をオンライン公開しているため、公開定価そのものを入札価格として調達を実施しても落札者一社を決することができません。したがって、本調達においては、SI事業者に対してクラウド事業者の公開定価とSI事業者の再販割引率（割増率）を入札価格として提示させ、再販割引率を比較することで落札者を決定しています。

本調達は、価格の面で入札者を競争させるという意味では従来の調達方式を踏襲しています。他方で、契約の中では「契約期間内に…定価が変動する場合は、契約時と同等の割引（又は割増）率で利用できるものとする。また、新たなサービスが追加利用される場合は同様のサービスと同等の割引率とする。」と規定されています。このように、本調達の契約では、クラウドサービスならではの性質である、定価が一般的に適用されたり新規サービスが継続的に導入されたりする点に配慮していることが注目に値します。(クラウドサービスの性質に関する詳細については、本連載の第2回目をご参照ください)

システムアプリの特製化や SaaS/PaaS等、すべてについてSI事業者に依拠する場合

クラウドサービスを独自で（分離して）調達せず、クラウドサービスを選定することから設計・構築までのすべてを第三者に依拠する場合は、二通りの調達パターンが考えられます。

SaaS/PaaS

一つ目は、クラウド上で稼働しており、既定のサービスとして提供されているSaaSやPaaSを利用することです。

こういったSaaSやPaaSはすべての利用者に対して同一のサービスとして提供されているため、クラウドサービスと同じようにサービスを “選定する” ことになります。したがって、要件定義や契約・調達方式に関する考察は上述したクラウドサービスにおけるものと類似します。

責任分担については、事業者側でより広範で責任を負ってくれるため責任の境界点がより事業者寄りになりますが、責任が事業者と利用者で分担されることには変わりありません。

また、料金形態についても、クラウドサービスと同様に従量課金制になることが想定されます。

システムアプリの特製化

二つ目は、特製化されたシステムアプリをSI事業者にクラウド上で設計・構築してもらうことです。このパターンは従来のITの “作ってもらう” イメージに近いので、固定した方法による要件定義や固定金額での調達になる可能性があります。

もっとも、この場合でも、完成物であるシステムアプリの一部を構成するクラウドサービスに関して上述した要素があることは変わりません。したがって、コストの最適化を図るなどの理由から、クラウドサービスの部分は分離調達し、クラウドサービスの利用料については単価契約を活用することにより、上記の「設計構築等についてSI事業者の支援を得る場合」のモデルに近づけることも考えられます。これを実施するかについては利用者の判断が求められ、SI事業者との合意が必要になるところです。