自己成長するサブエージェントを「評価」してみた——本当の戦いは作った後だった

• URL: https://zenn.dev/tai_chii_dev/articles/eval-subagent
• 日付: 2026-06-21
• Tier: Tier 3
• 要旨: 自己成長するコードレビューサブエージェントを作り、15 回以上の実測で評価・チューニング。過去バグ試験では KB 検索力しか測れない。コールドスタート（未知問題）で推論力測定。プロンプト文言は書き方次第で効きが天と地。KB は「ログ」でなく「再利用可能な原則」に昇格。判断精度より「わからない」と申告させる安全性を優先。

詳細

レビュー相棒エージェント：PR・仕様相談・テストレビュー を手伝う。過去不具合を KB に構造化して溜める自己成長。実装は Markdown 定義（name・description・tools・model）+ KB ファイル。「動いた」と「効く」は別物。ゴールデンタスク（模範問題集）とルーブリック（採点表）で毎回計測。発見 1：KB に既に答えあれば「recall（検索）」しか測れず、detection（推論）測定不可。未知問題をコールドで投げ、grep で未検録確認。ページング境界・リトライ・冪等性などを自力検出。発見 2：プロンプト文言の書き方で効き一変。「判断せよ」（曖昧）× → 「テストレビュー時はコード読め」（具体的動作）○。Mode→Action 指示が 5/5 で実コード読み。発見 3：KB は「このバグが起きた」（ログ、転用されない）× → 「この種の処理では…というリスク」（原則、コールド発火）○。抽象度がちょうどよく、該当モードが読む場所に置く。発見 4：「いつ掘るか」正しく判断させる→無理。掘らなくていい場面でも掘らせ（時間増）、掘るべき場面で掘らず（誤り増）。コストの非対称性から「安い失敗に寄せる」：コードレビューは常に読む、掘らないときは「実コード未確認」自己申告。評価は実験室で 1 回ではなく、運用しながら回し続けるもの。