# Adversarial Verify

> レビュー・点検で出した指摘を、報告・Issue 化・差し戻しの前に検証するとき。「この指摘を検証して」「誤検出を除いて」「指摘を確定して」等で使う。skill-lint の点検や run-agent-team の reviewer（設計レビュー・解散前チェック）の検証フェーズとしても参照される。各指摘を「誤検出である」と仮定し、証拠の実在・基準への紐づけ・反例探しの 3 点で反証を試み、生き残った指摘だけを確定し、棄却は理由付きで記録する。

- Skill: `turntuptechnologies-ai/adversarial-verify` (Agent Skill)
- Install (CLI): `npx skillmds@latest add turntuptechnologies-ai/adversarial-verify`
- Raw SKILL.md: https://api.skillmd.com/api/skills/turntuptechnologies-ai/adversarial-verify/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: turntuptechnologies-ai (https://skillmd.com/u/turntuptechnologies-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/turntuptechnologies-ai/adversarial-verify

---


# 敵対的検証（adversarial-verify）

## このスキルがやること

レビュー・点検・チェックで出た指摘の「候補」を受け取り、各候補に反証を試みて、生き残ったものだけを確定指摘にする。誤検出を報告前に落とし、棄却は理由付きで記録する。単体でも、指摘を出す他の Skill（`skill-lint`、`run-agent-team` の reviewer 等）の検証フェーズとしても使う。

## 前提（入力）

次の 3 点を揃えてから始める。欠けていれば検証を始めずに要求する:

1. **指摘候補**: 検証したい指摘のリスト
2. **対象**: 指摘が向けられた成果物（ファイル・設計文書・差分・ドキュメント等）
3. **基準**: 何に照らした指摘か（チェックリスト・受け入れ条件・規約・要件等）

## 手順

1. 候補ごとに立場を反転し、「**この指摘は誤検出である**」と仮定して 3 つの反証を順に試みる:
   1. **証拠の実在**: 指摘の根拠を対象から原文引用できるか。引用できない（記憶や印象で書かれた）指摘は棄却する。
   2. **基準への紐づけ**: 基準のどの項目への違反か特定できるか。どの項目にも紐づかないなら fail にせず「参考」に降格する。
   3. **反例探し**: 対象の**別の場所で実は満たされていないか**を全文再読して探す。満たしている箇所が見つかれば棄却する。
2. 反証の結果で仕分ける:
   - 反証に**成功** → 棄却する（棄却理由を記録）。
   - 反証に**部分的に成功**（基準違反とまでは言えないが改善余地はある） → 「参考」に降格する。
   - 反証に**失敗** → 確定する。反証できなかったのに棄却してはいけない。
3. 出力フォーマットで確定・参考・棄却を報告する。

## 独立検証（指摘した側と検証する側を分ける）

- 候補が **3 件以上**あるとき、または **PR・Issue 化・差し戻し直前の最終ゲート**として使うときは、検証用サブエージェントを起動する。
- **既定は 1 体にまとめる**: 全候補を 1 体の検証用サブエージェントに渡す。独立性の要件は「指摘を出した側と別コンテキストであること」であり、1 体でも満たせる。候補ごとに個別起動すると対象の読み込みが候補数分発生し、検証の質は上がらないままコストだけ増えるため、既定にしない。
- **候補ごとに個別起動する**のは次のときのみ: リリース・公開の直前ゲート等、誤検出の見逃しコストが特に高いとき。または候補同士が関連していて、まとめて渡すと検証者が相互に引きずられる（片方の結論をもう片方に流用する）恐れがあるとき。
- 検証者には指摘を出した側の推論を渡さない。「指摘の主張・対象・基準」だけを渡し、「各指摘を反証せよ。反証できたら棄却と判定せよ」と指示する。
- 指摘を出した本人（同一エージェント・同一コンテキスト）による検証は独立検証とみなさない。

## 候補ゼロ（全件 pass）の場合

そのまま合格を宣言しない。判定が最も際どかった 2 項目を選び、逆方向（「実は fail ではないか」）の反証を試みてから合格を宣言する。

## 出力フォーマット

必ずこの 3 節で報告する。該当なしの節は「なし」と明記する（節ごと省略しない）:

```markdown
**確定した指摘**:

| # | 指摘 | 根拠（原文引用） | 紐づく基準 |
|---|---|---|---|

**参考に降格**（基準に紐づかない・違反とまでは言えない改善提案）:

| # | 指摘 | 降格理由 |
|---|---|---|

**棄却した候補**（誤検出と判定）:

| # | 候補の指摘 | 棄却理由 |
|---|---|---|
```

## ルール・コツ

- 敵対的検証は指摘の品質保証であって、指摘を減らすための言い訳探しではない。反証に失敗したら素直に確定する。
- 棄却を黙って消さない。棄却理由の記録は、レビューの再現性と基準自体の改善材料になる。
- 基準が渡されていない指摘は検証しない（基準が無いと fail と「参考」の区別がつかない）。まず基準を確定させてから始める。
- 呼び出し元の Skill に独自の報告フォーマットがある場合はそちらを優先し、本 Skill の 3 節（確定/参考/棄却）の情報が漏れなく含まれるようにする。

## 完了条件

以下を全て満たしたら完了。**満たせない項目があれば、黙って省略せず理由を報告する。**

- [ ] 全ての候補に 3 点（証拠の実在・基準への紐づけ・反例探し）の反証を試み、確定/参考/棄却のいずれかに仕分けた
- [ ] 確定した指摘の全てに根拠の原文引用と紐づく基準を添えた
- [ ] 棄却・降格の全てに理由を添えた
- [ ] 候補ゼロの場合、際どい 2 項目への逆方向の反証を行ってから合格を宣言した
- [ ] 独立検証の条件（候補 3 件以上、または最終ゲート）に該当する場合、検証用サブエージェントで検証した

## 補足

- 社名・内部 URL・認証情報などの固有情報は扱わない。
- このリポジトリ以外（各プロジェクトのレビュー運用）でも、指摘候補・対象・基準の 3 点が揃えば同じ手順で使える。