サーバーレス・コンテナとは？Dockerを使う理由と発注者の判断軸

「バックエンドはDockerコンテナで構築し、一部処理はサーバーレス（Lambda）を使います」――開発会社から受け取った提案書にこうした一文が並び、見積の内訳に「ECS Fargate」「API Gateway + Lambda」といった聞き慣れない用語が続いたとき、意思決定者としてどう判断すればよいか悩む方は少なくありません。

社内にインフラ専任がいない状況では、提案の妥当性を検証する相談相手も限られます。「一般的な構成らしいから」と鵜呑みにして発注したものの、運用が始まってから想定外のコストに驚いたり、拡張時に身動きが取れなくなったりするケースも実際に起きています。

本来、サーバーレスとコンテナの選択は「どちらが優れているか」ではなく、システム特性とビジネス要件にどちらが合うかを判断する問題です。そして、その判断は非エンジニアの発注者であっても、いくつかの軸さえ押さえれば十分にできます。

本記事では、まずサーバーレス・コンテナ（Docker）の仕組みを日常語で整理し、費用・運用・拡張性という発注者が最も気にする3観点で両者を比較します。そのうえで、提案書の妥当性を自分の言葉で評価できる判断軸と、開発会社に投げるべき質問のチェックリストまで落とし込みます。読み終えたときに、「このシステムならコンテナが妥当」「この処理はサーバーレスでコスト効率が高い」と自分の言葉で説明できる状態を目指します。

サーバーレス・コンテナとは？発注者が最低限押さえたい全体像

サーバーレスとコンテナを理解する最短ルートは、「サーバーを動かすうえでどこまでを自分で管理し、どこからをクラウド事業者にお任せするか」という視点で整理することです。クラウドには、大きく分けて「仮想マシン（VM）」「コンテナ」「サーバーレス」という3つの選択肢があり、この順番で管理範囲が狭く（＝お任せ範囲が広く）なっていきます。

VM・コンテナ・サーバーレスは「お任せ範囲」が違う

イメージしやすくするために、住まいの例で考えてみます。仮想マシン（VM）は「自分名義の一戸建て」のようなもので、土地（物理サーバー）こそクラウド事業者から借りますが、家の設計・家具の配置・掃除まで自分で管理する必要があります。OSのアップデートやミドルウェアの設定も、発注者側の責任です。

コンテナは「家具付きの賃貸マンションの一室」に近い存在です。建物の管理や共用部の掃除は大家（クラウド事業者）が担当し、部屋の中にアプリケーションと必要なライブラリを「箱詰め」で持ち込みます。引っ越し（別のクラウドへの移行）も、箱ごと運べば基本的にそのまま動きます。

サーバーレスはさらに踏み込んだ発想で、「ホテルのルームサービス」に近いものです。部屋を借りて家具を持ち込むのではなく、「必要な料理（コード）」を渡しておけば、呼ばれたときだけ調理・配膳してくれます。使わない時間帯は費用が発生しません。

発注者目線での3つの判断観点（費用・運用・拡張性）を先出し

この「お任せ範囲」の違いが、そのまま費用・運用・拡張性のトレードオフに直結します。お任せ範囲が広いほど、運用の手離れはよくなる反面、特定のクラウド事業者のサービスに深く依存することになります。一方で、コンテナは移植性が高い代わりに、負荷に応じたスケーリング設計や監視の仕組みを自分たちで整えなければなりません。

以降のセクションでは、この3観点（費用・運用・拡張性）を物差しにして、コンテナとサーバーレスを同じ土俵で比較していきます。

コンテナとは？仮想マシンとの違いをわかりやすく解説

コンテナは「アプリを箱ごと運ぶ」仕組み

コンテナとは、アプリケーション本体と、それを動かすために必要なライブラリ・設定ファイル・実行環境を「ひとつの箱」にまとめて、どの環境でも同じように動かす技術です。名前のとおり、港で見かける物流コンテナのイメージが近く、「中身が何であっても、規格さえ合えば同じ船・トラック・列車で運べる」という発想です。

現場でよく使われるたとえとして、「自分のPCでは動くのに、本番サーバーでは動かない」という現象があります。これは開発環境と本番環境の差異が原因で起きることが多く、従来は調査と対応に多くの時間を取られてきました。コンテナはアプリと実行環境をひとまとめに梱包するため、開発者のPC・テスト環境・本番環境で同じ「箱」を動かすことになり、この種のトラブルを大幅に減らせます。

仮想マシン（VM）との違い：軽さ・速さ・再現性

コンテナと仮想マシン（VM）は、どちらも「1台のサーバー上で複数のアプリを隔離して動かす」点では共通しています。違いは、OSを丸ごと仮想化するか、アプリ部分だけを軽く隔離するかです。

VMは1つひとつが独立したOSを持つため、先ほどの比喩でいう「家ごと引っ越し」に近い重さがあります。起動に数十秒から数分かかり、使うメモリも大きくなります。一方、コンテナはOSのカーネルをホストと共有し、アプリと必要なライブラリだけを「荷物として詰めて」運びます。起動は数秒以内、1台のサーバーに数十個のコンテナを詰め込めるケースも珍しくありません。

観点	仮想マシン（VM）	コンテナ
イメージ	家ごと引っ越し	荷物だけ詰めて移動
起動時間	数十秒〜数分	数秒以内
1台のサーバーに載る数	数個〜十数個	数十個以上
環境の再現性	OS設定に依存しやすい	箱ごと同じなので高い

SCROLL→

発注者目線のメリット（引き継ぎ・環境差異トラブルの低減）

コンテナを発注者視点で言い換えると、次の3点が大きな利点になります。

1. 開発スピードの向上: 開発者ごとに環境構築でつまずく時間が減り、着手から動作確認までが早くなります
2. 環境差異トラブルの減少: 「本番でだけ動かない」といった原因切り分けが困難な障害が起きにくくなり、品質保証コストが下がります
3. 引き継ぎのしやすさ: 別の開発会社に保守を引き継ぐ場合でも、コンテナという規格に載っていれば、環境の移行コストが大きく下がります

つまりコンテナは、エンジニアの生産性を上げる技術であると同時に、発注者にとってはリスク低減と引き継ぎ負担の軽減という形でメリットが返ってきます。提案書に「コンテナ化」と書かれていたら、「開発効率とリスク低減のための投資」として評価する視点を持つとよいでしょう。

Dockerとは？発注者が知るべき「コンテナの事実上の標準」

Dockerはコンテナを扱う業界標準ツール

Dockerとは、コンテナを簡単に作成・配布・実行できるようにしたソフトウェアで、現在のコンテナ技術の事実上の業界標準（デファクトスタンダード）です。Dockerの登場により、開発者は「Dockerfile」と呼ばれる設計図さえ書けば、アプリを再現可能な形で箱詰めできるようになりました。

Docker Hubというオンラインのレジストリ（コンテナイメージの共有倉庫）には、OS・データベース・プログラミング言語のランタイムなど、すぐに使える部品が公式ベンダーから多数公開されています。これにより、開発会社はゼロから環境を組み立てる必要がなく、実績のある構成部品を組み合わせて短期間でシステムを立ち上げられます。

Kubernetes・ECS・Cloud Runとの関係（Dockerイメージを動かす基盤）

実運用では、Dockerで作ったコンテナを「どこで」「どう束ねて」動かすかが問題になります。1個のコンテナだけで完結するシステムは少なく、実際にはWebサーバー・バックエンド・データベース処理など複数のコンテナを協調させ、負荷に応じて数を増減させる仕組みが必要です。この役割を担うのがオーケストレーションツールで、代表的なものに以下があります。

• Kubernetes（クバネティス）: Google発のオープンソース。機能が豊富で大規模運用に強いが、学習コストが高い
• Amazon ECS / ECS Fargate: AWSのコンテナ実行サービス。Fargateはサーバー管理すら不要で、コンテナだけ渡せば動く
• Google Cloud Run: Googleのコンテナ実行サービス。リクエストがない時はゼロスケールでき、サーバーレスに近い使い勝手

これらはいずれも「Dockerで作ったコンテナ」を動かす基盤で、同じコンテナを別の基盤に移すこと自体は比較的容易です。

発注者がDocker採用を評価する3つの観点（標準性・移植性・人材確保）

発注者が提案書で「Docker」の文字を見たときに確認したい観点は次の3つです。

1. 標準性: 広く使われている技術のため、ノウハウ・情報が豊富で、障害時の解決速度が上がる
2. 移植性: Dockerイメージは基本的にどのクラウドでも動くため、将来別のクラウドに移す際の負担が小さい
3. 人材確保: エンジニアの求人市場でもDockerは標準スキルのため、開発会社を切り替えても引き継ぎ可能なエンジニアを見つけやすい

つまり、Docker採用は「特定ベンダーに縛られず、エンジニアの流動性が確保された選択」として理解してよい構成です。提案書に「独自の仮想環境」や「特定ツールに強く依存するデプロイ方法」が書かれているよりも、Dockerベースの方が発注者のリスクは低くなります。

サーバーレスとは？FaaS・Lambdaの仕組みを発注者向けに解説

サーバーレスは「呼ばれたときだけ動く自動販売機」

サーバーレスとは、コードをクラウド事業者に預けておき、「呼ばれたときだけ」自動で実行してもらえる仕組みです。「サーバーがない」わけではなく、「サーバーの存在と管理を開発者・発注者が意識しなくてよい」ことが本質です。

イメージとしては、自動販売機に近いものがあります。普段は電源と補充を事業者に任せておき、買い物客が来てボタンを押した瞬間だけドリンクが出てくる――この「使われた分だけの稼働・課金」が、サーバーレスの考え方です。サーバーが常時起動しているわけではないため、リクエストがない時間帯は費用が発生しません。

FaaS（Function as a Service、ファース）は、このサーバーレスを関数単位で実現するサービスの総称で、代表例がAWS Lambdaです。Lambdaでは、「ユーザーが画像をアップロードしたらサムネイルを生成する」「毎晩0時にデータを集計する」といった処理を、短いコード（関数）としてアップロードしておけば、指定した条件が満たされたときだけクラウドが実行してくれます。

イベント駆動・従量課金・自動スケーリングの3大特徴

サーバーレスの特徴は、次の3つに集約できます。

1. イベント駆動: 「HTTPリクエストが来たら」「ファイルがアップロードされたら」といったきっかけ（イベント）で呼ばれたときだけ動く仕組み
2. 従量課金: 実行回数と実行時間の合計に対して課金される。待機時間には料金がかからない
3. 自動スケーリング: 同時に大量のリクエストが来ても、クラウドが自動で並列実行数を増やす。開発者はスケーリング設計を意識しなくてよい

AWS公式のLambda料金ページ（AWS Lambda の料金）では、呼び出し回数1回あたりと、実行時間のGB秒あたりで料金が設定されており、処理が軽ければ軽いほど1回の単価も小さくなります。

AWS Lambda / Cloud Run functions / Azure Functions の代表例

主要クラウドの代表的なサーバーレス（FaaS）サービスは以下のとおりです。提案書でどれが採用されているかによって、使えるエコシステムが変わります。

• AWS Lambda: 最も歴史が長く、エコシステム（連携サービス）が最大規模。他のAWSサービスとの連携が強力
• Google Cloud Run functions: コンテナ技術と統合されており、コンテナベースの開発から段階的に移行しやすい
• Azure Functions: Microsoft製品・サービスとの親和性が高く、Microsoft 365/SharePointなどとの連携案件で採用されやすい

提案書に「Lambda」と書かれていた場合、「特定イベント発生時にだけ処理を走らせる、従量課金の構成を採用している」と読み替えることができます。次のセクションでは、この従量課金がコンテナと比べてどこでコスト優位になるか、どこで逆転するかを見ていきます。

コンテナとサーバーレスの違いを費用・運用・拡張性で比較

ここまで両者の仕組みを見てきましたが、発注者として最も気になるのは「結局、どっちが自社のシステムに合うのか」という点だと思います。本セクションでは、費用・運用・拡張性・ベンダーロックイン・開発スピードの5観点で、両者を同じ物差しで並べます。

比較一覧表（費用・運用・拡張性・ベンダーロックイン・開発スピード）

観点	コンテナ（例: ECS Fargate）	サーバーレス（例: Lambda）
初期費用	コンテナ設計・オーケストレーション設定が必要で、相対的に高め	関数を書いてデプロイするだけで済み、相対的に低い
ランニング費用	常時起動している時間に対して課金（アクセスがなくても発生）	実行回数と実行時間に応じた従量課金（待機時間は無料）
運用負荷	スケーリング設定・監視・ログ収集の設計が必要	サーバー管理不要で手離れがよいが、分散トレースやデバッグは工夫が要る
拡張性	事前設定の範囲で自動スケール。スケール上限の設計が必要	原則として無制限に自動スケール（クラウド側の上限あり）
ベンダーロックイン	Dockerイメージは他クラウドにも移しやすく、ロックイン度は低め	クラウド固有のサービス（Lambda等）と連携するほど移行コストが上がる
開発スピード	本番同等の環境を再現しやすく、テストしやすい	個別関数は小さく作れるが、全体のアーキテクチャ設計に慣れが必要

SCROLL→

この表だけでも判断材料になりますが、最も意思決定に効くのは費用の具体的な逆転ポイントです。

費用の逆転ポイント ― 月間リクエスト数の目安

サーバーレスは「使った分だけ課金」の構造上、リクエスト数が少ないうちはコンテナより圧倒的に安くなります。一方、リクエスト数が増えるとコンテナの常時稼働型の方が単価で有利になり、どこかの地点で費用が逆転します。

StigCloudの2026年版ECS FargateとLambdaのコスト比較（ECS Fargate vs Lambda — Which AWS Compute to Pick in 2026）によれば、一般的なWeb APIワークロードでPythonやJavaランタイムを使う場合、Lambdaとコンテナの費用逆転ポイントは1日あたり5万〜15万リクエストの範囲に収まると報告されています。月次に換算するとおおむね150万〜450万リクエスト程度です。この水準を下回るとLambdaの「ゼロスケール課金（使わない時は0円）」の優位性が際立ち、超えるとFargateの定額コンピュート料金が相対的に安くなります。

同記事ではさらに、2026年第1四半期時点で、Fargate on ARM64は1 vCPU時間あたり0.03238ドル、1 GB時間あたり0.00356ドル（米国東部リージョン）で、x86版より20%安いと記載されています。Lambdaは100万回の呼び出しあたり0.20ドル、加えて実行時間に応じたGB秒単価で課金されます。また、ランタイムが重い場合（Javaで初期化に10秒かかるケース等）はLambdaの初期化コストが増え、逆転ポイントはさらに下にずれるとも報告されています。

実際の判断材料として、次の目安を押さえておくとよいでしょう。

• 月間リクエスト100万回以下: サーバーレス（Lambda）が費用面で有利な可能性が高い
• 月間リクエスト150万〜450万回: ワークロード特性次第でどちらが得か変わる、丁寧な試算が必要な領域
• 月間リクエスト500万回以上で常時トラフィックあり: コンテナ（Fargate等）が費用面で優位になりやすい

なお、このラインはランタイム選定（Python / Node.js / Javaなど）や初期化処理の重さによって大きく動きます。詳細な料金計算はAWS Lambda の公式料金ページで確認できます。提案書に「Lambdaでコスト効率を」と書かれている場合、想定リクエスト数と初期化処理の重さを具体的に質問すると、妥当性を検証できます。

運用負荷の違い ― 「手離れのよさ」と「デバッグの難しさ」はトレードオフ

サーバーレスの運用負荷は、多くの観点でコンテナよりも低くなります。サーバー本体のメンテナンス、OSのアップデート、スケーリング設計、負荷分散――これらはすべてクラウド側で処理されます。

ただし、いいことづくめではありません。「複数の関数が連鎖して動く」仕組みになるため、ある処理のエラー原因を追跡する際、どこで何が起きたかを追う「分散トレース」の設計が必要になります。ログが関数ごとに細切れに出力されるため、監視基盤（CloudWatch、Datadog等）の設計にも一定のノウハウが求められます。

一方コンテナは、自分たちで設計する範囲が広い反面、ログやデバッグは「1つのプロセスの中を追う」感覚に近く、従来のアプリケーション運用の延長で対応できます。運用体制が弱いチームには、コンテナの方が「よく知られた運用のまま移行できる」というメリットがあります。

ベンダーロックインの違い ― 移行しやすさで評価する

将来、別のクラウドに移行したい、あるいは他社と併用したいと考えたときに、どれだけ柔軟に動けるかも重要な判断軸です。

コンテナ（特にDocker）は、仕様がオープンに標準化されているため、AWS・Google Cloud・Azure間で同じイメージをおおむねそのまま動かせます。ベンダーロックインは相対的に小さく、将来の選択肢が広い構成です。

サーバーレスは、AWS Lambda・Cloud Run functions・Azure Functionsといった各社固有のサービスに依存します。特にLambdaから他のサービスを呼び出す「連携部分」はクラウド固有の書き方になるため、コンテナに比べると移行コストが高くなります。ただし、処理の中核部分を移植しやすい形で書く設計指針もあり、AWS公式の意思決定ガイド（AWS Fargate or AWS Lambda?）でも、ロックインを減らす設計手法が紹介されています。

提案書を評価する際は、「どの部分がクラウド固有の書き方になっているか」「将来移行する場合、何を書き直すことになるか」を開発会社に確認しておくと、将来のリスクが見えやすくなります。

発注者がアーキテクチャ選択で押さえる判断軸

ここまでの比較を踏まえて、実際に提案書を評価する際のチェックリストとして、5つの判断軸に落とします。加えて、どちらか一方に寄せる必要はなく、「適材適所のハイブリッド構成」も選択肢になるため、その評価観点も最後に示します。

判断軸1 ― 実行時間とリクエストのパターン

最初に確認すべきは、そのシステムが「どんなリクエストパターンで動くか」です。

• 短時間・バースト型（数秒で終わる処理、1日1回の集計、画像アップロード時の変換など）: サーバーレス向き。呼ばれない時間帯は課金されない
• 長時間・常時稼働型（チャットサーバー、動画ストリーミング、常時応答が必要なAPIなど）: コンテナ向き。常時稼働前提でコストを積みやすい

なお、AWS Lambdaは1回の実行時間に15分という上限があります。15分を超える処理が発生する場合、サーバーレスだけでは完結できず、コンテナや他のバッチ基盤との組み合わせが必要です。

判断軸2 ― 必要なメモリ・CPU・GPU

処理の重さも大きな判断材料になります。

• 軽い処理（APIのルーティング、JSONの変換、簡単な計算）: サーバーレスで十分
• 重い処理（画像・動画の変換、機械学習の推論、大規模データ処理）: コンテナの方が柔軟。GPUが必要な機械学習の推論などは、コンテナ基盤の方が選択肢が豊富

Lambdaはメモリ上限・実行時間上限があるため、重い処理を無理にサーバーレスに押し込むと、処理の分割や設計上の工夫が必要になり、かえって開発コストが上がることがあります。

判断軸3 ― ステート（状態）保持の要否

「ステート（状態）」とは、前のリクエストの情報を覚えておく必要があるかどうか、という観点です。

• ステートレス（毎回、リクエストが独立している処理。例: 商品検索API、単発の変換処理）: サーバーレス向き
• ステートフル（進行中の対話、長時間のセッション管理、接続を維持するWebSocketなど）: コンテナ向き

サーバーレスは「都度新しく起動される前提」のため、状態保持には外部のデータベースやキャッシュ（Redis等）との併用が基本になります。状態保持の頻度が多い処理をサーバーレスで無理に組むと、設計が複雑化しがちです。

判断軸4 ― チームの運用体制と技術者確保

技術選定は「使いたい技術」ではなく「続けられる体制があるか」で決めるべきです。

• インフラ運用の経験者がいない / 兼任体制: サーバーレスが手離れの良さで有利
• SRE・インフラ専任がいる / 監視基盤がすでに整っている: コンテナの自由度を活かせる

ただしサーバーレスは「分散トレース」「関数間連携のデバッグ」など、従来とは異なる運用ノウハウを必要とします。体制が弱いからといって即座にサーバーレスが楽とは限らず、むしろ「慣れた運用形態に近いコンテナの方が、トラブル対応のときに落ち着いて対処できる」というケースもあります。

判断軸5 ― ベンダーロックインの許容度

将来、別のクラウドに移行する可能性、複数クラウド併用の可能性をどれだけ重視するかも、判断軸になります。

• ロックインを避けたい / マルチクラウドを想定: コンテナ（Docker）ベースが有利
• 特定クラウドを長期採用予定 / 連携サービスを最大活用したい: サーバーレスの利便性を取ってよい

提案書で「Lambda」「API Gateway」「DynamoDB」などAWS固有サービスが多数組み合わされている場合、AWSを長期的に使う前提の設計と理解してよいでしょう。後から抜けにくくなることを承知のうえで承認する、という意識が必要です。

ハイブリッド構成は「適材適所」が正しいか評価する

5つの判断軸を通して見るとわかるとおり、多くのシステムは「すべてサーバーレス」でも「すべてコンテナ」でもなく、処理の性質ごとに使い分けるのが合理的です。実際、AWS公式ドキュメント（AWS Fargate or AWS Lambda?）でも、Lambda関数とコンテナを組み合わせたハイブリッド構成が推奨されるケースが明記されています。

よくある妥当なハイブリッドパターンは次のとおりです。

• 常時稼働の本体APIはコンテナ、単発の画像変換・通知送信はサーバーレス: メインのトラフィックはコンテナで安定処理し、突発的な処理をサーバーレスに逃がす
• ユーザー向けAPIはコンテナ、管理者向けバッチ処理はサーバーレス: 使用頻度の差をコストに直結させる
• Webフロントはコンテナ、イベント駆動の非同期処理はサーバーレス: 処理方式の違いを素直に技術に反映する

提案書にハイブリッド構成が書かれていた場合は、「なぜこの処理はコンテナで、あの処理はサーバーレスなのか」という使い分けの根拠を開発会社に確認します。根拠が「実行時間」「リクエスト頻度」「状態保持の有無」など、上記5つの判断軸で説明できれば妥当です。「なんとなくそうしました」だと、運用開始後のコスト最適化の余地が大きい兆候です。

提案書を読み解くチェックリストと発注者がすべき質問

判断軸を頭に入れたうえで、実際に提案書を手にしたときに、どのキーワードを見て、どんな質問を投げるべきかを整理します。

提案書で確認したい5つのキーワードと意味

提案書や見積書に出てくる代表的な用語と、それが意味する構成イメージは次のとおりです。

キーワード	意味	確認したい観点
Docker / コンテナ化	アプリを箱詰めして動かす技術	なぜコンテナ化するのか、移植性を活かせる設計か
ECS / ECS Fargate	AWSのコンテナ実行サービス。Fargateはサーバー管理不要	コンテナ数・スケール設定・月額想定
Kubernetes / EKS	大規模なコンテナ管理基盤	規模に対して過剰でないか、運用体制が足りるか
AWS Lambda / Cloud Run functions / Azure Functions	代表的なサーバーレス（FaaS）	どの処理をFaaS化したか、想定リクエスト数
API Gateway	FaaSをHTTP APIとして公開する仕組み	認証・レート制限・料金の見積

SCROLL→

これらのキーワードが何の役割を果たしているかをざっくり捉えたうえで、「なぜそれを選んだか」を質問すると、構成の妥当性が見えてきます。

発注者が投げるべき8つの質問

提案書を受け取ったタイミングで、次の8つを開発会社に投げてみてください。質問の深さに対する回答の質で、提案の検討度合いを測ることができます。

1. なぜコンテナ（またはサーバーレス）を選んだのですか？他の構成と比較しましたか？――判断の理由と比較の有無を確認する
2. 月間リクエスト数の想定はどのくらいで、それに対して費用逆転ポイントはどこに置いていますか？――コストの試算根拠を確認する
3. 1回あたりの処理時間と、最長どれくらいまで許容する設計ですか？――Lambdaの15分制約などに引っかからないかを確認する
4. ステート（状態）の保持はどう設計していますか？――セッション管理・キャッシュ・データベースの分担を確認する
5. 運用監視・ログ収集はどう組みますか？――CloudWatch、Datadogなど、具体的な監視基盤を確認する
6. 将来AWSから別のクラウドに移したい、と言われたら何をやり直すことになりますか？――ベンダーロックインの深さを定量的に確認する
7. 開発・ステージング・本番の環境差異はどう防ぐ設計ですか？――コンテナ採用のメリットが活かされているかを確認する
8. 運用開始後、保守は自社で内製するのか・御社に継続依頼するのかで、構成の推奨は変わりますか？――自社体制に応じた最適化の余地を確認する

これらの質問に対して「検討していませんでした」「一般的な構成なので」と返ってきた場合は、もう一歩踏み込んで議論する必要があります。逆に、具体的な数値やトレードオフを提示できる開発会社は、運用開始後の対応力も期待できます。

まとめ ― サーバーレスとコンテナは「どちらが正解」ではない

ここまで見てきたとおり、サーバーレスとコンテナは「どちらが優れているか」を競う関係ではなく、システム特性・チーム体制・ビジネス要件に応じて適切な側を選ぶ、あるいは組み合わせて使う技術です。

発注者として押さえておきたいポイントを改めてまとめます。

• コンテナ（Docker）は、環境の再現性・移植性・引き継ぎのしやすさが強みで、常時稼働・重い処理・ベンダーロックインを避けたい場合に向く
• サーバーレス（Lambda等）は、手離れのよさ・従量課金・自動スケーリングが強みで、イベント駆動・短時間処理・リクエスト変動が激しい場合に向く
• 費用の逆転ポイントは、おおむね月間150万〜450万リクエスト付近。この水準の上下で有利な側が入れ替わる
• 提案書を評価するときは、「なぜこの構成か」「費用逆転点をどこに置いたか」「運用・監視をどう設計するか」「ロックインの深さ」を開発会社に問うと妥当性が見える

本記事の冒頭で描いた「検索後の理想状態」――つまり「このシステム特性ならコンテナが妥当」「この部分はサーバーレスにするとコスト効率が高い」と自分の言葉で説明できる状態に、近づけたのではないかと思います。

技術選定の最終判断は、一人で抱え込む必要はありません。開発会社と対等に議論し、判断軸を持って質問し、回答の納得度で評価する――この姿勢さえ持てれば、意思決定者としてGOサインを出す準備は整います。もし提案された構成に疑問が残るなら、本記事で示した8つの質問を投げてみてください。返ってくる回答の質が、パートナーの提案力と運用開始後の安心感を測る材料になるはずです。

アーキテクチャ選択の判断をさらに深めたい方には、マイクロサービスとモノリスの違いとは？発注者が知るべき選び方の判断基準も合わせてご覧ください。サーバーレス・コンテナの選択と合わせて、システム全体の構造設計を俯瞰する視点が得られます。