はじめに
このシリーズでは、AWS Lambda を基準に、5つのクラウドの FaaS とコンテナ実行基盤を比べてきました。比べるほどに見えてきたのは、「FaaS」と「コンテナ」の境界がどんどん曖昧になっている ということです。
- AWS Lambda は、コンテナイメージを動かせるようになり、HTTP サーバーをそのまま載せられる形態（AWS Lambda Web Functions）まで登場した
- Google Cloud Run functions は、中身がコンテナ実行基盤の Google Cloud Run そのもの
- Google Cloud Run、Azure Container Apps、さくら AppRun などのコンテナ実行基盤は、FaaS のようにゼロスケールする
締めくくりとして、2回に分けて「FaaS とは何だったのか」と「今ならどう作るか」を考えます。今回は前半として、次の5つを扱います。
- FaaS の変遷（関数からコンテナに近づいていった流れ）
- AWS Lambda が登場したとき、なぜ好まれたのか
- FaaS を支える基盤技術
- FaaS のセキュリティ事情
- では、FaaS とは何か（定義を考え直す）
この記事の事実関係は、2026年11月時点の各社の公式情報にもとづいています。「定義」や「考察」の部分は筆者の見解です。
1. FaaS の変遷 ― 「関数」から「コンテナ」へ近づいた12年
年表
| 年 | AWS Lambda | ほかのクラウド・関連技術 |
|---|---|---|
| 2007〜2008 | ― | PaaS の時代（Heroku、Google App Engine） |
| 2014 | AWS Lambda のプレビュー公開。Node.js のみ。S3、DynamoDB、Kinesis のイベントで起動 | ― |
| 2015 | 一般提供開始。Java に対応 | Amazon API Gateway の登場で、HTTP の API を作れるように |
| 2016 | Python に対応。タイムアウトが5分に。VPC 接続、環境変数、AWS SAM | Azure Functions が一般提供開始。Google Cloud Functions が登場 |
| 2017 | AWS X-Ray、SAM Local | Cloudflare Workers が発表される |
| 2018 | カスタムランタイムで任意の言語に対応。Amazon SQS のトリガー。タイムアウトは後に15分へ | Firecracker がオープンソース化。Knative が登場。Google Cloud Functions が一般提供開始 |
| 2019 | Provisioned Concurrency（事前に起動しておく機能） | Google Cloud Run が一般提供開始（コンテナのサーバーレス実行） |
| 2020 | コンテナイメージに対応（最大 10 GB）。メモリ 10 GB / 6 vCPU。1 ms 単位の課金 | ― |
| 2021 | Graviton2（Arm）に対応。Lambda Extensions | ― |
| 2022 |
Function URLs（API Gateway なしで HTTPS）。SnapStart。/tmp が最大 10 GB |
Google Cloud Functions の第2世代（中身は Google Cloud Run） |
| 2023 | レスポンスのストリーミング。スケールが12倍速く | ― |
| 2024 | 再帰ループの検出。VS Code ベースのエディタ | Google Cloud Functions が Google Cloud Run functions に統合。Azure Functions Flex Consumption が一般提供開始 |
| 2025 | INIT フェーズの課金開始。AWS Lambda Managed Instances、AWS Lambda Durable Functions、テナント分離モード | さくら AppRun が正式サービス化（Knative ベース） |
| 2026 | AWS Lambda MicroVMs（6月）、AWS Lambda Web Functions（10月） | Cloudflare の Python Workers が一般提供開始 |
4つの流れ
年表を眺めると、FaaS は次の4つの方向に少しずつ変わってきたことがわかります。
| 流れ | 変化 | 例 |
|---|---|---|
| ① 制約の緩和 | 短い・小さい → 長い・大きい | タイムアウト（数分 → 15分 → AWS Lambda Managed Instances で90分）、メモリ 10 GB、/tmp 10 GB |
| ② 持ち込みの自由 | 決められた言語 → 何でも | マネージドランタイム → カスタムランタイム → コンテナイメージ |
| ③ HTTP への適応 | イベント専用 → Web サーバーそのもの | Amazon API Gateway が必須 → Function URLs → AWS Lambda Web Functions |
| ④ 実行モデルの変化 | 1リクエスト = 1インスタンス → 多重化・常駐 | Provisioned Concurrency → マルチコンカレンシー、CPU 時間課金 → AWS Lambda Managed Instances |
逆方向の流れも同時に起きています。コンテナ実行基盤が、FaaS のようになってきた のです。
FaaS はコンテナに近づき、コンテナは FaaS に近づいた。 2026年の時点で、両者はほぼ同じ場所に集まりつつあります。
2. なぜ AWS Lambda は好まれたのか ― FaaS のストロングポイント
2014年当時の状況
AWS Lambda が登場した頃、クラウドでアプリを動かすには、おおむね次の作業が必要でした。
- EC2 のインスタンスを選び、OS をセットアップしてパッチを当て続ける
- オートスケールの設定を自分で組み、ピークに合わせて台数を確保する
- 夜間や休日など、誰も使っていない時間もサーバー代を払う
- 「S3 にファイルが置かれたら処理する」程度のことでも、常に動くサーバーとポーリングの仕組みが要る
AWS Lambda は、これらをまとめて不要にしました。
FaaS の7つの強み
| # | 強み | 中身 |
|---|---|---|
| 1 | サーバー管理がない | OS、ランタイム、パッチ、台数の管理をクラウドが引き受ける |
| 2 | イベントの「糊」になれる | S3、DynamoDB、SQS などのイベントに、コードを直接つなげられる。サービス同士をつなぐ処理をほぼ設定だけで書ける |
| 3 | ゼロスケールと従量課金 | 使っていない時間は0円。1回だけ動く処理にもサーバー代がかからない |
| 4 | 自動スケール | スケールの設定なしで、1件から数千件まで同じコードで処理できる |
| 5 | 責任範囲が小さい | セキュリティの責任のうち、OS とランタイムの部分をクラウドが持つ |
| 6 | 小さい単位でデプロイできる | 関数ごとにデプロイできるので、マイクロサービスやチームの分割と相性が良い |
| 7 | 試すコストが低い | 無料枠の中で、すぐに本番と同じ環境で試せる |
特に効いたのは ②イベントの「糊」 と ③ゼロスケール です。「バッチサーバーを1台立てるほどでもない処理」が、クラウドの中にはたくさんあったからです。
12年後の今、その強みはどうなったか
| 強み | 2026年の状況 |
|---|---|
| サーバー管理がない | コンテナ実行基盤でもほぼ同じ（Google Cloud Run、Azure Container Apps、さくら AppRun） |
| イベントの「糊」 | 今も FaaS の最大の強み。特に AWS Lambda のイベント連携の幅は、ほかのサービスより抜けている |
| ゼロスケールと従量課金 | ゼロスケールできるコンテナ実行基盤が増え、FaaS だけの強みではなくなった |
| 自動スケール | コンテナ実行基盤でも標準になった。スケールの速さ では今も FaaS が有利 |
| 責任範囲が小さい | マネージドランタイムを使う FaaS は今も有利（コンテナはベースイメージの管理が必要） |
| 小さい単位でデプロイ | コンテナでも同じことができる |
| 試すコストが低い | 各社に無料枠があり、差は小さい |
FaaS ならではの強みとして残ったのは、イベント連携・スケールの速さ・ランタイムを管理しなくてよいこと の3つだと言えます。
3. FaaS を支える基盤技術
隔離技術
FaaS の基盤は、たくさんの利用者のコードを、1台の物理サーバーの上で、安全かつ高速に動かす 必要があります。そのための隔離技術が、各社の FaaS の性格を決めています。
| 技術 | 仕組み | 起動の速さ | 隔離の強さ | 使っている主なサービス |
|---|---|---|---|---|
| コンテナ（namespace / cgroups） | Linux カーネルを共有し、見える範囲を分ける | 速い | △ カーネルを共有する | 一般的なコンテナ基盤 |
| gVisor | ユーザー空間で動くカーネルが、システムコールを肩代わりする | 速い | ○ | Google Cloud Run（第1世代の実行環境） |
| microVM（Firecracker） | 最小限の機能だけを持つ軽量な仮想マシン | 速い（約125 ms） | ◎ ハードウェア仮想化 | AWS Lambda、AWS Fargate |
| V8 isolate | JavaScript エンジンの中で、メモリ空間を分ける | 非常に速い（数 ms） | ○（独自のサイドチャネル対策と組み合わせる） | Cloudflare Workers |
| WebAssembly | ブラウザ由来のサンドボックスでバイナリを動かす | 非常に速い | ○ | 一部のエッジ実行基盤 |
Firecracker：AWS Lambda の心臓部
AWS Lambda と AWS Fargate を支えているのが、AWS が開発して2018年にオープンソース化した Firecracker です。
| 項目 | 内容 |
|---|---|
| 言語 | Rust（約5万行） |
| 起動時間 | アプリのコードが動き出すまで 約125 ms |
| メモリのオーバーヘッド | 1つあたり 5 MB 未満 |
| 作成速度 | 1台のホストで 毎秒最大150個 |
| デバイス | ネットワーク、ブロック、vsock、シリアル、最小限のキーボードの 5種類だけ（USB や GPU はない） |
| 防御 | jailer で権限を落とし、seccomp でシステムコールを制限する |
「仮想マシンの強い隔離 と コンテナ並みの軽さ を両立する」という発想が、FaaS をマルチテナントで安全に提供するための鍵でした。AWS Lambda MicroVMs は、この技術をそのまま利用者に開放したサービスと見ることもできます。
AWS Lambda の構成（概念図）
コールドスタートを短くする技術
| 技術 | 内容 | 例 |
|---|---|---|
| ウォームプール | 起動済みの環境を用意しておき、すぐ割り当てる | 各社の内部実装 |
| スナップショットと復元 | 初期化が終わった状態を保存し、そこから再開する | AWS Lambda SnapStart（Firecracker のスナップショット） |
| 事前起動 | 利用者が指定した数を常に起動しておく | Provisioned Concurrency、Always Ready インスタンス、最小インスタンス数 |
| 軽い隔離 | そもそも起動が速い技術を使う | V8 isolate（Cloudflare Workers） |
| 先読み | 接続が来た時点で準備を始める | Cloudflare Workers は TLS のハンドシェイク中にコードを読み込む |
そのほかの重要な部品
- 配置とビンパッキング: どのホストにどの関数を置けば、リソースを無駄なく使えるかを決める仕組み。FaaS の採算は、ここで決まると言っても過言ではありません。
- イベントソースマッピング: SQS や Kinesis などを FaaS 側が読みに行き、関数を呼び出す仕組み。「イベントの糊」の正体です。
- 細かい計量: 1 ms 単位（AWS Lambda）や CPU 時間（Cloudflare Workers）で、使った量を正確に測る仕組み。従量課金を成り立たせています。
4. FaaS のセキュリティ事情
責任共有モデルの変化
| レイヤー | 仮想マシン（IaaS） | コンテナ実行基盤 | FaaS（マネージドランタイム） |
|---|---|---|---|
| 物理・ハイパーバイザー | クラウド | クラウド | クラウド |
| OS | 利用者 | クラウド | クラウド |
| ランタイム・ベースイメージ | 利用者 | 利用者 | クラウド |
| アプリのコード・依存ライブラリ | 利用者 | 利用者 | 利用者 |
| 権限・設定・データ | 利用者 | 利用者 | 利用者 |
FaaS では利用者の責任範囲が最も小さくなります。ただし、コードと権限の責任は必ず利用者に残ります。そして、FaaS には FaaS 特有のリスクがあります。
FaaS 特有のリスク
| リスク | 内容 | 対策 |
|---|---|---|
| 権限の与えすぎ | 関数の数だけ権限の設定があり、まとめて強い権限を付けがち | 関数ごとに最小権限のロールを付ける |
| イベントインジェクション | HTTP だけでなく、ファイル名やキューのメッセージなど、あらゆるイベントが攻撃の入り口になる | すべてのイベントの入力を検証する |
| 依存ライブラリ | 小さな関数でも大量のパッケージを含みがち | SBOM の作成、脆弱性スキャン、コード署名 |
| シークレットの扱い | 環境変数に平文で入れがち | シークレット管理サービスを使い、取得は初期化時に1回だけにする |
| 実行環境の再利用によるデータの残留 | 前のリクエストのデータが、グローバル変数や /tmp に残る |
リクエストごとの情報をグローバルに置かない。/tmp は使ったら消す |
| マルチコンカレンシーによる混線 | 同時に処理している別のユーザーのデータが混ざる（#4 参照） | リクエストのスコープに情報を閉じ込める |
| Denial of Wallet | 大量のリクエストを送られ、自動スケールで 請求額が膨らむ | 同時実行数の上限、レート制限、予算アラート |
| 再帰ループ | 関数が出力したイベントで自分自身が起動し、無限に動き続ける | 設計で避ける（AWS Lambda には再帰ループを検出する機能がある） |
| 見えにくさ | 処理が多数の関数に分散し、攻撃の全体像を追いにくい | 分散トレース、構造化ログ、リクエスト ID |
マルチテナントと隔離の新しい動き
FaaS の上で SaaS を作る場合や、AI が生成したコードを動かす場合には、「利用者のさらに先にいるユーザー同士」の隔離 が問題になります。最近は、ここに各社が手を入れ始めています。
- AWS Lambda のテナント分離モード（2025年11月）: 呼び出し時にテナント ID を渡すと、あるテナントが使った実行環境を、ほかのテナントに使い回さない ようになります。これまでは、テナントごとに関数を分けるなどして自前で作る必要がありました。
- AWS Lambda MicroVMs（2026年6月）: AI が生成したコードなど、信頼できないコードを隔離して動かす ためのサンドボックスです。
- Cloudflare Workers: isolate は仮想マシンより隔離が弱い分、サイドチャネル攻撃への対策を独自に重ねて提供しています。
セキュリティのチェックリスト
- 関数ごとに最小権限のロールを付けている
- HTTP 以外のイベントの入力も検証している
- シークレットを環境変数に平文で入れていない
- 依存ライブラリの脆弱性をスキャンしている
-
グローバル変数や
/tmpにリクエストの情報を残していない - 同時実行数の上限と予算アラートを設定している（Denial of Wallet 対策）
- マルチテナントの SaaS なら、テナント間の隔離方法を決めている
- ログに個人情報やトークンを出力していない
5. では、FaaS とは何か
よく使われる定義
CNCF（Cloud Native Computing Foundation）のサーバーレスのホワイトペーパーでは、サーバーレスを「サーバーの管理を必要とせずにアプリを作り、動かす考え方」と説明しています。そのうえで、FaaS は 一般にイベント駆動の計算を提供するもの と位置づけています。
一般に、FaaS の特徴としては次の5つがよく挙げられます。
- イベント駆動: リクエストやイベントをきっかけに動く
- サーバー管理が不要: OS や台数を意識しない
- 自動スケール・ゼロスケール
- 使った分だけ課金: アイドル時は0円
- ステートレス・短命: 状態を持たず、短時間で終わる
2026年のサービスに当てはめてみる
この5つの特徴を、今のサービスに当てはめてみます。
| サービス | イベント駆動 | サーバー管理不要 | ゼロスケール | 使った分だけ課金 | ステートレス・短命 |
|---|---|---|---|---|---|
| AWS Lambda（Event Functions） | ○ | ○ | ○ | ○ | ○ |
| AWS Lambda Web Functions | △（HTTP サーバー） | ○ | ○ | ○（CPU 時間） | △（長く生きる） |
| AWS Lambda Managed Instances | ○ | △（EC2 を選ぶ） | × | ×（EC2 料金） | △ |
| AWS Lambda Durable Functions | ○ | ○ | ○ | ○ | ×（状態を持ち、最大1年） |
| Cloudflare Workers | ○ | ○ | ○ | ○（CPU 時間） | ○ |
| Google Cloud Run（コンテナ） | △（HTTP サーバー） | ○ | ○ | ○ | △ |
| Azure Container Apps | △ | ○ | ○ | ○ | △ |
| AWS Fargate | × | △ | × | × | × |
「AWS Lambda」という名前のサービスでさえ、5つの特徴をすべて満たさない形態がある 一方で、コンテナ実行基盤の Google Cloud Run は、ほとんどの特徴を満たしています。「関数かどうか」「コンテナかどうか」では、もう線を引けません。
定義を考え直す
では、FaaS の本質はどこにあるのでしょうか。このシリーズで比べてきた結果から、筆者は次の3つの軸で考えるのがよいと考えます。
| 軸 | FaaS 的 | コンテナ・サーバー的 |
|---|---|---|
| 管理の単位 | リクエスト・イベント | インスタンス・台数 |
| 課金の単位 | 処理した量（実行時間・CPU 時間） | 確保した量（起動時間） |
| 起動のきっかけ | イベントが来たら、基盤が勝手に用意する | 利用者が起動しておく |
そのうえで、筆者なりの定義を次のようにまとめます。
FaaS とは、利用者が「実行環境」ではなく「処理したいリクエストやイベント」だけを渡し、実行環境の起動・台数・停止をすべて基盤に任せ、処理した量に応じて支払う計算基盤のことである。
この定義では、「関数」はプログラミングモデルの1つにすぎません。HTTP サーバーを渡そうが、コンテナイメージを渡そうが、利用者が実行環境のライフサイクルを意識しなくてよいなら、それは FaaS 的なサービスです。
逆に、AWS Lambda Managed Instances のように、利用者が台数や EC2 の種類を意識し、確保した量に払うなら、関数で書いていても コンテナやサーバーに近い と言えます。
まとめ
- 変遷: FaaS は「制約の緩和」「持ち込みの自由」「HTTP への適応」「実行モデルの変化」の4方向に進化し、コンテナに近づいた。同時に、コンテナ実行基盤も FaaS に近づき、両者はほぼ同じ場所に集まりつつある。
- 強み: AWS Lambda が好まれた理由は、サーバー管理なし、イベントの「糊」、ゼロスケールなど。今も FaaS ならではの強みとして残るのは、イベント連携・スケールの速さ・ランタイムを管理しなくてよいこと。
- 基盤技術: Firecracker（microVM）、gVisor、V8 isolate などの隔離技術と、スナップショット、配置、計量の技術が FaaS を支えている。
- セキュリティ: 利用者の責任範囲は小さくなるが、権限、イベントの入力、依存ライブラリ、Denial of Wallet など FaaS 特有のリスクがある。マルチテナントの隔離は、各社が新たに手を入れ始めている。
- 定義: 「関数かどうか」ではなく、管理の単位・課金の単位・起動のきっかけ で FaaS を捉え直すのがよい。
次回（最終回）は、これを踏まえて 「もし今、自分が FaaS を設計するなら」 と FaaS の未来の予想 を考えます。
参考
- AWS Lambda turns ten: The first decade of serverless innovation（AWS News Blog）
- Study of Firecracker MicroVM（arXiv）
- CNCF Serverless Whitepaper（CNCF Serverless WG）
- AWS Lambda announces new tenant isolation mode（AWS）
- Lambda のクォータ（AWS）
- AWS Lambda introduces MicroVMs（AWS News Blog）
- Announcing AWS Lambda Web Functions（AWS News Blog）
- AWS Lambda standardizes billing for INIT phase（AWS Compute Blog）
- AppRun 正式サービス提供開始のお知らせ（さくらインターネット）