サーバーレスシステムの発注は、業務のイベントとデータの流れを整理し、PoCで不確かな点を確かめてから、契約範囲と納品物、運用への移管までを合意して進めます。
契約範囲や納品物、運用移管まで合意しておくと、障害時にも業務を継続しやすくなります。全体像は、下に挙げた完全ガイドもご覧ください。
▼全体ガイドの記事
・サーバーレスシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
発注前に知るサーバーレスシステムの全体像
サーバーレスシステムは、物理サーバーや仮想マシンの台数、OSのパッチ適用、キャパシティの確保を利用企業が直接管理せず、クラウドのマネージドサービスで動かします。
ただし、サーバー自体は存在します。インフラの運用責任を、クラウド事業者側へ寄せる考え方です。
サーバーを管理しないことと、サーバーがないことの違い
代表的な構成は、Web画面、API Gateway、関数実行基盤の組み合わせです。
これにデータベースやオブジェクトストレージ、キューやイベントバスが加わります。
認証や監視・ログも、構成に含まれます。
AWSでは、AWS Lambda、Amazon API Gateway、Amazon DynamoDBを組み合わせます。
Amazon S3、Amazon SQS、Amazon EventBridgeも候補になります。
Azureでは、Azure Functions、Storage、Service Busを組み合わせ、Application Insightsなども使います。
発注時には、業務イベントを起点に、どのデータをどの処理へ渡すかを示しておきます。たとえば、申請フォームの登録を起点に、承認者へ通知し、承認結果を販売管理システムへ連携します。
- 処理の流れ：APIや非同期処理へ渡すデータとイベント
- 運用設計：再実行や権限設計を含む処理方法
向いている業務と、採用を慎重に考える業務
サーバーレスが合う業務と慎重に考えたい業務は、負荷の変わり方と処理の条件で分かれます。
- 適する業務：注文受付、ファイル変換、定期バッチ、通知、IoT処理、SaaS連携
- 変動する業務API：低負荷時は処理能力を抑え、繁忙時は自動で増やせる
- 併用を検討する業務：常時稼働、低遅延、長時間処理、特殊なミドルウェア
- 既存基幹業務：DBとの結合が強い場合は、コンテナやマネージドVMも候補になります
負荷特性とデータ整合性を中心に、復旧目標や社内の運用体制も発注条件に含めて判断します。
サーバーレス開発の発注形態の選び方
業務整理から相談するなら準委任、新技術や費用を小さく検証するならPoC契約が向いています。また、仕様が固まった機能の納品には、請負契約を使います。
要件定義、PoC、本開発、保守を分けて発注すると、試行錯誤の範囲と納品の責任を整理しやすくなります。
一括請負で発注するケース
請負は、成果物や納期を決め、合意した仕様に基づいて依頼する方法です。
請負契約を選ぶかどうかは、予算や納期の見通しと、変更時の追加負担で判断します。
- 契約前に確定：成果物、納期、検収条件、機能範囲
- 見通しやすい点：予算と納期
- 変更時の注意：イベント、連携先、権限要件の追加は費用になりやすい
コールドスタートやリトライ時の二重登録のように、実装後に課題が見つかることがあります。そのため、不確かな段階では、技術検証と基本設計を先に行います。
検証で分かったことは、本契約の仕様書に反映します。
納品物には、ソースコード、クラウド構成図、IaCを含めます。
そのほか、環境変数一覧や監視設定、運用手順書も納品物に入れます。
準委任・アジャイルで発注するケース
準委任は、要件整理や設計、開発などを決めた期間と体制で任せる方法で、請負と違って完成後の動作は保証されません。進め方と定める範囲は、発注前に決めておく必要があります。
- 進め方：週次で優先順位を見直し、検証結果から次の機能を決めます
- 向く段階：要件が変わりやすい初期
- 契約上の注意：請負のように完成後の動作を保証しません
- 定める範囲：作業、時間、担当、レビュー、成果物、責任分界
作業範囲が曖昧なままだと、作業を終えても期待した機能が出来上がらないことがあります。
一次Q&Aでは、同じ内容でも請負は準委任より1.3〜1.5倍程度高い傾向が示されています。ただし、これは契約条件やリスク分担で変わる目安です。
企画・PoC・本開発・保守を分ける発注
企画や要件整理から運用保守までを、段階ごとに分けて発注する方法もあります。
- PoCの対象：代表的な業務イベントを実データに近い条件で検証
- 技術・費用：処理時間、失敗時の再実行、同時実行、月額見込み
- 運用適性：監視のしやすさと現場で使い続けられるか
発注者側でクラウドアカウントを持ち、委託先には必要な権限だけを渡しておくと、移管や利用量の確認が容易です。
委託先のアカウントを使う場合は、移行期限とデータ出力について合意しておきます。また、ドメインと証明書、ソースコードとIaCの受け渡しも合意します。
RFPと要件を整理してから外注する進め方
RFPは、開発会社に提案を依頼するための資料です。最初から分厚い仕様書を完成させる必要はありません。
背景と目的、対象業務、利用者を揃えると、各社の提案を比べられます。加えて、既存システムや希望時期、予算の考え方、提案範囲も、RFPに書いておきます。
業務フローとイベントの一覧
サーバーレスのRFPには、画面一覧に加えて、業務の開始条件と終了条件を書きます。
- イベント例：注文登録、在庫不足、担当者の承認、外部応答の失敗
- 各イベントで整理：入力、処理、出力、担当者、例外対応
- 連携方式：同期API、キュー、ワークフローの必要性
データの正本も、RFPで明確にしておきます。販売管理システムと新システムのどちらが顧客情報の正本かによって、連携方式や更新順序、重複排除の仕方が変わります。さらに、障害時の復旧手順も変わるため、正本は早めに確かめておきます。
個人情報や機密情報を扱う場合は、その分類と保存期間、アクセス役割をRFPに書きます。加えて、保管リージョンやログへ記録する情報も含めます。
数字で示す非機能要件
見積もりの前提をそろえるため、「速く」「安全に」「止まらない」といった要望は、性能や運用条件を分かる範囲で数値化しておきます。
- 性能：許容レスポンスタイム、ピークリクエスト数、同時利用者数、月間処理件数
- 可用性：目標稼働率、RTO、RPO、バックアップ世代数
- 運用：障害通知の時間帯と、未確定条件を置いた見積もり前提
未確定の項目は、開発会社に仮定を置いて提案してもらい、その前提を見積書に残します。
自動スケールでも、同時実行数やサービスクォータ、下流システムの処理能力が限界になることがあります。そのため、下流が遅いときのキュー退避や再試行回数、重複処理の防止方法も、RFPに記載します。ここが曖昧なままだと、追加の設計や費用につながります。
RFPで委託先に必ず回答してもらう項目
構成図に加えて、採用理由と代替案も説明してもらいます。クラウド名だけでは見えない設計や費用の前提を比べるため、委託先の回答は技術選定から運用・移管まで項目ごとに確かめます。
- 技術選定：AWS、Azure、Google Cloud、DBの選定理由、コンテナやVMとの境界
- 障害・性能：コールドスタート対策、再実行、監視方法
- 費用：月額試算の条件と、含むサービス
- 体制・成果物：担当、レビュー、テスト、脆弱性診断、IaC、CI/CD
- 運用・移管：引き継ぎ、保守時間、障害一次対応、契約終了時の移管
同じ質問への回答を並べると、実務能力とリスク分担の違いを見つけやすくなります。
サーバーレスシステムを外注する開発の進め方
発注後は、要件定義と基本設計から始めます。その後、PoCと本開発、テストを経て、リリースと運用引き継ぎへ進みます。
実際には、前の段階に戻ることもあります。そのため、各段階で決めること、検証内容、発注者の承認事項を区切っておきます。区切りごとに確認すると、仕様変更や品質問題を早期に見つけやすくなります。
要件定義とPoCでの小さな検証
要件定義では、業務フローと画面、APIを固めます。さらに、データと権限、外部連携、例外処理も固めておきます。
- 例外要件：タイムアウト、重複イベント、途中失敗、下流停止、権限エラー
- PoC対象：不確かな一つか二つの論点を実データに近い条件で検証
特に、注文が集中する業務では、想定ピークの負荷と、販売管理システム遅延時のキュー滞留を検証します。
画像やファイルでは、サイズ上限とウイルスチェック、再処理を確認します。保管期間やダウンロード権限も、あわせて見ておきます。
PoCの合格基準は、「動いた」だけでは足りません。応答時間と障害復旧、月額見込みで定め、運用担当者が確認できるログも基準に含めます。
設計・開発で管理するイベントとデータの境界
関数を細かく分けること自体を目標にせず、変更単位や責任範囲、データの一貫性を基準にします。
- 複数サービスの処理：状態と補償処理、再実行条件、利用者への表示を決めます
- 環境管理：Terraform、AWS CDK、AWS SAM、BicepなどのIaCで差分を管理
- 開発・リリース：レビュー、脆弱性スキャン、秘密情報、承認ルールを成果物に含めます
なお、複数サービスをまたぐ処理は、単一のトランザクションにできない場合があります。
テスト・リリース・運用引き継ぎを含む発注範囲
テストは、処理や運用まで含めて行います。画面確認だけでは、テストとして不十分です。確認する観点は、品質、障害対応、データ・イベントです。
- 品質：単体、API結合、権限、負荷の各テスト
- 障害対応：障害注入、バックアップ復旧、ログとアラート
- データ・イベント：移行照合、二重処理、順序逆転、同じメッセージの複数受信
リリース前には、切り戻し方法とメンテナンス時間を読み合わせます。
連絡網や監視画面、一次対応も、あわせて確認します。
AWS公式のサーバーレス事例では、LambdaとAPI Gatewayを使ったフロントエンドで、EC2と比べて99％のコストを削減した例が公開されています。
ただし、これは固有の構成と利用状況による結果です。自社のリクエスト数や転送量を前提に、データベースとログの分も含めて試算します。
契約形態と納品物でトラブルを防ぐポイント
サーバーレスでは、アプリケーションのコードだけでなく、クラウド上の設定と運用知識もシステムの一部です。
契約書には、作るものと管理するアカウント、保守範囲を具体的に記載します。
契約終了時の引き渡しも、記載の対象です。
ソースコード以外の納品物の定義
受入後に別の会社へ引き継げるよう、納品するものの一覧と受入基準を契約で定めます。
- 設計・開発：ソース、テストコード、IaC、API仕様、データモデル、イベントスキーマ
- 環境・運用：構成図、環境別設定、CI/CD、監視、アラート、バックアップ、復旧・運用手順
- 所有情報：管理者アカウント、ドメイン、証明書、暗号鍵、秘密情報の所有者
クラウド設定がコード納品の対象外になっている場合や、監視が別料金になる場合は、契約前に確認します。
独自サービスを使う場合は、データの出力形式と代替構成も記録しておきます。そうしておくと、将来の移行費用を見積もりやすくなります。
保守・障害対応の受け持ち範囲
保守契約では、対応条件と、どこまでを誰が受け持つかを具体的に決めておきます。
- 対応条件：営業時間、障害の重要度、一次回答時間、復旧目標
- 作業範囲：クラウド障害時の連絡、ログ調査の範囲、軽微な改修
- 継続するリスク：IAMの過剰権限、公開API、依存ライブラリ、秘密情報の漏えい
OSパッチ作業が減っても、アプリの脆弱性や個人情報のログ出力は残るため、保守対象から外しません。
AWSのサーバーレスアプリケーションレンズは、セキュリティを5つの領域で整理しています。具体的には、アイデンティティとアクセス管理、検知、インフラ保護です。残りは、データ保護とインシデント対応です（出典：AWS Well-Architected Serverless Applications Lens、2026年確認）。
委託先には、最小権限と暗号化、監査ログについて説明してもらいます。
脆弱性対応や、事故時の報告と証跡保全の方法も、あわせて説明してもらいます。
クラウドアカウントとデータの所有権
アカウントの所有者によって、請求確認や契約終了時の移行条件が変わります。
- 発注者が所有：請求と利用状況を自社で確認し、必要なIAM権限だけを付与
- 委託先が所有：請求内訳、サポート、リージョン、バックアップ、解約時の移行を明記
- 個人情報を扱う場合：再委託、保管地域、権限、ログ保存期間、事故報告期限を確認
発注者が所有する場合は、管理者権限の利用記録も残しておきます。
IPAの「中小企業の情報セキュリティ対策ガイドライン第3.1版」は、クラウドの安全利用を確認する土台になります（出典：IPA、2026年確認）。
サーバーレスシステムの費用相場と見積もりの内訳
サーバーレスの費用は、開発費とクラウドの月額利用費を分けて考えます。
開発費は画面数だけでは決まらず、業務ルール、認証・権限、既存システム連携で変わります。データ移行やテスト、監視も費用に影響します。加えて、セキュリティや運用引き継ぎも、金額を左右します。
クラウド利用費には、関数の実行に加えて、API、DB、ストレージが含まれます。ログや監視、バックアップ、データ転送も、利用費の対象になります。
規模別に見る開発費のレンジ
開発費の目安は、2025〜2026年時点の企画用の数字で、開発規模によって100万円前後から4,000万円以上まで幅があります。
- PoC・単機能：APIや簡易バッチを含め100万〜300万円
- 小規模：認証やファイル保管を含む業務Web/APIで300万〜800万円程度
- 中規模：複数業務と外部SaaS連携を含み800万〜2,000万円
- 基幹連携・段階移行：1,500万〜4,000万円以上の場合があります
- 発注時：下限だけで予算を組まず、前提別に見積もりを取ります
これは、サーバーレス開発に限った公的な市場統計ではなく、企画段階で使うレンジです。NotebookLMの一次Q&Aにある業務システムのスクラッチ開発費などをもとにしています。
参考情報には、月60万〜120万円程度の人月単価、サーバーレスの構成要素、公開事例が含まれます。要件や移行の範囲、可用性と監査条件によって、金額は変わります。
構成要素ごとに見る月額のクラウド費用
企画用の運用費は、規模や可用性といった条件ごとに、次のとおり試算します。
- 検証・小規模：月0.5万〜5万円
- 中規模業務API：月5万〜30万円
- 可用性・監視・転送量が大きい本番：月30万〜100万円以上
- 追加要素：コールドスタート対策の費用
この数字は、AWSの無料枠と従量課金の考え方、類似システムの費用データに基づく企画用の推定です。ベンダーの確定見積もりではありません。
AWS Lambdaは月100万件の無料リクエストと40万GB秒の計算時間を無料枠として案内しています（出典：AWS Lambda料金、2026年8月確認）。
DBの常時稼働やNAT Gateway、ログは別料金になる場合があります。WAF、転送、サポートも、別料金になることがあります。
Azure FunctionsのFlex従量課金では、実行時間と、常時使用可能なインスタンスを見積もります（出典：Microsoft Learn、2026年確認）。
見積書で確かめる前提条件
見積書は、作業項目ごとに分かれていても、含む範囲と対象外の作業が読み取れなければ、前提を比べられません。
- 見積もり内訳：担当人数、期間、工程、機能、外部サービス、テスト環境
- 移行・運用：データ移行、監視、文書、保守
- 追加になりやすい項目：API調査、マスターデータ整形、移行リハーサル
- 受入・稼働：受入テスト支援、リリース立会い
「一式」が多い場合は、何が含まれるかを質問します。PoCや監視、バックアップが除外されていると、稼働後の総額が上がる可能性があります。障害対応やコード引き渡しも、除外されていないかを確かめます。
初期費用とクラウド月額、保守月額を分けます。年次のセキュリティ費も含め、3年間の総保有コストで比べます。
委託先選定と相見積もりで比較するポイント
委託先は、クラウドの認定数やサービス名だけでは決めません。
業務要件や既存連携を理解する力、障害設計と利用量に応じた費用管理の力を確認します。加えて、運用引き継ぎの力も見ます。
大規模SIer、クラウド専門会社、小規模な専門会社では、得意な案件が異なります。まず、自社の規模と必要な伴走範囲を決めておきます。
公開事例と担当者の経験
公開事例は、自社に近い案件かどうかを見ます。公開できない案件については、どう説明されるかも確かめます。
- 事例の近さ：業務、データ量、ピーク特性、規制要件
- 経験の説明：匿名化した構成、担当範囲、課題、障害や費用増への対応
- 面談参加者：営業、設計責任者、運用担当者
- 設計力：下流上限、キュー、リトライ、監視、復旧の具体性
AWS、Azure、Google Cloudのいずれか一つに詳しいこと自体は問題ありません。ただし、得意な技術に寄せて、要件に合わないサービスを提案していないかは確かめます。
実装を担当する人が、発注者の業務を自分の言葉で説明できるかも見ておきます。
同じ条件と評価軸で比べる相見積もり
同じRFPを2〜3社に渡し、回答期限と質問方法を揃えます。
回答は、提案、品質・運用、費用の3つの観点で、同じ評価軸に並べます。見積もりの前提が明確かどうかも、そこで確認します。
- 提案：業務理解、具体性、要件定義、技術構成、PoC
- 品質・運用：テスト、セキュリティ、保守、納品物、契約条件
- 費用：初期費用、月額費用、3年間の総額と見積もり前提
価格差が大きいときは、工数単価よりも、機能の抜けやテスト範囲を確かめます。
保守時間やクラウド費用の扱いも確かめます。
本開発のみの見積もりと、PoCや移行リハーサルを含む見積もりは、そのままでは比べられません。
提案内容を同じ粒度に揃え、差分を発注者側の意思決定事項として記録します。
避けたい提案と発注者側の注意点
利点だけを強調する提案では、価格や性能、安全性を言い切る表現が使われがちです。
- 価格の断言：「必ず安い」と条件を示さない
- 性能の断言：「すべて自動でスケールする」と制約を示さない
- 安全性の誤認：「セキュリティはクラウド任せ」と説明する
- 採用判断：採用しない場合や代替案も説明できる会社を選ぶ
サーバーレスでも、脆弱性や過剰な権限、公開設定は起こり得ます。さらに、ログへの個人情報の混入や費用超過も起こり得ます。
発注者側は、MUSTとWANTを分けておきます。そのうえで、必須機能を先に本番化し、分析画面や自動化は次の段階へ送れます。
変更表には、理由と影響、追加工数を記録します。
納期や月額費用、承認者も記録し、予算超過を抑えます。
よくある質問（FAQ）
発注や外注を検討する企業から多い質問に回答します。
費用や技術だけでなく、契約前の確認事項も扱います。
サーバーレスシステムの開発費はいくらですか？
開発費は規模と既存システムとの連携の範囲によって大きく変わるため、企画段階の目安を4つの区分に分けて示します。
- PoCや単機能API：100万〜300万円
- 小規模業務Web/API：300万〜800万円
- 中規模：800万〜2,000万円程度
- 既存基幹との複雑な連携や段階移行：1,500万〜4,000万円以上の場合があります
金額は、要件や連携、移行によって変わり、公的な固定相場ではありません。監視やセキュリティの条件でも金額は変わるため、同じRFPで複数社から前提付きの見積もりを取ります。
サーバーレスなら外注費も必ず安くなりますか？
サーバー運用やピーク用の余剰リソースは減らせる一方で、イベント設計には工数が必要です。そのため、外注費が必ず安くなるとは限りません。
ほかにも、次の作業で工数がかかります。
- 分散したログの監視、リトライ、データ整合性：設計工数が必要
- クラウドサービス間の連携：工数がかかる
判断するときは、開発費とクラウド利用費を分けて見ます。そのうえで、3年間の総額と社内で削減できる運用工数を合わせて判断します。
既存システムをすべてサーバーレスへ移行する必要がありますか？
既存システムは段階を踏んで少しずつ移すため、効果が高く切り離しやすい部分から、PoCで負荷と整合性を確かめながら範囲を決めます。
- 最初の移行：効果が高く切り離しやすい新規APIや通知、ファイル処理、バッチ
- 既存システムとの接続：販売・在庫・会計システムとは、APIやキューでつなぐ
- 範囲の判断：PoCで負荷と整合性を確かめ、月額や運用体制も見て決める
サーバーレス開発会社を選ぶときの最重要ポイントは何ですか？
業務要件と運用を、クラウド名より先に設計できるかを確認します。
公開事例や担当者の経験を比べ、PoCや監視、障害対応も見ます。
IaCやコードの納品と契約終了時の移管、3年間の総額も、同じ条件で比べます。将来も発注者が管理できる提案かどうかを見極めます。
まとめ
発注前に揃える業務と費用の前提
業務イベントとデータ、既存連携を、RFPに整理します。ピーク負荷やセキュリティ、運用体制も、同じRFPに書き込みます。開発費と月額は分けて、契約範囲や見積もり前提も確かめます。
将来の運用と移管まで見据えた委託先の選び方
委託先は、価格や技術名だけでは比べ切れません。運用を誰が担うか、契約終了後に別会社へ移せるかまで見ます。
- 運用：監視・障害対応を担う体制
- 成果物：IaC、コード、データを受け取れること
- 所有権：クラウドアカウントの管理者
- 移管性：別会社へ引き継げる成果物と手順
対象業務イベント、データ、運用担当を整理し、企画やPoCは準委任、仕様確定後の納品は請負など段階に合わせます。
RFPには、業務フローや連携、ピーク負荷、RTO・RPOを記載します。セキュリティと月額予算、テストも書きます。さらに、監視やIaC、コードとデータの所有権も含めます。
3年間の総額は、API、DB、ストレージを含めて比べます。ログや転送、保守の費用も、総額に含めます。そのうえで、障害対応と自社管理を支える委託先を選びます。
▼全体ガイドの記事
・サーバーレスシステム開発の完全ガイド
▼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を創業。