実行環境の選び方 ― VM/コンテナ/サーバーレス/Wasm ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「システムアーキテクチャ」カテゴリ第4弾として、アプリを「どこで動かすか」を決める実行環境の選定について解説する記事です。

2013年のDocker登場で「VM主役」から「コンテナがデフォルト」へ10年で入れ替わった領域で、さらにFaaS・Wasmが押し寄せています。本記事ではベアメタル／VM／コンテナ／サーバーレス／WebAssemblyの5レイヤーを比較し、規模・用途別の推奨構成、移行時の鬼門まで解説します。

このカテゴリの他の記事

どこまで自分で管理し、どこから手放すか

選定は、開発効率・運用負荷・コスト・性能・スケーラビリティの全てに効きます。2010年代まではVMが主流でしたが、2020年代はコンテナがデファクトになりました。さらに FaaS と Wasm が急速に広がりつつあります。

「どれを選ぶか」よりも「どこまで管理を手放すか」の視点で見ると、筋の良い判断がしやすくなります。

実行環境の選定は、後戻りしやすいTwo-way Doorではありません。一度コードをその環境向けに書くと、別環境への移行は部分的な書き直しを要します。特にFaaSのようなイベント駆動前提の設計は、通常サーバーへの戻しが大工事になります。

最初に選ぶときの体感軽さと、あとで戻すときの重さは対称的ではないので、「気軽に試す」姿勢で選ぶと後で痛い目を見ます。

実行環境は「どこまで自分で管理するか」のトレードオフです。手放せるところまで手放すのが基本になります。

主な5つの選択肢

現代の実行環境は5つのレイヤーに分類できます。下に行くほど「管理範囲が狭く、運用が楽」な代わりに、自由度や性能に制約が乗ります。

flowchart TB
    BARE[ベアメタル<br/>HW〜App全て自分]
    VM[VM<br/>OS〜App自分]
    CON[コンテナ<br/>App+ランタイムのみ]
    FAAS[FaaS<br/>関数コードのみ]
    WASM[WebAssembly<br/>サンドボックスで実行]
    BARE --> VM --> CON --> FAAS --> WASM
    LEFT[管理範囲: 大<br/>自由度: 高<br/>運用負荷: 高] -.- BARE
    WASM -.- RIGHT[管理範囲: 小<br/>自由度: 低<br/>運用負荷: 低]
    classDef heavy fill:#fee2e2,stroke:#dc2626;
    classDef mid fill:#fef3c7,stroke:#d97706;
    classDef modern fill:#dbeafe,stroke:#2563eb;
    classDef light fill:#fae8ff,stroke:#a21caf;
    class BARE heavy;
    class VM mid;
    class CON,FAAS modern;
    class WASM light;

選択肢	管理範囲	代表例
ベアメタル	ハードウェア〜アプリ全て	物理サーバー直接運用
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（Virtual Machine、仮想マシン）は、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方式を主要な観点で並べると、左から右になるほど管理負荷が下がる。この傾向がはっきり出ます。

観点	ベアメタル	VM	コンテナ	FaaS	Wasm
管理範囲	全て	OS以上	アプリのみ	コードのみ	コードのみ
起動速度	遅（分）	遅（分）	速（秒）	やや速	最速（ms）
コスト	固定・高	固定	変動	従量	従量
スケール	困難	手動寄り	自動	自動	自動
ベンダーロックイン	低	中	中	高	低

ベンダーロックインの観点では、コンテナと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は規模が見合う組織の武器です。背伸びで選ぶと運用で溶けます。

実行環境移行の鬼門・禁じ手

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のリトライ戦略を未設計	自動リトライで同じ処理が複数回走り、決済・メール送信が二重化

移行は「1つの機能で試す → 監視実戦投入 → 本格採用」の3段階です。いきなり全体を切り替えるビッグバン移行は禁じ手です。

移行は段階的に。全切り替えは本番障害の最短ルートです。

AI時代の視点

AI駆動開発（バイブコーディング）が前提になると、選定軸は「人間の学習コスト」から「性能・起動速度・コールドスタート・ロックイン」へ一気に移ります。

Kubernetesのように学習コストが高くて敬遠されてきた技術も、AIが設定ファイルを書く時代では人間の負担が大幅に下がり、むしろ性能と移植性で選ばれるようになる可能性が高いです。

AI時代に有利	AI時代に不利
コンテナ（ポータブル・IaC で完結）	ベアメタル手動運用
Wasm（高速起動・ロックイン少）	ベンダー固有ランタイム
FaaSでもOIDC+IaC管理	GUIでポチポチ設定する実行環境
Kubernetes（AIがYAMLを書ける前提）	独自の運用自動化ツール

逆に、FaaSのコールドスタート問題はAIでは解けません。「低レイテンシならWasm、バッチならFaaS」という性能主導の使い分けがより鮮明になります。

学習コストで諦めていたKubernetesの再評価、コールドスタート回避のためのWasm台頭。ここが次の潮流です。

AI時代の選定は「性能要件・移植性」が中心軸です。学習コストは意思決定の要素から外れていきます。

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/オンプレ）の活用方針
• ランタイム言語のサポート状況

よくある失敗

• いきなりKubernetesを採用 → 運用チームが疲弊。小規模ならECSやCloud Runで十分。背伸びの典型
• FaaSで長時間処理 → 15分制限を見落として設計ミス
• コンテナ化したが環境依存を残して動かない ― Dockerfileの設計を怠った結果
• コールドスタートを軽視してUX悪化 ― FaaSのAPIが初回数秒遅延しクレーム多発
• ベアメタルから直接FaaSへ移行 ― 段階（VM→コンテナ→FaaS）を飛ばすと破綻

最終的な判断の仕方

実行環境は「どこまで自分で管理するか」のトレードオフで、基本原則はできるだけ管理を手放す方に倒すことです。管理範囲が狭いほど運用人員が少なく済み、バグの温床も減ります。

ただし性能・レイテンシ・ロックインで譲れない線がある場合のみ、上位レイヤー（VM・ベアメタル）に戻る。これが背骨です。

2026年のデフォルトはコンテナで、「起動速度 × ポータビリティ × エコシステム成熟度」のバランスが最良です。FaaSとWasmは補助的に組み合わせる位置づけで、用途特化（イベント駆動・エッジ処理）の武器として使います。

AI駆動開発では、Kubernetesの学習コスト問題がAIに吸収されるため、性能・移植性が主軸に戻る流れが加速しています。

選定の優先順位をまとめると次の通りです。

1. 性能要件・物理制約（レイテンシ・GPU・コールドスタート）で除外候補を洗う
2. 運用人員の厚みでk8s / ECS / Cloud Runの粒度を決める
3. ポータビリティ（将来のクラウド移行可否）でFaaS濃度を調整
4. 単一方式に固執せず、用途別の使い分けを設計に組み込む

「コンテナを軸に、足りない部分だけFaaS/Wasm」が2026年の鉄板構成です。学習コストはAIが肩代わりする前提で選びます。

まとめ

本記事はクラウド時代の実行環境（VM・コンテナ・サーバーレス・Wasm）の選び方を解説しました。如何だったでしょうか。

2026年のデフォルトはコンテナを軸に用途特化を必要最小限で足すのが鉄板です。k8sは規模が見合う組織の武器なので、小中規模はECS/Cloud Runで十分です。

次回はOSの選定、「Linux/Windows/UNIX」のどれを選ぶかを解説していきます。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。