サーバレスか Kubernetes か ー 日本のチームが本当に見るべき判断基準

「サーバレスとは」の先にある本当の問い

「サーバレスとは」と検索して記事を開く人の多くは、定義そのものを知りたいわけではありません。知りたいのは、自分たちのシステムをサーバレスに寄せるべきか、Kubernetes を選ぶべきか、という一点です。本稿は用語解説ではなく意思決定を扱います。

先に結論を述べます。両者は対立する二択ではありません。実際の判断は「どのワークロードをどの実行モデルに置くか」という配置の問題であり、多くの場合、両者は同じシステムの中で共存します。二択として扱った瞬間に、議論は好みの問題にすり替わります。

サーバレスは一つの技術ではない

議論が噛み合わない最大の原因は、「サーバレス」という言葉が少なくとも三つの異なるものを指していることにあります。

• FaaS — AWS Lambda、Google Cloud Functions、Azure Functions など。関数単位でデプロイし、イベント駆動で起動します。実行時間の上限、パッケージサイズの制約、実行環境の自由度の低さが特徴です。
• マネージドコンテナ実行基盤 — Google Cloud Run、AWS App Runner、ECS Fargate、Azure Container Apps など。コンテナイメージをそのまま渡し、ノードとスケーリングの管理をクラウド側に委ねます。ランタイムの自由度は通常のコンテナと変わりません。
• サーバレスデータストア — Aurora Serverless、DynamoDB のオンデマンドモードなど。容量の事前確保をやめ、実際の消費に応じて課金される設計です。

この三つは制約もコスト構造も運用の勘所も異なります。「実行時間に上限があるから使えない」は FaaS には当てはまりますが、マネージドコンテナには当てはまりません。「ロックインが強い」という懸念も、コンテナイメージを成果物とする形なら移行コストは下がります。混同したまま議論すると、採用できたはずの選択肢を入口で捨てることになります。

Kubernetes が実際に提供しているもの

一方の Kubernetes は「コンテナを動かす仕組み」ではなく、「宣言的なプラットフォームを自分たちで組み立てるための土台」です。スケジューリング、サービスディスカバリ、ローリングアップデート、リソース制御を一つの API で統一的に扱えることが価値であり、その代償として、クラスタのアップグレード、ネットワークポリシー、証明書、オブザーバビリティ、権限設計といった継続的な運用責任を引き受けることになります。

したがって Kubernetes の採否は、技術的な優劣ではなく「その運用責任を担い続けられるチームがあるか」という組織の問題に帰着します。ここを曖昧にしたまま導入すると、クラスタは動いているが誰もアップグレードしたがらない、という状態に行き着きます。

判断基準1 — 負荷プロファイル

最も効く基準は負荷の形です。トラフィックがゼロに近づく時間帯を持ち、突発的なピークがあるワークロード（社内向け管理画面、イベント起点の API、キャンペーン連動の処理）は、アイドル時に課金されない実行モデルと相性が良い。逆に一日を通してほぼ一定の負荷が続くなら、確保済みキャパシティを高い稼働率で使い切れるインスタンスやノードプールが有利です。

判断にあたっては、平均値ではなくピークと谷の比率、そしてピークの継続時間を見てください。平均リクエスト数だけを見ていると、課金額もスケーリング挙動も見誤ります。

判断基準2 — コールドスタートとレイテンシ要件

コールドスタートは「あるかないか」ではなく「どこに現れるか」で評価すべき指標です。ユーザーの操作を直接ブロックする同期パスに現れるのか、非同期処理の裏側に隠れるのかで、許容度はまったく違います。バッチやキュー消費なら、初回起動の遅延は実質的に無視できることがほとんどです。

同期パスに厳しい要件がある場合でも、選択肢はゼロか一かではありません。最小インスタンス数の確保、初期化処理をリクエスト処理の外に出す設計、起動の軽いランタイムの採用といった緩和策があります。まず「その遅延が誰に見えるのか」を定義してください。

判断基準3 — 実行時間、ネットワーク、ステート

• 実行時間 — FaaS には実行時間の上限があり、長時間のバッチ処理、動画変換、大規模なデータ変換は分割設計を強いられます。マネージドコンテナやジョブ実行基盤の方が素直に書けます。
• ネットワークの複雑さ — VPC 内のデータベースへの接続、取引先から固定 IP を求められる連携、オンプレミスとの専用線接続。これらが絡むと、サーバレス側でも VPC 統合やコネクタ、NAT の設計が必要になり、「設定が少ない」という利点は薄まります。日本では取引先システムとの IP 制限連携が今も広く残っており、検討の初期に確認すべき点です。
• ステートフルな要件 — WebSocket の長時間接続、インメモリキャッシュへの依存、ローカルディスク前提の処理。サーバレスの実行モデルと相性が悪く、外部化にかかる設計・実装コストを見積もる必要があります。

コストは「単価」ではなく「課金メカニズム」で考える

コスト比較で最も多い失敗は、単価表を並べて比べることです。単価は改定され、割引条件は契約形態で変わります。安定して効くのは課金メカニズムの方です。

• 従量課金型（サーバレス）— リクエスト数と、実行時間に割り当てリソースを掛けた量に対して課金されます。コストは利用量に比例し、アイドル時間の費用はほぼ発生しません。
• 確保型（インスタンス／ノードプール）— 起動している時間に対して課金されます。コストは確保量に比例し、実際にどれだけ使われたかとは無関係です。

分岐点は稼働率です。確保したキャパシティを高い稼働率で使い続けられるなら確保型の方が単位あたりのコストは下がり、稼働率が低い、あるいは予測できないなら従量課金型が有利になります。

ただし比較から抜け落ちがちなコストが二つあります。一つは Kubernetes 側の間接コスト、すなわちコントロールプレーン、監視・ログ基盤、そして何よりクラスタを維持する人の時間。もう一つはサーバレス側のデータ転送とサービス間連携のコストで、アーキテクチャが細かく分割されるほど積み上がります。この二つを無視した比較は、ほぼ必ず結論を誤らせます。

進め方は単純です。自分たちの実測トラフィックを両方の課金モデルに当てはめて計算する。公開料金と自社のメトリクスがあれば実行でき、他社事例よりはるかに信頼できる根拠になります。

日本のチームに固有の論点

ここまでは市場を問わず成り立つ基準です。加えて日本には、判断に実際に影響する固有の条件があります。文化的な一般論ではなく、設計と契約に跳ね返る要素だけを挙げます。

• データの所在と規制対応 — 金融、医療、公共分野では、データの保管場所と、監査時に構成を説明できることが要件になります。国内リージョンの提供状況、FISC 安全対策基準や政府情報システムの調達要件（ISMAP 登録の有無）への適合が、そもそもの選択肢を絞ります。マネージドサービスは運用を軽くしますが、監査に必要な情報を開示できるかを先に確認すべきです。
• SIer との分業構造 — インフラの構築と運用を外部に委託している場合、「運用が不要になる」という利点はそのまま契約構造の変更を意味します。運用保守契約が人月ベースなら、技術的な最適解と契約上の最適解はずれます。この不一致を整理しないまま技術検討だけを進めても、実装フェーズで止まります。
• SRE・プラットフォームエンジニアの需給 — Kubernetes を選ぶとは、その運用を担う人材を確保し続けるということです。国内の SRE 採用市場は逼迫しており、特定の一人に依存した構成は事業リスクになります。採用の見込みが立たないなら、運用責任をクラウド側に寄せる設計の方が現実的です。
• 稟議と意思決定プロセス — 稟議を通す以上、判断は文書として残り、後から検証されます。通りやすいのは「新しいから」ではなく「基準に照らしてこう判断した」と書ける選択です。負荷プロファイル、レイテンシ要件、運用体制という言葉で根拠を整理しておけば、承認は速く進み、数年後の見直しも容易になります。予測しやすい確保型コストと利用実態に連動する従量型コストのどちらが社内で説明しやすいかも、実務上は無視できません。
• オンプレミスからの移行 — 稼働中のシステムがまだオンプレミスにある場合、最初の移行先にいきなりサーバレスを選ぶと書き換え量が大きくなりがちです。コンテナ化を第一段階としてマネージドコンテナ基盤に載せ、適した部分から FaaS やサーバレスデータストアへ寄せる段階的な移行の方が、リスクを分散できます。

意思決定フレームワーク

以上を踏まえ、次の順序で判断することを勧めます。

1. ワークロードを分解する。システム全体を一つの選択肢に収めようとしない。同期 API、非同期ジョブ、定期バッチ、常駐プロセスに分ける。
2. 除外条件を先に確認する。データ所在、規制要件、ネットワーク制約、実行時間の上限。この段階で選べない選択肢を落とす。
3. 負荷プロファイルを実測する。ピークと谷の比率、ピークの継続時間、ゼロに近い時間帯の有無。
4. レイテンシ要件を同期パスに限って定義する。コールドスタートが利用者から見えるかを明確にする。
5. 運用体制を正直に評価する。Kubernetes を運用し続けられる人員が今いるか、今後も確保できるか。
6. 自社の実測値を両方の課金モデルに当てはめて計算する。間接コストを必ず含める。
7. 判断根拠を文書化する。何が変わったら見直すのか、という再検討の条件も書く。

最初の二つのステップで選択肢が現実的な範囲まで絞られ、残りの議論が具体的な数字と要件の話になる。この順序に意味があるのはそのためです。

現実的な着地点

現実的な着地は、どちらか一方への集約ではありません。変動するサービスや新規サービスはマネージドコンテナ基盤に、イベント駆動の処理や定期ジョブは FaaS に、安定した高負荷を処理するコアシステムや多数のサービスを標準化したいケースは Kubernetes に置く。運用負荷を担える範囲に収めつつ、コストの説明可能性も保てます。

避けるべきは「サーバレスは安い」「Kubernetes は業界標準だ」といった一般論から入ることです。どちらも条件付きでしか成立しません。判断は常に、自分たちのワークロードの形と、自分たちのチームの運用能力から始まります。