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

Gunicornのシステムを発注するときは、業務要件を整理し、契約範囲を明確にしたうえで、段階的に検証しながら進めると、認識差や手戻りを抑えやすくなります。

発注形態は、仕様をどこまで先に固められるかで選び分けます。全体像は、完全ガイドでも扱っています。

▼全体ガイドの記事
・Gunicornのシステム開発の完全ガイド

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

Gunicornの位置づけ

Gunicornは、DjangoやFlaskなどのPythonアプリを本番環境で動かすHTTPサーバーで、業務機能を持つ完成品ではありません。

画面やAPI、DB、認証、クラウド、監視を組み合わせることで、初めて業務システムになります。

Gunicornと周辺コンポーネントの役割分担

典型的な構成では、まずCDNやWAF、ロードバランサーがアクセスを受けます。次に、NginxなどのリバースプロキシがGunicornへ転送します。

Gunicornの先では、Django、Flask、FastAPIなどのアプリを実行し、業務データはPostgreSQLなどに保存します。

• 非同期処理：Celeryなどのジョブワーカーで実行します。
• キャッシュ：Redisなどの別の仕組みに任せます。
• ファイル：オブジェクトストレージに保存します。

業務要件で決めるDjango・Flask・FastAPIの選択

管理機能の厚さや、API中心かどうかによって、採用候補となるフレームワークが変わります。

• Django：管理画面、認証、ORM、権限管理を含む業務アプリの候補。
• Flask：軽量な社内サービスや小規模APIの候補。
• FastAPI：API中心で、型検証や非同期処理を重視する場合の候補。

FastAPIなどのASGIアプリでは、GunicornのASGIワーカー、Uvicorn単体、別のプロセスマネージャーの中から選ぶことになります。その判断には、負荷試験で応答時間と運用性を確かめます。

Gunicornのシステムの発注形態の選び方

発注形態は、完成責任をどこまで委託先に持たせるか、自社の技術担当者数、要件変更の頻度によって決まります。

Gunicornの設定だけを任せるのか、業務アプリとインフラを一括で任せるのかも、先に決めておきます。範囲が曖昧なままだと、見積を比べられません。

完成物と予算を先に固めたい案件に向く請負型

請負契約では、合意した仕様のシステムを完成させ、検収を受ける責任を委託先が負います。

請負型では、仕様が発注前にどこまで固まっているかが、予算と納期の見通しを左右します。業務フローと画面、APIに加えて、次の項目も発注前に固められるなら、管理しやすくなります。

• データ移行
• 性能
• セキュリティ
• 受入条件

発注後に対象部署や移行データを増やすと、追加契約になりやすい点に注意が必要です。

要件を検証しながら進める案件に向く準委任型

準委任契約は、時間や業務の提供に対して報酬を支払う形態で、PoC、既存Pythonシステムの調査、運用改善に向いています。

段階的にMVPを作る開発のように、着手時点で全仕様を決めにくい案件にも適しています。

作業時間を投入することと、期待する業務成果が完成することは別です。そのため、役割、月ごとの成果物、レビュー方法を契約書や計画書に明記し、稼働上限と品質基準も決めておきます。

フェーズごとに契約を分けるハイブリッド型

要件定義と技術検証は準委任型で行い、要件が確定したあとの開発と受入は請負型にする方法もあります。

たとえば、2〜6週間程度のPoCで代表画面、認証、外部API、簡易負荷試験を確かめてから本開発へ移す方法があります。この順にすると、構成の見落としを早い段階で見つけられます。

契約を分けるときは、各フェーズで引渡しを確認します。著作権やソースコードのほか、Dockerfile、IaC、検証環境も対象になります。

発注前のRFPと要件の整理

RFPは、開発会社に提案と見積を依頼する資料です。解決したい業務課題、成果、前提条件、評価方法を、どの会社にも同じ条件で伝えるために作ります。

RFPでは、Gunicornのバージョンやワーカー数を指定するより、利用状況と非機能要件を明らかにするほうが、実現性のある提案につながります。

利用者と業務フローから書く業務要件

業務要件は、誰が、いつ、どのデータを使い、どの判断をするかを書き出すところから始めます。利用者は、管理者、現場担当者、取引先などに分けて整理します。

• 画面と操作：ログイン後の画面や、登録・承認・差し戻しの操作を示します。
• 情報の扱い：検索条件や帳票、通知、外部連携の内容を書き出します。
• 既存業務：置き換える場合は、Excel、CSV、紙帳票、手作業の承認も含めて書きます。

ピーク時の同時接続数や1日あたりの処理件数は、費用を左右します。ファイルサイズや保存期間、個人情報や決済情報の有無も、見積の前提になります。

Gunicornのワーカー数は、CPUだけでなくメモリとDB接続数にも影響します。これらをRFPに記載すると、見積の条件がそろいます。

SLOと運用体制まで含めた非機能要件

性能目標と運用基盤の選び方は、見積にも、本番後の運用負担にも関わります。

• 品質目標：応答時間、稼働時間、復旧目標のRTO、許容損失を示すRPOを定めます。
• 運用要件：バックアップや監査ログ、権限分離、脆弱性対応の方法を決めます。
• VM型：Linux、systemd、Nginx、Gunicornで構成します。
• コンテナ型：Dockerを使い、Web、ジョブ、マイグレーションを分けて扱います。
• マネージド型：Cloud RunやElastic Beanstalkなどが候補になります。

性能要件は、「速い」といった言い方ではなく、検証できる条件で書きます。たとえば、平日9時から18時のピーク時に、主要検索の95パーセントを2秒以内に応答する、と定義できます。

AWS公式資料によると、Elastic BeanstalkのPython環境は、Gunicornを標準のWSGIサーバーとして提供しています。ただし、EC2、ロードバランサー、RDS、ログ、通信の費用と設計責任は残るため、PaaSを使っても運用費はゼロになりません。

Gunicornのシステム開発を発注する進め方

発注後は、要件定義、設計、実装、テスト、リリース、保守の順に工程を進めます。そのうえで、工程ごとの終了条件と確認する成果物も決めておきます。

終了条件を明確にしておくと、「そこまで作ってもらえると思っていた」という認識差を防ぎやすくなります。

要件定義で決める小さな検証範囲

要件定義では、どこまでを最初に作るかと、MVPで何を検証するかを決めます。

• 優先度：Must、Should、Couldのように分け、初回リリースの範囲を定めます。
• MVP：認証、代表的な登録や検索、権限、外部API、エラー処理を含めます。

小さなMVPで利用者に確かめてもらうと、業務上の見落としを減らせます。

特に、要件定義を急ぐと、追加要望や手戻りによって、工数と費用が1.3〜1.5倍に膨らむ可能性があります。見積を取る前に、業務担当者がレビューする時間も確保しておきます。

設計・実装でのアプリと実行基盤の境界

画面やAPIのほか、Gunicorn、プロキシ、DBなどの実行基盤の管理担当も決めます。キャッシュ、ジョブ、監視も含めて、どこまでを誰が受け持つかを定めます。

静的ファイルの配信とTLS終端はNginxやロードバランサーが受け持ち、業務処理はPythonアプリ、データの保存はDBが受け持つ、という形で責任を文書に残します。

ワーカー数は「2×CPU＋1」を初期値として使えます。ただし、これは公式Dockerイメージの目安なので、負荷試験で検証します。

テスト・リリースでの失敗時の戻し方

テストでは、画面の表示だけでなく、障害条件とリリース時の手順も確認します。

• 負荷・停止：ピーク時の同時接続、タイムアウト、ワーカー停止、DB接続の枯渇を試します。
• 異常系：外部API障害、ファイル容量の超過、権限の逸脱に対する動作を確認します。
• デプロイ：正常終了とgraceful shutdownの動作を見ます。
• 復旧手順：ログ保存、DBマイグレーション、ロールバックを一連で確かめます。

納品前にバックアップの復元、障害時の連絡先、初動時間を確認しておくと、本番後に誰が何を受け持つかがはっきりします。

契約書で確認すべきGunicornシステムの委託範囲

アプリ開発会社とインフラ会社が別々になることもあります。そのため、「システム一式」とだけ書いても、担当範囲は分かりません。

OSやPython、Gunicorn、依存パッケージの更新は、誰が担当するかを契約と運用設計書で定めます。監視、障害対応、クラウドアカウント、バックアップについては、担当者を同じ書類に書きます。

ソースコードと運用資産の権利・引渡し

契約では、納品物と権利を決めておきます。そのうえで、次の資産を引き渡すかどうかを確認します。

• アプリ資産：ソースコード、設定ファイル、requirements.txt、ロックファイル。
• 開発・運用資産：Dockerfile、CI/CD、Infrastructure as Code、監視設定。
• 文書・定義：運用手順書、テスト仕様書、データベース定義。
• 権利・契約：著作権、翻案権、OSSライセンス、第三者サービスの契約主体、クラウドの所有者。

納品後に別の会社へ保守を移せる状態かどうかは、発注前に質問しておきます。

対応時間と更新範囲を分けた保守契約

月額保守に含む作業と対応条件を分けて、SLAに記載します。

• 定常作業：監視、障害の一次対応、OS・Python・Gunicorn・依存パッケージの更新。
• 範囲の切り分け：脆弱性、性能改善、問い合わせ、機能追加が、月額の内か別見積かを確認します。
• 対応時間：平日のみか、夜間・休日を含むか、一次回答までの時間を定めます。
• 脆弱性更新：周辺ワーカーやPythonパッケージのCVEを対象に含めます。

Gunicornのシステム開発費用・外注費用の相場

GunicornはOSSなので、通常はライセンス購入費がかかりません。費用の中心は、アプリの設計・実装と移行です。そこに、クラウド、セキュリティ、監視、保守が加わります。

次に示す金額は、Gunicorn単体の公式価格ではありません。リサーチノートの業務Webシステム相場と、Python構成を照らし合わせた推定です。

規模と非機能要件で変わる初期費用

初期費用と開発期間の目安は、案件規模や連携、可用性の要件によって変わります。

• PoC・技術検証：30万〜150万円、期間は2〜6週間の想定。
• 小規模：画面やAPIが限られる社内業務Webシステムで、300万〜700万円、3〜4か月。
• 中規模：複数部署、外部API、移行、冗長化を含み、700万〜1,500万円、5〜8か月。
• 高可用性・基幹連携：1,500万〜5,000万円以上、8〜12か月以上が目安。

金額と期間は、事業規模、画面数、連携先、移行量によって変わります。SLAやセキュリティ要件も、金額と期間に影響します。

参照ノートの工程配分では、人件費は総額の60〜80パーセント程度、実装は48〜50パーセント程度とされています（出典: NotebookLM「業務システム全般_13」Q&A、2026年）。

見積は、Gunicorn設定費だけで比べないようにします。要件定義から保守まで、工程ごとの費用を分けて確認します。

クラウドと保守のランニングコスト

クラウドの利用規模と保守範囲を分けて見ると、継続費用を見積もりやすくなります。

• 小規模本番：DB、バックアップ、ログ、WAF、通信を含めて、月1万〜10万円程度からのケースがあります。
• 冗長構成など：条件によっては、月10万〜50万円以上になることもあります。
• Cloud Run：CPU、メモリ、リクエスト数などの使用量で課金されます。
• 保守：初期開発費の年15〜25パーセント程度、または月10万〜50万円程度を検討の目安とします。

Cloud Runの金額は、無料枠、リージョン、最小インスタンス数によっても変わります（出典: Google Cloud「Cloud Run pricing」、2026年）。

冗長化やマネージドDB、複数AZを使うと、クラウド費も上がります。さらに、監視の保持期間やアクセス量が増えると、その分も費用に加わります。

保守には、監視、障害対応、性能改善が含まれます。加えて、OSやPython、依存パッケージの更新や、脆弱性への対応も見積に入れます。

保守費の幅は、NotebookLM「業務システム全般_13」Q&Aを参考にした推定で、市場価格を保証するものではありません。比べるときは、対応時間、担当人数、月の作業時間、改修量をそろえて見ます。

Gunicornに対応できる委託先の選び方と見積比較

委託先は、「Python対応」できるかだけでなく、本番環境の設計や運用まで質問して選びます。

Gunicornの公開実績がなくても、Django・Flask・FastAPIやDockerの経験は候補の材料になります。そのうえで、クラウド（AWS・GCP・Azure）、Nginx、CI/CD、監視まで、一体で説明できるかも確かめます。公開実績は、今回の規模を安全に運用できるかを判断する材料の一つです。

構成と検証内容まで確認する技術実績

構成の選定理由と検証方法を、候補会社に質問します。

• 技術構成：Pythonフレームワーク、WSGI・ASGI、ワーカー種別、プロキシ、DB、ジョブ、デプロイ方法。
• ワーカー設計：CPUだけでなく、メモリ、DB接続プール、ピーク同時接続、タイムアウト、実測応答時間を確認します。

CPU数だけを聞いて即答せず、条件を確認したうえで提案する会社を評価します。

2026年のGunicorn公式Changelogでは、ASGI対応の拡充と公式Dockerイメージが示されています（出典: Gunicorn公式Changelog、2026年）。

PROXY protocol v2とHTTPリクエスト解析の厳格化も示されています（出典: Gunicorn公式Changelog、2026年）。

更新を検証環境で確かめてから本番に反映する方法や、脆弱性が見つかったときの緊急対応も聞きます。開発経験と運用経験を分けて評価できます。

工程・前提・除外項目をそろえた見積比較

相見積もりでは、各社の作業範囲を同じ工程にそろえて比べます。そのうえで、前提となる数量や条件も確認します。

• 工程：要件定義、UI設計、実装、インフラ、移行、負荷試験の並びで照らし合わせます。
• 品質・公開：セキュリティ診断、リリース支援、保守の有無を見ます。
• 前提条件：画面、API、連携先、データ、利用者、環境の数をそろえます。
• 除外費用：クラウド、SSL証明書、監視ツール、外部API、決済手数料の扱いを確かめます。

極端に安い見積では、非機能要件、テスト、移行、文書、保守が抜けている可能性があります。一方で、高い見積でも、不要な段階から冗長化や24時間監視が含まれることがあります。

本番公開の条件、追加費用の条件、発注者側で準備するものを示してもらい、同じ前提で比べます。

提案時の質問によるプロジェクト管理力の確認

未確定の要件をどう進めるか、追加変更をどう管理するか、遅延や障害をいつ報告するかを確認します。担当者の経歴だけでなく、設計、実装、運用のメンバーやレビュー責任者、緊急時の代わりの要員まで聞きます。そのうえで、「できます」と答えるだけでなく、検証方法や前提条件を説明できる会社を選びます。

発注時に確認したいセキュリティと運用保守

Gunicornは、通信を受ける構成要素の一部にすぎません。そのため、TLSやWAF、認証認可、秘密情報、監査ログ、脆弱性対応は、別に設計します。

個人情報を扱う場合は、個人情報保護委員会の安全管理措置に沿って、権限や委託先の監督、ログ、バックアップ、事故連絡を確認します。

決済情報を扱う場合は、経済産業省が2025年3月に改訂したクレジットカード・セキュリティガイドラインも、確認先になります。

要件に含める信頼境界と入力検証

転送元のIPやプロトコル情報を無条件に信頼すると、アクセス制御や監査ログを誤るおそれがあります。

そのため、信頼境界と入力検証を受入条件に含め、次の点を確認します。

• 信頼境界：信頼ネットワーク、PROXY protocol許可元、TLS終端、管理画面の接続制限。
• 入力・認可：入力検証、SQLインジェクション、XSS、CSRF、認可制御の欠落。
• 対策の確認：IPA「安全なウェブサイトの作り方」を基礎資料にします。

納品後の更新・監視・障害対応

CPUやメモリ、ワーカー、DB接続を監視し、閾値を超えたら通知します。応答時間や5xxエラー、キュー滞留も監視の対象になります。

ワーカーが停止したときの自動再起動、ログの保存期間、段階的なリリース、ロールバックの方法は、手順書にまとめます。さらに、依存パッケージを更新するための検証環境を用意し、定期的な脆弱性スキャンとバックアップ復元を保守に含めます。

よくある質問（FAQ）

Gunicornの発注でよく聞かれる質問を、費用、技術選定、運用の観点から取り上げます。

Gunicornだけを導入する場合の費用はいくらですか？

GunicornはOSSなので、通常はライセンス費がかかりません。一方で、設定や既存アプリの改修、テスト、デプロイ、監視に費用がかかります。

既存環境の調査と本番への反映だけであれば、新規開発より小さくできます。ただし、TLSやWAF、負荷試験、CI/CD、障害対応を含めると、範囲が広がります。

見積では、Gunicornの設定費だけでなく、周辺構成と保守の有無も確認します。

Nginxやロードバランサーも発注する必要がありますか？

本番公開では、TLS終端、静的ファイル配信、アクセス制御、負荷分散を担うNginxやロードバランサーを前段に置く構成が一般的です。

必須となる要素は、利用形態やクラウドによって変わります。ただし、Gunicornだけをインターネットに直接公開する前提の見積は避けます。

RFPに公開経路と、誰がどこまでを受け持つかを書き、周辺サービスを含めた提案を受けます。

委託先にGunicornの実績がない場合は依頼できますか？

本番でDjango・Flask・FastAPIやDockerを扱った経験があれば、公開実績がなくても候補になります。クラウド、Nginx、CI/CD、監視の経験も確かめます。

構成の理由と検証方法を説明できるかを確認します。画面開発の経験だけで、負荷試験や障害対応、更新を説明できない場合は、慎重に判断します。

PoCと負荷試験を先に行い、実力を確かめてから本開発へ進む方法もあります。

まとめ

発注の対象は、Gunicornの設定だけでなく、Pythonアプリ、DB、クラウド、認証、監視、保守を含むシステム全体です。

仕様を固められる部分は請負型、検証しながら進める部分は準委任型とし、必要に応じて契約を分けます。

発注前の業務要件・非機能要件・責任分界の整理

発注条件と費用をそろえるため、見積の前提を次のとおり確認します。

• RFP：利用者、業務フロー、データ量、同時接続数、連携先、RTO・RPOを記載します。
• 委託・運用：セキュリティや納品物、保守範囲を明記します。
• 費用内訳：初期開発、クラウド、保守、追加変更を分け、根拠と除外項目を確認します。
• 推定相場：PoCは30万〜150万円、小規模は300万〜700万円、中規模は700万〜1,500万円です。
• 高可用性・基幹連携：1,500万〜5,000万円以上。どれも要件に依存する目安です。

本番運用と納品後まで見る委託先の選び方

委託先には、フレームワークとGunicorn・ASGIの選定理由や、負荷試験、監視、セキュリティ更新、障害対応について質問します。

ソースコード、Dockerfile、IaCの引渡しも確認します。技術選定と検証を説明でき、初期費用と運用費を分けて提示できる委託先であれば、公開後も安定して使えるシステムにつながります。

▼全体ガイドの記事
・Gunicornのシステム開発の完全ガイド

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