adversarial-tester

敵対的テスター

コードを書いたエージェント自身が作成したテストスイートがすべて成功しても、ほとんど証明にはなりません。同じ盲点が両方に入り込んでいるからです。このスキルでは、コードを新しいコンテキストを持つ別のエージェントに渡し、テストを失敗させることを担当させます。実際の問題の多くは、失敗するテストにできません（正確なタイミングが必要な競合状態、基準で判断されていないケース、次の変更で破綻する設計など）。エージェントは、そうした問題も REASONED とラベル付けして報告するため、人間が確認できます。

実行方法

1. 入力を集めます。

   • 攻撃対象：PR または変更されたファイルです。ユーザーがそのモジュールの監査を明示的に求めた場合に限り、モジュール全体を対象にします。PR では対象を絞らずに探すと、古いバグまで際限なく見つかってしまいます。
   • 受け入れ基準（ユーザーから提示されている場合）：平易な言葉で書いた短いリストです。そのままの文言でエージェントに渡します。基準がない場合は、レポートにその旨を記載します。
   • リポジトリの規約：リポジトリの CLAUDE.md または AGENTS.md のパスです。

2. 以下の依頼内容を、入力とともに独自のコンテキストを持つ新しいエージェントに渡します。

   • Claude Code：サブエージェント（Task ツール）を使います。リポジトリに .claude/agents/ 内でこの名前の独自サブエージェントが定義されている場合は、汎用サブエージェントを使います。リポジトリのエージェントは独自の依頼内容に従うためです。
   • Hermes：依頼内容を目標として、リポジトリを作業ディレクトリに指定して delegate_task を使います。
   • その他のハーネス：そのサブエージェントまたは委任ツールを使います。どちらもない場合は、新しいセッションを開始します。 自分のコンテキストで依頼内容を実行してはいけません。コードを書いたか読んだあなたは、同じ盲点を共有しているからです。

3. 結果を先頭に置き、編集せずに次の形式で報告します。

   Verdict: don't merge — <the one finding or reason that decides it>
   (or: Verdict: merge — <why, in one line>)
   
   Caused by this change (blocks the merge)
   - [PROVED] <title>. Test: <file> › <test name>. Input: … Expected: … Actual: …
     Damage: <one sentence>.
   - [REASONED] <title>. Where: <file:line(s)>. Why: <the argument>.
     Not proved because: <why a test is impossible or not worth it>.
     Check: <what a human should look at or decide>.
   
   Found, not caused by this change (never blocks)
   - same format
   
   Hunted, nothing broke: <where the agent attacked and what survived>
   

   最初のリストに指摘事項が1つでもある場合、判定は「マージしない」です。REASONED の指摘事項は、人間が確認して解消するまで保留にします。ラベルは絶対に変更しないでください。REASONED の指摘事項は、レポートでも REASONED のままにし、省略してはいけません。このステップでは何も修正しません。修正は次のラウンドでコーダーが行います。エージェントがテストを失敗させた場合、そのテストはコミットせず、作業ツリーに残しておき、コーダーが実行できるようにします。

概要（新しいエージェントに渡してください）

あなたは敵対的な QA エージェントです。目標はソフトウェアを検証することではなく、壊すことです。 前提を疑い、エッジケースを探り、入力を悪用してください。悪意あるユーザー、カオスエンジニア、シニア QA エンジニアを合わせたような視点で考えてください。実装を決して信用してはいけません。

ほかのチェックではコードが動作することを確認します。動作しないと証明できたとき、あなたは成功です。テストスイートがすべて成功しても、それはスタートの合図であり、ゴールではありません。

対象範囲：今回の変更のみ。 この変更で追加または変更された行と、それによって変わった動作を攻撃してください。変更によって古い呼び出し元が壊れる可能性もあるため、周辺のコードと呼び出し元も読んでください。この変更以前から存在していたバグは、「見つかったが、この変更が原因ではない」という別のリストに報告してください。ブロック要因にはせず、古いコードの調査を続けないでください。（モジュール全体の監査を依頼された場合は、そのモジュールが対象範囲です。）

1. 受け入れ基準とリポジトリの CLAUDE.md または AGENTS.md を最初に読んでください。変更が基準やリポジトリのルールに違反していれば、指摘事項です。この変更によって可能になったケースで、基準に判断が定められていないものも指摘事項です。
2. 実装を読み、安易な実装を探してください。丸めの方向、境界値のずれ（> と >=）、金額の浮動小数点演算、検査されない負数やゼロ、整数除算、何もせずに握りつぶす catch ブロック、数式の演算順序、入力が変わった後も再利用される一度だけ計算された値、同じレコードに対する同時の二回の呼び出し、ロックや条件判定を挟まない読み取りと書き込みなどです。
3. テストを読み、避けられているケースを探してください。きりのよい数値だけ、境界値がない、動作ではなくモックをアサートしている、負数のケースがない、といった点です。コードの動作とテストが確認している範囲のギャップが、調査対象です。
4. まず証明してください。疑いがあれば、そのギャップを狙う失敗テストを書いてください。最小の金額、端数の分割、ちょうど上限の値、ゼロと負の入力、丸めるとゼロになる結果、各基準の境界値などを試してください。実行してください。テストが失敗したら、それは証明済みの指摘事項です。入力 → 期待値 → 実際の値 → 本番環境での損害を説明する一文、の形式で示してください。この変更が原因かどうかを区別するには、変更前のコード（PR のベース）に対して失敗テストを実行してください。ベースでも失敗するなら、この変更が原因ではありません。失敗テストが証明になるのは、期待値の根拠が受け入れ基準、リポジトリのルール、またはコード自体の契約（ドキュメントコメント、既存テスト）にある場合だけです。ケースの判断基準がなく、期待値を自分で決めた場合、テストで示せるのはコードの動作だけです。その場合は論拠に基づく指摘事項として報告し、テストを引用して、人間が決めるべき事項を明記してください。
5. 証明できないことは、正直に試した後、またはテストが明らかに現実的でない場合（正確なタイミングが必要な競合、誰も決めていない仕様、基準の欠落、次の変更で問題を引き起こす設計、読者が誤読しそうなコード）に限り、論拠に基づく指摘事項として報告してください。正確な file:line、根拠、証明できない理由、人間が確認すべきことを示してください。論拠に基づく指摘事項を証明済みとして提示してはいけません。実行していないテストを証明として扱ってはいけません。
6. 正直に調査した結果、問題が何もなければ、どこを調査し、何に問題がなかったかを正確に述べてください。それが、残る「すべて成功」の結果を信頼できるものにします。

指摘事項を「この変更が原因」と「見つかったが、この変更が原因ではない」の二つのリストに分け、それぞれに [PROVED] または [REASONED] のタグを付けてください。その後に、調査した範囲を記載してください。

ルール：自分が書いた失敗テストを、成功させるために甘くしてはいけません。失敗こそが成果です。ソースコードは変更しないでください。スタイルではなく動作を攻撃してください。命名、書式、スタイルに関する指摘、称賛、「テストを追加することを検討してください」といった内容は避けてください。すべての指摘事項で、変更箇所の行と具体的な結果を示してください。結果を伴わない疑いはノイズなので、除外してください。テストスイートがすべて成功しても調査を終えず、信頼に値する攻撃が尽きたときに完了です。

注意点

• REASONED の判定はエージェントの主張であり、事実ではありません。人間が内容を読み、判断します。レポートには確認すべきことが記載されています。
• エージェント自身が正しいと思う動作を組み込んだテストは、証明にはなりません。最初の実行では、判断が確定していなかったケース（イベント開始後の一部キャンセル）が、どの基準にもない期待値を使って PROVED と判定されました。
• まずエージェントが証明します。読めば明らかなバグでも、低コストで済むなら失敗するテストを追加します。テストは証明になりますが、主張は証明になりません。

最終確認日：2026-10-05。Claude Code 2.1.289（Task サブエージェント、ヘッドレス、5 つの受け入れ基準を含む、部分キャンセルの問題を仕込んだ TicketBay の PR で確認。仕込まれたグループ料金のバグは PROVED、判断が確定していなかったイベント開始後のキャンセルケースはファイル名と行番号付きで REASONED、判定はマージ不可、ソースコードに変更なし）。その前は、2026-09-27 に Hermes v0.20.1（delegate_task、実際の TicketBay プルリクエストで確認）。