本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第4弾として、アプリを「どこで動かすか」を決める実行環境の選定について解説する記事です。
2013年のDocker登場で「VM主役」から「コンテナがデフォルト」へ10年で入れ替わった領域で、さらにFaaS・Wasmが押し寄せています。本記事ではベアメタル／VM／コンテナ／サーバーレス／WebAssemblyの5レイヤーを比較し、規模・用途別の推奨構成、移行時の鬼門まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『Amazon Web Services基礎からのネットワーク＆サーバー構築 改訂4版』・『Linuxのしくみ 増補改訂版』も参考にしてみてください。
この記事の結論
- デフォルトはコンテナ（ECS / Cloud Run）
- k8sは「10人規模+運用専任1人」が実質下限。小中規模はECS / Cloud Runで十分
- FaaSは間欠処理専用。常時稼働APIには使わない
- 移行はレイヤーを1段ずつ。ビッグバン移行はしない
この記事を読む前に
本記事はサーバーやネットワークといったインフラ寄りの用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「サーバーとクラウドの基本」と「Webサービスが動く仕組み」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそも実行環境とは何か
実行環境とは、ざっくり言えば「書いたプログラムを実際に動かすための土台」です。
料理の厨房を想像してください。自分の家のキッチン（ベアメタル/VM）なら好きな調理器具を揃えられますが、掃除もメンテも全部自分です。シェアキッチン（コンテナ）なら基本設備は揃っていて、自分の道具だけ持ち込めます。出前専門のクラウドキッチン（FaaS）なら注文が入った時だけ厨房を使い、使った分だけ払います。どこまで自分で管理し、どこから他人に任せるか──このトレードオフが実行環境の選択です。
なぜ実行環境の選択が重要なのか
もし実行環境を気軽に選んだらどうなるか。一度コードをその環境向けに書くと、別環境への移行は部分的な書き直しを要します。特にFaaSのようなイベント駆動前提の設計は、通常サーバーへの戻しが大工事になります。
選定は開発効率・運用負荷・コスト・性能・スケーラビリティの全てに効きます。最初に選ぶときの体感の軽さと、あとで戻すときの重さは対称的ではないので、「気軽に試す」姿勢で選ぶと後で痛い目を見ます。
主な5つの選択肢
現代の実行環境は5つのレイヤーに分類できます。下に行くほど「管理範囲が狭く、運用が楽」な代わりに、自由度や性能に制約が乗ります。
| 選択肢 | 管理範囲 | 代表例 |
|---|---|---|
| ベアメタル | ハードウェア〜アプリ全て | 物理サーバー直接運用 |
| VM（仮想マシン） | OS〜アプリ | AWS EC2・VMware |
| コンテナ | アプリ+ランタイムのみ | Docker・Kubernetes |
| サーバーレス（FaaS） | アプリコードのみ | AWS Lambda・Cloud Functions |
| WebAssembly（Wasm） | ブラウザ/ランタイム上 | Cloudflare Workers |
住居で例えると、ベアメタルは土地付き一戸建て（庭も配管も自分）、VMは分譲マンション（建物は共用、部屋は自分）、コンテナはウィークリーマンション（家具付き・いつでも移れる）、FaaSはカプセルホテル（寝る時だけ料金発生）、Wasmは空港ラウンジ（一瞬で入って一瞬で出られる）。原則は「機能・性能要件を満たせる範囲で、管理を手放せるところまで手放す」です。
それぞれの使いどころ
ベアメタル・VM ― 特殊用途と移行の入り口
ベアメタル（物理サーバー直接運用）を新規で選ぶ理由はほぼありません。候補になるのはHFT（マイクロ秒単位の金融取引）・科学計算・特殊GPUワークロードなど「仮想化のわずかなオーバーヘッドも許されない」用途だけです。
VMは1台の物理サーバー上で複数の仮想コンピューターを動かす技術で、EC2やAzure VMの実体です。OSレベルの完全な独立性があり、既存オンプレアプリを最小改修でクラウドに移す入り口として今も有力です。ただし起動が遅く集約度も低いため、新規で選ぶならコンテナが本命になります。
コンテナ ― 2026年のデファクト標準
コンテナは、アプリと必要なライブラリ・設定を丸ごとパッケージ化した軽量な実行単位です。OSカーネルをホストと共有してアプリ層だけを隔離するため、起動が数秒と劇的に速く、リソース効率も高い。登場の最大の意義は、Dockerイメージでアプリと実行環境を一緒に固めて配布することで「開発環境では動くが本番では動かない」問題を根絶したことです。このポータビリティがCI/CDを劇的に短縮し、DevOpsが広がる原動力になりました。新規WebアプリはほぼDockerコンテナで作るのが鉄板です。
運用ツールの選択には注意が要ります。オーケストレーションの標準Kubernetes（k8s）は強力ですが運用の牙が鋭く、小〜中規模には過剰です。AWSのECS / App Runner、GCPのCloud Runは「k8sの90%の機能を10%の学習コストで使える」選択肢で、規模が小さいうちはこちらが筋の良い選択です。
FaaS ― 間欠的な処理の専用機
FaaS（AWS Lambda等）は、関数単位でコードを預けて呼ばれた時だけ実行するモデルです。インフラ管理が完全に不要で、リクエストのない時間は1円もかからない従量課金が最大の売りです。刺さるのはイベント駆動処理・非同期バッチ・Webhookハンドリング・画像変換のような間欠的な処理です。
ただし制約も明確です。コールドスタート（未起動時の初回起動遅延が数百ms〜数秒）、実行時間上限（Lambdaは15分）、ステートレス（状態を持ち越せない）。常時稼働のWeb APIに使うのは典型的な地雷で、低レイテンシ要件のAPIはコンテナかEdge Runtimeが本命です。
Wasm / Edge Runtime ― コールドスタートほぼゼロの次世代
WebAssembly（Wasm）は元々ブラウザで高速処理を動かすための技術ですが、近年はサーバー側の実行環境として注目されています。Cloudflare Workers・Fastly等のエッジ環境で採用され、「ミリ秒単位のコールドスタート」「安全な分離」「多言語対応」でFaaSの次世代と位置付けられます。LLM応答のストリーミングが絡む処理とは特に相性が良いです。弱点はエコシステムの未成熟さで、ファイルI/Oやネイティブライブラリに制約があります。
なお「サーバーを管理しない」という括りでは、認証・DB・関数まで束ねたBaaS（Supabase・Firebase等）もあります。FaaS＝特定リージョンで関数実行、Edge Runtime＝世界中のCDN拠点でミリ秒起動、BaaS＝バックエンド丸ごと提供、とレイヤーが違い、組み合わせて使えます。個人開発やMVPではBaaS+Edge Runtimeでバックエンドの自前実装をほぼゼロにする構成が定着しました。ただしBaaSはDBごと引っ越しが困難なロックインの重さを、採用前に見積もっておく必要があります。
5つの方式の総合比較
ベンダーロックインの観点では、コンテナとWasmはポータブルで他クラウドに移行しやすい一方、FaaSはクラウド固有機能と密結合するため移行が難しいです。FaaSを選ぶ時点でロックインの覚悟が必要です。
どう選べばいいのか ― 規模別の3シナリオ
個人開発・スタートアップなら ― マネージドに全部任せる
Cloud RunやApp Runner、Vercelのようなオーケストレーション不要のマネージドコンテナか、BaaSとEdge Runtimeの構成で始めるのが良いと思います。この規模でk8sは論外ですし、素のVMも運用の無駄になってしまいます。バックエンドの自前実装を減らすほど、プロダクト本体に時間を使えます。
中小SaaSなら ― ECS Fargate+Lambdaの組み合わせ
Web/APIはECS Fargate（またはCloud Run）、画像変換・通知・Webhook受信のような間欠処理はLambdaで補完するのが現場で最も多い構成です。チーム3〜10人ならk8sはまだ早すぎます。ログを標準出力に流す・イメージタグを固定するといったコンテナの基本作法を整えるほうが先です。
大企業・マイクロサービスなら ― k8sは専任を置いて
k8sを入れる実質下限は「10人規模かつ運用専任1人」です。マイクロサービス化・マルチリージョン・サービスメッシュ（Istio等）が本当に必要な規模なら、マネージドk8s（EKS / GKE）を専任チーム付きで運用します。HFT・科学計算のような特殊用途だけベアメタルを別枠で持ちます。
規模別の目安
| チーム規模 | 推奨実行環境 | オーケストレーション |
|---|---|---|
| 〜3人 | Cloud Run / App Runner / Vercel | 不要（マネージド） |
| 3〜10人 | ECS Fargate+Lambda（バッチ） | ECS（k8sは早すぎ） |
| 10〜30人 | コンテナ+EKS / GKE | k8s（運用専任必須） |
| 30人〜 | k8s+サービスメッシュ | k8s+Istio / Linkerd |
AI判断軸 ― 学習コストの壁が下がり、性能と移植性が中心軸に
AI駆動開発が前提になると、選定軸は「人間の学習コスト」から「性能・起動速度・ロックイン」へ移ります。Kubernetesのように学習コストが高くて敬遠されてきた技術も、AIが設定ファイルを書く時代では負担が大幅に下がります。
k8sのYAML生成はAIの得意領域になった
Deployment・Service・Ingress・HPA等のYAMLマニフェストは、AIが高精度で生成できる領域です。学習データにHelmチャートやkustomize構成が大量に含まれているためです。ただし、RBAC・NetworkPolicy・PodSecurityStandardのようなセキュリティ系YAMLは動作に直結しないため省略されやすいという癖があります。AIが生成したk8s構成をレビューする際は、セキュリティ関連のマニフェストが含まれているかの確認を習慣にする必要があります。
コンテナ化されたアプリはAI運用自動化と相性が良い
Dockerfileの記述・マルチステージビルドの最適化・ヘルスチェック設定はAIが正確に書ける定番パターンです。さらにコンテナ化されたアプリはログが標準出力に流れる前提で設計されるため、AIによるログ解析や障害検知との連携が自然に成立します。ベアメタルや従来型VMのアプリは、ログの場所・起動方法・設定形式がプロジェクトごとに異なるため、AIが運用タスクを自動化する際の事前情報が多く必要になります。
やってはいけないこと
VM → コンテナ → FaaS / Wasmの移行は「レイヤーを1段ずつ」進めるのが定石です。特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| VM運用中アプリをいきなりFaaS化 | ステートフルな挙動・長時間処理がFaaSの前提に合わない → まずコンテナ化を挟む |
| FaaSで常時稼働Web APIを提供 | コールドスタートがユーザー体験を削る → Edge Runtimeかコンテナにする |
| k8s導入をインフラ専任なしで決める | YAML・RBAC・Helm・証明書の全てが学習対象で事故が頻発する → ECS / Cloud Runで始める |
| コンテナのログをファイル出力のまま | コンテナ再起動でログが消失する → stdout / stderrへ流す |
ベースイメージに latest タグを指定 | 再現性が消え、ある日突然動かなくなる → バージョンを固定する |
| FaaSのリトライ戦略を未設計 | 自動リトライで決済・メール送信が二重実行される → 冪等性を設計に組み込む |
移行は「1つの機能で試す → 監視付きで実戦投入 → 本格採用」の3段階で進めます。いきなり全体を切り替えるビッグバン移行は本番障害の最短ルートです。
筆者メモ ― k8sを小規模で入れた日
数人規模のチームでKubernetesを本番導入し、毎週どこかのCRDやHelm Chartに振り回されて疲弊した──2018〜2020年頃に多数報告された事例です。監視・ログ・Ingress・証明書更新・ネットワーク設定、どれも「正しい運用」を維持するのに専門知識が必要で、3人以下のチームにはどう見ても過剰でした。同じ時期にECSやCloud Runで組んだチームは、同じ機能を1/5の運用負荷で回せていたケースが多く、k8sを入れて半年持たずにECSに戻した、という話を身近で聞いたこともあります。
k8sは規模が大きい組織にとっての標準ですが、「規模が大きくないのに選ぶ」と苦しむ、典型的な背伸びの地雷です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 実行環境の主軸（VM / コンテナ / FaaS / Wasm）
- オーケストレーション方式（k8s / ECS / マネージドサービス）
- スケール戦略（自動・手動・スケジュール）
- コールドスタートの許容度
- ベンダーロックインの受容範囲
- 既存資産（VM/オンプレ）の活用方針
言語化した答えはADRとして残します。書き方の具体例は以下の記事で解説しています。
この記事に関連する記事
まとめ
本記事はクラウド時代の実行環境（VM・コンテナ・サーバーレス・Wasm）の選び方を解説しました。如何だったでしょうか。
2026年のデフォルトはコンテナを軸に用途特化を必要最小限で足すのが鉄板です。k8sは規模が見合う組織の武器なので、小中規模はECS/Cloud Runで十分です。
次回はOSの選定、「Linux/Windows/UNIX」のどれを選ぶかを解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS コンテナサービス も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（15/95）