WebAssemblyは仕様であって、実行ファイルではありません。ブラウザの外で .wasm を動かすには、バイナリを読んで機械語に直し、線形メモリ（モジュール専用の作業領域）を確保し、外の世界との窓口を用意する実装が要ります。Wasmtimeはその実装のひとつで、サーバー側でWASMを使うときにまず名前が挙がります。
作っている場所
開発元はBytecode Alliance。WASMとWASIの仕様づくりを進めている非営利団体で、Fastly、Microsoft、Armなどが参加しています。仕様を書く場所と実装する場所が近いぶん、提案が動く形で降りてくるのが早いという特徴があります。
本体はRustで書かれており、毎月リリースされます。2026年8月のリリースがバージョン48です。数字の大きさは機能の断絶を意味するものではなく、月次で刻んでいるためのものです。
コンパイラが二つあります
WASMを機械語に直す部分には、性格の違うものが二つ載っています。
Craneliftは最適化するほうで、レジスタ割り当てや別名解析を持ち、x86-64でもAArch64でもSIMD命令まで使います。長く走らせる処理では、こちらが速くなります。
Winchは最適化をほとんどせず、読んだそばから実行に入ります。1リクエストで終わる短い処理では、最適化に使った時間を回収できないため、起動の速さがそのまま結果に出ます。
どちらを使うかは設定で選べます。両方を持っていること自体が、WASMが「長く走るサーバー」と「一瞬で終わる関数」の両方に使われていることの表れでもあります。
窓口はホストが決めます
モジュールは自分の線形メモリの外へ手が届きません。ファイルを読むにもネットワークに出るにも、ホスト（モジュールを動かす側のプログラム）が関数を渡す必要があります。
これがWASIのcapabilityの実際の姿で、Wasmtimeでは渡す関数を組み立てて実行環境に載せます。何を渡すかを決めるのは呼び出す側のコードのため、権限の設計が設定ファイルではなくプログラムの構造として残ります。渡し忘れたものは、中から呼びようがありません。
WASIの0.2系は安定しており、非同期を扱う0.3系の実装が並行して進んでいます。
埋め込めるということ
Wasmtimeはライブラリとして自分のプロセスに埋め込めます。別のサーバーもデーモンも要りません。プラグイン機構を持ちたいアプリケーションが、誰が書いたか分からない拡張を受け入れるときに向いています。
エッジで利用者のコードを走らせる基盤や、ECの決済ロジックを顧客がカスタマイズする仕組みが、実際にこの形で作られています。どちらも「他人の書いたコードを、自分のサーバーで動かす」という同じ問題を抱えています。
見えにくいところの仕事
サンドボックスを名乗る以上、破られないことを示し続ける必要があります。Wasmtimeは継続的にファジング（不正な入力を大量に投げ込む試験）を回しており、脆弱性が出たときの公開手順も定められています。メモリ境界の検査も、実行時に毎回比較するのではなく仮想メモリのガードページを踏ませる方式で、速度を落とさずに外へ出られないようにしています。
機能一覧には出てこない部分ですが、実行環境を選ぶときに確認する価値があるのはこうした点です。
portaでの使い方
Aid-Onが公開しているportaは、.wasm を渡されたときの実行にWasmtimeを使っています。ネイティブのコマンドはOSのカーネルで閉じ、WASMモジュールはWasmtimeの中で閉じます。入口は porta run のひとつで、中身の閉じ方が二通りある形です。
外部で作られたコードを自社のサーバーで動かす計画がある場合は、その実行環境が何を渡しているかをコードから読み取れるか、脆弱性が出たときの公開手順が示されているかが、選定時の確認点になります。
