IaaS構築を外注する前に決める責任分界点と成果物の所有権

IaaSの構築を外注しようと調べ始めると、出てくるのはクラウド事業者の比較記事ばかりです。どこのサービスを使うかという情報は豊富にある一方で、誰にどう頼むかという実務を扱った情報は多くありません。

本記事では、製品の比較はいたしません。発注する側が契約前に何を決めておくべきか、という一点に絞って整理します。

外注で後から効いてくるのは、技術力の差よりも、決めないまま進めた条件です。責任の分け方、成果物が誰のものになるか、契約の形、そして解約するときの条件といった項目は、着手後に交渉を始めると不利になりがちです。

責任分界点、成果物の所有権、契約形態、見積もりの前提、出口の条件、そして外注すべきでない範囲という6点を順に見ていきます。

クラウド事業者を選ぶことと構築会社を選ぶことは別

最初に整理しておきたいのは、この2つが別々の判断だという点です。同じ会議で同時に決めようとすると、議論が混ざります。

IaaSは、サーバーやストレージ、ネットワークといった基盤を事業者から借りて使う形態を指します。借りた土地の上に何を建てるかは利用者側の裁量であり、OSから上の設計と運用は自社の責任範囲に残ります。

つまりクラウド事業者を決めても、設計と構築の仕事はそのまま残ります。事業者が保証するのは基盤の可用性までで、その上に載る構成が実運用に耐えるかどうかは、設計した人の力量で決まります。

総務省の令和7年版情報通信白書によると、2024年時点で80.6%の企業がクラウドサービスを利用しています。（総務省「令和7年版情報通信白書」）

利用が当たり前になった分だけ、事業者選びよりも「誰が設計するか」の差が結果に出るようになりました。事業者の名前で安心せず、構築を担う会社の設計内容を見てください。

責任分界点を1枚の対応表にまとめる

外注の準備で最も効果が高い作業は、工程ごとの担当を1枚の対応表に書き出すことです。この作業は発注前に、自社の側で始められます。

対応表の項目には、基盤の維持、設計と構築、移行、監視と通知、復旧の試験、更新の適用、障害時の一次受付、費用の管理といった工程を並べます。それぞれについて、自社、構築会社、クラウド事業者のどこが担うのかを埋めていきます。

埋めていくと、必ず空欄が残ります。多いのは、バックアップからの復旧試験と、費用が想定を超えたときの検知です。どちらも平常時には誰も困らないため、担当が決まらないまま運用に入りがちな部分にあたります。

クラウド事業者が担う範囲は、事業者側の規約であらかじめ定められています。裏を返せば、そこに含まれない部分はすべて、自社か構築会社のどちらかが引き受けることになります。

この対応表を提案依頼の資料に添えると、各社の提案が同じ土俵に並びます。逆に対応表なしで見積もりを取ると、金額の差が役務範囲の差なのか単価の差なのか判別できません。

成果物の所有権を契約前に決める

外注で最も後から効いてくる条件が、成果物が誰のものになるかという点です。ここを曖昧にしたまま進めると、数年後に他社へ切り替えられない状態になります。

設計書とパラメータシート

構築の内容を記録した文書が、どの形式でいつ納品されるのかを決めておきます。画面の写真を貼っただけの資料と、設定値が一覧で読み取れる資料とでは、引き継ぎのしやすさがまったく違います。

あわせて、稼働後に設定を変更したときの文書更新を誰が行うのかも決めておく必要があります。更新されない資料は、時間の経過とともに価値を失います。

構成を自動化するコード

構成を自動で作るためのコードを使って構築する場合、そのコードの権利と保管場所が論点になります。コードが構築会社の環境にしか存在しない状態は、実質的なロックインを生みます。

自社が管理する場所にコードを置き、内容を読める形で受け取れるかを確認してください。読めなければ、資産として持っていても活かせません。

テナントの名義

見落とされやすいのが、テナントの契約名義です。構築会社の名義で作られた環境は、請求も管理者権限も相手側にあります。

自社名義で契約し、必要な権限を構築会社に付与する形にしておくと、会社を変えるときの手続きが軽くなります。どちらの形にするかは、費用の支払い方と社内の管理体制の相対評価で決めます。

構築工程は請負契約で依頼する

IaaS構築を外注するときは、請負契約を基本に考えることをおすすめします。請負は仕事の完成に対して対価を払う契約で、作業の遂行に対して対価を払う準委任とは責任の置きどころが異なります。

請負であれば、何を完成させるかを契約の時点で定めるため、受け取る成果物と費用を事前に見通せます。完成した成果物が契約の内容に合わない場合に、修補などを求められる点も発注側にとっての利点です。

一方の準委任は、作業にかけた時間や工数に応じて費用を払う形が一般的で、完成そのものを約束する契約ではありません。要件が固まらないまま作業が長引くと、そのぶん費用も膨らみやすくなるでしょう。

IPAが公開する「情報システム・モデル取引・契約書」でも、請負と準委任の性質を踏まえたうえで、契約の時点で仕様や検収の方法について発注側と受注側の認識をそろえることが促されています。（独立行政法人情報処理推進機構「情報システム・モデル取引・契約書（第二版）」）

請負で依頼するための前提は、仕様が確定していることです。現況調査と要件定義を先に済ませ、構成や移行の範囲を文書にしてから構築を発注すると、請負の利点を生かせます。要件が動く段階だけを準委任で切り出し、構築は請負で固める形にすれば、完成を約束してもらう範囲がはっきりするでしょう。

なお、契約書の具体的な文言については一般的な整理にとどめています。実際の締結にあたっては、法務部門や専門家にご確認ください。

「CyaaSでは構築工程を請負でお受けしています」のような自社の立場の一文は、先方の実際の契約運用が確認できていないので入れていません。そうした運用であれば、まとめH2に足すとさらに訴求が強まるので、先方に確認してみてください。

見積もりの精度は現況調査で決まる

同じ要件を伝えても、会社によって見積もりの精度は大きく変わります。差が生まれるのは、金額を出す前に現況を確認したかどうかです。

要件を聞いただけで金額を出す会社と、既存環境の確認から入る会社では、着手後の追加費用の発生率が変わります。既存環境の確認、さらには現地調査から入る会社であれば、かなり心強いといえます。

確認してほしいのは、現行サーバーの台数と構成、動いているミドルウェアの版数、扱うデータの量、業務を止められる時間帯、そして既存の運用手順書の有無です。これらは資料だけでは実態と食い違っていることがあります。

見積書を受け取ったら、前提条件の欄を先に読んでください。前提が細かく書かれた見積書ほど、後から前提が崩れたときの議論がしやすくなります。
金額だけが安い見積もりは、確認していない部分が多いという意味でもあります。安さの理由を説明できるかどうかを、その場で質問してみてください。

受け取った見積もりの前提が自社の環境に合っているかを、第三者の立場から確認したい場合は、次の窓口もご利用ください。

運用と出口の条件を先に決める

構築が終わった後の条件は、契約前にしか決められません。稼働してから交渉を始めると、選択肢がほとんど残らない状態になります。

決めておきたいのは3点です。1つ目は復旧の目標で、障害から復旧するまでにかけてよい時間と、どの時点のデータまで戻せるかを数値で決めておきましょう。前者を復旧時間目標、後者を復旧時点目標と呼びます。

2つ目は障害時の一次受付です。利用者から連絡を受ける窓口がどこになるのか、そこからクラウド事業者へ問い合わせる経路はどうなるのかを、文書で確認しておきましょう。

3つ目は解約時の条件です。契約が終わるときに、設計文書とコード、データをどの形式でいつまでに返してもらえるのか、移行の支援を受けられるのかを決めておきます。

あわせて、再委託の可否と範囲も確認しておきたい部分です。実際に設計と構築を行う技術者が、契約先の会社に所属しているのかどうかは、提案の場で聞けば分かります。

外注すべきでない範囲

すべてを任せる形は、短期的には楽でも、後から選択肢を狭めます。次の4つは自社に残しておくことをおすすめします。

• 何を作るのかという要件の決定

• 費用の上限と、超えたときの判断

• クラウドの契約名義と管理者権限

• 運用の判断基準（どこまでを異常とみなすか）

要件の決定を任せると、出来上がったものが業務に合っていなくても、その理由を説明できるのは相手だけという状態になります。判断の材料を作ってもらうことと、判断そのものを預けることは違います。

もう1点、委託先のセキュリティ体制も確認しておきたい部分です。IPAの「情報セキュリティ10大脅威 2026」の組織編でも、サプライチェーンや委託先を狙った攻撃が2位に選出されています。（独立行政法人情報処理推進機構「情報セキュリティ10大脅威 2026」）

外部の会社に環境の管理者権限を渡す以上、その会社の体制も自社のリスクに含まれます。認証の取得状況や作業者の管理方法を、提案の段階で聞いてください。

作業者の入れ替わりが多い体制では、設定の意図が引き継がれずに残る場合もあります。担当する技術者が固定されるのかどうかも、あわせて確認しておきましょう。

よくある質問

IaaSの構築を外注すると費用はどれくらいかかりますか

対象システムの規模、既存環境からの移行の有無、担ってもらう工程の範囲で大きく変わるため、一律の相場は示せません。設計、構築、移行、運用の工程ごとに金額を分けて出してもらう方法をおすすめします。
工程を分けて出せない見積もりは、範囲が固まっていない可能性があります。

どこまで外注できますか

設計から構築、移行、稼働後の運用まで、工程単位で任せられます。設計だけを切り出して依頼し、構築は別の会社に頼むという形も選べます。
ただし要件の決定と費用の判断は、自社に残しておくほうが後の選択肢を確保できます。

設計書やコードは自社のものになりますか

契約の書き方によって変わります。何も定めなければ、成果物の権利や保管の扱いが曖昧なまま進みかねません。
納品物の一覧と形式、権利の帰属、保管場所を契約書に明記してもらってください。文言の妥当性は法務部門にご確認ください。

テナントは誰の名義にすべきですか

自社名義を基本にしておくと、会社を変えるときの手続きが軽くなります。請求の処理や社内の管理体制の都合で構築会社の名義にする場合は、移管の手順を契約前に文書で確認してください。

準委任と請負のどちらで契約すべきですか

工程によって使い分けます。要件がまだ動く上流は準委任、仕様が確定した構築は請負という形が一般的です。
1本の契約にまとめず、工程ごとに区切ると、条件を見直す機会を作れます。

途中で会社を変えられますか

可能ですが、成果物の扱いとテナントの名義によって難易度が変わります。設計文書とコードが自社の手元にあり、テナントの契約が自社名義であれば、引き継ぎは進めやすくなります。

中小企業でも頼めますか

規模を問わず依頼できます。担当者が少ない企業ほど、設計だけを切り出して依頼し、運用の一部を任せるといった形が現実的です。

IaaS構築の外注でお困りならCyaaS株式会社へ

CyaaS株式会社は、サーバー、ネットワーク、セキュリティ、クラウドを含むITインフラ基盤を、要件定義から設計、構築、導入まで一貫してご支援するエンジニアリング集団です。

特定のメーカーやプロダクトに縛られない中立的な立場から、オンプレミス、クラウド、両者を組み合わせた構成のいずれについてもご提案しております。物品の購入を伴わない構築と設計だけのご依頼にも対応しており、設計だけを切り出して発注したい場合にもお使いいただけます。

これまでの支援実績には、信頼性と拡張性を重視した某病院向けのネットワークと仮想化基盤の設計構築がございます。停止が許されない環境の設計経験から、復旧の目標値や運用体制の設計についてもご相談いただけます。

情報セキュリティマネジメントシステムの認証（ISO/IEC 27001:2022、登録番号JUSE-IR-560）も取得しており、委託先としての体制についてもご確認いただけます。

責任分界点の整理や、受け取った見積書の前提確認といった段階からご相談いただけます。お問い合わせには通常3営業日以内にご返信しております。

参考文献

• 総務省「令和7年版情報通信白書」2025年

• 独立行政法人情報処理推進機構「情報システム・モデル取引・契約書（第二版）」2020年

• 独立行政法人情報処理推進機構「情報セキュリティ10大脅威 2026」2026年