【アーキテクチャ考察】Goのクロスコンパイルの悩みから、Wasm・Rust・そして「次世代OS」の未来までを一気に駆け抜ける

はじめに

Go言語でC言語依存（cgoなど）のライブラリを使った途端、OSやアーキテクチャごとのクロスコンパイルが急に煩雑になる……。そんな悩みに直面したことはないでしょうか？

「一度書けば、どのOSや環境でも動く（Write Once, Run Anywhere）ジョブスケジューラーを作りたい」

このシンプルな要求からスタートした思考実験は、言語選定（Go vs Rust）にとどまらず、Dockerの限界、WebAssembly（WASI）の可能性、そして「次世代OS」やハードウェアの地殻変動へと繋がっていく、壮大なアーキテクチャ探求の旅になりました。

本記事では、その考察プロセスを備忘録としてまとめます。

1. 「どこでも動く」の最適解：WASIという黒船

当初の目的である「OSを問わずに動く常駐型ジョブスケジューラー」を実現するため、仮想マシン（Java等）の重さを避けつつ到達したのが「WASI（WebAssembly System Interface）」でした。

Wasmはブラウザの中だけで動く技術から、サーバーやOS上で直接動く技術へと進化しています。Wasmtime や wazero のような極めて軽量なランタイムさえあれば、.wasm ファイル1つでMacでもWindowsでもLinuxでも全く同じように動作します。

言語選定：Goか、TinyGoか、Rustか？

WASI向けにビルドする際、どの言語を採用すべきか。それぞれのトレードオフは以下のようになります。

比較項目	標準Go (`GOOS=wasip1`)	TinyGo	Rust
バイナリサイズ	大きい (数MB〜)	小さい (数十KB〜)	最小 (数KB〜)
メモリ使用量	GCのため少し多め	少ない	極めて少ない (GCなし)
Wasmエコシステム	発展途上	良好	圧倒的トップ
学習コスト	非常に低い（簡単）	非常に低い（簡単）	非常に高い（難しい）

Wasmの世界において、メモリ管理（GC）が不要で極小・超高速なバイナリを吐き出せるRustは間違いなく最強の言語です。しかし、実務における「書きやすさ・保守性」を重視する場合、Goの軽快さを保ちつつバイナリを極小化できるTinyGoも、非常に有力な選択肢になります。

2. セキュリティの壁：Wasmは「魔法のブラックボックス」ではない

ここで一つの疑問が生まれました。
「Wasm化すれば、ソースコードや独自のアルゴリズムを隠蔽したままユーザーに配布できるのではないか？」

結論から言うと、それは不可能です。
Wasmファイルはクライアントにダウンロードされる以上、wasm2wat などのツールやデコンパイラを使えば、ロジックを解析（リバースエンジニアリング）されるリスクが常に伴います。

もし「独自の計算式やソースコードを絶対に見られたくない」のであれば、Wasmをユーザーに配るというロマンを捨て、「RustやGoで作ったプログラムを自社サーバーの奥深く（Dockerコンテナ内など）で常駐させ、ユーザーにはAPI経由で結果だけを返す」という、オーソドックスなバックエンド設計に回帰するのが最も堅牢な正解となります。

3. DockerとWasmの違い：CPUアーキテクチャの壁

サーバー側で動かすならDockerが標準ですが、DockerとWasm（WASI）が解決する領域には明確な違いがあります。

Dockerが越える壁： 「OSの違い（Windows / Mac / Linux）」を吸収する。
Dockerが越えられない壁： 「CPUアーキテクチャの違い（Intel / ARM）」は吸収できない。M1 MacでビルドしたイメージをIntelサーバーに持っていくと起動エラーになる（※マルチプラットフォームビルドで回避は可能）。

これに対し、Java（JVM）やWASI（Wasmランタイム）は、「中間言語」をリアルタイムに通訳するため、OSだけでなくCPUアーキテクチャの壁すらも完全に無視できます。

4. Wasmのさらに先へ：インフラのパラダイムシフト

WASIの台頭は、現在起こりつつあるインフラ技術の地殻変動の一部に過ぎません。現在、以下の3つの潮流が同時進行しています。

Wasm Component Model: 言語の壁を破壊する技術。Rustで作ったWasmとGoで作ったWasmを、レゴブロックのように直接合体させて1つのプログラムにすることが可能になる。
eBPF: OSの深淵（カーネル空間）を、再起動なしに安全なサンドボックス内で拡張・操作する技術。
Unikernel: OSの不要な機能を全削ぎ落とし、プログラム本体と必要最小限のOS機能だけを極小イメージにコンパイルする、究極のリソース効率化技術。

技術の振り子は現在「巨大化したコンテナ」から「より細かく、より軽く、より安全なサンドボックス」へと強烈に振れています。

5. 究極のエンドゲーム：「Wasm OS」とハードウェアの革命

WasmがCPUアーキテクチャの壁を完全に無効化する未来が行き着く先、それは「WasmベースのOS」の誕生です。

現在のOSは、プロセス間のメモリを物理的な壁で隔離しているため、通信に莫大なコスト（コンテキストスイッチ）がかかります。しかし、数学的に安全が証明されたWasmのサンドボックスを使えば、すべてのアプリを同じメモリ空間にゴチャ混ぜに置いても安全（SASOS: シングルアドレススペースOS）になります。アプリ間の通信が「ただの関数呼び出し」になり、常識を覆す超高速OSが誕生します（現在、Rustベースの Nebulet などで実験が進んでいます）。

ソフトウェアの進化が、ハードウェア産業を丸裸にする

Wasm OSが普及し、ソフトウェアがCPUアーキテクチャに依存しなくなるとどうなるか。

これまでIntel（x86）やARMが持っていた「命令セット（ISA）の独占」という防壁が崩壊します。ライセンス料の高い既存のCPUを使う理由がなくなり、オープンソースで無料のCPUアーキテクチャである「RISC-V」の爆発的普及が加速します。

今後のハードウェアメーカーは互換性で縛ることをやめ、純粋な「計算スピード」と「Wasm専用の物理処理回路」の開発で勝負する時代へと突入していくでしょう。

おわりに

「Goのライブラリを別のOS向けにビルドするのが面倒だ」という日常的な悩み。
それを突き詰めていくと、Dockerの実態、WasmがもたらすCPUアーキテクチャの無効化、そしてRISC-V台頭によるハードウェア産業の根底からの変革という、とてつもなく深いウサギの穴に繋がっていました。

制約から解放された未来のコンピューティング環境で、私たちはどんなアプリケーションを作るべきか。アーキテクチャの進化を追うのは、本当にワクワクしますね。