アーキテクチャ
// ARCHITECTURE
3 つの実行レイヤー、1 つのバグに 1 つだけ。
Layer 1 のブラウザ内 WebAssembly、Layer 2 のコンテナ、Layer 3 の record-replay。どのレイヤーで動くかはレシピが宣言します——あなたが選ぶ必要はありません。下表で 3 層を一望してから、深掘りに進めます。
ブラウザの中で、瞬時に。
Docker / microVM で、忠実度を。
トレース同梱で、どこでも再生。
rr replay だけ。~4 GB 上限、本物の fork/exec、データレース、コンパイラ自体のビルド。wasm32-wasip1 / sqlite-wasm。Dockerfile + ghcr.io/aletheia-works/vivarium-<slug> + Codespaces バッジ。rr トレースを焼き込んだ自己完結 GHCR イメージ。// 01 · LAYER 1
WebAssembly、ページの中で。
ユーザーのブラウザタブの中で再現が直接実行される層です。アカウントもインストールも不要、ページを開けばすぐ動きます。Phase 0〜2 で複数の Python / Ruby / PHP / Rust レシピを揃え（例: cpython#137205やpandas#56679）、現在は最も「ブラウザだけで完結する」surface です。
向くバグ
- アルゴリズムバグ（ソート、パース、テキスト処理）。
- データ処理のリグレッション（pandas / polars / numpy のシェイプバグなど）。
- データベースの動作バグ（SQLite のクエリ異常、JSON パスのエッジケース）。
- ファイルシステム・ネットワーク・プロセスモデルに触れない、ライブラリ内部のロジックバグ。
起動時間
- 初回（キャッシュなし）: 1〜10 秒。ランタイムのダウンロード（Pyodide ≈ 10 MB 圧縮）とインスタンス化が支配的。
- 2 回目以降: ブラウザのキャッシュが効いて 1 秒未満で起動。
- 再現スクリプトの実行自体: ミリ秒〜数秒。
届かないこと
- メモリ。 ブラウザタブはピーク 1 GB 超で性能が劣化、4 GB が実質上限。本番規模のデータは Layer 2 へ。
- システムコール。 本物の
fork/exec、本物のソケットは使えない。WASI シムが一般的なケースをカバー。 - 並行性バグ。 デフォルトはシングルスレッド。データレースやハイゼンバグは Layer 3 へ。
- コンパイラ自体のビルド。 Rust のバグはブラウザ内で再現できますが、Rust コンパイラ自体のビルドは Layer 2。
対応ランタイムと実例
- Python: Pyodide — live: cpython#137205やpandas#56679
- Rust:
wasm32-wasip1— live: regex#779 - Ruby: Ruby.wasm — live: ruby#21709
- PHP: php-wasm — live: php#12167
- SQLite: sqlite-wasm（Pyodide 経由）— sqlite WASM ビルドを Pyodide 経由で叩くレシピは上の Python の項にまとまっている。
// 02 · LAYER 2
Docker / microVM、訪問者のマシン上で。
本物のファイルシステム、本物のプロセス、本物のネットワークが必要なバグのための層です。Vivarium 側で再現を実行するのではなく、訪問者自身の Docker（または Codespaces）で動かすカタログ型の配信モデルを採用しています。
向くバグ
- プロジェクト全体の再現——実際のパッケージインデックスへの依存解決を要するバグ。
- システムコール依存のバグ——本物の
fork、ソケット、ファイルロック、シグナル。 - ツールチェーン固有のバグ——特定の GCC、glibc、カーネル ABI の癖。
- プロセス間の相互作用が原因のマルチプロセスバグ。
使い方
各レシピページにはピン留めされた Dockerfile と、コピペ可能な docker run … コマンド、そして ghcr.io/aletheia-works/vivarium-<slug> に公開されたビルド済みイメージへのリンクが揃っています。CI で取得した verdict スナップショットがページ上に表示され、訪問者自身の docker run がライブ再現になります。Codespaces 対応のレシピには「Open in Codespaces」バッジも提供されます。
届かないこと
- ページ内では実行されない。 訪問者がローカルか Codespaces で実行します。
- Docker（または Codespaces アカウント）が必要。 どちらもない場合は、レシピと verdict スナップショットの閲覧のみ可能。
- 並行性そのものをデバッグするバグ。 Layer 2 は本物のスレッドで動きますが、ハイゼンバグの再現性確保は Layer 3 の領分。
// 03 · LAYER 3
トレースを同梱、どこでも再生。
数回再実行しても再現する保証がないハイゼンバグのための層です。Vivarium 側であらかじめ録音したトレースを GHCR イメージに焼き込み、訪問者は再生だけすれば済むようにしています。
向くバグ
- データレース、メモリ順序バグ、単純な再実行では再現しない use-after-free。
- 長時間 replay シナリオ：何時間ものキャプチャ実行を数分で巻き戻す。
- 特定のメッセージインターリーブに依存する分散システムバグ。
- 事後フォレンジック分析——録音済みトレースを後ろに戻る形のデバッグ。
使い方
各 Layer 3 レシピは、トレースを焼き込んだ自己完結 GHCR イメージとして配布されます。rr replay は PMU を必要としないため、訪問者と CI の再生はどちらもコモディティな Linux ホストで動作します。録音そのものは PMU を備えた Linux/x86_64 環境を要するため、レシピ追加時のオフライン作業として Vivarium 側で済ませてあります。
届かないこと
- 環境制約。 訪問者のマシンは Linux/x86_64 が前提。ARM Mac や Windows の場合は Codespaces または WSL2 + Docker にフォールバック。
- カバレッジの形が違う。
rrは単一プロセス Linux x86_64、分散シミュレーションツールは分散システムを対象。互いの領域はカバーしない。 - トレースが大きい。 レシピあたり数十 MB から一桁 GB のオーダー。
実例
- pthread lost-update — 真のスレッド競合を
rrで決定的に保存し、訪問者はrr replayで巻き戻すだけ。 - 新しい Layer 3 レシピは PMU 録音のオフラインフットワークを要するため、追加ペースは L1/L2 より緩やか。
どのレイヤーで動くかは、レシピ側があらかじめ宣言しています。あなたが選ぶ必要はなく、レシピを開けば自動的にそのレイヤーで動作します。