サーバーレスのシステム開発の発注/外注/依頼/委託方法について

サーバーレスのシステム開発は、業務を切り出して要件を整理し、RFPで条件をそろえて委託先を比べたうえで、段階的に開発・運用へ移していく流れで進めます。

この流れで進めると、要件漏れや想定外の費用を抑えやすくなります。

▼全体ガイドの記事
・サーバーレスのシステム開発の完全ガイド

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

サーバーレスのシステム発注の全体像

サーバーレスは、サーバーが存在しない方式ではありません。つまり、OSや仮想マシン、ミドルウェアの常時運用を、クラウド事業者に委ねる方式です。

一方で、発注者はアプリケーション、データ、権限、業務ルールの管理を担います。外注の成否は「Lambdaを使えるか」よりも、業務を切り出す単位と、自社・委託先の担当範囲で決まります。

サーバーレスの外注で委託する範囲

委託先には、企画支援、業務整理、要件定義を依頼できます。さらに、設計と開発、クラウド設定、テストを任せられるほか、リリースや保守運用まで依頼することもできます。

「開発一式」として頼むと、監視アラートやバックアップ方針が含まれないことがあります。また、IaCが納品されず、別の会社へ移管できなくなる場合もあります。

委託作業は、業務・アプリ、クラウド基盤、セキュリティを中心に整理します。データ移行と運用・改善を加えて、5つの領域に分けます。そのうえで、発注者の意思決定と委託先の実装・報告・障害対応も、同じ表に書き出します。

発注前のサーバーレスとの適合性

サーバーレスに合うかどうかは、業務の処理単位とアクセス量の変動を見て判断します。

• 処理単位：イベントやAPI単位に分けやすい業務が候補になります。
• 対象業務：受発注や申請・承認、予約、通知、画像・帳票生成、IoTデータ収集が例です。
• アクセス変動：閑散時の常時稼働を抑えたい場合や、繁忙期に処理能力を自動で増やしたい場合も候補です。
• 構成と開始範囲：業務に合わせて、部分導入も含めた構成を選びます。

長時間処理や常時の高負荷、複雑な分散トランザクションがある業務では、コンテナや仮想マシンとの併用が適する場合があります。特定ミドルウェアへの強い依存も、併用を考える理由になります。全面移行にこだわらず、独自性の高い機能や既存基幹の周辺から始める方法も検討します。

サーバーレスのシステムの発注形態の選び方

発注形態は、要件が固まっているか、社内にIT人材がいるか、開発後の運用を誰が担うかで選びます。

業務や品質条件がまだ整理できていない場合は、企画・要件定義を先に進め、仕様が確定してから開発を発注する二段階方式が、比較的リスクを抑えやすいです。

一括請負で開発を外注するケース

一括請負は、機能・性能・納期・成果物を仕様書などで明確にしたうえで、合意した成果物の完成を依頼する方式です。

画面数やAPI、外部連携が確定している場合は、予算と納期を管理しやすくなります。権限やログ保存、テスト条件も決まっていれば、計画の見通しがさらに立ちます。

開発中に構成やデータ設計の調整が多くなると、追加費用や仕様変更の協議も増えます。そこで、請負の範囲は確定した機能に絞り、探索的なPoCや要件整理は準委任で分ける方法があります。

準委任・ラボ型で伴走してもらうケース

準委任は、専門人材の稼働や役務の提供を受けて、発注者と委託先が一緒に進める方式です。

• 向く案件：新規業務の整理や既存連携の調査、PoC、段階的な内製化など、完成形を固定しにくい案件です。
• 進行管理：月ごとの作業、稼働上限、成果報告、会議体を決めておくと、柔軟性と予算管理を両立しやすくなります。
• 発注者の役割：機能完成を約束する契約ではないため、意思決定者とレビュー担当を置き、週次で未決事項やリスク、次の検証対象を確認します。
• 成果物：設計書やソースコード、IaC、テスト結果を受け取り、作業時間だけが費やされる事態を防ぎます。

企画・PoCと本開発を分ける二段階方式

社内に詳しい人材がいない場合は、企画・PoCで業務イベントを一つ通してみて、段階的に本開発へ進めます。

1. 数週間から数か月かけて企画・PoCを行い、業務の流れを小さく検証します。
2. 申請登録から承認通知、画像アップロードから帳票生成までなど、一連の流れを通します。
3. 機能に加えて、コールドスタート時の応答や失敗時の再実行、重複処理を確かめ、監視ログ、権限、概算利用料も見ます。
4. 成果をRFPに反映して、複数社へ本開発を依頼します。前提がそろった見積もりが集まるため、技術用語だけで評価するリスクを下げられます。

サーバーレスのシステム開発を外注する進め方

発注は、次の順に工程を進めます。

1. 業務整理
2. RFP作成
3. 提案・見積比較
4. 契約
5. 設計・開発
6. テスト
7. リリース
8. 運用移行

サーバーレスは、クラウド設定が動作や費用に直結します。そのため、アプリだけでなく、基盤と運用も同じ計画に含めます。

企画・要件定義で決める事項

要件定義では、業務の現状と、機能・非機能の条件を分けて整理します。

• 業務の前提：現状フロー、利用者、処理量、繁忙期を押さえます。そのほか、既存システム、外部サービス、個人情報の有無も確かめます。
• 機能要件：申請者と承認者、差し戻しと取消の扱い、処理結果を連携するシステムと時点を決めます。
• 非機能要件：同時利用者数、ピーク時のリクエスト数、応答時間、可用性、RTO・RPO、ログ保存期間を定めます。
• 運用・実行条件：バックアップ、データ所在地、暗号化、権限、監査証跡、障害通知を決めます。同時実行数やリトライ、タイムアウト、イベント順序、重複排除も検討します。

設計・開発での確認事項

設計・開発では、構成と環境、再現性、変更管理を一体で確かめます。

• 構成設計：API、関数、データベース、オブジェクトストレージの関係を図にします。さらに、メッセージキュー、ワークフロー、認証、監視も含めます。
• 方式の評価：公式の構成図を基に、既存要件との違いを洗い出して判断します。
• 環境の再現：Terraform、CloudFormation、BicepなどのIaCで構成を組み直せるようにし、開発・検証・本番を分けます。
• 変更と保管：CI/CD、秘密情報の管理、ロールバック、依存ライブラリの更新を決め、発注者がソースコードと設定の保管場所を確認できるようにします。

AWS公式リファレンスには、静的コンテンツ、認証、API、Lambda、DynamoDBを組み合わせる構成があります。ただし、そのまま使えるとは限らないため、既存のID基盤や業務データ、必要な整合性を先に確かめます。

テスト・リリース・運用移行での確認事項

テストでは、正常動作だけでなく、障害や非同期処理の状態も確かめます。

• 異常系：外部API停止、権限不足、タイムアウト、イベント再送・順序逆転、二重実行を試します。
• 負荷・データ：データ移行の不整合、ピーク負荷、ログ欠落を対象にします。
• 運用移行：成功・失敗・再実行の状態を、業務担当者が確認できるようにします。手順書や障害連絡先、監視も引き継ぎます。
• 検収：設計、主要機能、連携、負荷、運用移行の節目ごとに行い、本番日に一括しないようにします。

運用移行では、一次対応や復元手順、利用料の確認方法も、あわせて渡します。

RFPと要件整理で委託先に伝える項目

RFPは、開発会社から同じ条件で提案と見積もりを受けるための文書です。そのなかで、課題、期待成果、制約、予算・納期の考え方を示します。

技術方式を特定の一社に合わせて指定するより、サーバーレス、コンテナ、既存基盤を含めた選択理由を提案してもらうほうが、構成を比べやすくなります。

業務要件と対象範囲の整理

RFPでは、業務の対象範囲と優先順位、達成したい成果を書いて伝えます。

• 対象範囲：現状フロー、課題、部門、利用者を書き出します。さらに、データ、既存システム、外部連携、対象外も記載します。
• 機能の優先度：Must、Should、将来検討に分けます。たとえば、申請・承認を今回、分析ダッシュボードを将来に回せば、初期費用の膨張を抑えられます。
• 成果指標：処理時間や月末件数、手入力の削減割合、障害からの復旧時間などを定めます。
• 納品後の評価：指標がないと、動いていても業務改善につながっていないと判断される可能性があります。

非機能要件とクラウド費用の前提の整理

非機能要件と利用料は、性能や運用条件、利用量の前提をそろえたうえで依頼します。

• 要件：応答性能、可用性、障害復旧、セキュリティ、監査を分けて示します。拡張性や運用性も挙げ、通常時・月末・キャンペーン時のピークを添えます。
• 利用量：保存データ量、転送量、ログ量、バックアップ世代数を示し、初期開発費と月額クラウド費用を分けます。
• 内訳：コンピューティング、API、データベース、ストレージ、監視をサービス別に求めます。ログ、バックアップ、暗号鍵、NAT、データ転送も同じ形で求めます。
• 割引条件：無料枠や割引を前提にする場合、適用期間と終了後の金額も併記します。

成果物と提案書の提出条件

提案書の提出条件と納品物をRFPで指定しておくと、各社の回答を同じ形で比べられます。

• 提案内容：実績、採用クラウドと理由、構成図、体制、工程を求めます。加えて、リスクや初期・月額・保守費用、前提、除外事項も書いてもらいます。
• 実績の確認：業務課題、負荷変動、障害対応、運用体制まで確認し、サービス名の有無だけで判断しないようにします。
• 納品物：要件定義書、基本・詳細設計書、ソースコード、IaC、CI/CD設定、テスト仕様書と結果を含めます。
• 引き継ぎ資料：操作・運用手順書、監視設定、アカウント・権限一覧、第三者ライブラリ一覧を指定し、移管協力の範囲と費用も質問します。

契約形態とサーバーレス特有の責任分界

契約では、請負か準委任かを決めたうえで、作業範囲と成果物、検収を定めます。また、変更管理も定めます。知的財産と秘密保持、再委託は契約に含めます。さらに、保守、障害対応、終了・移管条件も記載します。

クラウド事業者の障害や仕様変更も、開発や運用に影響します。そのため、委託先が保証できる範囲と、クラウドサービスに依存する範囲を分けて記載します。

工程ごとの請負と準委任の使い分け

工程の前提と完成条件に応じて契約形態を選び、判断基準を明記します。

• 準委任：要件定義やPoCなど、前提が変わりやすい工程で使う方法があります。
• 請負：仕様と受入条件を確定させた実装や設定で使う方法があります。
• 契約条件：完了の定義、成果物の確認者、未達・変更の扱いを、契約書と個別仕様書で確認します。
• アジャイル開発：毎月のゴール、優先順位、レビュー、受入、稼働時間、品質基準を明示します。納期・予算・品質の判断も曖昧にしません。

セキュリティ・個人情報の責任分担と契約条項

OSのパッチ作業が減っても、セキュリティの責任は残ります。そのため、責任分界を契約で定めておきます。

• 残る責任：IAM、アプリの脆弱性、秘密情報、公開範囲、暗号化を分担します。ログ、監視、バックアップ、障害対応も、分けて決めます。
• 障害対応：権限の承認者、アラートの受信者、一次対応までの時間、エスカレーション条件を定めます。
• 個人データ：クラウド事業者と開発会社がデータを扱うのか、契約上アクセスしないのかを確認します。

個人情報保護委員会のQ&A 7-53では、保存データに個人データが含まれるかどうかは、第三者提供や委託に当たるかを判断する材料の一つにすぎないとされています。

もう一つの判断基準は、クラウドサービス提供事業者が個人データを取り扱うことになっているかどうかです（出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」に関するQ&A、2026年8月確認）。

発注者は、法務・セキュリティ担当と、契約条項やアクセス制御、漏えい時の連絡と報告の主体を確かめます。

知的財産と別会社への移管条件

知的財産と移管条件は、納品物、管理者、引き継ぎ方法のそれぞれに分けて定めます。

• 権利と納品：ソースコード、IaC、パイプライン、設計書、テストコード、監視設定の著作権や利用権を確認します。
• 管理者：著作権法第27条・第28条の権利、第三者ライブラリのライセンス、クラウドアカウント、ドメイン、証明書の管理者を明確にします。
• 移管条件：データ形式、構築手順、引き継ぎ期間、質問対応、移管費用、秘密情報の返却・削除を契約に含めます。

発注者名義で構築するか、委託先から移管するかによって、終了時の負担は変わります。ロックインを避けるには、特定のクラウドを避けることより、発注者が構成と運用を再現・理解できる状態にすることが有効です。

サーバーレスのシステム開発費用相場とコストの内訳

サーバーを買わずに済んでも、開発費まで無料になるわけではありません。要件定義や業務設計、画面・API開発には人件費がかかります。連携や移行、テストにも人件費がかかります。さらに、セキュリティや監視・運用設計にも、人件費が加わります。

また、クラウド利用料も別途かかります。ここで示すのは、リサーチノートの人月単価と工数をもとにした発注計画上の推定レンジで、公的な全国相場ではありません。

規模別の開発費レンジ

開発費は機能の範囲と規模によって幅があるため、機能と期間をあわせてレンジを比べます。

• 小規模PoC・MVP：ログイン、数画面、API、簡易データベース、通知を備え、200万円〜500万円程度、期間は1〜3か月が目安です。
• 小〜中規模：申請・承認、顧客や案件の管理、帳票、権限、監査ログ、外部API連携を含み、500万円〜1,200万円程度、3〜6か月程度が推定レンジです。
• 中規模：1,200万円〜3,000万円程度、6〜12か月程度を想定します。
• 大規模刷新：3,000万円〜1億円以上、12〜24か月以上になる可能性があります。

中規模は、複数部署・拠点、データ移行、複数のSaaSや基幹システムとの連携、可用性・災害対策、運用設計を含む想定です。一方で、大規模刷新は、基幹周辺の段階移行、大量データ、複数リージョン、厳格な監査、24時間運用を含む場合があります。

金額は、画面数に加えて、業務の複雑さやデータ品質、連携先数によって変わります。さらに、テストの深さや運用体制、セキュリティ水準によっても変わります。要件定義やテストを極端に少なくした見積もりは、追加費用が出やすいため、工程別の工数と前提条件を確かめます。

クラウド利用料の考え方

利用料は、Lambdaの実行条件に加えて、周辺サービスと利用規模を分けて試算します。

• Lambdaの課金：リクエスト数と実行時間を基本に課金されます。
• 単純試算：512MB・0.5秒を月1,000万回実行した場合、Lambda部分は約36.8米ドル（1米ドル=150円で約5,500円）です。
• 周辺サービス：Lambda以外のサービス利用料も、請求に加わります。
• 初期試算：PoC・小規模は月5,000円〜3万円、社内業務システムは月2万円〜15万円、中規模本番は月15万円〜80万円程度になる場合があります。

公式料金ページでは、月100万件の無料リクエストと、月40万GB秒の無料コンピューティング時間が示されています（出典: AWS「AWS Lambdaの料金」、2026年8月確認）。

請求には、API Gateway、データベース、S3などのストレージ、CloudFront、CloudWatchも加わります。さらに、暗号鍵やバックアップ、NAT、データ転送も請求の対象になります。

単純試算は、無料枠を差し引いたLambda部分だけを対象にした机上の計算です。円換算は1米ドル=150円で行っています。なお、月額のレンジも構成と利用量を前提にした推定で、市場統計や保証額ではありません。

開発費・利用料・運用費のTCO比較

TCOでは、初期開発費と継続費用を合算して、実際の処理量と構成をもとに判断します。

• 合算する費用：クラウド利用料や保守、監視・障害対応、脆弱性対応を含めます。さらに、バックアップや転送、追加開発、社内運用工数も加えます。
• 従量課金の変動：少ない時期は抑えやすい一方、リトライのループ、過剰なログ、不要な常時起動、転送量増加で膨らむことがあります。

AWS事例では、株式会社朝日新聞社のサーバーレス化したフロントエンドが、Amazon EC2利用時と比べ99％のコスト削減を実現したと説明されています（出典: AWS導入事例「株式会社朝日新聞社」、2026年8月確認）。

これは同社の対象システムにおける事例で、すべての業務システムに同じ削減率が当てはまるとは限りません。そのため、自社の処理量と構成で見積もる必要があります。

委託先選定と見積比較で確認すべきポイント

委託先を見るときは、資格やサービス名のほかに、業務理解、分散システム設計、セキュリティ、テスト、運用、内製化支援を評価します。

提案書の見栄えより、担当者がリスクと制約を説明でき、質問に前提を添えて答えられるかを重視します。

類似案件の実績と担当体制

類似案件では、業務の近さ、構成の分け方、運用実績を確かめます。

• 業務と構成：受発注、申請、顧客管理、画像処理、データ分析などの実績を聞き、サーバーレスとコンテナ・既存基盤の分担を確認します。
• 運用体制：負荷変動や障害への対応、運用開始後の担当範囲を確かめます。

AWS事例では、株式会社チカクが負荷変動への対応を目的に、画像・動画処理へLambdaを採用しました。その結果、管理対象のサーバー台数は従来の1割程度まで減らせたと、担当者が説明しています（出典: AWS導入事例「株式会社チカク」、2026年8月確認）。自社と負荷特性や処理、運用体制が近いかを確かめます。

見積もりの内訳と前提条件のそろえ方

見積もりは、内訳と前提を同じ粒度にそろえたうえで、複数社に確認します。

• 項目の粒度：工程、役割、工数、単価を分けて示してもらう
• 範囲の明示：成果物や前提、除外事項も、同じ形式で書いてもらう
• 工程の範囲：要件定義からデータ移行までの記載を確認する
• 費用の含有：クラウドアカウント、ライセンス、外部サービス料金が含まれるかを見る

テストは単体・結合・総合・負荷まで、リリースや運用移行も含めて見ます。3社程度に同じRFPを渡し、工数、処理件数、障害対応時間、除外作業を質問します。金額差が大きい場合は、要件、テスト、移行、保守のうち含まれない範囲を特定してから判断します。

最新機能の採用前に確認する提供条件

新機能は、発表内容と提供条件を確かめたうえで、業務要件に合う場合に採用を検討します。

• 選択肢：新機能が、実行方式の候補に加わっています。
• 提供条件：提供状況、対象リージョン、料金、上限を確認します。
• 運用と選定：監視・IaCとの連携や、担当者の運用可否を見ます。そのうえで、業務要件、TCO、可用性、移管性を満たす最小構成を選びます。

2025年11月にAWS Lambda Managed Instancesが、2026年6月にはAWS Lambda MicroVMsが発表されました。これらにより、特殊な計算資源や分離実行を、サーバーレスと組み合わせる選択肢が増えました。

MicroVMsはAWSの公式発表で、東京リージョンを含む提供地域が示されています（出典: AWS公式発表「AWS introduces Lambda MicroVMs」、2026年8月確認）。

よくある質問（FAQ）

発注時に迷いやすい費用、社内体制、既存システムとの連携を取り上げます。提案を依頼する前の確認に役立ててください。

サーバーレスのシステムは外注すると安くなりますか？

クラウド利用料やサーバー保守の一部は抑えられる可能性がありますが、外注の開発費まで自動的に安くなるとは限りません。

要件定義、業務設計、連携、テスト、監視、運用移行には、工数が必要です。そのうえで、開発費と月額利用料を分け、TCOで比べます。

小規模な会社でもサーバーレスを発注できますか？

発注できます。少人数でサーバー台数の管理やパッチ作業を減らしたい場合は、マネージドサービスを活用する価値があります。

社内に業務の意思決定者と運用責任者を置き、権限、費用、障害連絡、データ管理を確認できる体制を用意します。

既存のオンプレミスや基幹システムと連携できますか？

連携できます。ただし、接続方式、データ形式、認証、通信経路、処理順序、障害時の再送を設計する必要があります。

たとえば、通知や帳票、API、データ連携など、周辺機能から切り出す方法があります。既存基幹との境界を明確にしたうえで段階的に移行すると、リスクを抑えやすいです。

ベンダーロックインを避けるにはどうすればよいですか？

特定のクラウドを避けることより、構成を発注者が管理・移管できる状態にしておくことが大切です。

発注者名義のアカウントやIaC、ソースコード、設計書を納品範囲に含めます。加えて、テストコードや監視設定、データのエクスポート手順も対象に入れます。

発注者は、別会社への移管条件と協力費用も、契約に記載します。

まとめ

発注時は、サーバー管理の軽減に加えて、業務適合性、責任分界、開発費、利用料、運用費、移管性をまとめて判断します。

アクセス変動が大きく、イベント単位に分けられる業務は候補になります。一方で、長時間・常時高負荷の処理は、コンテナや既存基盤との併用も比べます。

発注前の最終チェック

発注前には、対象業務と対象外の範囲を確認します。機能は、Must、Should、将来機能に分けて整理します。そのうえで、ピーク処理量と性能・可用性、RTO・RPOも確かめます。

そのほか、個人情報とアクセス権、開発費と月額費用を確かめておきます。成果物と検収、保守・障害対応も、あわせて確認します。さらに、ソースコードとIaCの所有・移管条件も確かめます。

これらをRFPに反映して3社程度へ依頼すると、価格だけでなく提案の違いも比べられます。

小さな業務単位からの相談

全社の基幹システムを一度に刷新せず、申請・通知・帳票・画像処理など一つの業務イベントを題材にします。そのうえで、PoCや要件整理を依頼する方法があります。

技術が動くか、運用できるか、費用が許容範囲に収まるかを確かめてから本開発へ進むと、自社に合う発注につながります。

▼全体ガイドの記事
・サーバーレスのシステム開発の完全ガイド

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