API・バックエンド（中規模）の推奨構成｜2026年版

先に要点

中規模のAPIは、コンテナ実行 + ロードバランサー/APIゲートウェイ + マネージドDBが2026年の基本形です。
サーバーレス（[API（個人）](/playbook/api-serverless)）から一段上げ、常時負荷・長時間処理・持続接続に強い構成にします。
コンテナの実行先は、まずマネージドなコンテナサービス（Cloud Run / ECS 等）で十分。Kubernetesは要件が出てから。
注意は 過剰なオーケストレーション。中規模で最初からKubernetesを入れると、運用の複雑さだけが増えます。

「APIが育ってきて、常時それなりの負荷がある」「長時間処理やWebSocketも扱う」── この中規模では、コンテナでAPIを動かす構成が効きます。サーバーレスの手軽さから一段上げ、安定した実行環境と制御を手に入れます。

このページでは、API・バックエンド（中規模）のコンテナ構成と、Kubernetesを急がない判断を整理します。実行環境の比較はコンテナ・サーバーレス・VMの比較が前提です。

対象と前提

常時それなりの負荷があるAPI/バックエンド
長時間処理、バッチ、WebSocketなどサーバーレスが苦手な処理を含む
複数人で開発・運用している
サーバーレスの実行時間上限やコールドスタートが問題になってきた

全体構成（リファレンスアーキテクチャ）

結論: 「ロードバランサー → コンテナ(常時起動) → マネージドDB」。Kubernetesはまだ要りません。

読み込み中...

各層を具体的なサービスに置くと、次のようになります。

層	役割	具体的な候補(2026年)
実行	コンテナを常時起動・自動スケール	ECS Fargate / Cloud Run / AWS App Runner
入口	分散・認証・流量制御	ALB / API Gateway / Cloud Load Balancing
データベース	マネージドRDB(必要なら冗長化)	RDS / Aurora / Cloud SQL
構成管理・監視	再現性・観測	Terraform / CloudWatch・Datadog + Sentry

言語は Go(高性能・低リソース)・Node.js/TypeScript(NestJS等)・Python(FastAPI)・Java(Spring Boot) が定番。チームの得意な言語で選びます。ポイントは、いきなりKubernetesに行かないこと。中規模なら、Cloud RunやECSのようなマネージドなコンテナ実行で十分回ります。Kubernetesは強力ですが運用の複雑さが大きく、小規模にKubernetesは過剰かで整理したとおり、必要性が明確になってから（Kubernetesとは）検討します。

なぜこれを選ぶか

常時負荷に強い ── 起動しっぱなしなので、コールドスタートが無く安定して応答
長い処理・持続接続が可能 ── 実行時間の上限に縛られず、WebSocketやバッチも扱える
移植しやすい ── コンテナ化しておくと、別のコンテナ基盤やクラウドへ移りやすい（ベンダーロック対策にもなる）

コスト感

2026-06時点の目安(公式で要確認)

コンテナの稼働時間・台数、ロードバランサー、マネージドDBが主な項目です。常時起動するぶん、アイドル時もコストがかかるため、アクセスが断続的ならサーバーレスの方が安いこともあります。常時負荷が見込めるかで、サーバーレスとコンテナのコストを比較してください。

落とし穴

過剰なKubernetes ── 中規模で最初からKubernetesを入れると、運用とデバッグの複雑さだけ増える
アイドルコスト ── 常時起動なので、アクセスが少ない時間帯もコストがかかる
スケール設計 ── コンテナの自動スケールやヘルスチェックを設計しないと、負荷時に詰まる
状態の置き場所 ── コンテナは使い捨て前提。状態はDBや外部ストレージに置く

スケール時の移行余地

さらに大規模・高可用が必要になったら、Webアプリ（大規模）と同様にマルチAZ・オートスケール・リードレプリカへ。マイクロサービス化やKubernetesは、組織とサービスが本当にその規模になってから検討します（急がない）。

よくある質問

Q. 中規模APIに最初からKubernetesを使うべきですか？

A. 多くの場合不要です。Cloud RunやECSのようなマネージドなコンテナサービスで十分回ります。Kubernetesは多数のサービスを束ねる大規模・複雑な運用に向く一方、学習と運用のコストが大きいです。必要性が明確になってから導入する方が、中規模では無理がありません。

Q. サーバーレスからコンテナへ、いつ移るべきですか？

A. 「実行時間の上限に当たる」「コールドスタートが許容できない」「常時高負荷でサーバーレスだと割高」「WebSocketなど持続接続が要る」のいずれかが出てきたときです。これらが無ければサーバーレスのままで十分です。アプリをコンテナ化しておくと、この移行がスムーズになります。

Q. ロードバランサーとAPIゲートウェイ、どちらが要りますか？

A. 用途で選びます。単純にコンテナへトラフィックを分散するならロードバランサー、認証・流量制御・APIキー管理など入口で多くを担わせたいならAPIゲートウェイが向きます。両方を組み合わせる構成もあります。まず必要な機能を洗い出してから選ぶと、過剰になりません。

Q. コンテナにすると運用が重くなりませんか？

A. マネージドなコンテナサービスを使えば、思うほど重くなりません。OSやオーケストレーションの大半を事業者が担うため、利用者はコンテナと設定に集中できます。自前でKubernetesクラスタを運用すると重くなりますが、中規模ではそこまで必要ないことがほとんどです。