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

サーバーレスのシステムを発注・外注するなら、クラウドサービスの選定だけでなく、業務範囲、責任分界、運用費、成果物を先に定義してから委託先を比較することが重要です。

サーバー管理を減らせるという理由だけで依頼先を決めると、要件漏れや想定外のクラウド料金、引き継げない構成が発生する可能性があります。この記事では、発注形態の選択、RFPと要件の整理、契約形態、費用相場、委託先の選び方、見積比較、検収と運用移行までを、業務システムの発注担当者向けに順を追って解説します。

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

サーバーレスのシステムを発注する前に知っておきたい全体像

サーバーレスはサーバーが存在しない方式ではなく、OSや仮想マシン、ミドルウェアの常時運用をクラウド事業者に委ね、発注者がアプリケーション、データ、権限、業務ルールを管理する実行方式です。したがって、外注の成否は「Lambdaを使えるか」よりも、業務をどの単位で切り出し、どこまでを委託先に任せ、どこからを自社で運用するかで決まります。

委託先に依頼できる範囲は、企画支援、業務整理、要件定義、アーキテクチャ設計、アプリケーション開発、クラウド設定、テスト、リリース、保守運用まで広がります。発注時に「開発一式」とだけ書くと、例えばAPIは作られていても監視アラートやバックアップ方針が含まれない、IaCが納品されず別会社へ移管できない、といった認識差が起きやすいです。

最初に、委託先へ任せる作業を「業務・アプリ」「クラウド基盤」「セキュリティ」「データ移行」「運用・改善」に分けます。そのうえで、発注者が担う意思決定と、委託先が担う実装・報告・障害対応を表にしておくと、見積もりの前提と契約の責任分界がそろいます。

サーバーレスと相性がよいのは、受発注、申請・承認、予約、通知、画像や帳票の生成、IoTデータ収集など、イベントやAPI単位に処理を分けられ、アクセス量が時間帯や季節で変動する業務です。アクセスが少ない時間帯に常時稼働のサーバーを持ち続けたくない場合や、繁忙期だけ自動で処理能力を増やしたい場合に効果を検討しやすいです。

一方、長時間処理、常時高負荷、複雑な分散トランザクション、特定ミドルウェアへの依存が強い業務は、コンテナや仮想マシンとのハイブリッド構成が適する場合があります。全面的にサーバーレスへ寄せることを前提にせず、独自性の高い機能だけを切り出す、既存基幹の周辺から始める、といった発注単位を検討することが安全です。

サーバーレスのシステムの発注形態はどれを選びますか？

発注形態は、要件が固まっているか、社内にIT人材がいるか、開発後の運用を誰が担うかで選びます。結論として、業務や品質条件が未整理なら企画・要件定義を先行して委託し、仕様が固まってから開発を発注する二段階方式が、サーバーレス案件では比較的リスクを抑えやすいです。

一括請負は、発注者が求める機能、性能、納期、成果物を仕様書や要件定義書で明確にし、委託先が合意した成果物を完成させる方式です。画面数、API、外部連携、権限、ログ保存、テスト条件まで確定している場合は、予算と納期を管理しやすい方法です。

ただし、サーバーレスでは開発途中にサービス構成やデータ設計を調整することがあります。変更が多い段階で一括請負にすると、追加費用や仕様変更の協議が増えます。請負にする範囲は確定した機能に限定し、探索的なPoCや要件整理は準委任で分ける方法も有効です。

準委任は、専門人材の稼働や役務の提供を受け、発注者と委託先が一緒に要件や実装を進める方式です。新規業務の整理、既存システムとの連携調査、PoC、段階的な内製化など、完成形を最初から固定しにくい案件と相性がよいです。月ごとの作業内容、稼働上限、成果報告、会議体を定義しておけば、柔軟性と予算管理を両立しやすいです。

一方で、準委任は機能完成を約束する契約ではないため、発注者側にも意思決定者とレビュー担当が必要です。週次で未決事項、リスク、次の検証対象を確認し、設計書、ソースコード、IaC、テスト結果を成果物として受け取る運用にすると、作業時間だけが消費される事態を防ぎやすいです。

サーバーレスに詳しい人材が社内にいない場合は、最初から本番システム全体を発注せず、数週間から数か月の企画・PoCで一つの業務イベントを通す方法が現実的です。例えば、申請登録から承認通知まで、画像アップロードから帳票生成まで、といった一連の流れを小さく検証します。

PoCでは、機能が動いたかだけでなく、コールドスタート時の応答、失敗時の再実行、重複処理、監視ログ、権限設定、概算利用料を確認します。PoCの成果をRFPに反映して本開発を複数社へ依頼すると、見積もりの前提がそろい、技術用語だけで提案を評価するリスクを下げられます。

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

発注の進め方は、業務整理、RFP作成、提案・見積比較、契約、設計・開発、テスト、リリース、運用移行の順に区切ります。サーバーレスはクラウドの設定変更がアプリの動作や費用に直結するため、アプリ開発だけでなく、基盤と運用を同じ計画に含めることが大切です。

最初に、対象業務の現状フロー、利用者、処理量、繁忙期、既存システム、外部サービス、個人情報の有無を整理します。機能要件は「申請できる」だけでなく、誰が申請し、誰が承認し、差し戻しや取消をどう扱い、処理結果をどのシステムへいつ連携するかまで書きます。

非機能要件には、同時利用者数、ピーク時のリクエスト数、目標応答時間、可用性、RTO・RPO、ログ保存期間、バックアップ、データ所在地、暗号化、権限、監査証跡、障害通知を含めます。サーバーレスでは同時実行数、リトライ、タイムアウト、イベント順序、重複排除なども検討対象です。

設計では、API、関数、データベース、オブジェクトストレージ、メッセージキュー、ワークフロー、認証、監視の関係を図にします。AWSの公式リファレンスでは、静的コンテンツ、認証、API、Lambda、DynamoDBを組み合わせる構成が紹介されていますが、公式構成をそのまま採用すればよいとは限りません。既存のID基盤や業務データ、必要な整合性に合わせて設計を評価します。

開発会社には、コンソール上の手作業ではなく、Terraform、CloudFormation、BicepなどのIaCで環境を再現できる状態を求めます。開発・検証・本番の環境分離、CI/CD、秘密情報管理、ロールバック、依存ライブラリの更新方法を決め、ソースコードと設定の保管場所を発注者が確認できるようにします。

テストは画面やAPIが正常に動くかだけでは不十分です。外部APIの停止、権限不足、タイムアウト、イベントの再送、順序の逆転、同じ処理の二重実行、データ移行の不整合、ピーク負荷、ログ欠落をテストケースに入れます。特に非同期処理は画面上で結果がすぐ返らないため、成功・失敗・再実行の状態を業務担当者が確認できるようにします。

リリース前には、運用手順書、障害時の連絡先、監視項目、アラートの一次対応、バックアップの復元手順、クラウド利用料の確認方法を引き継ぎます。検収を本番リリース日に一括で行うのではなく、設計、主要機能、連携、負荷、運用移行の節目ごとに確認すると、最後に大きな未達が残りにくいです。

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

RFPは、開発会社から同じ条件で提案と見積もりを受けるための文書です。技術方式を一社に合わせて指定するより、解決したい業務課題、期待する成果、制約条件、予算・納期の考え方を示し、サーバーレス、コンテナ、既存基盤を含む選択理由を提案してもらう方が、適切な構成を比較しやすいです。

RFPには、現状の業務フロー、解決したい課題、対象部門、利用者区分、対象データ、既存システム、外部連携、対象外の範囲を記載します。機能をMust、Should、将来検討に分けると、各社が同じ優先順位で見積もれます。例えば、申請・承認を今回の対象にし、分析ダッシュボードは将来検討と明記すれば、初期費用の膨張を抑えられます。

成果指標も具体化します。処理時間を何分以内にするのか、月末の処理を何件こなすのか、手入力を何割減らしたいのか、障害から何時間以内に復旧したいのかを決めます。成果指標がないと、納品後に「動くが業務改善になっていない」という判断になりやすいです。

非機能要件は、応答性能、可用性、障害復旧、セキュリティ、監査、拡張性、運用性に分けて記載します。アクセス数は平均だけでなく、通常時、月末、キャンペーン時などのピークを分けます。保存データ量、転送量、ログ量、バックアップ世代数も、クラウド利用料を左右する前提です。

見積依頼では、初期開発費と月額クラウド費用を別欄にします。月額費用は、コンピューティングだけでなく、API、データベース、ストレージ、監視、ログ、バックアップ、暗号鍵、NAT、データ転送をサービス別に示してもらいます。無料利用枠や割引を前提にする場合は、適用期間と終了後の金額も併記します。

RFPには、提案書に含める項目も指定します。会社や担当者の実績、採用クラウドと選定理由、システム構成図、開発体制、工程、リスク、初期費用、月額費用、保守費用、前提条件、除外事項をそろえて提出してもらいます。サーバーレスの実績は、サービス名の羅列ではなく、業務課題、負荷変動、障害対応、運用体制まで確認します。

納品物には、要件定義書、基本・詳細設計書、ソースコード、IaC、CI/CD設定、テスト仕様書と結果、操作・運用手順書、監視設定、アカウントや権限の一覧、第三者ライブラリ一覧を含めます。将来別会社へ移管する可能性がある場合は、移管時の協力範囲と費用もRFP段階で質問します。

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

契約では、請負と準委任の違いを理解し、作業範囲、成果物、検収、変更管理、知的財産、秘密保持、再委託、保守、障害対応、終了・移管条件を定めます。サーバーレスはクラウド事業者の障害や仕様変更も影響するため、委託先が保証できる範囲と、クラウドサービスに依存する範囲を分けて書くことが重要です。

要件定義やPoCのように前提が変わりやすい工程は準委任、仕様と受入条件を確定した実装や設定は請負、という分け方が一例です。ただし、契約名だけで判断せず、何をもって業務が完了したとするか、成果物を誰が確認するか、未達や変更をどう扱うかを契約書と個別仕様書で確認します。

アジャイル開発を採用する場合も、毎月のゴール、優先順位の決め方、レビュー、受入、稼働時間、品質基準を明示します。柔軟な開発を理由に、納期、予算、品質の判断基準まで曖昧にしないことが大切です。

サーバーレスでは、OSのパッチ作業が減っても、IAM、アプリケーションの脆弱性、秘密情報、公開範囲、データ暗号化、ログ、監視、バックアップ、障害対応の責任は残ります。誰が権限を承認し、誰がアラートを受け、何分以内に一次対応し、どの条件でエスカレーションするかを契約と運用設計に記載します。

個人データを扱う場合は、クラウド事業者と開発会社がデータを取り扱うのか、契約上アクセスしないのかを確認します。個人情報保護委員会のQ&A 7-53では、第三者提供や委託に当たるかは、保存データに個人データが含まれるかだけでなく、クラウドサービス提供事業者が個人データを取り扱うことになっているかが判断基準とされています（出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン」に関するQ&A、2026年8月確認）。法務・セキュリティ担当と契約条項、アクセス制御、漏えい時の連絡と報告主体を確認します。

ソースコード、IaC、パイプライン、設計書、テストコード、監視設定の著作権や利用権を確認します。特に、著作権法第27条・第28条に関する権利の扱い、第三者ライブラリのライセンス、クラウドアカウントの所有者、ドメインや証明書の管理者を明確にします。発注者名義のアカウントで構築するか、委託先のアカウントから移管するかでも、終了時の負担が変わります。

委託先を変更する可能性がある場合は、データのエクスポート形式、環境構築手順、引き継ぎ期間、質問対応の時間、移管費用、秘密情報の返却・削除を契約に入れます。ベンダーロックインを避けるには、特定クラウドを使わないことよりも、構成と運用を発注者が再現・理解できる状態にすることが有効です。

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

サーバーレスの発注費用は、サーバーを購入しないからといって開発費が無料になるわけではありません。要件定義、業務設計、画面・API開発、外部連携、データ移行、テスト、セキュリティ、監視・運用設計に人件費がかかり、別途クラウド利用料が発生します。以下の金額は全国一律の公的相場ではなく、リサーチノートで整理した業務システムの人月単価と工数をもとにした、発注計画上の推定レンジです。

ログイン、数画面、API、簡易データベース、通知を備えた小規模PoC・MVPは、200万円〜500万円程度、期間は1〜3か月が初期検討の目安です。申請・承認、顧客や案件の管理、帳票、権限、監査ログ、外部API連携を含む小〜中規模の業務システムは、500万円〜1,200万円程度、3〜6か月程度を一つの推定レンジとします。

複数部署・拠点、データ移行、複数のSaaSや基幹システムとの連携、可用性・災害対策、運用設計まで含む中規模案件は、1,200万円〜3,000万円程度、6〜12か月程度を想定します。基幹周辺の段階移行、大量データ、複数リージョン、厳格な監査、24時間運用を含む大規模刷新では、3,000万円〜1億円以上、12〜24か月以上になる可能性があります。

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

AWS Lambdaは、リクエスト数とコードの実行時間を基本に課金され、公式料金ページでは月100万件の無料リクエストと月40万GB秒の無料コンピューティング時間が示されています（出典: AWS「AWS Lambdaの料金」、2026年8月確認）。例えば512MBの関数を0.5秒、月1,000万回実行する単純計算では、無料枠を差し引いたLambda部分が約36.8米ドルとなります。1米ドル=150円と仮置きした場合は約5,500円ですが、これはLambdaのみの机上計算です。

実際の請求には、API Gateway、データベース、S3などのストレージ、CloudFront、CloudWatch、暗号鍵、バックアップ、NAT、データ転送が加わります。初期試算のレンジとして、PoC・小規模なら月5,000円〜3万円、社内業務システムなら月2万円〜15万円、中規模本番なら月15万円〜80万円程度を置くことがありますが、これは構成と利用量を前提にした推定であり、市場統計や保証額ではありません。

比較すべきなのは初期開発費だけではありません。クラウド利用料、保守契約、監視・障害対応、脆弱性対応、バックアップ、データ転送、追加開発、社内担当者の運用工数を合算した総保有コストで判断します。従量課金はアクセスが少ない時期に抑えやすい一方、リトライのループ、過剰なログ、不要な常時起動、転送量の増加で予想以上に膨らむことがあります。

AWSの導入事例では、株式会社朝日新聞社がサーバーレス化したフロントエンドについて、Amazon EC2で開発した場合と比較して99％のコスト削減を実現したと説明しています（出典: AWS導入事例「株式会社朝日新聞社」、2026年8月確認）。ただし、これは同社の対象システムに関する事例であり、すべての業務システムに同じ削減率を適用できるわけではありません。自社の処理量と構成で見積もることが必要です。

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

委託先は、クラウドの認定資格やサービス名だけでなく、業務理解、分散システムの設計、セキュリティ、テスト、運用、内製化支援を一体で評価します。提案書の見栄えより、担当者がリスクと制約を説明できるか、発注者の質問に前提付きで答えられるかを重視します。

実績確認では、単に「サーバーレスを導入した」という説明で終わらせず、受発注、申請、顧客管理、画像処理、データ分析など自社に近い業務の事例を聞きます。どの処理をサーバーレスにし、どこをコンテナや既存基盤に残したのか、負荷変動や障害にどう対応したのか、運用開始後に誰が何を担当しているのかまで確認します。

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

見積書は総額の安さではなく、工程、役割、工数、単価、成果物、前提、除外事項を同じ粒度で比較します。要件定義、設計、実装、連携、データ移行、単体・結合・総合・負荷テスト、リリース、運用移行が別々に記載されているかを確認します。クラウドアカウントやライセンス、外部サービスの料金が含まれるかも重要です。

3社程度へ同じRFPを渡し、各社の見積もりに対して「この機能は何人日か」「この月額費用は何件の処理を前提にしたか」「障害対応は何時間までか」「除外した作業は何か」と質問します。金額差が大きいときは、安い会社をすぐ選ぶのではなく、要件、テスト、移行、保守のどこが含まれていないのかを特定します。

2025年11月にはAWS Lambda Managed Instances、2026年6月にはAWS Lambda MicroVMsが発表され、特殊な計算資源や分離実行を、サーバーレスの運用体験と組み合わせる選択肢が広がっています。MicroVMsはAWSの公式発表で東京リージョンを含む提供地域が示されています（出典: AWS公式発表「AWS introduces Lambda MicroVMs」、2026年8月確認）。

ただし、新機能を使うこと自体を提案の評価点にしないことが重要です。一般提供か、対象リージョンか、料金と上限は何か、既存の監視やIaCに組み込めるか、担当者が運用できるかを確認します。新機能の採用が目的ではなく、業務要件、TCO、可用性、移管性を満たす最小の構成を選びます。

よくある質問（FAQ）

サーバーレスのシステムを発注するときに、多くの担当者が迷う点をまとめます。費用、社内体制、既存システムとの連携について、提案依頼前に確認しておくと相談が進みやすくなります。

クラウド利用料やサーバー保守の一部を抑えられる可能性はありますが、外注の開発費まで自動的に安くなるわけではありません。要件定義、業務設計、連携、テスト、監視、運用移行の工数が必要なため、開発費と月額利用料を分け、TCOで比較することが大切です。

発注できます。むしろ、少人数でサーバーの台数管理やパッチ作業を減らしたい場合は、マネージドサービスを活用する価値があります。ただし、社内に業務の意思決定者と運用責任者を置き、権限、費用、障害連絡、データ管理を確認できる体制を用意します。

連携できますが、接続方式、データ形式、認証、通信経路、処理順序、障害時の再送を設計する必要があります。全面移行ではなく、通知、帳票、API、データ連携など周辺機能から切り出し、既存基幹との境界を明確にする段階移行が、リスクを抑えやすい方法です。

特定クラウドを使わないことより、構成を発注者が管理・移管できる状態にすることが重要です。発注者名義のアカウント、IaC、ソースコード、設計書、テストコード、監視設定、データのエクスポート手順を納品範囲に含め、別会社への移管条件と協力費用を契約に記載します。

まとめ

サーバーレスのシステムを発注・外注するときは、「サーバーを管理しなくてよい」という技術上の利点だけでなく、業務の適合性、責任分界、開発費、クラウド利用料、運用費、移管性をまとめて判断します。アクセス変動が大きく、イベント単位に処理を分けられる業務は候補になりやすい一方、長時間・常時高負荷の処理はコンテナや既存基盤との組み合わせも比較します。

発注前には、(1)対象業務と対象外の範囲、(2)Must・Should・将来機能、(3)ピーク時の処理量、(4)性能・可用性・RTO・RPO、(5)個人情報とアクセス権、(6)開発費と月額費用、(7)成果物と検収条件、(8)保守・障害対応、(9)ソースコードとIaCの所有・移管条件を確認します。これらをRFPにそろえて3社程度へ依頼すると、価格だけでなく提案の違いを比較できます。

いきなり全社の基幹システムを刷新するのではなく、申請・通知・帳票・画像処理など一つの業務イベントを題材に、PoCまたは要件整理を依頼する方法があります。技術が動くか、運用できるか、費用が許容範囲かを確認したうえで本開発へ進めると、サーバーレスのシステムを自社に合う形で発注しやすくなります。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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