はじめに
エージェントスキルは、エージェントアプリケーションを切り取って簡略化したものとも解釈できます。
エージェントアプリケーション全体の品質評価には高度な技術が必要になりますが、スキル単位であれば問題を十分単純化できます。
であれば、エージェント品質評価の基礎とも言える情報検索の評価手法のアイデアを流用することで多くの示唆を得られると考えました。
そこで本記事では、コードレビューのように、指摘の採用・不採用や有用・無用が比較的判定しやすいタイプのエージェントスキルに範囲を絞って取り上げます。生成タスクのように正解集合を作りにくい領域には、別の評価論が必要になります。
レビュースキルの「指摘漏れ」と「誤指摘」に悩む
コードレビュースキルに、次のような少し抽象的な観点を書き込んだとします。
- 性能劣化を生む構造の指摘
- 排他制御まわりのレースコンディション検知
- 仕様意図と実装の乖離
いずれも linter では機械的に潰せない、コード全体の文脈を読まないと判定できない観点です。実際に運用してみると、こんなことが起きます。
- 書いたはずの観点が指摘されない（漏れ）
- 問題ないコードに対して指摘してくる（誤検出）
次は、改善のためスキルプロンプトをいじります。
↓
指摘が増える
↓
今度は別の箇所で漏れる。あるいはノイズが増える。
↓
どちらかを直すと、もう片方が悪くなる。
これは、プロンプトエンジニアリングの問題ではなく、検索エンジンや情報検索（Information Retrieval, IR）分野で磨かれてきた評価問題そのものです。
情報検索の評価問題との対応
レビュー対象コードの「ある箇所」について、{修正必要、修正不要} と、スキルが{指摘した、しなかった}をクロスさせると、次のような4象限ができます。
| 修正が必要 | 修正は不要 | |
|---|---|---|
| スキルが指摘した | TP (True Positive): 正解 | FP (False Positive): 誤指摘 |
| スキルが指摘しなかった | FN (False Negative): 指摘漏れ | TN (True Negative): 問題なし |
冒頭の2つの悩みは、それぞれ表の FN（偽陰性） と FP（偽陽性） に対応します。
スキルが返した指摘リストは、検索エンジンが返す検索結果と同じ構造を持っていて、情報検索の評価指標がそのまま使えます。
適合率と再現率
ここで、次の2つの集合を考えます。
- 集合 A = 修正の必要がある箇所の集合（正解集合）
- 集合 B = スキルが指摘した箇所の集合（検索結果に相当）
ここから、2つの基本指標が定義されます。
適合率 (Precision) $\displaystyle = \frac{|A \cap B|}{|B|}$
指摘したもののうち、本当に正しかった割合。精度、ノイズの少なさを表します。
再現率 (Recall) $\displaystyle = \frac{|A \cap B|}{|A|}$
本当に問題ある箇所のうち、拾えた割合。取りこぼしの少なさを表します。
「指摘漏れが多い」は 再現率が低い、「誤指摘が多い」は 適合率が低い と言い換えられます。
症状に名前がつくだけで、議論の解像度が一段上がります。
トレードオフと、情報検索分野の立ち向かい方
この2つは、一般にトレードオフになります。指摘を増やせば B が大きくなって再現率は上がりますが、適合率は落ちます。逆も同じです。スキル調整の堂々巡りの一因はこれです。
情報検索分野はこの問題を、オフライン評価とオンライン評価の両輪で扱ってきました。
オフライン評価：固定の正解データで測る
- 評価用の正解データセットを先に作ります。
- 少量でいいので、「修正が必要な箇所」を事前に特定したケースを用意し、TP / FN / FP を数えます。過去のPRレビューを利用したり、古典的なバグ埋め込み法も使えます。
- F値で1つの指標に統合します。
- 適合率と再現率の調和平均なので、片方だけ上げる偏った改善を許しません。用途に応じて重みを調整します。古典的なF値以外にも、チームやドメインの好みも考慮したDCG（Discounted Cumulative Gain）など多くのオフライン指標が提唱されているので目的に応じた指標を選択します。
なお、この正解データの準備が結構辛いです。
単に過去事例を収集するのは楽になりましたが、修正すべき指摘なのかどうかの判断の負担が大きいです。
ですが、ここが曖昧だと、結局はレビュー観点が言語化されてない、レビュースキルの用途が曖昧、ということであり、そもそもスキル化以前の問題として向き合う機会となると思います。
オンライン評価：実地で改善前後を比較する
ここでは評価対象の「ユーザー行動」を以下のどちらかだとして話を進めます。
- 指摘を受け入れて実際にコードを修正した
- そのPRでは対応しなかった場合も含め、有用な指摘と評価した
これらが、レビュースキルにおける現場での価値を最もよく表す指標になります。
- A/Bテスト
- 旧スキル（または単純なプロンプト）と新スキルを PR / スキル実行単位で振り分け、ユーザー行動の差を測ります。skill-creator の eval や variance analysis は、まさにこの A/B テストのスキル開発版で、同じ入力に対する出力ばらつきを測定しています。
- インターリービング（Interleaving）
- 同じ PR に対して旧スキル・新スキルの指摘を混ぜて1つのリストで提示し、どちらの指摘がより採用されたかで勝敗を決めます。一つのレビュー結果として同時に評価できるので、A/B テストより評価負担を下げられる、というのが嬉しいポイントです。
まず「レビューの位置づけ」を決める
道具を使う前に、そのレビュースキルを何のために回すのか、位置づけと優先観点を先に宣言することです。
これが決まらない限り、適合率と再現率のどちらに振るかも決まりません。
パターン1：漏れを許したくない（再現率優先）
セキュリティレビュー、リリース前の最終チェックなど、FN（見逃し）のコストが極めて高い用途です。
- 検出条件を広めに取り、再現率を稼ぎます
- 増えるノイズはランキングで対処します。指摘ごとに重要度スコアを付け、上位 N 件だけを人間に見せる方法です。検索エンジンが膨大なヒットの中から上位10件を選び出すのと、考え方は同じです。重要度区分で分けるのも同様です。
パターン2：人間の確認コストを減らしたい（適合率優先）
日常の PR に混ぜたい、ノイズで信頼を失いたくない、といった FP（誤指摘） のコストが高い用途です。
- 検出条件を絞り、確信のあるものだけ出します
- linter や静的解析と併用して、機械的に判定できる部分はそちらに任せ、スキルは LLM でしか拾えない論点に絞ります
- 検証用のスキルやサブエージェントを別建てにします（LLM-as-a-judge）。検出役のスキルが出した指摘を、別エージェント・別種モデルが「この指摘は本当に妥当か」と判定して落とす二段構成です。FP 削減に役立てます。
パターン3：両方欲しいなら、スキルを分割する
実務では「漏れも許せないが、ノイズも出したくない」という要求が当然出てきます。
このとき1つのスキルで両立を狙うのは筋が悪いです。トレードオフ曲線上のたった1点を探す難問になってしまうからです。
代わりに、スキルを分割して目的を分けるのが定石になります。
たとえば「セキュリティ重大度 High だけを再現率優先で拾うスキル」と「日常 PR 向けに適合率優先で軽く拾うスキル」を別々に運用するなどです。評価セットも指標も独立に持てるので、トレードオフの設計判断がそれぞれのスキル内で完結します。
ただし、スキルが増えると重複指摘や指摘同士の競合といった問題も出てくるので、スキル結果の統合や優先順位付けが必要になる場合もあります。この辺りはまさにリランキングの手法を応用できそうです。
まとめ
コードレビュースキルの開発は、 問題を単純化させると「ノイズと取りこぼしのトレードオフ」を扱う検索エンジンに対する検索クエリの改善と同じ問題に帰着されます。
情報検索の語彙が入るだけで、スキル定義調整の議論は一段解像度が上がります。
ただ、現実問題はここまで単純化できないため、より高度な課題にはLLM検索エンジンの評価理論を土台に、ランキング・選好学習・人間評価を組み合わせた問題として向き合う必要があります。
とはいえ、その基礎となる情報検索の評価は、コードレビュースキル開発の新しい教養となり得ると思います。