要旨
第一世代のAI Harnessは、出力がpassしたかを見る。第二世代は、agentがpolicy gateを守ったかを見る。MARIA OSに必要なのは第三世代である。失敗を、安全でreview可能でMemoryに基づくsystem improvementへ変換するMARIA Self-Healing Runtimeである。
Agentic Systemは最終出力だけで失敗するのではない。routing、retrieval、tool call、token消費、authority escalation、artifact生成、外部system連携の途中で失敗する。観測器は失敗を検知できる。Gateは失敗を止められる。しかしOSにはさらに、原因を分析し、境界付き改修を計画し、PRを作り、証跡を再検証し、次回の予防ruleとして記憶するloopが必要である。
0. 本質
本質は、自律修復できることではない。安全に自律修復できることである。安全性はloopの最後に足す飾りではない。Failure Analyzer、Meta-Harness、Envelope、Memory Store、Human Approval Gate、Loop Controlという6つの構造そのものである。
この章を先頭に置く理由は、忙しい読者が最初の30秒で全体像を掴めるからである。以降の章は、この一文を実装へ落とすための詳細である。runtimeは診断し、patchし、replayし、学習してよい。しかし不確実性を隠し、reviewを迂回し、自分のgateを弱め、速度を責任より優先してはならない。
対外名称はMARIA Self-Healing Runtimeに統一するのがよい。Self-Healingは既存infra領域で理解されやすく、MARIAを先頭に置くことで御社固有のruntime capabilityとして記憶される。CI/CD、E2E、Prompt/RAG、Agent Workflow、Preventive Harnessまでを含む名前としても自然である。
1. Open-loop gateからclosed-loop repairへ
Policy Harnessはopen-loopな安全機構である。振る舞いを観測し、rule違反時に止める。これは必要だが、agent infrastructureには十分ではない。すべての違反が人間待ちになると安全だが改善が蓄積しない。すべての違反が自動patchになると速いが、recursive self-permissionの危険が出る。
MARIA Self-Healing Runtimeは中間の道である。observe、diagnose、plan、repair、replay、approve、deploy、monitor、learnを明示的なstability marginの中で回す。systemを改善してよい。しかし自分自身の改善権限を決めるauthority contractを書き換えてはならない。
2. Failure Analyzerが上限を決める
Failure Analyzerはloop全体の上限である。DB schema driftをUI defectと誤分類すればPatch Plannerは誤ったfileを触る。Authority violationをprompt品質問題として扱えばFixer Agentがgovernanceを弱める。分類品質は補助機能ではなく、最初の安全面である。
Analyzerは三層にする。第1層はDeterministic Analyzerで、log signature、HTTP status、schema diff、type error、route name、changed file、permission policy、CI jobを読む。第2層はLLM Analyzerで、requirement contradiction、prompt ambiguity、responsibility boundary mismatch、business-process driftなど意味的な失敗に原因仮説を出す。第3層はMemory Analyzerで、過去の類似failure episode、repair PR、review decision、rollback outcome、recurrence patternを照合する。
分類には必ずconfidenceを付ける。confidenceが低い場合は自動改修せず、evidence、候補分類、confidence、owner、次に実行すべき診断commandを添えてhuman escalationにする。KPIは誤分類率、人間エスカレーション率、同一失敗の再発率、自律改修成功率、平均復旧時間である。
3. 個別Harness、横断Harness、Meta-Harnessの順序
修復は順序を固定する。まず個別Harnessで患部が治ったかを確認する。次に横断Harnessで他を壊していないかを確認する。次にMeta-Harnessで必要なHarnessが揃っているかを見る。その後にDeploy Harness、Post-Deploy Harnessへ進む。
この順序を崩すと、局所修復で全体を壊す。Global harnessを先に走らせるとnoiseが増え、因果が見えにくい。Local harnessだけで終えると、UI修正がAPI前提を壊したり、API修正がaudit traceを弱めたりする。
4. Meta-Harness
横断Harnessがあっても、Coverageが抜けることはある。新しいAPI routeが追加されたのにAPI Contract Harnessがない。新しい画面が増えたのにE2E Harnessがない。新しいAgent、外部連携、権限、promptが追加されたのに対応Harnessがない。この抜け漏れを検知するのがMeta-Harnessである。
Meta-Harnessの問いは単純である。systemに新しいsurfaceが増えた時、どのHarnessが責任を持つのか。答えがなければ、safeと見なさずcoverage gapとしてPRやrelease gateに出す。
5. Memory Storeを再発防止資産にする
Memory Storeはlog倉庫ではない。再発防止資産である。保存項目は、失敗内容、原因分類、証拠、修正差分、修正理由、再実行結果、副作用の有無、人間レビューコメント、人間レビュアーの判断根拠、再発防止rule、次回検知pattern、関連Harnessである。
人間レビュアーの判断根拠を独立項目にする価値は大きい。コメントは表層であり、rationaleはなぜsafe、unsafe、incomplete、approval-worthyと判断したかを構造化する。これによりMemory Analyzerは、機械の失敗patternだけでなく、人間がどこで責任を戻すかの推論patternを学べる。
これはMARIA OSの哲学と整合する。systemは失敗から改善してよい。しかし最も価値のある学習信号は、人間がどの根拠で責任境界を判断したかである。
6. Fixer Agent Envelope
Autonomous Fixer Agentは何でも直してよい存在ではない。Low Risk Envelopeではtest追加、型修正、文言修正、軽微UI修正をdraft PRまで許可する。Medium Risk EnvelopeではAPI仕様、DB read系、prompt、RAG設定をPR作成後に人間reviewへ戻す。High Risk Envelopeでは本番DB、請求、メール送信、権限、契約、外部送信を提案までに止める。Memory Write Envelopeでは学習書き込みにReviewer Agent承認を要求する。
これにより、誰の権限で直したのか、どこまで自動でよいのか、どこから人間責任へ戻すのかが明確になる。特に、自分自身のrepair permissionを決めるruleは自動改修できない。提案はできるが適用はできない。
7. Loop Control
Self-healingは、前回のpatchが作った症状を次のpatchで追い続けると不安定になる。最初からloop controlが必要である。incidentごとの最大改修回数、同一signatureの再試行上限、rollback-first patch、cost ceiling、authority drift時のescalation、flakyまたはhigh-risk loopのquarantineを入れる。
実務上の初期policyは保守的でよい。incidentごとに3回まで。同一failure signatureは2回まで。High-risk changeは自動mergeしない。本番DB、billing、outbound communication、permission、contract、constitutional policyは人間承認。Cost spikeやconfidence collapseでは自動停止する。
8. 実装Phase
Phase 1はCloud Build/GitHub Actions失敗の自動診断と修正PR。Phase 2はE2E失敗のUI/API/DB root cause mapping。Phase 3はLLM/RAG/Prompt品質Harnessとbounded improvement。Phase 4はAgent Workflow失敗、routing改善、human escalation。Phase 5はHarness Coverage Meta-Harness。Phase 6はHarness間依存関係推定。Phase 7はFailure Memory Storeによる再発防止。Phase 8はPreventive Harnessで失敗前に危険な変更を検知する。
Phase 9は、追加実装というよりstatement of completionと外部公開のphaseである。Phase 8まで成立した時点で技術的にはほぼSelf-Healing Runtimeである。Phase 9では、MARIA Self-Healing Runtimeとして名称を確定し、operating modelを公開し、KPIとmeasurement standardを示す。
9. PRを最終単位にする
初期段階で本番自動反映まで進める必要はない。むしろ進めない方がよい。MARIA Self-Healing Runtimeの最初の完成単位はdeployではなくPRである。検知、原因分析、修正案、修正PR、個別Harness、横断Harness、Meta-Harness、人間承認、deployという順序を固定する。これにより、AIによる改修がblack boxにならず、review可能なengineering artifactとして残る。
PR本文には、何が壊れていたか、なぜこの修正なのか、どのHarnessで検知したか、どのHarnessを再実行したか、副作用risk、rollback方法、Memory更新内容を必ず含める。特に重要なのはrollbackとMemory更新である。Rollbackがないpatchはrepairではなくmutationである。Memory更新がないpatchは、同じ失敗を次回も初見として扱うことになる。
このPR-first設計は、組織の責任境界とも相性がよい。Fixer Agentは差分を作り、Harnessは証跡を作り、Reviewer Agentは一貫性を見て、人間は高リスク判断を承認する。誰が何をしたのかがPR上に並ぶため、AI改修を導入しても責任が霧散しない。MARIA OSにとってPRは単なるGitHub上の作業単位ではなく、agentic systemが自己改善するときの責任containerである。
10. KPIをMeasurement Standardにする
MARIA Self-Healing Runtimeを対外的に強くするには、機能名だけでは足りない。測定指標を先に握る必要がある。MTTR、HITL convergence、人間エスカレーション率、誤分類率、同一失敗の再発率、自律改修成功率、coverage gap detection rate、repair regret、rollback rate。これらを公開できる形で設計すると、MARIA OSは単にself-healingを名乗るのではなく、AI infrastructure resilienceの測定標準を提示できる。
ここで大事なのは、成功率だけを追わないことである。自律改修成功率が上がっても、誤分類率やrepair regretが上がるならsystemは危険になっている。人間エスカレーション率が下がっても、高リスクcaseまで自動化しているだけなら改善ではない。MTTRが短くなっても、Memory Storeに再発防止ruleが残らないなら、次のincidentで同じ時間を失う。
したがってscorecardは複数軸で見る。速度のKPIはMTTRとtime to PR。品質のKPIはrepair success rateとcross-harness pass rate。安全のKPIはmisclassification rate、authority drift escalation、repair regret。学習のKPIはrepeat failure rate、memory hit rate、new harness proposal rate。網羅性のKPIはcoverage gap rateとmeta-harness closure timeである。このmulti-axis scorecardがあると、self-healingが単なる自動化ではなく、運用される制御systemになる。
11. MVPはCI/CD修復から始める
最初に作るべきMVPは、MARIA OS全体の自律改善ではない。CI/CD failureを直してPRを出すsystemで十分である。Cloud Build Failure Harness、GitHub Actions Failure Harness、E2E Failure Harness、API Contract Harness、Failure Store、Analyzer Agent、Patch Planner、Fixer Agent、PR Generator、Regression Runner、Memory Store、Human Approval Gate。この範囲なら、失敗の入口が明確で、証跡も残り、reviewも既存開発workflowに乗せやすい。
CI/CDから始める理由は、failure signalが構造化しやすいからである。job名、exit code、stack trace、changed files、test name、Playwright trace、build log、type error、route pathが取れる。Deterministic Analyzerが強く働くため、最初からLLM reasoningに依存しすぎない。confidenceが低い場合は人間へ戻し、高い場合だけPatch Plannerへ進める。この順序は、production AIに必要な保守性を作る。
E2E、RAG、Agent Workflowへ広げるのはその後でよい。E2EではUI、API、DB、permissionの境界が絡む。RAGではsource freshness、retrieval scope、prompt policy、answer evidenceが絡む。Agent Workflowではrouting、authority、human escalation、external actionが絡む。難しい領域へ広げる前に、CI/CDでFailure Analyzer、Envelope、PR Generator、Regression Runner、Memory Storeの基本loopを鍛えるべきである。
12. カテゴリ定義
Agent governanceはautonomyをaccountableにする。Self-healing agent infrastructureは、accountable autonomyを制約下で改善し続ける。ここにカテゴリ差がある。前者はagentを管理する。後者はagentic organizationを disturbance の中で保つruntime nervous systemを運用する。
MARIA OSはresponsibility gate、evidence trail、runtime episode、approval boundaryをfirst-class architectureとして扱っている。MARIA Self-Healing Runtimeはこれらをrepair loopとして接続する。FDE knowledgeをMemory Store資産にし、CI failureをrepair PRにし、prompt failureをreplayable episodeにし、organizational driftをowner-routed interventionに変える。
MTTR、HITL convergence、failure recurrence、misclassification rate、coverage gap detectionをfirst-class product metricとして公開できれば、MARIA OSはAI infrastructure resilienceのmeasurement standardを握れる。
13. 対外説明の型
対外的には、MARIA Self-Healing Runtimeを「AI Agentや業務systemの失敗を検知するだけでなく、原因分析、改修計画、修正PR、再検証、学習までを自律的に実行するruntime」と説明するのがよい。ただし、必ず次の一文を添える。高リスク変更はHuman Approval Gateを越えない。これがないと、Self-Healingは便利な言葉ではなく危険な印象になる。
投資家やCTOに対しては、技術構成よりもoperating outcomeを先に示す。たとえば、CI failureのMTTRを短縮する。E2E failureの原因分類を高速化する。同じ失敗の再発率を下げる。新しいAPIや画面にHarnessがない状態をMeta-Harnessで検知する。自動修正PRにはrollback、side-effect risk、Memory updateが必ず付く。この説明順にすると、Self-Healingが単なる自動化ではなく、enterprise infrastructure resilienceの話として伝わる。
技術者に対しては、architecture objectを先に示す。Failure Episode、Failure Analyzer、Patch Planner、Fixer Agent、Regression Runner、Harness Coverage Meta-Harness、Failure Memory Store、Human Approval Gate、Loop Controllerである。各objectは独立してtest可能で、PR上に証跡を残し、authority boundaryを越える時はfail-closedする。これにより、実装担当者はどこから作り始めればよいかを理解できる。
顧客に対しては、AIが勝手に本番を変えるsystemではないと明確に伝えるべきである。MARIA Self-Healing Runtimeは、失敗を見つけ、原因を分け、修正候補を作り、検証し、review可能な形にする。人間の承認が必要な領域では止まる。つまり、AIの速度を使いながら、最終責任が必要な箇所では人間へ戻すruntimeである。
14. 社内仕様としての使い方
この設計文書はWhitepaperだけではなく、社内仕様書としても使える。まず、Memory Storeのschemaを決める。failure_id、surface、coordinate、deterministic_classification、llm_hypothesis、memory_matches、confidence、evidence_paths、patch_diff、patch_rationale、rerun_result、side_effects、review_comment、reviewer_rationale、prevention_rule、next_detection_pattern、related_harnessesを持たせる。これで、失敗DBではなく再発防止資産としての最小schemaになる。
次に、Envelope policyを実装する。Low Riskはtest、type、copy、local UIに限定し、draft PRまで許可する。Medium RiskはAPI contract、DB read、prompt、RAG設定をreview必須にする。High Riskはproduction DB、billing、email、permission、contract、external sendを提案までに止める。Memory WriteはReviewer Agent承認を要求する。このpolicyはcode上の差分量ではなくauthority impactで判定する。1行のthreshold変更でもhuman escalationを減らすならHigh Riskに近い。
最後に、Loop ControlをCI/CDから始める。1 incidentあたり3回、同一signatureは2回、confidence低下で停止、cost spikeで停止、同一patch areaの反復失敗でquarantine、rollback不明ならPR生成不可。この制御があると、Fixer Agentは失敗圧力の中でも局所最適化に流れにくくなる。Self-Healingを安全にするのは、賢いpatch生成よりも、この停止条件の明確さである。
結論
テストするHarnessは有用である。GateするHarnessは安全である。診断し、修復し、再検証し、学習し、自分自身のresponsibility envelopeを保存するHarnessはinfrastructureになる。
難しいのはpatch生成ではない。改修をbounded、reviewable、replayableにし、自分自身へ追加権限を与えられないようにすることである。だからMARIA Self-Healing Runtimeはautomation機能ではない。accountabilityを失わず改善し続けるagentic systemのruntime governance layerである。