先に要点
- 中規模Webアプリの2026年の鉄板は、クラウド(AWS or GCP)に、アプリをコンテナで動かし(ECS Fargate / Cloud Run)、DBはマネージド(RDSやCloud SQLのPostgreSQL)、入口にCDN+ロードバランサーという形です。
- 言語・フレームワークは チームが書けるものを最優先。PHPならLaravel、TypeScriptならNext.js / NestJS、PythonならDjango / FastAPI、RubyならRails。
- セキュリティは 「全HTTPS・WAF・DBは非公開・秘密情報はSecrets管理・実績ある認証・最小権限・依存更新・バックアップ」を必ず一式そろえます。
- 土台は IaC(Terraform) + CI/CD(GitHub Actions) + 監視(メトリクス+Sentry)。中規模はここで差が出ます。やりすぎ(マイクロサービス等)は禁物。
「ユーザーが増えて、止まると困る。複数人で開発している」── この中規模・成長期では、Webアプリ（1人運用）のPaaS構成から一段上げ、クラウド上にきちんとした構成を組みます。このページは抽象論ではなく、具体的にどのサービス・言語・フレームワークを、どのケースで選ぶかまで踏み込んで提案します。
対象と前提
- ユーザーが増え、ダウンタイムがビジネスに直接響くようになった
- 複数人で開発・運用(コードレビューやリリース管理が必要)
- トラフィックが伸び、単一サーバー構成では性能・可用性が不安
- まだ超大規模ではない(常時の超高負荷をさばく専用設計までは不要)
全体構成（リファレンスアーキテクチャ）
まずリクエストの流れを絵で押さえます。「ユーザー → CDN → ロードバランサー → アプリ(コンテナ) → DB」。これさえ分かれば、あとは各箱に具体的なサービスを当てはめるだけです。
基本方針はシンプルで、状態を持たないアプリはコンテナで水平に増やし、状態を持つDBはマネージドに任せる。上の各層を具体的なサービスに置き換えると、AWS/GCPで次のようになります(どちらかに揃えればOK)。
| 層 | 役割 | AWSでの例 | GCPでの例 |
|---|---|---|---|
| 配信(CDN) | 静的配信・キャッシュ・DDoS緩和 | CloudFront | Cloud CDN |
| 入口(LB) | 複数台へ分散・TLS終端 | ALB | Cloud Load Balancing |
| アプリ実行 | コンテナを水平スケール | ECS Fargate | Cloud Run |
| データベース | マネージドRDB(冗長) | RDS / Aurora | Cloud SQL / AlloyDB |
| キャッシュ | セッション・高速化 | ElastiCache(Redis) | Memorystore |
| ストレージ | 画像・ファイル | S3 | Cloud Storage |
| 認証 | ログイン基盤 | Cognito | Identity Platform |
| 秘密情報 | 鍵・パスワード管理 | Secrets Manager | Secret Manager |
| CI/CD・IaC・監視 | 自動化・再現性・観測 | GitHub Actions / Terraform / CloudWatch・Cloud Monitoring + Sentry | |
「コンテナ＝Kubernetes」と思いがちですが、中規模では ECS Fargate / Cloud Run のようなマネージドなコンテナ実行で十分です。Kubernetesは強力な反面、運用が重く、必要になるのはもっと大きく複雑な段階。詳しくは[小規模にKubernetesは過剰か](/articles/is-kubernetes-overkill-for-small-services)。
クラウドはどれを選ぶ
AWSとGCPが二大候補です。中規模ならどちらでも十分こなせるので、チームの慣れと既存資産で決めて構いません。
AWSの基本用語の地図はAWSの基本用語(EC2/IAM/S3/VPC)を。VPSやレンタルサーバーからの移行を考えているならVPSからクラウドへ移行すべきタイミングも読むと判断しやすいです。
言語・フレームワークの選び方
最優先は「チームが書ける言語」です。慣れた言語の方が、速く・安全に・保守しやすく作れます。そのうえで代表的な選択肢を挙げます。
| 言語 | 推奨フレームワーク | 向いているケース |
|---|---|---|
| PHP | Laravel | 管理画面付きの業務系Webアプリ。エコシステムが厚い |
| TypeScript | Next.js / NestJS | フロントと一体で作る(Next.js)、API主体(NestJS)。型で安全に |
| Python | Django / FastAPI | 管理画面標準のフル機能(Django)、高速API・AI連携(FastAPI) |
| Ruby | Ruby on Rails | 少人数で素早く作る。生産性が高い |
| Java / Kotlin | Spring Boot | 堅牢さ・大規模・企業システム |
| Go | 標準ライブラリ + 軽量FW | 高性能・低リソースなAPI。コンテナと相性良い |
新規プロジェクトでは TypeScriptを選ぶ割合が増えています。型による安全性が中規模以上で効くためです(AIが勧めるTypeScriptを初心者が使うべきか)。フロントは React / Vue / Svelte が主流で、SSRやフルスタックなら Next.js / Nuxt / SvelteKit を使います。
データベースの選び方
結論: 新規ならPostgreSQL、運用はマネージドで。 中規模Webアプリは リレーショナルデータベース(RDB)が基本です。
- まずは PostgreSQL を推奨 ── 機能・拡張性・標準準拠・JSON対応に優れ、新規の初手として無難。MySQLも実績十分なので、チームの慣れや既存資産があればそちらでも問題ありません(両者の詳しい違いは別途記事化予定)。
- マネージドで運用 ── AWSならRDS / Aurora、GCPならCloud SQL。可用性が要るならMulti-AZ、読み取りが多いならリードレプリカを足します(DBサーバーを分ける必要性)。
- NoSQL・全文検索・キャッシュは必要になってから ── セッションや高速化にRedis、全文検索にOpenSearch等を、要件が出てから足します。最初からあれこれ持たない。
セキュリティ（中規模で必ずやる一式）
結論: 下の8つは全部やります。 どれか1つ欠けても弱点になります。「あとで」にせず、構築と同時にそろえるのが鉄則です。
具体的な参考: OWASP Top 10 / OAuth 2.0とOIDCの違い / JWTのベストプラクティス / Cognitoユーザープール / IAMのロール・ポリシー / サニタイズ・エスケープ・バリデーション。ログイン体験を上げるならパスキーも検討に値します。
CI/CD・デプロイ・監視
中規模では「自動化と観測」が効きます。手作業デプロイと無監視は卒業します。
GitHub Actions でテスト→コンテナビルド→デプロイを自動化。ステージング環境を本番と分け、ローリング/ブルーグリーンで無停止に近づける。
監視・エラー追跡
CPU/メモリ/レイテンシ/エラー率をCloudWatchやCloud Monitoring、Datadogで監視。アプリのエラーはSentryで追跡し、閾値超えはアラート通知する。
コスト感
主な費用は、コンテナ(ECS Fargate/Cloud Run)の実行時間と台数、マネージドDB(冗長構成やリードレプリカは割高)、ロードバランサー、CDNの転送量、キャッシュ。1人運用のPaaS構成より確実に上がるので、規模に見合うかを都度確認し、コスト監視とアラートを必ず入れます。クラウド料金は構成で大きく変わるため、見積もりと実測を併用してください。
落とし穴
- 過剰設計 ── 中規模なのにマイクロサービスやKubernetes、マルチリージョンまで作り込むと、運用負荷とコストだけ増える。まずはモノリス+コンテナで十分
- DBを公開してしまう ── 設定ミスでDBが外部から触れる状態は重大事故。プライベートサブネット+最小権限を徹底
- 秘密情報のベタ書き ── パスワードや鍵をコード・リポジトリに残すと漏洩源になる。Secrets管理に寄せる
- 監視・バックアップの後回し ── 障害に気づけない・戻せないのが最悪。最初に監視とバックアップ復元を用意する
- コストの想定外 ── 冗長構成・転送量・レプリカで膨らむ。コストアラートを設定する
スケール時の移行余地
さらに大規模・高可用が必要になったら、Webアプリ（大規模・高可用）へ。マルチAZ・オートスケール・リードレプリカ増設、必要に応じてキャッシュ層やシャーディングへ進みます。ただしどれも複雑さが増すので、本当に必要になってから段階的に上げます(可用性の段階)。
よくある質問
Q. クラウドはAWSとGCP、どちらを選ぶべきですか？
A. 中規模ならどちらでも十分こなせるので、チームの慣れと既存資産で決めて構いません。AWSはサービスが網羅的で事例・人材が最多、GCPはCloud Runの手軽さやデータ/AIの強みがあります。すでに一方に詳しい人がいるなら、その慣れを優先するのが立ち上げも運用も速くなります。
Q. 言語・フレームワークは何で選べばいいですか？
A. 最優先はチームが書ける言語です。慣れた言語の方が速く安全に作れます。そのうえで、PHPならLaravel、TypeScriptならNext.jsやNestJS、PythonならDjangoやFastAPI、RubyならRails、堅牢さ重視ならJavaのSpring Bootが定番です。新規では型の安全なTypeScriptを選ぶ割合が増えています。
Q. データベースはPostgreSQLとMySQLどちらがいいですか？
A. 新規なら、機能・拡張性・標準準拠に優れるPostgreSQLを初手の推奨にします。ただしMySQLも実績十分で、チームの慣れや既存資産、特定の要件があればMySQLでまったく問題ありません。どちらもRDS/Cloud SQLなどマネージドで運用でき、可用性はMulti-AZ、読み取り負荷はリードレプリカで対応します。
Q. 中規模で最初からKubernetesを入れるべきですか？
A. 多くの場合不要です。ECS FargateやCloud Runのようなマネージドなコンテナ実行で十分回り、運用もずっと軽くなります。Kubernetesは多数のサービスを束ねる大規模・複雑な運用で効いてきますが、学習と運用のコストが大きいです。必要性が明確になってから導入する方が、中規模では無理がありません。
Q. セキュリティで最低限やるべきことは？
A. 全通信のHTTPS化、前段のWAF、DBを外部非公開(プライベートサブネット)、秘密情報のSecrets管理、実績ある認証基盤、IAM最小権限、フレームワーク標準でのSQLi/XSS対策、依存ライブラリの自動更新、バックアップの8点です。どれか1つでも欠けると弱点になります。「あとで」にせず、構築と同時にそろえます。
Q. 監視やCI/CDは中規模でも必要ですか？
A. 強く推奨します。複数人で運用する中規模では、手作業デプロイはミスと属人化のもとです。GitHub Actionsで自動化し、Terraformで構成を再現可能にし、メトリクスとSentryで異常に早く気づける状態にしておくと、障害対応と機能追加の両方が安全に速くなります。むしろここの整備が中規模の肝です。
関連する考え方
- 構成選びの総論: 構成の選び方（総論）
- 前の段階: Webアプリ（1人運用）
- 次の段階: Webアプリ（大規模・高可用）
- 手間とコストの天秤: マネージド vs 自前運用