はじめに
#6 では、FaaS の変遷・強み・基盤技術・セキュリティを振り返り、FaaS の定義を次のように考え直しました。
FaaS とは、利用者が「実行環境」ではなく「処理したいリクエストやイベント」だけを渡し、実行環境の起動・台数・停止をすべて基盤に任せ、処理した量に応じて支払う計算基盤のことである。
シリーズ最終回の今回は、ここまでの比較で見えた 各社の良いところと、利用者がつまずくところ をもとに、
- もし今、自分が FaaS サービスを設計するなら、何を考えるか
- FaaS はこれからどうなるか
を考えます。
この記事は、シリーズで調べた事実をもとにした 筆者の考察と予想 です。特定のサービスの今後の計画を示すものではありません。
1. 設計の前提：誰の、どんな仕事を引き受けるのか
いきなり機能を考える前に、2026年の FaaS が引き受けるべき仕事を整理します。#1〜#5 の比較から、利用者の困りごとは次の5つにまとめられます。
| 困りごと | シリーズで見えたこと |
|---|---|
| 待ち時間に払っている | AWS Lambda（Event Functions）は I/O の待ち時間もすべて課金される（#4、#5） |
| ローカルと本番が違う | 権限、イベント、制限値の違いで「本番だけ動かない」が起きる（#3） |
| ランタイムの EOL に追われる | マネージドランタイムは定期的に移行作業が発生する（#3） |
| クラウドを移れない | イベント形式や権限の仕組みがクラウドごとに違う（#2） |
| FaaS かコンテナか、選ぶのが難しい | 課金モデルと稼働率で、どちらが安いかが入れ替わる（#5） |
そして、利用者が変わりつつある ことも前提にします。人間の開発者だけでなく、AI エージェントがコードを書き、デプロイし、呼び出す 時代になっています。
2. 12の設計判断
全体像
| # | 領域 | 設計判断 |
|---|---|---|
| 1 | プログラミングモデル | Web 標準の Request / Response を基本 にし、イベントはそれに変換して渡す |
| 2 | パッケージ | ソースコード・コンテナ・Wasm のどれでも受け付ける |
| 3 | 実行モデル | マルチコンカレンシーを標準 にし、同時処理数は基盤が動的に調整する |
| 4 | 課金 | アクティブな CPU 時間 + メモリ。待ち時間には課金しない |
| 5 | 隔離 | 用途に応じて isolate / microVM / 専有 を選べる3段階 |
| 6 | コールドスタート | スナップショットからの復元 を標準にする |
| 7 | 長時間処理と状態 | Durable Execution（途中経過の保存と再開） を組み込みで持つ |
| 8 | ランタイムの更新 | 互換性日付 方式で、EOL による強制的な移行をなくす |
| 9 | 開発体験 | ローカルでも本番と同じランタイム が動く |
| 10 | セキュリティ | 関数ごとの ID・既定で外向き通信を拒否・テナント分離 を標準にする |
| 11 | コスト管理 | 予算の上限（ハードキャップ） を設定できる |
| 12 | 可観測性 | OpenTelemetry をそのまま出力 する |
ここからは、それぞれの判断の理由を説明します。
① プログラミングモデル：Web 標準の Request / Response を基本にする
// HTTP もイベントも、同じ形で受け取る
export default {
async fetch(request: Request, env: Env, ctx: Context): Promise<Response> {
// HTTP リクエスト
},
async event(event: CloudEvent, env: Env, ctx: Context): Promise<void> {
// ストレージやキューのイベント（CloudEvents 形式）
},
};
-
HTTP は Web 標準の
Request/Responseで受け取る。Cloudflare Workers や、Hono などのフレームワークが採用している形で、ほかの基盤への移植もしやすい。 - イベントは CloudEvents 形式 に変換して渡す。クラウドごとに違うイベントの JSON を、利用者が覚えなくて済む。
- 「関数」で書きたい人には関数の形を、「Web サーバー」で書きたい人にはサーバーの形を、どちらも提供する。
② パッケージ：何でも受け付ける
| 形式 | 向いている人 |
|---|---|
| ソースコード | すぐに動かしたい人。基盤がビルドする（Google Cloud Run functions のような方式） |
| コンテナイメージ | 依存関係が多い、独自のバイナリを使う人 |
| WebAssembly | 起動速度を極限まで求める人、言語を問わず軽く動かしたい人 |
「コードをアップすればすぐ動く」と「コンテナで何でも持ち込める」を両立 させます。中身がどれでも、利用者から見た操作は同じにします。
③ 実行モデル：マルチコンカレンシーを標準にする
#4、#5 で見たとおり、同時処理数が1で固定 だと、待ち時間の長い処理（今の AI アプリの大半）でコストが大きく膨らみます。
- 既定は マルチコンカレンシー。同時処理数は、CPU とメモリの使用状況を見て 基盤が動的に調整 する（AWS Lambda Web Functions の方式）
- 「スレッドセーフでないコード」のために、同時処理数1のモードも選べる ようにしておく
- 同時処理によるデータの混線を防ぐため、リクエストのスコープを持つ API（Node.js の AsyncLocalStorage に相当するもの）をランタイムに組み込む
④ 課金：待ち時間には課金しない
| 課金の要素 | 方針 |
|---|---|
| CPU | 実際に使った CPU 時間 だけ |
| メモリ | 実行環境が存在する間（ただし単価は低く） |
| リクエスト | 低めに設定する。#5 で見たように、高いと大量リクエストのケースでコンテナに勝てない |
| 常時起動 | 割安な「アイドル料金」を用意し、コールドスタートを避けたい人が選べる |
CPU 時間で課金する方式は、Cloudflare Workers と AWS Lambda Web Functions がすでに採用しています。LLM の応答待ちが長い AI アプリが主流になった今、これが標準になるべき だと考えます。
⑤ 隔離：用途に応じて3段階から選べる
| レベル | 技術 | 起動 | 隔離 | 用途 |
|---|---|---|---|---|
| ライト | V8 isolate / Wasm | 数 ms | ○ | エッジの軽い処理、API の中継 |
| スタンダード | microVM（Firecracker 系） | 100 ms 程度 | ◎ | 一般的な API やイベント処理 |
| アイソレーテッド | 専有ホスト + microVM | 秒単位 | ◎◎ | 規制のある業界、信頼できないコード、テナントごとの完全分離 |
利用者は コードを変えずに、隔離のレベルだけを選べる ようにします。AWS Lambda MicroVMs や、AWS Lambda のテナント分離モードの考え方を、最初から1つのサービスにまとめるイメージです。
⑥ コールドスタート：スナップショットからの復元を標準にする
- 初期化が終わった状態を 自動でスナップショットに保存 し、そこから復元する（AWS Lambda SnapStart の考え方を全言語の既定にする）
- スナップショットから復元すると、乱数の種や一意な ID が重複するおそれがある。そのため、復元後に呼ばれるフック を標準の API として用意する
- アクセスのパターンを学習して、ピークの前に少しだけ先回りして起動 する
⑦ 長時間処理と状態：Durable Execution を組み込みで持つ
AI エージェントのように、何ステップも外部を呼び出し、途中で人の承認を待つ 処理が増えています。これを「15分で切れる関数」で作るのは無理があります。
- 途中経過を自動で保存し、失敗しても続きから再開 できる仕組みを、ランタイムに組み込む（AWS Lambda Durable Functions、Azure Functions の Durable Functions の考え方）
- 待っている間は課金しない
- 小さな状態を持てる 組み込みの KV ストア も用意する（Cloudflare の Durable Objects のように）
⑧ ランタイムの更新：互換性日付で EOL をなくす
#3 で見たとおり、マネージドランタイムの EOL は、利用者にとって大きな運用負担です。
- Cloudflare Workers の 互換性日付（compatibility date） の方式を採用する
- 利用者は日付で挙動を固定し、基盤側はセキュリティパッチを当て続ける
- 新しい挙動を使いたい人だけが日付を進める
言語のメジャーバージョンの差を基盤が吸収するのは簡単ではありません。それでも、「EOL が来たので全関数を移行する」という作業をなくすこと には、大きな価値があります。
⑨ 開発体験：ローカルでも本番と同じランタイムを動かす
- 本番のランタイムを オープンソースで公開 し、ローカルでもそのまま動かせるようにする（Cloudflare の workerd の方式）
- ローカルで動かしながら、本番のリソースや権限に安全につなげる モードを用意する（Cloudflare Workers のリモートバインディング、AWS Lambda のリモートデバッグ）
- AI エージェントが操作しやすい CLI と API を用意する。デプロイ、ログの確認、ロールバックを、すべて機械が読める形で返す
⑩ セキュリティ：安全な設定を既定にする
| 項目 | 既定値 |
|---|---|
| 権限 | 関数ごとに 専用の ID を自動で作り、権限は何も付けない状態から始める |
| 外向きの通信 | 既定で拒否。許可するドメインを明示する |
| シークレット | 環境変数ではなく、シークレットの専用の仕組み から注入する |
| 依存ライブラリ | デプロイ時に SBOM を自動で作り、既知の脆弱性を検出 する |
| マルチテナント | テナント ID を渡すだけで、実行環境をテナントごとに分ける |
| データの残留 |
/tmp は リクエストごとに分けた領域 を標準にする |
「設定すれば安全にできる」ではなく、「何もしなければ安全」 を目指します。
⑪ コスト管理：予算の上限を設定できる
FaaS のコストが青天井になる問題（Denial of Wallet）は、今も多くのサービスで「アラートを出す」止まりです。
- 月の予算の上限（ハードキャップ） を設定でき、超えたら止まる、または縮退モードに入る
- 同時実行数やリクエスト数の上限と合わせて、「最悪いくらかかるか」が事前にわかる ようにする
個人開発や PoC、AI エージェントが自動で作ったアプリにとって、これは特に重要です。
⑫ 可観測性：OpenTelemetry をそのまま出力する
- ログ、メトリクス、トレースを OpenTelemetry の形式で、設定なしに出力 する
- リクエスト ID とテナント ID を自動でログに付ける（マルチコンカレンシーで混ざったログを追えるように）
- 出力先は利用者が選べる（自社の監視基盤、ほかのクラウドの監視サービスなど）
番外：クラウドを移れるようにする
①の Web 標準 API、②のコンテナや Wasm、⑫の OpenTelemetry、CloudEvents を採用すると、利用者は自分のサービスから他社に移りやすくなります。サービスを提供する側にとっては、短期的には不利に見えます。
それでも、「いつでも出ていける」ことは、利用者が安心して使い始める理由になります。各国でデータ主権（ソブリンクラウド）への関心が高まっているので、国内の事業者にとってはむしろ追い風になる可能性があります。
3. 設計したサービスの全体像
4. FaaS の未来の予想
最後に、これからの FaaS がどうなるかを予想します。
予想1：「FaaS」と「サーバーレスコンテナ」の区別がなくなる
#6 で見たとおり、両者はすでにほぼ同じ場所に集まっています。数年後には、「関数で書くか、コンテナで持ち込むかは、パッケージの形式の違いにすぎない」 という認識が一般的になると考えます。Google Cloud Run functions と Google Cloud Run の関係が、その先例です。
予想2：CPU 時間課金が標準になる
AI アプリの多くは、LLM の応答を待つ時間が処理時間の大半を占めます。待ち時間に課金する方式は、利用者から選ばれにくくなる でしょう。Cloudflare Workers と AWS Lambda Web Functions に続いて、ほかのクラウドも CPU 時間課金や、待ち時間を安くする課金方式を広げると予想します。
予想3：最大の利用者は AI エージェントになる
- AI エージェントが コードを書き、FaaS にデプロイし、呼び出す ことが当たり前になる
- AI エージェントが使うツール（MCP サーバーなど）の 置き場所として FaaS が使われる
- AI が生成した 信頼できないコードを安全に動かすサンドボックス（AWS Lambda MicroVMs のようなもの）の需要が増える
そのため、機械が操作しやすい API と、安全な既定値と、予算の上限 が、FaaS の競争力を左右するようになると考えます。
予想4：Durable Execution が当たり前になる
「途中で止まっても続きから再開できる」仕組みは、AI エージェントのワークフローに欠かせません。関数を書くと、途中経過の保存が自動でついてくる のが標準になると予想します。
予想5：WebAssembly が「第3の隔離技術」として広がる
起動が速く、言語を問わず、隔離も強い WebAssembly は、isolate と microVM の間を埋める技術 として広がると考えます。特に、エッジや、AI が生成したコードの実行で使われる場面が増えそうです。
予想6：エッジとリージョンの使い分けが自動になる
利用者の近くで動かすべき処理（認証やキャッシュ）はエッジで、データの近くで動かすべき処理（DB を使う処理）はリージョンで。どこで動かすかを、基盤が自動で判断する ようになると予想します。
予想7：国内・ソブリンの FaaS の需要が高まる
#2 で調べたとき、国産のクラウドで汎用の FaaS を一般に提供しているところは見つかりませんでした。一方で、データを国内で完結させたい、円建てで契約したいというニーズは確実にあります。さくら AppRun のような Knative ベースの基盤の上に、FaaS 的な体験を載せる 動きが出てくることを期待しています。
予想のまとめ
| # | 予想 | 根拠となった変化 |
|---|---|---|
| 1 | FaaS とサーバーレスコンテナの区別がなくなる | Google Cloud Run functions、AWS Lambda Web Functions |
| 2 | CPU 時間課金が標準になる | Cloudflare Workers、AWS Lambda Web Functions |
| 3 | 最大の利用者は AI エージェントになる | AWS Lambda MicroVMs、AI エージェントの普及 |
| 4 | Durable Execution が当たり前になる | AWS Lambda Durable Functions、Azure Functions の Durable Functions |
| 5 | WebAssembly が広がる | エッジ実行基盤での採用 |
| 6 | エッジとリージョンの使い分けが自動になる | Cloudflare Workers、各社のエッジ実行 |
| 7 | 国内・ソブリンの FaaS の需要が高まる | さくら AppRun、データ主権への関心 |
シリーズのまとめ
全7回で、AWS Lambda を基準に、Google Cloud、Microsoft Azure、Cloudflare、さくらインターネットの FaaS とコンテナ実行基盤を比べてきました。
| 回 | テーマ | わかったこと |
|---|---|---|
| #1 | AWS Lambda を整理する | AWS Lambda は5つの形態に分かれ、「どの AWS Lambda を使うか」から設計する時代になった |
| #2 | 主要クラウドの FaaS の比較 | コールドスタート、時間の制限、閉域網、同時処理数で各社の性格が分かれる |
| #3 | 運用編 | ローカルとの差、EOL、ロールバックのしやすさに大きな差がある |
| #4 | マルチコンカレンシー | 同時処理数を上げるだけで、コストが数分の1になることがある |
| #5 | FaaS VS コンテナ実行基盤 | 比べるべきは「何に課金されるか」と「稼働率」 |
| #6 | FaaS とは何だったのか | FaaS とコンテナは同じ場所に集まりつつある。定義は「管理・課金・起動の単位」で考える |
| #7 | もし自分が設計するなら | 待ち時間に課金しない、安全な既定値、AI エージェントが使いやすいことが鍵 |
サーバーを意識せずにコードを動かす という FaaS の考え方は、形を変えながら、これからのクラウドの標準になっていくはずです。この12年で AWS Lambda が切り開いた道は、「関数」という形を超えて、より広い場所につながっています。
最後まで読んでいただき、ありがとうございました。
参考
- AWS Lambda turns ten: The first decade of serverless innovation（AWS News Blog）
- Scaling Lambda Web Functions（AWS）
- AWS Lambda introduces MicroVMs（AWS News Blog）
- AWS Lambda announces new tenant isolation mode（AWS）
- Lambda in 2026: Durable Functions and Managed Instances Explained（AWS Builder Center）
- Workers のローカル開発（Cloudflare）
- Cloudflare Workers Pricing
- Cloud Run functions のランタイム（Google Cloud）
- Concurrency in Azure Functions（Microsoft Learn）
- CNCF Serverless Whitepaper（CNCF Serverless WG）
- AppRun 正式サービス提供開始のお知らせ（さくらインターネット）