5. ERPプロジェクトでharnessをdogfoodしてわかったこと: 検証記録そのものも検証が必要だった

ERPプロジェクトでharnessをdogfoodしてわかったこと: 検証記録そのものも検証が必要だった

こんにちは。韓国出身のジュニア開発者です。
日本語はツールの助けも借りながら整えています。少し不自然な表現があればご容赦ください。

これは harness-starter-kit シリーズの 5 本目です。

初めてこのシリーズを読む方は、先に前の記事を読むと流れがわかりやすいと思います。

1. Cursorに毎回同じ指示を繰り返すのがつらくなったので、ルールをリポジトリに残すOSSキットを作った
   https://blog.csdn.net/2604_96221454/article/details/161573772
2. harness-starter-kitを実プロジェクトに入れて試してみた
   https://blog.csdn.net/2604_96221454/article/details/161632236
3. harness-starter-kitは魔法ではない。エラーを早く表に出すためのもの
   https://blog.csdn.net/2604_96221454/article/details/161657136
4. まだharnessがagentを強くしたとは言えない。でもPRでagent workの境界、検証結果、再利用できる証拠を記録し始めた
   https://blog.csdn.net/2604_96221454/article/details/161706287

前回までの記事では、主に次のことを書いてきました。

• なぜ harness-starter-kit を作ったのか
• なぜ coding agent に毎回同じプロジェクトルールを説明したくないのか
• なぜ repo に AGENTS.md、検査スクリプト、decision memory、failure memory を残すべきなのか
• なぜ感覚だけで agent が良くなったと判断できないのか
• なぜ PR が agent work の measurement unit になりうるのか

今回は、さらに一歩進んだ話です。

前回、私はこう書きました。

記録がなければ、比較はできない。

でも ERP dogfood をやってみて、もう一文付け加える必要があると気づきました。

記録があるだけでは足りない。
記録そのものも検証される必要がある。

今回は、より企業アプリに近い dogfood プロジェクトに変えた

以前は Next.js の today-bus というプロジェクトで dogfood していました。

今回は、より社内業務システムに近い小さなプロジェクトに変えました。

harness-erp

大きなシステムではありません。
それでも、前の例よりは伝統的な業務アプリケーションに近いです。

技術スタックは、おおよそ次の通りです。

• Java 21
• Spring Boot
• Maven wrapper
• H2 database
• vanilla HTML / CSS / JavaScript frontend

業務内容も、比較的よくあるものです。

• employee management
• purchase request
• approval workflow
• role-based access policy
• approval history
• frontend API coverage

ERP を選んだのは、完全な ERP 製品を作りたいからではありません。

より重要だったのは、次のことを観察したかったからです。

coding agent が backend、frontend、業務ルール、権限ルール、テスト、ドキュメントを持つプロジェクトに向き合うとき、harness は余計な変更、検証忘れ、既知のミスの再発を減らす助けになるのか。

今回は「機能ができたか」だけを見ない

単に機能だけを見るなら、エージェントが API を作り、画面を書き、テストが通れば終わりに見えます。

でも harness dogfood では、そうは見ません。

各タスクに task outcome record を残すようにしました。

そこには次のような内容を記録します。

• 今回のタスクの目的
• expected boundary
• エージェントが実際に変更したファイル
• wrong-file edit があったか
• repeated known mistake があったか
• first-pass verification が通ったか
• 最後に実行した検証コマンド
• このタスクを effectiveness report に入れられるか

少し面倒に見えるかもしれません。

でも私にとって、これらの記録はとても重要です。

エージェントの作業がチャットログだけに残っていると、すぐに消えてしまうからです。

数日後には、私はたぶんこうしか覚えていません。

今回はわりとスムーズだった気がする。

でも、次のことまでは覚えていないかもしれません。

• どのタスクで最初のテストが失敗したのか
• どのタスクが境界外のファイルを変更したのか
• どのタスクは setup であり、product-task metrics に入れるべきでなかったのか
• どの検証コマンドが本当に実行されたのか
• どれが検証に見えるだけだったのか

だから今は、こう考えるようになりました。

コード差分だけがすべてではない。
agent work の境界、検証、失敗も、repo 内の artifact になるべきだ。

ERP dogfood で記録したこと

今回の ERP dogfood は、単一のタスクではありませんでした。

いくつかの task group に分けました。

最初のグループは backend initial benchmark です。

• ERP-001: employee search
• ERP-002: purchase request amount validation
• ERP-003: approval comment
• ERP-004: employee department field
• ERP-005: role-based access policy

その後、backend follow-up もありました。

• ERP-006: enforce service-layer role policy
• ERP-007: purchase request filtering
• ERP-008: approval history
• ERP-009: employee update

さらに frontend follow-up もあります。

• FE-001: vanilla frontend shell
• FE-002: employee management frontend
• FE-003: purchase request frontend
• FE-004: approval workflow frontend
• FE-005: full frontend API verification

合計で 14 個の product-task outcome を記録しました。

結果だけを見ると、悪くありません。

たとえば、次のような結果です。

• backend initial group に 5 個の product task
• backend follow-up group に 4 個の product task
• frontend follow-up group に 5 個の product task
• 多くのタスクで wrong-file edit はなかった
• 既知のミスの明確な再発は見られなかった
• すべてのタスクに task outcome record が残った

それでも私は、まだこうは言えません。

harness は agent をより有効にしたと証明できた。

理由は前回と同じです。

pre-harness baseline がありません。
human rework minutes もきちんと測っていません。
プロジェクト規模もまだ十分ではありません。

より正確には、こう言うべきだと思います。

今回の ERP dogfood は、より多くの harnessed-only evidence を与えてくれた。
harness が agent work の境界、検証、失敗を記録する助けになることは示している。
ただし、harness adoption が agent effectiveness を高めたことは、まだ証明していない。

この結論は、広告文句としては弱いです。
でも、こちらのほうが誠実だと思っています。

今回、本当に気になったのは数字ではなかった

ERP dogfood のあと、より細かい問題に気づきました。

以前の私は、こう見ていました。

task outcome record はあるか。

でも今は、こう見るようになっています。

task outcome record に書かれた verification command は、本当に信頼できるのか。

たとえば記録にこう書かれているとします。

./mvnw verify

では、そのリポジトリには本当に mvnw があるのでしょうか。

記録にこう書かれている場合はどうでしょう。

mvn test

リポジトリのルートに本当に pom.xml があるのでしょうか。

こう書かれている場合もあります。

./gradlew check

その repo に本当に gradlew はあるのでしょうか。

あるいは、こう書かれている場合です。

go test ./...

repo root に本当に go.mod はあるのでしょうか。

一つ一つは小さな問題に見えます。
でも、とても重要です。

確認しなければ、エージェントは「いかにも検証したように見える記録」を残せてしまうからです。

たとえば、次のような記録です。

Verification: mvn test

しかし対象 repo は Maven プロジェクトではない。

あるいは、次のような記録です。

Detection check: go test ./...

しかし repo に go.mod がない。

このような記録は、見た目には整っています。
でも実際には、何も証明していません。

ただ evidence がそろっているように見えるだけです。

これは harness にとって危険です。

harness の目的は、きれいなドキュメントを作ることではありません。
repo をより信頼できる状態にし、エージェントのミスを早く表に出すことです。

だから今回、harness-starter-kit にもう一段階のチェックを追加しました。

Maven / Gradle / Go の command reference も検査対象にした

現在の starter-kit ブランチでやっていることは、かなり具体的です。

failure memory、adoption report、task outcome の中で Maven、Gradle、Go の検証コマンドを参照している場合、そのコマンドが repo root の project marker と一致しているかを確認する。

おおよそのルールは次の通りです。

• mvn test には root pom.xml が必要
• ./mvnw verify には root pom.xml と root mvnw が必要
• gradle test には Gradle build/settings file が必要
• ./gradlew check には Gradle build/settings file と root gradlew が必要
• go test ./... には root go.mod が必要

これで、コマンドが正しい業務ロジックをすべてカバーしていると証明できるわけではありません。

たとえば mvn test が存在しても、approval comment を本当にテストしているとは限りません。
go test ./... が存在しても、特定の bug path をカバーしているとは限りません。

それでも、もっと基本的な問題は防げます。

ドキュメントに検証らしいコマンドが書かれているが、
そのコマンドが現在の repo とそもそも一致していない。

つまり、これは完全な correctness proof ではありません。
もっと早い段階の sanity check です。

でも、この sanity check はかなり役に立ちます。

エージェントは「それっぽい文章」を簡単に書けるからです。
harness は、その一部を検査可能なものに変えるべきだと思っています。

harness の価値は、ここにある気がしている

最初に harness-starter-kit を作ったとき、考えはもっと単純でした。

私はただ、coding agent に毎回同じことを説明するのに疲れていました。

• このプロジェクトではどのコマンドを使うのか
• どのファイルを変更してはいけないのか
• テストはどう実行するのか
• 以前どんなエラーが起きたのか
• どのアーキテクチャ上の決定を繰り返し議論しないのか

だから、これらのルールを repo に入れようと考えました。

その後、ルールがあるだけでは足りないとわかりました。
そこで failure memory を追加しました。

さらに、failure を記録するだけでも足りないとわかりました。
failure memory は regression check につながっている必要がありました。

そして今、task outcome record があるだけでも足りないとわかりました。
task outcome に書かれた verification command も検査される必要があります。

この過程で、私の中の harness の理解は変わりました。

これは「エージェントを自動的に賢くする魔法のツール」ではありません。

むしろ、repo の中にある feedback loop です。

1. エージェントがミスをする
2. repo がそのミスを記録する
3. repo がルール、テスト、チェックを追加する
4. 次にエージェントが似たミスをしたとき、より早く表に出る
5. チェックそのものに穴があれば、そのチェックも補強する

これが、私が今 harness-starter-kit を広めたい理由です。

すべての問題を解決できたからではありません。
実用的な方向性を示してくれるからです。

prompt だけを最適化しない。
repo そのものもエンジニアリングする。

普通の開発者にとって何が役に立つのか

Cursor、Claude Code、Codex、その他の coding agent を使っている方なら、似たような状況に遭遇したことがあるかもしれません。

• 新しいセッションのたびにプロジェクトルールを説明し直す
• エージェントがテスト実行を忘れる
• エージェントが変更してはいけないファイルを触る
• エージェントが見た目はきれいだが誰もメンテしない docs を生成する
• エージェントが「検証済み」と言うが、何を検証したのかわからない
• 同じバグや同じ種類のミスが数日後にまた出る

これらは、長い prompt だけでは解決しにくい問題です。

chat prompt は消えやすいからです。
一方で、repo 内のファイルはそれほど簡単には消えません。

だから私の提案は、小さく始めることです。

たとえば、次のようなことです。

• 短い AGENTS.md を書く
• 繰り返し起きた failure を一つ記録する
• その failure を test や check に接続する
• プロジェクトの本当の検証コマンドを書く
• PR に task outcome を記録する
• setup task と product task を分けて集計する

最初から複雑にする必要はありません。

私自身の dogfood も、少しずつ進めています。

第一歩は、ルールを repo に置くことでした。
第二歩は、失敗を記録することでした。
第三歩は、task outcome を記録することでした。
第四歩は、harness health と agent effectiveness を区別することでした。

そして今の第五歩は、次のことです。

evidence そのものも検査対象にする。

現在 kit がサポートしていること

現在の harness-starter-kit には、私自身が dogfood してきたものがいくつか含まれています。

• prompt-first adoption workflow
• AGENTS.md guidance
• decision memory
• failure memory
• drift checks
• Harness Doctor
• task outcome template
• effectiveness report template
• /harness doctor
• /harness update
• /harness refresh
• /harness review
• TodayBus と Harness ERP の dogfood reports
• common checks の command-reference validation
• Maven / Gradle / Go project-marker validation

これは自動インストーラーではありません。

あなたのプロジェクトのことを、あなたのプロジェクト以上に理解しているふりもしません。

設計の方向性は次の通りです。

まず agent に repo を読ませる。
そのあと、最小限で有用な harness pieces だけを追加する。

この点は、私にとって重要です。

テンプレートをあちこちにコピーして、最後に repo を複雑にするようなツールにはしたくありません。

作りたいのは starter kit です。

エージェントに、次のような作業方法を与えるものです。

• まず対象プロジェクトを調べる
• 既存アーキテクチャを尊重する
• プロジェクト固有の package manager、CI、テスト、ドキュメントの習慣を保つ
• 本当に役立つルール、チェック、memory だけを追加する
• 重要な失敗を、後から見直せて検出可能な記録に変える

今回、責任を持って言えること

今回の ERP dogfood をまとめるなら、今の私はこう言います。

Harness ERP dogfood では、14 個の harnessed-only product-task outcomes を記録した。
Spring/Maven backend、vanilla frontend、role policy、approval workflow、frontend API coverage、browser smoke verification を含んでいる。
これらの evidence は、agent work の境界と検証結果を見直す助けになる。
ただし、pre-harness baseline がなく、human rework minutes も測定していないため、harness adoption が agent effectiveness を高めたとはまだ証明できない。

さらに、こう付け加えます。

今回の dogfood で、task outcome record に書かれた検証コマンドも検査すべきだとわかった。
そのため starter kit は、Maven、Gradle、Go の command reference が repo root の project marker と一致しているかを検証し始めた。

長い文章です。
でも「このツールで agent が強くなります」と言うより正確です。

最近は、大きすぎる宣伝文句を書きたくないと思うようになりました。

むしろ、こう書きたいです。

この kit は、エージェントがミスをしないことを保証しません。
でも、エラー、ルール、検証、証拠を repo に置き、次のミスを早く表に出す助けになります。

プロジェクトリンク

harness-starter-kit はこちらです。

実プロジェクトで coding agent を使っていて、
「毎回同じルールを説明し直す」「agent がプロジェクトコンテキストを忘れる」「検証記録が信用しにくい」といった問題に遭遇しているなら、この kit を見てみてください。

最初から完全な仕組みを導入する必要はありません。

小さな一歩から始められます。

agent に一番よく繰り返しているルールを、一文だけ repo に書く。
最近もう二度と踏みたくない失敗を、failure memory として残す。
次の PR の agent work を、task outcome として記録する。

これだけでも、チャットログだけに頼るよりずっと信頼できます。

今後も dogfood を続けます。

特に、次の領域を試したいです。

• さらに多くの Spring/Maven シナリオ
• monorepo command validation
• Rust / .NET / Python module command checks
• human rework minutes tracking
• より安定した prompt reference
• より多くの実 PR に基づく effectiveness report

この方向性が役に立ちそうだと思った方は、GitHub repo に star をいただけるとうれしいです。

私にとって、これは単なる OSS プロジェクトではありません。

ジュニア開発者として、coding agent ともっと真面目に協働する方法を学ぶための取り組みでもあります。

エージェントが常に正しいと信じるのではありません。

repo に、次のことを覚えてもらうのです。

• エージェントが守るべきルール
• エージェントが以前に犯したミス
• 本当に実行された検証
• 後から見直せる evidence
• まだ過度に宣伝してはいけない結論

これが、今の私が理解している harness engineering です。