WebAssemblyをサーバーレスで動かす｜AWS Lambdaの手順と主要3基盤の上限・事前コンパイルの実測

WebAssembly（Wasm）をサーバーレスで使うと、リクエストのたびに起動する短い処理を、言語に依存しないサンドボックスで実行できます。ただし載せられるかどうかは「Wasmだから速い」では決まりません。各基盤が公開している CPU 時間・メモリ・パッケージの上限と、WASI の実装範囲で決まります。この記事では Cloudflare Workers・Fastly Compute・AWS Lambda の上限を並べたうえで、Wasm の管理ランタイムが無い Lambda に Rust 製の Wasm を載せる手順を示し、事前コンパイルで起動時間がどこまで縮むかを実測します。数値は2026年10月11日時点です。ブラウザ側の Wasm と JavaScript の連携はWebAssembly(Wasm)とは？JavaScript連携とMemory・Table操作の実装で扱っています。

まとめ

• Wasm が向くのは、新しい実行環境の立ち上げが頻繁に起きる基盤での短命処理（ヘッダー加工・認証トークン検証・データ変換・ユーザーコードの隔離実行）です。常駐サーバーの置き換えには向きません。
• 上限は基盤ごとに桁が違います。CPU 時間は Cloudflare Workers の Free が 10ms、Fastly Compute が 50ms、Lambda はタイムアウトの 900 秒までです。Workers のサイズ上限は Free・Paid とも非圧縮 64MiB に統一され、圧縮後の上限はなくなりました。
• AWS Lambda には Wasm の管理ランタイムがありません。provided.al2023 に wasmtime を同梱し、bootstrap から Wasm を呼びます。
• Lambda で起動時間を縮めるのは事前コンパイルです。手元の計測では、Go の hello world は毎回コンパイルすると 1,129ms、.cwasm と wasmtime-min を使うと 35ms でした。zip も wasmtime 本体（70.5MB）を同梱した場合の約 17MB から、1.2MB まで縮みます。
• WASI 0.3 は批准を経て 2026-06-11 に公開されましたが、Fastly の Rust ビルドは wasm32-wasip1 固定、Workers の WASI は experimental、Go 1.27 も wasip1 だけです。本番は Preview 1 前提で書きます。

サーバーレスでWebAssemblyが向く処理と向かない処理

サーバーレス基盤は、リクエストに合わせて実行環境を用意します。Fastly はCompute resource limitsで CPU 時間も実行時間も「single request instance」単位で定めており、リクエストごとに作り直します。Lambda は前回の実行環境が空いていれば再利用し、Workers は1つの isolate で複数のリクエストを処理します。どの基盤でも新しい環境を立ち上げる費用はそのまま遅延になるため、OS もコンテナイメージも持たず、ランタイムがサンドボックスへ読み込むだけで動く Wasm が選ばれます。

速くなるのは起動であって計算ではありません。向くのは、1リクエストの実処理が数ミリ秒で終わる処理です。

• リクエストヘッダーの書き換え、A/B テストの振り分け、リダイレクト判定
• JWT などの認証トークン検証
• 画像形式の変換や JSON の整形といった前処理
• 利用者が書いたコードやプラグインを、ファイルやネットワークに触れさせずに実行する処理

外部 API の応答を数秒待つ処理や、数百MBのデータをメモリへ展開する処理では、起動時間の差はほとんど効きません。CPU 時間で上限を切る基盤（Workers・Fastly）では、重い計算は Wasm にしても同じように上限に当たります。サーバーレス構成そのものの選び方はサーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説に譲ります。

主要3基盤の上限値｜Cloudflare Workers・Fastly Compute・AWS Lambda

各社の公式ドキュメントに載っている上限を並べます（2026年10月11日に確認）。

3基盤へ移植できる設計にすると、最も厳しい上限（CPU なら Workers Free の 10ms、メモリなら 128MB）が全体の天井になります。

Cloudflare Workers｜128MBのisolateと64MiBのWorkerサイズ

Workers のWebAssembly のドキュメントは、Wasm を WebAssembly.instantiate() 経由で呼ぶ方法と、Rust で Worker 全体を書く方法を示しています。どちらも Wasm は JavaScript の isolate の中で動きます。同じページには「Threading is not possible in Workers」とあり、WASI は「experimental on Cloudflare Workers, with only some syscalls implemented」です。

limits ページによると、メモリは isolate あたり 128MB で、JavaScript のヒープと Wasm の割り当てがこの枠を共有します。以前あった圧縮後 3MB（Free）・10MB（Paid）の上限はなくなり、現在は「There is no compressed size limit. Only the uncompressed bundle size counts.」として非圧縮 64MiB だけが残っています。代わりに制約になるのは起動時間の上限 1 秒で、同じページには大きなバンドルは起動時間に響くという注記があります。プラットフォームの全体像はCloudflare Workersとは？対応言語・無料枠・使い方・料金を最新版で総まとめ、Lambda@Edge や Akamai との比較はCloudflare Workersのエッジ実行を比較｜Lambda@Edge・Fastly・Akamaiとの違いとできることにあります。

Fastly Compute｜CPU時間50msとwasm32-wasip1固定

Fastly Compute は Wasm をそのまま実行単位にする基盤で、上限は1実行あたり CPU 時間 50ms、ヒープ 128MB、スタック 1MB、実行時間 2 分（トライアルは 60 秒）、バックエンドへのリクエスト 32 本（トライアルは 10 本）です。設計で先に当たるのは 2 分ではなく 50ms のほうで、移すなら「待ちが長く計算が軽い」処理から始めます。

ビルドターゲットは固定されています。Rust 向けガイドは、2025-03-25 公開の Fastly CLI 11.0.0 以降「the CLI only supports the wasm32-wasip1 compilation target for Rust services in Compute」と書いています。

AWS Lambda｜Wasm管理ランタイムが無くprovided.al2023で動かす

Lambda のランタイム一覧には、nodejs24.x・python3.14・java25・dotnet10・ruby4.0 と OS-only ランタイムの provided.al2023 が並び、Wasm の識別子はありません（nodejs26.x と python3.15 は public preview）。同じページは Go や Rust について「use an OS-only runtime」と案内しており、Wasm も同じ扱いになります。旧来の provided.al2 は 2026-07-31 に非推奨になり、関数の新規作成は 2027-07-29、更新は 2027-08-31 からできなくなります。2023年以前の「Lambda で Wasm」記事の手順は provided.al2023 に読み替えて使います。AL2 からの移行で詰まりやすい箇所はAmazon Linux 2のサポート終了後の移行手順｜AL2023へ移す棚卸しと詰まる箇所にまとめています。

制約になる上限は、クォータのページにある「レイヤーとカスタムランタイムを含めた展開後 250MB」です。wasmtime の Linux 版は本体だけで 70.5MB（49.0.2 の aarch64 版）あるため、同梱の仕方でパッケージの大きさが大きく変わります。Lambda の仕組みと料金はAWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説を参照してください。

AWS LambdaでWebAssemblyを動かす手順

bootstrap（シェルスクリプト）が Lambda Runtime API からイベントを受け取り、標準入力で Wasm に渡し、標準出力をレスポンスとして返す構成です。Rust 1.98.0・wasmtime 49.0.2・arm64 を前提に macOS 上で各手順を実行し、bootstrap は Runtime API を模したローカルサーバーで動作を確かめました（Lambda への実デプロイは行っていませんが、arm64 の provided.al2023 ベースイメージと Runtime Interface Emulator で同じ zip の中身が応答を返すことを確認しました）。

Rustでwasm32-wasip1のモジュールをビルドする

イベントの JSON を標準入力で読み、環境変数 STAGE と合わせて JSON を返すだけのハンドラーです。WASI では、ホストが明示的に渡した環境変数しか Wasm 側から見えません。

use std::io::{self, Read};

fn main() {
    // Lambdaのイベント(JSON)を標準入力で受け取る
    let mut event = String::new();
    io::stdin().read_to_string(&mut event).unwrap();
    // ホストが --env で渡した値だけが見える
    let stage = std::env::var("STAGE").unwrap_or_else(|_| "unset".into());
    // 標準出力がそのままレスポンスになる
    println!("{{\"bytes\":{},\"stage\":\"{}\"}}", event.len(), stage);
}

cargo new handler で作ったプロジェクトの src/main.rs を上のコードに置き換え、Cargo.toml にはサイズ優先の設定を足します。

[profile.release]
opt-level = "z"
lto = true
strip = true
panic = "abort"
codegen-units = 1

ビルドしてローカルの wasmtime で動かします。

$ rustup target add wasm32-wasip1
$ cargo build --release --target wasm32-wasip1
$ ls -l target/wasm32-wasip1/release/handler.wasm
-rwxr-xr-x  1 user  wheel  55677 Oct 11 23:30 target/wasm32-wasip1/release/handler.wasm

$ echo '{"a":1}' | wasmtime run --env STAGE=dev target/wasm32-wasip1/release/handler.wasm
{"bytes":8,"stage":"dev"}

生成物は 55,677 バイトでした。Fastly と揃えるなら wasm32-wasip1 を選びます。wasm32-wasip2 でもビルドはでき、hello world で比べると wasip1 が 40,097 バイト、wasip2 が 54,707 バイトでした。Rust で Wasm を書くこと自体の手順はRustでWebAssemblyを実装する手順｜wasm-packでのWASM化と軽量化・配置先の選び方【2026年版】で詳しく扱っています。

bootstrapでRuntime APIとWasmをつなぐ

カスタムランタイムの入口は、パッケージ直下の実行可能ファイル bootstrap です。Runtime API のドキュメントは、/next で受け取った Lambda-Runtime-Invocation-Id をレスポンスで返すよう求めており、ヘッダーを付けたうえで値が合わないときは「400 InvalidInvocationId」で拒否します。ヘッダー自体は既存ランタイムとの互換のため省略でき、省略しても拒否はされません。1つのリクエスト ID に対して実行が複数回起きることがあるため、新しく書く bootstrap では付けておきます。

#!/bin/bash
set -uo pipefail
API="http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation"
cd "$LAMBDA_TASK_ROOT"

while true; do
  # 次のイベントを待つ（GETにはタイムアウトを付けない）
  curl -sS -D /tmp/h.txt -o /tmp/event.json "$API/next" || exit 1

  REQUEST_ID=""; INVOCATION_ID=""
  while IFS= read -r line; do
    line="${line%$'\r'}"
    case "${line,,}" in
      lambda-runtime-aws-request-id:*) REQUEST_ID="${line#*: }" ;;
      lambda-runtime-invocation-id:*)  INVOCATION_ID="${line#*: }" ;;
    esac
  done < /tmp/h.txt

  # 事前コンパイル済みの .cwasm を wasmtime-min で実行する
  if ./wasmtime-min run --allow-precompiled --env STAGE handler.cwasm \
       < /tmp/event.json > /tmp/out.json 2> /tmp/err.txt; then
    RESULT=response
  else
    printf '{"errorMessage":"wasm exited with error","errorType":"WasmError"}' > /tmp/out.json
    RESULT=error
  fi

  # /next で受け取った Invocation-Id を返す（付けた値が食い違うと 400 InvalidInvocationId）
  curl -sS -X POST --data-binary @/tmp/out.json \
    ${INVOCATION_ID:+-H "Lambda-Runtime-Invocation-Id: $INVOCATION_ID"} \
    "$API/$REQUEST_ID/$RESULT" > /dev/null
done

AWS 公式チュートリアルも、provided.al2023 上のシェルスクリプトの bootstrap から curl を呼んでいます。DevelopersIO の検証記事（2026-07-31）は「curl は同梱されていません」として静的リンク版を同梱していますが、2026-10-11 に取得した arm64 の provided.al2023 ベースイメージには curl 8.21.0 と bash 5.2.15 が入っていました。模擬 Runtime API では、正常時は /response、Wasm が異常終了したときは /error に、Invocation-Id 付きで送られることを確認しました。

arm64向けに事前コンパイルしてzipにまとめる

wasmtime は別のアーキテクチャ向けの機械語も出力できます。wasmtime-min は 49.0.2 の配布物に入っている実行専用の小さなバイナリで、コンパイラを持たないため .cwasm しか実行できません。

# arm64(Graviton)向けに事前コンパイル。wasmtime-min で読める設定にする
$ wasmtime compile --target aarch64-unknown-linux-gnu -W threads=n,gc-support=n \
    target/wasm32-wasip1/release/handler.wasm -o handler.cwasm

# 49.0.2 の aarch64-linux 配布物から wasmtime-min だけを取り出す
$ curl -LO https://github.com/bytecodealliance/wasmtime/releases/download/v49.0.2/wasmtime-v49.0.2-aarch64-linux.tar.xz
$ tar xf wasmtime-v49.0.2-aarch64-linux.tar.xz
$ cp wasmtime-v49.0.2-aarch64-linux/wasmtime-min .

$ chmod +x bootstrap wasmtime-min
$ zip -9 function.zip bootstrap wasmtime-min handler.cwasm
$ ls -l function.zip
-rw-r--r--  1 user  wheel  1200526 Oct 11 23:36 function.zip

-W threads=n,gc-support=n を外して作った .cwasm は、wasmtime-min でmodule was compiled for the copying collector but the host is configured to use the deferred reference-counting collector と出て読み込めませんでした。threads だけ残した場合もModule was compiled with support for WebAssembly feature threads but it is not enabled for the host（実際のメッセージでは threads がバッククォートで囲まれます）で止まります。.cwasm は作った wasmtime の版・対象アーキテクチャ・機能設定と組で使うものと考えてください。

あとは関数を作るだけです。arm64 を指定し、ハンドラー名は任意の文字列で構いません（bootstrap が読まれるため）。

$ aws lambda create-function --function-name wasm-handler \
    --runtime provided.al2023 --architectures arm64 \
    --handler handler --zip-file fileb://function.zip \
    --memory-size 256 --timeout 10 \
    --environment '{"Variables":{"STAGE":"prod"}}' \
    --role arn:aws:iam::123456789012:role/lambda-role

事前コンパイルで起動時間を削る｜実行時コンパイル（JIT）と.cwasmの実測

先の DevelopersIO の検証は、Rust 製の 95KB の Wasm を wasmtime 本体で毎回 wasmtime run し、Init Duration 73.94ms・初回の Duration 2,243.71ms・2回目以降の平均 約130ms という結果でした。記事は改善策として「事前コンパイル（wasmtime compile による .cwasm の同梱）」を挙げていますが、その数字は出していません。そこで、同じ実行方法の違いを手元で測りました。

計測は Intel Core i9-9880H の macOS で、どれも hello world を 15 回起動したプロセス時間の中央値です。毎回コンパイルする方式は、モジュールが大きいほど遅くなります。Go では起動の 9 割以上がコンパイルでした。.cwasm にするとモジュールの大きさにほとんど左右されなくなり、wasmtime-min は本体より起動が軽くなります。

キャッシュにも注意が要ります。wasmtime の CLI はコンパイル結果をキャッシュし（macOS では ~/Library/Caches/BytecodeAlliance.wasmtime に書き込まれました）、Go の例では 2 回目以降が 100ms 台（計測の回により 107〜135ms）に下がりました。Lambda で書き込めるのは /tmp だけで、そこに置いたキャッシュは同じ実行環境が使い回される間しか残りません。初回だけが遅く 2 回目以降が速いという DevelopersIO の結果はこの挙動と整合しますが、毎回のコールドスタートで払う費用には変わりありません。さらに Lambda の CPU はメモリに比例して割り当てられ、1 vCPU 相当になるのは 1,769MB からです。256MB の関数ではコンパイルは手元より遅くなります。

パッケージも縮みます。bootstrap（1,162 バイト）・arm64 向けの wasmtime-min（3,473,280 バイト）・handler.cwasm（344,136 バイト）を zip -9 でまとめると 1,200,526 バイトでした。DevelopersIO の構成は wasmtime 本体と curl を同梱して約 21MB です。250MB の上限には余裕があっても、デプロイと初期化で扱うファイルは小さいほうが有利です。

言語ごとのwasmサイズとWASI対応｜Go・TinyGo・Rust

「Wasm は小さい」は、言語ランタイムを持たない場合の話です。標準出力に 1 行書くだけのプログラムを wasip1 向けにビルドすると、次のようになりました。

計測時の版です。執筆時点の最新は Rust 1.99.0（2026-10-01）と TinyGo 0.43.0（2026-10-09）です。

Go は GC とランタイムを丸ごと抱えるため、hello world でも 2.5MB 近くになります。Workers の上限が 64MiB になりサイズでは弾かれにくくなりましたが、前節のとおり実行時コンパイルの費用はモジュールが大きいほど増え（40KB で 78ms、2.48MB で 1,129ms）、Go は 1 秒を超えます。小さく保つなら Rust か TinyGo を選び、TinyGo を使うときは -no-debug を付けます。TinyGo の導入と制約はTinyGoとは？通常のGoとの違い・インストール・Lチカ・WebAssemblyを0.42.0で実測にあります。

WASI の版にも差があります。2026-08-19 公開の Go 1.27 でも GOOS=wasip2 は「unsupported GOOS/GOARCH pair wasip2/wasm」でビルドできません。Rust は wasm32-wasip2 を出せますが、Fastly CLI は Rust では wasm32-wasip1 しかサポートしていません。

2026年10月時点の仕様と実装の差｜WASI 0.3・Wasmtime・Docker Desktop

WASI 0.3は批准済み、実行基盤はPreview 1が中心

WASI 0.3.0 は WASI Subgroup の批准投票を経て 2026-06-11 に公開され、非同期処理が Component Model の future<T> や stream<u8> で書けるようになりました。0.3.1 は 2026-08-11 に公開され、WIT に implements と map<K, V> が加わっています。WASI のリリース一覧では 2026-10-11 時点の最新が 0.3.1 です。仕様の詳細はWASIとは｜WebAssemblyをブラウザ外で動かすシステムインターフェース【2026年版】にあります。

マネージドの2基盤は 0.3 を受け付ける段階にありません。Fastly は wasm32-wasip1、Workers の WASI は experimental です。Lambda は同梱したランタイム次第ですが、Go のように処理系側が wasip1 しか出せない場合もあります。フレームワーク側は先に進んでおり、Spin（最新は 2026-10-06 の v4.2.2）は Rust テンプレートが 0.3 を出力します。Spin の使い方と Fermyon Cloud の現状はFermyon Cloudとは？Spin 4.2での使い方・料金とAkamai買収後の現状【2026年10月】を参照してください。wasmCloud は 2026-10-02 に v2.10.3 を公開しています。

Wasmtimeの月次リリースとLTS｜24系は2026年8月で終了

Lambda で wasmtime を同梱するなら、その版の保守も自分の仕事です。Wasmtime のリリース方針は、毎月20日にメジャー版を出し、「Each release that is a multiple of 12 is considered an LTS release and is supported for 24 months. Other releases are supported for 2 months.」と定めています。セキュリティ修正はサポート中の全版へ戻される一方、通常のバグ修正は「volunteer basis」です。

実際のリリースもこの通りに動いています。2024-08-20 公開の 24 系は 2026-08-20 の 24.0.13 が最後でした。2026-08-20 には次の LTS の 48.0.0 が出ており、2026-10-02 には 49.0.2・48.0.5・36.0.17 が同じ日に公開されています。毎月の更新に追随できないなら、最初から 48 系に固定します。この記事の手順は 49.0.2 で検証しており、48 系で組むなら配布物を 48.0.5 に替え、.cwasm も 48 系の wasmtime で作り直してください。

Docker DesktopのWasmワークロードは廃止予定

2023年前後に多く出た「Docker Desktop で Wasm を動かす」解説は前提が崩れています。Docker の公式ドキュメントは現在、「Wasm workloads are deprecated and will be removed in a future Docker Desktop release. This feature is no longer actively maintained.」と書いています。

サーバーレスWebAssemblyを採用すべきでない場面

次のどれかに当てはまるなら、通常のサーバーレス関数やコンテナのままのほうが総費用は下がります。

• Node.js や Python の既存資産をそのまま載せたい。Wasm 向けの言語へ書き直す費用が、起動時間の短縮分を上回ります。
• 1リクエストの計算が重い。Workers Free の 10ms や Fastly の 50ms を超える処理は、Wasm にしても同じ上限に当たります。
• ファイルシステムやソケットに依存する。WASI の実装範囲が基盤ごとに違い、Workers では一部の syscall しか動きません。
• スレッド並列が前提。Workers はスレッドを使えず、wasmtime も 47.0.0 で wasi-threads のサポートを削除しました。
• Lambda で使い、wasmtime の更新を追う体制がない。ランタイムの同梱・事前コンパイル・LTS への追随をすべて自分で抱えます。Rust で書くなら、Wasm にせず provided.al2023 向けのネイティブバイナリにするほうが単純です。

反対に、起動が頻繁で処理が軽く、隔離が要件になる処理（エッジでのリクエスト加工、マルチテナントでのユーザーコード実行、プラグイン機構）なら、Wasm を選ぶ理由を上限値で説明できます。どの基盤に載せるかを含めて AWS 上の構成を相談したい場合は、AWS・Google Cloud・Azure のインフラ構築支援で承っています。

よくある質問

WebAssemblyはサーバーレスで何ができるのですか？

リクエストごとに短時間で起動するサンドボックス実行です。ヘッダー書き換えや振り分け、認証トークンの検証、データ変換、ユーザーが書いたコードの隔離実行が該当します。CPU を長く使う処理やファイルシステムに依存する処理は、基盤の上限と WASI の実装範囲に制約されます。

AWS LambdaでWebAssemblyは動かせますか？

動かせますが、管理ランタイムはありません。provided.al2023 のパッケージに wasmtime などのランタイムを同梱し、bootstrap から Wasm を呼びます。毎回コンパイルすると起動が遅くなるため、wasmtime compile --target aarch64-unknown-linux-gnu -W threads=n,gc-support=n で事前コンパイルした .cwasm を wasmtime-min で実行する構成にします。

Cloudflare WorkersでWASIは使えますか？

公式ドキュメントは「WASI support is experimental on Cloudflare Workers, with only some syscalls implemented」としており、実験的なサポートです。スレッドも使えません。ローカルの wasmtime で動いたモジュールがそのまま Workers で動く前提では設計できません。

WebAssemblyの将来性はどう判断すればよいですか？

仕様は進んでおり、批准を経た WASI 0.3.0 が 2026-06-11 に、0.3.1 が 2026-08-11 に公開されました。一方で実行基盤は Preview 1 が中心で、Docker Desktop の Wasm 機能は廃止予定です。ブラウザ外の Wasm は何でも置き換える方向ではなく、エッジとサーバーレスの短い処理や隔離実行に用途が絞られつつあると見るのが実態に近い判断です。

Webサーバーはサーバーレスに置き換えられますか？

リクエスト単位で完結する処理は置き換えられます。実行環境がいつ再利用・破棄されるかを関数側では制御できないため、WebSocket の長時間接続、プロセス内キャッシュの共有、ローカルファイルへの書き込みといった常駐前提の設計は、そのままでは移せません。

関連記事

• WebAssembly(Wasm)とは？JavaScript連携とMemory・Table操作の実装
• WASIとは｜WebAssemblyをブラウザ外で動かすシステムインターフェース【2026年版】
• AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説
• Cloudflare Workersのエッジ実行を比較｜Lambda@Edge・Fastly・Akamaiとの違いとできること
• サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説