基礎編 #02：なぜJavaScriptやPythonではなく、あえて難解な「Rust」を選ぶのか？
Web開発や自動化を始めるなら、JavaScriptやPythonは非常に有力な選択肢です。情報量が多く、試作が速く、AIにもコードを書かせやすい。小さなツールや業務自動化を早く形にする目的なら、まずこの2言語から考えるのは自然です。
それでも、24時間動かし続ける常駐処理、限られたVPS資源で動かす収集基盤、WebAssemblyへ展開する処理の中核などでは、Rustが強い候補になります。
理由は「Rustなら絶対に落ちない」からではありません。Rustは、メモリの扱い、データの所有関係、並行処理で起きやすい危険を、実行前のコンパイル段階で多く検出できるよう設計されています。さらに、ガベージコレクターを前提とせず、ネイティブコードやWebAssemblyへコンパイルできるため、実行環境の構成を小さくしやすいという特徴があります。
この記事では、JavaScriptやPythonを否定せず、それぞれの得意分野を整理したうえで、なぜProject Gのような長時間稼働するシステムの中核にRustを選ぶのかを、建築現場の考え方に置き換えて解説します。
1. 最初に結論：Rustは「すべてを置き換える言語」ではない
JavaScript、Python、Rustは、同じ目的のために並んだ三つの工具ではありません。それぞれ得意な工事が違います。
- JavaScriptは、ブラウザ画面やWebサービスとの接続に強い
- Pythonは、データ処理、AI、試作、自動化に強い
- Rustは、長時間動く処理、資源効率、安全性を重視する中核処理に強い
したがって、判断基準は「どの言語が一番優れているか」ではなく、次の問いになります。
そのプログラムは、どこで動き、どれくらい長く稼働し、停止したときに何が困るのか。
一度だけ実行する集計スクリプトなら、Pythonの方が短く早く書けることがあります。ブラウザの画面を動かすなら、JavaScriptやTypeScriptが中心になります。一方、毎分データを監視し、失敗を記録し、何か月も常駐させる基盤では、Rustの設計思想が効いてきます。
Rustを選ぶ理由は、流行や難しさへの挑戦ではありません。壊れたときの損失が大きい場所へ、より厳しい事前検査を導入するためです。
2. JavaScriptとPythonが優れている理由
Rustを説明するとき、JavaScriptやPythonを「弱い言語」として扱うのは正確ではありません。むしろ、両者にはRustが簡単には代替できない強みがあります。
JavaScriptはWebの標準接着剤
JavaScriptはブラウザ上で動く中心的な言語です。画面操作、フォーム、通信、DOM操作、各種Web APIとの連携では、JavaScriptまたはTypeScriptが最も自然な選択になる場面が多くあります。
Node.jsを使えば、同じ言語をサーバー側でも利用できます。フロントエンドとバックエンドで知識を共有しやすく、パッケージも豊富です。
建築に例えるなら、JavaScriptは現場のあらゆる設備を接続する配線と制御盤です。照明、スイッチ、センサー、表示装置をすばやく結び、利用者が触れる場所を作ることに長けています。
Pythonは試作とデータ処理が速い
Pythonは記述量が少なく、読みやすく、データ分析やAI関連のライブラリが充実しています。CSVの加工、APIからの取得、機械学習、日常業務の自動化などを短時間で組み立てられます。
建築に例えるなら、Pythonは現場で素早く加工できる万能工具です。調査、計測、試験、仮設、検証に強く、「まず動かして確かめる」段階で大きな力を発揮します。
速く作れることは、立派な性能
開発では、実行速度だけが性能ではありません。
- 開発にかかる時間
- 修正しやすさ
- 人材や情報の多さ
- ライブラリの充実
- 試作から検証までの速さ
これらも重要な性能です。小規模な処理をRustで厳密に作り込むより、Pythonで数時間のうちに検証した方が合理的なことは珍しくありません。
それでもRustを選ぶのは、試作の速さよりも、長期稼働時の構造と予測可能性を優先したい場所です。
3. Rustが「実行前の検査」を重視する理由
Rustはコンパイル言語です。ソースコードをそのまま逐次実行するのではなく、事前にコンパイラが検査し、実行可能な形式へ変換します。
ただし、「コンパイル言語だから安全」というだけではありません。Rustの特徴は、型システムと所有権の仕組みを使って、メモリの扱いや参照関係を厳しく確認する点にあります。
所有権は資材管理台帳に近い
Rustでは、値には所有者があり、その値を誰が持ち、どこまで使えるかが規則として管理されます。
建築現場で考えると、重要な工具や資材を「誰が管理しているか不明」のまま放置しない仕組みです。
- 資材の管理者は誰か
- 別の担当者へ引き渡したのか
- 一時的に借りているだけなのか
- すでに廃棄された資材を参照していないか
こうした関係をコンパイラが確認します。
たとえば、ある値の所有権を別の変数へ移した後、元の変数をそのまま使おうとすると、Rustはコンパイルエラーにします。これは不便に見えますが、二重解放や無効な参照につながる危険を早い段階で止めるための仕組みです。
借用は「閲覧」と「変更」を分ける
Rustでは、値を所有したまま別の処理へ一時的に貸すことができます。これを借用と呼びます。
借用には大きく二つあります。
- 読み取りだけを行う不変参照
- 内容を書き換えられる可変参照
同じデータに対して、読み取りと書き換えが無秩序に重なると、途中状態を読んだり、複数の場所から同時に変更したりする危険が生まれます。Rustはこうした競合をコンパイル時に制限します。
建築現場なら、最新図面を閲覧する人は複数いてもよい一方、原本を書き換える担当者は同時に一人だけにするようなものです。
コンパイル成功は「無欠陥証明」ではない
ここは重要です。
Rustのコンパイルが通っても、プログラム全体が正しいとは限りません。
- 計算式を間違える
- 条件分岐を逆にする
- 外部APIが停止する
- ディスク容量が尽きる
- ネットワークが切れる
panic!を起こす処理を書くunsafe部分で誤る
こうした問題は残ります。
Rustが強く防ぐのは、主にSafe Rustの範囲におけるメモリ安全性や、型・所有関係から検出できる問題です。「絶対に落ちない」のではなく、危険の一部を本番運転前へ移動させる言語と考える方が正確です。
4. 常駐サービスでRustが魅力になる理由
Project Gのような仕組みでは、プログラムが一度動けば終わるわけではありません。
- 1分ごとのキュー確認
- WordPress投稿状態の監視
- GA4データの収集
- SQLiteへの記録
- APIの待受
- systemdによる常駐運転
- 失敗時の再試行
こうした処理を長期間動かします。
長時間稼働するサービスでは、瞬間的な速さだけでなく、次の要素が重要です。
実行環境を小さくしやすい
Rustは通常、ネイティブ実行ファイルへコンパイルします。PythonインタープリターやNode.jsランタイムを別途起動する構成とは異なり、必要な処理を一つの実行ファイルへまとめやすくなります。
もちろん、利用するライブラリやリンク方法によって実行ファイルの大きさや依存関係は変わります。それでも、配布物と起動手順を単純化しやすいことは、VPS運用で大きな利点です。
ガベージコレクターを前提としない
Rustは所有権とスコープに基づいて、多くのメモリを決定的なタイミングで解放します。一般的なRustプログラムは、実行時のガベージコレクターを前提としません。
これにより、GCの動作タイミングに左右されにくく、応答時間やメモリ解放のタイミングを見通しやすくなる場合があります。
ただし、JavaScriptやPythonだから必ず重く、Rustなら必ず軽いわけではありません。実際の使用量は、処理内容、ライブラリ、データ構造、キャッシュ、実装方法によって大きく変わります。
比較は言語名だけで決めず、同じ条件で計測する必要があります。
型が運用上の契約書になる
常駐サービスでは、データの欠落や形式違いが障害の種になります。
Rustでは、値が存在しない可能性をOption、失敗する可能性をResultとして型で表現できます。これにより、「失敗するかもしれない処理」を、成功した前提でうっかり進めにくくなります。
たとえば、WordPress APIから記事IDを取得する処理では、通信失敗、認証失敗、想定外レスポンスなどを明示的に扱えます。
これは、現場の施工要領書に「異常時の処置」が最初から組み込まれている状態に近いでしょう。
5. WebAssemblyとRustの相性
Rustを選ぶもう一つの理由が、WebAssemblyとの関係です。
WebAssemblyは、ブラウザや対応ランタイムで実行できる移植性の高いバイナリ形式です。Rustはwasm32系ターゲットへコンパイルでき、wasm-bindgenや関連ツールを使ってJavaScriptとの橋渡しもできます。
この組み合わせには、次の利点があります。
- Rustで書いた計算処理をブラウザへ持ち込める
- JavaScriptからRust由来のWasm関数を呼び出せる
- 同じRustの知識をサーバー側とWasm側へ応用できる
- 型や所有権を使って処理の中核を設計できる
ただし、Rustを使えば自動的に小さく高速なWasmになるわけではありません。
- DOM操作ではJavaScriptとの境界を越える必要がある
- 文字列や複雑なデータの受け渡しにはコストがある
- 生成物のサイズ最適化が必要になることがある
- ブラウザAPIを直接使えないコードもある
- すべてのRustクレートがWasm環境に対応しているわけではない
したがって、画面全体をRustへ置き換えるのではなく、計算、変換、解析、ゲームロジックなど、境界が明確な処理へ使う設計が現実的です。
6. JavaScript・Python・Rustを比較する
| 観点 | JavaScript / TypeScript | Python | Rust |
|---|---|---|---|
| 得意分野 | ブラウザUI、Web連携、Node.js | AI、分析、自動化、試作 | 常駐基盤、低レベル処理、Wasm |
| 開発初速 | 速い | 非常に速い | 学習初期は遅め |
| 実行方式 | ブラウザやNode.jsランタイム | Python処理系 | ネイティブやWasmへコンパイル |
| メモリ管理 | 主にGC | 参照カウント＋GCなど | 所有権とスコープ中心 |
| 型の厳密さ | JSは動的、TSは静的検査 | 基本は動的 | 静的で厳格 |
| 配備 | npm環境やバンドル | 処理系・仮想環境など | 実行ファイルへまとめやすい |
| Wasmとの関係 | Wasmのホストとして重要 | 実行方法に追加構成が必要 | 主要なコンパイル元の一つ |
| 向いている段階 | UIとWeb接続 | 調査・試作・分析 | 長期運用する中核 |
この表からも分かるように、RustはJavaScriptやPythonの代わりではありません。
実際のシステムでは、次のような組み合わせが有効です。
text ブラウザ画面：JavaScript / TypeScript データ分析・試作：Python 常駐API・キュー処理：Rust 計算ロジック：Rust → WebAssembly コンテンツ管理：WordPress
Project Gが目指しているのも、一つの言語で全部を囲い込む構造ではありません。各技術を適材適所で組み合わせ、その中心を銀翼の艦橋で管理する構造です。
7. Rustを選ぶべき場面
次の条件が多く当てはまる場合、Rustを検討する価値があります。
- 24時間動かす常駐サービス
- メモリやCPUが限られたVPS
- 多数のジョブを並行処理する基盤
- 停止やデータ破損の影響が大きい処理
- WebAssemblyへ展開したい計算処理
- 単一バイナリに近い形で配備したい
- 長期間保守する中核コンポーネント
一方、次の場面ではJavaScriptやPythonの方が合理的なことがあります。
- 数時間で試作品を作りたい
- 一度だけ使う変換スクリプト
- AI・機械学習ライブラリを優先したい
- ブラウザUIが中心
- チームがRustを保守できない
- 実行速度やメモリ使用量が問題になっていない
難しい言語を選ぶこと自体に価値はありません。運用上の課題が、Rustの厳格さによって実際に減るかどうかで判断します。
8. Rustの難しさは「前払いの工事費」
Rustを学び始めると、所有権、借用、ライフタイム、Result、Option、トレイトなど、慣れない考え方に何度も止められます。
JavaScriptやPythonならすぐ動く処理が、Rustではコンパイルエラーになることもあります。
しかし、この厳しさは無駄な障害ではありません。
- 値を誰が所有しているのか
- 失敗をどこで処理するのか
- 並行処理で競合しないか
- データが存在しない場合を考えたか
- 外部境界で何が起きるか
これらを実行前に考えるよう迫られます。
建築に例えるなら、Rustは施工中の自由度を下げる代わりに、構造計算、材料検査、施工要領、検査記録を先に求める工法です。初期工程は重くなりますが、完成後の改修や障害対応を減らせる可能性があります。
もちろん、テスト、監視、ログ、バックアップ、再起動設計はRustでも必要です。言語だけで運用は完成しません。
それでも、長く動かす中核へ「壊れにくい構造」を埋め込む手段として、Rustは魅力的です。
9. まとめ：Rustを選ぶのは、安心を設計段階で買うため
JavaScriptやPythonは、速く作り、つなぎ、試すことに優れています。Rustは、長期間動かす中核を厳密に組み立てることに向いています。
Rustを選ぶ理由は、他の言語を否定するためではありません。
- メモリ安全性をコンパイル時に強く検査できる
- 所有権と型でデータの扱いを明確にできる
- ガベージコレクターを前提としない
- ネイティブ実行ファイルへまとめやすい
- WebAssemblyへ展開できる
- 長期運用する中核の設計を厳密にできる
これらが、常駐型の自動化基盤や銀翼の艦橋のようなシステムと噛み合います。
Rustは「絶対に壊れない城」を自動的に建てる魔法ではありません。しかし、構造上の危険を工事中に見つけやすくし、完成後に起きる事故の一部を前工程へ移せます。
だからこそ、JavaScriptやPythonで素早く試し、Rustで長く使う中核を固める。この分担が、個人開発でも現実的な選択になります。
関連記事候補
- 基礎編 #01：「WebAssembly（Wasm）とは何か？」を現場監督が建築の言葉で解説する
- 基礎編 #03：「ブラウザの中で動く技術」だったWasmが、なぜサーバーでも注目されているのか
- 基礎編 #05：「メモリ安全性」とは何か？夜中にサーバーが落ちる不安を減らすRustの仕組み
- 基礎編 #13：「コンパイラに怒られる」は最高のコンサルタント
- 基礎編 #15：「所有権」とは何か？データを誰が持ち、いつ手放すのか
参考資料
- The Rust Programming Language「Understanding Ownership」
- The Rust Programming Language「Unsafe Rust」
- Rust and WebAssembly documentation
- Python公式ドキュメント「Memory Management」「gc」
- Node.js公式ドキュメント「V8」