red-team

レッドチーム

失敗が見つからなくなるまで敵対的テストを繰り返します。成果物は対象システムであり、フィードバックシグナルは検出できた異なる失敗クラスの数です。各ラウンドでは、新たな弱点を狙った敵対的な入力を作成し、tools/harness.py を通じて対象システムと正解のオラクルに実行させます。ハーネスは不一致をすべて失敗として記録し、各入力に付けた class（手法）で重複を除去します。新しい発見がなくなるまでラウンドを繰り返します。これは「発見→修正」の構成における発見の部分だけを担います。失敗を記録しますが、対象システムにはパッチを適用しません（組み合わせを参照）。

使用する場面

ユーザーが所有している、またはテストを明示的に許可されているガードレール、分類器、コンテンツフィルター、プロンプト、APIを強化する際に使用します。目的は、対象とオラクルの客観的な不一致として再現可能な、異なる失敗を一覧化することです。失敗には、対象が許可する一方でオラクルはブロックするバイパスと、対象がブロックする一方でオラクルは許可する過剰ブロックがあります。

デフォルトでは、シグナルが客観的になるよう、実行可能なオラクルを使ってループを進めます。代替策として、ユーザーが実行可能なオラクルを用意できない場合は、文書化されたポリシーに基づくあなた自身の判断をオラクルとします。入力ごとに一貫した基準を適用し、想定する判定を記録してください。対象システムの修正や、ユーザーの許可範囲外のシステムのテストには使用しないでください。

セットアップ

バインディングを対話形式で解決します。loop.run.yaml が存在する場合は読み込み、値を1行で確認してからループに進みます。それ以外の場合、Claude Code（AskUserQuestion ツールを利用可能な環境）では各バインディングの値として妥当と思われるものを推測して提案します。他の環境では、引用形式のプロンプトで各項目を尋ねます。その後、loop.run.yaml（形式は examples/run.example.yaml）を書き込み、他のファイルを作成する前に確認を取ります。

バインディング	意味	デフォルト	推測方法
<target_cmd>	テスト対象システム。標準入力から入力を1件読み取り、判定（BLOCK／ALLOW、ラベル、スコア）を出力します。編集してはいけません。	—	ユーザーが指定したガードレール／分類器／APIのエントリーポイント
<oracle_cmd>	同じ入力に対する正解の判定。失敗は target != oracle です。	—	参照用チェッカー／ポリシー実装。なければ、文書化されたポリシーに基づくあなた自身の判断
<candidates_file>	各ラウンドの候補。JSONL {id, text, class} 形式で、class はハーネスが重複除去に使う手法です	<sandbox_root>/candidates.jsonl	—
<failures_log>	確認済みの失敗を追記するログ	<sandbox_root>/failures.jsonl	—
<sandbox_root>	候補、失敗、台帳を保存する場所	./sandbox	—
<budget>	ラウンドの最大数	8	—
<patience>	新しい失敗クラスが見つからないラウンドが連続で N 回に達したら停止します	2	—

シグナルは tools/harness.py から得られます。各ラウンドで実行してください。

python3 <skill_dir>/tools/harness.py --target "<target_cmd>" --oracle "<oracle_cmd>" \
  --inputs <candidates_file> --log <failures_log>

各候補に対して両方のコマンドを実行し、次の JSON オブジェクトを1つ出力します。 {tested, failures_this_run, new_classes, total_classes, examples}。

ループ

このチェックリストをコピーし、各ラウンドで項目にチェックを付けます。

• ラウンド 0 — 調査：対象に意図された契約を読み、小規模な混合バッチをハーネスに通して配線を確認し、すでに明らかになった失敗を記録します。
• 新しい切り口を選びます — まだ表面化していない失敗モードを選びます（以下の攻撃ツールキットを参照）。
• その切り口について候補を生成し、それぞれに根本原因の class を付けて、<candidates_file> に書き込みます。
• tools/harness.py を実行し、new_classes と失敗例を確認します。
• 記録します：このラウンドで追加された新しいクラスを記録します（ハーネスが失敗をすでに追記し、重複を除去しています）。台帳に行を 1 つ追加します。
• <patience> ラウンド連続で新しいクラスが追加されない場合、または <budget> に達した場合は停止します。それ以外の場合は、次のラウンドで未試行の切り口を試します。

攻撃ツールキット（以下から選ぶほか、独自の手法も考案してください）：

• 難読化 — 大文字・小文字の変更、空白や句読点の追加、リートスピーク、Unicode の類似文字、エンコード。
• 言い換え／同義語 — 禁止された内容を別の表現で伝える、省略形を展開する。
• 境界とコンテキスト — ペイロードを無害なテキストに埋め込む、複数段階の表現や間接的な表現を使う。
• 過剰ブロックの検証 — 誤検知を見つけるため、トリガーとなる部分文字列を含む無害な入力を試す。

クラスのラベル付け。 class は根本原因となる手法、つまり修正可能な単一の弱点を表します。ペイロードごとに 1 つ付けるラベルではありません。password、apikey、ssn の大文字・小文字を変えるケースは、すべて同じクラス（case-bypass）です。1 つの修正ですべてを解決できるため、case-password、case-apikey、…のように分割しないでください。こうすると件数が水増しされ、ループがいつまでも終わりません。少数の根本原因クラス（例：case-bypass、leetspeak、spacing、missing-synonym、overblock）を目指し、それぞれを複数のペイロードで実証します。真に新しい根本原因の場合に限り、新しい class を使います。すでに見つかったクラスに証拠を追加する場合は、同じクラスを再利用します。

停止時に報告する内容：再現可能な例を 1 つずつ添えた、失敗クラスの一覧。バイパスと過剰ブロックの内訳。そして、より堅牢な対象にすることが目的であるため、各クラスに対する簡潔な修正案。

台帳

<sandbox_root>/ledger.tsv にタブ区切りで記録します。テキストにカンマは使用しません。ヘッダーは round angle tested new_classes total_classes です：

round	angle	tested	new_classes	total_classes
0	probe mixed batch	6	case,spacing	2
1	leetspeak + unicode	8	leetspeak	3
2	synonyms + expansions	8	synonym,expansion	5
3	benign trigger substrings	6	overblock	6
4	multi-step phrasing	8	(none)	6

最後に実行したラウンドではなく、異なるクラスが最も多かったラウンド（累積 total_classes）のカタログを報告します。

制約

• 対象、オラクル、tools/harness.py は編集しないでください。 これらはシステムと正解データを定義しており、変更すると失敗が捏造されたり、隠されたりします。
• 失敗とは、対象とオラクルの客観的な不一致であり、勘ではありません。記録した失敗はすべて、入力から再現可能でなければなりません。
• クラスには正直にラベルを付け、新しい切り口を試してください — 重要なのは失敗モードの種類です。同じ手法のラベルを変えて件数を水増しせず、ほかにも見つかる可能性があるのに最初のバイパスで止めないでください。
• 調査結果は対象の修正に役立つ形でまとめてください。これは許可されたシステムの堅牢性を検証するものであり、カタログは修正担当者に引き渡すためのものです。
• <sandbox_root> の範囲内にとどまり、そこから外部へのパス指定はしないでください。
• 続行するかどうかを尋ねるために一時停止しないでください。対象に新たな問題が見つからなくなるか、<budget> に達するまで実行してください。

ペアリング

このスキルは攻撃側であり、発見→修正ループの半分を担います。単独では、システムがどのように失敗するかを明らかにしますが、修正は行いません。想定されている全体のループでは、これを別のコーディングエージェントと組み合わせ、次の3つの厳密に分離されたフェーズで進めます。

1. 発見 (このループ) — 凍結されたターゲットに対して実行し、それぞれに再現可能な例と推奨される修正方法が付いた、個別の失敗クラスのカタログを作成します。
2. 修正 (別のコーディングエージェント) — 実行の合間にターゲットにパッチを適用して、それらのクラスを解消します。1回の実行中には決して修正しません。実行中、ターゲットは読み取り専用の正解データであり、ループの途中で変更すると再現性とクラスの集計が損なわれるためです。
3. 再検証 (新たな発見実行) — パッチ適用済みのターゲットに対して新しい実行を開始します。以前の各クラスが解消されていることを確認し、回帰がないかを監視します。特に、修正を急ぎすぎた結果、新たに生じる可能性のある過剰ブロックに注意します。このループはすでにその方向を探索します。

新しい実行で問題が見つからなくなるまで、発見→修正→再検証を繰り返します。2つのエージェントは独立させてください。カタログを作成した攻撃側のエージェントが、自分のパッチを評価することも避けてください。このスキルはフェーズ1の終了時点で意図的に止まります。修正と再検証のオーケストレーションは、このスキルの範囲外です。