antithesis-triage

Antithesis 実行のトリアージ

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

このスキルを使用して、Antithesis のテスト実行を分析します。

参照ファイル： このスキルの references/ ディレクトリには、特定のタスクに関する詳細なガイドが含まれています。最初にすべてを読まないでください。指示があった場合にのみ、参照ファイルを読んでください。各参照ファイルは、必要となる箇所で名前が示されています。

前提条件

• snouty がインストールされていない場合は、作業を進めないでください。インストール方法については https://raw.githubusercontent.com/antithesishq/snouty/refs/heads/main/README.md を参照してください。
• snouty が 0.8.0 より古い場合は、作業を進めないでください。バージョンを確認するには snouty --version を使用してください。更新するには snouty update を使用してください。
• jq がインストールされていない場合は、作業を進めないでください。インストール方法については https://jqlang.org/download/ を参照してください。

事前確認：トリアージを実行できることを確認する

トリアージスキルは snouty API（snouty runs ...）を通じて Antithesis と通信します。作業を始める前に、セットアップが完了していることを確認してください。

snouty doctor --json

これにより、API への接続が検証され、snouty が解決した設定が報告されます。

最上位の ok が true であり、api_key チェックの status が ok の場合にのみ続行してください。それ以外の場合は、失敗したチェックの message／notes を伝えて、作業を中止してください。api_key チェックが失敗している場合は、ユーザーに ANTITHESIS_API_KEY を設定するよう伝えてください。

同じ出力にある settings 配列には、snouty が解決したパラメーターが含まれています。たとえば、解決されたテナントは次のように確認できます。

snouty doctor --json | jq -r '.settings[] | select(.name == "tenant") | .value'

ユーザー入力の収集

開始する前に、次の情報をユーザーから収集してください。

1. テナント名（必須）— テナント名を把握している必要があります。snouty doctor --json から snouty が解決したテナントを読み取ってください（「事前確認」を参照）。snouty は環境または設定ファイルからテナントを解決するため、その値を信頼してください。doctor でテナントが未設定の場合にのみ、ユーザーに確認してください。

2. 知りたい内容 — 特定の実行におけるすべての失敗に関心がありますか？特定の失敗を調査していますか？全般的な概要を求めていますか？実行を比較しますか？これに応じて、従うワークフローが決まります。

実行から情報を取得する方法

情報を取得する主な方法は、--json オプションを付けて snouty runs <OPTION> コマンドを使用することです。--json オプションは、行区切りの JSON を返します。JSON のフィールドは、使用するオプションによって異なります。同じコマンドを --json なしで実行すると、フィールド数の少ない、人が読みやすい表形式の出力が返されます。

RUN_ID を把握する必要があります。run_id の取得方法については、references/run-discovery.md を読んでください。

ワークフロー

最近の実行を要約する

references/run-discovery.md を読んで最近の実行の一覧を取得し、レポートにまとめてください。

特定の実行を調べる

特定の実行（レポート）を調べるには、references/run-info.md を読んでください。その後、必要に応じて他のワークフローに進んでください。

実行をトリアージする

実行のステータスが「incomplete」の場合は、以下の「不完全な実行の診断」セクションを参照してください。

1. 実行の情報を読み込むには、references/run-info.md を読んでください
2. 実行情報の出力で links.triage_report が null または存在しない場合、この実行のトリアージレポートは生成されていません（通常は cancelled の実行や、一部の unknown／starting 状態で発生します）。これらの実行では properties および logs エンドポイントが 404 を返すため、この実行はトリアージできないことを報告してください。
3. properties を読み込むには、references/properties.md を読んでください
4. 成功数／失敗数を確認してください
5. インストルメンテーションのセットアップ状況を示すシグナル（Software was instrumented および Symbols were uploaded プロパティ）を確認してください。解釈方法については、references/instrumentation.md を読んでください。
6. すべての失敗の確認と新しい失敗の指摘を含む、実行の詳細な要約を作成してください。要約にはインストルメンテーションのステータスも含めてください。

失敗したプロパティを調査する

1. references/properties.md を読みます。snouty runs --json properties を使って、例とともにプロパティを抽出し、ログのダウンロード方法を確認します。

2. references/logs.md を読んで、ログの読み解き方を確認します。

3. 調査する各プロパティについて、次の手順に従います。 a. 最初の失敗例を選びます。 b. 該当する時点を見つけます。反例に moment フィールドがない場合（テレメトリ／メタプロパティについては references/properties.md を参照）は、反例の値を証拠として報告し、手順 c〜e は省略します。 c. references/logs.md の説明に従って、その例のログをダウンロードします。 d. ダウンロードしたログをローカルで分析します。 e. 問題の原因がはっきりしない場合は、同じプロパティのほかの反例や例のログもダウンロードすることを検討します。それぞれの発生箇所を比較し、失敗の原因を説明できる共通点や相違点がないか確認します。成功例のログと比較すると、成功時と失敗時の違いを見つけるのに役立つことがあります。

   プロパティの成功または失敗の評価をさらに見つけるには、snouty runs --json search を使います。まず snouty runs search --help を実行してください。クエリ言語の説明と、そのまま貼り付けて使えるスニペットが記載されており、アサーションの評価を ID で選択する例も含まれています。ID は調査中のプロパティデータの「name」フィールドです。「condition」フィールドを、さらに確認したい例または反例に照合してください。結果は --limit（既定値は 50）で上限が設定されたサンプルであり、一部の評価のみが表示され、すべてが含まれるとは限りません。すでに取得した例や反例が結果に含まれている可能性が高いため、各結果の moment を、すでにダウンロードしたものと比較してください。

4. 重要： 利用できる場合は、ログをテスト対象システム（SUT）のソースコードおよびワークロードと照合してください。

5. 失敗を詳しく調査し、その原因となった可能性のある事象のタイムラインを把握します。

6. 調査結果を報告します。

重要： プロパティのステータスやアサーションのテキストだけでは不十分です。失敗を理解するために必要な実行時の状況は、ログから確認できます。

タイムライン全体を検索する

ダウンロードしたログが対象とするのは、1 つの履歴のみです。実行中のすべてのタイムラインにまたがる質問（「イベント A は常に失敗 B より先に発生したか？」「先行する障害がなくても失敗は発生するか？」「このエラーを最初に記録したコンテナはどれか？」）に答えるには、snouty runs --json search を使います。クエリを書く前に snouty runs search --help を実行し、クエリ言語を確認してください。ログテキスト、コンテナ、アサーション、vtime ウィンドウによるフィルタリング、イベントセットの結合、同じタイムライン上の別のセットから最も近い前後のイベントによる各イベントへの注釈付けについて説明されています。結果にはすべて moment が含まれるため、references/logs.md の説明に従って、該当箇所までのログをダウンロードできます。

インストルメンテーションを確認する

SUT とワークロードがインストルメントされ、シンボルが登録されていることを確認するには、references/instrumentation.md を読んでください。

不完全な実行の診断

特定の実行の「status」が「incomplete」の場合、確認すべきエラーログがある可能性があります。「incomplete」ステータスの実行をトリアージする手順は次のとおりです。

1. snouty runs --json show ${RUN_ID} を実行します。
2. 返された JSON の failure_moment 構造を確認します。存在する場合は、failure_moment の input_hash と vtime を使用し、references/logs.md の手順に従ってログをダウンロードします。
3. 特に failure moment がない場合は、snouty runs --json build-logs ${RUN_ID} を使用してビルドログを取得し、ビルド内のエラーを探します。

links.triage_report に関する注意： 不完全な実行では、プロパティごとの properties エンドポイントと logs エンドポイントは通常 404 を返しますが、show では links.triage_report と failure_moment に値が設定されている場合があります。show に実際に含まれている内容を報告してください。そのフィールドが null でない限り、triage_report リンクが存在しないと断定してはいけません。不完全な実行のトリアージワークフローは、レポート URL の有無にかかわらず、failure_moment と build-logs を使用します。

一般的なガイダンス

• 失敗について結論を出す前にログを確認します。 失敗したプロパティに moment が指定された例がある場合は、根本原因を断定する前にログをダウンロードして分析します。例やログがないプロパティもあり、その場合はステータスのみが根拠となります。
• プロパティの失敗については、提供されている場合、「details」セクションを確認します。 これは、失敗時点のシステムの状態を明らかにするために、プロパティの作成者が選定したフィールドです。
• 結果をわかりやすく提示します。 プロパティのステータスを報告するときは、表またはリストを使用します。ログの調査結果を報告するときは、仮想タイムスタンプ、ソース、コンテナ、ログテキストを含めます。
• レポートはブラウザーで表示するよう案内し、署名付き URL は貼り付けないでください。 ユーザーがトリアージレポート全体を確認したい場合は、長い links.triage_report URL を表示するのではなく、snouty runs show <RUN_ID> --web を提案します。--web が機能するのは、トリアージレポートが存在する場合のみです。references/run-info.md を参照してください。

フォローアップスキルの提案

トリアージの要約の最後に、役立つ場合はフォローアップスキルや追加のトリアージワークフローを挙げた短い「次のステップ」セクションを追加してください。これらはユーザーへの提案として扱い、自動的に実行してはいけません。いつ呼び出すかはユーザー（またはユーザーのオーケストレーション）に委ねてください。ユーザーがスキルの連鎖実行（例：「トリアージを実行し、その後、失敗したプロパティをデバッグする」）を明示的に求めている場合は、その指示に従って連鎖を進めてください。

トリアージで判明した内容に応じて、提案する価値のあるスキル：

• antithesis-research — コードベースを調査し、テスト可能なプロパティをより適切に見つけます。失敗が個別のバグではなく、体系的なテストカバレッジの不足を示している場合に役立ちます。
• antithesis-workload — アサーション、テストコマンド、ログを拡張または改善します。すべてのプロパティが成功している場合は、ワークロードを段階的に改善するために提案してください。また、ワークロードの能力不足によりプロパティに到達できない場合にも提案してください。このスキルは、根本原因の分析に役立つようログを増やしたり、プロパティを修正したりするためにも使用できます。
• antithesis-debug — snouty runs exec を使って、失敗時点またはそれ以前の時点で実行中のシェルコマンドを実行し、コンテナー、プロセス、ディスク上の状態を調査します。ログの分析だけでは失敗の原因を説明できない場合に役立ちます。snouty が必要です。完了済みの実行をデバッグするにはデバッグセッションが必要で、キャンセルされるまでコア時間を使用します。
• antithesis-mutation-testing — プロパティごとに現実的なバグを1つ注入し、それぞれが検出されることを確認して、プロパティが実際に失敗し得ることを証明します。提案するのは、実行が成功して戻ってきている（失敗したプロパティがなく、先に追跡すべき SUT のバグもない）場合、かつカタログですでにミューテーションテストが実施された形跡がない場合に限ります。スクラッチブックのプロパティ証拠ファイルに ## Falsification セクションがあるか、antithesis/scratchbook/mutation-testing/ ディレクトリがあるか確認してください。すべて成功というレポートは、十分に保護されたシステムと、問題をまったく検出できないカタログとを見分けられない状況にほかなりません。

ユーザーが状況を再調査せずに次のスキルを呼び出せるよう、必要なデータ（run_id、プロパティ名、時点など）を含めてください。

セルフレビュー

このスキルを完了とする前に、以下の基準に照らして作業を確認してください。このスキルの出力は会話形式（要約、表、分析）なので、現在のコンテキスト内でレビューしてください。このファイルのガイダンスを読み直し、作成した回答と分析について、以下の各項目を順に確認してください。

レビュー基準：

• 報告した各プロパティのステータス（成功、失敗、未検出）は、推測や仮定ではなく、実際のプロパティ取得結果から抽出されている
• 調査結果には、プロパティ名、アサーションのテキスト、ログ行、タイムスタンプなど、プロパティデータの具体的な情報が記載されている
• ログを利用できる失敗プロパティについて、アサーションのテキスト、関連するログ行、時系列の情報など、対応に役立つ情報が含まれている。ログが存在する場合、失敗に関する結論はログの証拠に基づいている
• レポートに示されている内容と、そこから解釈または推奨する内容が区別されている
• 実行を比較する場合、相違点は一方のレポートだけでなく、両方のレポートのデータに基づいている
• バイナリがインストルメントされていないという主張は references/instrumentation.md に従っており、Software was instrumented プロパティの重複排除済みサンプルだけを根拠としていない