サーバーレスのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

サーバーレスのシステム開発は、要件整理から運用の定着まで6つのフェーズを順に進めます。業務課題と対象範囲を先に固めることが、手戻りを抑える出発点になります。

まずは1業務または1イベントを小さく通し、そのあとで対象範囲を広げると、技術先行や手戻りを防ぎやすくなります。

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

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

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

サーバーレスでは、利用企業がサーバーを購入・保守しない形をとり、代わりに複数のマネージドサービスを業務要件に合わせて組み合わせます。

サーバー管理の工数は減らしやすい一方で、業務フローやデータ整合性は発注者と開発会社が主体となって決める必要があります。認証や監査ログ、障害時の再実行方法も、両者で決めておきます。

サーバーレスの仕組みと代表的な構成

この方式では、仮想マシンの台数やOSのパッチを利用企業が常時管理せず、リクエストやイベントに応じて実行基盤を使います。裏側ではサーバーが動いており、そのプロビジョニングやスケーリング、ランタイムの一部をクラウド事業者に任せます。

代表的なAWS構成では、画面配信にAmazon S3、認証にAmazon Cognitoを使います。さらに、APIにはAmazon API Gateway、業務ロジックにはAWS Lambdaを使います。

データの保存先として、Amazon DynamoDBを使う構成もあります（出典：AWS「サーバーレスウェブアプリケーション」、2026年8月確認）。業務ロジックや認証の役割は、Azure と Google Cloud では次のサービスで担えます。

• Azure：Azure FunctionsやMicrosoft Entra ID。
• Google Cloud：Cloud Run、Cloud Functions、Identity Platformなど。

向いている業務と向いていない業務

アクセス数や処理件数が変動する業務で、短時間の処理をイベント単位に分けられるものは、必要なときだけ処理を動かせます。

• 向く業務：社内申請、受発注、予約、通知、画像・帳票の生成、IoTデータ収集、夜間処理。
• 段階的な切り出し：新機能をAPIとして既存システムから分けて作る場合に使いやすい形です。
• 別構成が適する場合：常時高負荷の処理、数時間以上の処理、複雑な分散トランザクション、特定のOS・ミドルウェアが必須の業務。

選ぶ際は、処理時間とピーク時の同時実行数を見ます。さらに、データ整合性や障害時の再実行、既存資産との接続も基準になります。

サーバーレスのシステム開発の進め方

6フェーズは要件整理から始まり、定着で終わります。途中は、クラウドとサービスの選定、設計と開発、テストを経て稼働へ進みます。

進め方としては、まず1業務または1イベントを小さく通し、そのあとで対象範囲を広げます。この順にすると、技術先行や手戻りを防ぎやすくなります。

フェーズ1：要件整理によるサーバーレス化の範囲の決定

最初に整理するのは、解決したい業務課題です。システム化したい機能は、その課題に照らして後から決めます。

申請の滞りや受注登録の二重入力を、業務フローの中で洗い出します。繁忙期の遅延や帳票作成の負担も、同じ業務フローに書き込みます。

Must機能、将来機能、対象外を分けます。そのうえで、各機能をサーバーレス、SaaS、パッケージのどれに任せるかを決めます。

• 処理条件：開始イベント、入力、完了条件、連携先、応答時間、月間・ピーク件数。
• 運用条件：利用者と権限、個人情報、保存期間、障害時の継続方法。
• 件数の定義：「月間1万件」に加えて、「月末の2時間に4,000件」と指定します。

たとえば「1件を3回再送しても二重登録しない」と定義しておくと、設計と見積もりが具体的になります。

フェーズ2：クラウドとマネージドサービスの選定

選ぶ基準は、サービスの知名度よりも、既存の人材や認証基盤、開発言語との相性です。分析基盤や契約条件との相性も、あわせて見ます。

Microsoft 365、Microsoft Entra ID、.NET資産を使うならAzure、AWSの運用人材や選択肢を重視するならAWSが候補になります。

• Google Cloud：コンテナやデータ分析・AI連携を重視する場合の選択肢です。
• 比較条件：同じ業務シナリオで性能、運用、費用、移行性を比べます。
• サービス構成：API、実行基盤、DB、ファイル、キュー、ワークフロー、認証、ログ、監視、秘密情報。

将来の変更に備えて、TerraformやCloudFormation、BicepなどのIaCで環境を再現できるかを確認します。

コードと設定を自社に引き渡せるか、他のクラウドやベンダーへ移せるかも見ます。

安易なマルチクラウドは運用を複雑にするため、原則は単一クラウドとし、必要な理由がある部分だけハイブリッドにします。

フェーズ3：業務設計・アプリ設計・開発

画面やAPIの作り込みより前に、イベントの流れと失敗時の動作を決めます。

• イベント設計：受付関数が注文IDを発行し、キュー経由で在庫引当と通知を別処理へ渡します。
• 失敗時の動作：順序逆転、イベント再送、外部API停止時の保留・再実行場所。
• 非機能条件：可用性、RTO・RPO、同時実行数、タイムアウト、リトライ、暗号化、データ所在地、ログ期間、アラート先。

非機能条件は数値で定義し、開発・検証・本番の環境を分けます。そのうえで、CI/CDによる自動デプロイ、承認、ロールバックまで設計します。自動化まで求めるのは、コンソールで手作業により構築した環境が再現できず、障害復旧や監査で問題になりやすいためです。

フェーズ4：分散システム特有のテスト

分散システムでは、画面表示や正常系APIの確認に加えて、障害や負荷の試験が欠かせません。単体・結合テストを行ったうえで、負荷試験と障害試験を実施します。さらに、権限とデータ移行の試験、運用リハーサルも行います。

• イベント：再送、重複登録防止、順序逆転の確認。
• 障害：タイムアウト、部分成功、外部APIエラーが起きた場合の動き。
• 運用：認証期限切れ、ログ欠落、復旧判断。

テストケースには、入力と期待結果を書きます。加えて、安全な再実行方法とログを見る担当者、復旧時間も書きます。

画像処理の失敗時は、ファイルの隔離から再処理キューへの移動、担当者への通知までを業務テストに含めます。要件定義やテストを極端に短くすると、稼働後の手作業と障害対応の費用が増えるため、注意が要ります。

フェーズ5：安全な稼働と移行

まず、切り替え日時と旧システムの停止条件を決めます。未処理データと初回移行は、あわせて扱います。

そのうえで、権限付与と監視を準備します。連絡網とロールバック条件も決めておきます。

• 段階移行：全面切り替えに不安がある場合は、部署や新規データ単位、並行稼働のパイロット、限定ユーザーへのカナリアリリース。
• 判定基準：業務継続、データの正しさ、障害時に戻せることを確認します。
• 受け入れ：完了率、応答時間、件数照合、重大障害ゼロ、バックアップ復元、運用手順。
• 納品物：ソースコード、IaC、構成図、API仕様、テスト結果、運用手順、障害時連絡先。

フェーズ6：運用の定着と改善

クラウド事業者がサーバーを管理しても、利用企業の運用は残ります。現場が新しい手順を使い続けることで、効果が事業成果へとつながります。

• 継続運用：IAM棚卸し、脆弱性、ログ、バックアップ、障害一次切り分け、月次費用、改善優先度。
• 監視指標：CPU使用率、業務失敗率、処理待ち、リトライ、外部連携の遅延。
• 研修と振り返り：現場操作と運用担当の障害訓練を分け、稼働後30日、60日、90日などで確認。

監視は、CPU使用率だけでなく利用者に影響する業務指標を中心に設計します。

振り返りでは、利用率や問い合わせ、処理時間を見ます。費用と障害件数も確認し、不要なログやリトライを減らします。

サーバーレスのシステム開発の費用相場

費用は、開発会社への初期開発費と、クラウド事業者への月額利用料に分けて見ます。

サーバーの常時稼働費は、抑えられる可能性があります。ただし、要件定義と業務設計の工数は残ります。外部連携やデータ移行の作業も残り、テストや監視設計も必要です。

次の金額は、業務システム相場と構成をもとにした初期検討用の推定レンジです。全国一律の公定価格ではありません。

規模により200万〜1億円以上に広がる開発費

規模ごとの費用と期間の目安を見て、業務要件に合う範囲を見積もります。

• 小規模PoC・MVP：200万〜500万円、1〜3か月程度。ログイン、数画面、API、簡易DB、通知など。
• 小〜中規模：500万〜1,200万円、3〜6か月程度。申請・承認、顧客・案件管理、帳票、権限、監査ログ、外部API連携。
• 中規模：1,200万〜3,000万円、6〜12か月程度。複数部署・拠点、イベント連携、複数SaaS・基幹接続など。
• 大規模刷新：3,000万円〜1億円以上、12〜24か月以上になる場合があります。

金額を左右するのは、画面数よりも業務ルールと連携本数です。移行データやテスト範囲によっても変わります。中規模の見積もりには、可用性や災害対策、運用設計も含まれます。

大規模刷新では、基幹周辺の段階移行や大量データの扱いを求められる場合があります。複数リージョンや厳格な監査、24時間運用が加わることもあります。

各レンジは、業務システム相場と人月単価をもとにした推定です。個別の見積もりに代わるものではありません。

構成別のクラウド利用料の試算

AWS Lambdaなどは、リクエスト数、実行時間、割り当てメモリを基準に課金されます。

AWS公式料金では、月100万件の無料リクエストと、月40万GB秒の無料コンピューティング時間が用意されています。

• 無料枠超過後：最初の料金階層で100万件あたり0.20米ドル（出典：AWS「AWS Lambdaの料金」、2026年8月確認）。
• 試算例：512MB、0.5秒、月1,000万回ではLambda部分が約36.8米ドル。

1米ドル=150円と仮定すると、試算例は約5,500円です。

実際の請求には、Lambda以外の費用も加わります。

• 追加料金：API Gateway、DB、ストレージ、バックアップ、CloudWatchのログ・監視。
• その他：暗号鍵、NAT、転送、開発環境の常時稼働も加えて試算。
• 月額推定：PoC・小規模0.5万〜3万円、社内業務2万〜15万円、中規模本番15万〜80万円。
• 高負荷構成：高可用性・大量転送・分析を伴うと月80万〜300万円以上の場合があります。

月額レンジは、構成例をもとにした推定で、市場統計ではありません。

AWSが2025年11月に発表したLambdaマネージドインスタンスは、Lambdaの開発体験を保ったまま、EC2上で関数を動かします。定常的な大容量ワークロードのコストを抑える狙いで使う選択肢です。

料金は、リクエスト、EC2、EC2オンデマンド料金を基準にした15％の管理料金から成ります。常時高負荷の部分は、無条件に通常の関数課金へ寄せず、別に検討できます（出典：AWS公式ブログ「AWS Lambdaマネージドインスタンス」、2025年12月公開）。

サーバーレス開発の見積もりを取る際のポイント

合計金額だけでなく、工程と成果物の範囲をそろえて比べます。監視やセキュリティは、別料金になる場合があります。データ移行や負荷試験、運用引き継ぎも同じように確認します。

RFPに書く件数・性能・責任範囲

RFPには、現状フローと利用者数、月間・ピーク件数を書きます。さらに、画面数やAPI・ファイル連携数、既存データ量も記載します。保存期間と個人情報の有無も、あわせて示します。

「速い」「止まらない」のような表現は、条件として曖昧です。応答時間は、ピーク時95パーセンタイルで3秒以内など、検証できる形で書きます。

• 処理量：月末4時間に5,000件を処理します。
• 復旧時間：障害から60分以内に復旧します。
• 見積工程：要件定義、基本・詳細設計、実装、各種テスト、移行、リリース、研修、初期運用支援。

見積もりは工程を分けて提示してもらいます。料金の前提には、リージョンとリクエスト数を含めます。さらに、実行時間とメモリも含めます。

DB容量やログ保存期間、転送量まで含めます。バックアップや開発環境も含めておくと、会社ごとの見積もりを比べやすくなります。

資格だけでなく運用まで見る開発会社の比較

依頼先を見るときは、資格に加えて、設計から稼働後まで担う体制があるかを確認します。

• 体制：PM、分散システム技術者、セキュリティ・監査担当、運用担当。
• 実績：Lambda利用だけでなく要件定義、基幹連携、移行、障害対応、現場定着。
• 質問事項：重複防止、API停止時の再処理、費用上限、コード・IaC受領、保守後の移管。

認定資格やパートナーランクは判断材料の一つとし、同じRFPと質問を候補各社へ渡します。

NRIデジタル、SCSK、NTTデータなどを、同じ条件で比べます。TIS、サーバーワークス、クラスメソッドも同じ条件に入れると、提案の違いを確かめられます。

セキュリティ・契約・責任分界の明文化

サーバーのパッチを任せても、利用企業側に残る役割があります。IAMやアプリの脆弱性、秘密情報の扱いは、その典型です。データ保護、ログ監視、設定ミスの防止も、利用企業側で担います。

• 個人情報：取扱い契約か保存場所の提供かを、個人情報保護委員会Q&Aや社内法務に沿って確認。
• 漏えい時：報告・通知、調査ログ、海外リージョン、再委託先の扱いを契約に含めます。
• 納品物：コード、IaC、CI/CD、設計書、監視、バックアップ、テスト結果の所有者と引き渡し時期。
• 契約条件：著作権、ライセンス、脆弱性、料金、一次対応時間、復旧目標、法改正、移管。

条件を書面にしておけば、将来のロックインや認識違いを防げます。

サーバーレスのシステム開発でよくある質問

発注前によくある疑問に、費用、既存システムからの移行、運用体制、最新動向の順に答えます。

サーバーレスにするとシステム開発費は安くなりますか？

必ず安くなるとは限りません。サーバー台数の設計やOS保守の工数は減らせます。ただし、イベント設計や分散処理のテストが必要です。

監視や権限の設計、データ移行、再実行設計も欠かせません。初期開発費は業務の複雑さで決まります。そのうえで、開発費とクラウド利用料を分け、数年分の運用・保守・障害対応を含むTCO（総所有コスト）で比べます。

既存のオンプレミスや仮想マシンから移行できますか？

移行はできますが、全面移行が最適とは限りません。まずは、通知や画像処理、帳票生成など、切り出しやすく失敗時に戻しやすい機能でPoCを行います。API受付も、同じ観点で選べます。

長時間処理や特定のミドルウェア、複雑なトランザクションは、コンテナや仮想マシンに残します。周辺機能だけをサーバーレスにする構成も有効です。

サーバー運用が不要なら情シスの仕事もなくなりますか？

情シスの仕事は残ります。物理サーバーやOSの運用は減ります。一方で、利用者・サービス・データの権限や脆弱性の管理は残ります。

ログとアラート、クラウド費用の管理、障害時の業務判断も残ります。役割としては、サーバー台数の管理から、業務サービスの信頼性とデータ保護を管理する仕事へ変わります。

2026年時点でサーバーレスの最新動向は何ですか？

AWSの新機能は、対象のワークロードや実行環境に応じて確認します。

• Lambdaマネージドインスタンス：2025年11月発表。
• Lambda MicroVMs：2026年6月22日発表。
• 本番採用の確認：リージョン、料金、制限、運用実績を見てから採用を判断し、既存のLambda関数やコンテナとは役割を分けます。

Lambdaマネージドインスタンスは、Lambdaの開発体験を保ちながらEC2の柔軟性を使い、定常ワークロードのコストを抑える狙いの機能です。

Lambda MicroVMsは、ユーザーやAIが生成したコードを、分離されたステートフルな環境で実行します（出典：AWS公式ブログ、2025年11月・2026年6月）。

まとめ

サーバーレス開発で目指すのは、業務の課題を解決することです。サーバーを管理しないことは、その手段の一つです。

要件整理で対象範囲を決め、クラウドとサービスを選びます。そのうえで、イベントとデータ、権限と監視を設計します。

分散処理で起こりうる失敗を試験してから、稼働に進みます。

発注前に確認する5つの判断基準

発注前には、変動する処理量に合うか、処理をイベント単位に分けられるかを確認します。あわせて、認証・基幹・データ連携と、個人情報・監査・障害対応の責任分界を見ます。最後に、TCOでの予算化を確認します。

この5点を決めないまま技術選定を進めると、導入後に業務要件や運用コストで問題が起きやすくなります。

最初の1業務・1イベントのPoC

小さく試した結果をもとに、サーバーレス化する範囲を見極めます。

• 対象業務：通知、帳票、画像処理、申請受付など、影響を限定できる業務を一つ選びます。
• 評価指標：処理件数、応答時間、月額費用、復旧手順、現場利用率。

効果を測りやすい業務で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を創業。