概要
国際監査基準（ISA）およびJICPA基準に成文化された監査手続は、本質的に散文に偽装された実行可能な仕様である。各基準は前提条件、必要な証拠、判断ロジック、事後条件を定義している — ソフトウェア関数と同じ構造である。しかし監査の実行は依然として手作業の紙ベースプロセスであり、経験豊富な専門家が文書化された基準をアドホックなワークフローに変換し、各ステップでトレーサビリティを失い、不整合を生じさせている。
本論文ではAudit Universe Runtimeを紹介する — MARIA OSガバナンスフレームワーク内のマルチエージェント実行エンジンであり、監査手続をファーストクラスのランタイム・オペレーションとして扱う。ISAおよびJICPA基準を型付きエージェントタスク定義にコンパイルし、不変の監査証跡を持つガバナンスされたパイプラインを通じて実行し、精密に定義された重要性閾値で人間-エージェント協働を調整する。その結果は「AIが監査人に取って代わる」ことではなく、監査手続が人間の権限の下で自らを実行することである — すべての判断コールがトレース可能で、すべてのサンプルが統計的に正当化され、すべての結論がその裏付けとなる証拠に形式的に紐付けられている。
1. 実行可能な仕様としての監査手続
Audit Universe Runtimeを駆動する洞察は構造的なものである：ISA基準はすでに実行可能なプログラムのセマンティクスを含んでいる。ISA 500（監査証拠）を例に取ろう。監査人は十分かつ適切な監査証拠を入手するために監査手続を立案し実施しなければならないと規定している。これは以下に分解される：（a）証拠の十分性述語、（b）証拠の適切性分類器、（c）手続選択関数、（d）実行プロトコル。
この分解を監査手続仕様（Audit Procedure Specification: APS）として形式化する：
// Audit Procedure Specification — ISA/JICPA基準からコンパイル
interface AuditProcedureSpec {
id: string // e.g., "ISA-500-AP-03"
standard: "ISA" | "JICPA"
standardRef: string // e.g., "ISA 500.6(a)"
preconditions: PredicateExpr[] // 実行前にすべて成立する必要がある
requiredEvidence: EvidenceRequirement[]
samplingStrategy: SamplingConfig
assertionsCovered: AuditAssertion[] // 実在性、網羅性、評価等
executionSteps: ProcedureStep[]
postConditions: PredicateExpr[] // 実行後にすべて成立する必要がある
materialityThreshold: MonetaryAmount
humanGate: GateConfig // 人間の監査人にエスカレーションする条件
}
interface ProcedureStep {
order: number
action: AgentAction
evidenceOutput: EvidenceType
failMode: "halt" | "flag" | "escalate"
timeout: Duration
coordinate: MARIACoordinate // このステップを担当するAgent
}
type AuditAssertion =
| "existence"
| "completeness"
| "valuation"
| "rights_and_obligations"
| "presentation_and_disclosure"
| "accuracy"
| "cutoff"
| "classification"各ISA基準は1つ以上のAPS定義に解析される。コンパイルプロセスは生成的ではなく、基準の規範的要求事項から型付きインターフェースへの構造的マッピングである。基準が「監査人は〜しなければならない」と記述する箇所では、failMode: "halt"を持つProcedureStepを生成する。「監査人は〜を考慮すべきである」と記述する箇所では、failMode: "flag"と人間ゲートを持つステップを生成する。
2. ISA/JICPA基準からエージェントタスクへのマッピング
Audit Universeは基準レジストリを維持する — すべてのISAおよびJICPA基準をエージェントタスク仕様にマッピングしたコンパイル済みデータベースである。レジストリはバージョン管理され不変である：基準が更新されると新しいバージョンが追記され、決して上書きされない。これにより、過去のエンゲージメントがどのバージョンの基準に準拠していたかを証明する能力が保持される。
| 基準 | エージェントタスク領域 | 対象アサーション | エージェント数 |
|------|---------------------|----------------|-------------|
| ISA 240 | 不正リスク評価 | すべて | 3 |
| ISA 315 | リスクの識別と評価 | すべて | 5 |
| ISA 330 | 評価したリスクへの対応 | すべて | 4 |
| ISA 500 | 証拠の収集と評価 | すべて | 6 |
| ISA 520 | 分析的手続 | 網羅性、評価 | 2 |
| ISA 530 | 監査サンプリング | すべて（間接） | 3 |
| ISA 540 | 会計上の見積り | 評価、網羅性 | 4 |
| ISA 550 | 関連当事者取引 | 実在性、開示 | 2 |
| ISA 570 | 継続企業の評価 | すべて | 3 |
| JICPA IT委 | IT全般統制テスト | 網羅性、正確性 | 4 |
| JICPA品基報 | 品質管理基準 | N/A（メタ） | 2 |各エージェントタスクはMARIA座標系から責任制約を継承する。座標G1.U2.P1.Z1.A3のISA 315リスク評価エージェントは、明示的なクロスゾーン認可なしにはゾーン境界外の証拠にアクセスできない — ISA 220が要求する職務の分離を強制する。
3. 証拠収集の自動化
証拠は監査の基本通貨である。Audit Universe Runtimeは、監査証拠の取得・検証・アサーションへの紐付けを自動化する証拠収集エンジンを実装する。
interface EvidenceBundle {
id: string
engagementId: string
procedureRef: string // AuditProcedureSpec.idへのリンク
assertionsCovered: AuditAssertion[]
sources: EvidenceSource[]
collectedAt: ISOTimestamp
collectedBy: MARIACoordinate // Agent座標
verificationStatus: "unverified" | "auto_verified" | "human_verified"
hashChain: string // 不変性のためのSHA-256チェーン
sufficiencyScore: number // 0.0 - 1.0
appropriatenessScore: number // 0.0 - 1.0
}
interface EvidenceSource {
type: "erp_extract" | "bank_confirmation" | "document_scan"
| "external_api" | "management_representation" | "recomputation"
rawPayload: EncryptedBlob
extractedAt: ISOTimestamp
sourceSystem: string
reconciliationKey: string // クロスリファレンス用
}
// 証拠の十分性は継続的に評価される
function evaluateSufficiency(
bundle: EvidenceBundle,
requirement: EvidenceRequirement,
materialityThreshold: MonetaryAmount
): SufficiencyResult {
const coverage = computeAssertionCoverage(bundle, requirement)
const reliability = assessSourceReliability(bundle.sources)
const sufficiency = coverage * reliability
return {
score: sufficiency,
sufficient: sufficiency >= requirement.minimumThreshold,
gaps: identifyEvidenceGaps(bundle, requirement),
recommendation: sufficiency < 0.7
? "additional_procedures_required"
: "sufficient"
}
}エンジンはプルモデルで動作する：監査手続が証拠を必要とするとき、型付き証拠リクエストを発行する。証拠収集エンジンは接続されたソースシステム（ERP、銀行ポータル、文書管理）にクエリを送信し、抽出トランスフォーマーを適用し、検証済みのEvidenceBundleを返すことでリクエストを解決する。すべてのバンドルは収集後の改ざんを防ぐためにハッシュチェーンで連結される。
4. サンプリング戦略エージェント
ISA 530は、監査サンプリングが結論の合理的な基礎を提供するよう設計されることを要求する。Audit Universe Runtimeは、統計的に有効なサンプルサイズを計算し、適切な方法でサンプルを選択し、許容虚偽表示閾値に対して結果を評価する専用のサンプリング戦略エージェントを実装する。
サンプリングの判断は以下のように形式化される：
n = \frac{N \cdot z_{\alpha/2}^2 \cdot p(1-p)}{(N-1) \cdot e^2 + z_{\alpha/2}^2 \cdot p(1-p)}ここでNは母集団サイズ、zは信頼係数、pは予想誤謬率、eは許容誤差である。サンプリングエージェントは、関連するアサーションに対する重要な虚偽表示のリスク評価に基づいて、これらのパラメータを動的に調整する。
interface SamplingDecision {
method: "monetary_unit" | "classical_variable" | "attribute" | "stratified"
populationSize: number
sampleSize: number
confidenceLevel: number // e.g., 0.95
tolerableError: MonetaryAmount
expectedError: MonetaryAmount
riskOfMaterialMisstatement: "low" | "moderate" | "high"
selectionMethod: "random" | "systematic" | "haphazard" | "stratified_random"
stratification?: StratificationConfig
projectedMisstatement?: MonetaryAmount // 評価後
}
// 貨幣単位サンプリング（MUS）— 過大計上テストに推奨
function computeMUSSampleSize(
bookValue: number,
materialityThreshold: number,
confidenceLevel: number,
expectedMisstatement: number
): number {
const reliabilityFactor = getReliabilityFactor(confidenceLevel, 0)
const adjustedMateriality = materialityThreshold - expectedMisstatement
return Math.ceil((bookValue * reliabilityFactor) / adjustedMateriality)
}重要なのは、サンプリングエージェントが単にサンプルサイズを計算するだけではないことである — すべてのサンプリング決定を、選択されたパラメータを評価されたリスクレベル、母集団の性質、テスト対象の特定のアサーションにリンクするSamplingRationale文書を生成することで正当化する。この根拠は不変の監査証跡の一部となる。
5. リスク評価ランタイム
ISA 315（2019年改訂）は、監査人が事業体とその環境の理解を通じて重要な虚偽表示のリスクを識別し評価することを要求する。リスク評価ランタイムは、これを時点での活動ではなく継続的な評価エンジンとして実装する。
従来の監査はリスク評価を計画段階の活動として扱う。Audit Universe Runtimeはリスクを継続的に評価する — 証拠が収集されるとき、取引が処理されるとき、異常が検知されるとき。リスクスコアは生きた値であり、リアルタイムで監査対応の再評価をトリガーする。リスクモデルはISA 315の構造に従って3層に分解される：
AR = IR \times CR \times DRここでARは監査リスク、IRは固有リスク、CRは統制リスク、DRは発見リスクである。ランタイムはこれらを離散的カテゴリではなく連続変数として維持し、監査対応の強度の精密なキャリブレーションを可能にする。
interface RiskAssessment {
entityId: string
assessmentCycle: number
inherentRisk: RiskVector // アサーションごとのリスクスコア
controlRisk: RiskVector // 統制テストから評価
detectionRisk: RiskVector // 目標監査リスクを達成するために算出
significantRisks: SignificantRisk[]
riskResponses: RiskResponse[] // ISA 330の対応
lastUpdated: ISOTimestamp
triggerEvents: RiskTriggerEvent[] // 再評価のトリガーとなった事象
}
interface RiskVector {
existence: number // 0.0 - 1.0
completeness: number
valuation: number
rights: number
presentation: number
accuracy: number
cutoff: number
classification: number
}リスクスコアが事前定義された閾値を超えると、ランタイムは計画された監査対応を自動的に調整する — サンプルサイズの増加、実証的手続の追加、または責任ゲートを通じた人間パートナーレビューへのエスカレーション。
6. 実証的テスト実行エンジン
実証的手続 — 詳細テストと実証的分析手続 — は監査証拠収集の中核を形成する。実行エンジンはこれらを並行エージェントワークフローとしてオーケストレーションし、依存関係の順序と証拠の前提条件を尊重する。
エンジンは実証的テストをステートマシンを通じて処理する：
type SubstantiveTestState =
| "queued"
| "prerequisites_checking"
| "sampling"
| "executing"
| "evaluating_results"
| "anomaly_review"
| "concluded"
| "escalated"
interface SubstantiveTestExecution {
procedureId: string
state: SubstantiveTestState
sampleSelected: SamplingDecision
itemsTested: number
itemsWithExceptions: number
projectedMisstatement: MonetaryAmount
conclusionReached: boolean
evidenceBundles: EvidenceBundle[]
anomaliesDetected: AnomalyRecord[]
validTransitions: Map<SubstantiveTestState, SubstantiveTestState[]>
}
// ステートマシンは有効な遷移を強制する
const VALID_TRANSITIONS: Record<SubstantiveTestState, SubstantiveTestState[]> = {
queued: ["prerequisites_checking"],
prerequisites_checking: ["sampling", "escalated"],
sampling: ["executing"],
executing: ["evaluating_results"],
evaluating_results: ["concluded", "anomaly_review", "escalated"],
anomaly_review: ["concluded", "escalated"],
concluded: [],
escalated: ["queued"] // 人間レビュー後に再キューイング可能
}各実証的テストは、予測虚偽表示、勘定残高が重要な虚偽表示を含む可能性の評価、結論を支持する証拠チェーンを含む形式的な結論を生成する。エンジンは、証拠の十分性スコアが関連するアサーションの最小閾値を満たさない限り、テストがconcluded状態に到達することを防止する。
7. 監査証跡の不変性
監査証拠の完全性は、証拠・結論・判断が事後的に検知されずに変更されないことの保証に依存する。Audit Universe Runtimeは、ハッシュチェーン証拠台帳を通じて不変性を実装する。
interface AuditTrailEntry {
sequence: number
timestamp: ISOTimestamp
actorCoordinate: MARIACoordinate
action: AuditAction
payload: EncryptedPayload
previousHash: string
currentHash: string // SHA-256(sequence + timestamp + action + payload + previousHash)
signature: AgentSignature // 実行Agentの暗号署名
}
function appendToTrail(
trail: AuditTrailEntry[],
action: AuditAction,
payload: unknown,
actor: MARIACoordinate
): AuditTrailEntry {
const previous = trail[trail.length - 1]
const entry: AuditTrailEntry = {
sequence: previous.sequence + 1,
timestamp: getCurrentTimestamp(),
actorCoordinate: actor,
action,
payload: encrypt(payload),
previousHash: previous.currentHash,
currentHash: "",
signature: signWithAgentKey(actor)
}
entry.currentHash = computeHash(entry)
return entry
}
// 検証：チェーン内の改ざんを検出
function verifyTrailIntegrity(trail: AuditTrailEntry[]): IntegrityResult {
for (let i = 1; i < trail.length; i++) {
const recomputed = computeHash({ ...trail[i], currentHash: "" })
if (recomputed !== trail[i].currentHash) {
return { valid: false, brokenAt: i, reason: "hash_mismatch" }
}
if (trail[i].previousHash !== trail[i - 1].currentHash) {
return { valid: false, brokenAt: i, reason: "chain_break" }
}
}
return { valid: true }
}ランタイム内のすべてのアクション — 証拠収集、サンプリング決定、リスク再評価、テスト結論、人間によるオーバーライド — はハッシュチェーンにエントリを追記する。チェーンはエンゲージメント終了時、品質レビューチェックポイント、および規制当局の照会時に検証される。各エントリが前のエントリのハッシュを含むため、過去の記録を変更するとそれ以降のチェーン全体が無効化される。
8. 監査人-エージェント協働モデル
Audit Universe Runtimeは人間の監査人を置き換えることを目指していない。エージェントが手続的な実行を担い、人間が判断集約的な意思決定の権限を保持する段階的協働モデルを実装する。
| 判断の種類 | エージェント権限 | 人間の権限 | ゲートトリガー |
|-----------|---------------|-----------|-------------|
| 算出パラメータからのサンプル選定 | 完全 | なし | なし |
| ソースシステムからの証拠抽出 | 完全 | 例外時レビュー | ソース利用不可 |
| ルーティン照合（< 重要性/10） | 完全 | 抜取チェック | なし |
| 異常の分類 | 提案 | 確認/オーバーライド | 常時 |
| リスク評価の調整 | 提案 | 承認 | リスク増加 > 0.15 |
| 特別なリスクの識別 | フラグ | 決定 | 常時 |
| 継続企業の評価 | 証拠の編纂 | 完全な権限 | 常時 |
| 監査意見の形成 | 要約の編纂 | 完全な権限 | 常時 |
| エンゲージメントパートナーの署名 | N/A | 完全な権限 | 常時 |この協働モデルはMARIA OSの中核テーゼを体現する。エージェントは決定論的な監査手続の80% — 抽出、照合、再計算、サンプリング — を実行する。人間は専門的判断を必要とする20% — リスク評価、異常の解釈、継続企業の評価、意見形成 — に集中する。協働はMARIA OSの責任ゲートを通じて強制される。エージェントがその権限レベルを超える判断ポイントに達すると、ゲートが実行を停止し、事前にコンパイルされた証拠パッケージとともに判断を適切な人間の監査人にルーティングする。人間の判断は不変の証跡に記録され、そのアイデンティティに帰属し、レビューした証拠にリンクされる。
9. 監査中のリアルタイム異常検知
従来の監査は異常を遡及的に — テスト完了後の証拠評価中に — 発見する。Audit Universe Runtimeは、証拠収集と実証的テストと並行して動作するストリーミング異常検知を実装する。
interface AnomalyDetector {
type: "statistical" | "pattern" | "temporal" | "relational"
threshold: number
windowSize: number // スライディングウィンドウ内の取引数
detect(stream: TransactionStream): AsyncIterable<AnomalyCandidate>
}
interface AnomalyCandidate {
transactionIds: string[]
anomalyType: AnomalyClassification
severity: "low" | "medium" | "high" | "critical"
confidence: number // 0.0 - 1.0
explanation: string
suggestedProcedure: string // 実施すべき追加監査手続
relatedAssertions: AuditAssertion[]
}
type AnomalyClassification =
| "benford_violation" // 桁分布の異常
| "round_number_excess" // 端数金額の異常な頻度
| "timing_anomaly" // 期末付近に集中した取引
| "counterparty_concentration" // 取引先の異常な集中
| "reversal_pattern" // 操作を示唆する仕訳-取消パターン
| "segregation_violation" // 同一行為者が非互換的な役割に従事
| "threshold_manipulation" // 承認閾値直下の金額
| "journal_entry_anomaly" // 異常な手動仕訳異常検知システムは4つの並行検知器を実行する。統計検知器はベンフォードの法則分析、比率分析、分布テストを適用する。パターン検知器は既知の不正指標（端数バイアス、閾値操作）を識別する。時間検知器は期間境界付近に集中した取引や異常な時間帯に記帳された取引をフラグする。関係検知器は取引ネットワークをマッピングし、異常な取引先パターンや循環的な資金フローを識別する。
深刻度high以上の異常が検知されると、ランタイムは即座に人間ゲートをトリガーする — 監査人が発見事項をレビューするまで、関連する自動化手続を停止する。
10. 監査完全性の形式モデル
監査における根本的な問いは「十分に行ったか」である。Audit Universe Runtimeは、監査の完全性を主観的に評価するのではなく検証可能な数学的性質として形式化する。
監査完全性関数 C(E, A, M)を以下のように定義する：
C(E, A, M) = \min_{a \in A} \left( \frac{\sum_{e \in E_a} w(e) \cdot r(e)}{\theta(a, M)} \right)ここでEは収集されたすべての証拠の集合、Aはカバーすべきすべてのアサーションの集合、Mは重要性の閾値、E_aはアサーションaに関連する証拠の部分集合、w(e)は証拠項目eの重み（ソースの信頼性に基づく）、r(e)は証拠eのアサーションaに対する関連性スコア、theta(a, M)は重要性レベルMにおけるアサーションaの十分性閾値である。
監査は、すべての重要な勘定残高と取引種類についてC(E, A, M) >= 1.0のとき完了する。この関数は証拠が蓄積されるにつれて継続的に計算され、監査完了に向けたリアルタイムの進捗指標を提供する。
証拠収集が非破壊的（証拠が破棄されない）であり、証拠の重みが非負であれば、C(E, A, M)はエンゲージメント期間中に単調非減少である。これは完全性への進捗が不可逆であることを保証する — 従来の監査が形式的に主張できない性質である。11. 継続的監査 vs. 定期的監査エージェント
Audit Universe Runtimeは2つの実行モードをサポートする：定期モード（従来のエンゲージメントベースの監査）と継続モード（ローリング証拠蓄積によるリアルタイムモニタリング）。
| 次元 | 定期エージェント | 継続エージェント |
|------|---------------|---------------|
| 起動 | エンゲージメント開始日 | 常時稼働 |
| 証拠ウィンドウ | 会計期間 | ローリング30/90/365日 |
| リスク再評価 | 計画段階のみ | リスクトリガーイベントごと |
| サンプル選択 | サイクルごとに1回 | 適応的リサンプリング |
| 異常検知 | バッチ（収集後） | ストリーミング（リアルタイム） |
| 人間レビュー頻度 | マイルストーンベース | 閾値トリガー |
| レポート出力 | エンゲージメント終了時 | 日次/週次ダッシュボード |
| コストモデル | エンゲージメントごとの報酬 | サブスクリプション・リテーナー |継続的監査エージェントは新たな課題を導入する：証拠の陳腐化。6ヶ月前に収集された証拠は、事業体の統制環境が変化していれば、もはや現在のアサーションを支持しない可能性がある。ランタイムはこれを証拠減衰関数で対処する：
w_t(e) = w_0(e) \cdot e^{-\lambda(t - t_e)}ここでw_t(e)は時刻tにおける証拠eの重み、w_0(e)は収集時刻t_eにおける初期の重み、lambdaはソースシステムのボラティリティによって決定される減衰率である。高ボラティリティのソース（現金残高、在庫棚卸）は低ボラティリティのソース（固定資産台帳、長期借入金契約）よりも高い減衰率を持つ。
証拠の重みが十分性閾値を下回ると、継続エージェントは自動的に再収集をトリガーする — 手動のスケジューリングなしに監査の完全性を維持する。
12. 品質レビューゲートとエンゲージメント管理オーケストレーション
Audit Universe Runtimeは、ISA 220の品質管理要求事項をMARIA OSの責任フレームワーク内の形式的なゲート構造として実装する。
// MARIA座標から監査エンゲージメント構造へのマッピング
// Galaxy = 監査法人
// Universe = エンゲージメント（クライアント監査）
// Planet = 監査ドメイン（収益、費用、資産、負債、純資産）
// Zone = 勘定科目グループ（例：売掛金、貸倒引当金）
// Agent = 個別手続の実行者
interface EngagementOrchestrator {
coordinate: MARIACoordinate // G1.U2（法人.エンゲージメント）
engagementPartner: HumanIdentity
engagementQualityReviewer: HumanIdentity
planets: AuditDomain[]
qualityGates: QualityGate[]
timeline: EngagementTimeline
}
interface QualityGate {
id: string
name: string
trigger: "milestone" | "risk_event" | "completeness_threshold"
reviewLevel: "manager" | "partner" | "eqr" // 審査担当者
requiredEvidence: string[]
approved: boolean
approvedBy?: HumanIdentity
approvedAt?: ISOTimestamp
}
// エンゲージメントのライフサイクルをステートマシンとして定義
type EngagementPhase =
| "planning"
| "risk_assessment"
| "control_testing"
| "substantive_testing"
| "completion"
| "reporting"
| "archiving"
const ENGAGEMENT_GATES: Record<EngagementPhase, QualityGate[]> = {
planning: [
{ id: "QG-01", name: "エンゲージメント受嘱", trigger: "milestone",
reviewLevel: "partner", requiredEvidence: ["independence_confirmation",
"risk_acceptance_memo", "engagement_letter"], approved: false }
],
risk_assessment: [
{ id: "QG-02", name: "リスク評価承認", trigger: "milestone",
reviewLevel: "manager", requiredEvidence: ["risk_assessment_summary",
"significant_risks_memo"], approved: false }
],
control_testing: [
{ id: "QG-03", name: "統制の不備レビュー", trigger: "risk_event",
reviewLevel: "partner", requiredEvidence: ["control_test_results",
"deficiency_classification"], approved: false }
],
substantive_testing: [
{ id: "QG-04", name: "実証的手続完了レビュー", trigger: "completeness_threshold",
reviewLevel: "manager", requiredEvidence: ["completeness_matrix",
"misstatement_summary"], approved: false }
],
completion: [
{ id: "QG-05", name: "審査担当者レビュー", trigger: "milestone",
reviewLevel: "eqr", requiredEvidence: ["full_evidence_package",
"opinion_draft", "significant_judgments_memo"], approved: false }
],
reporting: [
{ id: "QG-06", name: "報告書発行承認", trigger: "milestone",
reviewLevel: "partner", requiredEvidence: ["signed_representations",
"final_analytics", "subsequent_events_review"], approved: false }
],
archiving: []
}エンゲージメントオーケストレーターは、エンゲージメントUniverse内のすべてのエージェントを調整し、フェーズの順序付け、ゲートの通過、リソース配分を強制する。リスク評価ゲート（QG-02）が人間のマネジャーによって承認されるまで、いかなるエージェントも実証的テストを開始できない。審査担当者レビューゲート（QG-05）がエンゲージメントチームから独立した人間の審査担当者によって承認されるまで、いかなる監査報告書も発行できない。
このアーキテクチャにより、Audit Universe Runtimeは高度な自動化にもかかわらず、専門的基準が要求する人間の権限構造を保持する。エージェントは手続を実行する。人間は判断を行使する。システムは、いかなる判断もバイパスされず、いかなる証拠も失われず、いかなる結論も形式的に十分な証拠基盤なしには到達されないことを保証する。
結論
Audit Universe Runtimeは、監査手続が単に自動化に適しているだけでなく、その本質的な構造においてすでに実行可能な仕様であることを実証する。ISAおよびJICPA基準は、前提条件、証拠要件、判断ロジック、品質ゲートを、エージェントタスク仕様にコンパイルするのに十分な精度で定義している。欠けていたのは監査ロジックの形式化ではなく、それを安全に実行するためのガバナンスインフラストラクチャである：不変の監査証跡、責任ゲート、段階的な人間-エージェント協働、形式的な完全性検証。
MARIA OSはこのインフラストラクチャを提供する。エンゲージメント構造をMARIA座標系にマッピングし、監査手続をガバナンスされたステートマシンとして実装し、すべての重要性に敏感な判断ポイントで人間の権限を強制することで、Audit Universe Runtimeは完全に手動でも完全に自動でもないアプローチが達成できないことを実現する：人間の権限の下で自らを実行し、完全性の数学的保証と不変の証拠チェーンを持つ監査手続。
監査の未来は、人工知能が専門的判断に取って代わることではない。すべての手続をトレース可能にし、すべてのサンプルを弁護可能にし、すべての結論をその証拠に形式的にリンクする、インテリジェントなランタイムを通じて専門的判断が運用されることである。