サーバーレスとコンテナ｜開発会社が顧客に提案するときの比較フレーム

クラウドネイティブなシステム開発において、避けて通れないのが「サーバーレス（FaaS）」と「コンテナ（CaaS/K8s）」の選択です。顧客から「コストを抑えたい」「メンテナンスフリーにしたい」という要望を受ける際、単に技術的な好みで選定するのではなく、ビジネス要件に合致した明確な判断基準（フレームワーク）を提示することが求められます。

本記事では、AWS、Google Cloud、Microsoft Azureの実名サービスを挙げながら、実務担当者が顧客提案時に活用できる「比較判断フレームワーク」を詳説します。インフラの選定は、その後の開発スピードや保守コストを決定づける極めて重要な意思決定です。

サーバーレスとコンテナの定義と現代的解釈

まず、提案の前提となる両者の特性を、現代のクラウドエコシステムに基づいて整理します。

FaaS（サーバーレス関数）が提供する「運用の抽象化」

AWS LambdaやGoogle Cloud Functionsに代表されるFaaS（Function as a Service）は、コードを実行するための「サーバー」という概念を完全に抽象化します。開発者はビジネスロジックの記述に集中でき、OSのパッチ適用やスケーリングの設定から解放されます。最大の特徴は、「イベント駆動」と「従量課金」の徹底です。リクエストがない時間はコストがゼロになり、急激なトラフィック増にはクラウド側が自動でインスタンスを増殖させて対応します。

CaaS（コンテナ）が提供する「環境の標準化」

Dockerに代表されるコンテナ技術は、アプリケーションを実行環境ごとパッケージ化します。「開発環境では動いたが本番環境では動かない」という問題を解消し、OSのカーネルを共有しながら軽量に動作します。FaaSと比較すると自由度が高く、特定の言語制限やライブラリの制約、実行時間の制限（15分ルールなど）を受けません。ただし、オーケストレーション（配置や管理）の設計は自前で行う必要があります。

サーバーレスコンテナ（Fargate等）という中間解

近年、両者の「いいとこ取り」をしたサービスが主流となっています。AWS FargateやGoogle Cloud Runがこれにあたります。コンテナイメージをデプロイするだけで、背後のEC2インスタンス等の管理をクラウド側に任せられる仕組みです。実務上の提案では、この「サーバーレスコンテナ」を軸に据えることが、最も汎用性の高いアプローチとなります。

開発会社が活用すべき比較判断フレームワーク

顧客への提案時に、以下の4つの基準でスコアリングを行うと、選定理由が論理的に明確になります。

【基準1】ワークロードの特性（イベント駆動 vs 常駐リクエスト）

「いつ、どのくらいの頻度で動くか」が最大の分岐点です。

• サーバーレス向き: 特定の時刻に実行されるバッチ処理、S3へのファイルアップロードをトリガーとした画像処理、散発的なAPIリクエスト。
• コンテナ向き: 常に一定以上のトラフィックがあるWebサイト、長時間実行されるデータ解析、WebSocketなど常時接続が必要なアプリケーション。

【基準2】開発・運用リソースの成熟度

自社または顧客の運用チームのスキルセットを考慮します。Kubernetes（EKS/GKE）は非常に強力ですが、専任のSRE（Site Reliability Engineer）がいない組織が導入すると、インフラの複雑性に飲み込まれ、開発スピードが劇的に低下します。
運用リソースが限られている場合は、徹底的に「マネージド」に寄せた提案が必要です。例えば、社内業務のDXであれば、インフラ管理を極限まで排除した構成が好まれます。

関連記事：Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイド

【基準3】スケーラビリティの要求速度（ミリ秒 vs 分単位）

トラフィックのスパイク（急増）への反応速度を比較します。

• FaaS: ミリ秒単位で数百、数千のインスタンスが並列起動します。
• コンテナ（Fargate等）: 新しいタスクのプロビジョニングに数十秒〜数分かかる場合があります。

テレビ番組での紹介や、SNSでのバズが予想されるキャンペーンサイトでは、FaaSのバースト対応力が決定打となります。

【基準4】ステートレス性と実行時間の制約

FaaSには「ステートレス（状態を持たない）」であることと、「実行時間制限（例：AWS Lambdaは最大15分）」という制約があります。
長時間かかる計算処理や、ローカルディスクに一時ファイルを大量に書き込む処理、メモリを数十GB消費するような処理は、コンテナ（特にマネージドなECS/EKS）を選択せざるを得ません。

【比較表】主要クラウドサービスの実名比較

主要3社のサービスを、提案時にそのまま使える形式で比較しました。最新の仕様は各公式サイトを参照してください。

※料金の詳細は、AWS Lambda 料金やGoogle Cloud Run 料金などの公式ページで、最新の無料枠と単価を確認してください。

実務で直面する「サーバーレス」の壁と回避策

「サーバーレスは安いし楽だ」と安易に提案すると、実装フェーズで以下の問題に直面します。

コールドスタート問題の技術的解決

しばらくリクエストがない状態で関数が呼び出される際、実行環境の初期化に時間がかかる現象です。JavaやC#などの静的型付け言語で顕著になります。

• 回避策1: PythonやGo、Node.jsなど起動の早い言語を選択する。
• 回避策2: AWSの「Provisioned Concurrency（設定済み同時実行数）」を利用し、常に一定数の実行環境を暖めておく（※ただし待機コストが発生します）。

RDB接続（コネクションプーリング）の最適化

LambdaなどのFaaSからAmazon RDS等のRDBに接続すると、関数が並列実行されるたびにコネクションを張りに行き、DB側の最大接続数を使い果たしてしまうことがあります。

• 回避策: AWS Lambdaであれば「RDS Proxy」を介在させることで、コネクションをプールし、DB負荷を軽減します。Google Cloud Runであれば、内蔵のコネクションプーリング機能を活用します。

実務で直面する「コンテナ」の壁と回避策

一方、コンテナ、特にKubernetesを採用する場合の壁は「運用コスト」に集約されます。

コンテナオーケストレーションの運用負荷

EKSやGKE自体の管理はマネージドですが、その上で動くアドオン（Ingress Controller、CSI Driver、Monitoring Agent等）のバージョンアップ作業は発生し続けます。
「なんとなくカッコいいからK8s」という提案は、数年後の顧客の運用コストを増大させるリスクがあります。10マイクロサービス以下の小規模構成であれば、まずはAWS App RunnerやGoogle Cloud Runのような、K8sを隠蔽したプラットフォームを提案するのが定石です。

関連記事：SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

CI/CDパイプラインとセキュリティ

コンテナはOSパッケージを含むため、ベースイメージに脆弱性が含まれるリスクがあります。

• 手順: GitHub ActionsやAWS CodeBuildを利用し、ビルド時にAmazon InspectorやTrivyによる脆弱性スキャンを自動実行するパイプラインを構築します。
• エラー対処: イメージサイズが肥大化するとデプロイが遅延し、タイムアウトエラーが発生しやすくなります。マルチステージビルドを駆使して、最終イメージを軽量化（Distrolessイメージの採用など）することが必須です。

顧客への提案シナリオ別・推奨構成

具体的な提案の型を3つ示します。

【新規事業】最速リリースと低コストを優先する場合

推奨: Google Cloud Run + Firebase (Firestore) / AWS Lambda + DynamoDB
初期コストを限りなくゼロに抑えつつ、需要に応じて無限にスケールする構成です。サーバーレスデータベース（DynamoDB等）を組み合わせることで、DBの管理工数も削減します。

【既存移行】オンプレミスのレガシー資産をクラウド化する場合

推奨: AWS Fargate (ECS) + RDS
既存のアプリケーションコードを大幅に変更することなく、Docker化するだけでクラウドへ移行できます。FaaSの制約に合わせるためのリファクタリング工数が出せない場合に有効です。

【大規模/複雑】データ基盤やAI連携を含む場合

データ処理のパイプラインや、広告最適化などの高度なデータ連携を行う場合、基盤となるインフラの選定はさらに慎重を期します。例えば、BigQueryと連携したデータアーキテクチャを構築する場合、バッチ処理にはサーバーレス（Cloud Functions）、フロントエンドにはCloud Runといった使い分けが一般的です。

関連記事：広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

まとめ：技術選定を「ビジネスの成功」に繋げるために

サーバーレスとコンテナの比較は、単なるスペック比較ではありません。顧客のビジネスフェーズ、予算、運用体制を考慮した「責務の分配」の議論です。

開発会社としての正解は、顧客が将来的に「インフラを意識せず、ビジネス価値の創出に集中できる状態」を作ることです。そのためには、まずは管理コストの低いサーバーレスやマネージドコンテナ（Fargate/Cloud Run）から検討を開始し、技術的な制約（実行時間、ライブラリ、特殊なプロトコル）によって実現不可能な場合にのみ、自前運用のコンテナ（EC2上のDockerやKubernetes）へと一段ずつ抽象度を下げていくアプローチを推奨します。

本記事の比較フレームワークを、ぜひ次回の提案書作成に活用してください。