システム開発の提案書や見積書を確認していると、「ロードバランサー」という項目が費用の中に含まれていることがあります。開発会社から「サービスの高負荷に対応するため必要です」と説明を受けても、「そもそもロードバランサーとは何なのか」「なぜうちのサービスに必要なのか」「この費用は妥当なのか」といった点が判断できず、見積もりの承認を保留してしまうケースは少なくありません。
ロードバランサーは、インフラエンジニアにとっては当たり前の仕組みですが、システム発注者にとってはなじみの薄い概念です。技術的な説明は受けても、費用の妥当性や導入の必要性を非エンジニアが評価するための情報がなかなか見当たりません。
この記事では、ロードバランサーの基本的な概念を分かりやすく解説するとともに、「どんなサービス規模から必要になるのか」「費用はどのくらいが相場なのか」「開発会社への確認ポイントは何か」を発注者の視点から整理します。見積もりの判断基準として、ぜひ参考にしてください。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
ロードバランサーとは何か
ロードバランサーとは、インターネットから来るアクセス（トラフィック）を複数のサーバーに振り分ける「交通整理役」です。英語の「ロード（負荷）」と「バランサー（均等化するもの）」を合わせた名称で、負荷分散装置とも呼ばれます。
1台のサーバーで起きる問題
Webサービスやアプリケーションは、1台のサーバーで運営できる期間はシンプルで管理も楽です。しかし、ユーザー数が増えたり特定のタイミングにアクセスが集中したりすると、次のような問題が起きます。
- レスポンスが遅くなる: サーバーへの処理要求が増えすぎて、ページの表示が遅くなる
- サーバーがダウンする: 処理しきれない状態になるとサービスが停止する
- 単一障害点になる: サーバーが1台しかなければ、故障時にサービス全体が止まる
キャンペーン期間中のECサイト、チケット販売の受付開始直後、年末年始の会員制サービスなど、想定外のアクセス集中でサービスが止まった事例は多く存在します。
ロードバランサーが解決すること
ロードバランサーを導入すると、アクセス（トラフィック）が複数のサーバーに均等に振り分けられます。これにより以下の2点が実現できます。
可用性の向上 複数のサーバーが稼働しているため、1台が故障しても他のサーバーがカバーします。サービスが停止するリスクが大幅に低下します。
パフォーマンスの維持 アクセスが1台に集中しないため、処理能力を超えた過負荷状態になりにくくなります。急激なアクセス増加にも対応できます。
ロードバランサーは「アクセスを分散する装置」ではなく、「サービスの安定性と継続性を支える仕組み」と理解することで、見積もり上の価値がイメージしやすくなります。
詳しくはクラウドインフラとは？もあわせてご覧ください。
ロードバランサーが必要になる条件
「どのくらいのアクセス数から必要になるのか」というのは、発注者がもっとも知りたい情報の一つです。ただし、単純なページビュー数だけでは判断できません。重要なのは「同時アクセス数」と「アクセスの集中度」です。
同時アクセス数の目安
一般的なWebサーバー（メモリ2〜4GB、2コア程度）が安定して処理できる同時アクセス数はおよそ50〜200人程度が目安です（サーバーの性能やアプリケーションの処理内容によって大きく異なります）。
サーバー規模 | 目安の同時アクセス数 | 月間PVの目安 |
|---|---|---|
小規模（メモリ2GB、2コア） | 〜100人 | 〜30万PV |
中規模（メモリ4GB、4コア） | 〜200〜300人 | 〜100万PV |
大規模（専用サーバー・高スペック） | 300〜1,000人以上 | 100万PV〜 |
この目安を超えるアクセスが想定される場合、または超えた際にサービスへの影響が許容できない場合は、ロードバランサーの導入（= 複数サーバー構成）が検討対象になります。
サービス特性別の判断基準
同時アクセス数の目安に加えて、サービスの特性によっても判断基準が異なります。
ロードバランサーが特に必要になりやすいケース:
- ECサイト・通販サービス（セール・キャンペーン時のアクセス急増）
- チケット販売・予約サービス（販売開始時の集中アクセス）
- 会員制サービス（特定の時間帯や月初月末への集中）
- BtoB向けSaaS（契約上のSLA・稼働率保証が必要な場合）
シングルサーバーで対応できるケース:
- 月間数万PV以下の情報サイトやコーポレートサイト
- 管理者のみが使う社内ツールや管理画面
- アクセスの集中が起きにくいサービス
負荷分散（スケーリング）の仕組みを導入するかどうかは、サービスの性質と想定するユーザー規模によって判断が変わります。開発会社が提案する場合は、「どのようなシナリオでロードバランサーが必要と判断したか」を確認することが重要です。
ロードバランサーの種類：L4とL7の違い
見積書に「ALB」「ELB」「L7ロードバランサー」などの用語が出てくることがあります。これらはロードバランサーの種類を表しています。
L4（第4層）ロードバランサー
「ネットワーク層」と呼ばれるレベルで動作するロードバランサーです。IPアドレスやポート番号を基準にトラフィックを振り分けます。処理が高速で、単純なTCPトラフィックの分散に適しています。
L7（第7層）ロードバランサー
「アプリケーション層」で動作するロードバランサーです。URLのパス（例: /api/と/static/を別のサーバーに振り分ける）やHTTPヘッダー、Cookieの内容を基準に振り分けができます。現代のWebサービスはほとんどがL7ロードバランサーを使用しています。
AWSではALBが主流
クラウドインフラとしてAWSを使う場合、ELB（Elastic Load Balancing）という名称でロードバランサーサービスが提供されています。ELBには複数の種類がありますが、通常のWebサービス・APIサービスではALB（Application Load Balancer）が標準的な選択肢です。
種類 | 特徴 | 主な用途 |
|---|---|---|
ALB（Application LB） | L7対応、URL/ヘッダーで振り分け可能 | WebアプリやAPIサービス（最も一般的） |
NLB（Network LB） | L4対応、超高速・低レイテンシ | リアルタイムゲーム・金融系など特殊要件 |
CLB（Classic LB） | 旧世代、L4/L7両対応 | レガシーシステムの移行のみ（新規非推奨） |
一般的なWebサービスやSaaSを開発・運用する場合、見積書に「ALB」または「Application Load Balancer」と記載されていれば、標準的な選択です。
ロードバランサーの費用目安
ここからが、発注者がもっとも確認したい「費用」の話です。
クラウド型（AWS ALB）の費用
AWSのALBは、大きく「固定費（稼働時間）」と「変動費（LCU）」の2つで構成されます。
固定費（インスタンス料金） ALBを動かしている時間に対して課金されます。東京リージョンでは1時間あたり約0.0243USD（2024年時点）。
月額換算: 0.0243 USD × 24時間 × 30日 ≒ 17.5 USD ≒ 約2,500〜2,800円/月（為替レートにより変動）
（出典: AWS Elastic Load Balancing 料金表）
変動費（LCU料金） 実際のトラフィック量（接続数・帯域幅）に応じて課金されます。1LCUあたり約0.008USD/時間。通常の中小規模Webサービスでは、月額1,000〜5,000円程度の追加が目安です。
月額合計の目安
サービス規模 | 月額目安（ALBのみ） | 備考 |
|---|---|---|
小規模（月間数万〜十数万PV） | 3,000〜5,000円 | 固定費のみまたは少量LCU |
中規模（月間数十万〜100万PV） | 5,000〜15,000円 | LCU課金が加算 |
大規模（月間100万PV以上） | 15,000円〜 | トラフィック量に依存 |
重要な注意点: ALBの費用はロードバランサー本体の費用です。ロードバランサーを追加する際には、振り分け先のサーバー（インスタンス）も複数台必要になります。見積書全体の費用増加（サーバー台数増 + ロードバランサー費用）として確認することが必要です。
ハードウェア型の費用
AWSなどのクラウドを使わず、自社データセンターやオンプレミス環境で物理的なロードバランサー機器を導入する場合、初期費用として30万〜数百万円以上かかるケースがあります。現在はクラウド型が主流であり、新規のシステム開発でハードウェア型を選ぶことは少なくなっています。
見積書での費用項目の見方
開発会社からの見積書に「ロードバランサー」関連の費用が含まれる場合、以下の内訳に分かれることが一般的です。
- 初期設定費用: ロードバランサーの設定・構築にかかる作業費。数万〜十数万円が一般的
- 月額クラウド費用: AWS ALBなどのサービス利用料（上記の月額目安参照）
- サーバー費用の増加: ロードバランサー導入により増えるサーバー台数分のインフラ費用
これら3点の合計が見積書に記載されているかを確認することで、費用の内訳が把握できます。
開発会社への確認ポイント
見積書を受け取った際に、以下の質問をすると費用の妥当性を評価しやすくなります。
確認すべき3つの質問
① 想定同時アクセス数と判断根拠を聞く
「ロードバランサーが必要と判断した根拠となる想定アクセス数を教えてください」
この質問により、「月間○○万PV・同時アクセス○○人を想定しており、シングルサーバーでは対応しきれないと判断した」という具体的な根拠が得られます。根拠なく「念のため」という理由で提案されている場合は、再検討を求めることができます。
② ロードバランサーの種類と選定理由を確認する
「どの種類のロードバランサー（AWSの場合はALB/NLB等）を想定しており、その選定理由を教えてください」
一般的なWebサービスではALBが標準的です。NLBやその他の特殊な構成を提案される場合は、理由を確認しましょう。
③ 月額費用の内訳を確認する
「月額費用の内訳（固定費・従量費・サーバー追加費用）を教えてください」
ALBの固定費の相場（月額2,500〜2,800円）に加えて、トラフィック量や追加サーバーの費用がいくらになるかを確認します。総額が相場から大きく外れる場合は、その理由を質問することで妥当性を判断できます。
費用が相場と異なる場合のチェックポイント
費用が高すぎる場合の確認事項:
- 過剰なサーバー台数になっていないか（必要以上の台数を提案している可能性）
- 設定費用が適正かどうか（同規模の案件の相場と比較する）
- クラウド費用の見積もりが最大値で計算されていないか
費用が低すぎる場合の確認事項:
- ロードバランサーは提案されているが、振り分け先のサーバーが1台しかない場合（ロードバランサーを入れても意味がない構成になっている可能性）
- 冗長化（障害時の自動切り替え）の設計が省略されている場合
まとめ
ロードバランサーとは、複数のサーバーへアクセスを振り分ける負荷分散の仕組みです。サービスの高可用性（止まりにくさ）とパフォーマンス維持のために、一定規模以上のWebサービスでは標準的に採用されます。
発注者として見積もりを評価する際の3つのポイントをまとめます。
1. 必要性の確認: 同時アクセス数の根拠を開発会社に確認する。アクセス集中が想定されるサービスか、SLA要件があるかを判断軸にする
2. 費用の目安: AWSのALBを使う場合、月額2,500〜15,000円程度（サービス規模によって変動）が一般的な相場。これにサーバー追加費用が加わる
3. 確認のポイント: 「想定アクセス数の根拠」「種類の選定理由」「費用の内訳（固定費・変動費）」の3点を開発会社に確認する
ロードバランサーは「不必要に追加されるコスト」ではなく、「サービスの安定稼働に必要な投資」です。開発会社と費用根拠について建設的に確認し合うことで、適切な判断ができるようになります。
システム開発の費用を正しく理解するガイドブック――相場・見積チェックリスト・予算策定テンプレート付き
この資料でわかること
発注検討者がシステム開発の費用体系を正しく理解し、「この見積は適正か」「どのくらい予算を確保すれば良いか」を自分で判断できるようになること。
こんな方におすすめです
- システム開発の発注を初めて担当する方
- 複数社の見積もりを比較・評価したい方
- IT投資の社内稟議を通す根拠を固めたい方
入力いただいたメールアドレスにPDFをお送りします。
