執筆：Swooo編集部／監修：北浦 聡大（Bubble公式認定デベロッパー・国内初合格）
「Webアプリを作りたいけれど、サーバーって結局なにをするもの？」
「レンタルサーバーとクラウドとPaaS、どれを選べばいいの？」
Webアプリの開発を考え始めると、必ずぶつかるのがサーバーの話です。仕組みそのものは昔から大きく変わっていませんが、「どこでどう用意するか」の選択肢はこの数年で大きく広がりました。今は個人でも無料枠だけでWebアプリを公開できますし、逆に選び方を誤ると、あとから移行の手間で苦労することもあります。
この記事では、まず「サーバーとは何か」「Webアプリが動く仕組み」を図解つきで押さえたうえで、2026年時点の現実的な選択肢（PaaS・BaaS・VPS/クラウド・レンタルサーバー）と費用感の目安まで、初心者向けに一気通貫で解説します。ノーコードやAI開発の場合にサーバーがどうなるかにも触れるので、開発を外注するか自分で作るか迷っている方にも役立つ内容です。
Webアプリそのものの仕組みや作り方を先に知りたい方は、こちらの記事もあわせてどうぞ。
Webアプリとは？ 仕組みと作り方を解説
そもそもサーバーとは？
サーバーとは、簡単にいうと「ユーザーにサービスを提供しているコンピュータ」です。
コンピュータ自体は、普段みなさんが使っているパソコンと本質的には変わりません。ユーザーからの要求（リクエスト）を受け取り、応答（レスポンス）を返す役割を担っていて、インターネットを介してユーザーとつながっています。
仕組みとしては「自動販売機」に似ています。お金を入れてボタンを押すと、飲み物が出てきますよね。この「ボタンを押す」という要求を受けて、「該当する飲み物を出す」という処理を行うのがサーバーの仕事です。
反対に、要求を出す側（ブラウザやスマホアプリ）は「クライアント」と呼ばれます。Webアプリは、このクライアントとサーバーがリクエストとレスポンスをやりとりすることで動いています。たとえばSNSでタイムラインを開くと、ブラウザが「最新の投稿をください」とサーバーに要求し、サーバーがデータベースから投稿を取り出して返す。この往復が、みなさんが画面を触るたびに裏側で起きています。
「Webアプリだけでも難しいのに、サーバーの構築まで勉強しないといけないのか」と感じた方も、心配はいりません。後述するとおり、2026年現在はサーバーの調達や運用をクラウド事業者やプラットフォームに任せられる選択肢が充実しています。まずは仕組みを理解して、そのうえで「自分はどこまで自分で管理するか」を選ぶのが近道です。
Webアプリが動く仕組み — Web3階層モデルと1台構成
Webアプリのサーバー構成は、大きく2つのパターンに整理できます。「Web3階層モデル」と「1台構成」です。どちらを選ぶかは、開発規模・予算・想定される負荷によって決まります。
先に押さえておきたいのは、この「3つの役割に分けて考える」という発想自体は、後述するPaaSやサーバーレスの時代になっても変わらない、ということです。変わったのは「その3つを誰が・どこで管理するか」であって、役割分担の考え方は今もすべてのWebアプリの土台になっています。
Web3階層モデル
Web3階層モデルは、簡単にいうと「役割の異なるサーバーを3つ用意する仕組み」です。
なぜ3つに分けるのかというと、いちばんの理由は負荷を分散するためです。アクセスが多いシステムを1台のサーバーで受けると、そこに負荷が集中して応答が遅くなります。役割ごとにサーバーを分ければ、それぞれのコンピュータが自分の仕事に集中でき、パフォーマンスを発揮しやすくなります。
3つのサーバーとは、「Webサーバー」「アプリケーションサーバー」「データベースサーバー」です。それぞれの役割を順番に見ていきましょう。
Webサーバー
Webサーバーは「ユーザーとのやりとりの窓口になるコンピュータ」です。ユーザーからの要求を最初に受け取り、静的なコンテンツ（HTML・CSS・画像など）はそのまま返し、プログラムの処理が必要な要求はアプリケーションサーバーに渡します。処理結果を受け取って、最終的にユーザーへ返すのもWebサーバーの役割です。
Webサーバーを構築するには、コンピュータにWebサーバーソフトウェアをインストールします。代表的なものがNginx（エンジンエックス）やApache HTTP Serverです。これらのソフトウェアは、おもに次の3つの機能を備えています。
- ログ取得：誰がいつどんなデータを要求したかを記録する
- アクセスコントロール：アクセス権を制御し、許可されていない接続を弾く
- SSL/TLS通信：通信の暗号化と認証を行う（URLが https:// で始まる通信）
Webサーバーは常にインターネットに接続しているため、3層の中では外部からの攻撃を受けやすい位置にあります。だからこそ、こうした防御・記録の機能を最前線で備えているわけです。
アプリケーションサーバー
アプリケーションサーバー（APサーバー）は「プログラムを実行するコンピュータ」です。3層の中間に位置し、Webサーバーからユーザーの要求を受け取ってビジネスロジック（アプリ固有の処理）を実行します。必要なデータがあれば、データベースサーバーに問い合わせて取得します。
たとえばECサイトで「注文を確定する」ボタンを押したとき、在庫を確認し、注文データを作り、合計金額を計算する——こうした処理はすべてアプリケーションサーバーの仕事です。
構築には、アプリケーションの実行環境をコンピュータに用意する必要があります。Java系ならTomcat、JavaScript系ならNode.jsなどが代表例です。近年は、コンテナ技術（Docker）や、それを束ねて管理するKubernetesを使ってアプリケーションを動かすケースも一般的になっています。
なお、システムの規模によっては、Webサーバーとアプリケーションサーバーを1台にまとめる「2層構成」を取ることもあります。
データベースサーバー
データベースサーバー（DBサーバー）は「情報を集めて、整理して保管するコンピュータ」です。情報の検索・追加・更新・削除がしやすいように、データを構造化して管理しています。
データベースサーバーとして使うには、DBMS（データベース管理システム）というソフトウェアをインストールします。広く利用されているのはリレーショナル型（RDBMS）で、MySQLやPostgreSQLが代表例です。
動きの流れはこうです。まず、アプリケーションサーバーから「この条件のデータをください」という要求を受け取ります。
その要求をもとにデータベースから必要な情報を検索・追加・更新し、結果をアプリケーションサーバーに返します。
データベースには会員情報や決済履歴など重要なデータが格納されるため、接続時には認証が必要になるのが基本です。また、3層の中でいちばん奥に置かれ、インターネットから直接アクセスできない構成にするのがセオリーです。
1台構成
1台構成は、Web・アプリケーション・データベースの3つの機能を1台のコンピュータに集約した仕組みです。
サービスを提供するコンピュータが1つしかないため、そこに負荷が集中します。したがって、利用者が限られる社内システムや、開発規模が小さめのサービスに向いた構成です。逆にいえば、小規模なうちはこれで十分なケースも多く、コストと管理の手間を抑えられるのが持ち味です。
それぞれのメリット・デメリット
2つの構成の違いを表に整理すると、次のようになります。
| Web3階層モデル | 1台構成 | |
|---|---|---|
| メリット | ・問題箇所や変更部分を特定しやすい ・負荷を分散でき、各サーバーが役割に集中できる ・層ごとに独立して増強・保守できる | ・初期コストを抑えられる ・管理するサーバーが1台で済み、手間が少ない |
| デメリット | ・サーバーが3台必要で費用がかかる ・サーバー間のやりとりが増える（オーバーヘッド） | ・1台に負荷が集中する ・一部の障害がシステム全体の停止につながる ・変更時に他機能への影響が出やすい |
| 向いているケース | 利用者が多い本番サービス、成長を見込むサービス | 社内システム、小規模サービス、検証用途 |
Web3階層モデルの強みは、変更部分や問題箇所を特定しやすいことです。たとえばアプリの処理（ロジック）を変更したいとき、1台にすべてが詰まっていると3つの機能が絡み合って修正箇所を切り分けにくくなりますが、役割ごとに分かれていれば「直すのはアプリケーションサーバー」とすぐに特定できます。障害が起きたときの調査も同じ理屈で楽になります。
一方の弱みは費用とオーバーヘッドです。3つの役割ぶんのサーバーが必要になるため、1台構成よりコストがかかります。また、オーバーヘッドとは「目的の処理に付随して発生する余分な処理」のこと。ミカンを食べるためには先に皮をむく必要がありますが、この「皮むき」にあたる作業——サーバー間の通信や受け渡し——が3層では増えます。
1台構成はこの裏返しです。初期コストと管理の手間を抑えられる代わりに、負荷が1台に集中し、どこかの機能が止まるとシステム全体が停止します。Web・アプリ・データベースのどれかに変更を加えるとき、同じコンピュータ上の他機能に影響が及ぶリスクも意識しておく必要があります。
2026年のサーバーの選択肢 — 自前で組む以外の方法が広がった
ここまでは「自分でサーバーを用意して構成する」前提で解説してきました。しかし2026年現在、個人開発やスタートアップの新規サービスでは、サーバーの構築・運用そのものをプラットフォームに任せる選択肢のほうがむしろ主流になりつつあります。
整理すると、選択肢は大きく4つです。
- PaaS（Vercel・Render・Railwayなど）：コードを置くだけでWebサーバー〜APサーバー相当の環境が整う
- BaaS（Supabase・Firebaseなど）：データベース・認証・ストレージをまとめて提供
- VPS・クラウド（AWS・Google Cloud・Azureなど）：仮想サーバーを借りて自分で構成する
- 共用レンタルサーバー：Webサイト向けの伝統的な選択肢（Webアプリには制約あり）
ポイントは、先ほどのWeb3階層モデルの考え方が失われたわけではない、ということです。PaaSはWebサーバー層とアプリケーション層を、BaaSはデータベース層と認証まわりを、それぞれ「代わりに管理してくれるレイヤー」だと捉えると、全体像がすっきり整理できます。
PaaS — Vercel・Render・Railway
PaaS（Platform as a Service）は、アプリケーションのコードをアップロード（多くはGitHubと連携してpush）するだけで、サーバーの構築・OS管理・ミドルウェア設定を意識せずにWebアプリを公開できるサービスです。
- Vercel：Next.jsをはじめとするフロントエンド・サーバーレス関数のホスティングに強い。個人向けのHobbyプランは無料で使える
- Render：常時稼働型のWebサービスやデータベースをまとめてデプロイできる。無料枠あり（ただし後述のスリープ挙動に注意）
- Railway：フルスタックアプリのデプロイ基盤。データベースも同じ画面で立ち上げられる手軽さが特徴
従来「サーバーを借りて、OSを設定して、NginxとNode.jsを入れて……」と手作業で行っていた環境構築が、PaaSでは大幅に短縮されます。個人開発やMVP（検証用の最小プロダクト）の公開先として、まず候補に挙がる選択肢です。
注意点は、無料枠には制約があることです。たとえばRenderの無料プランは、15分間リクエストがないとサービスがスリープし、次のアクセス時に再起動へ1分ほどかかります（2026年7月時点・公式ドキュメントより）。試作品の共有には十分でも、常時快適に使ってもらう本番サービスには有料プランが前提になります。
BaaS — Supabase・Firebase
BaaS（Backend as a Service）は、データベース・ユーザー認証・ファイルストレージ・APIといったバックエンド機能を、まとめて提供するサービスです。Web3階層モデルでいうデータベースサーバー層に加えて、アプリケーション層の一部までを肩代わりしてくれるイメージです。
- Supabase：PostgreSQLベースのオープンソース系BaaS。SQLの知識がそのまま活きるのが強み
- Firebase：Googleが提供するBaaS。モバイルアプリのバックエンドとして広く使われている
「フロントエンドはVercel、バックエンドはSupabase」のようにPaaSとBaaSを組み合わせる構成は、個人開発の入門としてよく紹介される定番パターンです（一般に広く推奨されている構成であり、唯一の正解というわけではありません）。
こちらも無料枠の制約には注意が必要です。Supabaseの無料プランは、1週間操作がないとプロジェクトが一時停止し、アクティブに保てるプロジェクトは2個までです（2026年7月時点・公式ページより）。開発を中断して久しぶりに戻ったら止まっていた、というのは無料枠あるあるなので覚えておきましょう。
従来型のVPS・クラウド（AWS・Google Cloud・Azure）
VPS（仮想専用サーバー）やクラウド（AWS・Google Cloud・Microsoft Azureなど）は、仮想的なサーバーを借りて、OSから上を自分で構成する選択肢です。この記事の前半で解説したWeb3階層モデルや1台構成を、文字どおり自分の設計で組み上げることになります。
自由度はいちばん高く、細かなチューニングやセキュリティ要件への対応、既存システムとの接続など、PaaSでは難しい要求にも応えられます。データベースの運用を任せられるマネージドサービス（Amazon RDSなど）や、リクエストが来たときだけ処理が動くサーバーレス（AWS Lambda・Cloud Runなど）を組み合わせれば、運用負担を抑えつつ柔軟な構成が組めます。
一方で、構築・運用にはインフラの知識が必要で、料金体系も従量課金が基本のため見積もりの難易度が上がります。個人・小規模チームの最初の一歩としては、まずPaaS/BaaSから始めて、規模が大きくなったらクラウドへ移行するという段階的な進め方が、一般に現実的とされています。
共用レンタルサーバーはWebアプリに向くのか
「サーバーといえばレンタルサーバーでは？」と思った方もいるでしょう。月数百円〜で借りられる共用レンタルサーバーは、WordPressサイトやPHP＋MySQLの伝統的なWebサイトには今も有力な選択肢です。
ただし、Node.jsやPythonの常駐プロセスを前提とするモダンなWebアプリの本番運用には、一般に次のような制約があるとされています。
- 多数の利用者が同じ環境を共有するため、常駐プログラムの実行が原則禁止されているケースが多い
- 待受ポートやリバースプロキシの設定など、構成の自由度が低い
- WebSocketのような長時間接続が制限される場合がある
- 管理者権限がないため、プロセスの自動復帰やデプロイの仕組みを自前で組みにくい
事業者によってはNode.js実行を公式にサポートする動きもありますが、常時稼働のWebアプリを本番運用するなら、PaaSかVPS/クラウドを選ぶほうが素直です。「Webサイトならレンタルサーバー、Webアプリなら別の選択肢」と覚えておくと判断を誤りにくくなります。
費用感の目安（2026年7月時点）
主要なPaaS/BaaSの無料枠と有料最低プランを整理します。いずれも2026年7月時点の各社公式ページで確認した情報です（海外サービスは米ドル建てのためドル表記のまま記載します。最新の料金は必ず公式ページでご確認ください）。
| サービス | 無料枠 | 有料最低プラン |
|---|---|---|
| Vercel（PaaS） | Hobbyプランが無期限無料。データ転送 月100GB など | Pro：$20/ユーザー/月〜（従量課金あり） |
| Render（PaaS） | Webサービス月750時間まで無料。 ※15分アクセスがないとスリープ、復帰に約1分 | Starter：$7/月〜（常時稼働・スリープなし） |
| Railway（PaaS） | 継続的な無料枠はなし。初回のみ$5分のトライアルクレジット | Hobby：$5/月〜 |
| Heroku（PaaS） | 無料プランなし | Eco：$5/月〜（30分無操作でスリープ） |
| Firebase（BaaS） | Sparkプラン無料。Firestore読み取り 5万/日 など | Blaze：従量課金（無料枠を超えたぶんに課金） |
| Supabase（BaaS） | DB 500MB・月間アクティブユーザー5万まで無料。 ※1週間操作なしでプロジェクト一時停止 | Pro：$25/月〜（DB 8GB・停止なし） |
表からわかるとおり、学習や試作品の公開なら無料枠だけでも成立しますし、常時稼働の小規模サービスでも月$5〜$25程度から始められます。かつて無料枠の代名詞だったHerokuに現在無料プランがない点は、古い解説記事を読むときに注意してください。
進め方の目安としては、次のような段階的アプローチが一般に紹介されています。
- まずはPaaS＋BaaSの無料枠で作って公開してみる（例：Vercel＋Supabase）
- 常時稼働のバックエンドやWebSocketが必要になったら、Render等の有料プランを追加する
- ユーザー数や要件が増えたら、AWS・Google Cloudなどのクラウドへ段階的に移行する
なお、ここで挙げたのはサーバー（インフラ）の費用です。アプリ本体の開発を外注する場合の費用感は別の話になるので、AIアプリ開発の費用相場はいくら？方式別の料金と内訳【2026年版】を参考にしてください。
ノーコードやAI開発の場合、サーバーはどうなるか
ここまでは「コードを書いて開発する」前提で選択肢を見てきました。最後に、ノーコード開発とAI開発（生成AIアプリ・AI駆動開発）の場合にサーバーの扱いがどう変わるかを整理します。
ノーコード（Bubbleなど）の場合 — サーバーはツールに含まれる
Bubbleなどのノーコードツールでは、サーバーもデータベースもツール側に含まれています。利用者がサーバーを調達・構築する必要は基本的になく、アクセス増加への対応もプランの範囲でツール側が受け持ちます。この記事で解説してきたサーバー選びの悩みが、まるごとスキップできるのがノーコードの大きな特徴です。
そのぶん、サーバー構成を細かく設計する自由度は下がります。どこまでをツールに任せ、どこからを自前で作るかの線引きが、方式選びの論点になります。ノーコード開発の全体像はノーコード開発とは？メリット・デメリットを解説で詳しくまとめています。
AIアプリ・AI駆動開発の場合 — GPUサーバーは基本的に不要
「AIアプリを作るには高価なGPUサーバーが必要なのでは」と心配される方が多いのですが、多くの場合は不要です。現在の生成AIアプリの主流は、OpenAI・Anthropic・GoogleなどのLLM（大規模言語モデル）をAPIで呼び出す構成で、AIの計算はAPI提供元のサーバーで行われます。自分のサーバーは「APIを呼び出して結果を返す」だけなので、要件は通常のWebアプリとほぼ変わりません。
リクエスト単位で外部APIを呼んで返すシンプルな処理になりやすいため、サーバーレス（Vercel Functionsなど）との相性も良いと一般にいわれています。GPUサーバーが必要になるのは、自前でモデルをホスティングしたりファインチューニングしたりする場合で、個人や小規模チームがAI機能つきWebアプリを作る段階では、まず考えなくて構いません。
また、開発の作り方そのものも変わってきています。Claude Codeに代表されるAIコーディングツールを使うAI駆動開発では、コードを書く工程をAIに任せながら、公開先には本記事で紹介したPaaS/BaaSを使う、という組み合わせが定着しつつあります。詳しくはAI駆動開発とは？進め方とメリットを解説をご覧ください。
よくある質問（FAQ）
Q. WebサーバーとAPサーバーの違いはなんですか？
Webサーバーはユーザーとの窓口で、静的なコンテンツ（HTMLや画像）を返したり、要求を後ろに取り次いだりします。アプリケーションサーバー（APサーバー）はプログラムを実行する係で、ログイン処理や注文処理などアプリ固有のロジックを担当します。小規模なシステムでは1台にまとめることもあります。
Q. 個人でWebアプリを公開する場合、サーバー代はいくらかかりますか？
学習・試作レベルならVercelやSupabaseなどの無料枠で0円から公開できます（2026年7月時点）。無料枠にはスリープや一時停止などの制約があるため、常時稼働のサービスとして運用するなら、月$5〜$25程度の有料プランが目安になります。
Q. レンタルサーバーでWebアプリは動かせますか？
PHP＋MySQL構成のWebサイト・Webアプリであれば動かせます。一方、Node.jsやPythonの常駐プロセスを前提とするアプリは、共用レンタルサーバーでは常駐実行の制限などがあり、一般に本番運用には不向きとされています。その場合はPaaSかVPS/クラウドを検討しましょう。
Q. AIアプリを作るのにGPUサーバーは必要ですか？
LLMのAPIを呼び出す構成であれば不要です。AIの計算はAPI提供元のサーバーで行われるため、自分のサーバー要件は通常のWebアプリと変わりません。GPUが必要になるのは、自前でAIモデルをホスティング・学習する場合に限られます。
Q. 最初にサーバー選びを間違えたら、あとから変更できますか？
変更できます。実際、「無料枠で検証→有料PaaSで運用→クラウドへ移行」という段階的な進め方がよく紹介されています。ただしデータベースの移行には手間がかかるため、最初からPostgreSQLなど広く使われるDBMSを選んでおくと、後の移行がしやすくなります。
まとめ — 仕組みを理解すれば、選択肢は怖くない
今回は、Webアプリに必要なサーバーについて、仕組みから2026年時点の選択肢・費用感までを解説しました。要点を振り返ります。
- サーバーは「ユーザーにサービスを提供するコンピュータ」。Webアプリはクライアントとサーバーの往復で動く
- 構成の基本はWeb3階層モデル（Web・アプリケーション・データベース）と1台構成。役割分担の考え方は今も土台
- 2026年はPaaS（Vercel・Render・Railway）やBaaS（Supabase・Firebase）で、サーバー運用を任せる選択肢が主流に。無料枠から始められる
- 共用レンタルサーバーは常駐型Webアプリの本番運用には一般に不向き
- ノーコードならサーバーはツールに含まれ、AIアプリもAPI型ならGPUサーバーは不要
どの構成・方式が向いているかは、作りたいアプリの規模・予算・運用体制によって変わります。まず小さく作って検証したい場合は、MVP開発の進め方も参考になるはずです。
Swoooは、東証グロース上場の株式会社アイビス（証券コード9343）が運営する開発支援サービスです。ノーコード（Bubble公式Goldパートナー）・AI駆動開発・通常開発を、つくりたいものに合わせて使い分けながら、サーバー構成の選定も含めて開発を支援します。新規事業の立ち上げ支援から個別の技術相談まで、構成選びで迷ったらお気軽にご相談ください。
