WebAssemblyはどこまで来たか――Photoshopの移植から、買い物かごの裏側まで

ブラウザ版Photoshopの筆には、どんなコードが入っているのか

写真を開き、ブラシを選んで線を引く。利用者にとっては一筆でも、開発者から見ると、ボタンを描くこと、ペンの位置を受け取ること、画素を書き換えることは別々の仕事です。デスクトップ版で何年も調整してきたブラシの動きを、Web版のためにもう一度書くとしたら、速さ以前に「同じ一筆」を再現するのが大変です。

AdobeとChromeの開発チームが紹介したPhotoshopの移植では、C++のコードをEmscriptenでWebAssembly（Wasm）にコンパイルし、Web側のUIなどと組み合わせました。既存の処理をブラウザにも届けられる。ここに、ベンチマークの数字だけでは見えにくいWasmの強みがあります。^[2]

そもそもWasmは、プログラミング言語のコンパイラが出力できる共通の命令形式です。開発者はC++やRustなどで処理を書き、配布用のモジュールを作ります。受け取ったブラウザや専用ランタイムがモジュールを検証して実行します。印刷なら、同じ版を別の印刷機に掛けるようなものです。紙の送り方まで版に刻む必要はありませんが、どの機械も必要な大きさの紙を扱えるとは限りません。

3.0になって、何が作りやすくなったか

2017年に主要ブラウザへ登場した当初の中心用途は、数値演算と連続したメモリ領域を使うプログラムでした。そこから機能が積み上がり、2025年9月にコア仕様3.0の完成が発表されました。現行世代を理解するには、版番号よりも「自分のコードが以前どこで困っていたか」を見る方が近道です。^[3]

従来の32ビットのアドレスで区別できる範囲は4 GiBです。Memory64で表現できる範囲が広がっても、スマートフォン上で巨大な画像を必ず開けるわけではありません。たとえば圧縮ファイルが小さくても、展開後の画素、編集前のコピー、取り消し履歴が同時にメモリに載ります。実際に使う端末で測る対象は、ファイルサイズより、この合計のピークです。ブラウザやランタイム別の実装状況は公式の機能表で調べられます。^[4]

速くなるのは、一筆のどの部分か

4000×3000画素の写真に、赤・緑・青・透明度の各1バイトを割り当てると、展開後のデータは48 MBです。入力と出力を別々に持てば計96 MB。これは仕様や実測値ではなく、サイズを見積もるための単純な掛け算です。一つの画像を変換するだけでも、計算本体のほかにコピーとメモリ確保の費用が見えてきます。

同じ明るさ補正でも、JavaScriptから画素ごとにWasm関数を呼ぶ設計なら、境界を1200万回通ります。画像全体をバッファーで渡せば、補正を一度の呼び出しにまとめられます。連続した画素に同じ演算を繰り返す部分は、複数の値を一命令で扱うSIMDの候補です。一方、ボタンを押したあと大半の時間を通信待ちに費やす画面では、その待ち時間は画素の計算を速くしても縮まりません。

評価するときは、初めてページを開いた端末でのダウンロードと初期化、二枚目以降の処理時間、画面に結果が出るまでの時間をそれぞれ記録します。メインスレッドで長い同期処理をすれば、Wasmでもボタンの反応は止まります。ワーカーに移すときには、処理が短くなるかに加えて、操作できる時間が増えたかを見ます。体感に効く変更が、最速のループと一致しないことがあります。

初回と二回目、利用者が待つのはいつか

実験用の画像を開くとき、開発者のパソコンにはコードも画像もすでに残っていることがあります。公開後の利用者が最初に見るのは、その状態とは限りません。旅行先で通信が細いとき、画面の表示だけはすぐ終わるのに、編集ボタンを押してから処理エンジンの取得が始まる。端末内の演算がいくら短くても、本人にとってはボタンを押してからプレビューが出るまでが一つの待ち時間です。

そこで計測表には「ページを開く」「操作できる」「プレビューが出る」「保存が終わる」の時刻を残します。最初の表示を早めるために読み込みを後ろへずらした場合も、この表なら待ち時間をどこに移したのかが分かります。取り消して別の画像に切り替えたとき、前の処理の結果が新しいプレビューを上書きしないことも確かめます。短いデモで見えにくいのは、変換そのものより、人が処理の途中で次の操作を始める瞬間です。

もう一つの比較対象は、手元に既にあるブラウザの機能です。単純な表示上の拡大や色調の変更であれば、その画面で必要なのは加工済みファイルなのか、見た目だけが変わった表示なのかを先に決めます。後者なら、全画素を取り出し、加工した画像を保存する設計自体を省ける場合があります。逆に加工結果を書き出し、別のアプリにも同じ結果を渡すなら、利用者に見えた色と保存されるデータの一致まで確かめる必要があります。

移植の費用にも時間軸があります。デスクトップとブラウザで画像の読み込み部分を共通化できれば、新しい形式に対応したときの修正やテストデータを共有できます。ただしコンパイラを更新した後に同じ画像が同じように読めるかは、両方の環境で確認する仕事として残ります。初回の開発工数に加え、一年後に不具合を修正して配り直すところまで想像すると、「一度書けばどこでも」のうち、実際に一度で済む部分が見えてきます。

SQLiteとShopifyでは、同じ技術が違う仕事をする

SQLiteのブラウザ版では、SQLを解釈し実行する既存エンジンを端末内で使えます。たとえば持ち歩く資料集に索引を作り、電波の弱い場所でも検索する設計が可能です。ここで初めて「検索できる」と「タブを閉じた翌日にもデータがある」という二つの要件が分かれます。SQLiteの公式文書には、サイト専用の保存領域OPFSを使う選択肢と、保存方式ごとのワーカー・同時アクセスの条件が載っています。シークレット閲覧時の容量や永続性もブラウザ次第です。^[5]

Shopify Functionsでは、買い物かごの中身などを入力として受け、割引などの処理結果を返す拡張をShopify側で実行します。店舗ごとに異なるルールを持ち込めても、価格への反映はプラットフォームが管理できます。この場合の価値は、大量の画素を速く計算することよりも、「入力と出力が決まった場所に、他者のプログラムを組み込める」ことです。利用可能な機能や配布方法にはプランによる違いがあります。^[6]

両者に共通するのはホストの役割です。Wasmの命令だけではタブにファイル選択画面を出したり、注文を変更したりできません。実行環境がどの機能を渡し、戻り値を何に使うかを決めます。サンドボックスの設計でもここが重要です。意図しないメモリアクセスを抑える仕組みと、アプリが渡した顧客情報をプログラムが正しく扱うことは別々に検討します。

ブラウザを出たWasmとWASI 0.3

サーバーで同じモジュールを動かそうとすると、時計やファイル、通信にどう触れるかという問題が出てきます。WASIはホストが提供するこうした機能のインターフェースを定めます。コア仕様3.0と、2026年6月に発表されたWASI 0.3は、名前は似ていても別の仕様です。一方は実行する命令と型、もう一方はプログラムが外の世界と仕事をする約束を扱います。^[7]

コンポーネントモデルでは、別々の言語で作った部品の間で、文字列やレコードなどを型の付いた契約として受け渡せます。WASI 0.3で大きいのは非同期処理です。たとえばHTTPの応答本文を少しずつ受け取り、次の部品が届いた分から加工する構成を、ストリームとして記述できます。応答全体をメモリに貯める設計を避けられる一方で、受け手が遅い場合や途中で中断した場合の扱いは設計に残ります。^[7]

移植の単位は「言語がWasmに対応している」という宣伝文句より小さく見積もるのが現実的です。変換ロジックを移せても、GUIやクラウド固有の認証に依存する部分には別の接続が必要です。必要なインターフェースを列挙し、二つのホストが同じ版を実装するかを確かめると、どのコードを共通化できるか具体的になります。

普及の数字から、これからをどう読むか

HTTP Archiveの2025年版Web Almanacでは、調査したデスクトップサイトの0.35%、モバイルサイトの0.28%でWasmが観測されました。これはWeb全体の処理量でも利用者の割合でもありません。ログイン後に初めて開く編集画面や、サーバー内部の割引関数は、外からページを読み込む調査には映りにくいからです。Wasmは一般サイトに一様に入る技術なのか、特定の重い機能に集中する技術なのか。数字を読むときの分母が変わります。^[8]

今後数年で広がりやすいと考えるのは、既存のエンジンを端末へ運ぶ用途です。 文書検索や画像変換なら、入力を外部サーバーに送らずに済むこと自体に価値があります。反対に、初回のダウンロードが大きく、年に一度しか使わない機能なら、利用者が待てる時間を超えるかもしれません。予測を確かめる指標は、対応言語の数より、低価格端末でも使える機能が実際に出荷されるかです。

サーバー側では、拡張機能の配布が次の候補です。 入出力を狭く定義できる変換器や業務ルールなら、ホスト側を更新するたびにすべての拡張を書き直す負担を減らせます。ただし、非同期I/Oの仕様が整うことと、障害発生時にどの部品で詰まったか担当者が追えることには距離があります。複数ランタイムに同じ部品を配布でき、エラー、遅延、権限まで追跡できる事例が増えるかを見たいところです。これは普及を約束するロードマップではなく、2026年11月時点の見通しです。

すでに端末へ移った検索――VS Codeのドキュメント

この予測の足元にある実例が、VS Codeのサイト内検索です。開発チームは2026年1月、RustとWasmで作ったdocfindの仕組みを公開しました。文書が増えるたびに利用者の端末で全文を読み直すのでは時間が掛かります。そこでサイトのビルド時に文書から索引を作り、検索に必要なデータを含むWasmモジュールを配信します。利用者が文字を入力した時点では、索引を作る仕事はすでに終わっています。^[1]

この例で面白いのは、検索する場所を決めると、更新の仕方まで変わる点です。サーバーへの問い合わせを毎回行う設計なら、公開直後の訂正をサーバーの索引に反映すれば、その後の検索に届きます。索引を端末に配る設計では、どの版を取得したかが検索結果を左右します。新しい用語を公開したのに古い索引には載っていない、という食い違いをどう解消するか。小さなサイト内検索でも、配布物の版とキャッシュの更新方針が設計の一部になります。

また、資料を端末で扱えることと、どんな資料でも端末へ渡してよいことは違います。一般公開のマニュアルや用語集なら、索引をダウンロードできても公開範囲は変わりません。部署ごとに閲覧範囲の違う社内文書なら、検索候補だけで文書名を推測できる場合があります。閲覧者に渡せる範囲で索引を分けるか、アクセス判定が必要な検索をサーバーに残すか。こうした条件は、Rustで書くかJavaScriptで書くかを決める前に確かめられます。

導入を決める小さな比較実験

写真補正を例に、自分のアプリでWasmを使う価値を調べるなら、最初から二種類のアプリを作る必要はありません。入力画像と期待する出力画像を一組用意し、補正する関数だけを交換できるようにします。出力の丸め方や端の画素の扱いが異なると、速かった側が処理を一部省いていたということもあります。速さを比較する前に、結果が同じか、許容する差が決まっているかをテストにしておきます。

次に小さなサムネイルと原寸写真を混ぜます。サムネイルでは変換に掛かる時間より関数の準備が支配的で、原寸では逆転するかもしれません。一枚ずつ別のページで開く利用者と、何十枚も続けて処理する利用者を同じ平均値にまとめると、誰が得をするか分からなくなります。処理を何回使う人が多いかが分かれば、初期化をいつ行えばよいか、ページを開いた瞬間にダウンロードする必要があるかも判断できます。

最後に、完了した仕事に対して採否を決めます。目的が「電波のない場所でも最後まで編集できる」なら、サーバー版より変換時間が多少長くても価値があります。目的が「既存の管理画面で一つの数値を表示する」だけなら、依存ツールや配布物が増える費用が効いてきます。速度、再利用、端末内で完結すること、権限を限定した拡張。この四つのうちどれを得たいのかを決めると、同じWasmでも選ぶ理由が具体的になります。

参考文献・出典

1. [1]VS Code開発チーム・docfindの設計と配布 ↩
2. [2]Adobe・Chrome開発チームによるPhotoshop移植の解説 ↩
3. [3]WebAssembly公式・Wasm 3.0 Completed ↩
4. [4]WebAssembly公式・実行環境ごとの機能表 ↩
5. [5]SQLite公式・ブラウザでの永続化方式 ↩
6. [6]Shopify Functionsの仕組み ↩
7. [7]Bytecode Alliance・WASI 0.3の発表 ↩
8. [8]HTTP Archive・2025 Web AlmanacのWebAssembly調査 ↩