---
title: WASMはどこから来たのか WASMは何者か WASMはどこへ行くのか
tags: 
author: [nuskey](https://docswell.com/user/nuskey)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/Y76WD9PM7V.jpg?width=480
description: Kanto Tech Circle Meetup登壇資料です。
published: July 11, 26
canonical: https://docswell.com/s/nuskey/5R899R-the-present-and-future-of-wasm
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/Y76WD9PM7V.jpg)

WASMはどこから来たのか
WASMは何者か
WASMはどこへ行くのか
> The Present and Future of WebAssembly
2026/07/11 @住友不動産 六本木グランドタワー/SUMITOMO
KANTO Tech Circle Meetup
#KTC_meetup
1


# Page. 2

![Page Image](https://bcdn.docswell.com/page/G75M3NKQ74.jpg)

- @nuskey8
- OSSをメインに開発やってます
- 個人で累計⭐9.0kスター超えました、やった〜
- この間はWebAssembly 3.0ランタイムを作りました
- 時々ゲーム作ったりVJしたりもします
#KTC_meetup
#
#
自己紹介
2


# Page. 3

![Page Image](https://bcdn.docswell.com/page/9J29Z5WWER.jpg)

# WASMはどこから来たのか
#KTC_meetup
3


# Page. 4

![Page Image](https://bcdn.docswell.com/page/DEY4RKL9JM.jpg)

- ブラウザで色々なものが動くようになり、JavaScriptの速度がネックになり始めた
- 高速化のための試みは色々あったが、特に大きなものはNaClとasm.js
- NaCl(Native Client)はChromeにかつて存在したプロジェクト
- ネイティブコードをサンドボックス環境で動作させる機能
- レガシーなプラグインAPIに依存していたため、標準化には至らず
- asm.jsはAOTコンパイルのためのJavaScriptのサブセット
- 高速化はするが、ネイティブコードほどのパフォーマンスには届かない
- 実現手法がかなりhackyで、起動が遅いなどの問題を抱えていた
#KTC_meetup
#
#
[2010年〜] NaCl/asm.jsの時代
4


# Page. 5

![Page Image](https://bcdn.docswell.com/page/VJNYDR4D78.jpg)

- これらのプロジェクトの反省から、Webには新たなバイトコードVMが必要だという認識に
- そして2015年、ついにWebAssemblyという言葉が登場する
- 正式にブラウザに実装され、出荷されたのは2年後の2017年
- こうしてWebAssemblyは誕生した
#KTC_meetup
#
#
そしてWebAssemblyへ
5


# Page. 6

![Page Image](https://bcdn.docswell.com/page/YE9PGMQ8J3.jpg)

# WASMは何者か
#KTC_meetup
6


# Page. 7

![Page Image](https://bcdn.docswell.com/page/GE8DVLGZED.jpg)

- スタックマシンベースの低レベルなバイトコード形式
- 機械語と比較するとかなり高級、普通にifとかある
(逆にjumpなどはない)
- 多くの言語がコンパイル先としてサポートしている
- ミニマルな1.0コア仕様と多くのProposalsから構成される
- ランタイムがどこまでサポートするかは自由
- 正直Web要素はあまりない
- 単体ではDOMアクセスもできないしWeb APIも呼べない
#KTC_meetup
#
#
改めてWebAssemblyとは
7


# Page. 8

![Page Image](https://bcdn.docswell.com/page/LELM5LG17R.jpg)

- 静的型付けかつバイトコードなのでJSより高速
- と言いたいところだが、JITが未発達なのでJSのが速いケースも多い
- バイナリ操作などの低レベルな処理に向いている
- セキュアであることが重視されている
- 静的型付けで型安全、実行せずともValidationが可能
- 与えられた線型メモリ以外へアクセスができない
- 明示的にホストから与えられた関数以外を呼べない
- JSの弱点を補いつつ、多言語にも対応した次世代のブラウザ言語
#KTC_meetup
#
#
Efficient, Fast, Safe
8


# Page. 9

![Page Image](https://bcdn.docswell.com/page/4JMY3MQ5JW.jpg)

# WASMはどこへ行くのか
#KTC_meetup
9


# Page. 10

![Page Image](https://bcdn.docswell.com/page/PJR9QV8Z79.jpg)

- 前述の通り、WASMにWeb要素はほとんどない
- 仕様が小さいため、ブラウザ外で動くランタイム実装もたくさんある
- (e.g. wasmtime、Wasmer、wasmi、etc.)
- ポータビリティが高い&サンドボックスな実行可能バイナリとして活用できる
#KTC_meetup
#
#
Webを越えたWebAssemblyの活用
10


# Page. 11

![Page Image](https://bcdn.docswell.com/page/PEXQ5Z81JX.jpg)

- 現在のコンテナ技術は毎回環境を建て直すため
起動時のオーバーヘッドが大きい
- wasmバイナリを用いてオーバーヘッドの少ない
セキュアな実行環境を実現する
- ユーザーランドを含まないため、コンテナよりセキュアで軽量
- 実際にCloudflare Workers、Fastlyなどの
エッジコンピューティング環境で活用されている
#KTC_meetup
#
#
コンテナ技術のその先へ
11


# Page. 12

![Page Image](https://bcdn.docswell.com/page/3EK968KMED.jpg)

- 実際にクライアントサイドでのエコシステムが形成され始めている
- システムコール-likeな呼び出し規約を定めるWASI
- 多言語のwasmモジュール間を繋ぐComponent Model提案など
- これらのエコシステムはBytecode Allianceなどの
標準化団体が中心となって進化を続けている
- もっともこれらのコミュニティも一枚岩ではなく、
私としても言いたいことは色々あるが…
#KTC_meetup
#
#
WASIとComponent Model
12


# Page. 13

![Page Image](https://bcdn.docswell.com/page/L73W62Z275.jpg)

# まとめ
#KTC_meetup
13


# Page. 14

![Page Image](https://bcdn.docswell.com/page/87DKVZR6JG.jpg)

- NaClやasm.jsの反省からWebAssemblyは生まれた
- WebAssemblyはJSの弱点を補う新たなブラウザ言語として策定された
- 現在はブラウザだけに留まらず、コンテナ技術の代替としての用途や
エッジコンピューティングで活用されている
#KTC_meetup
#
#
まとめ
14


# Page. 15

![Page Image](https://bcdn.docswell.com/page/VJPKVDMZE8.jpg)

# Thank you for listening!
#KTC_meetup
15