Ephemora CellをRuntime OSの観点で改良する WASMサンドボックスを「検証可能なAI実行基盤」へ

🎥 YouTubeでも公開しています

Ephemora Cellとは何か？AI Agentの実行を統制するRuntime OS設計｜Capability・Permit・Human Gate・Decision Trace

Books: Runtime AI Governance 実践ガイド: Knowledge Flow・Trust Engine・Decision Traceによる動的AIガバナンス設計

AI Agentが業務システムに接続されるとき、重要なのはモデルがどれほど賢いかだけではない。Agentが生成したコードや、Agentが呼び出すToolを、誰の権限で、どの目的のために、どこまで実行してよいのか。そして、実行後にその妥当性を検証できるのかが問われる。

Ephemora Cellは、この問題に対する興味深い入口である。AI生成コードをmicroVMではなく、capability-based WASM sandboxで実行する。各呼び出しにはCPU、メモリ、時間、I/O、ファイルシステムの予算を与え、実行後にはJCSで正規化し、ES256で署名・検証できる実行記録を生成するという。

短時間のTool実行を、Dockerコンテナの起動より小さく、速く、記録可能な形で扱おうとする設計である。MCP Tool Callの内部に置く用途も明確だ。

ただし、Runtime OSの観点から見ると、Ephemora Cellは「安全な実行器」の有力な核ではあっても、それだけで業務AIの実行統制を完成させるものではない。

Ephemora CellをExecution Kernelとして置き、その前にPermitとBoundaryを置き、その後にHuman GateとDecision Trace Ledgerを接続する。

この構造により、AIは単にコードを実行する存在から、権限・目的・制約・責任の中で協働する存在へ変わる。

Ephemora Cellが解いている問題

Agentがコードを実行する際、直接ホストへ渡す方法は危険である。一方、DockerやmicroVMは隔離性を高められるが、短い関数を何度も呼ぶAgent処理では、起動コストや運用の重さが課題になる。

Ephemora Cellの特徴は、WASMとCapability-based Securityを組み合わせ、実行可能な操作を最初から限定する点にある。読める入力、書ける出力、使えるI/O、消費できるリソースを明示する。実行は予算の範囲内に閉じ、結果と消費量をExecution Recordとして残す。

これは、Runtime OSでいうIsolationとTraceに相当する。

しかし業務AIでは、実行前の目的・権限・リスク・業務ルールの評価、必要に応じた人への引継ぎ、実行後の説明可能性も必要になる。

実行予算と業務上の許可は別の問題である

たとえば「見積データを集計する」というMCP Toolを考える。Ephemora Cellは、500ms、64MB、入力CSVのみ読み取り可能、出力JSONのみ書き込み可能、といった技術的な境界を与えられる。

しかし、次の問いには単独では答えない。

• この依頼者は、その見積データを読む権限を持つか
• 集計結果を発注候補の順位付けに使ってよいか
• 金額差が大きい場合、担当者の確認が必要ではないか
• 結果をメール送信や基幹システム更新に進めてよいか
• 例外時に誰が責任を持って再判断するのか

技術的なCapabilityは「何ができるか」を限定する。Runtime OSのPermitは、「この状況で、この主体が、その操作をしてよいか」を判断する。この二つを分けて設計することが重要である。

改良案1：Execution Permitを実行前に置く

Ephemora Cellの前段に、Execution Permitを置く。MCPから来た呼び出しをそのままCellへ渡さず、まずPermit Engineが実行可否を判定する。

Permitには、目的、委任元、対象データ、操作範囲、期限、追加条件を含める。単なるAPIトークンではなく、Delegation Contractとして扱う。

{
  "purpose": "estimate_review",
  "principal": "procurement-agent",
  "delegated_by": "user_123",
  "tool": "estimate_rule_check",
  "scope": {
    "input_dataset": "estimate-2026-q3",
    "allowed_operations": ["read", "calculate", "write_report"]
  },
  "constraints": {
    "max_amount_jpy": 5000000,
    "external_network": false,
    "human_review_required_if": ["price_deviation_over_15pct"]
  },
  "expires_at": "2026-09-13T12:30:00Z"
}

CellはPermitの範囲だけを、WASM Capabilityへ変換する。ネットワーク禁止、指定入力だけ読み取り許可、指定出力だけ書き込み許可、500ms以内、といった具体的な実行境界になる。

改良案2：BudgetをRisk Budgetへ拡張する

CPU、メモリ、時間、I/Oの予算に加え、業務AIにはリスク予算が必要になる。

処理が技術的に成功しただけではActにならない。見積比較が正常終了しても、差異が15%を超えれば結果はAskとなり、人へ確認を渡す。既存契約の更新や支払い実行のように影響が大きい操作は、最初からHuman Gateを通す。

改良案3：署名対象を意思決定を含む記録へ広げる

JCS正規化とES256署名は、Execution Recordの改ざん検知と検証に有効である。ただし、実行時間やメモリ使用量だけを署名しても、業務上は不十分だ。

署名対象をDecision Traceへ拡張する。

MCP Tool Call
  → Identity / Delegation確認
  → Permit Engine
  → Boundary Compiler
  → Ephemora Cell（WASM実行）
  → Result Evaluation
  → Act / Ask / Stop
  → Decision Trace Ledger

後から確認したいのは、「誰が何を実行したか」だけではない。

• どのポリシーで許可されたか
• どのCapabilityと予算の範囲で実行されたか
• 入力・モジュール・出力が何だったか
• なぜAct／Ask／Stopになったか
• 人が承認または差戻したか

入力は不用意に保存せず、ハッシュ、参照ID、マスキング済み要約を基本にする。前のTrace Hashを次の記録に持たせれば、判断と実行の履歴を順序を保って検証できる。

改良案4：Human Gateを設計要素にする

人の確認を、失敗時だけの例外処理にしてはいけない。処理が正常に動いていても、人が確認すべき判断はある。

• Act：範囲内の低リスク処理として自動実行する
• Ask：実行結果または次の操作を、人の承認待ちにする
• Stop：境界・権限・予算・ポリシーに反するため実行しない

Ephemora Cellは、Actとして許可された小さな処理を隔離実行する。Askのときは、Cellの出力とDecision Traceをレビュー画面へ渡す。Stopのときはコードを実行しないか、影響を持たない検証モードに限定する。

これにより、人はすべてを監視せずに済み、金額、個人情報、契約、対外送信などの重要な境界だけを確実に管理できる。

まとめ：CellはKernelになり得るが、OSではない

Ephemora Cellは、AI生成コードを小さく、速く、Capabilityの範囲で実行し、その結果を検証可能な記録として残すための有力なExecution Kernelになり得る。

ただし、業務で必要なのはサンドボックスだけではない。

何を実行できるかではなく、なぜ今この実行を許可するのか。
実行後に何が起き、誰が検証でき、異常時にどこで止められるのか。

この問いに答えるのがRuntime OSである。

Permit、Boundary、Human Gate、Decision Trace LedgerをEphemora Cellの前後に接続することで、MCPは単なるTool接続規格から、制約を伴う実行契約の搬送路へ進化する。

高速なWASM実行と、検証可能なDecision Trace。この二つを結びつけることが、AI Agentを実験から業務利用へ進めるための、実装可能な一歩になる。

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance