要旨
多くの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を満たすための制御された試行になる。
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すべきである。
結論
ハーネス駆動開発は、prompt craftからruntime engineeringへの移行である。dynamic harnessを仕様にし、runtime episodeを回帰単位にし、scorecardを測定面にし、gateをauthority boundaryにする。この基盤があって初めて、MARIA OSは内部の自動実装と自動改修を安全に扱える。