Gunicornを使うシステム開発は、要件整理と方式選定から始め、設計・開発へ進みます。テスト、稼働、定着まで順に進めることで、業務基盤として運用できます。
開発の全体像、各フェーズで決めること、費用の目安、見積もりの確認点を、この順に見ていきます。
▼全体ガイドの記事
・Gunicornのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Gunicornのシステム開発の全体像
Gunicornは、DjangoやFlaskなどで作ったPythonアプリを本番環境で動かすHTTPサーバーです。
業務システムには、画面や業務ルール、DB、アクセス制御、バックアップ、監視も必要です。Gunicornが担うのはその一部のため、責任範囲を先に分けておくと、発注範囲や見積もりの抜け漏れを減らせます。
Gunicornが担当する範囲と担当しない範囲
リクエストの流れと、Gunicornや周辺部品が担う役割を、まず一覧にしておきます。
- リクエスト経路：CDNやWAF、ロードバランサーを通り、Nginxなどを経由してGunicornへ届きます。
- 連携先：Django・Flask・FastAPI、PostgreSQLなどのDB、Redis、ストレージ
- Gunicornの役割：ワーカーでHTTP要求を受け、起動と再起動の管理を担う
必要に応じて、Celeryなどの非同期ジョブ基盤も組み合わせます。
TLS終端、静的ファイル配信、認証認可、データ保存、メール送信は、Gunicornとは別の責任です。また、監査ログや脆弱性対応は、別のコンポーネントかアプリ側で担います。
責任の分け方を要件定義書に書いておかないと、本番公開の段階で担当が決まらず、公開できない事態が起こりやすくなります。
Django・Flask・FastAPIと実行基盤の選び方
業務アプリの要件とチームの経験を照らし合わせて、候補のフレームワークを絞り込みます。
- Django：管理画面、ユーザー管理、ORM、フォーム、権限などを含む業務アプリ
- Flask：小さな社内APIや機能を絞ったサービス
- FastAPI：型検証や非同期処理を重視するAPI
選ぶ際は、人気に加えて既存資産、拡張機能、障害対応体制も合わせて見ます。
DjangoやFlaskのようなWSGIアプリでは、まず同期またはスレッドワーカーから検討します。一方、I/O待ちが多いAPIやストリーミングでは、負荷試験の結果を見てから非同期ワーカーを選びます。
FastAPIなどのASGIアプリでは、GunicornのASGIワーカーとUvicorn単体、別のプロセスマネージャーを比べます。
構成は、目標レスポンスタイム、同時接続数、エラー率、運用者のスキルに合うものを選びます。
2026年時点で確認したいGunicornの動向
Gunicorn公式の2026年5月の26.0.0では、次の更新が示されています。
- ASGI：互換性テスト拡充とPROXY Protocol v1/v2対応
- HTTP：入力の検証を強化
- Docker：Python 3.14を使った公式イメージを更新
ASGI互換性テストは438件中444件が通過したと公表されています（出典: Gunicorn公式Changelog、2026年）。
新機能を取り入れる際は、依存ライブラリやプロキシ、監視への影響も確認します。新規開発では、GunicornとPythonのバージョン、ベースイメージ、WSGI・ASGIを固定したうえで、更新方針も決めておきます。
更新前には、ステージング環境でリクエスト、アップロード、ストリーミング、ヘルスチェック、グレースフルシャットダウンを試しておきます。特に、HTTP解析の厳格化が古いクライアントやプロキシに影響しないかは、事前に確かめておく必要があります。
Gunicornのシステム開発の進め方
ワーカー数や起動コマンドから始めると、業務要件が抜けるおそれがあります。そこで、目的と非機能要件を整理してから、6つのフェーズを順に進めます。
各フェーズに終了条件を決めておくと、後工程での手戻りを抑えやすくなります。
フェーズ1：業務と非機能の要件整理
要件整理では、業務を使う人や扱うデータを洗い出し、改善したい点を明らかにします。洗い出す内容は、利用状況から非機能要件まで4つの面に分けられます。
- 利用状況：部署・権限、月間利用者数、ピーク時の同時接続数
- データ・連携：1件あたりのデータ量、外部API・基幹システムとの連携
- 業務ルール：個人情報・決済情報の有無、申請承認や在庫引当
- 非機能要件：目標レスポンスタイム、稼働時間、RTO、RPO
RTOは障害時の復旧時間、RPOは許容できるデータ損失を示します。そのうえで、バックアップと監査ログの保存期間も決めます。
たとえば、主要APIは通常時の95パーセンタイルで2秒以内とします。平日8時から20時に稼働し、重大障害は4時間以内に復旧する、という基準を置くこともあります。
要件定義で作る成果物や受入、運用準備も、このフェーズで決めておきます。
- 成果物：機能、画面・API、権限、データ項目、連携の各一覧と非機能要件
- 受入：受入条件をまとめ、業務責任者の承認を得る。
- 運用準備：例外処理の担当者、移行対象と件数、問い合わせ窓口を事前に決める
要件定義を短縮しすぎると、追加要望や連携仕様が後から見つかり、工数と費用が膨らみます。
フェーズ2：フレームワーク・クラウド・運用方式の選定
要件をもとに候補を絞り、開発者の経験や既存のPython資産とも照らし合わせます。選択肢は、アプリの作り方と、動かす場所の二つの面に分かれます。
- フレームワーク：CRUD・管理画面ならDjango、軽量APIならFlask、型検証・非同期APIならFastAPI
- VM：小規模で構成を細かく管理したい場合
- Docker：中規模以上で再現性と自動化を重視する場合
- PaaS・サーバーレス：インフラ運用の負担を抑えたいとき
実行基盤には、Linux上でNginx・Gunicorn・systemdを動かす構成、Docker、Cloud RunやElastic Beanstalkなどがあります。
AWS Elastic BeanstalkのPython環境は、Gunicornを標準のWSGIサーバーとして提供しています。また、Procfileでワーカー数などを指定できます（出典: AWS Elastic Beanstalk公式ドキュメント、2026年確認）。
DB、ロードバランサー、ログ、通信、バックアップは、別途設計が必要で、料金も別に加わります。そのため、選定の段階で費用、運用、引き渡しを確かめておきます。
- 費用：初期費用と月額費用
- 運用：担当者の作業と障害時の復旧方法
- 引き渡し：ベンダー変更時に受け取れる範囲
フェーズ3：設計・開発での責任の分け方と性能の作り込み
基本設計では、通信経路と各部品の責任を決めるとともに、認証認可やデータモデルも設計します。
- 通信と安全：Gunicornをインターネットへ直接公開せず、プロキシの後ろに置きます。
- 起動・環境：起動コマンド、環境変数、シークレットの保管場所
- 運用設定：ヘルスチェックとタイムアウトに加え、停止時の動作、ワーカーの再起動条件（max requests）、ログ形式
このうち、TLS終端の場所と信頼する転送元IPは設計書に記載します。また、バックアップ方式とログの保存場所も設計します。
ワーカー数を決める際は、「2×CPU＋1」を初期値とする公式Dockerイメージの式が参考になります（出典: Gunicorn公式Changelog、2026年）。ワーカーを増やしても、必ず速くなるとは限りません。そのため、メモリやDB接続数も踏まえ、負荷試験で調整します。
設計では、例外系の扱い、構成の分け方、成果物の範囲も含めて決めます。
- 例外系：権限不足、二重送信、外部APIの停止など、異常時の扱い
- 構成分割：Webアプリ、非同期ジョブ、定期バッチ、DB移行を一つのコンテナに詰め込みすぎない
- 成果物：ソースコード、Dockerfile、依存定義、IaC、運用・リストア手順
開発は、レビューしやすい機能単位に分けて進め、正常系と例外系の両方を実装します。
フェーズ4：機能・連携・負荷・復旧のテスト
テストは、単体、結合、総合、受入の段階に分けて実施します。次に、構成、運用・連携、負荷の観点を確かめます。
- 構成試験：プロキシのヘッダー、静的ファイル、TLS、セッション、DB接続
- 運用・連携試験：ワーカー異常終了、ログ、監視アラート、外部先の遅延やエラー
- 負荷試験：ピークの接続数・要求数と応答時間、CPU、メモリ、ワーカー、DB接続の計測
キューの滞留や5xxエラー率も測ります。そのうえで、変更によって改善した指標と悪化した指標を記録しておきます。
個人情報を扱う場合は、本番データをそのまま複製せず、マスキング済みのデータを使います。また、受入条件や切り戻し、障害連絡もテストの段階で決めておきます。
- 受入条件：対象画面・帳票、許容エラー、移行件数、復元時間
- 切り戻し：デプロイ失敗時のロールバックとDB移行の戻し方
- 障害連絡：連絡先と監視停止時の代替手段
重大な未解決課題が残っている場合は、稼働判定をしないことが安全です。
フェーズ5：段階的な本番切り替え
本番公開は、まず限定したユーザーから始めます。操作感や業務ルールに漏れがないかを確かめながら、対象を広げていきます。切り替えでは、公開範囲の広げ方から、公開後の監視までを順に決めておきます。
- 対象部署に公開し、問題がなければ全社へ広げます。
- 既存システムがある場合は並行稼働させ、データの突合と切り戻しの期限を定めます。
- 開始と終了の条件、担当者、作業順、判断者、連絡先を一覧にまとめておきます。
- 環境変数、シークレット、DNS、WAF、ロードバランサーの設定、DB移行、バックアップ、監視通知の確認
- 公開後は、アクセス数や5xx、レイテンシ、ワーカー再起動、DB接続、キュー滞留を監視します。
フェーズ6：定着期の運用改善と引き継ぎ
利用率が上がらない原因は、業務手順や権限、教育、問い合わせ導線にあることもあります。導入後は、利用者への支援と改善を続けながら、保守と引き継ぎを進めます。
- 利用支援：利用者マニュアル、管理者の設定手順、障害の一次切り分け
- 改善：質問をFAQや改善バックログに蓄積し、導入後1か月・3か月などで利用状況を確認する
- 保守：監視時間、障害の重大度、初動時間、復旧目標、Gunicorn・Pythonの更新、依存パッケージのCVE対応、バックアップ確認、性能改善
- 引き継ぎ：コード、クラウド設定、監視、CI/CD、手順書
監視を24時間行うか、営業時間内の通知にとどめるかで、費用は変わります。
Gunicornのシステム開発費用相場とコストの内訳
Gunicorn自体はOSSのため、通常はライセンス購入費が開発費の中心になることはありません。費用の中心は、業務アプリの設計・実装やデータ移行です。ほかにも、クラウド、DB、監視、テスト、保守の費用がかかります。
見積もりは、Gunicorn単体の規模ではなく、業務システム全体の規模で行います。
規模別の初期費用レンジと開発期間
このレンジは、業務Webシステムの相場を、Gunicornを採用するPython Webシステムの構成と照らし合わせて推定したものです。規模は、検証だけの段階から、基幹システムと連携する段階まで4つに分けて見ます。
- 技術検証・PoC：30万〜150万円、2〜6週間
- 小規模な社内業務Web・API：300万〜700万円、3〜4か月程度
- 中規模システム：700万〜1,500万円、5〜8か月程度
- 高可用性・基幹連携型：1,500万〜5,000万円以上、8〜12か月以上
PoCは、代表的なAPIや1画面、Docker、簡易認証、簡易負荷試験を含む想定です。さらに、小規模はCRUD、権限、DB、単一環境、基本監視まで含みます。
中規模では、複数部署、外部API、詳細な権限、データ移行、冗長化、運用設計を含みます。高可用性・基幹連携型は、複数AZ、高度な監査ログ、ERP連携、大量データ移行、SLA、24時間対応まで求める場合です。
これらは、Gunicorn公式の価格ではなく、業務システムの相場をもとにした推定です。
要件定義、設計・環境構築、実装、テストに、それぞれ工数が割り振られます。一般的な業務システムでは、人件費が総額の60〜80％程度を占めます（出典: NotebookLMリサーチノート「業務システム全般_13」、2026年確認）。
連携数や権限の複雑さが、費用を左右します。そのほか、移行データの品質や非機能要件、テストの深さも費用に影響します。確認が不足すると、見積もり後に追加費用が発生するおそれがあります。
クラウド・DB・監視・保守のランニングコスト
小規模な本番環境は、クラウド、マネージドDB、バックアップ、ログ、WAF、通信を合わせて、月1万〜10万円程度から組めます。冗長化や読み取り用DB、長期ログ、複数環境、CDN、24時間監視を加えると、月10万〜50万円以上になる場合があります。金額は利用量、リージョン、可用性、データ転送量で変わるため、料金計算機で試算し直します。
内訳は、従量課金、保守費、契約範囲に分けて見ておきます。
- 従量課金：Cloud RunはCPU・メモリ、リクエスト、通信量に応じて費用が変わる
- 保守費：OS・Python・Gunicornの更新、脆弱性対応、障害調査、性能改善、問い合わせを含めると、月額10万〜50万円程度です
- 契約範囲：障害調査、性能改善、問い合わせ、対象時間、対応レベル
東京リージョンで1 vCPU・0.5GiBを730時間連続稼働させた試算では、CPU・メモリの合計が約31米ドルでした。
1ドル150円で換算すると約4,700円になりますが、これは無料枠、通信、DB、ログを含まない参考値です（出典: Google Cloud Run公式料金表、2026年確認）。
また、常時稼働にするか、ゼロまで縮退させるかでも金額は変わります。そのため、対象時間と対応レベルを決め、開発費と月額契約の作業を分けて見積もります。
Gunicornのシステム開発で見積もりを取る際のポイント
見積もりでは、総額だけでなく、前提や成果物、除外項目、追加費用の条件も確認します。負荷試験や監視、バックアップ、セキュリティ、引き継ぎが見積もりに含まれていないと、稼働後に別費用となる場合があります。
見積書への要件と前提条件の反映
見積依頼書には、利用規模、機能、セキュリティ、運用の前提を記載します。
- 規模・機能：利用者数、ピーク同時接続数、画面数、API数、権限
- 連携・移行：外部連携先、移行件数、個人情報・決済の有無
- 運用：目標稼働率、バックアップ、監視時間帯
未確定の項目は、どの条件で金額が変わるのかを具体的に書きます。たとえば、連携先が2つから5つに増える場合や、ID・パスワードから多要素認証へ変える場合が該当します。
成果物として、要件定義書や画面・API仕様、DB定義、インフラ構成図を挙げてもらいます。さらに、DockerfileやIaCが含まれるかも確認します。テスト仕様・結果、監視設計、運用・復旧手順も、あわせて確かめます。
ソースコードのほか、コードとクラウド設定の所有権も契約で確かめます。あわせて、OSSライセンスや開発会社を変える際の引き渡し、生成物や翻案物の権利も確認しておきます。
開発会社の比較と本番経験の確認
候補となる会社には、Python対応に加えて、Gunicornの本番利用経験も尋ねます。比べる際は、技術と運用の経験をまず確かめ、そのうえで見積もりと提案体制を見ます。
- 技術経験：WSGI・ASGIの理由、Nginx・ロードバランサーとの接続
- 運用経験：Docker、AWS・GCP・Azure、CI/CD、負荷試験、夜間障害対応
- 見積比較：同じ要件書をもとに、初期費用と月額費用を分けて比べる
- 提案体制：体制、レビュー、品質基準、リスク、顧客側の作業、問い合わせ窓口
公開事例があっても、自社と同じ規模や機密性、可用性の経験があるとは限りません。そのため、担当者が経験や判断理由を説明できるかを確かめます。
期間が短い提案では、要件定義やテスト、移行、ドキュメントが削られていないかを見ます。
契約前のセキュリティと運用リスクの確認
契約前には、通信から障害対応まで、領域ごとの責任範囲を確かめておきます。
- 通信・権限：プロキシ、TLS、転送元IPの限定、管理画面のアクセス制御
- 情報管理：秘密情報、個人情報の権限・ログ・委託先・バックアップ・削除手順
- 更新・決済：脆弱性対応者、自社保管か決済代行か、関連基準
- 障害対応：判断者、復旧担当、無償対応の範囲をSLAや保守契約に記載
個人情報を扱う場合は安全管理措置も確認します（出典: 個人情報保護委員会「個人情報保護法ガイドライン（通則編）」、2026年確認）。
Gunicornのシステム開発でよくある質問
発注前によくある質問を取り上げます。どの質問も、アプリ、インフラ、セキュリティ、保守を一体で確認して判断します。
Gunicornは無料なので、システム開発費も安くなりますか？
GunicornはOSSのため、通常はライセンス購入費が不要です。ただし、業務機能の開発費に加えて、次の費用がかかります。
- DB、認証、クラウドの構築
- 監視、テスト
- 移行、保守
見積もりでは、Gunicornの設定費と業務システム全体の費用を分けて示してもらいます。
Gunicornの前にNginxやロードバランサーは必要ですか？
Gunicorn公式はプロキシ利用を推奨し、本番ではその後ろに置く構成が一般的です（出典: Gunicorn公式Deploy、2026年確認）。プロキシが担う役割と、設計で確かめる点を分けて見ます。
- 構成要素：TLS終端、静的ファイル、接続制御、複数インスタンスへの振り分け
- 設計確認：製品は一律に決めず、直接公開した場合のリスクと責任の分け方を確かめる
Gunicornのワーカー数はどのように決めますか？
CPU数をもとにした「2×CPU＋1」を初期値として検討し、負荷試験で調整します。調整では、判断材料と性能の制約を押さえます。
- 判断材料：メモリ、DB接続数、処理時間、同時接続数
- 性能と制約：同時処理能力が上がる場合も、メモリ不足やDB接続枯渇を招く場合もあります。
- 記録：測定結果と設定変更の理由を運用文書に残します。
Gunicornを使った業務システムの開発期間はどれくらいですか？
開発期間は規模や可用性で異なるため、目安は規模ごとに分けて見ます。
- 技術検証：2〜6週間
- 小規模な社内業務Web：3〜4か月
- 中規模：5〜8か月
- 高可用性・基幹連携型：8〜12か月以上
期間は画面数だけでなく、連携、権限、移行、テスト、承認、運用設計によって変わります。そのため、要件整理の結果と開発体制を合わせて確認します。
個人情報を扱う場合に何を確認すればよいですか？
個人情報や決済情報を扱う際は、技術対策と運用上の責任の分け方を確認します。確認の中身は、基本対策、運用体制、決済情報に分けて見ます。
- 基本対策：アクセス権限、TLS、秘密情報、監査ログ、バックアップ、復元
- 運用体制：脆弱性対応、委託先管理、障害時の連絡手順
- 決済情報：カード情報の保存範囲と決済代行との責任の分け方
安全管理は開発会社任せにせず、要件、テスト、保守契約に分けて記載します。
まとめ
Gunicornを使う開発は、Pythonアプリだけでなく、DBや認証、プロキシ、クラウド、監視、保守までを含めた業務基盤として捉えます。
要件整理では、利用者と業務ルール、連携先と負荷を押さえます。RTO・RPOやセキュリティも定めたうえで、WSGI・ASGIの方式を決めます。続いて、フレームワークはDjango・Flask・FastAPIから、実行基盤はVM・Docker・PaaSから選びます。
まとめで押さえたい判断基準
進行や発注先は、工程、費用の範囲、運用対応を基準に判断します。
- 工程管理：6段階で進め、終了条件と成果物を確認
- 費用比較：初期・月額費用と含む・除外作業を分けて相見積もり
- 会社選び：本番運用、セキュリティ、障害対応、引き継ぎを説明できること
費用は、業務機能、移行、クラウド、監視、テスト、保守によって大きく変わります。そのため、工程や費用、開発会社の対応を確かめておくことが、長く使えるシステムにつながります。
次に行うべき準備
相談の前に条件を整理しておくと、同じ前提で複数社を比べられます。
- 利用者、業務フロー、連携先、ピーク負荷、個人情報の有無、希望時期を書き出します。
- Gunicornの本番経験とクラウド運用体制を持つ複数社への相談
- 同じ条件での初期・月額費用、成果物、保守範囲の比較
▼全体ガイドの記事
・Gunicornのシステム開発の完全ガイド
▼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を創業。