本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第4弾として、アプリを「どこで動かすか」を決める実行環境の選定について解説する記事です。
2013年のDocker登場で「VM主役」から「コンテナがデフォルト」へ10年で入れ替わった領域で、さらにFaaS・Wasmが押し寄せています。本記事ではベアメタル／VM／コンテナ／サーバーレス／WebAssemblyの5レイヤーを比較し、規模・用途別の推奨構成、移行時の鬼門まで解説します。
本記事のテーマについてさらに詳しく知りたい方は『Amazon Web Services基礎からのネットワーク＆サーバー構築 改訂4版』・『Linuxのしくみ 増補改訂版』も参考にしてみてください。
そもそも実行環境とは何か
実行環境とは、ざっくり言えば「書いたプログラムを実際に動かすための土台」です。
料理の厨房を想像してください。自分の家のキッチン（ベアメタル/VM）なら好きな調理器具を揃えられますが、掃除もメンテも全部自分です。シェアキッチン（コンテナ）なら基本設備は揃っていて、自分の道具だけ持ち込めます。出前専門のクラウドキッチン（FaaS）なら注文が入った時だけ厨房を使い、使った分だけ払います。どこまで自分で管理し、どこから他人に任せるか──このトレードオフが実行環境の選択です。
なぜ実行環境の選択が重要なのか
もし実行環境を気軽に選んだらどうなるか。一度コードをその環境向けに書くと、別環境への移行は部分的な書き直しを要します。特にFaaSのようなイベント駆動前提の設計は、通常サーバーへの戻しが大工事になります。
選定は開発効率・運用負荷・コスト・性能・スケーラビリティの全てに効きます。2020年代はコンテナがデファクトになり、さらに FaaS と Wasm が急速に広がりつつあります。最初に選ぶときの体感軽さと、あとで戻すときの重さは対称的ではないので、「気軽に試す」姿勢で選ぶと後で痛い目を見ます。
主な5つの選択肢
現代の実行環境は5つのレイヤーに分類できます。下に行くほど「管理範囲が狭く、運用が楽」な代わりに、自由度や性能に制約が乗ります。
| 選択肢 | 管理範囲 | 代表例 |
|---|---|---|
| ベアメタル | ハードウェア〜アプリ全て | 物理サーバー直接運用 |
| VM（仮想マシン） | OS〜アプリ | AWS EC2・VMware |
| コンテナ | アプリ+ランタイムのみ | Docker・Kubernetes |
| サーバーレス（FaaS） | アプリコードのみ | AWS Lambda・Cloud Functions |
| WebAssembly（Wasm） | ブラウザ/ランタイム上 | Cloudflare Workers |
原則は「できるだけ楽な選択肢を選ぶ」です。機能要件と性能要件を満たせる範囲で、管理を手放せるところまで手放す。これが背骨です。
住居で例えると、ベアメタルは土地付き一戸建て（庭も配管も自分）、VMは分譲マンション（建物は共用、部屋は自分）、コンテナはウィークリーマンション（家具付き・いつでも移れる）、FaaSはカプセルホテル（寝る時だけ料金発生）、Wasmは空港ラウンジ（一瞬で入って一瞬で出られる）。この比喩を頭に入れておくと、各方式の立ち位置が掴みやすくなります。
ベアメタル
ベアメタルは、OSすら入っていないまっさらな物理サーバーに、直接OSを入れてアプリを動かす形態です。クラウドが存在しなかった時代は唯一の選択肢でした。今もオンプレミスの多くはこれで動いています。
| メリット | デメリット |
|---|---|
| 仮想化のオーバーヘッドがなく高速 | ハードウェア管理が全て自分の責任 |
| ハードウェアを完全にコントロール可 | スケールが物理的に限られる |
| 物理的分離で最高レベルのセキュリティ | 調達・構築に時間がかかる |
| 既存の物理資産を活用できる | 障害時の復旧が困難 |
新規でベアメタルを選ぶ理由はほぼありません。候補になるのはHFT（High-Frequency Trading、マイクロ秒単位で売買する金融取引）・リアルタイム演算・科学計算・特殊GPUワークロードなど、「わずかなオーバーヘッドも許されない」用途だけです。通常のWebアプリやバックエンドでベアメタルを選ぶのは、やってはいけない選択です。
今でも使われるのは「仮想化のオーバーヘッドすら許されない」ケースのみです。
VM（仮想マシン）
VMは、1台の物理サーバー上で複数の仮想的なコンピューターを動かす技術です。各VMは独立したOSを持ち、お互いに干渉せず動作します。クラウドのEC2やAzure VMなどは全てVMで提供されています。
仮想化方式は大きく2つあります。ホストOS型は通常のOS上で仮想化ソフト（VMware Workstation等）を動かす方式で、開発用途でよく使われます。本番ではハイパーバイザー型（AWS Nitro や ESXi 等）が主流で、物理ハードウェアに直接仮想化層を入れるため処理効率が高く、EC2もこの方式で動いています。
| メリット | デメリット |
|---|---|
| ハードウェアを気にせず運用可 | ゲストOS層のオーバーヘッドがある |
| 柔軟にリソース変更・スケール可 | OS以降は自分で構築・運用 |
| 既存オンプレアプリの移行に向く | コンテナと比べ起動が遅い |
| OSレベルの完全な独立性 | 集約度がコンテナより低い |
クラウド移行の入り口としては依然有力です。ただし新規で選ぶならコンテナが本命になります。
コンテナ
コンテナは、アプリケーションと動作に必要なライブラリ・設定を丸ごとパッケージ化した軽量な実行単位です。VMがOSごとの仮想化なのに対し、コンテナはOSカーネルをホストと共有し、アプリ層だけを隔離します。これにより起動が数秒〜ミリ秒と劇的に速くなります。
登場の最大の意義は、「開発環境では動くが本番では動かない」問題の根絶です。Docker イメージという形でアプリと実行環境を一緒に固めて配布するため、どこで動かしても同じ挙動をします。
このポータビリティがCI/CDサイクルを劇的に短縮し、DevOps（開発と運用を一体で進めて頻繁にリリースする文化）が広がる原動力になりました。Docker は2013年に当時の PaaS ベンダー dotCloud が社内ツールとして開発したものを公開したのが始まりで、10年で業界を塗り替えました。
| メリット | デメリット |
|---|---|
| 起動が高速（秒単位） | コンテナ自体の学習コスト |
| 環境の同一性が保証される | オーケストレーション（k8s）が複雑 |
| リソース効率が高く集約できる | OSカーネルレベルの分離はVMより弱い |
| CI/CDと相性が良い | 状態を持つワークロードには追加設計が必要 |
2026年のデファクト標準です。新規WebアプリはほぼDockerコンテナで作るのが鉄板です。
コンテナを運用するツール
コンテナを作って動かすには、コンテナ化ツールとオーケストレーション（複数コンテナの統合管理）ツールが必要です。現場で使われる定番は以下の通りです。
| カテゴリ | ツール | 説明 |
|---|---|---|
| コンテナ化 | Docker | 圧倒的シェア。実質的な標準 |
| オーケストレーション | Kubernetes（k8s） | Google発の汎用オーケストレーター |
| マネージドk8s | EKS / AKS / GKE | 各クラウドのk8sマネージド版 |
| 簡易オーケストレーション | AWS ECS / Cloud Run | より手軽にコンテナ運用 |
Kubernetesは強力ですが、運用の牙が鋭い。小〜中規模には過剰で、下手に入れると運用チームが溶けます。AWSのECS や App Runner、GCP の Cloud Run といった「k8sより簡単にコンテナを動かせる」選択肢のほうが、規模が小さいうちは筋が良いです。
k8sは万能ツールですが運用コストが高い。規模に合わせて選びます。
サーバーレス（FaaS）
FaaS（Function as a Service）は、関数単位でコードをアップロードするだけで動くサービスです。AWS Lambda・Azure Functions・Google Cloud Functions が代表格です。広義の「サーバーレス」はサーバー管理が不要なサービス全般を指しますが、現場ではFaaSを指すことが多いです。
開発者はハードウェアもOSもコンテナも一切意識せず、ビジネスロジックのコードだけ書けばよい。実行時間に対する従量課金のため、リクエストのない時間は1円もかからない。この「極めて低コストで動かせる」性質が最大の売りです。
| メリット | デメリット |
|---|---|
| インフラ管理が完全に不要 | コールドスタート（起動遅延） |
| 呼び出し回数で課金・アイドルゼロ | 実行時間に上限（Lambda15分等） |
| 自動スケール | ステートレス（状態を持てない） |
| デプロイが簡単 | 長時間処理・高頻度呼び出しには不向き |
FaaSが刺さるのは、イベント駆動処理・非同期バッチ・Webhookハンドリング・API単位の軽量処理です。常時稼働型のWebサーバーに使うのは典型的な地雷です。
FaaSの制限と対策
FaaSの「関数単位の実行」という性質から、通常のサーバーとは異なる制約が付いてきます。これを知らずに採用すると、運用フェーズで必ず痛い目を見ます。
| 制限 | 内容 | 対策 |
|---|---|---|
| コールドスタート | 非アクティブ時の初回起動に数秒かかる | Provisioned Concurrency・常時呼び出し |
| 実行時間上限 | Lambda 15分 / Azure 10分等 | 長時間処理は Step Functions 等で分割 |
| ステートレス | メモリを次回実行に持ち越せない | DynamoDB等の外部ストアで状態管理 |
| デバッグ困難 | ローカルで動かしにくい | SAM・Serverless Framework等で対応 |
コールドスタートはユーザー向けAPIで特に顕在化します。VIPユーザー向け・低レイテンシ要件のAPIにFaaSを選ぶのは筋が悪い。そこはWasmかコンテナが本命です。
FaaSは「軽量・短時間・イベント駆動」で輝きます。向かない用途を見極めることが重要です。
WebAssembly（Wasm）
WebAssembly（Wasm）は、元々ブラウザで高速処理（3D描画・動画編集・物理演算等）を動かすために生まれた技術です。C++・Rust・Go などの高級言語を .wasm バイナリにコンパイルし、ブラウザや Wasm ランタイムで動かします。JavaScript の数倍〜数十倍の速度で実行できます。
近年注目されるのは、サーバー側の実行環境としてのWasmです。Cloudflare Workers・Fastly Compute@Edge などのエッジコンピューティング環境で採用され、「FaaSより圧倒的に速いコールドスタート」「安全な分離」「多言語対応」という特徴で、FaaSの次世代として勢力を伸ばしつつあります。
| メリット | デメリット |
|---|---|
| コールドスタートがミリ秒単位 | エコシステムがまだ発展途上 |
| サンドボックスで高い安全性 | 対応言語・ライブラリに制限 |
| 複数言語のバイナリが同じ形式で動く | デバッグツールが未成熟 |
| エッジ実行に最適 | ファイルI/Oや一部のOS機能に制約 |
「エッジ実行の本命技術」FaaSの限界を超える次世代ランタイムと位置付けられています。
FaaS / Edge Runtime / BaaS ― 似て非なる三者
「サーバーを管理しない」という看板で混同されがちですが、走る場所と守備範囲が違います。
FaaSは関数単位で呼ばれた時だけ特定リージョンで実行、Edge Runtimeは世界中のエッジ（CDN拠点）でミリ秒起動する軽量ランタイム、BaaS（Backend as a Service）は認証・DB・関数・Realtime通信まで束ねた「バックエンド丸ごと」の提供形態。レイヤーが異なります。相互排他ではなく組み合わせる方式でもあります。
個人開発やMVPでは BaaS + Edge Runtime でバックエンドの自前実装をほぼゼロにする構成が、ここ2〜3年で一気に定着しました。LLM呼び出しのようなストリーミング応答が必要な場面では、通常のFaaSよりEdge Runtimeが圧倒的に相性が良く、採用の決め手になることが多いです。
| 観点 | FaaS | Edge Runtime | BaaS |
|---|---|---|---|
| 代表例 | AWS Lambda・Cloud Functions | Cloudflare Workers・Vercel Edge | Supabase・Firebase・Convex |
| コールドスタート | 数百ms〜数秒 | ほぼゼロ（ms単位） | 内蔵関数はEdge相当 |
| 実行時間 | 15分等の上限 | 30秒前後＋ストリーミング別枠 | サービス次第 |
| 得意分野 | 非同期バッチ・Webhook | ストリーミング・軽量API | 認証+DB+関数の一括提供 |
| ロックイン | 中〜高 | 低〜中 | 高（DBごと引っ越しが困難） |
BaaSは「バックエンドを書かない」を極限まで突き詰めた選択肢です。個人開発で最も費用対効果が高い反面、成長後の脱出コストは重くなります。
5つの方式の総合比較
5方式を主要な観点で並べると、左から右になるほど管理負荷が下がる。この傾向がはっきり出ます。
ベンダーロックインの観点では、コンテナとWasmはポータブルで他クラウドに移行しやすい一方、FaaSはクラウド固有機能と密結合するため移行が難しいです。FaaSを選ぶ時点でロックインの覚悟が必要です。
ケース別選定
実行環境は要件と制約で自然と絞られます。典型ケースと推奨の組み合わせは次の通りです。
| ケース | 推奨 |
|---|---|
| 新規WebアプリをSaaS型で作る | コンテナ（+ ECS/Cloud Run） |
| オンプレWebアプリを最小改修で移行 | VM（EC2） |
| オンプレWebアプリを運用効率化も含めて移行 | コンテナ |
| イベント駆動バッチ・Webhook処理 | FaaS（Lambda） |
| エッジでの超低レイテンシ処理 | Wasm（Cloudflare Workers等） |
| 超高速処理が必要な特殊ケース | ベアメタル |
新規のWebアプリなら、「コンテナがデフォルト」その上で、部分処理（画像変換・通知・Webhook受信）をFaaSで補完するハイブリッドが、現場で最も多い構成です。
規模・用途別の推奨構成
「コンテナが鉄板」は正しいですが、規模・用途によって最適な粒度が変わります。チーム人員と実行環境の相性は下記が目安です。
| チーム規模 | アプリ特性 | 推奨実行環境 | オーケストレーション |
|---|---|---|---|
| 〜3人 | Web / API 中心 | Cloud Run / App Runner / Vercel | 不要（マネージド） |
| 3〜10人 | Web + バッチ | コンテナ（ECS Fargate）+ Lambda（バッチ） | ECS（k8sは早すぎ） |
| 10〜30人 | マイクロサービス | コンテナ + EKS / GKE（マネージドk8s） | k8s（運用専任必須） |
| 30人〜 | 多サービス・マルチリージョン | k8s + サービスメッシュ | k8s + Istio / Linkerd |
| 特殊用途 | エッジ低レイテンシ | Wasm（Cloudflare Workers等） | ― |
| 特殊用途 | HFT・科学計算 | ベアメタル | ― |
k8sを入れる実質下限は「10人規模かつ運用専任1人」それ未満で入れると CRD・Helm・Ingress・証明書更新・ネットワークポリシーの学習コストで全員が疲弊します。
ECS Fargate / Cloud Run は「k8sの90%の機能を10%の学習コストで使える」の目安で、小中規模の鉄板です。
k8sは規模が見合う組織の武器です。背伸びで選ぶと運用で溶けます。
AI時代の判断軸 ― 性能と移植性が中心軸に
AI駆動開発（バイブコーディング）が前提になると、選定軸は「人間の学習コスト」から「性能・起動速度・ロックイン」へ一気に移ります。Kubernetesのように学習コストが高くて敬遠されてきた技術も、AIが設定ファイルを書く時代では負担が大幅に下がります。
| AI時代に有利 | AI時代に不利 |
|---|---|
| コンテナ（ポータブル・IaC で完結） | ベアメタル手動運用 |
| Wasm（高速起動・ロックイン少） | ベンダー固有ランタイム |
| FaaSでもOIDC+IaC管理 | GUIでポチポチ設定する実行環境 |
| Kubernetes（AIがYAMLを書ける前提） | 独自の運用自動化ツール |
選定の優先順位をまとめると次の通りです。
- 性能要件・物理制約（レイテンシ・GPU・コールドスタート）で除外候補を洗う
- 運用人員の厚みでk8s / ECS / Cloud Runの粒度を決める
- ポータビリティ（将来のクラウド移行可否）でFaaS濃度を調整
- 単一方式に固執せず、用途別の使い分けを設計に組み込む
KubernetesのYAML生成はAIの得意領域になった
Kubernetes のDeployment・Service・Ingress・HPA等のYAMLマニフェストは、AIが高精度で生成できる領域です。学習データにHelmチャートやkustomize構成が大量に含まれているため、「Nginx Ingressで/apiをバックエンドに振り分けるIngress YAMLを書いて」のような指示にはほぼ正確に応答します。
ただし、RBAC（権限管理）・NetworkPolicy・PodSecurityStandard のようなセキュリティ系YAMLは、動作に直結しないため省略されやすいです。AIが生成したk8s構成をレビューする際は、セキュリティ関連のマニフェストが含まれているかを確認する習慣が必要です。
コンテナ化されたアプリはAIによる運用自動化と相性が良い
Dockerfileの記述・マルチステージビルドの最適化・ヘルスチェックの設定――これらはAIが正確に書ける定番パターンです。さらに、コンテナ化されたアプリはログが標準出力に流れる前提で設計されるため、AIによるログ解析や障害検知との連携が自然に成立します。
ベアメタルや従来型VMで動くアプリは、ログの場所・起動方法・設定ファイルの形式がプロジェクトごとに異なるため、AIが運用タスクを自動化する際の事前情報が多く必要になります。
やってはいけないこと
VM → コンテナ → FaaS / Wasm の移行は「レイヤーを1段ずつ」進めるのが定石です。飛ばすと大抵壊れます。
| 禁じ手 | なぜダメか |
|---|---|
| VM 運用中アプリをいきなり FaaS化 | ステートフルな挙動・15分超の処理・セッションなど、FaaS の前提に合わない設計を引きずる |
| Docker 化でログを標準出力に流さず従来通りファイル出力 | コンテナ再起動でログ消失。stdout/stderrへ流すのが基本 |
| k8s導入をインフラ専任なしで決める | YAML・RBAC・Helm・CRD・Ingress Controller・CNI・証明書の全てが学習対象。専任なしでは事故頻発 |
| FaaSで常時稼働Web APIを提供 | コールドスタート数百ms〜数秒がユーザー体験を削る。Edge Runtime かコンテナが本命 |
| Wasmでファイルマッピングやネイティブライブラリを多用する処理を動かす | 対応が限定的で、ポリフィルの互換性破綻が起きる |
コンテナのベースイメージに latest タグを指定 | 再現性が消え、ある日突然動かなくなる典型パターン |
| FaaSのリトライ戦略を未設計 | 自動リトライで同じ処理が複数回走り、決済・メール送信が二重化 |
| FaaSで15分超の長時間処理を設計 | タイムアウト上限（Lambda 15分）に抵触し途中切断。長時間処理はStep Functions / キュー + ワーカーで分割する |
| コンテナ化したが環境依存をハードコード | ホスト固有のパス・ポート・環境変数を埋め込むと、別環境デプロイで即座に壊れる |
移行は「1つの機能で試す → 監視実戦投入 → 本格採用」の3段階です。いきなり全体を切り替えるビッグバン移行は禁じ手です。
移行は段階的に。全切り替えは本番障害の最短ルートです。
k8sを小規模で入れた日（業界事例）
数人規模のチームで Kubernetes を本番導入し、毎週どこかの CRD（Custom Resource Definition、k8sを拡張する独自リソース定義）や Helm Chart（k8sマニフェスト群をパッケージ化する仕組み）に振り回されて疲弊した。という事例は、2018〜2020年頃に多数報告されています。監視・ログ・Ingress・証明書更新・ネットワーク設定、どれも「正しい運用」を維持するのに専門知識が必要で、3人以下のチームにはどう見ても過剰でした。
同じ時期にAWS ECSやGCP Cloud Runで組んだチームは、同じ機能を1/5の運用負荷で回せていたケースが多い、という観察もあります。あるチームでk8sを入れて半年持たずにECSに戻した、という話を身近で聞いたこともあります。
k8sは規模が大きい組織にとっての標準ですが、「規模が大きくないのに選ぶ」と苦しむ。典型的な背伸びの地雷です。
k8sは「規模が見合う組織」の武器です。小規模で選ぶなら、ECS/Cloud Runで十分です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 実行環境の主軸（VM / コンテナ / FaaS / Wasm）
- オーケストレーション方式（k8s / ECS / マネージドサービス）
- スケール戦略（自動・手動・スケジュール）
- コールドスタートの許容度
- ベンダーロックインの受容範囲
- 既存資産（VM/オンプレ）の活用方針
- ランタイム言語のサポート状況
この記事に関連する記事
まとめ
本記事はクラウド時代の実行環境（VM・コンテナ・サーバーレス・Wasm）の選び方を解説しました。如何だったでしょうか。
2026年のデフォルトはコンテナを軸に用途特化を必要最小限で足すのが鉄板です。k8sは規模が見合う組織の武器なので、小中規模はECS/Cloud Runで十分です。
次回はOSの選定、「Linux/Windows/UNIX」のどれを選ぶかを解説していきます。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS コンテナサービス も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（9/89）