WebAssembly（Wasm）プロキシによるエッジでのカスタムロジック注入

Heavy middlewareをわざわざ展開してトークン解析やペイロード書き換えを行う必要はありません。ルーティングロジックをWebAssemblyにコンパイルすることで、ネットワークエッジでほぼ遅延ゼロのカスタムプロキシ関数を実行可能です。2026年にはエコシステムも成熟し、本番環境での利用が現実的になっています。

現代のクラウドネイティブアーキテクチャでは、ネットワークエッジは単なる入口ポイントから、知的で高度にプログラム可能な境界へと変貌しています。長年、プラットフォームエンジニアは次のようなジレンマに直面してきました：リクエストがAPIゲートウェイやリバースプロキシに到達したとき、カスタムビジネスロジックはどこに置くべきか？従来、独自のトークン検証やPIIの除去、複雑なコンテキストに基づくルーティングを実装するには、二つの選択肢しかありませんでした。C++やGoで書かれたプロキシのソースコードをフォークしてカスタムビルドを維持するか、別のミドルウェアマイクロサービスを展開して、トラフィックを最終宛先にルーティングする前にネットワークホップを挟むかです。

どちらもコストが高くつきます。Envoyのようなプロジェクトをフォークすると技術的負債やアップグレードの難しさが増大します。外部ミドルウェアの展開はネットワーク遅延を招き、障害の表面積を増やし、展開の複雑さを増します。

そこでWebAssembly (Wasm)の登場です。カスタムロジックをWebAssemblyにコンパイルし、それをエッジプロキシに直接注入することで、プラットフォームエンジニアはトラフィックの取り扱い方を根本的に変えつつあります。このパラダイムは、Wasm-powered edge proxiesと呼ばれ、開発者はセキュアでほぼネイティブ速度のコードを、プロキシのコアコードに触れることなく実行できるようになっています。

---

Wasm-Powered Edge Proxiesとは？

WebAssemblyは、もともとWebブラウザ向けの高性能アプリケーション用に設計されたスタックベースの仮想マシン用バイナリ命令フォーマットです。Rust、C++、Go、AssemblyScriptなどの言語に対するポータブルなコンパイルターゲットです。サーバーサイドのネットワーキングに適用すると、Wasmはエッジコンピュートのためのユニバーサルプラグインシステムとして機能します。

ヘッダーの変更やトークンの検証、データの変換などを行うために、個別のマイクロサービスを維持する代わりに、開発者は好きな言語でロジックを書き、それを.wasmバイナリにコンパイルします。そのバイナリは、Envoyのような最新のリバースプロキシに直接注入されます。Wasmは安全な隔離サンドボックス内で動作するため、プロキシは安全にカスタムコードを実行可能です。もしWasmプラグインがクラッシュしても、プロキシ自体には影響しません。サンドボックスは破棄され、そのリクエストに対しては500エラーが返され、他の接続処理は継続されます。

これにより、リバースプロキシは高度に拡張可能なWasm APIゲートウェイとなり、パケットがネットワークエッジに到達した瞬間に、計算負荷の高いタスクを実行できます。

Proxy-Wasm ABI

このアーキテクチャの推進力となるのがProxy-Wasm Application Binary Interface (ABI)です。Proxy-Wasm以前は、プロキシ用のプラグインを書くには、その特定のプロキシの内部APIに密接に結びついたコードを書く必要がありました。Proxy-Wasmは、プロキシとWasm仮想マシン間の標準化されたインターフェースを定義しています。これにより、HTTPヘッダーやペイロード、接続メタデータの渡し方、そしてWasmモジュールに対してプロキシがどう動作させるか（リクエストをブロック、ヘッダー追加、アップストリームへのルーティングなど）を規定しています。

現在推奨されているABIのバージョンはv0.2.1で、Envoy、Istio、MOSN、Higress、API7などがこれを実装しています。v0.2.1に準拠したProxy-Wasmプラグインは、理論上、同じABIを実装する任意のプロキシ上で動作可能です。

この仕様の歴史について正直に述べると、Proxy-Wasm ABIはEnvoyやIstioで長年活発に使われてきましたが、十分な公式ドキュメントはありませんでした。2023年中頃、仕様リポジトリのメンテナはこれを公に認め、v0.2.1の正式なドキュメント化に取り組み始めました。このドキュメント化作業は2024年、2025年と続き、2025年10月には活発なコミットが行われています。ABI自体は実務上安定しており、プロダクション展開において大きな変更はありませんが、SDKやランタイムのアップグレード時には、ホスト側の期待と異なるABIバージョンのエラー（WASM missing Proxy-Wasm ABI version）が発生する可能性があります。

---

なぜWasmは従来のミドルウェアに取って代わるのか

1. ネットワーク遅延の排除

従来のマイクロサービスアーキテクチャでは、着信リクエストはアウトオブプロセスのHTTPやgRPC呼び出しをトリガーします。プロキシはリクエストを受け取り、一時停止し、ヘッダーを”AuthZ”サービスに送信し、応答を待ち、最終的にトラフィックをルーティングします。この内部ネットワークホップは高スループット時に大きな遅延を引き起こします。

EnvoyのWasm拡張では、ロジックはプロキシのメモリ内に存在します。Envoyのドキュメントによると、拡張はコントロールプレーンから直接ランタイムで配信・リロードでき、プロキシのバイナリを更新・再展開する必要はありません。カスタムロジックの実行はほぼ遅延ゼロで行われ、リクエストデータはWasm VMのメモリにマッピングされ、検証が行われ、即座にリクエストがルーティングされます。

2. 言語非依存性と開発者の生産性

プラットフォームチームはもはやC++の専門家を必要としません。セキュリティエンジニアはRustでレートリミットのアルゴリズムを書き、アイデンティティチームはGo（TinyGo経由）でJWTパーサを書き、プラットフォームチームはAssemblyScriptでヘッダー操作ロジックを書けます。

今日のProxy-Wasm開発の主なツールチェーンは:

• Rust — proxy-wasm-rust-sdk と wasm32-wasip1ターゲット（2024年3月にwasm32-wasiから改名）。最も成熟したパスです。
• Go — proxy-wasm-go-sdk（TinyGo必須）。標準Goはこの用途に対して未完成のWASIサポートのため、TinyGoに依存します。
• C++ — Clang/LLVMベースのWASI SDKを使用。

コンパイル済みのWasmモジュールは、コンテナイメージのように配布されます。OCI準拠のレジストリを使って、チームはWasmモジュールをプッシュ・プルし、既存のCI/CDパイプラインに統合できます。

3. 隔離とセキュリティ

WasmモジュールはホストOSのファイルシステムやネットワークプリミティブ、メモリにアクセスできません。クラッシュやメモリリークがあれば、VMはサンドボックスを終了します。Proxy-Wasm仕様では、ホストはクラッシュ率を追跡し、頻繁にクラッシュするプラグインのインスタンス化を制限でき、リソースを消費してクラッシュループに陥る攻撃を防ぎます。

これにより、ミッションクリティカルなネットワークコンポーネントへのカスタムロジック展開は、ネイティブ拡張よりもはるかに安全です。

---

Envoy内のWasmランタイム

Envoyは3つのWasmランタイム実装をサポートしています：V8、WAMR（Intel開発のWebAssembly Micro Runtime）、Wasmtimeです。Envoyの公式リリースイメージでは、V8がデフォルトで唯一のランタイムです。WAMRとWasmtimeはコードベースに存在しますが、公式ビルドには含まれていません。

Envoyのディストリビューションを超える環境では、例えばHigress（IstioとEnvoyを基盤とし、Alibaba Cloudで広く採用）では、WAMRへの関心が高まっています。HigressはWasmプラグインのランタイムをV8からWAMRに切り替え、AOTコンパイルを有効にしたところ、プラグインのパフォーマンスは平均50%向上し、複雑なロジックを持つプラグインでは2倍の速度になった例もあります。理由は、EnvoyのV8依存は2022年のバージョンに固定されており、新しいWasmGCなどの新機能を活用できないためです。一方、WAMRのAOTモードはターゲットプラットフォーム向けに機械コードを生成し、ネイティブバイナリに匹敵するパフォーマンスを実現します。

---

デプロイアーキテクチャ：EnvoyとIstio

Envoy

本番のKubernetesクラスタにおけるEnvoyのWasm拡張のライフサイクルは次の通りです：

1. 開発 — Rustでproxy-wasm-rust-sdkを使い、HttpContextトレイトを実装し、on_http_request_headersやon_http_response_bodyのコールバックを定義。
2. コンパイル — rustup target add wasm32-wasip1とcargo build --target wasm32-wasip1 --releaseでコンパクトな.wasmバイナリを生成。
3. 配布 — .wasmをOCI準拠のコンテナレジストリにプッシュ。
4. 設定 — Envoyのフィルタチェーン設定で、WasmモジュールのURIとランタイム（デフォルトはenvoy.wasm.runtime.v8）を指定。
5. インスタンス化 — Envoy起動や設定リロード時に、Wasmモジュールを取得・インスタンス化。
6. 実行 — HTTPリクエストはEnvoyのフィルタチェーンを通り、Wasmフィルタに到達。EnvoyはリクエストデータをWasm VMのメモリにマッピングし、プラグインが実行され、ヘッダーやボディを修正し、制御をEnvoyに返します。

IstioのWasmPlugin CRD

サービスメッシュ内では、Istioはextensions.istio.io/v1alpha1 APIグループのWasmPluginカスタムリソース定義を提供しています。これはIstio 1.12で導入されました。WasmPlugin CRDは、Envoyのフィルタチェーン設定の抽象化を行い、ワークロードセレクターやKubernetes Gateway APIのtargetRefsフィールドを使ったターゲティングをサポートします。これにより、Ambient Mesh展開のwaypointプロキシも対象にできます。

最小構成のWasmPluginリソース例:

apiVersion: extensions.istio.io/v1alpha1
kind: WasmPlugin
metadata:
  name: basic-auth
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  url: oci://ghcr.io/istio-ecosystem/wasm-extensions/basic_auth:1.12.0
  phase: AUTHN
  pluginConfig:
    basic_auth_rules:
      - prefix: "/api"
        request_methods: ["GET", "POST"]
        credentials:
          - "dXNlcjpwYXNz"

IstioエージェントはWasmPlugin設定を解釈し、OCIレジストリからWasmモジュールをダウンロード、Envoyサイドカー（またはAmbientのwaypointプロキシ）にHTTPフィルタを挿入します。モジュールの整合性は、sha256ハッシュを指定することで保証できます。

---

変革的なユースケース

高度な認証と認可

標準のAPIゲートウェイはJWTをJWKSエンドポイント経由で検証しますが、Wasmはより高度な認証ロジックを可能にします。独自のレガシートークンフォーマット、多段階の暗号検証、企業固有のHMACスキームなど、内部認証サービスへの往復を必要としない処理を実現します。Wasmプラグインはリクエストをインターセプトし、暗号計算をローカルで行い、エッジで接続を切断するか、ダウンストリームに渡します。悪意のあるトラフィックやDDoS攻撃も内部サービスには到達しません。

動的ペイロード変換とデータマスキング

WasmプラグインはアウトバウンドのHTTPレスポンスボディをインターセプトし、DLP（Data Loss Prevention）を行うことも可能です。Rustのメモリ安全な文字列処理を利用し、ペイロード内のPII（クレジットカード番号や社会保障番号など）をマスクまたは除去し、Content-Lengthヘッダーを再計算します。これにより、既存のレガシーアプリケーションの動作を変更せずにコンプライアンスを確保できます。

コンテキストに基づくルーティング

WasmはURLパスやHTTPヘッダーを超えたルーティング決定を可能にします。例えば、GraphQLクエリの抽象構文木を解析し、要求されたフィールドを所有するアップストリームサービスを特定、動的にアップストリームの選択を書き換えることもできます。マルチテナントSaaSでは、プラグインがプロキシ内のサイドバンド接続を通じてデータベースシャードのルーティングをローカルにルックアップし、一貫したテナント分離を実現します。

オーダーメイドWebアプリケーションファイアウォール

商用WAFはアプリケーションレベルのビジネスロジック攻撃に苦戦します。Wasmは、パラメータの速度監視やAPI乱用パターンのレートリミット、リクエスト形状のインバリアントを実装するプラグインを作成可能です。これらは一般的なWAFでは実現できない高度な検知を可能にします。

---

2026年のエコシステムの現状

WebAssembly 3.0

2025年9月17日、WebAssembly W3CコミュニティグループとワーキンググループはWebAssembly 3.0のリリースを発表しました。これは従来の2.0よりも大規模なアップデートで、多くの新機能が6〜8年にわたり開発されてきました。主な追加機能は:

• 64ビットアドレス空間 (memory64) — メモリとテーブルがi64アドレスタイプを使用可能に。理論上のアドレス空間は4GBから16EBに拡大。
• WasmGC — ネイティブのガーベジコレクションサポート。Java、Kotlin、Scala、Dartなどの言語は、フルGCランタイムをバンドルせずにWasmにコンパイル可能に。モジュールサイズが大幅に削減。
• 例外処理 — 構造化例外伝搬の標準化。
• テールコール — 再帰的な言語実装のための適切なテールコール最適化。
• 128ビットSIMD — 高度計算負荷のあるワークロード向けのベクトル演算。

プロキシやエッジプラグインの観点では、64ビットメモリ拡張と、RustやC++を使わないチーム向けの言語サポートの向上が最も重要です。

WASI 0.2とコンポーネントモデル

WASI 0.2（WASIp2またはPreview 2）は、2024年1月25日にBytecode Allianceによってリリースされました。これにはWebAssemblyコンポーネントモデルとWIT (WebAssembly Interface Types)が導入され、wasi:httpやwasi:socketsを通じたネットワーク機能が追加されました。WASI 0.2は2026年の安定した本番ターゲットです。Wasmtimeは、コンポーネントモデルとWASI 0.2 APIのフルサポートを最初に実現した主要ランタイムです。

コンポーネントモデルは、複数のWasmモジュール（異なる言語で書かれたものも含む）をリンクし、型付きのWITインターフェースを通じて通信できる仕組みです。ゲートウェイの文脈では、GoのJWT認証コンポーネント、Rustのレートリミッター、Pythonのデータ変換器を、ネットワークオーバーヘッドなしで一つのWasmランタイム内で構成できます。

WASI 0.3とネイティブの非同期

WASI 0.3.0は2026年2月にリリースされ、Wasmtime 37+でプレビューサポートが利用可能です。主な新機能はネイティブの非同期I/Oで、stream<T>やfuture<T>といった型を使い、明示的なstreamとfutureをサポートします。これにより、従来のpoll()を使った手動管理から解放され、I/O負荷の高いワークロードのコーディングが容易になります。WASI 1.0は2026年を目標としています。

実運用のエッジプラットフォーム

Proxy-Wasmプラグインだけでなく、Cloudflare Workers、Fastly Compute、Vercel Edge Functions、Fermyon Spinなど、多くのエッジネイティブプラットフォームが数十億リクエストを処理しています。Cloudflare Workersは世界330都市以上で稼働し、V8 isolatesによるミリ秒単位のコールドスタートとwasm32-wasip2による広範な言語サポートを提供しています。Fastlyは事前コンパイルによりほぼゼロ遅延でWasmを実行し、FermyonはAkamaiに買収され、世界中の4,000以上のロケーションでサーバーレスWasm関数を運用しています。

サーバーサイドやインプロセスのプラグインについても、ツールや観測性の向上が著しいです。開発者はローカルのWasmホストシミュレータを使い、RustやGoのプラグインコードをデプロイ前にデバッガで検証可能です。WasmプラグインはEnvoyのテレメトリストリームにカスタムメトリクスやトレース、構造化ログを直接出力でき、現代の観測性スタックにおいても重要な役割を果たします。

---

正直なトレードオフ

Wasmを用いたプロキシには制約も存在し、それを認識した上での設計が必要です。

ABIの断片化問題。 Proxy-Wasm v0.2.1は事実上の標準ですが、EnvoyやMOSN、API7などの実装間での互換性にはABIサポートの確認が必要です。wasm32-wasip2のコンポーネントモデルターゲットやWITインターフェースは、より堅牢なクロスホストの移植性を目指していますが、エコシステムの採用はまだ成熟段階です。

スケール時のメモリオーバーヘッド。 各Wasm VMインスタンスは独立したメモリブロックを必要とします。数千のインスタンスを運用すると、共有ランタイムに比べて総メモリ消費が増加します。コストはコンテナに比べて低いものの、ゼロではなく、大規模展開では注意が必要です。

Proxy-Wasmの同期I/O。 Proxy-Wasm ABIは同期的に設計されています。外部呼び出し（例：Redisサイドバンドやマルチテナントルーティング）にはdispatch_http_callを使い、コールバックモデルを実装する必要があります。これによりアーキテクチャの複雑さが増します。WASI 0.3のネイティブ非同期はプラットフォームの改善ですが、Proxy-Wasmのフィルタ実行モデル自体には直接影響しません。

デバッグの難しさ。 本番環境のEnvoy内でプラグインをデバッグするには、istioctl proxy-config wasmやEnvoyの管理API(/logging?wasm=debug)を使った詳細なログ設定と、構造化ログの相関が必要です。2021年と比べると改善されていますが、GoやRustのネイティブサービスのデバッグよりは手間がかかります。

---

結論

WebAssemblyリバースプロキシプラグインへの移行は、ネットワーク境界におけるカスタムロジックの提供方法を根本的に変えつつあります。認証、変換、ルーティングのロジックをWasmにコンパイルし、プロキシのプロセス空間に注入することで、低遅延、強力な障害隔離、開発者の生産性向上を実現します。これにより、プロキシコードのフォークやマイクロサービスの追加展開は不要です。

基盤となる標準は今や確固たるものとなっています。Proxy-Wasm ABI v0.2.1は、Wasm拡張をサポートする主要なプロキシで採用されている本番仕様です。WebAssembly 3.0は2025年9月に正式に標準化され、WASI 0.2はコンポーネントモデルと型付きモジュール連携を提供しています。2026年2月にリリースされたWASI 0.3.0は、サーバーサイドのI/O負荷の高いワークロードにおける非同期処理のギャップを埋めました。

実用面では、ルーティングや認証、変換ロジックをWasmにコンパイルすることはもはや実験ではありません。ツールチェーンは成熟し、ランタイムは安定し、観測性も追いついています。エッジプロキシを通るトラフィックがあるなら、Wasmを使う選択はもはや技術的なトレードオフではなく、正当な選択肢です。

---

更新履歴

以下は元のドラフトに対して行った事実修正と追記です：

#	元の記述	修正 / 追記
1	“Proxy-Wasm仕様のコアコンポーネントは高い安定性に達した”	正確には、ABI v0.2.1が事実上の標準であり、安定して広く実装されています。ただし、正式なドキュメント化は2023-2024年の努力によって進行中です。vNEXT ABIは未完全です。バージョン不一致エラーは運用上の課題です。出典：proxy-wasm/spec GitHub issues #38, #41; Envoy公式ドキュメント。
2	Envoyは”V8, Wasmtime, WAMR”を使用	正確には、V8はEnvoyの公式リリースイメージでデフォルトかつ唯一のランタイムです。WAMRとWasmtimeはコードベースに存在しますが、公式ビルドには含まれていません。出典：Envoy公式ドキュメント; GitHub issue #29827。
3	コンパイルターゲットはwasm32-wasi	正確には、Rustコンパイラでのターゲットは2024年3月にwasm32-wasiからwasm32-wasip1に改名されました。コンポーネントモデルのターゲットはwasm32-wasip2です。出典：Rustの公式ドキュメント。
4	Goのproxy-wasmプラグインはネイティブGo	明確化：proxy-wasm-go-sdkはTinyGoを使用し、標準Goは未完成のWASIサポートのために依存しています。出典：WasmEdgeドキュメント; wasm-nginx-moduleのドキュメント。
5	Proxy-Wasmの実運用移行は完了	補足：v0.2.1は本番グレードです。仕様リポジトリは活発ですが、未解決の課題（タイマーサポート、ヘッダーマップのマルチバリュー、KVSのキー存在確認）もあります。実情を正確に記述。
6	WebAssembly 3.0の状況	追記：WebAssembly 3.0は2025年9月17日にW3Cのライブ標準として正式リリースされ、WasmGC、例外処理、テールコール、64ビットメモリ、128ビットSIMDなど、多くの新機能を標準化しました。出典：webassembly.org/news/2025-09-17-wasm-3.0/。
7	WASIとコンポーネントモデルの説明	具体的なタイムラインを追加：WASI 0.2.0は2024年1月25日にリリース（コンポーネントモデル、WIT、ネットワーキング）。WASI 0.3.0は2026年2月にリリース（ネイティブの非同期I/O、stream<T>とfuture<T>型、Wasmtime 37+で利用可能）。WASI 1.0は2026年を目標。出典：wasi.dev/roadmap; bytecodealliance; devtoollab.com。
8	エッジプラットフォームの文脈不在	追加：Cloudflare Workers、Fastly Compute、Vercel Edge Functions、Fermyon Spinなどの実運用例を紹介。
9	トレードオフの議論未掲載	追加：ABIの断片化、インスタンスごとのメモリオーバーヘッド、同期I/Oの制約、デバッグの難しさについて詳述。
10	IstioのWasmPlugin CRDのAPIバージョン	確認：extensions.istio.io/v1alpha1。Ambient MeshやwaypointプロキシのターゲティングにはtargetRefsも利用可能。出典：istio.io公式ドキュメント。