[JavaScript] JavaScriptをネイティブ化する3つのアプローチと配布戦略

はじめに

JavaScriptはソースが丸見えのため、盗用リスクや改変リスクが常に付きまといます。そこで「ネイティブ化」によって、逆コンパイルのハードルを上げたり、配布形態を工夫するアプローチが考えられます。

この記事は、小規模ツールを配布したい開発者や、最低限の防御をしておきたい制作者向けに整理しました。

なぜ「ネイティブ化」を検討するのか

JSは配布＝可読に近い形での配布になりやすく、丸パクリ／改変のコストが低い
そこで「実行環境を同梱した単一バイナリ」「別エンジンでのAOT化」「WASM/ネイティブ拡張でコアを分離」の3系統で再実装コストを上げるのが現実解
なお “完全防止”は不可能。秘密鍵・トークンは絶対にバイナリへ埋め込まないこと

アプローチA：実行環境同梱の「単一バイナリ化」

狙い：Node/Deno本体＋アプリを一塊にしてEXE/ELF配布。JSは機械語にならないが、簡易に配布でき抽出難度もやや上がる。

pkg（Vercel）：Nodeアプリを単一実行ファイル化。クロスビルドのターゲット指定が可能。(GitHub)
```
npx pkg app.js --targets node18-win-x64,node18-linux-x64 -o dist/app
```
nexe：同様にNodeアプリを単一バイナリ化。失敗時は --build でローカルビルドを試す。(GitHub)
```
npx nexe app.js -t windows-x64-18.0.0 -o dist/app.exe
```
Deno compile：Denoは公式で単一バイナリ生成を提供。--target によるクロスコンパイル、ランタイムも同梱される。(Deno)
```
deno compile --allow-net --target x86_64-unknown-linux-gnu -o dist/runme main.ts
```
Node公式：Single Executable Applications Node自体にも「単一実行ファイル化」の公式ガイド（postject等でバンドル）あり。仕組みの理解に役立つ。(nodejs.org)

所感

強み：導入が最短。既存Node/Denoコードをほぼそのまま配布できる
弱み：サイズが大きめ。ツール次第でアーカイブ抽出は理論上可能（機密は入れない）

アプローチB：別エンジンでのAOT／軽量実行

狙い：QuickJSやGraalJSなど別のJS実行系を用い、バイトコード化やAOTで「読み解きにくさ」「起動・配布特性」を変える。

QuickJS（qjsc）：JS→Cソース（バイトコード埋め込み）→ネイティブへ。小さな単体実行が作れる。(bellard.org)
```
qjsc -o out.c main.js
cc out.c -lquickjs -o app
```
開発が活発な派生「quickjs-ng」もある。(GitHub)
GraalVM + GraalJS：JVM上の高速JS実装。native-imageでネイティブランチャを作れる構成がある（ポリグロット用途、--language:js 指定等）。(GraalVM)
```
gu install native-image
native-image --language:js -jar your-polyglot-app.jar
```

所感

強み：軽量化（QuickJS）や高速起動（GraalVM）など特性を選べる
弱み：eval/動的import制約、ビルド環境がやや重い（GraalVM）

アプローチC：コアだけ“本当に固くする”（WASM/ネイティブ拡張）

狙い：UIはJSに残し、計算コアのみをWASMやネイティブ拡張に分離し、再実装コストと解析難度を上げる。

WebAssembly
- AssemblyScript：TSに近い文法でWASMをAOT生成。ブラウザ/Node/Denoで実行。(assemblyscript.org)
```
npm i -D assemblyscript
npx asinit .
npm run asbuild   # build/optimized.wasm
```
- DenoでのWASM実行やRust→WASMのガイドも充実。(Deno)
Nodeネイティブ拡張（Node-API / N-API）
- ABI安定な公式API。C/C++ラッパ node-addon-api も利用可。(nodejs.org)
- Rust派生（Neon）：Rustで安全にAddonを作成。CLIで雛形生成。(neon-rs.dev)
```
npm init neon@latest my-addon
```

所感

強み：最も“堅い”。性能向上も得やすい
弱み：言語・ツール連携の学習コスト、OS/CPU別ビルドや配布管理が必要

どれを選ぶか（用途別クイックガイド）

まず動く単体配布が欲しい：pkg / Deno compile（短時間で到達）。(GitHub)
サイズを抑えたい／起動を速くしたい：QuickJS（qjsc）やGraalVM（要件合致時）。(bellard.org)
丸パクリの再実装コストを最大化：WASMまたはNode-API/Neonでコア分離。(assemblyscript.org)

実装時のチェックリスト

機密（APIキー・ライセンス鍵）は配布物に同梱しない
ランタイム依存（OpenSSL, ICU 等）やクロスビルド可否を事前確認
動的require／eval／外部アセット読み込みはAOT化の阻害要因
ライセンス表記・利用規約・責任限定の文言を同梱
それでも抽出・逆解析はゼロにできない前提で設計する

粗いベンチマーク観点（実務者目線）

観点	単一バイナリ化（pkg/Deno）	QuickJS/GraalVM	WASM/Node-API
導入速度	速い	中	中〜遅
配布サイズ	大（Denoは中）	小〜中	小（WASM）/中（Addon）
互換性	高（JSそのまま）	中（制約あり）	低〜中（言語混在）
解析耐性	中	中	高
性能	元コード次第	場合により向上	向上余地大

参考資料：pkg / nexe / Deno compile / Node公式の単一実行ガイド / QuickJS（qjsc） / GraalJS & native-image / AssemblyScript / Node-API & node-addon-api / Neon。(GitHub)

実践サンプル集

1. pkgで最短バイナリ化

$ npm init -y
$ npm install pkg
$ echo 'console.log("Hello native!");' > app.js
$ npx pkg app.js -o app

dist/app.exe (Windows) や dist/app (Linux/Mac) が出力される
落とし穴: pkg は一部モジュール解決が不得意（動的 require など）

2. nexeのビルド

$ npx nexe app.js -o app.exe

落とし穴: プリビルドのNodeバイナリが取得できないとエラー。その場合は --build を付けてローカルでNodeを再ビルドする必要あり。

3. Deno compile

$ deno compile --allow-net --target x86_64-unknown-linux-gnu main.ts

TypeScriptをそのままEXE化できる。
落とし穴: 動的importはビルド時に解決できず失敗する。

4. QuickJSでC化 → ネイティブ

$ qjsc -o out.c main.js
$ cc out.c -lquickjs -o app

特徴: 非常に小さな単体バイナリができる
落とし穴: Node APIが使えない（あくまでECMAScript準拠）

5. AssemblyScriptでWASM生成

$ npm install -D assemblyscript
$ npx asinit .
$ npm run asbuild

./build/optimized.wasm が生成される
落とし穴: JSと同じ感覚で書けるが、DOM操作やNode APIには直接アクセスできない

6. Neon（RustでNode拡張）

$ npm init neon@latest my-addon
$ cd my-addon
$ npm install
$ npm run build

.node バイナリが生成されJSから require() で呼び出せる
落とし穴: ビルドはOS依存。Windows/Linux/Mac用に分けて配布する必要あり

よくある失敗と回避法

動的requireやevalがある → 事前に静的importへ書き換える
秘密情報を埋め込む → 絶対NG。外部APIや環境変数から注入する
配布バイナリのサイズ肥大化 → QuickJSやAssemblyScriptで軽量化する手もあり
クロスビルドで詰まる → DockerやCI環境でターゲットごとにビルドジョブを分ける

学習を深める視点

「JSを守る」ではなく「守りたい部分をJSから切り離す」
どこまでユーザーに見せても困らないかを線引きして設計する
利用規約と著作権表記は心理的抑止力になるので必ず付ける
配布形態の選択肢（Web配布かローカル配布か）によって最適解は変わる

ユースケース別に考える「最適アプローチ」

1. CLIツールや小規模ユーティリティを配布したい

推奨: pkg / nexe / Deno compile
理由:
- 開発速度を優先できる
- コードはある程度難読化される
- 依存関係をまとめて1ファイルにできる
注意点:
- ファイルサイズは肥大化（30〜80MB程度）
- 秘密鍵やAPIキーは埋め込まない

2. ブラウザで使うWebアプリのロジックを守りたい

推奨: WebAssembly (AssemblyScript, Rust→WASM)
理由:
- ユーザーに渡さざるを得ない部分を「難読化＋高速化」できる
- 数値計算やゲームロジックの保護に強い
注意点:
- DOM操作やネットワークはJS側で行う必要あり
- WASMだけで完結は難しい → 「UIはJS／コアはWASM」に分離する

3. ネイティブ性能が欲しい（ゲーム・画像処理・暗号処理）

推奨: Node-API拡張（C++/Rust Neon）
理由:
- ネイティブ速度が出せる
- .node モジュールは解析難度が高い
注意点:
- OSごとにビルドが必要
- CI/CDでクロスビルド環境を整備するコストがある

4. 長期的に有料サービスを展開したい

推奨: 「サーバ側処理」＋「クライアントはUIのみ」
理由:
- 盗用対策の究極は「重要処理を配布しない」こと
- API経由で機能を提供すれば制御可能
注意点:
- サーバ維持コストがかかる
- APIのセキュリティ設計（短期トークン、利用制限）が必須

法的・ライセンス戦略

1. 利用規約・著作権表記を必ず明記

ソースや配布物に著作権表記とライセンス条件を含める
無断複製・改変の禁止、再配布条件などを簡潔に書いておく

2. OSSライセンスの活用

MITやApache-2.0を利用する場合は「著作権表記の維持」を義務付けられる
GPL系を使うと「派生物を公開義務」にできるが、商用では敬遠されやすい

3. ウォーターマークやビルドIDの埋め込み

コードやWASMに「ビルド日時・ID」を埋め込み
不正利用された場合に自分のコードと証明できる
これは法的措置の裏付けになる

4. 法的措置を視野に入れる

実際に盗用された場合は「証拠確保」が最優先
Gitのコミット履歴やビルドIDは証拠になる
弁護士対応を前提に、最低限のログや記録は残しておく

学習の深め方

技術的対策は「解析コストを上げる」に過ぎない
法的対策（著作権・ライセンス）と心理的抑止力を組み合わせることが現実解
最終的に「盗まれても困らない形で公開」できる設計にすることがゴール

CI/CDに組み込む意味

手動ビルドでは環境依存やヒューマンエラーが多い
自動化すれば「常に同じ条件でバイナリ生成＋署名＋配布」が可能
配布する以上は再現性と証跡が重要になる

一般的なワークフロー構成

リポジトリ管理 (GitHub/GitLab/Bitbucket)
- コードは必ずGit管理
- コミットハッシュが「法的証拠」としても使える
ビルド環境 (CIサービス)
- GitHub Actions / GitLab CI / CircleCIなど
- OSごとにジョブを分けてクロスビルドを行う
バイナリ生成
- pkg / nexe / deno compile / qjsc などをCI上で実行
- WASMやNeonなら cargo build --release を組み込む
署名・ハッシュ生成
- gpg --detach-sign で署名
- sha256sum でチェックサムファイルを作成
- ユーザーに配布するときに「検証できる状態」を提供する
成果物の配布
- GitHub Releaseやnpmパッケージ、独自サイトにアップロード
- 有料配布ならライセンス認証サーバと連携する

実装サンプル（GitHub Actions）

Node.jsアプリを `pkg` でバイナリ化する例

name: Build and Release

on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm install
      - run: npx pkg app.js -o dist/app
      - run: sha256sum dist/app > dist/app.sha256
      - uses: softprops/action-gh-release@v1
        with:
          files: |
            dist/app
            dist/app.sha256

ポイント: タグ付きリリース時に自動ビルド → Releaseページへ成果物を添付

WASMモジュールを自動ビルドする例

jobs:
  wasm:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 18
      - run: npm install -g assemblyscript
      - run: npx asbuild
      - run: sha256sum build/optimized.wasm > build/optimized.wasm.sha256
      - uses: softprops/action-gh-release@v1
        with:
          files: |
            build/optimized.wasm
            build/optimized.wasm.sha256

よくある課題と対処法

クロスビルドで失敗する → OSごとにジョブを分ける／Dockerで統一環境を用意
サイズが大きすぎる → QuickJSやWASMで軽量化、不要モジュール削減
秘密情報の管理 → .envやAPIキーは必ずCIのシークレット管理機能を使う
ユーザーへの信頼提供 → 署名やハッシュを公開し「改ざんされていない」ことを保証

学習をさらに進める方向

ライセンス認証の自動発行（Stripeや自前サーバ連携）
アップデート配信（差分アップデート／自動アップデーター）
Dockerイメージ配布（サーバ側処理を含める場合は有効）

ライセンス認証の考え方

目的：ソフトが「正規ユーザー」だけで動作するように制御する
前提：不正コピーは技術的に100%防げない → 「再配布コストを上げる」「検知できる」設計が現実解
構成：
1. クライアント側 → ライセンスキーを保持・送信
2. サーバ側 → キーの有効性を検証、利用状況を記録
3. 必要なら「短期トークン」を返し、クライアントはその間だけ機能利用可能

クライアント側実装（例：Node.js / JSアプリ）

ユーザーがライセンスキーを入力（または購入時に発行されたキーを保持）

起動時にサーバへ POST /verify リクエスト

{
  "license": "XXXX-YYYY-ZZZZ",
  "device": "machine-id-1234"
}

サーバがOKなら「短期トークン」を返す
そのトークンが有効な間だけ機能を解放する

※ 短期トークンを使うことで「キーを埋め込んで解析されるリスク」を軽減できる

サーバ側実装イメージ（簡易）

// Expressサンプル
import express from "express";
const app = express();

const validKeys = {
  "XXXX-YYYY-ZZZZ": { expires: "2025-12-31" },
};

app.post("/verify", (req, res) => {
  const { license, device } = req.body;
  const record = validKeys[license];
  if (!record) return res.status(403).json({ error: "Invalid key" });

  if (new Date() > new Date(record.expires)) {
    return res.status(403).json({ error: "Expired" });
  }

  // 短期トークン発行（例：JWT）
  const token = generateJWT({ device, license });
  res.json({ token });
});

短期トークン（JWTなど）は1日〜数時間で期限切れ
期限が切れれば再認証が必要

ライセンスキーの発行・管理

単純なキー生成
- UUIDやハッシュで生成してDBに保存
StripeやPayPalと連携
- 決済成功時にライセンス発行APIを呼ぶ
SaaS管理ツールを使う
- 例：Keygen, LicenseSpring, Cryptlex
- 管理画面・レポート・不正検知まで一括提供

よくある戦略

無料版と有料版を分ける
- 無料は機能制限＋広告
- 有料はライセンスキー入力で制限解除
利用回数制限
- ライセンスが有効でも「1日◯回」などをサーバ側でカウント
ウォーターマーク／ビルドID埋め込み
- 個別ビルドにユーザーIDやシリアルを埋め込む
- 流出した場合に誰のキーか特定できる

注意点

クライアント側のチェックは「無効化」される可能性がある
本当に守りたい部分は必ずサーバ処理に置く
ライセンス認証は「抑止力＋制御」であり、「完封」ではない

学習を深める方向

JWTを使った短期認証の設計例
KeygenやCryptlexなど外部サービスとの比較
個人配布／商用配布／OSS＋有料版でのライセンスモデルの違い

ライセンスモデルの主な種類

1. 買い切り型（Perpetual License）

概要: ユーザーが一度購入すると無期限で利用可能
メリット:
- ユーザーに分かりやすい（シンプルな料金体系）
- 導入障壁が低い
デメリット:
- 一度買われると継続収益がない
- アップデートをどう扱うか問題になる（有償アップグレードか無料か）
例: Photoshopの旧モデル、WinRAR

2. サブスクリプション型（Subscription License）

概要: 月額/年額など定期的に課金してライセンスを維持
メリット:
- 継続収益が見込める
- ユーザーに常に最新版を提供できる
デメリット:
- ユーザーが「支払い続ける価値」を感じないと離脱する
- サーバ維持コストが常に発生
例: Adobe Creative Cloud, JetBrains IDEs

3. フリーミアム型（Freemium）

概要: 無料版で基本機能を提供し、有料版で追加機能を開放
メリット:
- ユーザー獲得がしやすい
- 機能を体験してから課金へつなげやすい
デメリット:
- 無料ユーザーのサポート負荷が増える可能性
- 有料機能との差別化が不十分だと収益化しにくい
例: Evernote, GitHub Copilot（個人利用無料→商用は有料）

4. 二重ライセンス（Dual License）

概要: OSSライセンスと商用ライセンスを併用
メリット:
- OSSとして普及させつつ、企業利用で収益化できる
- OSSコミュニティからの貢献を受けられる
デメリット:
- OSSライセンスと商用ライセンスの境界が曖昧だとトラブルになりやすい
例: MySQL (GPL + 商用ライセンス), Qt

5. 利用回数／従量課金型（Usage-based Licensing）

概要: 利用回数や処理量に応じて課金
メリット:
- 実際の利用量に比例して収益が得られる
- 無駄が少なくフェア
デメリット:
- 実装コストが高い（利用状況を常にサーバでトラッキング）
- ユーザーが「使いすぎたら怖い」と感じやすい
例: API提供（OpenAI, AWS Lambda）

ライセンスモデル選定のポイント

ユーザー層
- 個人向けなら「買い切り」か「フリーミアム」
- 法人向けなら「サブスク」や「二重ライセンス」が相性良い
開発体制と更新頻度
- 更新が頻繁なら「サブスク」
- 大規模機能追加ごとに販売したいなら「買い切り＋有償アップデート」
配布形態
- SaaS/クラウドなら「サブスク or 従量課金」
- デスクトップ配布なら「買い切り or フリーミアム」

技術とライセンスの接続

買い切り型 → ライセンスキー＋期限チェック
サブスク型 → 定期的なサーバ認証＋短期トークン
フリーミアム型 → 機能分岐（有料機能はライセンス必須）
二重ライセンス型 → OSS公開部分とクローズド拡張部分を分離
従量課金型 → APIゲートウェイでリクエスト数を制御

学習の深め方

「OSSから商用への移行」で起こったトラブル事例を調べる
Stripeなどの決済サービスとライセンスサーバを連動させる設計例を学ぶ
利用規約の書き方（特に再配布禁止条項と責任限定）を押さえる

はじめに#

なぜ「ネイティブ化」を検討するのか#

アプローチA：実行環境同梱の「単一バイナリ化」#

アプローチB：別エンジンでのAOT／軽量実行#

アプローチC：コアだけ“本当に固くする”（WASM/ネイティブ拡張）#

どれを選ぶか（用途別クイックガイド）#

実装時のチェックリスト#

粗いベンチマーク観点（実務者目線）#

実践サンプル集#

1. pkgで最短バイナリ化#

2. nexeのビルド#

3. Deno compile#

4. QuickJSでC化 → ネイティブ#

5. AssemblyScriptでWASM生成#

6. Neon（RustでNode拡張）#

よくある失敗と回避法#

学習を深める視点#

ユースケース別に考える「最適アプローチ」#

1. CLIツールや小規模ユーティリティを配布したい#

2. ブラウザで使うWebアプリのロジックを守りたい#

3. ネイティブ性能が欲しい（ゲーム・画像処理・暗号処理）#

4. 長期的に有料サービスを展開したい#

法的・ライセンス戦略#

1. 利用規約・著作権表記を必ず明記#

2. OSSライセンスの活用#

3. ウォーターマークやビルドIDの埋め込み#

4. 法的措置を視野に入れる#

学習の深め方#

CI/CDに組み込む意味#

一般的なワークフロー構成#

実装サンプル（GitHub Actions）#

Node.jsアプリを pkg でバイナリ化する例#

WASMモジュールを自動ビルドする例#

よくある課題と対処法#

学習をさらに進める方向#

ライセンス認証の考え方#

クライアント側実装（例：Node.js / JSアプリ）#

サーバ側実装イメージ（簡易）#

ライセンスキーの発行・管理#

よくある戦略#

注意点#

学習を深める方向#

ライセンスモデルの主な種類#

1. 買い切り型（Perpetual License）#

2. サブスクリプション型（Subscription License）#

3. フリーミアム型（Freemium）#

4. 二重ライセンス（Dual License）#

5. 利用回数／従量課金型（Usage-based Licensing）#

ライセンスモデル選定のポイント#

技術とライセンスの接続#

学習の深め方#

💬 コメント

はじめに

なぜ「ネイティブ化」を検討するのか

アプローチA：実行環境同梱の「単一バイナリ化」

アプローチB：別エンジンでのAOT／軽量実行

アプローチC：コアだけ“本当に固くする”（WASM/ネイティブ拡張）

どれを選ぶか（用途別クイックガイド）

実装時のチェックリスト

粗いベンチマーク観点（実務者目線）

実践サンプル集

1. pkgで最短バイナリ化

2. nexeのビルド

3. Deno compile

4. QuickJSでC化 → ネイティブ

5. AssemblyScriptでWASM生成

6. Neon（RustでNode拡張）

よくある失敗と回避法

学習を深める視点

ユースケース別に考える「最適アプローチ」

1. CLIツールや小規模ユーティリティを配布したい

2. ブラウザで使うWebアプリのロジックを守りたい

3. ネイティブ性能が欲しい（ゲーム・画像処理・暗号処理）

4. 長期的に有料サービスを展開したい

法的・ライセンス戦略

1. 利用規約・著作権表記を必ず明記

2. OSSライセンスの活用

3. ウォーターマークやビルドIDの埋め込み

4. 法的措置を視野に入れる

学習の深め方

CI/CDに組み込む意味

一般的なワークフロー構成

実装サンプル（GitHub Actions）

Node.jsアプリを `pkg` でバイナリ化する例

WASMモジュールを自動ビルドする例

よくある課題と対処法

学習をさらに進める方向

ライセンス認証の考え方

クライアント側実装（例：Node.js / JSアプリ）

サーバ側実装イメージ（簡易）

ライセンスキーの発行・管理

よくある戦略

注意点

学習を深める方向

ライセンスモデルの主な種類

1. 買い切り型（Perpetual License）

2. サブスクリプション型（Subscription License）

3. フリーミアム型（Freemium）

4. 二重ライセンス（Dual License）

5. 利用回数／従量課金型（Usage-based Licensing）

ライセンスモデル選定のポイント

技術とライセンスの接続

学習の深め方