ハーネス駆動開発：Runtime Evidenceから逆算してAgentic Systemを作る
実装より先にscenario、gate、scorecard、repair boundaryを設計する開発方法論
ARIA-RD-012026/5/3024分で読めます要旨
多くのAIプロダクトは、まだsoftware-firstの流れでAgentic Systemを作っている。promptを書く。toolをつなぐ。demoを出す。失敗を見つけたら後からtestを足す。この流れは初速は速いが、Agentic Systemには弱い。なぜなら重要な欠陥はsyntax errorではなく、runtime phase errorとして現れるからである。agentが間違ったmodeに入る。古いmemoryを信じる。autonomyを使いすぎる。evidenceを残さない。責任が人間へ戻るべき地点を通過して実行を続ける。
ハーネス駆動開発は順序を逆にする。dynamic harnessはテスト補助ではない。主仕様である。agentを実装する前に、耐えるべきruntime episode、driftを分類するfailure taxonomy、改善を測るscorecard、そして承認なしに越えてはいけないauthority boundaryを定義する。実装は、このruntime contractを満たすための制御された試行になる。
中心命題は単純である。Agentic softwareはpromptから前向きに作るのではなく、期待されるruntime evidenceから逆算して作るべきである。
1. Prompt-first開発が壊れる理由
Prompt-first開発は最初のdemoが早い。しかし4種類の負債を隠す。第一に、振る舞いが文章でしか指定されないため、agentが改善したのか文体が変わっただけなのか分からない。第二に、失敗が逸話として保存されるため、正確に再生できない。第三に、tool behaviorが実装詳細として扱われるが、実際にはtool selectionこそがriskの入口になる。第四に、governanceが後付けになり、agentが直接実行する癖を学んだ後で止めようとする。
Dynamic harnessは、この隠れた負債をengineering objectに変換する。runtime episodeはgoal、input、memory state、tool call、evidence、output、score、final actionを保存する。failure taxonomyは、問題がmissing evidence、bad autonomy、stale memory、wrong tool use、unclear responsibility、latency pressure、cost pressureのどこから来たのかを分類する。scorecardはepisodeを測定可能なstate vectorに変換する。repair boundaryは、どの修正を自動化でき、どこから人間承認が必要かを定義する。
2. 仕様としてのハーネス
通常のsoftware specificationは、systemが何をすべきかを書く。しかしAgentic Systemではそれだけでは足りない。いつ止まるべきか、いつ聞くべきか、いつ不確実性を保存すべきか、いつ自分の出力を未検証として扱うべきかも仕様化しなければならない。したがってharness specificationは5層で構成される。
- Scenario layer: 代表的および敵対的なruntime episode。
- Gate layer: authority threshold、evidence requirement、human approval path。
- Score layer: quality、latency、cost、responsibility、memory、safety metrics。
- Repair layer: 自動修正可能範囲、承認必須範囲、rollback rule。
- Audit layer: MARIA coordinate、rationale、evidence path、diff history。
これによりharnessはevaluation suiteを超える。実装が満たすべき契約そのものになる。prompt、tool、workflow、policyは、gateを破らずruntime vectorを改善した時だけ正しい。
3. 開発ループ
ハーネス駆動開発のループは5段階である。第一にbehavior modeling。agentが行うdecision、利用可能なcontext、行使できるauthorityを定義する。第二にepisode encoding。exampleを再生可能なruntime episodeへ変換する。第三にimplementation。prompt、tool、workflow、policyをepisodeに合わせて実装する。第四にreplay。すべての変更をharnessで評価する。第五にhardening。失敗を使い捨てのbug noteではなく、新しいepisodeとして保存する。
type HarnessDrivenChange = { coordinate: string scenarioIds: string[] allowedAutonomy: "observe" | "draft" | "execute" | "repair" gates: string[] expectedScoreDelta: { quality: number responsibility: number latency: number cost: number } approvalRequired: boolean }
重要なのは、実装が意図ではなくreplayで評価される点である。新しいpromptがdemoを良く見せても、edge caseでunsafe autonomyを増やすなら失敗である。tool optimizationがlatencyを下げても、evidence traceabilityを失うなら失敗である。workflowがhuman checkpointを削除するなら、同等のresponsibility preservationを証明しない限り失敗である。
4. ページ分割という比喩
良いLP sectionはmobile viewportに収まり、横揺れしない。良いagentic featureはgovernance pageに収まり、責任が横揺れしない。原理は同じである。surfaceをbounded pageに分け、hidden overflowを防ぎ、濃い内容は制御されたcontainer内で縦にscrollさせる。ハーネス駆動開発は、この考え方をruntime behaviorに適用する。各episodeが1ページである。収まらないepisodeは、無制限のautonomyへ溢れさせるのではなく、より小さなepisodeへ分割する。
5. Product teamで何が変わるか
Product managerはuser storyだけでなくfailure storyを書く。evidenceが欠けた時、userが危険なshortcutを求めた時、data sourceがmemoryと矛盾した時、agentがbudget内に終われない時、何が起きるべきかを定義する。Engineerはcodeが動くかだけでなく、harness state vectorが改善したかを見る。Reviewerはstyleだけでなく、authority boundary、evidence path、repair permissionが変わったかを見る。
実務ルールは明快である。すべてのfeature PRはharness deltaを含むべきである。どのscenarioが追加されたか。どのscoreが変化したか。どのgateに触れたか。どのrepairが可能になったか。どの変更はhuman approval-onlyのままか。
6. 自動実装との関係
ハーネス駆動開発は、安全な自動実装の前提である。harnessが弱ければ、implementation agentには安定したtargetがなく、表面的なcompletionを最適化する。harnessが強ければ、implementation agentは明示されたruntime contractに対してcodeを合成できる。toolを生成し、episodeを実行し、失敗を読み、patchを提案し、score改善が飽和するかapproval boundaryに当たったところで停止できる。
つまりharnessは、code generationとgoverned implementationを分ける。Code generationは、modelがそれらしいcodeを書けるかを問う。Governed implementationは、そのcodeがauthority contractの下でruntime behaviorを改善したと証明できるかを問う。
7. 研究課題
次の研究課題はharness completenessである。現在のepisodeをすべてpassしても、意図したresponsibility modelを破れるなら、そのharnessは不完全である。これを測るにはmutation testingが有効である。prompt、tool、policy、memoryを意図的に摂動し、harnessが劣化を検出できるかを見る。強いharnessは悪いmutationを早く落とし、理由を説明できる。
第二の課題はharness compressionである。企業systemでは、すべてのchangeで全episodeをreplayすることはできない。必要なのはminimal basisである。少数のepisodeが大きなruntime全体のscore gradientを予測する状態である。ここでphase-space controlが実用になる。harnessはriskの異なる領域を代表するepisodeを特定し、PRごとにbasisを、定期評価でfull setをreplayすべきである。
関連記事: From Agent to Civilization: Multi-Scale Metacognition and the Governance Density Law
関連記事: Action Router × Gate Engine Composition: Formal Theory of Responsibility-Aware Routing
関連記事: 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設計の認知科学的基盤: マルチモーダル対話における注意資源配分モデル
関連記事: 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が自分の能力不足を認識するメタ認知アーキテクチャ
結論
ハーネス駆動開発は、prompt craftからruntime engineeringへの移行である。dynamic harnessを仕様にし、runtime episodeを回帰単位にし、scorecardを測定面にし、gateをauthority boundaryにする。この基盤があって初めて、MARIA OSは内部の自動実装と自動改修を安全に扱える。