--- title: "WebAssemblyをサーバーレスで動かす｜AWS Lambdaの手順と主要3基盤の上限・事前コンパイルの実測" url: "https://www.issoh.co.jp/tech/details/1890/" published: 2024-01-29 updated: 2026-10-12 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # 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操作の実装](/tech/details/4250/)で扱っています。 ## まとめ - 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](https://docs.fastly.com/products/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実装・採用判断を実装者目線で解説](/tech/details/13125/)に譲ります。 ## 主要3基盤の上限値｜Cloudflare Workers・Fastly Compute・AWS Lambda 各社の公式ドキュメントに載っている上限を並べます（2026年10月11日に確認）。 | 項目 | Cloudflare Workers | Fastly Compute | AWS Lambda | | ---------- | ----------------------------- | ------------------ | -------------------- | | Wasm の実行方法 | JS API 経由 | Wasm がそのまま実行単位 | ランタイムを自前で同梱 | | CPU 時間 | 10ms(Free) / 既定30秒・最大5分(Paid) | 50ms | 上限なし（タイムアウトで制御） | | メモリ | 128MB / isolate | ヒープ128MB + スタック1MB | 128MB〜10,240MB | | 実行時間 | HTTP は上限なし / Cron 15分 | 2分（トライアル60秒） | 900秒 | | サイズ上限 | 非圧縮 64MiB（両プラン） | 100MB / サービス | zip 50MB / 展開後 250MB | | WASI | experimental | wasm32-wasip1 | 同梱ランタイム次第 | 3基盤へ移植できる設計にすると、最も厳しい上限（CPU なら Workers Free の 10ms、メモリなら 128MB）が全体の天井になります。 ### Cloudflare Workers｜128MBのisolateと64MiBのWorkerサイズ Workers の[WebAssembly のドキュメント](https://developers.cloudflare.com/workers/runtime-apis/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 ページ](https://developers.cloudflare.com/workers/platform/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とは？対応言語・無料枠・使い方・料金を最新版で総まとめ](/tech/details/6760/)、Lambda@Edge や Akamai との比較は[Cloudflare Workersのエッジ実行を比較｜Lambda@Edge・Fastly・Akamaiとの違いとできること](/tech/details/6539/)にあります。 ### Fastly Compute｜CPU時間50msとwasm32-wasip1固定 Fastly Compute は Wasm をそのまま実行単位にする基盤で、上限は1実行あたり CPU 時間 50ms、ヒープ 128MB、スタック 1MB、実行時間 2 分（トライアルは 60 秒）、バックエンドへのリクエスト 32 本（トライアルは 10 本）です。設計で先に当たるのは 2 分ではなく 50ms のほうで、移すなら「待ちが長く計算が軽い」処理から始めます。 ビルドターゲットは固定されています。[Rust 向けガイド](https://www.fastly.com/documentation/guides/compute/developer-guides/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 の[ランタイム一覧](https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html)には、`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へ移す棚卸しと詰まる箇所](/tech/details/18024/)にまとめています。 制約になる上限は、[クォータのページ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html)にある「レイヤーとカスタムランタイムを含めた展開後 250MB」です。wasmtime の Linux 版は本体だけで 70.5MB（49.0.2 の aarch64 版）あるため、同梱の仕方でパッケージの大きさが大きく変わります。Lambda の仕組みと料金は[AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](/tech/details/15407/)を参照してください。 ## 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年版】](/tech/details/15290/)で詳しく扱っています。 ### bootstrapでRuntime APIとWasmをつなぐ カスタムランタイムの入口は、パッケージ直下の実行可能ファイル `bootstrap` です。[Runtime API のドキュメント](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-api.html)は、`/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 公式チュートリアル](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-walkthrough.html)も、`provided.al2023` 上のシェルスクリプトの bootstrap から curl を呼んでいます。[DevelopersIO の検証記事（2026-07-31）](https://dev.classmethod.jp/articles/20260731-lambda-wasm/)は「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 の同梱）」を挙げていますが、その数字は出していません。そこで、同じ実行方法の違いを手元で測りました。 | 実行方法 | Go（2.48MB） | Rust（40KB） | | ------------------------- | ---------- | ---------- | | wasmtime run（キャッシュ無効） | 1,129.1ms | 78.3ms | | wasmtime run + .cwasm | 44.8ms | 40.0ms | | wasmtime-min run + .cwasm | 35.3ms | 19.2ms | 計測は 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` 向けにビルドすると、次のようになりました。 | 処理系 | サイズ | gzip -9 後 | | ------------------------------- | ------------- | ----------- | | Go 1.27.2 | 2,479,946 バイト | 716,720 バイト | | TinyGo 0.42.0（既定） | 464,311 バイト | – | | TinyGo 0.42.0（-no-debug -opt=z） | 98,020 バイト | 38,595 バイト | | Rust 1.98.0（`opt-level="z"`） | 40,097 バイト | 16,353 バイト | 計測時の版です。執筆時点の最新は 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で実測](/tech/details/10217/)にあります。 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` や `stream` で書けるようになりました。0.3.1 は 2026-08-11 に公開され、WIT に `implements` と `map` が加わっています。[WASI のリリース一覧](https://github.com/WebAssembly/WASI/releases)では 2026-10-11 時点の最新が 0.3.1 です。仕様の詳細は[WASIとは｜WebAssemblyをブラウザ外で動かすシステムインターフェース【2026年版】](/tech/details/13251/)にあります。 マネージドの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月】](/tech/details/7295/)を参照してください。wasmCloud は 2026-10-02 に v2.10.3 を公開しています。 ### Wasmtimeの月次リリースとLTS｜24系は2026年8月で終了 Lambda で wasmtime を同梱するなら、その版の保守も自分の仕事です。[Wasmtime のリリース方針](https://docs.wasmtime.dev/stability-release.html)は、毎月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 の公式ドキュメント](https://docs.docker.com/desktop/features/wasm/)は現在、「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 のインフラ構築支援](/service/system/aws/)で承っています。 ## よくある質問 ### 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操作の実装](/tech/details/4250/) - [WASIとは｜WebAssemblyをブラウザ外で動かすシステムインターフェース【2026年版】](/tech/details/13251/) - [AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](/tech/details/15407/) - [Cloudflare Workersのエッジ実行を比較｜Lambda@Edge・Fastly・Akamaiとの違いとできること](/tech/details/6539/) - [サーバーレスアーキテクチャとは？構成パターン・AWS実装・採用判断を実装者目線で解説](/tech/details/13125/) --- 出典: [WebAssemblyをサーバーレスで動かす｜AWS Lambdaの手順と主要3基盤の上限・事前コンパイルの実測]()（株式会社一創）