「Webでも使われている」という言葉の中身を、ちゃんと見てみる
前の記事で、Rustが置き換えようとしているのはWindowsカーネルのような「一番下の層」であり、C#や.NETが住んでいる「アプリケーションの層」とは住み分けが進んでいる、という話を書いた。
ではWebの世界はどうなのか。「RustはWebでも使われている」という言葉は、ニュースやSNSでよく見かける。だが、これは一枚岩の話ではなかった。調べていくと、Webの中だけでも、Rustは少なくとも3つの、まったく性質の違う場所に顔を出していることが分かった。
顔1：サーバーの裏側で、Node.jsの代わりを狙う層
一つ目の顔は、いわゆる「バックエンド」の領域だ。これまでNode.jsやPython、Javaが担っていた、APIサーバーやWebサービスの裏側のロジックを、Rustで書こうという動きがある。
Axum、Actix Web、Rocketといったフレームワークがその代表だ。これらのフレームワークは、高負荷下やCPUを使う処理、厳しい遅延要件のもとでNodeのサービスがよく直面する限界に対応するもので、Rustの並行処理モデルと予測しやすいスループットが、パフォーマンスに敏感なバックエンドロジックに強みを発揮する。実際の採用企業を見ると、Cloudflare、Figma、Discord、Amazon、Dropboxといった企業が、パフォーマンスが重要なサービスやセキュリティに敏感な部分、インフラのツール群でRustを使っている。
ただ、これは「Node.jsを完全に置き換える」という話ではない。JS/TS開発者がRustのサーバーサイドの仕組みに移行しやすいよう、馴染みのあるパターンを採用しながら、より強い安全性の保証と予測しやすいパフォーマンスを提供するという立ち位置で、UIやアプリケーション層は今もJS/TSが担っているという説明がある。つまり、Webサービス全体をRustで作り替えるのではなく、重い処理だけをRustに任せ、画面側はそのままJavaScriptで作るという、部分的な使い分けが主流の形になっている。
顔2：ブラウザの中で動く、もう一つのWeb開発言語としての層
二つ目の顔は、もっと意外な場所にある。ブラウザの中で直接動くアプリケーションを、JavaScriptではなくRustで書くという動きだ。
これを実現しているのがWebAssembly（通称Wasm）という技術だ。Rustで書いたコードをWebAssemblyという形式に変換すると、ブラウザの中でJavaScriptと一緒に、ネイティブアプリに近い速度で動かせる。WebAssemblyの目標はJavaScriptを殺すことではなく、JavaScriptと並んで動き、処理の重い、あるいは低レベルな作業——Rustの得意とするパフォーマンスが活きる作業——を助けることだとRust公式サイトも説明している。
このために生まれたフレームワークが、LeptosやYew、Dioxusといった名前だ。Leptosは、Rustのメモリ安全性とパフォーマンスを活かしながら、Reactのような最新のJavaScriptフレームワークに匹敵する開発体験を提供する、フルスタックのRust Webフレームワークだ。実際に書くコードも、Reactの記法に近づけて作られている。
2024年のJetBrains開発者調査によれば、Rust開発者の35%が、すでにRustを使ったWeb開発の仕事をしていると回答している。これはCLIツール（44%）に次ぐ高さで、システムプログラミング（35%）と同率だ。Rustが「カーネルやドライバーだけの言語」という枠を超えて、Web開発者の現場にも入り込んでいることが分かる。
身近な実例も挙がっている。Figmaのようなブラウザベースのデザインツールは、ネイティブのインストールを必要とせずシームレスな体験を実現するためにWebAssemblyを採用している。Fastlyのようなクラウドコンピューティング企業は、エッジでのサーバーレス関数を超高速に実行するため、Compute@EdgeというサービスにWebAssemblyを組み込んでいる。
顔3：JavaScriptのツールの「中身」に隠れている層
三つ目の顔は、一番見えにくい。普段JavaScriptやNode.jsを使っている開発者が、知らないうちにRustの恩恵を受けている、というパターンだ。
これは「Rustで書かれたアプリを使う」のではなく、「JavaScriptのツールの内部実装が、いつの間にかRustに置き換わっている」という形を取る。VS Codeのウェブサイトの検索機能を例に挙げると、2026年、VS Codeチームはdocfindという、ブラウザの中で完全に動くWebAssemblyベースの検索エンジンを開発し、それまでサーバー側で行っていた検索処理を置き換えた。利用者からは、検索が速くなったとしか見えないが、その裏ではRustとWebAssemblyの組み合わせが動いている。
JavaScriptの世界でよく使われるビルドツールやリンター（コードの間違いを検出するツール）の中にも、内部のエンジン部分だけをRustに置き換えたものが増えている。表向きの使い方はこれまでと同じNode.jsのコマンドのままで、裏側だけが速くなる——これが三つ目の、最も静かな浸透の形だ。
まだ「ほぼ準備できている」段階のもの
ただし、Webの世界でのRust・WebAssemblyの広がりを、過大に見積もるのも正確ではない。
サーバーサイドでのWebAssembly活用については、まだ無視できない制約が残っている。WebAssemblyにはWASI上でのネイティブなマルチスレッディングがなく、データベースや高スループットの処理、本格的な並列計算を必要とするワークロードは、現状ほとんど対応できないという指摘がある。これは小さな欠点ではなく、サーバーサイドでWebAssemblyが現実的に動かせるプログラムの種類を、構造的に制限している。
また、2026年のWebAssemblyは、広く失敗しているわけではないが、広く成功しているわけでもなく、強みが活きてギャップが問題にならない、特定のニッチでこそ精密に成功している、という段階にあるという評価もある。エッジ関数やサーバーレスのFaaS、安全なプラグインシステムといった用途では実績があるが、「Webサービス全体をWebAssemblyで作る」という段階には、まだ届いていない。
つまり今のRust・WebAssemblyは、「もう何でも作れる、成熟した万能の選択肢」ではなく、「向いている場所では、すでに本番投入できる、伸び盛りの選択肢」という、もう少し慎重な言い方が正確だ。
では、necokoucan.comで使うとしたら、どこに向いているか
ここまでの3つの顔を踏まえると、戦史記事サイトのような既存のWordPressサイトにRustを導入するなら、どこから手をつけるのが自然かが見えてくる。
一番遠いのは、サイト全体をRustベースのフレームワーク（AxumやLeptosなど）でゼロから作り直す道だ。これはWordPressという既存の仕組みを丸ごと置き換えることになり、今ある艦艇データベースや記事生成の仕組みとの整合性を取り直す手間が大きい。
現実的に近いのは、特定の重い処理だけを、WebAssemblyとして切り出すやり方だ。たとえば、艦艇データの一覧表示で複雑なフィルタリングや並べ替えを行う処理、あるいは将来構想にある図面ビューア（一般配置図や側面図をブラウザ上でズーム・パンさせるような機能）は、JavaScriptで素朴に書くと重くなりやすい部分だ。こうした「ブラウザの中で、計算量の多い処理だけ」を、Rustで書いてWebAssemblyに変換し、既存のJavaScriptと組み合わせて呼び出す形であれば、WordPressのテーマやプラグインの構造を壊さずに、必要な場所だけをRustの恩恵で速くできる。
これは、前の記事で書いた「住み分け」の発想と同じだ。サイトの土台はそのまま、重い処理だけを部分的にRustへ預ける——Cloudflareや先述のVS Codeの例が示していたのも、まさにこの形だった。Webの世界でのRustの広がりは、全部を置き換える革命ではなく、向いている部分だけを静かに引き継いでいく、漸進的な広がり方をしている。