1. エグゼクティブサマリー / At a Glance
現代の分散システム、とりわけWebAssembly（Wasm）ランタイムを中核に据えたエッジおよびサーバーサイドの自動調停アーキテクチャにおいて、プログラムの「実行安全性」は単なるセキュリティの要件ではなく、システムの持続可能性と直結する「最重要インフラ」である。
本稿では、月額数百円の極小VPS環境（1 vCPU, 1GB RAM想定）において、自作のRust製Wasmモジュール（銀翼の艦橋）を司令塔として稼働させる際、Wasmが提供する「サンドボックス環境」の圧倒的な安全網について、シニアエンジニア向けに徹底的な解剖を行う。> **批判的警告 / Critical Warning Point**
> 従来のネイティブバイナリや重量級のスクリプト（PHP、Python等）を実行する環境では、プログラム内のたった一つの致命的バグやメモリ破壊、あるいは外部APIから注入されたインジェクション攻撃によって、プロセス全体が道連れとなり、最悪の場合はホストサーバーのOSカーネルやファイルシステムが完全に崩壊するリスクを常にはらんでいる。Wasmのサンドボックスは、この「爆破半径」を極限まで狭め、万が一の破綻時にもホスト環境を無傷で守り抜く絶対的な防壁である。
2. はじめに：なぜ「隔離された実行環境」が無人駆動の命取りを防ぐのか
WebAssembly（Wasm）がフロントエンドのブラウザという狭い鳥籠を飛び出し、サーバーサイドやエッジコンピューティングの領域においてDockerコンテナに匹敵する、あるいはそれを凌駕する超軽量な次世代実行基盤として熱狂的に迎え入れられている理由は、その圧倒的な低フットプリント（起動速度数ミリ秒、バイナリサイズ数百KB）だけではない。その本質的なイノベーションは、ハードウェアレイヤーに近い超高速な演算能力を維持しながら、同時に「完全なる隔離（フォルト・アイソレーション）」を両立させたその内部アーキテクチャにある。
個人開発者がVPSという限られたリソースの上で、AI駆動型のデータ解析・自動コンテンツ生成・複数プラットフォームにまたがる自動調停システムを24時間365日無人で回す場合、最も恐れるべきは「自分が寝ている間にシステムが致命的なエラーでクラッシュし、サーバー全体が沈没すること」である。Wasmのサンドボックス環境は、この恐怖を根本から消し去り、システムがどれほど野生化し、あるいはバグを爆発させようとも、ホストOSや隣接するシステムに一切の物理的被害を与えない「防爆区画」を提供する。
3. サンドボックスの本質：建築の言葉で解体する「防火壁と完全防爆実験室」
建築現場や化学プラントの設計において、最も重要視される設計思想の一つが「区画化（コンパートメンタライゼーション）」である。
例えば、高度な化学実験を行う研究所を建設する際、設計者はすべての実験室を一つの巨大なワンフロアに配置することは絶対にしない。万が一、ある実験室で予期せぬ引火や爆発、あるいは有毒ガスの漏洩が発生した場合、施設全体が全焼・全滅してしまうからである。
プロの設計者は、それぞれの実験室を分厚い「防火壁」と「耐圧防爆扉」で完全に隔離された独立空間（サンドボックス）として構築する。この防爆実験室の内部には、独自の換気ダクトと独自の排水経路しか存在せず、メインの廊下やオフィスのインフラとは完全に遮断されている。
万が一、室内の研究員（バグや悪意あるコード）が致命的なミスを犯して爆発を引き起こしたとしても、その破壊のエネルギーは防爆室の頑丈な壁の内部だけに閉じ込められ、壁の外側でコーヒーを飲んでいる他のスタッフ（ホストOSや他のWebサイト）は何の影響も受けずに仕事を続けることができる。
ソフトウェア開発における「Wasmサンドボックス」は、まさにこの「高精度な防爆実験室」をサーバーのメモリ空間内部にソフトウェア的に鋳造する技術である。プログラムは、Wasmという強固な安全網の中に完全に閉じ込められた状態でのみ実行され、外の世界のファイルシステムやネットワークといった「生のリソース」への自由な立ち入りを一切禁止される。
4. Wasmサンドボックスの内部構造：線形メモリと完全隔離の深層メカニズム
Wasmサンドボックスが、DockerのようなOSレベルの仮想化（名前空間やcgroups）や、従来のJVM（Java仮想マシン）のような重量級のランタイムと決定的に異なるのは、その「線形メモリ（Linear Memory）」アーキテクチャと「コンパイル時コード検証（Validation）」の二重の防衛機構にある。その深層メカニズムをシニアエンジニアの視点から精緻に分析する。
4.1 線形メモリ（Linear Memory）の絶対的境界線
Wasmインスタンスが起動する際、ホストランタイム（Wasmtimeなど）は、そのインスタンス専用に完全に連続した、単なる一つの巨大なバイト配列（Vec<u8> に相当する領域）を確保する。これが「線形メモリ」である。
Wasm内部で実行されるRustコードがどれほど複雑なポインタ操作やメモリ確保を行おうとも、プログラムから見える「メモリ番地0」は、ホストOSの物理メモリの0番地ではなく、この確保されたバイト配列の先頭番地にすぎない。Wasmバイナリ内のすべてのメモリアクセス命令は、この配列のサイズ（上限）を超えることができないよう、コンパイル時および実行時にハードウェアのMMU（メモリ管理ユニット）またはJITコンパイラによる境界チェックによって厳格にガードされている。
C言語や古いローレベル言語で頻発するバッファオーバーフロー攻撃や、不正なポインタによってOSの領域を書き換える「アドレス空間の汚染」は、Wasmの閉じた世界の中では理論的に発生不可能である。仮にWasm内部のコードが暴走してメモリ境界の外側を指し示したとしても、Wasmランタイムがそれを即座に検知し、ホストOSを巻き込む前に「トラップ（強制終了）」を発生させてインスタンスを安全に切断する。
ホスト物理メモリ空間 (Host OS Physical Memory Area)
┌────────────────────────────────────────────────────────────────────────┐
│ [Nginx プロセス] [OS カーネル領域] [その他の常駐システム] │
│ │
│ ▼ Wasmランタイム (Wasmtime) が鋳造した防爆区画 │
│ ┌──────────────────────────────────────────────────────────────────┐ │
│ │ Wasm インスタンス線形メモリ (Linear Memory: 連続したバイト配列) │ │
│ │ │ │
│ │ [0x0000] ───> [ ゲストコード実行領域 ] │ │
│ │ [0x1000] ───> [ 内部スタック / データ領域 ] │ │
│ │ [0x7FFF] ───> [ データの境界上限 (Max Boundary) ] │ │
│ │ │ │
│ │ ※この境界線を越えるメモリアクセスはランタイムが即座に「射殺」 │ │
│ └─────────────────────────────────┬────────────────────────────────┘ │
└────────────────────────────────────┼───────────────────────────────────┘
│
▼ (不正アクセス検知時の挙動)
┌────────────────────────────┐
│ ランタイム・トラップ発動 │
│ – インスタンスを瞬間蒸発 │
│ – ホストOSは1ミリも無傷 │
└────────────────────────────┘
4.2 コンパイル時検証（Validation Phase）の検問
Wasmバイナリ（.wasm）が実行される直前、ランタイムはバイナリの全構造をスキャンし、厳格な静的解析（バリデーション）を実行する。
この検問フェーズにおいて、関数スタックの型整合性、不正なジャンプ命令（コントロールフローの破壊）、未定義のメモリ操作がないかどうかが厳密にチェックされる。このバリデーションを通過しないバイナリは、1行たりとも実行されることはない。つまり、Wasmは実行される前の段階で、すでにその「安全性の証明書」を提出することを義務付けられているのである。
5. 三大連携対象における「防爆」の実効性：万が一の破綻シナリオ
私たちの自動調停システム「銀翼の艦橋」が結合する3つの主要外部コンポーネント（Claude, BASE, note）とのやり取りにおいて、サンドボックスの安全網が具体的にどのようにシステム崩壊を防ぐのか、リアルな破綻シナリオを用いてその実効性を検証する。
5.1 Claude API：AI出力のインジェクション攻撃に対する「絶対隔離」
- 破綻シナリオ: 外部の悪意あるフォーラムやSNSから収集した汚れた生データを、Claude APIに要約・解析させるフェーズ。AIがデータの内部に含まれていた悪意ある指示（プロンプトインジェクション）に騙され、予期せぬ制御コードや、システムコマンドを実行させようとするテキスト（例：os.system(“rm -rf /”) の亜種）を含んだ不正なJSONを出力したとする。
- サンドボックスの防衛線: 仮にその出力によってシステム内部のパーサーがバグを引き起こし、不正なメモリアドレスへジャンプしようとしたとしても、Wasmの線形メモリの壁に衝突してその瞬間にプロセスは爆死する。Wasmの外部にあるホストVPSのファイルシステムには、最初からアクセスするルート（システムコール）が遮断されているため、AIがどのような凶悪なコードを出力しようとも、サーバー全体がハッキングされるリスクは完全にゼロとなる。
5.2 BASE API：並行処理時のメモリ枯渇（OOM）に対する「コンプライアンス防壁」
- 破綻シナリオ: BASEのセール時に、突発的な購入Webhookが秒間数百件レベルでシステムに撃ち込まれ、非同期タスクが大量に生成された結果、データ処理バッファがメモリを急激に消費し始めたとする。
- サンドボックスの防衛線: 伝統的なネイティブサーバーであれば、システム全体のメモリを使い潰し、OSのOOM Killerが起動して無関係なNginxやデータベース（PostgreSQL等）まで巻き込んでサーバーごと強制シャットダウンさせてしまう。しかし、Wasmランタイム上では、個々のWasmインスタンスが消費できるメモリの上限（例: 1インスタンスあたり最大32MB）をあらかじめミリ単位で制限しておくことができる。上限に達したWasmインスタンスは単独で安全にダウンするが、ホストOSのリソースは完全に保護され、隣の区画のサーバーやWebサイトは何事もなかったかのように駆動を続ける。
5.3 note API：ネットワークエラーによるスレッド無限ループの「時間軸遮断」
- 破綻シナリオ: note APIへ完成アセットを投稿する通信の最中、ネットワークの瞬断が発生。自作の通信コードにバグがあり、タイムアウトをすり抜けて while true の無限再試行ループに突入したとする。CPU使用率は100%に張り付き、サーバーの演算リソースを食いつぶしにかかる。
- サンドボックスの防衛線: Wasmランタイムには「エポックベース・タイムアウト（Epoch-based Timeouts）」という機能が仕込める。ホスト側から定期的にエポック信号を送り、一定時間を過ぎても処理が戻らないWasmインスタンスの実行を、ランタイム側から強制的に割り込んで終了させることができる。プログラムのバグによってCPUがロックアップされるのを、外側から物理的に引き剥がすことができるのである。
6. 堅牢なる設計思想：WASIによる最小特権原則（Least Privilege）の具現化
サンドボックス環境がどれほど頑丈であっても、プログラムが外部と通信したり、CSVファイルを保存したりするためには、どこかのタイミングで外の世界へ手を伸ばさなければならない。この「防爆室の扉を、必要最小限の隙間だけ開ける」ための規格が、WASI（WebAssembly System Interface） である。
WASIの設計思想の根底にあるのは、セキュリティ工学における最高峰の原則である**「最小特権原則（Least Privilege）」** および 「ケイパビリティベース・セキュリティ（Capability-based Security）」 である。
従来のLinuxサーバーにおいて、プログラムが /var/log/app.log にログを書き込みたい場合、プログラムはOSに対して「ファイルシステム全体へのアクセス権（あるいは実行ユーザーの権限）」を持ってアプローチする。そのため、プログラムに脆弱性があれば、/etc/passwd などの全く関係のない重要ファイルを盗み見られる危険性があった。
対してWASIでは、Wasmインスタンスを起動するホスト側（Wasmtimeの設定コード）で、以下のように「このフォルダの、このファイルだけを読み書きしてよい」という具体的なケイパビリティ（トークン） を事前に手渡す設計をとる。
┌────────────────────────────────────────────────────────┐
│ ホストOS（Linux）の広大な領土 │
│ `/` (ルートファイルシステム) │
│ ├── `/etc/secret_keys` (絶対侵入不可) │
│ └── `/var/www/ginyoku/storage` <── 【ここだけを許可】 │
└──────────────────────────┬─────────────────────────────┘
│
│ (Wasmtimeの起動設定による明示的マウント)
▼ `preopened_dir` として受け渡し
┌────────────────────────────────────────────────────────┐
│ Wasm サンドボックスの内部世界 │
│ │
│ プログラムから見える世界は `/var/www/ginyoku/storage` │
│ という単一のディレクトリが「ルートのすべて」となる │
│ これ以外の階層のパス（../etc等）を指定しても、 │
│ Wasmの宇宙には存在しないためパースすらできない │
└────────────────────────────────────────────────────────┘
Wasmインスタンスの内部にいるRustコードからは、ホストOSの全体像は1ミリも見えない。手渡された特定のディレクトリだけが、そのプログラムにとっての「世界のすべて」となる。このケイパビリティを持たないネットワーク通信命令やファイル操作命令は、OSのカーネルに届く手前のWasmランタイムのレイヤーで即座に拒絶される。この徹底した「土地勘の剥奪」こそが、個人開発のインフラを守り抜く究極の防衛策である。
7. 実装ディープダイブ：Wasmtimeランタイムを用いた「防爆インスタンス」のホスト構成コード
それでは、ここまでに解説した「完全隔離サンドボックス」および「最小特権WASIマウント」を具現化する、ホストOS側（ランタイム側）のRust実装のディープダイブコードを示す。
本コードは、月額数百円のVPS上で、ゲストであるWasmバイナリを起動する際、メモリ使用量を厳格に制限し、特定のディレクトリのみをマウントして安全に実行するための中核的なインフラストラクチャコードである。
7.1 Cargo.toml のホスト側構成
ホスト側でWasmバイナリを安全に駆動するための設定依存関係である。
[package]
name = “ginyoku_host_runtime”
version = “0.3.0”
edition = “2021”
[dependencies]
# 高性能Wasmランタイムの標準アーキテクチャ
wasmtime = “16.0.0”
# WASI機能を有効化するためのクレート
wasmtime-wasi = “16.0.0”
# 非同期ランタイム
tokio = { version = “1.36.0”, features = [“full”] }
# 高精度ロギング
tracing = “0.1.40”
tracing-subscriber = “0.3.18”
7.2 ホスト側具象実装コード（防腐・防爆インジェクション）
use std::path::PathBuf;
use wasmtime::{Config, Engine, Instance, Module, Store, ResourceLimiter};
use wasmtime_wasi::{WasiCtx, WasiCtxBuilder};
// 1. サンドボックス内のメモリリソースを厳格に制限するためのカスタムリミッター
struct MemoryGuardレール {
max_memory_bytes: usize,
current_allocated: usize,
}
impl ResourceLimiter for MemoryGuardレール {
fn memory_growing(&mut self, current: usize, desired: usize, _maximum: Option<usize>) -> Result<bool, wasmtime::Error> {
// desired は要求された新しいページ数（1ページ = 64KB）
let desired_bytes = desired * 64 * 1024;
if desired_bytes > self.max_memory_bytes {
tracing::warn!(“【防爆警告】 Wasmインスタンスが設定上限（{} MB）を超えるメモリ拡張を要求。実行を強制遮断します。”, self.max_memory_bytes / 1024 / 1024);
// false を返すことで、Wasm内部に OOM トラップを発生させ、安全に爆破終了させる
return Ok(false);
}
self.current_allocated = desired_bytes;
Ok(true)
}
fn table_growing(&mut self, _current: u32, desired: u32, _maximum: Option<u32>) -> Result<bool, wasmtime::Error> {
Ok(desired < 10000) // テーブルサイズも不当な肥大化を防ぐガードを設置
}
}
// WASIコンテキストとリソースリミッターを包含するホストの状態オブジェクト
struct HostState {
wasi_ctx: WasiCtx,
limits: MemoryGuardレール,
}
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
// ロギングの初期化
tracing_subscriber::fmt::init();
// 2. Wasmtimeエンジンの詳細構成（静的バリデーションの強制化）
let mut config = Config::new();
config.async_support(true); // 非同期実行を有効化
config.epoch_interruption(true); // 時間軸遮断（エポックタイムアウト）の有効化
let engine = Engine::new(&config)?;
// ゲストWasmバイナリ（銀翼の艦橋 コアモジュール）の読み込み
let wasm_path = “./target/wasm32-wasi/release/ginyoku_core.wasm”;
let module = Module::from_file(&engine, wasm_path)?;
// 3. 最小特権原則に基づくWASIコンテキストの構築
let sandbox_storage = PathBuf::from(“/var/www/ginyoku/storage”);
std::fs::create_dir_all(&sandbox_storage)?;
// ホストOSの生ファイルを開き、特定のディレクトリに対するケイパビリティ（アクセス権）を鋳造
let preopened_dir = cap_std::fs::Dir::open_ambient(&sandbox_storage, cap_std::fs::ambient_authority())?;
let wasi_ctx = WasiCtxBuilder::new()
.inherit_stdout() // ログ出力の回収用
.inherit_stderr()
// ファイルシステムに対する絶対的な特権制限マウント
.preopened_dir(preopened_dir, “.”)?
.build();
// 4. メモリ上限を「32MB」に設定した防爆状態の生成
let state = HostState {
wasi_ctx,
limits: MemoryGuardレール {
max_memory_bytes: 32 * 1024 * 1024, // 32MBの上限壁
current_allocated: 0,
},
};
// ストアの構築とリミッターのインジェクション
let mut store = Store::new(&engine, state);
store.limiter(|s| &mut s.limits);
// エポックタイマーのバックグラウンドスレッドを駆動（時間軸監視の開始）
let engine_clone = engine.clone();
tokio::spawn(async move {
loop {
tokio::time::sleep(std::time::Duration::from_millis(50)).await;
engine_clone.increment_epoch(); // エポックのカウントを進める
}
});
// 1エポック（50ms）× 20回 = 最大1秒で強制タイムアウトさせる設定
store.set_epoch_deadline(20);
// 5. WASIファンクションのリンクとインスタンス化
let mut linker = wasmtime::Linker::new(&engine);
wasmtime_wasi::add_to_linker(&mut linker, |state: &mut HostState| &mut state.wasi_ctx)?;
tracing::info!(“Wasmサンドボックス環境の鋳造が完了。最小特権での安全実行を開始します。”);
// インスタンスの生成（ここでコンパイル時検証が走る）
let instance = linker.instantiate_async(&mut store, &module).await?;
// エントリポイント関数の取得と実行
let entry_point = instance.get_typed_func::<(), ()>(&mut store, “_start”)?;
match entry_point.call_async(&mut store, ()).await {
Ok(_) => {
tracing::info!(“Wasmインスタンスは正常にタスクを完了して休止しました。”);
},
Err(trap) => {
// 万が一の暴走時にも、ここへエラーを閉じ込めてホストは平然と駆動を継続
tracing::error!(“【防爆成功】Wasm内部で異常（トラップ/バグ）を検知し、隔離空間内で安全に処理を蒸発させました。理由: {:?}”, trap);
}
}
Ok(())
}
8. 運用における4つの評価基準と防衛策
この超軽量防爆要塞を24時間無人で運用し、ストック資産を守り抜くために、シニアエンジニアが設計時に満たすべき4つの実用的評価基準を体系化する。
8.1 爆破半径（Blast Radius）の最小化とマルチテナント分離
同じVPS上で複数の異なる処理（例：BASEのデータ解析と、noteの自動投稿）を動かす際、それらを一つの巨大なWasmバイナリにまとめてはいけない。処理ごとにバイナリを完全に分離し、タスクが発生するたびに個別のWasmインスタンスを独立して立ち上げる。
これにより、仮にBASE側のデータ変換コードが想定外の入力でクラッシュした（爆発した）としても、その影響は「BASE処理用の防爆室」の内部だけで完結し、隣で走っているnoteへの資産投稿タスクには1ミリの影響も与えない「障害分離」が完成する。
8.2 メモリ・リークの「プロセス単位リセット」による根絶
ロングランニング（常駐型）のシステムにおいて、最もエンジニアを悩ませるのが、コードの隙間からメモリが少しずつ漏れ出す「メモリリーク」である。Rustは所有権システムによってメモリ漏れを極限まで防ぐが、複雑なコレクションの保持によってはメモリが肥大化することがある。
Wasmサンドボックス環境における最強の防衛策は、「タスクが終わるたびに、インスタンスのメモリ空間ごと使い捨てる（ステートレス駆動）」 ことである。Wasmインスタンスは起動スピードが数ミリ秒と爆速であるため、リクエストが届いた瞬間に生成し、処理が終わったらインスタンスごとメモリから消去する。これにより、どれほどズタズタに書かれたコードであっても、物理的にメモリリークが発生する時間的余地そのものを抹殺できる。
8.3 ファイルパスのサニタイズと「脱獄（Directory Traversal）」の絶対阻止
WASIによって特定のディレクトリ（.）へのアクセス権を与えた際、ゲストコードの内部で悪意ある入力（例: ファイル名に ../../../../etc/passwd を指定する等）が混入した場合の挙動を評価する。
WASIのファイルシステム実装は、仮想的なルートパスの外側に遡ろうとする相対パス指定（..）を、ファイルシステム呼び出しのハンドラレベルで自動的にインターセプトし、エラー（PermissionDenied）を返却する仕様になっている。したがって、ゲストコード側でパスのサニタイズを万が一忘れてしまっても、サンドボックスの壁そのものが「脱獄」を物理的に遮断する。
8.4 クラッシュログ（パニック情報）の外部退避とDiscord監視直結
Wasm内部でRustコードがパニック（クラッシュ）した際、その詳細なスタックトレース（どこでエラーが起きたか）の文字列は、Wasm内部のメモリに書き出されるだけでは消滅してしまう。
ホスト側の実行ストアで、ゲストの標準エラー出力（stderr）をキャッチするバッファを常時監視し、パニックの予兆やトラップの発生を検知した瞬間、そのログメッセージを防腐層経由で速やかにDiscordのエラーログチャンネルへ撃ち込む監視ラインを構築する。これにより、「防爆室の中で何が起きてインスタンスが死んだのか」を、艦長はオフィスの外からリアルタイムで完璧に把握することが可能となる。
9. 結論：サンドボックスがもたらす無人駆動インフラの「精神的自由」
「サンドボックス環境の安全網を学ぶ」とは、単にセキュリティの専門用語やメモリの保護機能を知識として蓄えることではない。
それは、あなたが構築した自動調停システムに対して、**「万が一、コードに致命的なバグがあっても、あるいは外部からどれほど凶悪なデータが注入されようとも、自分が大切に育ててきたサーバーの領土全体が破壊されることは絶対にない」**という、エンジニアリングにおける「絶対的な安心感（精神的自由）」を手に入れるための、最も強固な防衛インフラを確立する作業である。
Dockerコンテナのような巨大な仮想化レイヤーを維持する体力のない、月額数百円の極小VPSという限られた土地だからこそ、常駐メモリほぼゼロで駆動するWasmの防爆実験室という選択が最大の戦闘力を発揮する。システムを恐怖と監視で縛る必要はない。完璧な隔離壁を敷き詰め、その内部でプログラムを思い切り暴れさせることによってのみ、真のメンテナンスフリーな無人経済圏は完成するのである。
10. アーキテクチャ・インフォグラフィック設計図
本記事のエッセンス（外部世界からの攻撃や内部バグによる破壊のエネルギーが、Wasmサンドボックスの壁によって完全に遮断され、ホストOSが無傷に保たれる構造）を視覚的に理解させるためのインフォグラフィックの配置およびビジュアル設計図である。
=========================================================================================
【インフォグラフィック設計図】 Wasmサンドボックスによる「完全防爆区画」の迎撃構造
=========================================================================================
┌─────────────────────────────────────────────────────────────────────────────┐
│ ホストVPSインフラ層 (月額数百円の格安土地) │
│ │
│ [Nginx 常駐サーバー] [OS カーネル / ファイルシステム] [他サイトの資産] │
│ │
═══════════════════════════════════════════════════════════════════════════════════════
▲ 堅牢なる防爆壁 (Wasmtime ランタイムによる境界線ガード)
┌─────────────────────────────────────────────────────────────────────────────┐
│ 【 Wasm サンドボックス内部：完全隔離された実験室 】 │
│ │
│ [破綻シナリオ A] [破綻シナリオ B] │
│ AIから注入された プログラムのバグによる │
│ プロンプトインジェクション メモリ境界外への不正アクセス │
│ │ │ │
│ ▼ ▼ │
│ 💥 制御不能の暴走！ 💥 バッファオーバーフロー発生！ │
│ │
│ ================== 境界線チェック（MMU / JIT） ================== │
│ │ │ │
│ ▼ (メモリ空間の外へ破壊のエネルギーが飛び出そうとするが…) │
│ 🛑 サンドボックスの線形メモリ上限壁に衝突して「即座に蒸発」 │
│ │
│ ——————————————————————— │
│ ★ WASIによる最小特権の窓口 (`preopened_dir`) │
│ ・指定された `/storage` ディレクトリ以外へのアクセス要求は門前払い │
└─────────────────────────────────────────────────────────────────────────────┘
│
▼ (ホストOS側への安全な還流)
┌─────────────────────────────────────────────────────────────────────────────┐
│ ホストOS層は 1ミリも無傷 / 他のプロセスも 1ミリ秒の瞬断なく平然と駆動継続 │
│ – ランタイムがトラップを回収し、エラーログを Discord へ静かに射出 │
└─────────────────────────────────────────────────────────────────────────────┘
=========================================================================================
【防爆統治の3大原則】
1. 処理ごとにWasmインスタンスを完全分離し、障害の「爆破半径」を極限まで狭めよ
2. 起動の速さをレバレッジし、タスクごとに使い捨てる「ステートレス駆動」でメモリ漏れを根絶せよ
3. WASIのケイパビリティベース認可を徹底し、プログラムに「余計な土地勘」を与えるな
=========================================================================================
結果:
この強固な防爆サンドボックス環境により、どれほど過酷なバグや外部の攻撃が押し寄せようとも、インフラ全体を絶対安全に守り抜く盾を手に入れました。しかし、この防爆室に閉じこもったままでは、サーバーのディスクにCSVデータを保存したり、外部のWebAPIと通信を交わすための「具体的な手続き」ができません。
次話
この隔離された安全な殻の中から、ホストOSの機能と安全かつ規格化された方法で会話を成立させるための世界標準の架け橋である
「基礎編 #10：WASI（WebAssembly System Interface）の基礎：ブラウザの外でファイルやネットワークを触る鍵」