MoonBitとWASM系言語の現在地(2026年) ― Wasm GC時代の言語選び

シリーズ第1回では技術の役割分担を、第2回ではランタイムとフレームワークの地図を整理しました。最終回となる本稿は、その上で動くコードを書く言語――「WASM系言語」を、MoonBitを中心に整理します。2026年7月時点の現在地です。

「WASM系言語」は三群に分かれる

ひとくちに「WASM系言語」と言っても、実際には性格の異なる三群に分けるべきです。

1. WASMを前提に新しく設計された言語 ― MoonBit、Grain、AssemblyScript など
2. 既存言語にWASMバックエンドを追加したもの ― Rust、C/C++、Go、Kotlin、Dart、Swift、C# など
3. WASMをアプリ配布形式として利用するフレームワーク ― Blazor WebAssembly、Compose Multiplatform、Flutter Web、Spin など

このうちMoonBitは、単にWASMへコンパイルできる言語ではなく、言語・コンパイラ・ビルド・パッケージ管理・テスト・IDE支援をWASM時代向けに一体設計した言語です。現在はwasm・wasm-gc・JavaScript・ネイティブ向けのバックエンドを持ち、WIT/Component Modelにも直接対応しています。

比較の軸 ― 「.wasmを出せるか」だけでは足りない

WASM対応言語を評価するとき、.wasmを出力できるかだけでは不十分です。重要なのは次の軸です。

とりわけ大きいのが、従来型の線形メモリWASMと Wasm GC の違いです。

従来型WASM             Wasm GC
線形メモリ             struct / array / typed reference
pointer + length       ホストGCがオブジェクトを管理
言語側でヒープ管理      Kotlin / Dart / MoonBit などに適する
C / Rust / AssemblyScript向き

WebAssembly 3.0でGCと型付き参照が仕様へ統合され、GC言語をWASMへ載せる基盤が大幅に強化されました。この変化が、言語選びの前提を動かしています。

MoonBit

MoonBitとは何か

MoonBitは、WASMを主要ターゲットとして設計された静的型付きの汎用言語です。公式ドキュメントでは、wasm・wasm-gc・JavaScript・C/native・LLVM(実験的)のバックエンドが示されています。同一モジュール内でWebフロントエンドとネイティブ処理が同じドメインモデルを共有する、混在バックエンド構成も想定されています。

言語としては、Rust・OCaml・Go・TypeScriptの要素を組み合わせたような構成です。

enum Result[T, E] {
  Ok(T)
  Err(E)
}

struct User {
  id : Int
  name : String
}

fn find_user(id : Int) -> Result[User, String] {
  if id > 0 {
    Ok({ id, name: "Alice" })
  } else {
    Err("invalid id")
  }
}

静的型付け、型推論、代数的データ型、パターンマッチ、ジェネリクス、トレイト、null安全性、例外効果の追跡、組み込みテスト、GCによるメモリ管理、高速な増分・並列ビルドが主な特徴です。Rustに似た構文を持ちますが、所有権・ライフタイムを中心に置く言語ではありません。

wasm と wasm-gc の使い分け

MoonBitは従来型WASMとWasm GCを明示的に分けています。wasm(線形メモリ)は対応ランタイムが広く、既存WASMツールやWASI環境と統合しやすい方式です。wasm-gcはWASMのGC型を直接利用し、文字列・配列・構造体をエンジン側のGCオブジェクトとして扱えます。

wasm       : MoonBit object → linear memory → MoonBit runtime / GC
wasm-gc    : MoonBit object → Wasm struct / array / ref → browser GC

Wasm GCの理論上の利点は、独自GCランタイムを小さくできること、JSオブジェクトとの橋渡しを改善できること、型付き参照を使えること、線形メモリ上のポインタ変換を減らせることです。一方でWASIやComponent Modelのエコシステムは従来型Core Wasmを中心に成熟してきたため、Wasm GCとの統合はランタイム・ツールの対応確認が要ります。

Component Model対応

MoonBitはWITからバインディングを生成し、WebAssembly Componentを構築できます。Bytecode AllianceのComponent Model公式ガイドでも対応言語として扱われています。

package example:calculator;

world calculator {
  export add: func(a: s32, b: s32) -> s32;
}

これは、MoonBitを単なるブラウザ向け言語ではなく、Spin・Wasmtime・Wasmerなどで動くサーバー/エッジコンポーネント言語として使えることを意味します。

FFIとホスト依存

外部世界へのアクセスは、ホスト関数のimportに依存します。公式ドキュメントも、標準ライブラリの一部がMoonBit固有のホスト関数を必要とし、可搬性を重視するなら利用を避けるべきだと説明しています。

extern "js" fn console_log(value : String) = "console.log"

注意すべきは、MoonBitで書けばWeb APIを直接・完全に型安全に使えるわけではない点です。ブラウザ用途では、依然としてJavaScript FFI、Web API用バインディング、JSグルー、ホストごとのimport定義、Worker/Promiseとの非同期統合が必要になります。非同期支援も存在しますが、一部は実験的機能として扱われています。

ツールチェーン

MoonBitの強みは、言語だけでなくツールチェーン全体が統合されていることです。moon が増分・並列ビルド、テスト、パッケージ管理、ドキュメント生成を統合し、レジストリはMooncakesです。

moon
  ├─ moon new / build / check / run
  ├─ moon test / fmt / doc
  └─ moon add / publish

この点はAssemblyScript(npmエコシステム上に構築)やGrain(独自言語・コンパイラ中心)との大きな差で、MoonBitは言語+ビルド+テスト+LSP+パッケージ管理を一体で提供します。

MoonBitの適性

小型WASMライブラリ、ブラウザ内の解析・変換処理、エッジ関数、WASM Component、DSLやパーサー、アルゴリズム実装、プラグイン、クロスバックエンドのドメインロジック、新規WASMネイティブアプリに向きます。逆に、巨大な既存ライブラリ資産を要するアプリ、OS APIへ深く依存するアプリ、成熟したGUIフレームワークが要るアプリ、複雑なDOMアプリ、高度な非同期ネットワークアプリでは慎重になるべきです。有望ですが、Rust・C++・C#・Kotlinほど既存資産が豊富な段階ではありません。

AssemblyScript

AssemblyScriptは、TypeScript風構文を持つWASM専用言語です。「TypeScriptのサブセット」と説明されがちですが、正確には、TypeScriptに似た構文でWASMへ直接対応する独立言語です。JSの動的型やオブジェクトモデルをそのまま使うわけではありません。

export function add(a: i32, b: i32): i32 {
  return a + b;
}

let value = load<i32>(ptr);
store<i32>(ptr, value + 1);

線形メモリ上に独自ランタイムとGC(incremental/minimal/stub)を実装します。小型の数値関数では非常に小さな出力にできますが、文字列・配列・クラスを多用するとランタイムとJS側バインディングが要ります。TypeScript開発者が入りやすい、生WASMに近い、npmと統合しやすい、といった長所がある一方、TSライブラリをそのまま使えない、DOM APIを直接使えない、独自GC、例外/非同期に制約、Component Modelは中心的ワークフローではない、といった制約があります。Wasm GC対応はロードマップ上ですが、既存設計は線形メモリと独自ランタイムが前提です。

「TypeScriptをWASMにする」より、TypeScript風の文法でCに近いWASMコードを書くと理解するのが正確です。

Grain

Grainは、WASMを唯一の主要実行基盤として設計された関数型寄りの言語です。ブラウザ・CLI・サーバー・WASI環境での実行を想定しています。

enum Option<a> {
  Some(a),
  None,
}

let divide = (a, b) =>
  if (b == 0) {
    None
  } else {
    Some(a / b)
  }

Hindley–Milner系の型推論、代数的データ型、パターンマッチ、イミュータブル指向、nullなし、GC付き、JavaScript FFIが特徴で、MoonBitより関数型色が強く、言語設計の簡潔さを重視します。関数型によるWASMアプリ、教育、CLI、SpinなどのWASIアプリ、型安全な小型サービス、パーサーに向きます。課題は、エコシステムが小さいこと、ネイティブバックエンドが中心でないこと、GUI/Web UIライブラリが少ないこと、企業採用が限定的なことです。MoonBitが「WASM時代の汎用システム・アプリ言語」を狙うのに対し、Grainは「WASMを実行基盤とする扱いやすい関数型言語」に近い位置づけです。

既存言語のWASMバックエンド

Rust

RustはWASM専用言語ではありませんが、現在も最も成熟した選択肢の一つです。ターゲットはwasm32-unknown-unknown(ブラウザ/JSホスト)、wasm32-wasip1(WASI Preview 1)、そしてComponent Model(cargo-component/wit-bindgen)。wasm-bindgen・web-sys・js-sys・wit-bindgen・cargo-component・wasm-tools・Wasmtime親和性・wgpu・SIMD・スレッド・メモリ制御・巨大なcrate資産と、周辺が非常に厚いのが強みです。弱みは、所有権・ライフタイムの学習コスト、DOM中心アプリでのコードの冗長さ、非同期とWASM境界の複雑さ、バイナリサイズ調整の必要性です。MoonBitより言語・ライブラリが成熟する一方、MoonBitはRustほどの低水準管理を求めず短く書けます。性能・資産・制御ならRust、開発速度・簡潔さ・WASM第一級設計ならMoonBit、という対比です。

C / C++

C/C++はEmscriptenまたはWASI SDKを通してWASMへコンパイルできます。最大の価値は既存資産で、SQLite・FFmpeg・OpenCV・LLVM・ゲームエンジン・圧縮/暗号ライブラリ・CAD/科学計算コードをWebへ持ち込めます。ネイティブ資産の移植、成熟したEmscripten、SIMD/スレッド、WebGL/WebGPU連携、細かなメモリ制御が長所。メモリ安全性、JSグルーの肥大化、POSIX互換層への依存、DOM操作への不向きが短所です。新規言語として選ぶより、既存ネイティブコードをWASMへ持ち込む主力経路です。

TinyGo / Go

Goはブラウザ向けjs/wasmとWASI向けターゲットを持ちますが、標準GoはGoランタイム・GC・schedulerを含むため出力が大きくなりがちです。Go 1.24ではWASM関数exportとreactor modeが強化され、WASMをGoアプリの拡張単位として扱いやすくなりました。TinyGo はWASM/WASI/組み込み向けに小さなバイナリを生成するGoコンパイラで、wasm・wasi・組み込みターゲットを持ち、Component Modelの言語支援も進んでいます。反面、標準Goとの完全互換ではなく、reflectionや一部標準ライブラリ、GC/goroutine挙動に制約があります。Go開発者がWASIコンポーネントを書くには有力ですが、ブラウザUIではJS連携が中心になります。

Kotlin/Wasm

Kotlin/Wasmは、KotlinをWasm GCへコンパイルするバックエンドです。ブラウザ向けwasm-jsとWASI向けwasm-wasiがあり、Wasm GCを使うため、クラスやオブジェクトを線形メモリ内の独自ランタイムだけで表現する必要がありません。Compose Multiplatform Web、Kotlin Multiplatform、KotlinドメインロジックのWeb共有が主用途で、型システム・coroutine・Compose・JVM/Android資産との共有・Wasm GCが強み。小型WASMライブラリ向きではなく、Kotlinランタイムと標準ライブラリが必要で、UIアプリ寄りです。MoonBitがWASM自体を配布・実行基盤として使うのに対し、Kotlin/Wasmは既存Kotlin資産とUI共有が主眼です。

Dart / Flutter Wasm

DartはWasm GCを利用する本番向けコンパイラdart2wasmを持ち、Flutter WebもWASMビルドへ対応しています。JavaScript interop APIもWASM対応に合わせて刷新されました。Flutter UI、Web/モバイル/デスクトップ共有、高水準のasync/await、ホットリロードが長所。反面、Flutterランタイムと描画層が大きく、小型WASMライブラリには不向きで、WIT Componentとして配布する言語でもありません。MoonBitと競合するというより、Flutter WasmはクロスプラットフォームUI基盤です。

C# / Blazor WebAssembly

Blazor WebAssemblyは、.NETランタイム自体をWASMとしてブラウザへロードし、その上でC#アプリを動かします(AOT使用時はより直接的にコンパイル)。.NETエコシステム、C#とRazor、ASP.NET Core統合、豊富な業務ライブラリ、デバッガ、UIフレームワークが長所。配布サイズと起動時間が大きく、小型コンポーネント用途には不向きで、生WASMライブラリとしての再利用性は低めです。BlazorはWASM言語というより、WASM上で.NETアプリケーションプラットフォームを動かす方式です。

SwiftWasm

SwiftWasmはSwiftコンパイラと標準ライブラリをWASMへ対応させるプロジェクトで、Swiftコードをブラウザ/WASI環境で実行します。JS統合にはJavaScriptKitを使います。

import JavaScriptKit

let document = JSObject.global.document
document.body.innerText = "Hello from Swift"

Swiftの型安全性、Apple系コードとの共有可能性、async/await、Swift Package Managerが長所。課題は、バイナリサイズ、Foundationの対応差、Swiftランタイム、JS連携ライブラリの成熟度、ブラウザUI資産の少なさです。デフォルトの並行実行は単一スレッドの協調タスクexecutorを使います。

言語の位置づけ比較

MoonBit・AssemblyScript・Rust の使い分け

この三つは特に比較されやすいですが、目的が異なります。

• 小さなJS向けWASMライブラリ → AssemblyScript。TS開発者が、画像処理・ハッシュ・数値処理などの小さなモジュールを書く用途。
• WASM Component / エッジアプリ → MoonBit。WIT・パターンマッチ・GC・高水準型・統合ツールチェーンで、アプリロジックを短く書く用途。
• 高性能・低水準・成熟資産 → Rust。WebGPU・SIMD・スレッド・DB・暗号・ランタイム埋め込みまで制御する用途。

まとめ ― MoonBitは「境界が明確な計算コンポーネント」から

MoonBitは「Rustより簡単なWASM言語」ではなく、WASM/クラウド/エッジを前提に言語とツールチェーンを新規設計した点に独自性があります。wasmとwasm-gcを使い分けられ、WIT/Component Modelに対応し、JavaScriptとネイティブにも出力でき、所有権なしで高水準な型を使え、ビルド・テスト・LSP・パッケージ管理が一体で、出力が比較的小さい。パーサー、アルゴリズム、データ処理と相性が良い言語です。

一方で実用上の最大の弱点は、言語仕様ではなく周辺資産です。パッケージ数、Web APIバインディング、非同期I/O、DBドライバ、GUI、GPU、ネイティブ連携、運用実績、長期互換性――ここはまだ発展途上です。

したがって2026年時点の妥当な判断は、次のようになります。MoonBitは、新規のWASM Component、エッジ処理、ブラウザ内計算ライブラリ、パーサー、データ変換には有力。一方、巨大な既存資産、高度なWebGPU統合、OS密着処理では、まだRustやC/C++を置き換える段階ではありません。

大規模なデータUIのような構成なら、全体を一つの言語へ寄せるのではなく、UI・DOM・Web ComponentsはTypeScript、GPUレンダラーや低水準共有メモリはRust/wgpu、フィルタ式・クエリ変換・パーサー・データ整形・ルールエンジンといった WASM境界が明確な計算・変換コンポーネント をMoonBit、という分担が堅実です。MoonBitは「全部を書く言語」としてではなく、境界の明確なコンポーネントを書く言語として採用するのが、現時点では最も現実的です。

参考リンク

• MoonBit 公式サイト / MoonBit ドキュメント
• AssemblyScript
• Grain
• Rust and WebAssembly / wasm-bindgen
• Kotlin/Wasm
• Dart to Wasm / Flutter on the web
• Blazor WebAssembly(Microsoft Learn)
• SwiftWasm
• WebAssembly Component Model
• Go WebAssembly / TinyGo