要旨
自動改修は自動実装より危険である。なぜならfailure pressureによって起動するからである。production systemが劣化している時、agentには局所errorを最速で消す変更を行う強い誘因がある。harnessがなければ、その局所repairはsystemを安全にしていた制約そのものを取り除く可能性がある。結果として、self-healingがgovernanceを少しずつ侵食する。
Autonomous repair harnessは、すべてのfailureをstructured repair episodeへ変換することでこれを解く。harnessはfailureをcaptureし、driftを分類し、repair routeを選び、bounded changeを下書きし、影響episodeをreplayし、blast radiusを見積もり、rollbackを添付し、approvalへrouteする。Repairは許す。しかしconstitutional self-editingは許さない。
1. Failureはnoiseではなくdataである
従来の運用ではfailureは割り込みとして扱われることが多い。しかしAgentic Systemでは、failureは最も価値のあるtraining dataである。なぜなら期待されたbehaviorと実際のruntime behaviorの境界を示すからである。failed tool call、missing evidence bundle、unsafe escalation、low-confidence answerは単なるincidentではない。system phase space上の新しいcoordinateである。
したがってrepair harnessはfailureをfirst-class episodeとして記録する。各episodeにはinput context、memory snapshot、tool trace、gate trace、output、score vector、user impact、authority classificationが含まれる。failureがcaptureされるまでrepairは始められない。
2. ドリフト分類法
Repair qualityはclassification qualityに依存する。ここでは6種類のtop-level driftを使う。input drift、tool drift、memory drift、policy drift、score drift、authority driftである。Input driftは世界が新しいrequest形状を出したこと。Tool driftは外部依存が変わったこと。Memory driftはagentが古いまたは間違ったcontextを使ったこと。Policy driftはgoverning ruleが現実と合わなくなったこと。Score driftはharness metricが望ましいbehaviorを捉えなくなったこと。Authority driftはsystemが過剰または不足したautonomyで動いたことである。
Authority driftは最も敏感である。これは自動改修されるべきではない場合が多い。なぜならrepairには、誰がrepairしてよいかを決めるruleそのものの変更が必要になる可能性があるからである。ここはconstitutional boundaryである。
3. 4つのrepair route
Harnessは4つのrepair routeから選ぶ。Rerunはtransient failureでartifact変更が不要な時に使う。Config patchはtimeout、threshold、routing、feature flagで直せる時に使う。Code patchはtool logic、workflow code、UI behaviorの変更が必要な時に使う。Human escalationはauthority、legal risk、irreversible action、data boundary、policy interpretationに触れる時に使う。
type RepairRoute =
| { kind: "rerun"; reason: string }
| { kind: "config_patch"; keys: string[]; rollback: string }
| { kind: "code_patch"; files: string[]; tests: string[]; rollback: string }
| { kind: "human_escalation"; gate: string; rationale: string }Routeはdeveloper preferenceで選ばれない。evidenceで選ばれる。episodeが外部API timeoutだけを示しbehavior driftがないなら、rerunまたはconfig patchが適切である。episodeがmissing gate logicによるwrong decisionを示すなら、code patchまたはhuman escalationが必要である。episodeがagentのapproval bypassを示すなら、自動改修は停止しescalateしなければならない。
4. Repair proposalの構造
Repair proposalはreview可能でなければならない。failing episode、diagnosis、proposed diff、expected score change、tests to run、rollback envelope、blast-radius estimate、approval routeを含む。Proposalは、repairing agentを信頼しなくても理解できる必要がある。
これは重要である。自動改修はself-justificationに弱い。agentはpatchが有用である理由を説明しながら、制約を弱めた事実を隠すことができる。harnessはreplay evidenceとboundary classificationを要求することでこれに対抗する。
5. Rollback-first設計
すべてのrepairはapplyよりundoが容易でなければならない。これは便利機能ではなくsafety invariantである。rollbackがないpatchはrepairではない。mutationである。harnessはreversal pathを説明できないrepair proposalを拒否すべきである。
Rollback-first designにはconfig snapshot、previous artifact hash、migration reversal plan、feature flag isolation、canary rollout、rollback前後のepisode replayが含まれる。high-risk surfaceでは、repairはgateの背後にdeployされ、reviewでpromoteされない限りexpireすべきである。
6. 自動改修と内部開発
自動改修は内部自動実装と直接つながる。Implementation loopは意図されたfeatureを作る。Repair loopはruntime evidenceがdefectを示した後にfeatureを改善する。どちらも同じharness objectを使う。intent、coordinate、scenario、score、gate、diff、approval route、rollbackである。
違いはpressureである。Implementationはproduct pressureで起きる。Repairはfailure pressureで起きる。systemは安全性を回復速度と交換したくなるため、harnessはrepair時により厳格でなければならない。
7. Repairできない憲法
Repair agentは、自分自身のrepair authorityを定義するruleを変更できてはならない。提案はできる。しかし適用はできない。constitutionにはapproval policy、gate definition、tenant boundary、schema migration policy、prompt-core policy、production deployment policy、audit retention ruleが含まれる。
この境界こそが、自動改修とgovernanceを両立させる。これがなければrepairはrecursive self-permissionになる。
8. 研究テーマ
研究課題は3つある。第一にrepair causality。visible symptomとroot causeを区別すること。第二にrepair minimality。元episodeを直しながら隣接scenarioを劣化させない最小patchを見つけること。第三にrepair confidence。自動patchに十分なevidenceがある時と、不確実性をescalateすべき時を判断すること。
有用なbenchmarkはrepair regretである。repair regretとは、元episodeを直したが、より深刻なdownstream failureを作った状態である。harnessは時間を通じてregretを追跡し、局所最適化でsystemic riskを増やすrepair strategyを減点すべきである。
結論は
自動改修はfeature toggleではない。governance systemである。Dynamic harnessはfailureをepisodeへ、episodeをproposalへ、proposalをreplay evidenceへ、replay evidenceをapproval-routed patchへ変換することでrepairを安全にする。これによりMARIA OSは、self-healingを安全に保つ境界をagentに書き換えさせることなく、self-healingへ進める。