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

IaaSの発注・外注は、現行環境と要件を整理し、契約と責任範囲を決めてから、検証・移行・運用引き継ぎへ進むのが全体の流れです。この順に進めると、導入後も自社で管理しやすくなります。

発注形態、RFPと契約、費用、委託先の選び方を、発注の順に並べました。全体像は、IaaS開発の完全ガイドにまとめています。

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

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

IaaSの発注・外注の範囲

IaaSの発注・外注では、仮想サーバーに加えて基盤設計やアプリ開発も依頼します。さらに、移行や監視、障害対応まで委託する場合もあります。OSやミドルウェアを利用者側で設計する範囲が広いため、クラウド契約と開発・運用委託は分けて考えます。

IaaS・PaaS・SaaSの外注範囲

IaaSでは仮想マシン、ストレージ、ネットワークを借りて、その上のOSやアプリ、データ、権限を自社か委託先が設計します。

• IaaS：既存のWindows Serverや特殊なミドルウェアを維持する場合に使います。
• PaaS：実行環境やデータベース運用の一部を、サービス側に任せる形です。
• SaaS：完成した業務機能を使い、標準的な業務を導入する形です。

業務単位で使い分けると、発注する範囲を絞り込めます。

責任共有モデルの発注書への記載

発注書には、設定担当だけでなく、継続運用や契約終了時までの役割も書き分けておきます。

• クラウド事業者：データセンターや物理ホストの安全を担います。
• 利用者側：OSパッチやIAM、ネットワーク、鍵、ログ、復旧確認の責任は、自動では負ってもらえません。
• 運用分担：設定・月次確認の担当、障害の一次切り分けを何分以内に始めるか、データ返却形式を決めます。
• 監視範囲：IPAの2025年資料はAPI操作、IAM、ネットワーク、ワークロード内の挙動を分ける考え方を示します。

セキュリティは、納品時の設定で終わらせず、運用の中で確かめ続けます。

発注形態の選び方

まず、クラウドの契約先と、設計・開発・運用の担当会社を一社にまとめるか、役割ごとに分けるかを決めます。そのうえで、自社が担える作業を一覧にし、委託する範囲を絞ります。

一括発注の特徴と責任窓口

一括発注では、責任の窓口を一つにまとめられます。その反面、委託範囲と見積条件の線引きが曖昧になりやすいため、RFPで委託範囲、提案条件、見積の内訳を明記しておきます。

• 委託範囲：要件定義、設計、開発、移行、テスト、監視、運用引き継ぎ。
• 適した企業：担当者が少ない企業や、停止できない業務システムを初めてクラウドへ移行する企業。
• 提案条件：成果物、前提、除外作業、再委託範囲。
• 見積の内訳：クラウド利用料と委託費を分ける。

分離発注による専門性と価格の比較

分離発注では、各社の専門性や価格を比べやすくなります。一方で、役割ごとに委託先が分かれるぶん、調整上の注意点もあります。

• 委託先の分担：基盤、アプリ、監視運用を別会社に任せる。
• 専門性に合わせる：クラウド移行、業務アプリ、24時間監視を各社に割り当てる。
• 障害時の注意：ネットワーク、OS、アプリの境界で対応が止まることがある。
• 統括と連携：内製チームが全体を統括できる場合に適します。SLA、エスカレーション、ログ共有も契約します。

構築と運用を段階的に分ける方法

構築と運用の委託方法には、内製へ戻す形と、段階的に引き継ぐ形があります。

• 構築後に内製化：構築だけ外注し、安定後に運用を自社へ戻す。
• 段階的に移管：初期の運用を委託し、後から自社へ引き継ぐ。

移行直後は障害や問い合わせが増えやすいため、まず引き継ぎ期間と手順書の完成条件を決めておきます。あわせて、教育の回数と権限移管の日も決めます。

運用を始める条件は、復旧訓練とバックアップ復元を終えた状態にします。さらに、監視アラートと月次報告の確認まで済ませておくと、引き継ぎ後の不安を減らせます。

RFPと要件整理の進め方

RFPは、提案依頼先に同じ前提で提案してもらうための文書です。細かな製品名は先に指定せず、目的や性能、移行期限を示します。加えて、データや運用体制、予算も示し、構成を提案する余地を残しておきます。

現行環境が分からないままだと、各社は異なる前提で見積もります。そのため、価格の差が技術の差なのか前提の違いなのか、判断しにくくなります。

現行資産と移行対象の洗い出し

現行調査では、機器構成と業務条件を一覧にします。この情報をそろえておくと、RFPの前提を合わせやすくなります。

• サーバー情報：名前、OS、CPU・メモリ、ディスク容量、DB、ミドルウェア、ライセンス。
• 連携と稼働：外部連携、固定IP、バッチ、利用時間、月間転送量。
• 業務条件：停止可能時間、繁忙期、同時利用者数、保存年数、情報の機密性。

古いOSやサポート切れのミドルウェアは、単純移行ではなくアップグレードや再設計が必要になります。そのため、RFPの前提として記載しておきます。

調査を委託する場合は、調査の成果物と、その後の設計・移行の作業を分けて提示してもらいます。

非機能要件の数値による定義

非機能要件として、可用性や性能、拡張性を整理します。さらに、バックアップや災害対策、運用性も、数値で示せる形にします。

「止まらない」のように言い切るより、数値の指標で決めておくと、各社の提案を比べやすくなります。

• 可用性・復旧：月間稼働率、復旧時間目標のRTO、復旧時点目標のRPO。
• 性能・運用：ピーク時応答時間、ログ保存期間、脆弱性対応期限。
• 災害対策：複数AZ、バックアップ世代数、リージョン障害への備え。

災害対策の設計は、利用料と構築費を左右します。規制のある業種では、自社の基準もRFPに含めておきます。

参考として、IPAの2026年度クラウド調達資料には、国内データ所在地や国内リージョン、ログ保存の要件があります。ISO/IEC 27001・27017・27018やISMAPも挙げられています。

RFPの成果物と提案条件の明記

RFPに記載する項目と提案条件をそろえると、各社の提案を比較しやすくなります。

• 依頼内容：背景、目的、範囲、現行環境、業務・非機能要件、日程、体制。
• 契約と評価：提出物、評価基準、契約期間、予算。
• 成果物：設計書、構成図、IAM設計、IaCコード、テスト計画、移行・運用手順書、障害連絡網、教育資料。
• 見積条件：利用料の算定条件、初期構築費、移行費、月次運用費、保守対象外、追加変更の単価。

この形にそろえると、作業範囲の狭い見積と必要な作業を含む見積を、同じ条件で見比べられます。

IaaS外注の契約形態

契約は、仕様がどこまで確定しているかと、発注者側の管理体制で選びます。IaaSでは、移行テストのあとに追加作業が見つかることもあるため、調査・要件定義、構築・移行、運用保守を分けると、各段階の判断を次の契約に反映できます。

請負契約が向いている工程

請負契約は、合意した仕事を完成させて成果物を引き渡す契約です。設計が確定したあとの環境構築、IaCコード作成、移行ツール開発などは、請負に向いています。

検収基準には機能テストに加えて、復元確認や最小権限の確認を含めます。さらに、監視通知や性能試験、移行リハーサルも対象に入れます。

仕様変更や納期遅延時の連絡、第三者サービスの料金変動は、誰が負担するかを明記します。

準委任契約が向いている調査・支援・運用

準委任契約では、専門家が善管注意義務を負いながら、調査や助言、設計支援を担います。管理や監視運用も、この契約で担う作業です。具体的には、現行調査やクラウド選定、RFP作成支援が対象になります。移行計画や月次運用、障害時の技術支援も含まれます。

契約では、時間単価や月額の範囲、対応時間を決めます。加えて、報告の方法や未消化時間、休日対応を確認します。再委託の条件と、発注者の判断遅れによる日程への影響も合意しておきます。

運用保守のSLAと責任の区分

まず、監視時間が24時間365日か平日日中かを確かめ、通知時間や復旧・原因調査の料金も確認します。クラウド障害と委託先の監視やバックアップの不備では責任が異なるため、SLAの対象を分けます。

定常作業とスポット作業を分けると、請求を予測しやすくなります。スポット作業には、更新や脆弱性対応、構成変更が含まれます。性能改善や環境追加なども、これに当たります。

IaaSの発注・外注費用の相場

IaaSの費用は、クラウド利用料と、設計・構築、移行に分けて考えます。運用保守や改善、追加開発も、別に見ておく必要があります。

利用料にはVMのほか、ディスクやバックアップ、ロードバランサーが加わります。さらに、パブリックIPv4やログ、転送も上乗せされます。サポートやOS・DBのライセンスも、費用に含まれます。

サーバー一台の月額だけを見て発注すると、冗長化や監視を加えた段階で予算を超えやすくなります。

小規模構成のクラウド利用料の目安、月額1万〜15万円程度

開発・検証環境と本番環境では構成が異なり、月額費用も変わります。

• 開発・検証：小型VM1〜2台、少量ストレージ、最低限のログで月額1万〜5万円程度。
• 小規模本番：Web・AP・DB、バックアップ、監視、LBやWAFを含み月額3万〜15万円程度。
• 冗長化などを追加：複数AZ、DB冗長化、専用線、転送、24時間運用で月額20万〜100万円以上の場合があります。
• 大規模構成：高トラフィック、GPU、複数リージョンでは月額100万円を超える可能性があります。
• AWS EC2 T3：掲載価格は機種ごとに異なります。

AWS掲載価格はt3.nanoが1時間あたり0.0052米ドル、t3.microが0.0104米ドル、t3.smallが0.0209米ドルです（出典：Amazon EC2 T3インスタンス料金表、2026年確認）。730時間稼働し、1米ドル150円で換算すると、VM本体は月約570円、約1,140円、約2,290円です。

この金額は、一般的な構成をもとにした推定で、保証された価格ではありません。また、AWS公式は転送やEBSなどの関連費用も案内しています。

為替やリージョン、税は請求額を左右します。OSライセンスや割引も関わるため、VM本体の計算額は、全体の見積の一部として扱います。

初期構築・移行費の幅、100万〜2,000万円以上

初期費用の目安は、規模と移行条件で変わります。一般的な検討の幅は、次のとおりです。

AWS事例では、川崎市が基幹20業務をカバーする13システムの移行を進めています。2025年度末を見据えて、2023年度から基本設計を始めました（出典：AWS「川崎市」導入事例、公開情報確認）。

• 小規模な新規環境：要件整理、ネットワーク、IAM、監視、バックアップ、テストを含み100万〜500万円程度。
• 複数サーバーの移行：500万〜2,000万円程度。
• 基幹系など：再構築、段階移行、複数拠点、災害対策、24時間運用を含み2,000万円〜1億円以上の場合があります。

この金額は、一般的なSI作業量などから置いた推定で、公的に決まった相場ではありません。調査の範囲や移行量によって変わり、テスト回数や停止時間、ライセンスも費用に響きます。

小規模な新規環境や単純移行は4〜10週間、中規模移行は3〜9か月が目安です。

基幹系や複数リージョンの再設計は6〜18か月以上かかることがあります。業務標準化、データ移行、関係部署の合意形成も期間を左右します。

月次運用費と隠れコストの分け方

月次費と別料金になりやすい作業を分けて確認します。見積では、各項目を次のように整理します。

• 月次費に含まれることがある作業：監視、通知対応、バックアップ確認、パッチ、アカウント・脆弱性対応、報告、問い合わせ。
• 別料金になりやすい作業：環境追加、構成変更、性能改善、原因調査、データ復旧、移行リハーサル。
• 年間作業：大規模更新、証明書更新、監査、復元試験、障害対応も、年間の作業として見込みます。
• 割引条件：プランごとの割引率と、その利用条件の違い。

Savings Plansはオンデマンド料金から最大72％、スポットは最大90％割引の場合があります（出典：Amazon EC2料金ページ、2026年確認）。

ただし、利用期間や中断の許容度が割引プランに合うかを、あわせて確かめる必要があります。

委託先の選定と見積比較の観点

委託先は、知名度や認定数より、同規模や同じOS・DB・業界での経験を見ます。さらに、移行後の体制や障害対応、成果物の品質も確認します。

クラウド事業者と、実装・移行・運用を担う会社は分けて評価します。そのうえで、設計書やIaCコードの所有者を確認します。障害時の連絡や切り戻し、追加作業への対応についても、質問しておきます。

類似条件による実績の確認

「AWSに強い」「Azureに対応できる」という説明より、似た案件の中身を見るほうが適合性を判断しやすくなります。

• 業務と規模：似た業務、利用者数、データ量の案件があるか。
• 条件の近さ：可用性、OS、連携、セキュリティ基準が近いかどうか。
• 担当者の関わり：担当予定者がどの工程に参加したか。公開できない業界では、匿名化した構成や課題、方式で確かめます。期間と体制も聞いておきます。
• 委託先チームの品質：大規模案件の実績があっても別に確認が必要です。責任者、設計者、移行・運用の担当の役割を明確にしてもらいます。

同じ前提による見積の比較

各社の見積は、サーバー数や稼働時間、容量を同じ前提でそろえます。ログや通信量、冗長化の条件も、そろえておきます。監視やサポートも、同じ条件に合わせます。為替や税、割引も、同じ前提で比べます。

見積では、利用料と設計、構築、移行を別行にします。テストや教育、月次運用、追加変更も、それぞれ独立した行で示してもらいます。バックアップや監視の有無も確認します。

3年程度のTCO（総所有コスト）を、初年度の構築・移行費と、2年目以降の利用料・運用費、定期改善費に分けると、抜け漏れを見つけられます。

成果物の所有権と契約終了時の移行

将来ほかの会社へ引き継げるよう、成果物と管理の範囲を契約で定めておきます。

• 成果物の範囲：設計書、構成図、IaCコード、CI/CD、監視、ログ、バックアップ。
• アカウントと秘密情報：所有権と利用権、保管場所、更新責任を契約に記載する。
• 終了時の手続き：返却の形式、アカウント移管、削除証明、引き継ぎ日数を決めておく。
• 納品条件：標準形式の資料と再現可能なIaCを含めると、特定ベンダーへの依存を避けられます。

IaaSの発注から稼働までの流れ

発注後は、要件定義、基本・詳細設計、構築の順に進みます。そのあと、移行、テスト、リリース、運用引き継ぎへと続きます。

不確実な構成は、小さな検証環境で先に確かめておきます。アプリの稼働や性能、移行の停止時間、バックアップからの復旧を、早い段階で確認します。

現行調査と小さな技術検証

構成図と実際の通信、バッチ、権限を照合します。ライセンスや障害履歴も、同じように突き合わせます。

資料だけでは分からない依存関係もあるため、ログや設定を調べたうえで、アプリや業務の担当者にも聞き取ります。

最小構成の環境で、接続や認証、性能を試験します。バックアップや監視、データ移行も、同じ環境で試しておきます。早い段階で要件を見直せば、本番後の手戻りを抑えられます。

本番前の移行リハーサルと切り戻し

本番移行での停止や手戻りを防ぐため、実施手順と事前に決める条件を整理します。

• 移行作業：抽出、変換、転送、整合性・接続確認、利用者受け入れ試験。
• 停止時間：実データに近い容量と処理時間で検証する。
• 切り戻し：失敗時の条件、旧環境の保持期間、リリース判断者、告知時期を手順書に記載する。
• テストと検収：機能、性能、障害、セキュリティ、復元、監視通知を試験し、証跡を残す。

運用開始後の確認項目と引き継ぎ

運用状況を把握して改善を続けられるよう、定期確認や報告、契約更新時の評価項目を引き継ぎます。

• 定期確認：アラート、バックアップ、脆弱性、パッチ、コスト、性能、アクセス権。
• 月次報告：利用料、稼働状況、障害、問い合わせ、変更、次月リスク。
• 構成の見直し：AWS、Azure、Google Cloudの機能・料金更新に応じ、サイズ、停止時間、割引、マネージドサービスを検討する。
• 契約更新：運用実績と改善案を評価し、監視代行だけで終わらせない。

よくある質問

発注前に多い質問を、クラウド利用料と外注費、RFP、内製と外注の境界について並べます。

IaaSの開発は自社だけで発注できますか？

発注はできますが、ネットワークやIAM、バックアップを設計できる体制が必要です。監視や移行、障害対応も含めて、体制を考えます。クラウド操作の経験は、判断材料の一つにすぎません。

社内に運用担当がいれば、調査や構築だけを外注して、運用は内製で行えます。

迷う場合は、まず要件定義と技術検証を依頼してから、範囲を決めます。

IaaSの月額料金だけで予算を決めてもよいですか？

予算は、月額料金に加えて、TCO（総所有コスト）で判断します。そこには、設計や移行、運用保守、バックアップ、ログが含まれます。転送やサポート、ライセンス、追加変更も、あわせて入れます。

平常時とピーク時を分け、3年程度の利用料と委託費を試算します。料金変動や障害対応の条件も確認します。

委託先に見積を依頼するとき何社に声をかけますか？

前提がそろっていれば、異なる強みを持つ3社前後が比較しやすい目安です。ただし、社数よりも、要件や成果物、運用時間、クラウド条件をそろえることを優先します。

移行や業務アプリ、運用に強い候補を含めます。価格のほか、担当者の経験や、どこまで受け持つかという責任の区分、引き継ぎやすさ、提案の透明性も評価します。

ISMAPや国内リージョンはすべての企業に必要ですか？

必要かどうかは、業界の規制と取引先の要求で変わります。政府・自治体や医療、金融の企業では、所在地や国内リージョンを確認します。

• 対象の情報：個人情報や機微情報を扱う企業。
• 確認の項目：監査ログ、認証、契約管轄。

デジタル庁は2026年にもISMAPリストを更新しました。また、IPAの資料も、国内所在地やログ、ISO認証、ISMAPを扱っています（出典：デジタル庁・IPAの2026年公開資料）。

業界の規制と取引先の要求を整理して、必要な範囲だけをRFPに含めます。

まとめ

IaaSの発注では、IaaS・PaaS・SaaSの役割を整理して、自社と委託先の担当範囲を決めます。そのうえで現行環境を調べ、可用性や性能、RTO・RPOをRFPにまとめます。

• その他の要件：セキュリティ、所在地、運用時間も、RFPに含めます。

構築には請負、調査や運用には準委任など、作業に合う契約を選びます。そのうえで、利用料と設計、移行、運用、追加変更を分け、公式料金とSI費用を比べます。

類似実績や障害対応、成果物の権利、契約終了時の引き継ぎを確認して委託先を決めると、自社で管理しやすいIaaS基盤につながります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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