概要
このアプリは動的ハーネス駆動開発により保守されています。つまり、手作業の確認、単発のバグ報告、一度きりのテストだけで保守しているのではありません。runtime evidenceを改修作業へ変換するループによって保守しています。
Dynamic Harnessは、意味のあるscenarioの中でsystemがどう振る舞ったかを観測します。evidenceがあったか、正しいgateが適用されたか、出力がauthority boundaryの内側にあったか、latencyやcostのdriftが出たか、最終actionを進めるべきか、止めるべきか、制約すべきか、承認に戻すべきか、改修すべきかを記録します。
本稿はこの方法を汎用レベルで説明します。内部実装、private prompt、infra詳細、repository path、credential、独自automation ruleなどは公開しません。
1. 通常のテストだけでは足りない理由
通常のテストは重要です。既知の振る舞いがまだ壊れていないかを確認できます。しかしDynamic Harnessは、もう一段広い問いに答えます。最新の振る舞いからsystemは何を学び、次に何をすべきか。
AI支援プロダクトの失敗は、単純な例外として現れるとは限りません。文章は自然でも根拠がない。workflowは完了してもapproval boundaryを飛ばしている。ある画面の修正がcross-system contractを弱めている。Dynamic Harnessは、こうした運用上の壊れ方を検知するためのものです。
2. Harness結果を運用証跡として扱う
保守の基本単位はruntime episodeです。episodeにはscenario、観測signal、評価結果、gate state、判断理由、次のcontrol actionが含まれます。Harness結果が出たら、それを一時的なtest outputとして捨てず、共通の収集pipelineへ流します。
安定したepisodeは、現在の振る舞いがoperating envelope内にある証跡になります。不安定なepisodeは、severity、category、evidence、改修方向を持つfailure signalになります。
3. 失敗から改修計画へ
有用なHarnessは検知で止まりません。失敗を分類し、riskを見積もり、影響surfaceを推定し、小さな改修範囲を提案し、再実行すべきverification harnessを示します。これにより、改修が広がりすぎることを防ぎます。
改修計画は境界付きです。低リスクの局所変更は速く進めます。中リスク変更は強い検証を要求します。authority、security、data、external action、本番影響を含む高リスク変更はapproval-gatedのままにします。
4. 個別Harnessと横断Harness
動的ハーネス駆動開発では、局所検証と横断検証を分けます。まず個別Harnessで対象機能、workflow、interfaceを確認します。その後、横断Harnessで修正が別の不整合を生んでいないかを確認します。
多くのregressionは局所だけでは見えません。UI修正がAPI前提を壊す。API修正がaudit traceを弱める。高速化がreviewに必要なevidenceを落とす。二段階の検証は、この広い影響を捕まえるためにあります。
5. Incident noteではなくLearning Storeへ
改修が計画または完了したら、学習を残します。何が起きたか、どのcontrolが検知したか、どの予防策をreplay setに残すべきか、どのapproval boundaryが関係したかを保存します。
これは単なるbug fixとの違いです。bug fixはcodeを変えます。Dynamic Harness loopは、似た失敗が次回より早く捕捉される確率を変えます。
6. ユーザーにとっての意味
ユーザーにとって、動的ハーネス駆動開発とは、プロダクトが生きた運用systemとして保守されているということです。失敗は欠陥としてだけでなく、scenario、gate、scorecard、approval、repair routeを改善するための証跡として扱われます。
目標は無制限の自己改変ではありません。目標は制御された保守です。より明確に観測し、より小さく直し、より確実に再実行し、authorityやriskが必要とする場所では人間承認を維持することです。
結論は
動的ハーネス駆動開発は、AI支援アプリケーションのための保守規律です。Harness結果をevidenceへ、evidenceをanalysisへ、analysisを境界付きrepair planへ、repairをre-runへ、re-runをlearningへ変換します。このアプリは、その運用モデルにより保守されています。