APサーバーとは？Webサーバー・DBサーバーとの違いと3層構成、見積書の「台数」の読み方【2026年版】

「見積書に『APサーバー2台』と書いてあるのですが、これは何ですか」——開発会社の相見積もりを前にした担当者の方から、こうした相談をよく受けます。Webサーバーとは違うのか、なぜ2台なのか、1台ではいけないのか。会議では当たり前のように飛び交う語なのに、改めて聞くタイミングを逃したまま、構成図を眺めている。そういう場面は珍しくありません。

結論から言うと、APサーバー(アプリケーションサーバー)とは、リクエストに応じてプログラムを実行し、その場で結果を組み立てて返すソフトウェアです。Webサーバーとの分かれ目は「静的か動的か」の1点で、できあいのファイルをそのまま返すのがWebサーバー、注文を受けてから作って返すのがAPサーバーです。そして「サーバー」という名前が付いていても、これは機械の台数ではなく役割の名前です。小規模なシステムでは1台に同居していますし、クラウドのマネージドサービスを使えば「台数」という単位そのものが構成図から消えます。

この区別が付くと、構成図の読み方が変わります。「Webサーバー1台/APサーバー2台/DBサーバー1台」という記述は、単なる部品表ではなく、どこに負荷が来ると見込み、どこを守り、どこを増やせるようにしたかという設計の説明になります。逆にこの区別が付かないまま「一式」と書かれた見積もりと比べると、中身が見えないほうが安く見えてしまう。これは失敗のもとです。

本記事では、APサーバーの定義と実際にやっていること、Webサーバーとの違い(静的と動的)、DBサーバーとの役割分担とWeb/AP/DBの3層構成が生まれた理由、1台にまとめるか分けるかの判断、代表的な製品と実行環境、クラウドとコンテナで何が変わったか、スケールのさせ方とセッションの置き場所、そして見積書や構成図にAPサーバーが出てきたときに発注者が確認する5点の順に解説します。製品の設定手順は扱いません。用語の定義や製品の位置づけは、各製品の公式ドキュメントを2026年9月15日に直接確認し、確認先を明記しています。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。相見積もりの相談で頻繁に起きるのは、「APサーバー2台」と正直に書いた会社が高いという理由で外され、残った会社が実は1台構成だった、というすれ違いです。この記事を読み終えるころには、構成図のどこを見て、開発会社に何を聞けばよいかが分かるはずです。

APサーバー(アプリケーションサーバー)とは——リクエストに応じてプログラムを実行し、その場で結果を組み立てて返すソフトウェア

APサーバーは「アプリケーションサーバー(Application Server)」の略で、読み方は「エーピーサーバー」です。役割を一文で言えば、利用者からのリクエストを受けてプログラムを実行し、その場で結果を組み立てて返すソフトウェアということになります。「サーバー」という語が付いているため専用の機械を想像しがちですが、指しているのは機械ではなく役割です。ここを最初に押さえておくと、この先の話がずっと楽になります。

一文で言うと「動的な処理を担当する層」

たとえばECサイトで「カートを見る」を押したとき、画面に出るのはあなたのカートの中身です。同じURLでも、人によって、時間によって、出てくる中身が変わります。この「その場で中身を決めて作る」仕事を引き受けているのがAPサーバーです。あらかじめ作っておいたファイルを渡すのではなく、注文を受けてから在庫を見に行き、金額を計算し、画面を組み立てて返す。これが動的な処理です。

Oracleは自社のWebLogic Serverを「Jakarta EEアプリケーションを構築・デプロイするためのアプリケーションサーバー」と説明し、その中身としてクラスタリング、セッション管理、永続化、セキュリティといったコンテナサービスを挙げています(2026年9月15日確認)。つまりAPサーバーとは、アプリケーションを動かす箱と、動かすために必要な共通の仕組みをまとめて提供するもの、という位置づけです。

APサーバーが実際にやっている4つのこと

抽象的な定義だけでは輪郭がつかみにくいので、実際に引き受けている仕事を4つに分けます。

4番目の「状態の保持」は、後半のスケールの話で必ず戻ってくる論点です。APサーバーが利用者ごとの状態を持っているという事実が、「台数を増やせば速くなる」という素朴な理解を裏切ります。

ソフトウェアの3階層でいうとミドルウェア——「サーバー」は機械ではなく役割の名前

ソフトウェアは、基本ソフト(OS)、ミドルウェア、応用ソフト(アプリケーション)の3階層で整理されます。APサーバーはこの真ん中、ミドルウェアにあたります。OSの上で動き、その上で自社のアプリケーションを動かすための土台です。この3階層そのものについては「ソフトウェアとは」の記事で扱っていますので、階層の全体像を知りたい方はそちらをご覧ください。

そして繰り返しになりますが、APサーバーは役割の名前です。1台の機械の上でWebサーバーとAPサーバーとデータベースが同居していることは、小規模なシステムではごく普通にあります。逆に、1つの役割が何十台にも広がっていることもあります。構成図に「APサーバー」と書かれていたら、それは「動的処理を担当する部分」を指しているのであって、機械が1台あるとは限らない。では、その隣に書かれている「Webサーバー」とは何が違うのか。ここが最大の混同点なので、章を改めて説明します。

WebサーバーとAPサーバーの違い——分かれ目は「静的」と「動的」。1台に同居していることも多い

この2つの区別が付かないまま先に進むと、3層構成も、台数の話も、すべてぼやけます。逆に言えば、ここさえ通れば残りは応用です。分かれ目は1点だけで、あらかじめ用意されたファイルをそのまま返すのがWebサーバー、その場で作って返すのがAPサーバーです。以下、その1点を具体物に落とし、各製品が公式にどう名乗っているかを確かめ、最後に「実務では前後に並んでいる」という現実を押さえます。

静的と動的——できあいの弁当を渡すか、注文を受けてから作るか

静的コンテンツとは、誰がいつアクセスしても中身が同じファイルのことです。HTMLファイル、CSSファイル、画像、JavaScriptファイル、PDFなどが該当します。これらはサーバー上に置いてあるものをそのまま返すだけなので、処理としては軽く、回数は非常に多い。1ページ表示するだけで画像やCSSを何十個も取りに来ます。

動的コンテンツとは、リクエストのたびに中身が変わるもののことです。ログイン後のマイページ、検索結果、カートの中身、在庫数、金額の計算結果。これらは誰かがどこかで計算しないと存在しません。データベースに問い合わせ、条件で絞り込み、並べ替え、表示用に整える。処理としては重く、状態を持ち、失敗したときの後始末も必要です。

コンビニに例えるなら、Webサーバーは棚に並んだできあいの弁当を渡す役、APサーバーは注文を受けてから厨房で作る役です。どちらが偉いという話ではなく、求められる能力が違うだけです。棚係には広い棚と素早い手が要り、厨房には火力と手順とレシピが要る。だから別の名前が付いています。

公式ドキュメントはそれぞれをどう名乗っているか

解説サイトごとに書いてあることが違うと感じたら、製品自身の言葉に戻るのが確実です。2026年9月15日に各公式サイトで確認したものを並べます。

• nginx: 自らを「HTTP web server, reverse proxy, content cache, load balancer, TCP/UDP proxy server, and mail proxy server」と説明しています。Webサーバーであると同時に、リバースプロキシとロードバランサーを兼ねると明言しているのが特徴です
• Apache HTTP Server: プロジェクトの説明では「HTTP(Web)サーバーの実装を作る共同開発の取り組み」と位置づけられています。モジュールで機能を足す構造を持ち、CGIやmod_perlといった動的処理の入口も用意されています
• Apache Tomcat: 「Jakarta Servlet、Jakarta Pages、Jakarta Expression Language、Jakarta WebSocket、Jakarta Annotations、Jakarta Authentication の各仕様のオープンソース実装」と名乗っています。最新の安定版は11系で、Tomcat 10以降はJakarta EE、9以前はJava EEの仕様に基づくという境目があります

注目したいのは、Tomcat公式サイトのこの説明文に「Webサーバー」とも「アプリケーションサーバー」とも書かれていないことです。この点は製品を扱う章で改めて取り上げます。

実務では前後に並ぶ——リバースプロキシとしてのWebサーバーと、静的ファイルの肩代わり

実際の構成では、WebサーバーとAPサーバーは「どちらか」ではなく前後に並びます。外からのリクエストをまずWebサーバーが受け、静的ファイルなら自分で返し、動的処理が必要なものだけAPサーバーへ転送する。この転送役を担うWebサーバーをリバースプロキシと呼びます。

これは理屈の上の話ではありません。AWSのElastic Beanstalkでは、Tomcatプラットフォームについて「Tomcatはnginxのプロキシサーバーの後ろで動く」と明記されており、プロキシサーバーはnginxが既定、Apache HTTP Serverも選べます。さらに、ソースコード内のフォルダを指定して静的ファイルをプロキシ側から直接返し「アプリケーションの負荷を減らす」設定が用意されています(2026年9月15日確認)。Webサーバーが前に立ち、静的ファイルを肩代わりし、動的処理だけを後ろへ流す——これがクラウドの既定構成にもそのまま入っているわけです。

Microsoftも同じ構図を説明しています。ASP.NET CoreではKestrelが既定のWebサーバーですが、IIS・nginx・Apacheをリバースプロキシとして前に置く構成と、Kestrelを直接インターネットに面させる構成の「どちらの構成もサポートされる」としています(2026年9月15日確認)。つまり前に何かを置くかどうかは要件次第で、必須ではありません。

「フロントエンド/バックエンド」との違い——あちらは職種、こちらはミドルウェア

混同されやすいのでひとこと添えておくと、フロントエンドとバックエンドは主に「担当する領域と職種」の分け方で、WebサーバーとAPサーバーは「ミドルウェアの役割」の分け方です。バックエンドエンジニアが書いたプログラムが動く場所がAPサーバー、という関係になります。人と体制の分かれ方については「フロントエンドとバックエンドの違い」の記事で扱っていますので、発注時の体制や見積もりの分かれ方を知りたい方はそちらをご覧ください。

ここまでで、「WebサーバーとAPサーバーは別の機械でなければならない」というのが誤解だと分かります。役割として別、機械としては同居することもある。では、なぜわざわざ分けた構成が標準として語られるのか。その理由は、3つ目の層であるDBサーバーを含めて考えると見えてきます。

DBサーバーとの役割分担と、Web/AP/DBの3層構成が生まれた理由——1台に集約するか分けるかの判断

Web・AP・DBの3つを並べた図は「Web3層構成」と呼ばれ、Webシステムの標準形として紹介されます。ただ、標準形だからそうする、では判断になりません。なぜ3つに分けたのか、分けると何が良くて、分けなければ何が困るのか。ここを理解すると、自社の案件で分けるべきかどうかを自分で判断できるようになります。

3層の役割の対比表——何を持ち、何が増えると苦しくなるか

この表の右2列が、3層に分ける理由をほぼ説明しています。苦しくなる原因が層ごとに違い、壊れたときの深刻さも違う。だから別々に扱いたい、というのが出発点です。

なぜ分けたのか——増え方が違う、守り方が違う、直す範囲が違う

1. 増え方が違うから、増やす単位を分けたい。 静的ファイルへのアクセスが10倍になってもDBの負荷はほとんど変わりません。逆に、検索機能だけが重いならAP層とDB層だけを強化したい。1台に全部入れていると、どこか1か所が苦しいだけで機械全体を買い替えることになります。分けておけば、苦しい層だけを増やせます。

2. 守り方が違うから、置き場所を分けたい。 インターネットに面してよいのはWeb層までで、データベースは外から直接触れないところに置きたい。AWSがAmazon RDSのドキュメントで示している典型構成でも、ロードバランサーがアプリケーションサーバーへ振り分け、アプリケーションサーバーはパブリックサブネット、DBインスタンスはプライベートサブネットに配置され、「サブネットがプライベートであるため、インターネットからのリクエストは一切許可されない」と明記されています(2026年9月15日確認)。層を分けることが、そのままネットワークの壁になります。

3. 直す範囲が違うから、改修の影響を分けたい。 画面のデザイン変更でデータベースを止める必要はありませんし、業務ロジックの修正でWebサーバーの設定を触る必要もありません。層が分かれていれば、直す場所と止める場所を限定できます。

そしてもう1つ、発注者の視点で見落とされがちな理由があります。責任と契約の境目を引きやすいということです。データベースの運用は自社、アプリケーションは開発会社、というように、層で区切れば担当を分けられます。1台に同居していると、障害が起きたときに誰が何を見るのかが曖昧になります。

1台にまとめる構成と分ける構成の判断——分けるべき5つのサイン

とはいえ、最初から分けるのが正解とは限りません。分ければ機械の台数が増え、その分だけ費用も運用の手間も増えます。当社が相談を受けたときに見ているのは、次の5点です。

1. 同時に使う人数が多いか、波が大きいか。 社内で10人が使う業務システムと、キャンペーンで一気にアクセスが来るECサイトでは前提が違います。波があるなら、AP層だけを増やせる形にしておく価値があります
2. 止まると業務や売上が止まるか。 数時間止まっても翌日取り返せるなら1台構成で十分です。止められないなら、少なくともAP層は2台以上にして、1台落ちても動く形が要ります
3. 外部に公開するか、社内限定か。 インターネットに公開するなら、データベースを外から見えない場所に置く構成が要ります
4. 扱うデータの機微性。 個人情報やカード情報を扱うなら、層の分離はセキュリティ要件として求められることがあります
5. リリースの頻度。 週に何度もアプリケーションを更新するなら、更新のたびに全部を止めない形にしておきたい

このうち2つ以上が当てはまるなら分ける構成を、1つも当てはまらないなら1台構成から始めて、必要になったら分けられる設計にしておく——というのが、私が発注者の方にお伝えしている目安です。「標準構成だから3台」という説明だけで台数が決まっているなら、そこは確認したほうがよいところです。

代表的なAPサーバーと実行環境——「Tomcatはアプリケーションサーバーか」で公式の表記が割れている

ここからは製品名の話です。ただし、どれを選ぶべきかを論じるつもりはありませんし、設定の手順も扱いません。発注者にとって必要なのは、構成図や見積書に出てきた製品名がどの系統に属するかを見分けられることです。そしてもう1つ、この分野には「同じ製品を人によって違う言葉で呼ぶ」という厄介な事情があります。それも含めて整理します。

主な製品・実行環境の一覧(2026年9月時点・各公式サイトの表記)

以下は2026年9月15日に各公式サイトで確認した内容です。「公式の自己紹介」の列は、製品自身が名乗っている言葉をそのまま要約しています。

この表を眺めると、製品は大きく3系統に分かれることが分かります。(a) Jakarta EEというJavaの企業向け仕様を丸ごと実装するもの(TomEE、WildFly、WebLogic)、(b) そのうちサーブレット周辺だけを実装するもの(Tomcat)、(c) 独立した製品ではなくアプリケーションの中に組み込んでしまうもの(Spring Boot)。なお、Jakarta EE Platform 11の仕様ページは、このプラットフォームを「Jakarta EEアプリケーションをホストする標準プラットフォームを定義するもの」と説明しており、用途に応じてWeb ProfileとCore Profileという小さめの版も用意されています(2026年9月15日確認)。

Tomcatをどう呼ぶのが正しいか——公式表記が割れている事実ごと押さえる

さて、本題です。「Tomcatはアプリケーションサーバーですか、サーブレットコンテナですか」という質問には、2026年時点でも決着していません。理由は単純で、判断の根拠になる公式表記そのものが割れているからです。

• Tomcat公式サイトの製品説明は「各仕様のオープンソース実装」であり、そこに「アプリケーションサーバー」という語は使われていません
• TomEE公式は「We start with Apache Tomcat, add our jars, and zip up the rest. The result is Tomcat plus EE features - TomEE」と説明しています。Tomcatに機能を足したものがJakarta EEアプリケーションサーバーだ、という書き方であり、裏を返せばTomcat単体はJakarta EE全体を満たしていないことになります
• WildFly公式は「application runtime」と名乗り、「application server」という語を避けています
• 一方でOracleは、WebLogic Serverを明確に「アプリケーションサーバー」と呼んでいます

つまり、「アプリケーションサーバー」という語を広く取れば(=動的処理を実行する実行環境という意味なら)Tomcatも含まれ、狭く取れば(=Jakarta EEのフルスタックを実装したものという意味なら)Tomcatは含まれず、サーブレットコンテナと呼ぶのが妥当、ということになります。どちらの使い方も実務で通用しており、どちらかを間違いと言い切ることはできません。

発注者として押さえておくべきは、正解を1つ覚えることではありません。同じ語を人によって違う広さで使っているという事実です。会議で「これはアプリケーションサーバーではない」と言われたときに、それが「Jakarta EEのフル実装ではない」という意味なのか、「動的処理をしない」という意味なのかを聞き返せれば十分です。

近年は「アプリに組み込む」形が増えた——Spring Bootの組み込みサーバーとKestrel

もう1つ、構成図の読み方に効く変化があります。かつてはAPサーバーという製品を先に用意し、そこにアプリケーション(WARファイル)を配置するのが標準でした。現在は、アプリケーションの中にサーブレットコンテナを組み込み、そのまま起動する形が増えています。Spring Bootは組み込みのTomcatとJettyをサポートし、既定では8080番ポートで待ち受けます。.NETのKestrelも、アプリケーションと同じプロセス内で動くHTTPサーバーです。

この変化のせいで、構成図に「APサーバー」という独立した箱が描かれないことが増えました。描かれていなくても動的処理の層は存在します。箱がないのではなく、アプリケーションの箱の中に入っているだけです。定義が割れる語を扱うときは、断定せずに出典と前提を添えて話す。これが、この分野で誤解を避ける唯一の方法だと考えています。

クラウドとコンテナで3層の輪郭はどう変わったか——スケールのさせ方とセッションの置き場所

ここまでの説明は、機械が何台あるかを数えられる世界の話でした。クラウドのマネージドサービスやコンテナを使うと、この前提が変わります。ただし変わるのは「管理の仕方」と「数え方」であって、動的処理を実行する層そのものが消えるわけではありません。何が変わって何が残るのかを切り分けます。

マネージドサービスでは「台数」が消える——App ServiceとElastic Beanstalkの実際

Azure App Serviceは、Microsoftの説明では「基盤となるインフラの管理を気にせずWebアプリケーション、モバイルバックエンド、RESTful APIを実行できるプラットフォーム」です。対応する実行環境として、.NET、Node.js、Python、PHPと並んで「Java(Java SE、Tomcat、JBossの各形態)」が挙げられています(2026年9月15日確認)。ここで注目したいのは、Tomcatという名前は残っているのに、何台のTomcatが動いているかは利用者が意識しないという点です。

AWSのElastic Beanstalkも同様で、「アプリケーションをデプロイすると、EC2インスタンスのプロビジョニング、ロードバランシングの設定、ヘルスモニタリングの設定、環境の動的なスケーリングを行う」と説明されています。前章で触れたとおり、Tomcatプラットフォームではnginxが既定のプロキシとして前に立ちます。3層の構造はそのまま残っているのに、利用者が指定するのはインスタンスの種類と数の範囲だけになる、という形です。

データベース側も同じです。Amazon RDSは「バックアップ、ソフトウェアのパッチ適用、障害の自動検出と復旧を管理する」マネージドサービスで、OSのインストールやパッチ、ハードウェアのライフサイクルはAWS側の責任範囲だと明記されています(2026年9月15日確認)。DBサーバーという層は残るが、サーバーの世話はしなくてよい、ということです。

結論として、クラウドで消えるのは「サーバーの管理」であって、「動的処理を実行する層」ではありません。 構成図から箱が消えたら、それは層がなくなったのではなく、名前が変わっただけです。

スケールは2方向——垂直(1台を強くする)と水平(台数を増やす)

APサーバーが処理しきれなくなったときの手当ては、大きく2方向しかありません。

DBサーバーは水平に増やすのが難しい層です(読み取り専用の複製を増やす形が中心になります)。一方、AP層は本来もっとも水平に増やしやすい層です。「本来」と書いたのは、条件があるからです。

水平に増やす前に決めること——セッションの置き場所3通り

第1章で触れたとおり、APサーバーは利用者ごとの状態(セッション)を持ちます。ログイン中かどうか、カートに何が入っているか。これを各APサーバーが自分のメモリの中に持っていると、台数を増やした瞬間に問題が起きます。1回目のリクエストは1号機に、2回目は2号機に振られ、2号機は「あなたが誰か」を知らない。結果はログアウトです。

対処は3通りあり、どれを選ぶかで運用も費用も変わります。

これも公式ドキュメントで裏が取れます。AWSのApplication Load Balancerは、ロードバランサーが生成するAWSALBというCookieで同じターゲットへ振り分ける方式(期間ベースのスティッキーセッション)を提供しており、期間は1秒から7日まで、既定は1日です。ただしAWSは、ターゲットが不健全になった場合は別の健全なターゲットへ振り替えられ、そのまま新しいターゲットに固定されると説明しています(2026年9月15日確認)。つまり1番の方式は、落ちたときにセッションが守られるわけではありません。

2番については、Tomcatのクラスタリングの公式文書が具体的です。全ノードに複製するDeltaManagerは「4ノードを超えるクラスタには推奨しない」とされ、ノード数が増えたら1つのバックアップノードにだけ複製するBackupManagerへ移行するよう勧められています。加えて、セッションに入れる値はすべてjava.io.Serializableを実装している必要があり、web.xmlに<distributable/>要素が要るといった前提条件も明記されています(2026年9月15日確認)。「台数を増やすだけ」では済まないことが、公式文書からも読み取れます。

当社ではAWS認定資格11冠のメンバーが構成設計を担当しており、介護記録SaaS「CareViewer」のように継続的に機能が増えていくサービスでは、最初から大きく組まず、利用が伸びた段階で水平に増やせる形にしておく提案をしています。セッションの置き場所を先に決めておくかどうかで、増設が「設定変更」で済むか「作り直し」になるかが変わるためです。

なお、コンテナやマイクロサービスとして分割する話、本番反映の手順、落ちたときの一次対応は、それぞれ別の記事の領域です。サービス分割の設計は「マイクロサービスとは」の記事、本番反映の流れは「デプロイとは」の記事、障害が起きたときの動き方は「サーバー障害の原因と対応」の記事をご覧ください。ここまで読んだうえで、自社の構成は垂直と水平のどちらで伸ばす前提になっているでしょうか。

見積書やインフラ構成図に「APサーバー」が出てきたら——確認する5点と、台数が費用に効く理由

ここからが、この記事を書いた本当の理由です。用語の意味が分かっても、目の前の見積書が妥当かどうかは判断できません。発注者が握るべきは製品名でも設定値でもなく、台数と費用の関係、そして将来増やせるかどうかです。技術の決定は開発会社に任せてよい。ただし、任せる前に聞いておくことがあります。

発注者が確認する5点(そのまま質問に使えるチェックリスト)

このうち発注者にとって効くのは3番と4番です。3番は将来の費用を、4番は今回の見積もりの前提をそろえるための質問です。

台数が費用に効く理由——本番以外の環境、監視・保守、ライセンスがすべて台数に連動する

「APサーバーを1台増やす」と聞くと、増えるのはサーバー1台分の利用料だけだと思われがちです。実際にはそうなりません。台数に連動して増えるものが複数あります。

1. サーバー自体の利用料。 クラウドならインスタンスの時間単価×台数。これは分かりやすい部分です
2. 本番以外の環境の分。 検証環境やステージング環境を本番と同じ構成で用意するなら、台数の増加はそのまま環境の数だけ掛け算になります。逆に、検証環境だけ1台構成にするという判断もできます
3. 監視・保守の対象数。 保守契約が対象サーバー台数で決まっている場合、台数が増えれば月額も上がります
4. ソフトウェアのライセンス。 商用のAPサーバー製品を使う場合、ライセンス費用がCPU数やコア数に紐づくことがあります。オープンソースのTomcatなどを使うか、商用製品を使うかで構造が変わります
5. 構築とテストの工数。 台数が増えれば設定と確認の作業も増えます。初期費用側に乗ります

見積書の読み方全般、工程と工数と単価の分解については「システム開発の見積もりの内訳」の記事で扱っていますので、インフラ費以外も含めて比べたい方はそちらをご覧ください。

ここで、私が現場でよく見るすれ違いを1つ挙げます。相見積もりの相談で、「Webサーバー1台/APサーバー2台/DBサーバー1台(冗長構成)」と台数を明記した会社が、金額が高いという理由で候補から外れ、「アプリケーション実行環境 一式」としか書かなかった会社が残る。ところが後から中身を聞くと、残ったほうは全部1台に同居する構成で、可用性の担保がなかった——という例です。一度や二度ではありません。「一式」と書かれた見積もりは、中身が見えないぶん安く見えます。台数を明記した会社が高く見えるのは、見えているものを数えているだけ、というのが実情です。比べるときは、まず台数と環境数をそろえてから金額を並べてください。

構成の決定を開発会社に任せるとき、発注者が握っておく3つ(当社の場合)

インフラ構成の設計そのものは、専門家に任せてよい領域です。発注者が製品を選び直す必要はありません。ただし、任せきりにしないために握っておく項目が3つあります。

1. 台数と月額の対応関係。 「この構成で月いくら」ではなく、「APサーバーを1台増やすと月いくら増える」という形で聞いておく。将来の意思決定が数字でできるようになります
2. 増設の余地。 利用が伸びたときに、設定変更で増やせるのか、アプリケーションの改修が要るのか。前章のセッションの置き場所がここに効きます。最初に決めておけば安く済み、後から直すと高くつきます
3. 責任の範囲。 どこまでが開発会社の保守対象で、どこからが自社かを文書に残す。障害のときに初めて確認するのでは遅く、これは要注意です

当社(TALENTBASE VIETNAM)は、日本人PMまたはブリッジSEをフロントに置き、ベトナム・ホーチミンの開発チームと組む体制を提供しています。構成設計にはAWS認定資格11冠のメンバーが入り、最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名から契約でき、増員は約1週間、縮小・交代は1か月単位で調整できます。エンジニアは2,000名以上の自社人財データベースから直接アサインするため、協力会社を経由する仲介マージンが乗りません。介護記録SaaS「CareViewer」では日本語対応のブリッジSE1名+フルスタックエンジニア2名の体制で、機能が増えていく前提の構成で継続開発を担当しています。

一方で、向かない案件もあります。すでに社内に構成設計ができる人がいて、手だけが足りない場合は、体制ごと預けるより人単位で補うほうが早い。既存システムの構成が文書化されておらず、現行の把握から始める必要がある案件も、初期に相応の時間がかかります。そうした場合はその旨を率直にお伝えします。まずは、手元の見積書を開いて、上の5つの質問のうち3番と4番を聞いてみてください。それだけで比較の土台がそろいます。

【FAQ】APサーバーに関するよくある質問

APサーバーについて、発注側の担当者の方から実際に受けることの多い質問を5つまとめました。技術的な正確さと、発注判断に使えるかどうかの両方を意識して短く答えます。

Q1. WebサーバーとAPサーバーは必ず分けなければいけませんか

いいえ。役割としては別ですが、1台の機械に同居させても問題なく動きます。社内の少人数で使う業務システムなら、同居構成で十分なことが多いです。分けたほうがよいのは、同時アクセスが多い、止められない、インターネットに公開する、機微なデータを扱う、リリースが頻繁、のうち2つ以上が当てはまる場合です。

Q2. Tomcatはアプリケーションサーバーなのですか

公式の表記が割れているため、断定できません。Tomcat自身は「Jakarta Servletなどの仕様のオープンソース実装」と名乗り、アプリケーションサーバーとは名乗っていません。Jakarta EEのフル実装を指してアプリケーションサーバーと呼ぶ立場ならTomcatは該当せず、動的処理の実行環境という広い意味なら該当します。会議で意見が割れたら、どちらの意味で使っているかを確認するのが早道です。

Q3. APサーバーは何台必要ですか

要件が分からなければ答えられない、というのが正直なところです。目安としては、止まると業務や売上が止まるサービスなら2台以上(1台落ちても動く形)、社内向けで数時間なら止まってもよいなら1台から始める、という考え方をします。大事なのは初期の台数より、増やしたいときに増やせる設計になっているかどうかです。

Q4. クラウドを使えばAPサーバーは不要になりますか

不要になるのはサーバーの管理であって、動的処理を実行する層そのものは残ります。Azure App Serviceの対応環境にTomcatやJBossの名前が残っているのがその証拠です。構成図から箱が消えても、アプリケーションの中や、マネージドサービスの内側に同じ層が存在しています。

Q5. 非エンジニアの発注担当者は、どこまで理解しておけばよいですか

設定手順や製品選定は不要です。押さえるべきは3つ。静的と動的の違いでWebサーバーとAPサーバーが分かれること、台数は役割ではなく設計の結果であること、そして台数が本番以外の環境や保守費にも連動すること。この3つが分かれば、開発会社への質問と見積書の比較は十分にできます。当社では日本人PMがこうした前提の説明から入り、1名からの体制で、最短2週間での開始にも対応する運用。

まとめ: APサーバーは動的処理を担当する層——違いは静的と動的、台数は設計の結果

APサーバー(アプリケーションサーバー)とは、リクエストに応じてプログラムを実行し、その場で結果を組み立てて返すソフトウェアです。Webサーバーとの分かれ目は「静的か動的か」の1点で、できあいのファイルをそのまま返すのがWebサーバー、注文を受けてから作って返すのがAPサーバー。そしてDBサーバーを加えた3層構成は、負荷の増え方・守り方・改修の範囲が層ごとに違うからこそ分けられています。分けるべきかどうかは、同時アクセス、可用性、公開範囲、データの機微性、リリース頻度の5つのうち2つ以上が当てはまるかで判断してください。

製品名については、公式の表記が割れている点を押さえておくと安全です。Tomcatは自らを「Jakarta Servletなどの仕様の実装」と名乗り、TomEEは「Tomcatに機能を足したものがJakarta EEアプリケーションサーバー」と説明し、WildFlyは「application runtime」と名乗り、Oracleだけが明確に「アプリケーションサーバー」と呼んでいます(いずれも2026年9月15日に公式サイトで確認)。近年はSpring Bootのようにアプリケーションの中へ実行環境を組み込む形が主流で、構成図からAPサーバーという箱が消えていることもあります。クラウドのマネージドサービスでも同じで、消えるのはサーバーの管理であって、動的処理を実行する層そのものではありません。水平に台数を増やす前に、セッションの置き場所(同じ台に固定する・台どうしで複製する・外部に出す)を決めておくことが前提になります。

発注者として握るべきは、製品名でも設定値でもありません。台数の根拠、1台構成との差額、増設の余地、本番以外の環境の扱い、運用の責任範囲。この5点を聞ければ、相見積もりの土台がそろいます。台数は本番のサーバー代だけでなく、検証環境の分、監視・保守の対象数、ライセンス数にも連動して月額に乗るためです。開発体制の分かれ方はフロントエンドとバックエンドの違い、インフラ費以外も含めた見積書の読み方はシステム開発の見積もりの内訳もあわせてご覧ください。当社はAWS認定資格11冠のメンバーが構成設計に入り、日本人PMをフロントに置いた体制を1名から提供しています。現在の体制と要件をお聞かせいただければ、構成と台数の考え方をふまえた概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。