クラウド移行支援システム開発の発注/外注/依頼/委託方法について

クラウド移行支援システムの発注は、現行環境を調査し、要件と責任分界を決めてから、段階的に移行する順に進めると、費用や障害のリスクを抑えやすくなります。

発注形態、RFPと契約、費用と委託先の選び方、移行後の進め方の順に見ていきます。全体像は完全ガイドもご覧ください。

▼全体ガイドの記事
・クラウド移行支援システム開発の完全ガイド

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

クラウド移行支援システムの発注で最初に決める事項

クラウド移行支援は、オンプレミスや既存ホスティング、別のクラウドの業務システムを移す支援サービスや構築プロジェクトです。移行先には、AWS、Microsoft Azure、Google Cloud、国内クラウドなどがあります。

「移行」を、物理サーバーのコピーだけの意味で使う場合もあります。ただし、発注の範囲は移行後の運用まで広げて定めます。業務継続、データ整合性、セキュリティも、この範囲に含めて考えます。

基盤移行にとどまらない委託範囲

発注範囲は、現行資産を洗い出すところから移行後の保守まで、工程ごとに区切って定めます。

• 現行調査：サーバーやOS、DB、ミドルウェア、ネットワークなどの基盤を洗い出します。ライセンス、連携、バッチ、帳票、バックアップも確認します。
• 基盤設計：アカウントやネットワーク、IAM、監視とログ、バックアップ、災害復旧環境を組み立てます。
• 移行と運用：データ移行、性能・セキュリティテスト、切り替え、ロールバック、保守までを一つの工程として進めます。

サーバーを移す会社と、業務アプリまで移行できる会社とでは、対応できるリスクが違います。特に、販売管理や会計などの基幹システムでは、DBの互換性と夜間バッチの順序を確かめる必要があります。そのうえで、他システムとの連携や停止時間まで対応できる会社を選びます。

発注前に決める目的と成功条件

移行後に何を改善したいのかは、KPIとして数字にしておきます。保守終了への対応や設備投資の抑制などが、目的の例です。

• 運用負担：月次の運用作業を何時間減らすかを定めます。
• 復旧時間：復旧目標時間を何時間以内にするかを、目標に置きます。
• 環境準備：新しい環境を何日で用意できるかを、基準にします。

目的には、拠点間接続の改善やBCPもあります。開発環境の準備時間を縮めることや、将来のデータ活用を挙げる場合もあります。

目的が曖昧なままだと、A社はリホスト、B社はアプリ改修を含むモダナイズという前提になり、見積条件がずれます。

そこで、業務ごとに残すか、廃止するか、移行するかを分けます。移行と同時に改修するものも分け、条件をそろえます。

クラウド移行支援システムの発注形態の選び方

発注形態は、移行対象と要件がどこまで決まっているか、発注者側のプロジェクト管理力、切り替えの難しさで選びます。

すべてを一社に任せる方法が、常に適切とは限りません。一方で、調査後に構築・移行を発注する二段階方式も有効です。

要件と成果物が決まっている場合の請負契約

請負契約は、合意した成果物を完成させて検収を受ける発注形態です。納品物と検収基準を決められる工程に向いています。

• 成果物：設計書、構成図、IaCコード、移行手順書、テスト結果、運用設計書を定めます。
• 検収条件：移行対象や停止時間、性能、バックアップからの復旧を、受け入れの基準として書きます。
• 変更手続き：対象外作業の追加見積もりと、納期変更のルールを契約に盛り込みます。

現行調査の前に全工程を固定価格で請け負うと、前提にない費用や仕様変更が発生しやすいため、範囲はアセスメントと要件定義の後に確定させます。

調査や伴走支援における準委任契約

準委任契約は、専門家が一定の業務を遂行する形態です。作業時間や知識の提供が中心で、完成条件を固定しにくい業務に向いています。

• 調査・評価：現行資産の洗い出し、移行方式の評価、RFP作成支援を任せます。
• 伴走・管理：技術調整、プロジェクト管理、運用設計を、継続して頼みます。

準委任は完成条件を固定しにくいぶん、細かな取り決めが欠かせません。稼働時間や役割、報告方法を先に決めます。意思決定者や作業場所、再委託の可否も、あわせて定めます。

準委任でも、判断者や資料の更新時期、問題発生時に何時間以内に報告するかまで具体化すれば、責任の所在をはっきりさせられます。

発注者側の担当者が足りない場合は、PMO支援を別枠で契約する方法もあります。

アセスメントと移行実行を分ける二段階発注

初めての移行では、第一段階で調査と計画をまとめ、第二段階で設計・構築・移行を発注すると、比較しやすくなります。

• 第一段階：現行調査、移行方式、概算費用、リスク、ロードマップを作成します。
• 第二段階：調査成果を使い、設計、構築、移行を複数社から比較します。

有償アセスメントでは、対象サーバー台帳や依存関係図、方式候補を納品物にします。概算TCOや未解決リスク、次工程のRFP案も、あわせて受け取ります。一方で、無料相談だけでは、深い依存関係や性能を確認しきれない場合があります。

RFPと要件整理の進め方

RFPは、提案を依頼する先に、現状と目的、対象範囲を伝える資料です。制約や納品物、評価方法も、同じ資料に書きます。

機能要件に加えて、停止許容時間やデータの所在を、同じ書式で示します。さらに、セキュリティや運用体制、責任分界も書きます。こうすると、提案内容と見積金額を比べやすくなります。

現行資産と移行制約の一覧

資産台帳には、性能や依存関係、運用情報を含めます。制約一覧には、停止条件や社内規程を書き込みます。

• 資産：サーバー名や役割、OS、DB、ミドルウェアを書きます。CPUやメモリ、容量、増加量も、あわせて記載します。
• 利用状況：稼働時間や利用者数、ピーク負荷、保守期限、ライセンスを押さえます。
• 連携・運用：API、ファイル、帳票、バッチを挙げます。監視や認証、手作業、障害手順も含めます。
• 移行制約：停止時間、RTO（目標復旧時間）、RPO（目標復旧時点）、繁忙期、法令・社内規程を整理します。
• 環境条件：国外リージョン、閉域接続、認証方式、予算上限、希望時期を決めます。

制約が抜けていると、後から専用線や冗長構成が追加になり、当初の見積もりと差が出るおそれがあります。

RFPに書く移行後の運用と検収基準

要求項目は工程ごとに整理し、必須と希望、提案に委ねる要件を分けておくと、提案の過不足を判断できます。

• 工程：現行分析、選定、基本・詳細設計、構築、改修、移行を、一つずつ分けます。テスト、教育、切り替え、並行運用、保守も、別の工程として扱います。
• 移行当日：手順、切り替え判定、切り戻し条件、データ整合性、障害連絡を定めます。
• 成果物と評価：設計書やIaCの範囲、引き継ぎ可否、評価配点を示します。

評価では、費用に加えて、移行実績や体制、提案の具体性を見ます。運用設計やロックイン対策も扱います。

6Rを基準にした移行方式の比較

業務ごとに方式を選び、比較表で費用や期間、リスクを確認します。将来の変更しやすさも、あわせて見比べます。

• リホスト：既存環境をほぼそのまま移し、短期間で進めます。
• リプラットフォーム：OSやDBをマネージドサービスへ置き換え、運用負担の軽減を目指します。
• リファクタリング：クラウド向けに作り替えます。効果が大きい一方、設計・テスト工数が増えます。
• その他：SaaSへのリパーチェス、現状維持のリテイン、廃止のリタイアも検討します。

全面刷新を同時に行うと、要件が膨らみ、納期と費用が読みにくくなります。そこで、保守終了が迫る場合は、先にリホストなどで安定させ、後から段階的にモダナイズする方法があります。

クラウド移行の契約で確認すべき責任分界とリスク

クラウド事業者が基盤を管理していても、利用者側の設定やデータ、運用は、自動では安全になりません。IAMやOS、アプリ、バックアップも、利用者側で確かめる範囲に入ります。そのため、クラウド事業者と移行SIer、発注者の責任分界は、図にして確かめます。

契約書で具体化する成果物、変更、SLA、再委託

対象のシステムとデータ、作業の場所と時間、納期を、契約書・仕様書に記します。納品物や検収、瑕疵対応、変更管理も、同じ書面に記します。

• 運用条件：受付時間、対応レベル、一次回答時間、復旧目標、計画メンテナンスを定めます。
• 報告：障害報告や月次報告の内容を、SLA・運用仕様書に記載します。
• 追加費用：データ量超過、OS変更、連携判明、切り替え延期時の再見積条件を決めます。

再委託と秘密保持、知的財産も、契約で定めます。データの返却・削除や契約終了時の引き継ぎも、あわせて決めておきます。

変更要求は、影響範囲と金額、納期を書面に残します。承認者も、あわせて記録しておきます。

個人データ、再委託先、リージョンの契約前確認

個人情報などを扱う場合は、保存場所や安全対策を契約の前に確かめます。

• 保護対象：個人情報や顧客機密、マイナンバー、決済情報の扱い。
• 管理策：権限、暗号化、ログ、バックアップ、脆弱性対応、事故通知の取り決め。
• 契約・所在：再委託先、リージョン、削除証明、データセンター所在地を確かめます。

個人情報保護委員会のQ&Aでは、事業者が個人データを扱うか、利用者だけがアクセスする保存領域かで、第三者提供や委託の整理が変わると説明されています。そのため、法務や情報セキュリティの部門と、契約内容を確認します。

政府・自治体案件や高い安全性が求められる業務では、ISMAP登録や監査報告書、障害通知の期限も評価します。

IPAが2026年に公開した中小企業の情報セキュリティ対策ガイドライン第4.0版は、クラウドの安全利用、バックアップ、サプライチェーン対策を整理しています。認証の有無に加えて、自社のリスクに必要な管理策を委託先へ質問します。

クラウド移行支援システムの費用相場と期間

費用は、サーバーの台数だけでなく、改修やデータ量、停止許容時間によって変わります。冗長化やセキュリティ、ネットワークの条件も、費用に関わります。さらに、移行後の運用の範囲も、金額を左右します。

ここに挙げる金額は、公開価格や類似案件に基づく目安です。個別の確定価格ではないため、移行作業費とクラウド利用料を分けて比べます。

規模別の初期費用の幅

改修や可用性の要件が増えるほど、初期費用と期間は上がります。下の4区分は、その違いを規模で分けた目安です。

• 単純移行：PoCや1〜2台のリホストは30万〜150万円程度、2週間〜2か月が目安です。
• 標準規模：数台〜十数台の社内業務システムやWebアプリは300万〜1,000万円程度、2〜6か月が目安です。
• 複数業務：連携を伴う販売・在庫・会計は1,500万〜4,000万円程度、6〜12か月が目安です。
• 大規模：複数拠点、高可用性、アプリ再設計を含むと4,000万円から数億円まで上振れします。

NTT東日本は2026年3月に「パブリッククラウドの導入費用は？」を公開し、最小構成は初期数十万円・月額数万円からとしています。また、標準構成については、初期300万〜1,000万円・月額30万〜100万円程度と紹介しています。

これはクラウド導入全般の目安で、業務アプリの改修や大規模なデータ移行は、追加の作業として見込みます。

公開価格の作業範囲の読み方

公開料金は、含まれる作業と発注者側の負担を踏まえて比べます。

• ヒアリング・構成図：IIJのAzure向け支援では25万円です。
• 5台までの移行：Azure Migrateを使う支援は120万円です。
• 追加サーバー：6台目以降は1台7万円です。

これは、仮想サーバー移行をパターン化したベーシックプランの例です。アプリ改修や複雑なネットワークは含まれず、全面的な移行計画や24時間運用も対象外です。

出典はIIJ「クラウド移行 – IIJクラウドインテグレーションソリューション for Microsoft Azure」です（確認日2026年8月）。

対象台数や移行ツール、作業場所を確かめます。発注者の作業や切り替え担当、監視設定も確認します。そのうえで、OS設定変更や利用者調整など、社内の工数も予算に含めます。

月額費用と二重稼働を含めた5年TCO

月額費用は、利用料だけでなく、接続やサポートなどの費用も含めて見る必要があります。

• 利用料：仮想サーバー、DB、ストレージ、バックアップ、ログ、監視を含めます。
• 接続・サポート：データ転送、VPN・専用線、サポート、セキュリティ費用までが対象です。
• 移行期間：旧環境を止められない場合は、新旧の月額費用が重なります。

判断は、初期費用と利用料、社内の運用工数を合わせた5年TCOで行います。保守費や二重稼働費も、そこに加えます。

期間の目安は、アセスメント2〜6週間、設計・構築1〜3か月、検証・並行運用1〜3か月です。

AWSの事例では、2名のチームが社内ポータルと基幹システムを合計2週間で移行しました。また、OSレイヤーの運用工数を9割以上削減しています（出典：Amazon Web Servicesブログ「アーベルソフト様のAWS事例」、2025年12月公開）。これは、対象を絞り、知見のあるチームが進めた事例なので、一般的な納期の保証とは分けて見ます。

委託先選定と見積比較のポイント

委託先は、知名度や資格の数だけでなく、実績と体制で評価します。実績は、自社に似た業務や規模、移行方式のものを見ます。説明の透明性と移行後の運用力も、判断材料になります。

得意分野は、基盤構築か業務アプリかで異なります。ネットワークやセキュリティも、会社ごとに差があります。そのため、RFPに沿って比べます。

見積書の工程、前提条件、対象外の比較

工程ごとの作業量と前提、対象外を同じ条件で並べると、追加費用の原因を把握できます。

• 工程別費用：調査や要件定義、設計、構築、改修、移行を分けます。テスト、教育、切り替え、並行運用、保守も、別に示します。
• 作業条件：人数、時間、サーバー数、データ量、テスト・切り替え回数、休日対応を確認します。
• 前提と対象外：資料提供、OS設定変更、データクレンジング、利用者テストを書きます。契約やライセンス、専用線、現地作業も明記します。

「移行一式」「管理費一式」のように一括で書かれると、会社間の比較が難しくなり、追加費用が生じることがあります。バックアップ設計、DRサイト、脆弱性診断が対象外なら、別費用かどうかと時期を確認します。性能改善や旧環境の撤去、移行後の教育も、対象外かどうかを確かめます。

実績の担当範囲と成果の確認

自社に近い案件の条件と、実際に担当する人の経験を確認します。

• 案件条件：業務、台数、データ量、停止時間、方式、アプリ改修を確かめます。
• 実施内容：テスト、運用体制、発生した問題と対策を聞きます。
• 担当者：可能であれば、提案責任者、実際のPM、設計担当者との面談を設けます。

AWS、Azure、Google Cloudなどの基盤提供者と、移行や業務システム開発を担うパートナーは分けて評価します。

さくらインターネットは2025年8月、条件付きで12か月間の利用料を20％割り引く法人向けキャンペーンを公表しました。さらに、先着20社へのITインフラアセスメントも公表しました（出典：さくらインターネット「クラウド移行支援キャンペーン」、2025年8月）。適用条件や期間は変わることがあるため、通常契約の費用と支援範囲も確認します。

ロックインと移行後の運用負担

独自サービスは運用を簡素化する一方、他クラウドへの移行や内製化を難しくする場合があります。

• 引き継ぎ資料：構成図、設計書、IaC、監視・バックアップ設定、手順を納品物に入れます。
• データ移管：エクスポート方法と契約終了時の引き渡しを確認します。
• 料金管理：通常時、繁忙期、障害時の3パターンで試算します。バックアップ保持、ログ保管、転送も、その計算に入れます。

移管できる情報を残しておくことが、事業継続の備えになります。マルチクラウドそのものを目的にするより、こちらを優先します。

予算アラートやタグの使い方、不要リソースの停止、予約・割引プランの検討方法も確かめます。料金上昇の原因を説明できる会社は、安い見積もりだけの会社より長期的な委託先として信頼しやすくなります。

発注後のクラウド移行を失敗させない進め方

移行は、リスクの低い対象からウェーブに分けて進めます。まず開発環境やファイルサーバーで手順を検証し、その後は連携が少ない業務へ広げます。最後に、停止の影響が大きい基幹・決済へ進めます。

小さな対象での性能・権限・復旧の検証

パイロットでは、技術面と現場業務の両方を検証します。

• 技術検証：通常・ピーク性能、権限、データ件数、バッチ、帳票、外部連携を確認します。
• 復旧検証：バックアップや復旧、監視通知を試し、RTO・RPOと判断手順を確かめます。
• 業務検証：締め処理、承認、検索、CSV出力、取引先連携を利用者が試します。

技術者の確認に頼ると、締め処理や承認など、現場の重要な操作が抜けることがあります。そのうえで、結果を記録し、本番設計と見積条件を直します。受け入れテストのシナリオと合格条件は、RFPや契約の段階で合意しておきます。

切り替えと切り戻しの判断基準

切り替え当日の担当と作業、切り戻しの条件を、時系列で決めます。

• 実施計画：日時、停止告知、最終バックアップ、同期、担当、確認項目を定めます。
• 連絡体制：問い合わせ窓口と経営層への報告を決めます。
• 切り戻し：重大エラー件数、判断時刻、旧環境の保持日数を具体化します。

並行運用には、クラウド利用料と旧環境の保守費がかかります。データ同期や二重入力の費用も、あわせて生じます。

並行運用の期間は、短すぎると検証不足になり、長すぎると費用と運用負担が増えます。そこで、業務の重要度と更新頻度から、並行運用の方式を選びます。

移行後のFinOpsと運用引き継ぎ

稼働後は、定期的に見直す項目を決めておきます。

• FinOps：料金と性能、障害を見ます。権限やバックアップ、ログ、脆弱性も確認します。
• 費用抑制：不要環境の停止、タグ、予算アラート、保持期間を見直します。
• 運用報告：前月比、予算差異、改善提案を月次報告に含めます。
• 引き継ぎ：構成図や設計書、アカウント・権限一覧、監視の設定を用意します。障害・復旧手順や変更履歴、連絡先、契約情報もそろえます。

内製化する場合は研修と演習を行い、委託先しか復旧できない状態を避けます。保守を続ける場合も、権限を洗い出し、改善の範囲を見直します。

よくある質問（FAQ）

発注では、費用だけでなく、委託範囲や契約、切り替え、運用も確かめる必要があります。

クラウド移行支援システムの発注費用はどのくらいですか？

小規模な単純移行は30万〜150万円程度、標準的な社内業務システムは300万〜1,000万円程度が目安です。

さらに、複数業務やアプリ改修を伴う基幹系は1,500万〜4,000万円程度、大規模・高可用性案件は4,000万円から数億円まで幅があります。

これらは公開情報や類似案件の目安です。個別の見積もりでは、対象台数や停止時間、データ量、運用範囲をそろえる必要があります。

RFPがない状態でも移行会社へ相談できますか？

相談できます。提案の精度を上げるには、サーバー台帳や構成図、データ量、連携先を整理します。停止可能時間やRTO・RPO、予算上限、希望時期も、あわせて伝えます。

資料が足りない場合は、現行アセスメントとRFP作成支援を先に委託します。その成果物を使えば、本番移行の相見積もりを取れます。

移行会社を選ぶときに一番見るべきポイントは何ですか？

自社に近い業務・規模・方式の実績と、実担当者の体制を確認します。金額以外にも、改修や移行、テスト、切り替え、保守の責任範囲を比べます。さらに、対象外作業や引き継ぎ、クラウド料金の試算方法も、比較の項目に加えます。

業務を止めずにクラウド移行できますか？

可能ですが、停止時間を短くするほど、事前同期や並行運用、冗長構成、段階切り替えの設計と検証が必要になり、費用も増えやすくなります。

データ同期や最終バックアップ、切り戻し条件、利用者への周知を計画します。パイロットで実現性を確かめてから、本番日を決めます。

まとめ

発注では、現行調査から運用までを一つの計画にまとめます。そのなかで、業務連携やセキュリティ、テスト、切り替えを、それぞれ対象に入れます。

要件が固まった工程は請負、調査や伴走支援は準委任に向きます。判断材料が足りない場合は、アセスメントを先に行えます。

費用の目安は、小規模で30万〜150万円程度、標準規模で300万〜1,000万円程度、複数業務の基幹系で1,500万〜4,000万円程度です。

公開価格や個別事例、類似案件からの推定は、分けて読みます。そのうえで、工程と前提、対象外、利用料、5年TCOを比べます。さらに、責任分界や成果物、移行後の支援も比べます。

▼全体ガイドの記事
・クラウド移行支援システム開発の完全ガイド

▼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を創業。