Gunicornのシステム開発は、業務アプリ、実行基盤、運用・セキュリティを役割ごとに分けて設計すると、安定した業務処理に役立ちます。構成、開発と運用の進め方、費用相場、発注先の選び方を順に取り上げ、各テーマの詳細は関連記事で確認できます。
▼関連記事一覧
・Gunicornのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Gunicornのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Gunicornのシステム開発の見積相場や費用/コスト/値段について
・Gunicornのシステム開発の発注/外注/依頼/委託方法について
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Gunicornのシステムの位置づけ
Gunicornは、Python製のWebアプリケーションを受け付けて動かす実行基盤です。そのため、画面や業務ルール、データ保存、認証、外部連携は、Gunicornとは別のアプリやインフラが担います。
Gunicornが担当する役割
Gunicornが担う部分と、本番環境で別に用意する機能は、分けて考えます。
- プロセス構成:Unix系OSでマスターが複数のワーカーを管理し、各ワーカーがPythonアプリへのリクエストを処理する
- 障害時:1つのワーカーに障害が起きても、ほかのワーカーで処理を続けやすい
- 起動と本番設定:起動例は
gunicorn myapp:app --workers 4。本番ではワーカー数、タイムアウト、ログ、ソケット、再起動方法の設定が必要 - 担当範囲:静的配信、TLS、認証、DBバックアップ、非同期ジョブは別の基盤に分ける
前段のプロキシやPythonアプリを含め、各基盤を分けて設計しておくと、運用しやすくなります。
pre-fork型と本番サーバーとしての特徴
pre-fork型は、複数のワーカーへ処理を分散する方式です。本番で使うには、並列化や異常時の復旧、ワーカー数が性能に与える影響を理解しておく必要があります。
- 方式:RubyのUnicornに由来し、複数のワーカーへ処理を分散する
- 並列化と復旧:CPU増加時に並列化しやすく、異常終了したワーカーも再生成しやすい
- ワーカー数:増やしても必ず速くなるとは限らず、メモリとDB接続数も増える
- 負荷確認:CPU、メモリ、DB最大接続数、リクエスト待ち時間を合わせて見る
公式資料はプロキシの背後での稼働を推奨しています(出典: Gunicorn公式Deploy、2026年8月確認)。
Gunicornのシステム全体像と役割分担

業務Webシステムは、利用者からアプリまでを役割ごとに分けて組みます。役割の境目が曖昧だと、障害の原因を切り分けにくくなり、見積もりにも漏れが出ます。
前段のプロキシ・ロードバランサー
Gunicornは、プロキシの背後で動かすのが基本です。通信の受け口を前段が担うことで、アプリは業務処理に集中できます。
- 経路:CDN、WAF、ロードバランサー、NginxなどからGunicornへ通信を渡す
- 前段の役割:TLS証明書、静的配信、接続制御、ヘルスチェック、転送元IPを扱う
- 公開範囲:Gunicornを直接公開すると、遅い接続や不正リクエストをアプリ側で抱えやすい
- 転送ヘッダー:
X-Forwarded-ForとX-Forwarded-Protoは信頼するプロキシからだけ受け入れる
信頼する範囲を誤ると、外部の利用者が転送元IPやHTTPSの情報を偽装する可能性があります。さらに、公式資料も信頼するIPを明示するよう求めています。直接アクセスできる状態での無制限設定は、危険だとしています。
アプリケーション・DB・非同期ジョブ
業務機能、保存先、時間のかかる処理は、役割ごとに分けて設計します。
- 業務機能:Django、Flask、FastAPIなどで、ログイン・権限・受注・在庫・申請・帳票を実装する
- データ保存:PostgreSQLなどのDBとオブジェクトストレージに分ける
- 時間のかかる処理:ジョブキューとワーカーに振り分ける
画像や帳票をオブジェクトストレージに置いておくと、アプリサーバーを交換したり増やしたりしやすくなります。
メール送信、CSVの大量取込、帳票生成は、Gunicornのワーカーで同期実行しない設計が適しています。また、外部APIとの定期連携も、同様に切り出す対象になります。ジョブキューを使えば、画面の応答を保ったまま、再実行や失敗通知を管理できます。
Web処理とバッチ処理のどちらを誰が受け持つかは、要件定義に含めておきます。
Django・Flask・FastAPIと実行方式の選び方
フレームワークは、業務機能や認証、データ量を基に選びます。また、APIの性質と運用体制も、選ぶ材料になります。Gunicornの構成は、WSGIやASGIなど、フレームワークの通信モデルと実装方式に合わせて組みます。
管理画面や権限を含む業務アプリはDjango
Djangoは、管理画面や認証などをまとめて設計しやすいフレームワークです。ORMやフォーム、URL制御なども、標準で備えています。複数部署の業務アプリや社内ポータルで、標準機能を活かしたい場合に合います。
Djangoを採用しても、要件定義は欠かせません。たとえば、部署ごとの閲覧範囲や承認経路を決め、履歴保存と削除ルールも定めて、標準機能で足りない部分を明確にします。さらに、運用後の権限追加やデータ移行も初期設計に含めると、後戻りを抑えられます。
小規模APIはFlask、非同期APIはFastAPI
APIの規模や必要な機能に応じて、FlaskとFastAPIを比べます。
- Flask:小規模サービスや社内APIの段階的な拡張に向く
- FastAPI:入力検証やAPI文書を作りやすく、外部連携・非同期APIなどの候補になる
どちらを選ぶかは、APIを段階的に広げるか、非同期の処理を増やすかで変わります。
FastAPIやStarletteなどのASGIアプリでは、ASGIワーカー、Uvicorn単体、別のプロセスマネージャーを比べます。
公式資料は、ストリーミングやWebSocket、HTTP/2などの利用場面も説明しています。
ただし、非同期方式が合うかは、案件ごとに異なります。処理時間、同時接続、外部APIの待ち時間を測り、負荷試験で決めます。
Gunicornのシステム開発の進め方

まず業務目的と非機能要件を定め、そのあとで技術を選びます。ワーカー数やクラウドの構成も、この順番で決めます。
PoCやMVP(Minimum Viable Product)で代表処理を本番に近い環境で試せば、費用と性能の見通しを立てやすくなります。
▶ 詳細はこちら:Gunicornのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
要件定義・企画フェーズ
要件定義では、業務フローとシステム条件を次の順で整理します。
- 担当者、時期、業務、データ、利用者数を業務フローにまとめる
- 通常・ピーク時の同時接続、1件あたりのデータ量、外部API応答を整理する
- 個人情報・決済情報の有無、RTO、RPO、監査ログの保存期間を決める
- Must機能と後回しにできる機能を分けたうえで、主要機能と連携をPoCで試す
- PoCでログイン、登録・検索・更新、権限を試し、操作性とレスポンスを確認する
要件が曖昧なまま進むと、連携仕様や移行データの追加で工数・費用が1.3〜1.5倍に膨らみやすい傾向があります。そのため、未確定の事項は一覧にして、発注側と開発会社で共有しておきます。
設計・開発フェーズ
設計・開発では、業務設計から環境の再現、デプロイ手順までを文書とコードに残しておきます。
- 基本・詳細設計:業務の仕様と、接続や運用の細部を設計書に定める
- 設定共有:アプリとインフラの設定を、リポジトリと設計書で共有する
- デプロイ:Web、ジョブ、DB移行を分けて扱う。CI/CDでテスト、脆弱性スキャン、デプロイ、ロールバックを自動化する
- 復旧準備:単一サーバーでも設定と手順をコード化する
基本設計では、画面やAPI、データモデル、権限を定めます。外部連携、エラー処理、ログ方針も、同じ段階で決めます。
詳細設計では、Gunicornとプロキシの接続方式、タイムアウト、ヘルスチェックを記録します。再起動、環境変数、シークレット管理も書き残します。
担当者だけの知識にしておくと、引き継ぎや障害対応のときに設定をたどれなくなります。また、開発、検証、本番環境でPythonと依存パッケージを固定すると、環境を再現できます。
テスト・リリースフェーズ
テストでピーク時の処理を確かめ、リリースと移行は段階を分けて進めます。
- 負荷・障害テスト:同時接続、遅いAPI、DB枯渇、異常終了、タイムアウト、切断を試す
- 段階リリース:社内少人数、限定部署、全利用者の順に進める
- 移行確認:件数、文字コード、重複、権限、移行後の業務を利用者と確認する
機能テストに加えて、デプロイ中の既存接続も確かめておきます。
ピーク負荷を再現し、応答時間、エラー率、CPU、メモリ、DB接続数を測ります。
小さなインスタンスでの起動確認では、本番に近い負荷は見えません。
切り戻しに備えて、復元の手順、旧版へのロールバック、連絡先、判断基準を事前に決めておきます。
本番環境へのデプロイと運用設計
本番環境は、Linux上でサービス管理する方式、コンテナ基盤、マネージドPython実行基盤に大別できます。方式は、アクセスの変動や監視体制を見て選びます。障害対応の時間や社内のインフラ経験も、判断材料になります。
Linuxサーバーとsystemdで運用する方式
Linuxサーバー方式は、構成を細かく調整できる点が特徴です。
- 基本構成:Linux、プロキシ、Gunicorn、systemd、マネージドDBを組み合わせる
- サービス管理:自動起動、異常時の再起動、停止・再読み込みを設定する
- 運用担当:OS更新、証明書、ログローテーション、バックアップ、監視エージェント、夜間対応を決める
GunicornはUNIXソケットでプロキシに接続します。小規模な社内システムでは、この構成が分かりやすいです。
また、公式のsystemd例は、起動ユーザー、作業場所、停止時間、権限を記載しています。設定を説明できる担当者を残しておくと、特定の人に頼りきりになるのを防げます。
コンテナ・マネージド基盤で運用する方式
コンテナ・マネージド基盤では、環境の再現性と運用設定を確かめます。
- 環境再現:Python、Gunicorn、依存、起動設定をまとめ、負荷に応じて増減する
- 運用設定:脆弱性スキャン、シークレットの注入、DB移行の順序、ログの保存、終了時の接続処理、最小・最大インスタンス数を設定する
- 費用・接続:スケールゼロの費用と起動時間、常時接続要件を確認する
検証環境と本番環境に同じコンテナイメージを配備すると、環境の違いによる差を抑えられます。
2026年の公式更新では、Dockerイメージの公開とPython 3.14への対応が示されました。ASGI互換性テストも拡充され、PROXY Protocol v2にも対応しました(出典: Gunicorn公式Changelog、2026年5月5日)。
運用設定の項目を決めておかないと、コンテナを使っても手作業が多く残ります。
アクセスが少ない場合は、待機費用を抑えられることがあります。
性能・障害対応・セキュリティの要点
本番での品質は、ピーク時の処理を続けられるか、異常を検知して復旧できるか、データを守れるかで決まります。性能とセキュリティは、非機能要件や見積もり、受け入れ条件に含めておきます。
ワーカー数と性能チューニング
ワーカー数は「2×CPU+1」を出発点にできますが、最終的な値は負荷を測って決めます。
ワーカー数を増やすと同時処理数は増えますが、メモリ消費とDB接続数も同じように増えます。
調整では、負荷の指標と同期処理の性質を合わせて見ます。
- 負荷の指標:CPU、メモリ、95パーセンタイル応答時間、5xxエラー率、DB待機時間
- 同期ワーカー:外部APIやDBの応答を待つ間も、処理枠を占有する
I/O待ちが多い場合は、スレッドやgeventも候補になります。ただし、使うライブラリの対応を確かめる必要があります。タイムアウトを延ばすより先に、重い処理の非同期化、クエリ改善、キャッシュ、ページングを検討します。
監視・障害復旧・セキュリティ
監視、復旧、情報保護の運用は、項目ごとに決めておきます。
- 監視:ワーカー再起動回数、5xxエラー、応答時間、CPU・メモリを確認する。DB接続、キュー滞留、ディスク容量も見る
- 復旧:ログを追跡して、再起動、切り戻し、復旧、告知の順を決める
- 個人情報:権限、操作ログ、脆弱性に対応する
死活監視に加えて、リクエストIDをログに付けておくと、プロキシ、Gunicorn、アプリ、DBのログを同じ要求ごとに追跡できます。
その手順は、Runbookにまとめて、障害時にすぐ参照できるようにします。
個人情報を扱う場合は、通信時と保存時のデータを暗号化し、バックアップも保護します。
個人情報保護委員会の指針は、アクセス制御、認証、不正アクセス防止、通信暗号化などを示しています(出典: 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」、2026年6月改正)。
IPAの「安全なウェブサイトの作り方」が扱うSQLインジェクション、認証、認可、CSRF、XSSも、受け入れテストの項目に反映します。
Gunicornのシステム開発の費用相場
GunicornはOSSのため、通常は大きなライセンス費がかかりません。費用の中心は、アプリの設計と実装です。そのほかに、DBや外部連携、クラウド、監視、セキュリティ、保守の費用も含まれます。
「Gunicornを入れるだけなら無料」と考えて予算を組むと、本番に必要な工程が抜けてしまいます。
▶ 詳細はこちら:Gunicornのシステム開発の見積相場や費用/コスト/値段について
規模別の初期費用と開発期間
初期費用と開発期間は、PoCから高可用性・基幹連携の案件まで、規模によって大きく変わります。
- PoC・技術検証:30万〜150万円、2〜6週間
- 小規模:300万〜700万円、3〜4か月
- 中規模:700万〜1,500万円、5〜8か月
- 高可用性・基幹連携:1,500万〜5,000万円以上、8〜12か月以上
これらは、業務システムの相場をもとにした推定で、Gunicornの公式価格や市場統計ではありません。
人件費は全体の60〜80%を占めることが多いため、見積もりでは工程ごとの根拠を確かめます。
内訳の目安は、要件定義10〜12%、設計・環境構築22〜24%、実装48〜50%、テスト15〜17%です(出典: 業務システム相場のリサーチノート、2026年8月)。
クラウド・保守・追加費用
実行基盤以外の費用と、稼働条件による幅も見積もりに含めます。
- 合算費用:DB、バックアップ、ログ、通信の費用が要る。WAF、ロードバランサー、監視も対象になる
- 小規模本番:月1万〜10万円程度からの構成がある
- 冗長化などを追加:月10万〜50万円以上の場合もある
- 保守費:監視・更新・脆弱性や障害対応・性能改善を月10万〜50万円程度で見積もる
東京リージョンの試算例では、1 vCPU・0.5GiBを730時間稼働させます。無料枠、通信、DB、ログを除くと、CPUは約29.5米ドル、メモリは約1.6米ドルです。
合計は約31米ドルで、1ドル150円で換算すると約4,700円です。
請求は、リクエスト数、通信量、常時稼働の有無で変わります(出典: Cloud Run公式料金表、2026年8月確認)。
この試算は一例にすぎないため、実際の費用は利用条件に応じて見積もります。
見積もり・契約・開発会社/ベンダーの選び方

発注先の候補は、Gunicornの本番経験やWSGI・ASGIの判断で比べます。「Python対応」は、候補を絞る入口の条件にとどまります。
クラウド運用、負荷試験、監視まで説明できるかを見ます。セキュリティ、移行、保守についても、説明が具体的かを確かめます。
技術力と本番運用の確認
発注する側は、Gunicornの構成や、Django・Flaskの同期処理かFastAPIなどのASGIかを尋ねます。また、前段の構成やワーカー数の決め方、負荷試験の内容も聞いておきます。
- 運用の具体性:レスポンス時間、エラー率、監視項目、障害時の切り戻しまで具体的な回答が得られるなら、稼働後の運用を想像しやすくなります
- セキュリティ:TLSやWAF、秘密情報、アクセス制御を確かめ、監査ログや依存パッケージのCVE対応も見ておく
- 個人情報・決済情報:扱う場合は、保存場所、権限申請、ログのマスキングを決めておく
- バックアップ:暗号化と、インシデント時の連絡時間を、契約と手順に定める
見積書と契約書での作業範囲と成果物
見積書と契約書では、作業範囲、費用、成果物をそれぞれ分けて確かめます。
- 見積:作業項目と初期費、月額保守、実費、追加・障害対応を明確にする
- 契約:成果物の所有権、引渡し範囲、返却、脆弱性修正期限を決める
要件定義、画面・API、DB設計、Gunicorn・プロキシ構築は、作業項目ごとに見積書へ記載します。さらに、テスト、移行、監視、文書も、作業項目として書き出します。
成果物の対象には、ソースコードやDockerfile、設定、IaCがあります。テストや手順書、ログも含まれます。OSS表示と依存パッケージの扱いも確かめます。
成果物の範囲が曖昧だと、引き継ぎや保守先の変更で追加費用が生じやすくなります。
▶ 詳細はこちら:Gunicornのシステム開発でおすすめの開発会社/ベンダー6選と選び方
▶ 詳細はこちら:Gunicornのシステム開発の発注/外注/依頼/委託方法について
よくある質問(FAQ)
Gunicorn単体の機能、フレームワークとの相性、費用、運用責任について、発注前によく出る疑問に答えます。
Gunicornだけで業務システムを作れますか?
Gunicornは実行サーバーのため、画面や業務ロジック、DB、認証、監視、バックアップは別途用意します。また、見積もりには、Gunicornの設定だけでなく、アプリと運用基盤も含めます。
Gunicornの前にリバースプロキシは必要ですか?
本番では、前段にプロキシを置く構成が基本です。TLSや静的ファイル、接続制御、負荷分散、転送ヘッダーの処理を切り離し、アプリを業務処理に集中させます。
内部ネットワークだけの検証環境では、省略できる場合もあります。ただし、公開する前には構成を見直します。
Gunicornのシステム開発費用はいくらですか?
PoCは30万〜150万円、小規模な社内業務Webシステムは300万〜700万円、中規模は700万〜1,500万円が目安です。
高可用性や複数連携、移行、厳格な監査を含む場合は、1,500万〜5,000万円以上になることがあります。費用を左右するのは、ライセンスよりも業務機能、テスト、クラウド、保守です。
ワーカー数はどのように決めますか?
「2×CPU+1」を目安にしたうえで、負荷試験で調整します。その際は、CPU、メモリ、DB接続、待ち時間、エラー率を同時に測ります。
ワーカー数を増やす前に、重いSQL、外部API待ち、同期処理、キャッシュ不足などの原因を特定します。
運用保守では何を依頼すべきですか?
依頼する範囲には、監視、障害の一次対応、Gunicorn・Pythonの更新、依存パッケージの脆弱性対応を含めます。さらに、バックアップ、性能改善、証明書更新、定期報告も範囲に入れます。
夜間対応や、受付から一次回答までの時間、復旧目標、追加開発との境界は、契約に明記します。設定と手順書も、納品の対象にします。
まとめ
Gunicornの業務システムは、Pythonアプリ、DB、プロキシ、認証、監視、バックアップを組み合わせて作ります。
ワーカー数を決めるより前に、業務フロー、利用者数、連携、RTO・RPO、個人情報の扱いを定めます。
この記事の要点
業務システムには、Gunicornに加えて、プロキシ、アプリ、DB、ジョブ、監視の役割分担が必要です。フレームワークや実行方式は、要件と負荷試験で決めます。
初期費用の目安は、PoCで30万〜150万円、小規模で300万〜700万円、中規模で700万〜1,500万円です。連携、移行、可用性、保守によって変わります。
発注前に決めておく項目
発注後の運用まで見通せるように、要件、費用、納品物を整理しておきます。
- 要件:Must機能、利用者数、ピーク接続、移行、連携をまとめる。セキュリティ、監視時間、復旧目標も書き出す
- 費用:開発、クラウド、保守、追加対応を分ける
- 引渡し:ソースコード、Dockerfile、IaC、テスト、運用手順の範囲を確認する
- 比較:業務を止めずに使えるかを基準に発注先を比べる
▼関連記事一覧
・Gunicornのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Gunicornのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Gunicornのシステム開発の見積相場や費用/コスト/値段について
・Gunicornのシステム開発の発注/外注/依頼/委託方法について
システム構成、方式選定、発注先は、それぞれ確かめる内容が違います。
- 構成:プロキシ、アプリ、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を創業。
