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

HAProxyのシステム発注は、要件を整理し、PoCで検証したうえで、設計・構築、障害試験と引継ぎへ進みます。この順で進めると、認識違いを抑えた本番運用につながります。

各段階で決めることは、委託範囲と発注形態、RFPの要件、費用と契約、委託先の比較です。

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

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

HAProxyのシステム発注・外注の全体像

HAProxyは、クライアントからの通信を受け取り、複数のWebサーバーやAPIサーバーへ振り分けるリバースプロキシ・ロードバランサーです。

HAProxyは、サービスを安定して配信するネットワーク基盤で、アプリケーションそのものを開発する製品ではありません。そのため、発注の成否は設定ファイルの作成だけでなく、どこまで可用性と運用を設計したかで決まります。

外注する作業の範囲

外注する作業と社内で担う作業は、技術者と障害対応の体制に合わせて分けます。社内にLinuxやネットワークの担当者がいる場合は、設計と設定レビューだけを依頼できます。その場合、構築と日常運用を社内で行う方法もあります。

• 設計・設定：現状調査、要件定義、ネットワーク設計、HAProxy設定を委託する範囲です。
• 構築・試験：サーバーやクラウドの構築、TLS証明書の設計、監視、負荷試験、移行。
• 運用・保守：障害時の切り分けを担える人材がいない場合の、24時間365日の監視や緊急対応。

特に抜けやすいのは、証明書の更新、OSやHAProxyのアップデート、設定変更の承認です。ログ保存や障害時の連絡先も、誰が担うかを発注前に決めておきます。

これらを構築後の運用として別扱いにすると、本番後に追加費用や対応時間をめぐる問題が起こりやすくなります。そのため、RFPに委託作業と自社作業の境目を書き込みます。

目的と社内体制で選ぶ発注形態

発注形態は、要件がどこまで確かかと、社内にどれだけ体制があるかによって、PoC、請負、準委任を組み合わせて選びます。

• 初回導入：本番環境を一括で発注する前に、小規模なPoCで技術的な適合性を見ます。
• 要件が明確：変更が少なければ、設計・構築・試験をまとめて請け負う請負型が選びやすいです。
• 不確定要素が多い：Kubernetes、複数クラウド、段階移行などは準委任で調査と設計を行い、構築を請負に分ける方法です。

HAProxy TechnologiesのEnterpriseでは、製品サポートとSIerの設計・構築契約が別になる場合があります。AWS Marketplaceから導入する場合も、AWS利用料、HAProxy製品利用料、構築会社の作業費は同じ請求項目になりません。

製品ベンダー、クラウド事業者、構築会社が、それぞれどこまでを受け持つかを一枚の資料にまとめてから発注します。障害時のたらい回しを防ぐため、この資料で受け持ちの範囲を明らかにしておきます。

発注前に整理する要件とRFPの作り方

HAProxyの見積もりは、サーバー台数だけでは算出できません。通信量や接続先の数によって作業量は大きく変わり、プロトコルや冗長化方式、証明書の数でも変わります。さらに、監視のレベルや切替試験の有無も、見積もりを大きく左右します。

「速くしたい」「止めたくない」といった希望は、そのままでは測れません。そのため、RFPでは測定できる条件に置き換えて書きます。

現状構成とトラフィックの把握

接続経路と通信の種類を図にすると、構成の抜けに気づきやすくなります。サービスごとに、次の項目を整理しておきます。

• 接続経路：利用者から、HAProxy、Web・アプリ・APIサーバー、DB、外部SaaSまでの流れ。
• 既存機器：DNS、CDN、WAF、クラウドLB、ファイアウォールの配置と、TLS終端・アクセス制御の位置。
• プロトコル：HTTP、HTTPS、WebSocket、gRPC、TCP、UDPを確かめ、L4・L7の設計に反映します。

アクセス数は、月間の平均値だけでなくピーク時のリクエスト数と同時接続数も整理します。平均だけでは、混雑時の負荷を見誤るおそれがあるためです。さらに、1接続の継続時間や、リクエストとレスポンスのサイズも記録します。

業務システムでは、営業開始時の集中アクセスやバッチ処理が、ボトルネックになることがあります。また、キャンペーンの実施時や外部APIへの一斉接続も、負荷の要因になります。

可能であれば、過去のアクセスログから平常時とピーク時のP95応答時間を算出しておきます。そうすれば、複数の発注先が同じ条件で見積もれます。

可用性・性能・セキュリティの数値目標

可用性は、障害発生から通信が復旧するまでの時間で定めます。HAProxyを2台にするかどうかは、その時間を満たすための手段のひとつです。

• 停止と切替：「1台停止時もサービスを継続する」「切替は何秒以内」などの条件。
• バックエンド：停止後、何回の失敗で振り分け対象から外すか。
• 接続と配置：セッション維持の要否と、オンプレミスのKeepalived・VRRPか、クラウドの複数AZやマネージドLBか。

TLSの終端位置、許可するTLSバージョンと暗号スイート、証明書の更新方法を指定します。あわせて、秘密鍵の保管先と、統計画面や管理ソケットのアクセス元も決めておきます。

IPAの「TLS暗号設定ガイドライン」第3.1.1版は、2025年4月に公開されました。TLS 1.2・1.3やHSTS、証明書更新忘れの防止策などを扱っています（出典：IPA、2025年）。

個人情報をログに残す場合は、マスキングや保存期間、閲覧権限を決め、転送先もRFPに含めます。

RFPの成果物と受入条件

納品物と受入条件を指定しておくと、設定の意図や業務上の動作まで、委託先から引き継げます。

RFPには、前提情報、納品物、受入条件を書き分けます。

• 前提情報：対象環境、接続サービス、想定トラフィック、ネットワーク制約。加えて、希望スケジュール、予算の考え方、運用体制。
• 納品物：設計書、構成図、HAProxy設定ファイル、IaCコード。さらに、監視定義、ログ仕様、テスト計画書、障害時手順書、運用引継ぎ資料。
• 受入条件：正常系に加えて、ノード停止、バックエンド異常、遅延、5xx。さらに、ネットワーク断、証明書期限切れ、構文エラー、ロールバック。

設定ファイルだけが納品され、health checkやタイムアウト値の理由が分からないと、将来の変更で困ることがあります。

HAProxy公式の説明では、TCP接続だけを確認するhealth checkのほか、/healthzなどへHTTPリクエストを送って応答を見る方法もあります（出典：HAProxy公式Health checks、2026年確認）。

業務アプリケーションが実際に使えるかを確かめるには、単純なポート監視だけでは足りません。そのため、アプリケーション層のチェックも受入試験に含めます。

HAProxyのシステム発注を進める手順

要件を整理してから複数社に相談し、提案と見積もりを比べたうえで契約します。

技術的な難所が多いため、見積金額だけでなく、どの仮定に基づいた提案なのかを見極めます。本番化の前に何を検証するのかも、併せて話し合っておきます。

小さく検証し、その結果を設計に反映すると、過剰な構成や後戻りのリスクを抑えられます。

方式選定とPoCによる実現性の確認

Community版をLinuxサーバーや仮想マシンで運用するか、Enterpriseを使うか、マネージドLBと組み合わせるかを比べます。製品名だけでは優劣を判断できないため、必要な機能と運用責任を照らし合わせます。

• Community版：ライセンス費を抑えやすい一方で、設定やパッチ、監視と障害対応は自社か委託先が担います。
• HAProxy Enterprise：サポートやWAF、DDoS、Bot管理などを含む商用の選択肢で、価格は個別見積もりです。
• マネージドLB併用：クラウドのマネージドLBと組み合わせた構成。

PoCでは、代表的なWebやAPIを1〜2本つないで、ルーティングやTLS終端、health checkを試します。ログと監視、負荷、切替の確認も、あわせて行います。

WebSocket、gRPC、TCPの長時間接続がある場合は、接続維持と再接続、タイムアウト、セッションの扱いを確かめます。

採否の理由や想定性能、残課題は、文書にまとめておきます。本番化作業の内容も、同じ文書に含めます。

運用を見据えた設計・構築

本番構成では、HAProxyを単一障害点にしない設計が基本です。

• オンプレミス：2台のactive/standbyの組み合わせと、仮想IPの引き継ぎ方法。
• クラウド：複数AZへの分散と固定IPに加え、セキュリティグループ、データ転送、バックアップの設計。
• 設定変更：Git管理や事前レビュー、構文確認、段階リリース、ロールバックの手順。
• 管理と秘密情報：秘密鍵の保管先と権限を決め、統計画面やRuntime API、管理用ポートは、管理ネットワークや踏み台に限定します。

2台に増やしたあとは、片系停止時に名前解決とルーティングが機能するかを確かめます。証明書や監視、管理経路も、同じ試験で見ておきます。

秘密情報は、設定ファイルに秘密鍵を直接置かない形で保管し、アクセス権限も決めておきます。

委託先には、設定変更を安全に行う手順も、設計書に記してもらいます。

障害試験・移行・引継ぎ

通常のリクエストが通るかだけでなく、障害時の検知と復旧まで確かめます。受入試験では異常を実際に再現し、検知から復旧までの時間を計測します。

• 機器・通信：HAProxyの片系停止、バックエンド異常、急増トラフィック、ログ転送停止。
• 設定・証明書：health checkの誤判定、証明書の期限切れ、設定の反映失敗。
• 接続処理：drainやバックアップサーバー利用時の既存接続、再接続後の振り分け先。

移行は、DNSの切替やクラウドLBからの段階移行など、元に戻せる手順で進めます。切替の前に、設定バックアップとTTL、監視アラートを準備し、連絡網とロールバック条件も決めておきます。

移行の作業では、担当者が同時に動ける時間帯を確保しておきます。

引継ぎでは、構成と設定意図、監視項目と閾値を説明してもらいます。障害初動や月次作業、脆弱性確認の方法も、あわせて示してもらいます。口頭の説明だけでなく、運用担当者が実際に障害対応を行う演習も含めます。

契約形態とHAProxyのシステム費用相場

HAProxyの費用は、ソフトウェア料金だけでは判断できません。要件定義から構築、試験までの作業費に、クラウド利用料や監視、保守を加えて合算します。ここで示す金額は、HAProxy単体の公式定価ではありません。

金額は、リサーチノートで整理した業務システム開発の相場と、HA構成に必要な作業を分解した見積もりの目安です。通信量や既存環境、セキュリティ要件、運用時間で変わるため、予算取りのレンジとして使います。

構成規模ごとの初期費用レンジ

初期費用と期間は、構成規模と作業範囲によって異なります。

• PoC・検証：HAProxy 1台、基本ルーティング、TLS、簡易health check、負荷試験で50万〜150万円程度、2〜4週間程度。
• 本番HA：Web・API 2台構成で要件定義、証明書、監視、ログ、IaC、切替試験を含み、200万〜500万円程度、1.5〜3か月程度。
• 複数環境：複数AZ、Kubernetes、CI/CD、権限・監査を含む場合、500万〜1,500万円程度、3〜6か月程度。
• 大規模案件：多拠点、WAF・Bot対策、DR、24時間運用を含む場合、1,500万〜3,000万円以上の可能性があります。

既存ネットワークの調査や認証連携がある場合、PoC期間は延びます。

検証を省くと、プロトコルやログ要件のずれが後から見つかり、追加費用につながることがあります（出典：リサーチノート、業務システム開発全般の相場整理、2026年作成）。

ライセンス費とクラウド費の切り分け

製品料金と基盤・運用費は、分けて確認しておきます。

• HAProxy Community：ライセンス料は無償です。
• Enterprise：Communityのコアに、商用サポートや管理・セキュリティ機能を加えたもの。
• AWS Marketplace：AMIのソフトウェア利用料。

Community版でも、サーバーやOS、バックアップの費用がかかります。監視や通信、設計、保守にも、費用が必要です。

価格は要件に応じた個別見積もりです（出典：HAProxy公式Enterprise製品ページ、2026年確認）。

対象AMIはHAProxy Enterprise Basic Ubuntu Server 24.04です。

掲載ページ上で、推奨インスタンスのソフトウェア利用料が0.35米ドル/時間と表示されています（出典：AWS Marketplace、2026年確認）。

Enterpriseは、ノード数や帯域、利用モジュールを分けて見ます。SLAや契約期間も、あわせて確認します（出典：HAProxy公式Enterprise製品ページ、2026年確認）。

730時間で単純計算すると、約255.5米ドル/月になります。為替などを含む実際の支払額を断定するものではありません。

EC2やEBS、データ転送の料金に加えて、監視やバックアップ、冗長化した2台分も別途必要です（出典：AWS Marketplace、2026年確認）。見積書では、製品料金とクラウド基盤料金、構築作業費を分けて示してもらいます。

契約形態と保守費の範囲

請負と準委任は、納品物と要件の確かさに応じて選びます。変更の条件と対応範囲も、契約に記しておきます。

• 請負：成果物と完成条件を定めやすく、要件が固まった構築に向きます。追加要件は変更契約になりやすいため、前提や対象外、検収、瑕疵対応を明記します。
• 準委任：調査、助言、運用支援など、作業時間や専門知識の提供に適しています。成果物と対応時間を決めておきます。

保守費は、脆弱性対応やOS・HAProxyの更新、証明書の管理、設定変更のどこまでを含むかで変わります。一次対応や負荷試験、定例報告も、含めるかどうかで金額が動きます。

初期費用の年15〜25％を仮置きする考え方では、本番HAの初期費用200万〜500万円に対し、年30万〜125万円程度になります。

24時間365日のSLAやオンコール、WAF、SIEM連携、DR訓練を含む場合は、この幅に収まるとは限りません。別途見積もりが必要です（出典：リサーチノート、業務システム保守相場の整理、2026年作成）。

委託先の選定と見積比較のポイント

委託先には、製品の知識に加えて、ネットワークやLinux、TLSの理解が求められます。さらに、クラウドや監視、アプリとの境界まで理解できるかを見ます。

HAProxyは前段に置かれる基盤です。そのため、バックエンドの状態や業務上重要な処理を理解していなければ、health checkやタイムアウトを適切に設計できません。

障害の再現方法、原因を切り分けるログ、復旧判断の条件を、委託先に尋ねます。

構成と成果物まで見た実績の確認

HAProxyの構築年数だけでなく、どのような構成を担当したのかを質問します。顧客名を開示できない場合でも、規模や通信プロトコルなどを匿名化して説明できるかを確かめます。

• 構成経験：2台以上の切替、TLS再暗号化、API・WebSocket、Kubernetes、複数AZ、F5・NGINXからの移行。
• 匿名事例：規模、通信、障害試験、納品物、運用期間の情報。
• 引渡し：設計書、設定、IaC、監視、テスト、運用と証明書更新の手順、教育資料の作成者。

導入事例は、数字をそのまま自社に当てはめるより、構成の考え方を読み取るのに使います。

HAProxy公式のSNCF Connect事例では、HAProxy EnterpriseをCDNのエッジに置いています。月6,000万人の訪問者と毎秒50件超のチケット販売を扱った構成が紹介されており、旧来の有料モデルと比べて運用費を3分の2削減したとされています。

ただし、これは同社のCDNやキャッシュ、帯域、運用体制を含めた結果です（出典：HAProxy公式Success Story、2026年確認）。

自社の見積もりでは、処理量と配置、キャッシュ、監視、運用人数を分けて見ます。

設定やIaCは、委託先の環境だけに残さず、契約終了時に自社へ引き渡される形にしておきます。

再委託や担当交代時の引継ぎ、脆弱性の通知窓口も確かめておくと、長期運用のリスクを抑えられます。

見積書の比較単位（作業と前提条件）

複数社の見積もりは、総額の安さだけでなく、作業の範囲をそろえて比べます。A社が1台、B社が2台、C社がクラウドLB併用なら、同じ条件にそろえないと価格差に意味がありません。

• 構成前提：1台か2台か、クラウドLB併用かといった条件。
• 作業範囲：要件定義、PoC、設計、構築、試験。加えて、移行、文書、教育、保守を別に示します。
• 見積条件：作業時間、担当ロール、前提、対象外、追加時単価。

安い見積もりでは、障害試験や証明書更新、ログ設計が対象外になっていないかを確かめます。監視やロールバック、運用引継ぎも、対象外になっていないかを見ます。

逆に、不要な商用機能や過剰なインスタンスが含まれていないかも確かめます。

「この金額で、本番切替後の障害一次対応まで含まれますか」と質問します。

脆弱性が公表された際に、誰が通知を受けて修正版を適用するのかも尋ねます。契約終了時に設定とIaCを受け取れるかも、あわせて聞いておきます。

質問すると、金額には表れない差が見えてきます。

アップデートとセキュリティ対応の契約範囲

HAProxyは、導入後も利用中のバージョンのサポート期間を見ながら、OSの更新や設定変更、脆弱性対応を続ける必要があります。

• バージョン選定：新機能をすぐ使うより、自社のサポート方針や利用ライブラリ、試験環境、ロールバック手順に合う版を選ぶ。
• 脆弱性対応：監視担当、通知期限、影響調査、緊急パッチ、時間外対応、費用負担を、契約やSLAに定める。

HAProxy 3.4は2026年6月に公開され、動的バックエンドやHTTP/3・QUIC、OpenTelemetry、health checkなどが強化されました。内容はHAProxy公式「Announcing HAProxy 3.4」に記載されています（2026年）。

2026年2月には、QUIC処理に関するCVE-2026-26080とCVE-2026-26081が公表されました。影響を受けるバージョンでは、更新やQUIC無効化が案内されています（出典：HAProxy Technologies公式セキュリティアドバイザリ、2026年）。

「最新化は必要に応じて協議する」といった文言があると、緊急時に意思決定が遅れます。脆弱性の通知と対応について、担当者と期限を書面で定めます。

HAProxyのシステム発注でよくある質問

費用や構成は、個別の要件によって変わります。判断の基準を持っておくと、委託先への質問や見積もりの比較を進めやすくなります。

HAProxyは無料なので、発注費用も安くできますか？

Community版は無償ですが、発注費用が必ず安くなるとは限りません。

冗長化やTLS、監視、負荷試験のほか、脆弱性対応や障害時の保守にも、専門的な作業が必要です。

ライセンス費やクラウド費、構築費、保守費は、分けて見積もります。無償版を選ぶ代わりに、運用の責任を誰が担うのかを確かめてください。

HAProxyは1台と2台のどちらで発注すべきですか？

停止が許容できない本番では、原則として2台以上を検討します。ただし、2台にすれば必ず停止を防げるとは限りません。

• 冗長構成の試験：仮想IP、複数AZ、監視、切替条件、証明書、管理経路。
• PoC・検証：短期PoCや停止許容時間が明確な環境なら、1台で始められます。
• 本番化：本番化の条件に、冗長化を加えられます。

HAProxyの発注でRFPに最低限書く内容は何ですか？

対象サービスや現在の構成、通信プロトコル、ピーク同時接続数を書きます。さらに、可用性や切替時間、TLSやログ、監視の条件を記載します。加えて、希望納期と予算の考え方も入れます。

設計書、設定、IaCを納品物とし、監視定義や試験結果、障害手順も含めます。受入条件には、ノード停止とバックエンド異常を入れます。

未確定の項目は、その旨を記しておきます。PoCで決める内容と本番契約で決める内容を分けておくと、過度な断定を避けられます。

構築後の保守も同じ会社へ依頼するべきですか？

同じ会社へ依頼すると、構築時の判断理由を引き継ぎやすく、障害時の初動も速くなりやすいです。

保守を別会社に分ける場合は、どこまでを誰が受け持つかを明確にします。

設定やIaC、監視、手順書、問い合わせ先を、契約と納品物に記します。自社が一次対応を担うなら、二次対応時間や緊急連絡、脆弱性通知、更新支援の条件も定めます。

まとめ

発注では、設定の単価ではなく、安定した配信に必要な設計と試験、保守を一体にして比べます。Community版が無償でも、構築やクラウド、監視、セキュリティ対応の費用は別に発生します。

停止を許容できる時間や通信量、運用体制を整理し、同じ前提で複数社へ相談することが出発点です。

最初の一歩はRFPとPoCの準備

まず、現状の構成図やアクセスログを集めます。そのうえで、通信プロトコルと可用性・性能の目標を決め、TLSやログの方針もあわせてRFPに記します。

PoCの範囲や本番の冗長化、受入試験、納品物を明確にします。提案を受けたあとは、価格だけでなく、障害時の担当と所要時間も比べます。

契約が終わったときに、何が引き渡されるかも確かめます。そのうえで、設定と運用の知識を社内に残せる形で発注します。

運用を任せられる委託先の選び方

導入後の保守と引継ぎも含めて、契約の前に対応範囲を確かめます。

• 技術力：ネットワークやLinux、TLS、クラウドを横断して判断できること。アプリの状態や監視、セキュリティも、そのなかで見られること。
• 更新確認：HAProxy 3.4やQUIC関連の脆弱性など、導入後も更新と確認が続く点。
• 保守契約：脆弱性対応やバージョンアップ、証明書、障害試験を含むかどうか。
• 運用引継ぎ：要件と責任の範囲を明確にし、自社業務を理解して、設定と運用知識を渡せること。

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

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