IaaS開発の発注/外注/依頼/委託方法について

IaaS開発の発注・外注は、クラウドの月額料金だけでなく、要件整理、ネットワーク設計、セキュリティ、移行、運用までの責任範囲を決めてから委託先を選ぶことが成功の近道です。

この記事では、IaaSを使った業務システムの発注を検討している担当者に向けて、発注形態の選び方、RFPと要件の整理方法、契約形態、費用相場、委託先の選定、見積書の比較ポイントを順番に解説します。AWS・Azure・Google Cloudなどのサービス料金と、設計・開発・移行・運用を担うSI費用を分けて考え、発注後に追加費用や責任の押し付け合いが起きない状態を目指します。

▼全体ガイドの記事
・IaaS開発の完全ガイド

IaaSの発注・外注とは何ですか？

IaaSの発注・外注とは、クラウド上の仮想サーバーを借りるだけではなく、業務システムを安全に動かすための基盤設計、アプリケーションの開発や移行、監視、障害対応までを外部の会社に依頼することです。IaaSはOSやミドルウェア、ネットワーク、アクセス権を利用者側で設計する範囲が大きいため、クラウド契約と開発・運用委託を切り分けて考える必要があります。

IaaSでは仮想マシン、ストレージ、ネットワークなどの基盤を借り、OS、ミドルウェア、アプリケーション、データ、利用者の権限管理を自社または委託先が設計します。PaaSはアプリケーションの実行環境やデータベース運用の一部をサービス側に任せやすく、SaaSは完成した業務機能を利用する形です。既存のWindows Serverや特殊なミドルウェアを維持するならIaaS、OS管理の手間を減らしたい部分はPaaS、標準業務を早く導入したい部分はSaaSというように、業務単位で使い分けると発注範囲を絞れます。

クラウド事業者はデータセンターや物理ホストなどの安全を担いますが、OSパッチ、IAMの設定、ネットワークの公開範囲、暗号鍵、ログ監視、バックアップの復旧確認まで自動で責任を負うわけではありません。発注時には「誰が設定するか」だけでなく、「誰が毎月確認するか」「障害の一次切り分けを何分以内に始めるか」「契約終了時にどの形式でデータを返却するか」まで決めます。IPAの2025年資料でも、API操作、IAM、ネットワーク、ワークロード内の挙動を分けて監視する考え方が示されており、セキュリティを納品時の設定だけで終わらせないことが重要です。

発注形態はどのように選べばよいですか？

発注形態は、クラウドの契約先と、設計・開発・運用を担う会社を一社にまとめるか、役割ごとに分けるかで整理します。初めてIaaSを導入する企業は一括委託が進めやすい一方、既存の情報システム部門に運用力がある企業は、設計と移行だけを外注して運用を内製する方法も選べます。最初に自社が担える作業と担えない作業を棚卸しすることが、過不足のない発注につながります。

一括発注は、要件定義、クラウド設計、アプリ開発、データ移行、テスト、監視、運用引き継ぎまでを一社の責任範囲にする形です。担当者が少ない企業や、停止できない業務システムを初めてクラウドへ移行する企業に向いています。ベンダー間の調整が減る反面、提案された構成や料金を比較しにくくなるため、RFPで成果物、前提条件、除外作業、再委託の範囲を明確にし、クラウド利用料と委託費を分けた見積を要求します。

クラウド基盤、アプリケーション、監視運用を別会社に分ける分離発注では、それぞれの専門性や見積を比較しやすくなります。たとえばクラウド移行はクラウドに強い会社、業務アプリは既存ベンダー、24時間監視はマネージドサービス会社に分ける方法です。ただし、障害が発生したときにネットワーク、OS、アプリの境界で対応が止まりやすいため、インシデント管理者を決め、SLA、エスカレーション、切り分けに必要なログの共有方法を契約書に書きます。内製チームが全体を統括できる場合に適した発注形態です。

構築フェーズだけ外注し、安定稼働後に運用を内製へ戻す、または最初は運用を委託してから段階的に引き継ぐ方法もあります。移行直後は障害や問い合わせが増えやすいため、引き継ぎ期間、運用手順書の完成条件、教育回数、管理者権限の移管時期を先に定めます。単に「構築完了」とするのではなく、復旧訓練、バックアップからのリストア、監視アラートの受信、月次レポートの確認まで完了した状態を運用開始の条件にすると、引き継ぎ後の不安を減らせます。

RFPと要件整理は何を決めてから始めますか？

RFPは、提案依頼先に同じ前提で提案してもらうための文書です。細かな製品名を先に指定するより、業務上の目的、必要な性能、守るべきデータ、移行期限、運用体制、予算の考え方を示し、構成提案の余地を残すほうが比較しやすくなります。現行環境が不明なままRFPを配ると、各社が異なる仮定で見積を出すため、価格差が技術差なのか前提差なのか分からなくなります。

最低限、サーバー名、OSとバージョン、CPU・メモリ、ディスク容量、データベース、ミドルウェア、ライセンス、外部連携、固定IP、バッチ、利用時間、月間データ転送量を一覧にします。さらに、業務ごとの停止可能時間、繁忙期のピーク、同時利用者数、保存年数、個人情報や機密情報の有無を整理します。古いOSやサポート切れのミドルウェアは、単純移行ではなくアップグレードや再設計が必要になるため、RFPの前提条件として明記します。現行調査を委託する場合は、調査だけの成果物と、調査後に行う設計・移行作業を分けて提示してもらいます。

可用性、性能、拡張性、セキュリティ、バックアップ、災害対策、運用性を非機能要件として整理します。たとえば「止まらない」ではなく、月間稼働率の目標、復旧時間目標であるRTO、復旧時点目標であるRPO、ピーク時の応答時間、ログの保存期間、脆弱性対応の期限で表します。複数AZを使うのか、バックアップを何世代保管するのか、リージョン障害を想定するのかで、クラウド利用料と構築費が変わります。IPAの2026年度クラウド調達の公開資料でも、国内データ所在地や国内リージョン、アクセスログの保存、ISO/IEC 27001・27017・27018、ISMAPなどの要件が確認できるため、規制業種では自社の基準と照合してRFPに含めます。

RFPには、背景と目的、対象範囲、現行環境、業務要件、非機能要件、希望スケジュール、体制、提出物、評価基準、契約期間、予算の考え方を入れます。成果物は、基本設計書、詳細設計書、ネットワーク構成図、IAM設計、IaCコード、テスト計画書、移行手順書、運用手順書、障害連絡網、教育資料などに分けます。提案書にはクラウド利用料の算定条件、初期構築費、移行費、月次運用費、保守の対象外、追加変更の単価を記載するよう求めます。これだけで、安いが作業範囲の狭い見積と、必要な作業を含む見積を同じ土俵で比べやすくなります。

IaaS外注ではどの契約形態を選びますか？

契約形態は、作業範囲と仕様をどこまで確定できるか、発注者がプロジェクト管理をどこまで担えるかで選びます。IaaSでは現行環境の不確実性が残りやすく、要件定義を終えた後も移行テストで追加作業が見つかることがあります。そのため、全工程を一つの契約で固定するより、調査・要件定義、構築・移行、運用保守に分け、各段階の判断結果を次の契約へ反映する方法が実務に合いやすいです。

請負契約は、合意した仕事を完成させ、成果物を引き渡すことを軸にする契約です。確定した設計書に基づく環境構築、IaCコードの作成、移行ツールの開発、テスト環境の構築など、完成条件と検収基準を定められる作業に向いています。検収基準には、機能テストの合格だけでなく、バックアップの復元確認、権限の最小化、監視通知、性能試験、移行リハーサルなどを含めます。仕様変更の扱い、納期遅延時の連絡、第三者サービスの料金変動を誰が負担するかも明記します。

準委任契約は、専門家が善管注意義務を負いながら、調査、助言、設計支援、プロジェクト管理、監視運用などの業務を行う形です。現行環境の調査、クラウド選定、RFP作成支援、移行計画、月次運用、障害時の技術支援のように、成果物だけでなく継続的な活動や判断が価値になる作業に向いています。時間単価や月額の稼働範囲、対応時間、報告内容、未消化時間の扱い、休日対応、再委託の条件を確認し、発注者側の意思決定が遅れた場合のスケジュール影響も合意します。

運用保守契約では、24時間365日の監視が含まれるのか、平日日中のみなのか、アラートを受けてから何分以内に連絡するのか、復旧作業と原因調査が料金に含まれるのかを確認します。クラウド事業者の障害と、委託先が設定した監視やバックアップの不備は責任の所在が異なるため、SLAの対象を明確に分けます。また、月額運用費に含まれる定常作業と、OSアップデート、脆弱性対応、構成変更、性能改善、追加環境の作成などのスポット作業を分けておくと、運用開始後の請求を予測しやすくなります。

IaaSの発注・外注費用相場はいくらですか？

IaaSの費用は、クラウド利用料、初期の設計・構築費、既存システムの移行費、月次の運用保守費、改善や追加開発の費用に分けて考えます。クラウド利用料には仮想マシンだけでなく、ディスク、バックアップ、ロードバランサー、パブリックIPv4、監視ログ、データ転送、サポート、OSやデータベースのライセンスが加わります。したがって「サーバー一台の月額」だけを比較して発注すると、冗長化や監視を足した段階で予算を超えやすくなります。

小規模な開発・検証環境は月額1万〜5万円程度、小規模な本番環境は月額3万〜15万円程度が一つの予算検討レンジです。開発・検証環境は小型VMを1〜2台、少量のストレージ、最低限のログとする前提で、本番環境はWeb・AP・DB、バックアップ、監視、ロードバランサーやWAFなどを含む想定です。これはベンダーが保証する定価ではなく、一般的な構成を置いた推定です。複数AZ、DB冗長化、専用線、データ転送量、24時間運用を加えると月額20万〜100万円以上となるケースもあり、大規模・高トラフィック・GPU・複数リージョンでは月額100万円を超える可能性があります。

公式料金の例として、AWSのEC2 T3掲載価格では、t3.nanoが1時間あたり0.0052米ドル、t3.microが0.0104米ドル、t3.smallが0.0209米ドルです。730時間稼働し、1米ドルを150円として単純計算すると、VM本体だけで月額約570円、約1,140円、約2,290円となります（出典: Amazon EC2 T3インスタンス料金表、2026年確認）。AWS公式も、オンデマンド料金とは別にデータ転送やEBSなどの関連費用を確認するよう案内しているため、この計算額を業務システム全体の見積として扱ってはいけません。為替、リージョン、税、OSライセンス、割引制度によって実際の請求額は変わります。

新規に小さな環境を作るだけなら、要件整理、ネットワーク、IAM、監視、バックアップ、テストを含む初期費用は100万〜500万円程度が検討レンジです。複数サーバーの業務システム移行では500万〜2,000万円程度、基幹系の再構築、段階移行、複数拠点、災害対策、24時間運用まで含めると2,000万円〜1億円以上になることがあります。これらはIaaSに公的な一律相場があるという意味ではなく、一般的なSI作業量と隣接する業務システム開発の情報から置いた推定です。現行調査の深さ、データ移行量、テスト回数、停止できない時間、既存ライセンスの扱いによって大きく変わります。

期間も、小規模な新規環境や単純なリフトなら4〜10週間程度、中規模の移行なら3〜9か月程度、基幹系や複数リージョンの再設計なら6〜18か月以上を見込みます。AWSの導入事例では、川崎市が基幹20業務をカバーする13システムのガバメントクラウド移行を進め、2025年度末を見据えて2023年度から基本設計を開始しています（出典: AWS「川崎市」導入事例、公開情報確認）。大規模案件ほど、クラウドの設定作業だけでなく、業務標準化、データ移行、関係部署の合意形成が期間を左右します。

月次運用費には、監視、アラート対応、バックアップ確認、パッチ適用、アカウント管理、脆弱性対応、月次報告、問い合わせ対応が含まれることがあります。一方、追加環境、構成変更、性能改善、障害原因の詳細調査、データ復旧、移行リハーサルは別料金になりやすい作業です。見積依頼では、平常月だけでなく、OSの大規模アップデート、証明書更新、監査対応、バックアップからの復元試験、障害対応を含む年間の想定作業も確認します。クラウド事業者の利用料は従量課金であり、AWSではSavings Plansがオンデマンド料金から最大72％、スポットインスタンスが最大90％の割引になる場合がありますが（出典: Amazon EC2料金ページ、2026年確認）、利用期間や中断許容度が合わなければ採用できません。

委託先の選定と見積比較では何を見ますか？

委託先は、クラウドの認定数や知名度だけで決めず、対象システムと同じ規模・OS・データベース・業界要件の経験、移行後の運用体制、障害対応の実績、成果物の品質を確認します。IaaSの発注では、クラウド事業者と実装・移行・運用会社を分けて評価し、どの会社が設計書やIaCコードを所有するかまで確認することが重要です。提案プレゼンでは、理想構成の説明だけでなく、障害時の連絡経路、切り戻し、想定外の追加作業への対応を質問します。

「AWSに強い」「Azureに対応できる」という説明だけでは、発注先の適合性は判断できません。自社と似た業務、ユーザー数、データ量、可用性、既存OS、外部連携、セキュリティ基準の案件を確認し、担当予定者がどの工程に参加したかを聞きます。実績の公開が難しい業界では、匿名化した構成、課題、移行方式、期間、運用体制だけでも確認します。大規模案件の実績があっても、自社案件の担当チームが同じ品質で対応できるとは限らないため、提案時の責任者、設計者、移行担当、運用担当の役割を明確にします。

複数社の見積を比較するときは、まず、サーバー台数、稼働時間、ストレージ容量、バックアップ世代、ログ保存期間、通信量、冗長化、監視時間、サポート時間、為替、税、割引の前提をそろえます。そのうえで、クラウド利用料、初期設計、構築、移行、テスト、教育、月次運用、追加変更の単価を別行にします。たとえば一社がバックアップや監視を含め、別の会社がオプション扱いにしていると、合計金額だけでは比較できません。3年程度のTCOを、初年度の構築・移行費、2年目以降の利用料・運用費、定期的な改善費に分けて見ると、安価に見える提案の抜け漏れを発見しやすくなります。

委託先の選定では、システムが動くことだけでなく、将来ほかの会社へ引き継げることも確認します。設計書、構成図、IaCコード、CI/CD設定、監視ルール、ログ、バックアップ、アカウント、秘密情報の管理方法を成果物として定義し、所有権や利用権、保管場所、更新責任を契約に記載します。契約終了時は、データをどの形式で返却するか、クラウドアカウントを誰に移管するか、削除証明を出せるか、引き継ぎ期間を何日とするかを決めます。特定ベンダーへのロックインを避けるには、標準形式の設計資料と再現可能なIaCを納品条件に含めることが有効です。

IaaSの発注から稼働まではどう進めますか？

発注後は、要件定義、基本設計、詳細設計、構築、移行、テスト、リリース、運用引き継ぎの順に進めます。各工程を一度に完了させようとせず、構成の不確実性が高い部分は小さな検証環境で先に確かめます。特に、既存アプリがクラウドで動くか、性能が足りるか、データ移行に必要な停止時間を守れるか、バックアップから復旧できるかを早い段階で確認します。

現行調査では、構成図と実際の通信、バッチ、権限、ライセンス、障害履歴を照合します。資料だけでは分からない依存関係があるため、アクセスログや設定ファイルを確認し、アプリ担当者や業務担当者にもヒアリングします。続いて、IaaS上に最小構成の検証環境を作り、接続、認証、性能、バックアップ、監視、データ移行の試験を行います。この段階で要件を変更できれば、本番環境を作ってから大きな手戻りが起きる可能性を下げられます。

移行では、データの抽出、変換、転送、整合性確認、アプリ接続確認、利用者受け入れ試験を実施します。本番移行の前に、実データの容量と処理時間を近い条件で試し、停止時間が業務要件に収まるかを検証します。失敗した場合の切り戻し条件、旧環境をいつまで保持するか、誰がリリース判断をするか、利用者へどのタイミングで告知するかも手順書にします。テストには機能、性能、障害、セキュリティ、バックアップ復元、監視通知を含め、検収の証跡を残します。

稼働後は、監視アラートの確認、バックアップ結果、脆弱性、未適用パッチ、コスト、性能、アクセス権を定期的に見直します。月次報告には、クラウド利用料の増減、リソースの稼働状況、障害・問い合わせ、変更履歴、次月のリスクを含めます。AWS、Azure、Google Cloudなどのサービスは機能や料金体系が更新されるため、導入時に決めた構成を固定せず、利用状況に応じてサイズ変更、停止スケジュール、割引制度、マネージドサービスへの置き換えを検討します。契約の更新前に、運用実績と改善提案を評価する場を設けると、外注が単なる監視代行で終わりません。

よくある質問

IaaSの発注では、クラウド利用料と外注費の違い、RFPの作り方、内製と外注の境界について質問が多く寄せられます。ここでは、発注前に判断しやすいように、特に相談の多い内容を簡潔に回答します。

発注できますが、クラウドの操作経験だけでなく、ネットワーク、IAM、バックアップ、監視、移行、障害対応を設計できる体制が必要です。社内に運用担当がいる場合は、現行調査や構築だけを外注し、運用を内製する方法もあります。判断に迷う場合は、要件定義と技術検証を外注してから、内製できる範囲を決めるとリスクを抑えられます。

月額料金だけで決めるのは避けてください。初期の設計・移行費、月次の運用保守費、バックアップ、ログ、データ転送、サポート、OSやデータベースのライセンス、追加変更の費用を含むTCOで判断します。まず平常時とピーク時の構成を分け、3年程度の利用期間でクラウド利用料と委託費を試算し、料金変動や障害対応の条件も確認します。

RFPの前提がそろっているなら、性質の異なる候補を含めて3社前後に声をかけると比較しやすくなります。大切なのは社数より、同じ要件、同じ成果物、同じ運用時間、同じクラウド利用条件で見積を出してもらうことです。候補には、クラウド移行に強い会社、業務アプリに強い既存ベンダー、運用に強い会社などを含め、価格だけでなく、担当者の経験、責任分界、引き継ぎやすさ、提案の透明性を評価します。

すべての企業に同じ要件が必要なわけではありませんが、政府・自治体、医療、金融、個人情報や機微情報を扱う企業では、データ所在地、国内リージョン、監査ログ、認証、契約管轄を確認する必要があります。デジタル庁は2026年にもISMAPクラウドサービスリストを更新しており、IPAの2026年度クラウド調達資料でも、国内データ所在地やログ保存、ISO/IEC 27001・27017・27018、ISMAPなどが要件として扱われています（出典: デジタル庁・IPAの2026年公開資料）。自社の業界規制と取引先の要求を先に整理し、必要な範囲だけをRFPに入れることが現実的です。

まとめ

IaaS開発を発注・外注するときは、最初にIaaS、PaaS、SaaSの役割を整理し、自社が担う範囲と委託する範囲を決めます。そのうえで、現行環境と移行対象を棚卸しし、可用性、性能、RTO・RPO、セキュリティ、データ所在地、運用時間などの要件をRFPにまとめます。

契約は、完成条件を定義できる構築工程には請負、調査・設計支援・運用には準委任など、作業の性質に合わせて選びます。費用はクラウド利用料だけでなく、初期設計・構築、移行、月次運用、追加変更を分け、AWSなどの公式料金の前提とSI会社の作業費を分離して比較します。最後に、類似実績、障害対応、成果物の所有権、契約終了時の引き継ぎまで確認してから委託先を決めると、導入後も自社でコントロールできるIaaS基盤を作りやすくなります。

▼全体ガイドの記事
・IaaS開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。