---
title: "RustでWebAssemblyを実装する手順｜wasm-packでのWASM化と軽量化・配置先の選び方【2026年版】"
url: "https://www.issoh.co.jp/tech/details/15290/"
published: 2026-07-17
updated: 2026-09-27
categories: ["Rust"]
publisher: "株式会社一創"
---

# RustでWebAssemblyを実装する手順｜wasm-packでのWASM化と軽量化・配置先の選び方【2026年版】

RustをWebAssembly（WASM）へコンパイルすると、ブラウザ上でネイティブに近い速度の処理を動かせます。この記事は「webassembly 入門」で調べた開発者が、Rust製のコードをwasm-packでWASM化し、JavaScriptから呼び出し、さらにブラウザ外まで配置するまでの実装手順を、一次情報のバージョンに沿って追える形でまとめたものです。ツールチェーンの構成（wasm-packとwasm-bindgenの役割分担）、JavaScriptとのデータ受け渡し、バイナリの軽量化、そして「どの環境に置くか」の選び方までを扱います。加えて、Rust×WASMを採用すべき条件と、あえて見送るべき場面の判断基準も示します。

## まとめ：Rust×WebAssembly実装の要点と採用が効く条件・配置先の判断

先に結論を示します。RustをWASM化する標準ルートは、ブラウザ向けなら`wasm-pack build`（内部でwasm-bindgenを呼ぶ）、サーバー向けなら`cargo build --target wasm32-wasip2`の二系統です。ターゲットの選択が実装の分岐点になり、ここを取り違えると後段のJavaScript連携やホスト連携がかみ合いません。

採用が効くのは、画像処理・暗号・パーサ・数値計算のように「JavaScriptでは律速になる計算」をモジュール単位で切り出せる場面です。逆に、DOM操作が主体のUIや、月間数十回しか動かない軽い処理にRustツールチェーンを持ち込むと、ビルドの複雑さとバイナリ増加が見合いません。配置先は、ブラウザ内（wasm32-unknown-unknown）、サーバー・エッジ（WASI）、プラグイン基盤の三択で考えると整理できます。以降で手順・軽量化・判断基準を順に掘り下げます。

## RustがWebAssemblyのコンパイル先に選ばれる理由と適性の範囲

WebAssemblyは、スタックマシン向けのバイナリ命令フォーマットです。C／C++／Rust／Go／MoonBitなど複数の言語がコンパイル先に選べますが、Rustは「ランタイムとGC（ガベージコレクタ）を持たない」ため、生成物にランタイムを同梱せずに済みます。ここが、WASMの持ち味である小さく速いバイナリと相性の良い理由です。

### ランタイム非同梱がバイナリサイズと起動速度の両方に効く仕組み

GCを持つ言語をWASM化すると、多くの場合ランタイムやGCの一部を成果物へ含める必要があり、初期ロードが膨らみます。対してRustは所有権モデルでメモリを静的に管理するため、標準ライブラリを使う小さな関数なら数十KB台のWASMに収まることも珍しくありません。起動の速さが効くのは、エッジ環境のようにインスタンスが頻繁に生成される場所です。1リクエストごとにコールドスタートが走る前提なら、ランタイム同梱の有無がそのまま応答時間に跳ね返ります。

### Rustが向く処理と、言語選択でMoonBitやTinyGoを検討すべき場面

Rustが強いのは、既存のCrate資産（画像デコード、正規表現、暗号、シリアライズ）をそのままWASMへ持ち込める点です。一方で、学習コストや所有権の制約が重いと感じる小規模チームでは、WASMを第一級ターゲットに据えた新言語という選択肢もあります。両者の設計思想の違いは、[MoonBitの特徴とRustとの違いを整理した解説](https://www.issoh.co.jp/tech/details/8968/)が参考になります。判断の目安はこうです。既存Rust資産があるか、細かなメモリ制御が要るなら Rust。ゼロから小さなWASM関数を量産し、バイナリサイズを最小に寄せたいなら新言語系も候補に入れる。目的が「今あるRustライブラリをWebで動かす」なら、迷わずRustです。

## wasm-packでRustをWASM化する実装手順とツールチェーンの構成

ブラウザ向けのRust→WASMは、rustup・wasm-pack・wasm-bindgenの三点で構成します。それぞれの役割を取り違えないことが、最初のつまずきを避ける近道です。

### rustup・wasm-pack・wasm-bindgenの役割分担とインストール手順

各ツールの担当は明確です。rustupがコンパイラとターゲットを用意し、wasm-packがビルドとパッケージングを束ね、wasm-bindgenがRustとJavaScriptの境界コードを生成します。導入は次の順で進めます。

1. rustupでツールチェーンを入れ、ブラウザ向けターゲットを追加する（`rustup target add wasm32-unknown-unknown`）。
2. wasm-packを入れる（`cargo install wasm-pack`／2026年時点は0.15系）。
3. ライブラリ用プロジェクトを作り、`Cargo.toml`で `crate-type = ["cdylib"]` を指定する。
4. 依存に wasm-bindgen（2026年時点は0.2系）を加える。

ここで`cdylib`指定を忘れると、WASM向けの動的ライブラリ形式で出力されず、リンク段階で失敗します。最初に一度だけ設定する項目なので、テンプレート化しておくと反復作業が減ります。

### wasm-pack buildが生成する成果物とターゲット指定の意味

`wasm-pack build --target web`を実行すると、WASM本体・JavaScriptグルーコード・型定義（.d.ts）・package.jsonが`pkg`ディレクトリに出力されます。`--target`は配布先の読み込み方式を決めるフラグです。ブラウザで`<script type="module">`から直接読むなら`web`、バンドラ（webpack／Vite）経由なら`bundler`、Node.jsなら`nodejs`を選ぶ形です。この選択を配布環境と合わせておかないと、生成されたグルーコードの読み込み方式が食い違い、実行時に初期化エラーが出ます。開発初期はまず`web`で最小の動作確認を取り、配布方式が固まった段階でバンドラ向けへ切り替えると手戻りが減ります。

## wasm-bindgenによるJavaScript連携とデータ受け渡しの実装

WASMのコア仕様が直接やり取りできる値は、整数と浮動小数点の数値だけです。文字列・配列・オブジェクトをJavaScriptと交換するには、境界のコードが要ります。それを自動生成するのがwasm-bindgenの役目です。

### 属性マクロで関数を公開し文字列や構造体をJSへ橋渡しする書き方

Rust側の関数やstructに`#[wasm_bindgen]`を付けると、JavaScriptから呼べる境界が生成されます。`&str`や`String`を引数・戻り値にすれば、線形メモリ上のエンコードとデコードはwasm-bindgenが肩代わりする仕組みです。JavaScript側は`init()`でWASMを初期化したうえで、公開した関数を通常のJS関数のように呼び出します。ここで押さえる勘所は、境界をまたぐ回数を減らすことです。ループの内側で1文字ずつ関数を呼ぶより、配列や文字列をまとめて1回渡し、Rust側で処理して結果を1回返すほうが、境界コストを抑えられます。

### 数値・文字列・バイト列で異なる受け渡しコストの実務上の扱い方

データ型ごとに越境コストは変わります。実装前にコスト感を持っておくと、設計段階で無駄な往復を避けられます。

| データ型             | 越境コスト           | 実装上の扱い           |
| ---------------- | --------------- | ---------------- |
| 数値（i32／f64）      | ほぼ無し            | そのまま引数・戻り値に置く    |
| 文字列（String）      | 中（UTF-8の複製が走る）  | 1回にまとめて渡す        |
| バイト列（Uint8Array） | 大きさに比例          | ゼロコピー系APIで複製を避ける |
| 構造体（serde経由）     | 大（JSON化を挟むと増える） | 頻繁な受け渡しには使わない    |

画像やファイルのようなバイト列は、`Uint8Array`とRust側の`&[u8]`を対応させ、可能な範囲でメモリの複製を避けます。構造体をserdeでJSON化してやり取りする書き方は手軽ですが、呼び出し頻度が高いホットパスでは変換コストが積み上がるため、そこだけは数値やバイト列の直接受け渡しへ寄せる判断が要ります。

## ブラウザ外でRust WASMを動かすWASI・エッジ環境の選択肢

WASMはブラウザ専用ではありません。ファイルやネットワークといったOS機能を扱うために策定されたのがWASI（WebAssembly System Interface）で、サーバー・エッジ・プラグイン基盤で同じバイナリを動かす土台になります。ブラウザ外の設計判断は、WASIの世代を理解すると迷いが減ります。

### wasm32-wasip1とwasm32-wasip2の違いと使い分けの基準

Rustのターゲットは目的で分かれます。ブラウザ向けは`wasm32-unknown-unknown`、サーバー・エッジ向けはWASIターゲットです。WASIには世代があり、選択が後段のホスト連携を左右します。

| ターゲット                  | 対応WASI   | 位置づけ（2026年時点）         |
| ---------------------- | -------- | --------------------- |
| wasm32-unknown-unknown | なし       | ブラウザ向け。wasm-bindgen前提 |
| wasm32-wasip1          | WASI 0.1 | 歴史的互換。旧来のホストと広く動く     |
| wasm32-wasip2          | WASI 0.2 | コンポーネントモデル前提          |

WASI 0.2（2024-01公開）はコンポーネントモデルの上に再設計された世代です。新規に型付きの部品として設計するなら`wasm32-wasip2`、既存ホストとの互換を優先するなら`wasm32-wasip1`、という選び分けになります。加えて、`wasm32-wasip2`はRust 1.82（2024-10-17）でtier2に達しました。ブラウザ外での仕組みと歴史的経緯は、[WASIがWebAssemblyをブラウザ外で動かすシステムインターフェースであることを解説した記事](https://www.issoh.co.jp/tech/details/13251/)で補完できます。コンポーネント形式で配布したい場合は、cargo-componentがwasm32-wasip1で生成したモジュールをWASI 0.2のコンポーネントへ変換する経路も使えます。

### エッジ・サーバーサイド実行で選ぶランタイムと配置パターンの基準

ビルドしたWASIバイナリを動かすには、ホスト側のランタイムが要ります。サーバー常駐ならWasmtimeやWasmer、エッジならCloudflare WorkersのRust向けSDK（workers-rs）やFastly Computeが代表的な選択肢です。配置パターンは、常駐プロセスに組み込む形と、リクエスト単位で起動する形に大別できます。前者はステートを保持しやすく、後者は水平スケールと隔離に強みがあります。プラグイン基盤としてWASMを使うなら、ホストアプリがWasmtimeを埋め込み、ユーザー提供のWASMをサンドボックス内で走らせる構成が定番です。どのランタイムでも、まずは小さな関数を1つ通して、ビルド設定とホストのバージョン差を潰してから機能を足すと安全です。

## WASMバイナリを軽量化し読み込み時間を削るための実装テクニック

Rust製WASMの初期実装は、想定より大きくなりがちです。デバッグ情報や未使用コードが残るためで、配布前の軽量化で数分の一まで削れます。順番に効かせるのが要点です。

### ビルドプロファイルとwasm-optでサイズを段階的に削る手順

軽量化は複数の設定を重ねて効かせます。1つずつ確認しながら適用すると、効果と副作用を切り分けられます。

1. `Cargo.toml`のリリースプロファイルで、サイズ削減を狙うビルドレベル `opt-level = "z"` と `lto = true` を指定する。
2. wasm-packが内部で呼ぶ軽量化ツール wasm-opt（Binaryen）で、デッドコード除去と命令の圧縮をかける。
3. 配信時にgzipまたはBrotliで圧縮し、転送量そのものを削る。

効き幅の目安は、デバッグビルド比でリリース＋wasm-optにより数分の一、転送はBrotliでさらに圧縮という積み上げです。過去に大きなアロケータ差し替えでサイズを稼ぐ手法が知られていましたが、保守状況が変わっているものもあるため、置き換え系はバイナリ実測とテストをセットにして採否を決めます。まず標準構成で計測し、足りなければ段階的に足すのが安全な順序です。

### ストリーミングコンパイルと遅延読み込みで体感速度を上げる設計

サイズを削っても、読み込み方が悪いと体感は上がりません。ブラウザ向けでは、ダウンロードとコンパイルを並行させるストリーミング初期化が効きます。WASMが要るのがユーザー操作の後なら、初期表示ではWASMを読まず、必要になった時点で遅延読み込みする設計が有効です。トップ表示に不要な計算モジュールを初回バンドルに含めない、という切り分けだけで、初期表示のブロッキングを避けられます。ここは「バイナリを小さくする」より「読むタイミングを遅らせる」ほうが体感への寄与が大きい、という優先順位で判断します。

## Rust×WebAssemblyを採用すべき条件と見送るべき場面の判断基準

ここが独自章です。入門手順を追えても、実務では「そもそもRust×WASMを入れるべきか」で立ち止まります。判断を言い切ります。

### 採用が投資に見合う条件と、費用対効果で見送るべきケースの基準

採用が効くのは、次の条件が揃うときです。第一に、JavaScriptで律速になる重い計算がモジュール単位で切り出せること。第二に、その計算が繰り返し呼ばれ、越境コストを上回る処理量があること。第三に、流用したいRustのCrate資産が既にあること。この3つが揃えば、Rust×WASMは投資に見合います。

逆に見送るべき場面もはっきりしています。UIのDOM操作が主体で計算がほとんど無いなら、WASM化してもJavaScriptと境界を往復するコストが勝ち、遅くなることさえあります。呼び出し頻度が低い処理、ビルドパイプラインを保守できるRust要員が居ない小規模チーム、数KBの節約のために数日を溶かす状況——これらは見送りが正解です。「速そうだから」という理由だけで全処理をRust化するのは、過剰投資の典型です。まず1つの重い関数だけをWASMに切り出し、計測で効果を確かめてから範囲を広げます。

### WASM化した高性能モジュールを既存システムへ組み込む進め方

Rust×WASMは、既存のWebシステムやAPIへ「一部だけ差し込む」形で導入すると失敗が減ります。全面刷新ではなく、律速箇所を1モジュールずつ置き換える漸進的な進め方が向いています。社内にRustとWASMの実装リソースが揃わない場合は、性能要件のある部品の実装と、それを既存システムへつなぐ連携設計をまとめて外部に委ねるのも一案です。高性能モジュールの受託実装やシステム連携は、[API開発・システム連携の受託](https://www.issoh.co.jp/service/system/api/)として相談できます。導入判断で見るべきは、置き換え対象の処理時間・呼び出し頻度・保守体制の3点で、ここが定まればWASM化の範囲は自ずと決まります。

## よくある質問

Rust×WebAssemblyの実装で、入門者からよく寄せられる質問に答えます。

### Rust WebAssemblyの学習は何から始めればよいですか？

まずrustupで`wasm32-unknown-unknown`ターゲットを追加し、wasm-packでライブラリを1つビルドしてブラウザから呼ぶ、という最小の一往復を通すところから始めます。文字列を1つ受け取って加工して返すだけの関数で十分です。この一往復でツールチェーンの役割分担が体に入るため、その後にJavaScript連携やサーバー向けターゲットへ広げると理解が速く進みます。

### wasm-packとwasm-bindgenは何が違いますか？

wasm-bindgenはRustとJavaScriptの境界コードを生成するライブラリとツール、wasm-packはビルドからパッケージングまでを束ねる上位ツールです。wasm-packは内部でwasm-bindgenを呼び出します。ブラウザ向けの標準ルートではwasm-packを使い、wasm-bindgenはその内部で動く、という関係で捉えると混乱しません。

### RustのWASMはJavaScriptより速いのですか？

計算主体の処理では速くなる傾向がありますが、常にではありません。JavaScriptとWASMの境界を越えるたびにコストが発生するため、細かく何度も往復する使い方では、逆にJavaScript単体より遅くなる場合があります。重い計算をまとめて1回で処理し、往復回数を減らす設計にしたときに、Rust×WASMの速度が生きます。

### WASMバイナリのサイズが大きいときはどう削りますか？

リリースビルドで`opt-level = "z"`と`lto = true`を指定し、wasm-opt（Binaryen）でデッドコードを除去し、配信時にBrotliで圧縮する、という三段で削ります。この順で適用するとデバッグビルド比で数分の一まで縮むことがあります。まず標準構成で実測し、足りない分だけ段階的に足すのが安全です。

### ブラウザ以外でRust WASMをどこで動かせますか？

WASIターゲット（`wasm32-wasip1`／`wasm32-wasip2`）でビルドすれば、WasmtimeやWasmerといったサーバー向けランタイム、Cloudflare WorkersやFastly Computeといったエッジ環境、さらにホストアプリのプラグイン基盤で動かせます。ブラウザ向けの`wasm32-unknown-unknown`とはターゲットが異なる点に注意してください。

## 関連記事

- [WASIとは｜WebAssemblyをブラウザ外で動かすシステムインターフェース](https://www.issoh.co.jp/tech/details/13251/)：本記事のサーバー・エッジ配置で前提となる、ブラウザ外実行の仕組みを詳しく解説しています。
- [MoonBit（ムーンビット）とは？WebAssembly対応の新言語の特徴・Rustとの違い](https://www.issoh.co.jp/tech/details/8968/)：WASM向けの言語選択でRust以外を検討する際の比較材料になります。

---

出典: [RustでWebAssemblyを実装する手順｜wasm-packでのWASM化と軽量化・配置先の選び方【2026年版】](<https://www.issoh.co.jp/tech/details/15290/>)（株式会社一創）