ガバナンス付き自動実装：Dynamic Harnessが研究意図をコードへ変換する仕組み
Design noteからimplementation plan、patch、replay、approval-gated mergeまで
ARIA-RD-012026/5/3025分で読めます要旨
自動実装はしばしばcode generation問題として語られる。しかしそれは狭すぎる。難しいのはcodeを書くことではない。code changeの中でintent、responsibility、evidence、reversibilityを保存することである。Dynamic harnessは、自動実装を気の利いたassistantではなく、統治されたruntime actorに変える。
Governed auto-implementation loopはresearch intentから始まる。note、issue、design sketch、failure episode、product requestなどである。harnessはそれをscopeへ変換し、影響coordinateを特定し、implementation planを生成し、bounded patchを適用し、関連episodeをreplayし、riskを分類し、automatic merge、agent review、human approvalへrouteする。
1. Code generationとauto-implementationの違い
Code generationはfileを生成する。Auto-implementationはsystemを変える。この違いは重要である。生成されたfileが見事でも、system全体は悪化することがある。実装とはinterface、test、product intent、runtime evidence、accessibility、security、governance、operational costを保存しながら変更することである。必要なのはmodel callではなくcontrol loopである。
Governed auto-implementationには3つの不変条件がある。第一に、すべてのimplementationはintent objectに結びつく。第二に、すべてのimplementationは関連harness episodeのreplayで評価される。第三に、すべてのimplementationはmerge前にauthority riskで分類される。
2. Intent object
Intent objectは、なぜその変更が存在すべきかの構造表現である。human request、failed runtime episode、regression detector、roadmap、research noteから発生する。harnessは生のrequestをmachine-checkable objectへ変換する。
type ImplementationIntent = { id: string source: "human" | "episode" | "regression" | "roadmap" | "research" summary: string coordinates: string[] expectedBehavior: string[] forbiddenChanges: string[] evidenceRequired: string[] approvalPolicy: "auto" | "agent-review" | "human" }
特に重要なのはforbiddenChangesである。自動実装は、何をするかだけでなく、何に触れてはいけないかを知る必要がある。negative scopeがなければ、implementation agentは隣接問題を解き、無関係なrefactorを行い、直近taskを楽にするためにauthority boundaryを変更しがちである。
3. 7段階ループ
Governed loopは7段階である。Intent parseはproseをstructured targetへ変換する。Scope resolutionはtargetをfile、API、data contract、UI surface、MARIA coordinateへ対応づける。Plan generationは最小実装案を出す。Patch synthesisはcodeを編集する。Replayはharness basisを実行する。Risk classificationはpatchがauthority、data、security、schema、prompt、workflow boundaryに触れたかを判定する。Approval routingはauto merge、agent review、human approvalのどれかを決める。
このloopはpatch synthesisとapprovalを意図的に分離する。Implementation agentはpatchを書ける。しかしpatchを進めてよいかを決めるのはharnessである。
4. Risk class
Auto-implementation changeは4分類できる。Class 1はcosmeticで、copy、layout、style、documentationなどbehaviorを変えないもの。Class 2はlocal behaviorで、component、utility、routeの boundedな振る舞いを変えるもの。Class 3はworkflow behaviorで、step order、retry、escalation、evaluationを変えるもの。Class 4はauthority mutationで、誰が決めるか、いつgateが発火するか、どのevidenceが必要か、何を自動修正できるかを変えるもの。
| Risk class | 例 | Default route |
|---|---|---|
| Class 1 | Text, responsive CSS, docs | build後にauto |
| Class 2 | Local UI logic, helper behavior | test後にagent review |
| Class 3 | Workflow DAG, retry policy, scoring | production-boundならhuman approval |
| Class 4 | Authority, schema, policy, prompt core | human approval必須 |
Dynamic harnessはここで保守的であるべきだ。code上は小さな変更でもauthority上は大きいことがある。例えばthresholdを0.82から0.75へ変えるのは1行だが、そのthresholdがhuman escalationを制御しているならauthority mutationである。
5. Reviewable artifactとしてのimplementation plan
Riskが高い時、patchの前にimplementation planをreviewできるべきである。Planにはaffected files、intended diffs、expected tests、expected score changes、rollback strategyが含まれる。これによりimplementation agentはcodeを書く前に説明責任を持つ。
良いplanは小さい。広いrefactorよりlocal patchを選び、新しい抽象より既存patternを選び、architecture ambitionよりtestable behaviorを選ぶ。harnessはevidenceなしにscopeを広げるplanを減点すべきである。
6. Merge predicateとしてのreplay
中心となるmerge predicateは、patchがcompileするかではない。compileは必要だが十分ではない。patchは関連runtime state vectorを改善または保存しなければならない。vectorにはquality、responsibility、evidence completeness、latency、cost、reversibilityが含まれる。
merge(patch) = pass(build) ∧ pass(types) ∧ pass(harness_basis) ∧ ¬authority_violation(patch)
Class 1変更ではharness basisは小さくてよい。Class 3または4変更では、adversarial episode、rollback test、approval-path verificationを含める必要がある。
7. MARIA OS内部の自動実装
MARIA OS内部では、auto-implementationを制限されたauthorityを持つinternal agentとして扱うべきである。patchを提案し、testを実行し、failureを読み、draft pull requestを作ることはできる。しかしproduction schema、global policy、core prompt、自分自身のauthority拡張を静かに変更することはできない。それらは明示gateを必要とする。
この設計はautonomous implementationの利点を保存しながら、recursive authority creepを防ぐ。Implementation agentはsystemを改善できる。しかしsystemを改善する憲法そのものは決められない。
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: Action Router Intelligence Theory: Why Routing Must Control Actions, Not Classify Words
関連記事: 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
関連記事: 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が自分の能力不足を認識するメタ認知アーキテクチャ
結論
Governed auto-implementationは、より良いpromptによるcode generationではない。code changeを囲むruntime control loopである。Dynamic harnessは、intent、scope、replay、risk classification、approval、rollbackという欠けていた構造を提供する。この構造があれば、内部自動実装は制御不能な生産性demoではなく、測定可能なengineering capabilityになる。