PaaS開発の発注は、業務要件と委託範囲を決め、契約形態を選んだうえで、段階を踏んで開発と運用へ進めていく流れです。この流れで進めると、想定外の追加費用を抑えやすくなります。
発注形態、要件整理と契約、費用の目安、委託先の選び方の順に見ていきます。
▼全体ガイドの記事
・PaaS開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
PaaS開発の発注・外注の基本
PaaS開発では、AWS Elastic Beanstalk、Azure App Service、Google App Engineなどを基盤として選びます。HerokuやOracle APEXなども、基盤の例にあたります。そのうえで、業務アプリを設計・開発・運用する作業を専門会社へ依頼します。
PaaS事業者と開発会社は、別の役割を担います。そのため、サービス提供者、実装担当、保守担当それぞれの責任を分けて整理しておきます。
PaaSの仕組みとアプリ開発への集中
PaaSでは、物理サーバーや仮想化基盤のほか、OSやランタイム、一部のミドルウェアもクラウド事業者が管理します。そのぶん、発注者と開発会社は、業務ロジックや画面、データモデルなどアプリ側の作業に集中しやすくなります。
- 新規サービス：業務アプリの新規開発に使える場面。
- 社内業務：申請・承認や在庫照会に使える場面。
- 業務アプリ：顧客ポータルや拠点間のデータ連携に使える場面。
テストや監視、バックアップ復元も、発注者側と委託先のどちらが担当するかを、あらかじめ決めておきます。ただし、PaaSを使っても、運用責任がなくなるわけではありません。
アプリの脆弱性、IAM権限、秘密情報は、利用企業または委託先が担います。データ分類、API認可、ログ確認、復旧手順も、同じ担い手が受け持ちます。
IPAの「情報セキュリティ10大脅威 2026」も、クラウド契約時の責任範囲、停止時の代替策、仕様変更後の設定確認を示しています（出典：IPA、2026年）。
外注と相性がよい企業と向かないケース
外注が合うかどうかは、社内の人材や立ち上げ時期によって変わります。アクセスの変動や性能要件、移行条件も判断材料になります。自社の状況を、次の観点で確かめます。
- 外注向き：社内のクラウド設計人材が少ない企業です。
- 短期立ち上げ：業務アプリを早く立ち上げたい企業です。
- 繁閑差がある：アクセスが時期によって増減する企業です。
Excelや古い個別システムを整理し、会計・販売・ERPは残したまま、申請やポータルから刷新する方法もあります。
特定のクラウドに業務を合わせられない場合や、特殊な性能要件がある場合には、他の方式も比べます。契約終了後に別の環境へ移す必要が高い場合は、IaaSやコンテナ基盤、SaaS、スクラッチ開発も候補になります。
まず、MUST要件とWANT要件を分け、PaaSの採用はそのあとに判断します。そのうえで、将来の移行コストも含めて方式を選びます。
PaaS開発の発注形態の選び方
発注形態は、一括請負のほかにもあります。企画や現状分析から進める伴走型、短期間で技術の実現性を確かめるPoC型、要件定義後に本開発へ移る段階型、社内チームを補う準委任型があります。
どの形が合うかは、業務ルールや意思決定者の有無、納期と予算のどちらを優先するかで変わります。
一括外注：責任窓口を一本化したい場合
要件、予算、納期、運用体制が比較的明確で、発注者側の負担を抑えたい場合は、一社への一括依頼が候補です。
一社に任せると、問い合わせ窓口が一つになり、基盤設定とアプリの不具合を切り分けやすくなります。
- 成果物：コードとリポジトリ、IaC、DB定義を明記します。
- 運用資料：API仕様、テスト結果、障害・復元手順を含めます。
- アカウント：発注者が請求と管理者権限を確認できる形にします。
PaaS利用料とクラウドアカウントの所有者は、契約で定めておきます。ソースコードや設計書、監視設定の所有者も、あわせて決めておきます。これらは、解約や委託先変更時の引き継ぎに必要です。
さらに、環境変数一覧も納品物に含めます。「アプリ一式」とまとめず、納品物を一つずつ具体的に列挙します。
PoC・段階導入：不確実性の高い案件
データ品質やAPI仕様、使いやすさ、ピーク時性能が不明な案件では、本番の完成形を一度に発注しない方法があります。そこで、2〜4週間程度のPoCで本開発の条件を合意します。PoCでは、次の点を確かめます。
- 技術確認：認証と主要画面、DB、外部APIを試します。
- 運用確認：デプロイやログ、バックアップを確かめます。
- 性能確認：簡単な負荷試験で前提を洗い出します。
PoCは、デモを作る工程ではなく、本番で困る前提条件を見つける工程です。そのため、確認項目と本開発へ進む条件は、事前に決めておきます。
段階導入では、申請や台帳、顧客ポータルなど、一つの業務から始めます。次に、利用率や処理時間、エラー率を測ります。問い合わせ件数や月額利用料も、同時に見ます。
その後、会計や販売管理との連携、他部門への展開、権限の細分化を追加していきます。MUSTを先に本番化してWANTを後へ回すと、現場で得た学びを次の要件に反映できます。
内製支援型：社内にノウハウを残したい場合
将来の改修や運用を社内で担うなら、委託範囲と発注者、開発会社それぞれの役割をはっきりさせておきます。
- 委託範囲：設計レビューとペア開発、手順整備、研修を含めます。
- 知識移転：移転の方法、コードレビュー、質問への回答期限の取り決め。
- 発注者の役割：社内で業務と受入れの意思決定者を決めます。
- 開発会社の役割：実装と専門的な助言を依頼します。
- 判断責任：決定は発注者が担います。委託先任せでは、業務との不一致が起こりやすくなります。
発注者側では、プロダクトオーナーと業務責任者、クラウド管理者を決めておきます。加えて、セキュリティ承認者と受入テスト担当も置きます。
RFPと要件整理で決めること
RFPは、各開発会社に同じ前提で提案と見積を依頼するための文書です。未確定の要件は「提案してほしい事項」と分けて示すと、各社の設計力も比べられます。
機能だけでなく、背景や対象部門、業務課題も記載します。利用者数やデータ量、ピーク時間、既存システムに加えて、連携対象と希望時期も示します。予算の考え方や運用担当、セキュリティ条件も伝えます。
現行業務とデータの発生源の洗い出し
データの発生源と更新者を特定し、入力から保存までの流れを整理します。洗い出しでは、次のような情報を対応づけます。
- 発生源：Excelや紙、会計・販売・在庫、CRM、勤怠、メール。
- 業務の流れ：入力と承認、集計、連携、訂正・削除、保存。
- 更新担当：各データを作成・変更する担当者。
在庫表示アプリなら、在庫の正本がERPか倉庫システムかを決めておく必要があります。正本が曖昧なままだと、画面を作っても数値の食い違いが残ります。
連携要件には、APIやCSV、SFTP、iPaaSなどの方式を書きます。更新頻度やタイムゾーン、文字コード、重複時の扱いも記します。
エラー通知や再送、手動補正、仕様変更時の責任者も決めておきます。また、連携一覧をRFPの別紙にしておくと、見積の抜けを減らせます。周辺システムとの連携費を見落とすことは、発注後の追加費用につながる論点です（出典：リサーチノート）。
機能要件の書き方：業務の結果と受入条件
機能名だけでなく、利用者の操作と業務上の結果を定義しておきます。受入条件には、例外処理や権限、履歴も含めます。
- 申請フロー：スマートフォンで申請し、上長が承認・差し戻しを行います。承認済みデータを会計へ送り、送信エラーを担当者へ通知します。
- MUST：認証・権限、監査ログ、バックアップ、主要連携、個人情報保護、RTO・RPOを含めます。
- WANT：高度な分析やAI候補提示、詳細なダッシュボード、複数シナリオが対象です。
優先順位と後続フェーズへ回す判断基準を決めておくと、納期と品質を守れます。
非機能要件と役割分担のRFPへの記載
非機能要件には、測定方法と許容値を定めておく必要があります。「安全に」や「止まらない」では、受入判定ができません。
- 性能・可用性：同時利用者数や応答時間、稼働時間、復旧目標。
- 保全：ログ保存期間、バックアップ頻度、監視時間帯。
- セキュリティ：所在地や暗号化、MFA、脆弱性対応。
基盤はPaaS事業者、アプリと設定は開発会社、業務データとアカウント管理は発注者が担う形を、表にまとめます。
個人データを扱う場合は、サーバーが国内にあるかどうかだけでなく、事業者の法人所在地や再委託先も確認します。加えて、アクセス権限や契約終了時の消去方法も確かめます。
個人情報保護委員会のガイドラインは、2025年12月にも一部改正されています。そこで、国外事業者の利用条件は法務担当と確かめます（出典：個人情報保護委員会、2025年12月改正）。
PaaS開発の契約形態の使い分け
クラウド利用や導入支援、準委任、請負、保守など、契約を分けることがあります。選ぶ際は会社の規模よりも、成果物の完成条件を事前に定められるかで判断します。
要件が動く工程を無理に固定価格へ押し込むと、変更費用や納期遅延が争点になります。
準委任が向く調査・要件定義・伴走支援
準委任は、専門家の作業や支援に対して、稼働時間や役務の対価を支払う契約です。要件が作業を通じて具体化していく工程に適しています。
- 調査：現状分析やRFP作成支援、PaaS比較。
- 検証：PoCや連携方式の確認。
- 伴走：アジャイル開発や社内チーム支援。
準委任では、完成機能を保証するのではなく、作業内容や担当者、稼働時間を明確にします。レビュー方法と成果物の扱いも決めておきます。
毎月残す成果物も決めておきます。要件一覧や課題管理表、設計メモ、議事録、検証結果、ソースコードなどが対象です。
発注者の意思決定が遅れた場合の影響や、作業時間の上限、担当者の交代を、契約に記します。再委託や秘密情報の扱いも、同じ契約に書いておきます。
請負：完成条件と検収方法を確定できる工程
請負は、合意した成果物を完成させ、検査・検収を行う契約です。仕様が固まり、テスト項目と合格条件を示せる本開発に向いています。
- 範囲：対象機能と対象外、前提条件、納品物を記します。
- 検収・権利：検収期限や不具合対応、知的財産権を具体化します。
一次Q&Aでは、準委任に比べて請負の見積が高くなりやすく、その差は1.3〜1.5倍程度という傾向値が示されています。ただし、これは公的統計ではなく、完成責任や仕様変更リスクを織り込む場合の目安です。価格差だけで決めず、要件の成熟度と変更管理の仕組みも比べます。
契約終了時の引き渡し条件
PaaSは特定サービスの機能やAPIに依存しやすいため、開始時に出口戦略を決めておく必要があります。終了時の条件は、次のように整理します。
- 引き渡し：返却形式や設計書・コードの所有者、移行支援時間、バックアップ消去時期を定めます。
- データ・契約：復元できる返却方法と、料金改定や規約変更、終了、リージョン障害、再委託、監査への対応。
- 保護・復旧：個人情報と秘密保持、脆弱性対応、障害連絡、保守時間、RTO・RPO、代替手順を決めておきます。
- 切り替え：手動運用へ移る条件を、受入資料と運用設計に含めます。
業務復旧は、SLAの稼働率だけでは判断できません。
PaaS開発の費用相場の目安
費用は、開発費、PaaSなどの利用料、保守・改善・セキュリティ対応の運用費に分けて考えます。公的に統一された開発相場表は少ないため、次に示すのは一次Q&Aと一般的な工数から整理した推定レンジです。
開発費：PoCから大規模開発までの幅
開発費の推定レンジは、規模と機能、連携範囲によって変わります。期間も含めて、予算の目安として見ておきます。
- PoC：100万〜300万円程度、2〜6週間。
- 小規模：300万〜800万円程度、2〜4か月。
- 中規模：800万〜2,000万円程度、4〜9か月。
- 大規模：2,000万〜5,000万円超、6〜12か月以上。
PoCは、認証と一画面、少数のAPI連携を確かめる規模です。小規模では、申請や台帳、簡易ワークフローと外部連携1〜3本を想定します。
中規模は、複数部門や権限、監査ログ、基幹連携、データ移行を含む場合があります。大規模では、多数拠点や高可用性、複雑な業務ルールに加えて、段階移行や運用設計も加わります。
仮に、エンジニア単価を月80万〜120万円程度とし、3人が4か月稼働すると、人件費だけで960万〜1,440万円程度になります。ただし、これは相場を断定するものではなく、予算検討用の試算です。
プラットフォーム利用料：構成と利用量による変動
PaaSの料金は、サービス本体と実行資源の課金方法を分けて見積もります。
- AWS Elastic Beanstalk：サービス自体に追加料金はありません。
- Google App Engine Standard：無料枠を超えると課金されます。
- Azure App Service：プランによって料金が決まります。
AWSでは、EC2やS3のほか、ロードバランサーやDB、通信にも課金されます。
主な費用はEC2インスタンスとロードバランサーで、通信量やDB・ストレージの量によっても変わります（出典：AWS公式、2026年8月確認）。
「PaaS無料」と書かれていても、料金はインスタンスや通信量、DB、ストレージの選択で変わります。そのため、請求額はアプリ全体の構成で確かめます。
公式例では、B1が1インスタンス時間あたり0.05ドル、B2が0.10ドル、B4が0.20ドルです。たとえば、B1を730時間動かす単純計算は36.5ドルになります（出典：Google Cloud公式料金、2026年8月確認）。
Azureはフルマネージド型のPaaSですが、専用レベルでは、VMインスタンス数に応じて課金されます（出典：Microsoft Azure公式、2026年8月確認）。無料枠や通信、ログ、DBやストレージ、スケール設定も、別途確かめます。
3〜5年のTCOによる初期費用と月額の比較
3〜5年分の費用は、初期開発や利用料だけでなく、環境の維持費と予備費も含めて見込み、同じ条件で比べます。
- 開発・運用：初期開発や利用料、DB、通信、監視、保守を含めます。料金最適化、脆弱性対応、追加改修、移行、社内工数も入れます。
- 環境の維持：検証環境の常時稼働やログ保存、バックアップ、NAT、WAFの費用を見込みます。
- 予備費：運用費は個別開発の初期費用に対して年15〜20％、要件追加費は初期見積の10〜20％を置く考え方もあります。
運用費は、保守の範囲や対応時間によって変わります。そのため、月額が安い案と運用負担が小さい案を、同じ条件で比べます。
補助金は、交付決定前の契約や対象外のクラウド費用に注意が必要です。そのうえで、補助金なしでも継続できるTCOで判断します。
PaaSの委託先選定と見積比較のポイント
委託先は、知名度や総額だけでなく、業務システムを運用できる体制で選びます。PaaS事業者と認定パートナー、SIer、ローコード支援会社では、得意領域が異なります。
候補は2〜3社に絞り、同じRFPとサンプルデータをもとに、提案とデモ、PoC、見積を比べます。こうすると、価格の前提がそろいます。
実績の確認：PaaS利用歴から業務成果まで
クラウドの利用歴だけでなく、担当範囲や類似する業務事例、導入後の成果を確認します。
- 担当範囲：要件定義や業務設計、API連携、移行、テスト、研修、保守を聞きます。
- 類似事例：複数拠点や権限、承認、ERP、個人情報、ピークアクセスの経験を確かめます。
- 導入成果：利用率や処理時間、運用工数、障害対応の変化を、匿名で示してもらいます。
Google CloudのJALインフォテック事例では、オンプレミスの刷新と生成AI導入を一度に全面置換せず、Lift & Transformで段階的に進めています。
そのうえで、PaaS案件でも移行方式と既存資産の扱いを説明できる会社を評価します。さらに、コンテナやサーバーレスの適用範囲と人材育成も確かめます（出典：Google Cloud公式ブログ、2025年1月公開）。
見積書の分解と比較：工程・工数・前提条件
見積には、工程別の工数や単価、担当ロールを記載してもらいます。期間や成果物、対象外、利用料の扱いも、示してもらいます。
- 設計・開発：要件定義、基本・詳細設計、画面・API。
- 環境・連携：PaaS構築やCI/CD、認証、外部連携。
- 移行・定着：データ整備、移行、テスト、研修。
- 管理・保守：進行管理、保守、成果物と対象範囲。
API連携は「一式」とせず、接続先や取得頻度、認証、エラー再送、相手側の仕様変更への対応を明記します。
安い見積では、要件定義や監視、バックアップが対象外になっている場合があります。脆弱性診断や並行稼働、データ整備、料金最適化が含まれていないこともあります。
一方で、高い見積には、不要な多重化や過剰なKubernetes構成が含まれている可能性もあります。価格差は、機能や品質、体制、前提の違いに分けて質問します。
運用・セキュリティ・出口戦略の最終比較
最終比較では、運用体制、セキュリティ、契約終了後の引き継ぎを一体で確認します。
- 運用：障害連絡先や一次切り分け、復旧目標、定期報告、ログ監視、復元テストの取り決め。
- 安全性：脆弱性対応や料金アラート、アプリ認可と設定不備への対策の有無。
- 代替策：停止時の対応や仕様変更後の設定確認を提案できる会社を選びます。
- 出口：返却形式と費用、国内外の所在地、再委託、海外アクセス、削除証明、ログ保存期間を確かめます。
提案では、3年と5年のTCO、障害時の事業影響、委託先変更時の移行費を並べて比べます。こうすると、初期費用だけに偏らず判断できます。
よくある質問
発注時には、費用だけでなく、委託範囲や判断者、将来の運用方法も確認します。そこで、相談の前によくある質問を紹介します。
PaaS開発は内製と外注のどちらがよいですか？
クラウド設計やセキュリティ、開発、運用を担う人材と時間があれば、内製も可能です。
最初からすべてを内製する必要はありません。PaaS選定や初期設計、PoC、セキュリティレビューを外注し、運用と改修を段階的に内製へ移す方法もあります。
判断の基準は、初期費用だけでなく、継続して障害対応と改善を行える体制があるかどうかです。
RFPが完成していなくても開発会社へ相談できますか？
相談できます。業務フローや課題、対象部門を整理できれば、RFP作成支援や現状分析から依頼できます。既存システムと希望時期、予算上限も、分かる範囲で添えます。未決事項は、相談の中で一緒に整理できます。
見積を公平に比べる段階では、利用者数や連携対象、必須要件、運用条件をそろえます。また、初回相談は、要件の抜けを見つける場として使います。
PaaSの月額利用料だけで開発費も含まれますか？
通常は含まれません。PaaS利用料は、実行基盤やDB、ストレージ、通信、ログ、監視などのクラウド費用です。
一方で、要件定義や設計、実装、移行、テスト、保守は、開発会社の費用に当たります。初期費用や月額利用料、年額保守、追加改修、料金変動条件は分けて、3〜5年のTCOで比べます。
見積比較では何社に声をかければよいですか？
初期段階では、2〜3社を比べるのが目安になります。
候補を増やしすぎると、説明や質問への対応に時間がかかり、要件整理も遅れます。
- 比較軸：PaaS候補や業務理解、RFPへの質問、提案、PoC、見積条件を比べます。
- デモ確認：同じサンプルデータと業務シナリオで依頼し、提案の差を確かめます。
- 評価範囲：価格だけでなく、体制と出口戦略も見ます。
まとめ
PaaS開発では、業務の目的と現状のデータを整理したうえで、PaaSで作る範囲と既存システムに残す範囲を決めます。SaaSやIaaSと比べる範囲も、あわせて定めます。
RFPには、機能に加えて、連携や権限、性能を記します。ログやバックアップ、データ所在地、運用責任、受入条件も、書き込みます。
契約と費用：工程と責任を分けた考え方
要件が固まらない調査やPoC、伴走支援には準委任を、完成条件を定義できる本開発には請負が候補になります。工程に合わせて、契約を選びます。
費用は、開発費、PaaS利用料、保守・改善費に分けて、初期価格ではなく3〜5年のTCOで比べます。
相場の幅は、予算検討の起点です。正式な金額は、連携数やデータ量、性能、移行範囲、運用体制を見積に反映して決まります。
同じRFPによる提案比較と出口の確認
委託先の提案は、業務改善と将来の運用を見据えて比較します。
- 評価範囲：PaaS知識や業務設計、既存連携、移行、セキュリティ、保守、内製支援を見ます。
- 比較条件：2〜3社へ同じRFPとサンプルデータを渡し、工程別見積、前提、対象外、体制を比べます。
- 継続性：障害対応、データ・設計書の返却条件を確かめます。安全な改善と将来の運用につながる発注計画を選びます。
▼全体ガイドの記事
・PaaS開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。