Dev Intel: separated test agent

同じ agent にテストと実装を両方やらせる弱さを、ワークフロー分離で潰すメモ。

Generated: 2026-05-21T17:04:02+09:00

Lane: 開発ネタ発掘

Why this is useful:

健人くんの OpenClaw/agent 運用では、最近ずっと「同じ agent が作って自己採点する弱さ」を hooks / evidence / evaluator で潰す話をしている。Zenn の実験はそこにかなり刺さる。ポイントは「テストを書け」と促すことではなく、テストを書く agent と実装する agent の情報を分離すると、TDD がプロンプトではなくワークフロー制約になること。

What I made/changed:

Zenn の separated-agent TDD 実験を、OpenClaw に盗める設計メモへ圧縮した。結論は「全部を multi-agent にする」ではなく、危ない差分だけ red_agent / green_agent / qa_agent の 3役に分け、成果物に test_independence を記録すること。

何が新しいか

同じ仕様・同じ技術スタック・同じ tasks.md で、単一 agent と分離 agent を比較している。

• 単一 agent: Agent A がテスト作成も実装も担当
• 分離 agent: Red Team がテスト、Green Team が実装、QA Agent が仕様を基準に責任判定
• Red と Green は git worktree で物理的に分離
• 失敗時は QA が「テストが悪い / 実装が悪い / 仕様が曖昧」を振り分ける

記事の一番おいしい観察は、分離した結果、テスト数が 20 から 227 に増えたこと自体ではない。テスト agent が実装を知らないので、内部都合に寄せたテストを書けず、公開 API・境界値・アクセシビリティ・状態更新設計を先に要求する形になったこと。

OpenClaw に盗むなら

危険度の高い作業だけ、成果物 contract にこれを足す。

review_topology:

mode: single_agent | separated_red_green_qa

trigger: "shared_behavior | auth | money | external_write | recurring_failure"

red_agent_scope: "tests/spec only; no implementation access"

green_agent_scope: "implementation only; no test assertions unless failing output is exposed"

qa_agent_scope: "decide test_fault | implementation_fault | spec_gap"

test_independence: "none | prompt_separated | worktree_separated"

max_retry: 3

これを常用すると遅い。記事でも separated method は開発速度と簡潔さで負けている。なので OpenClaw では bug_shape: dangerous、外部送信、money/auth、共有 runtime、または同じ失敗2回以上だけに使うのがよさそう。

今日の heartbeat への接続

Daily News の X 修正みたいな transport 問題では、同じ agent が「直した」と言うだけだと弱い。次に同種の recurring failure が出たら、実装 agent とは別に Red 側へ「公式 X データであること」「fallback が偽データでないこと」「timeout しても digest 全体を止めないこと」を先にテスト化させる。これは owner correction を prompt に積むより再発防止に近い。

Sources/Evidence:

• Zenn: Drastically Improved Code Quality by Decoupling Test and Implementation Agents in AI Coding — https://zenn.dev/kk225/articles/agent-separated-tdd?locale=en
• Zenn: Claude Codeの動きをOpenTelemetryで可視化したら「何してたか分からない」が消えた — https://zenn.dev/seeda_yuto/articles/otel-ai-agent-observability
• Local evidence: 今日の Daily News / X official data correction in memory/2026-05-21.md

Prediction:

agent の品質改善は「強いルールファイル」から「独立した役割と観測可能な責任境界」へ寄る。プロンプトで品質を祈るより、誰が何を見られない状態で作ったかを成果物に残すほうが、あとから再発防止に使える。

Verify by:

次の recurring failure artifact で、responsibility_layer に加えて review_topology / test_independence を1回だけ入れ、通常の単一 agent 修正より検出できる抜けが増えるかを見る。

Observed:

記事の比較では separated method が code quality / architecture / performance / test quality で優位、development speed と code conciseness では単一 agent が優位。OpenClaw では全件適用ではなく危険差分への限定適用が現実的。

Next safe action:

projects/task-queue-visibility/tasks/heartbeat-owner-value-loop.md か次の failure artifact template に、危険差分だけ review_topology を持たせる小パッチを検討する。今回は source-backed intel の整理までに留める。

Notify: yes — 今日の X/Daily News 失敗修正と直結していて、「同じ agent に自己採点させない」実装パターンとしてすぐ使える。