antithesis-review-inputs

Antithesis のレビュー入力

スキルのバージョン： 2026-10-21 4f8d80b

目的とゴール

ワークロードを調べ、入力生成がどの程度状態空間を探索できているかを報告します。テスト対象のシステムはブラックボックスです。このレビューでは、ワークロードのコードと、ユーザーから提供されたドキュメントのみを使用します。

このスキルは読み取り専用です。調査結果のレポートを作成します。ワークロードを変更したり、プルリクエストを作成したり、具体的なコード変更を提案したりすることはありません。

このスキルでは「未開拓の探索」という観点で捉えます。調査結果が示すのは、ワークロードが到達できる可能性のある上限であり、欠陥ではありません。アンチパターンが見られるワークロードでも、有効に機能している可能性はあります。重要なのは、ランダム性の使い方を構造的に変えることで、さらに興味深い動作に到達できるかどうかです。

使用する場面

バグが見つからず、入力生成によって Antithesis の探索範囲が制限されているかどうかを把握したい場合に使用します。人間が作成したワークロードにも、エージェントが生成したワークロードにも、定期的な健全性チェックとして役立ちます。

基本原則

固定されたポリシーのもとで選択肢だけをランダム化するのではなく、実行ごとにポリシーをランダム化します。各実行で設定の偏り方を変え、異なる動作領域を探索できるようにします。このスキルでは、ワークロードがこれをどの程度実現しているかをレビューします。

ワークフロー

1. ワークロードの場所を特定する

テストコマンドとワークロードのコードを探します。一般的な場所は次のとおりです。

• antithesis/test/ — テストコマンドのスクリプト
• テストコマンドから参照されるワークロードのソースファイル
• ワークロードで使用されるクライアントライブラリやヘルパー

ワークロードの場所が明らかでない場合は、ユーザーに尋ねてください。

2. アンチパターンのリファレンスを読む

ワークロードを調べる前に、references/anti-patterns.md を読みます。カテゴリ別に整理された入力生成のアンチパターンがすべて記載されており、それぞれが探索を制限する理由と、望ましい方法が説明されています。

3. ワークロードを調べる

ワークロードのコードを読み、アンチパターンに当てはまる構造的なパターンを探します。コードから確認できる内容に注目してください。

アクションの選択 — 操作はどのように選ばれていますか？

• 常にすべて有効な固定セットですか。それとも、実行ごとにサブセットを選びますか？
• アクションの重みは固定、一様、それとも実行ごとに変化しますか？
• 順序はハーネスによって決まりますか。それともランダム性から生じますか？
• 常に一緒に有効になる、対称的なペアはありますか？

データ生成 — 入力はどのように生成されていますか？

• 値はハードコードされていますか。固定プールから選ばれていますか。それとも生成されていますか？
• 範囲は実行ごとに変わりますか。それとも境界値がハードコードされていますか？
• 入力の品質は（有効、無効、混在）変化しますか。それとも常に有効ですか？
• ペイロードのサイズは桁違いの幅にわたりますか。それとも狭い範囲にとどまっていますか？

構造 — ワークロードはどのように構成されていますか？

• 並行処理のレベルは固定ですか。それとも実行ごとに変化しますか？
• 操作のペースは変化しますか。それとも常に一定または高速ですか？
• ワークロードは常に空の状態から開始しますか？

4. 調査結果をまとめる

ワークロードで特定したアンチパターンごとに、次の内容を記載します。

• パターンの名前
• コード内の該当箇所（ファイルと行番号）
• そのパターンによって未探索となる状態空間
• 変更した場合にワークロードが到達できる状態

説明は一般論をアンチパターンの説明として繰り返すのではなく、このワークロードに即した具体的な内容にします。「3つのアクション（put、get、delete）は常にすべて同じ重みで有効です。そのため、delete だけが実行されてキーがゼロの状態になる実行はテストされません」のほうが、「すべてのアクションが常に有効です」よりも適切です。

5. 指摘事項を段階分けする

すべての指摘事項が同じ重みを持つわけではありません。次のように段階分けしてください。

• 重要度高 — ワークロードに明確な構造上の制約があり、状態空間の特定の領域全体に到達できません。例：すべてのアクションが常に有効で、サブセット化できない、すべての値がハードコードされている。
• 検討の価値あり — 変更すれば、ワークロードがより広い範囲を探索できるものの、制約の影響はより状況に依存するか、深刻度が低いものです。例：null／値なしのバリエーションがない、並行処理レベルが固定されている。
• 観察事項 — システムによっては重要になる可能性があると、レビュー担当者が気づいた点です。例：エンコーディングのバリエーション、シードデータが実行ごとに同一。

ドメイン知識がなければ指摘の深刻度を評価できない場合（例：「この範囲はハードコードされていますが、システムが受け付ける値はわかりません」）は、その旨を伝えてください。構造上の事実を示し、ドメインに基づく判断はユーザーに委ねてください。

6. レポートを提示する

レポートは次の構成にします。

1. ワークロードの動作 — レビュー担当者が確認した内容を簡潔にまとめます。ワークロードが実行するアクション、データの生成方法、構造を説明します。これはワークロードに対するレビュー担当者の理解を示すものであり、指摘事項を読む前にユーザーが誤解を訂正できるようにします。

2. 指摘事項 — 重要度の高いものから段階ごとに整理し、複数の指摘事項が同じカテゴリに集まる場合は、カテゴリごとにまとめます。各指摘事項では、パターンを示し、該当するコードを挙げ、このワークロードに固有の内容に即して、未探索の状態空間について説明します。

3. 適切にできている点 — ワークロードですでに適切に実施されているパターンを示します。実行ごとにアクションをサブセット化している場合や、ペイロードのサイズを変えている場合は、その旨を記載してください。指摘事項だけのレポートは批判的な印象を与えます。適切にできている点を認めることで、評価としての視点を示せます。

トーン

レポートは「まだ到達できていない、探索可能な領域を示します」という内容にしてください。「ワークロードに問題がある」という論調には決してしないでください。複数のアンチパターンが見られるワークロードでも、バグを見つけている可能性はあります。目標は、より多くのバグを見つけられるよう支援することです。

指摘事項を「これを行うべきです」と表現しないでください。「ここはまだ到達できていない状態空間であり、そこに到達するとこのような探索が可能になります」と表現してください。何を変更する価値があるかは、ユーザーが判断します。

対象範囲の制限

このスキルでは、ワークロードがシステムを多様な状態に導く方法である入力生成をレビューします。次の項目はレビューしません。

• アサーションの品質 — バグに到達した場合、ワークロードがそれを検出できるかどうかです。これは別の検討事項です。
• システムの正しさ — テスト対象システムが正しく動作しているかどうかです。SUT はブラックボックスとして扱います。
• ワークロードの正しさ — ワークロードのコードにバグがあるかどうかです。レビュー担当者が確認するのはワークロードの構造であり、その正しさではありません。
• インフラストラクチャ — Antithesis のセットアップ、Docker の設定、テストテンプレートが正しいかどうかです。

レビュー担当者が対象範囲外の重要と思われる点（例：ワークロードにアサーションがまったくないこと）に気づいた場合は、観察事項として簡潔に触れてもかまいませんが、詳しくレビューしてはいけません。

参考ファイル

参考資料	読むタイミング
references/anti-patterns.md	ワークロードを確認する前 — アンチパターンの全一覧