WebAssemblyがログイン不要の無料ブラウザツールを進化させている理由

Squoosh がデスクトップアプリに匹敵するコーデックで画像を圧縮できる理由は、サーバーのパワーとは何の関係もありません。圧縮はブラウザのタブ内で完全に行われ、WebAssemblyという技術が支えています。アップロード不要、アカウント不要、リモートサーバーが処理して返送するのを待つ必要もありません。

これは「無料ブラウザツール」の意味を変えます。多くのツールにとって。

WebAssemblyとは何か

WebAssembly（略称：Wasm）は、JavaScriptよりもネイティブコードにはるかに近い速度でブラウザ内で動作するバイナリ命令形式です。WebAssembly仕様は2019年12月にW3C標準になりましたが、ブラウザサポートはそれ以前から始まっていました——Chrome 57・Firefox 52・Safari 11・Edge 16がすべて2017年にWasmサポートを搭載しました。

重要なのは、WasmはプログラミングLanguageではないということです。コンパイルターゲットです。C・C++・Rust・Goでコードを書き、.wasmバイナリにコンパイルして、ブラウザに送ります。ブラウザはそれを直接実行します——JavaScriptを解釈することもサーバーに接続することもなく。

パフォーマンスの差は現実です。ベンチマークではWasmが同等のネイティブコードより10〜20%遅いことが一貫して示されています——大きく聞こえますが、JavaScriptとの比較では話が変わります。特定の操作ではJavaScriptはネイティブより5〜10倍遅いのです。計算負荷の高い処理（画像エンコーディング・オーディオ処理・暗号化・データベースクエリ）では、Wasmはブラウザでできることとデスクトップアプリでできることのギャップを縮めます。

2022年に導入されたWebAssembly SIMD（Single Instruction Multiple Data）命令がこのギャップをさらに縮めました。SIMDによりWasmはCPUのベクタ演算を並列データ処理に使えます——デスクトップ画像ツールを高速にするのと同じ最適化です。Squooshはブラウザがサポートする場合にSIMDを使い、対応していない場合は自然にフォールバックします。

なぜこれが登録不要ツールにとって重要なのか

業界がはっきりと言葉にするのに時間がかかった関係がここにあります。サーバーサイドの処理は、ユーザーアカウントを必要とする主な正当化の一つです。

ツールがサーバー上でファイルを処理する場合、サービスは誰に何が属するかを追跡する必要があります。セッション管理・ファイルストレージ・ジョブキュー——これらはすべて身元を必要とします。そして身元はアカウント・メール・パスワードを意味します。

計算がブラウザに移ると、その依存関係が消えます。ファイルはあなたのマシンを離れません。追跡すべきジョブがなく、使用量に比例したサーバーコストもなく、リクエストをなんらかの身元と関連付ける必要もありません。

「ブラウザがOSだ」はシリコンバレーの常套句でした。WebAssemblyで、それはブラウザが実際に何を計算できるかについての文字通りの言明になりつつあります。

Wasmで構築されたツールは、本当にあなたが誰であるかを知る必要がないため、真のログイン不要・登録不要の体験を提供できます。計算はあなたのハードウェア上で、あなたのブラウザ内で、あなたのCPUが処理します。開発者のサーバーは静的ファイルを提供しているだけです。それだけです。

既にこれを使っているツール——宣伝していないだけで

以下のほとんどのツールはホームページで「WebAssembly搭載」とは一言も書いていません。DevToolsのネットワークタブで見てはじめてわかります——.wasmファイルが証拠です。しかし個別に理解する価値があります。それぞれが、サーバーからブラウザに移行した異なるカテゴリの作業を示しているからです。

Squoosh は最も目に見えるケースです。GoogleはWasmが画像圧縮で何ができるかを示すために特別に構築しました。開いて画像をドロップすると、MozJPEG・OxiPNG・WebP・AVIF・JPEG XLでエンコードできます——すべてローカルで実行されます。これらはC/C++ライブラリをWasmにコンパイルしたもので、タブの中で動きます。デスクトップ写真アプリが使うのと同じコーデックです。GIMPとエクスポートプラグインで同等の設定をするには完全なインストールと設定が必要です。Squooshは何も必要としません。

hat.sh はlibsodium——十分に審査された暗号化Cライブラリ——をWebAssemblyにコンパイルしたもので、ファイルを暗号化・復号します。ファイルがどのサーバーにも届くことはありません。hat.shで何かを暗号化すると、その操作はブラウザのタブのメモリ内で行われ、暗号化された出力だけがディスクに保存されます。これが暗号化ツールの正しいアーキテクチャです。暗号化のために暗号化されていないファイルをリモートサーバーに送ることは本末転倒です。

AudioMass はアカウントもインストールも不要のフル波形オーディオエディタで、マルチトラック編集ができます。オーディオ処理は本当に計算負荷が高く——フィルタリング・ピッチシフト・フォーマット変換にはすべて実際の処理が必要です。これがブラウザのタブで許容できる速度で動くのはWasm対応のパフォーマンスの直接の結果です。数年前、「オンラインオーディオエディタ」はファイルをアップロードして待つことを意味しました。今はローカルで処理することを意味します。

Datasette Lite はこれをさらに進めています。ブラウザ内でWebAssemblyにコンパイルされた完全なSQLiteデータベースエンジンを動かします。CSVやSQLiteファイルを読み込んで、サーバーに何も触れさせずにリアルなSQLクエリを実行できます。これはかつてデスクトップデータベースクライアントか、アカウント付きのクラウドデータベースサービスのどちらかが必要でした。今はブラウザのタブです。

重要な比較

これらのツールのパターンは一貫しています：

サーバーサイド処理はアカウントを必要とする理由を作り出します。ブラウザサイドのWasm処理はその理由を取り除きます。上の表は完全なリストではなく、方向性です。

よく見落とされるプライバシーの側面

Wasmベースのツールには、純粋なJavaScriptツールにはしばしばない特定のプライバシー特性があります。重い計算がサンドボックス環境内で行われ、ネットワーク境界を越える副作用がありません。

WebAssemblyに関するMDN Web Docsの解説はセキュリティモデルを明確に説明しています。WasmモジュールはJavaScriptと同じサンドボックス内で動作し、追加の権限はありません。独立してネットワークリクエストを発行することも、任意のファイルを読むことも、明示的なJavaScriptの仲介なしにハードウェアにアクセスすることもできません。

これはプライバシーに敏感なツールのユーザーにとって重要です。hat.shがファイルを暗号化するとき、Wasmモジュールは物理的にそのファイルをネットワーク越しに送ることができません——モジュール自体にネットワークアクセスがないのです。JavaScriptが明示的にアップロードする必要があります。オープンソースのツールはそれが起きていないことを監査できます。ソースコードが公開されているからです。

「サーバーで全て処理しています、ログは保持しません」がポリシーの言明にすぎない——データについて商業的な利害関係を持つ企業を信頼するだけ——ツールと比較してみてください。

CyberChef——GCHQが構築したエンコーディング・デコーディング・暗号操作用のブラウザツール——は今日の状況を示す良い例です。base64・AES・SHAハッシュ・バイナリ解析・データフォーマット変換など数百の操作を、サーバーの関与なしに処理します。これらはかつてアカウントシステムを付随した専用のバックエンドインフラを正当化する操作でした。

登録不要。ログイン不要。アップロード不要。

Wasmがまだできないこと

WebAssemblyには実際の制限があります。直接のDOMアクセスはありません——WasmとJavaScriptはまだブリッジ経由でやりとりしており、UIが多い操作ではオーバーヘッドが増えます。ファイルシステムアクセスはブラウザのFile System Access APIが許可する範囲に限られており、ローカルファイルの読み書きはできますが、任意のシステムレベルの操作はできません。真に大規模な操作（大きなデータセットでのMLモデル学習、数百GBのデータ処理）では、クライアントサイドの計算は実際のメモリ制限に当たります。

Wasmにはガベージコレクションが歴史的に組み込まれていませんでした——もっとも、2023年にPhase 4に到達したWebAssembly GCプロポーザルがKotlinやOCamlなどの言語に対してこれを変えました。スレッドサポートは存在します（WebAssembly Threads）が、すべてのホスト環境が提供するわけではない特定のHTTPレスポンスヘッダー（COOPとCOEP）が必要です。

これらの制限は現実ですが、縮小しています。WasmのツールチェインはC/C++向けのEmscripten・Rust向けのwasm-pack・Go向けのTinyGoとも活発なコミュニティと良いドキュメントで、2年前より成熟しています。「ブラウザには計算負荷が高すぎる」の境界は動き続けています。

ログイン不要ツールのカテゴリに実際に何が起きているか

Photopea はアカウントなしにPSD・XCF・Sketchファイルを扱えます。このような解析——複雑なバイナリファイル形式の読み込み・レイヤー合成・色空間管理——はかつてサーバー経由でファイルをルーティングする理由でした。今はブラウザのタブで動きます。PhotoshopのサブスクリプションとAdobeアカウントが必要なウェブアプリとは異なり、Photopea は即座に読み込まれ、無料で、登録不要です。

かつての制約は：ブラウザツールが本格的な計算能力を必要とするなら、サーバーに依頼しなければならないというものでした。Wasmはその制約を打ち破ります。制約が破れると、より広いツール群に対して「使うにはアカウントが必要」という正当化が弱くなります。

これはすべてのツールがログイン不要の無料ブラウザツールになることを意味しません。アプリケーションによっては永続的なサーバーサイドの状態が本当に必要なものがあります——デバイス間のリアルタイムコラボレーション・クラウド同期・GPUクラスターが必要な大規模AIの推論。それらのニーズは本物です。しかし底上げが進んでいます。ブラウザのタブで、無料で、登録なしでうまくできるタスクのカテゴリは、2020年より広くなっています。

プライバシーを気にするユーザーにとって——特に世界中の議会でデータ収集に関する立法議論が続く中——これは正しい方向性です。計算があなたのデバイスで行われるためにデータを収集できないツールは、収集しないと約束するだけで技術的には収集できるツールとは意味が違います。

実際的な結論：アカウントが必要なツールとアカウント不要のブラウザベースの代替品を選ぶとき、ブラウザベースの選択肢が機能面で妥協を強いられる可能性は、5年前より低くなっています。多くのカテゴリでは、それがより良いツールです。Wasmが主な理由です。

登録不要の無料ブラウザツールはこれからも増え続けます。基盤となる技術は高速化し続け、開発者向けのツールチェインは使いやすくなり続けています。

ログイン不要・アカウント不要のツールを nologin.tools で見つけましょう。