自動改修ハーネス：Runtime Failureを安全でReview可能な改善へ変換する
Failure episode、repair proposal、rollback envelope、approval boundaryによるself-healing agentic system
ARIA-RD-012026/5/3026分で読めます要旨
自動改修は自動実装より危険である。なぜなら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. Drift taxonomy
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が含まれる。
Self-healing systemは臓器を修復してよい。しかし外部authorityなしに憲法を書き換えてはならない。
この境界こそが、自動改修と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を減点すべきである。
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: Metacognition in Agentic Companies: Why AI Systems Must Know What They Don't Know
関連記事: Collective Calibration Dynamics: How Agent Teams Achieve Shared Epistemic Accuracy in MARIA OS
関連記事: Action Router Intelligence Theory: Why Routing Must Control Actions, Not Classify Words
関連記事: Voice User Interface設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル
関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing
関連記事: Gated Meeting Intelligence: Fail-Closed Privacy Architecture for AI-Powered Meeting Transcription
関連記事: Real-Time Meeting Session Orchestration: State Machine Design for Multi-Component Bot Systems
関連記事: Robot Judgment OS Lab: Designing Responsibility-Bounded Physical-World AI with Multi-Universe Gates
関連記事: CEO Clone: From Judgment Extraction to Autonomous Governance Engine
関連記事: Company Intelligence: なぜMARIA OSはAIツールではなく、会社の知能をつくるOSなのか
関連記事: MARIA VITAL：Agent組織のための生命維持システム — Heartbeat監視から再帰的自己改善まで
関連記事: Tool Genesis Under Governance: How to Safely Turn Generated Code into New Commands
関連記事: Anomaly Detection for Agentic System Safety and Deviation Control
関連記事: Institutional Design for Agentic Societies: Meta-Governance Theory and AI Constitutional Frameworks
関連記事: Agent Tool Compiler: From Natural Language Intent to Executable Tool Code via Compilation Pipeline
関連記事: Audit Universe Runtime: Agent Design for Executing Audit Procedures as Runtime Operations
関連記事: Governance Load Testing: Where Does Governance Break in the 1000-Agent Era?
関連記事: Agentic Ethics Lab: Designing a Corporate Research Institute for Structural Ethics in AI Governance
関連記事: Investment Decision Lab: Designing Agentic R&D Teams for Multi-Universe Capital Allocation
関連記事: Doctor Architecture: Anomaly Detection as Enterprise Metacognition in MARIA OS
関連記事: Audit Universe Runtime：監査手続をランタイム・オペレーションとして実行するAgentアーキテクチャ
関連記事: Meta-Insight Under Distribution Shift: Change-Point Governance Loops for Enterprise Agentic Systems
関連記事: Agent Capability OS — Command Registry・Tool Registry・Capability Graphで能力を管理するOS設計
関連記事: Repeated Games and the Cofounder Problem: Why Startup Cooperation Depends on Shared Time Horizons
関連記事: The Complete Action Router: From Theory to Implementation to Scaling in MARIA OS
関連記事: Memory Stratification for AI Governance: A Rate-Distortion Framework for Retention Decisions
関連記事: Capability Gap Detection — Agentが自分の能力不足を認識するメタ認知アーキテクチャ
結論
自動改修は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へ進める。