> ## Documentation Index
> Fetch the complete documentation index at: https://docs.befailproof.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# 監査の実行とレビュー
> 監査を実行し、対象範囲を確認して、得られた検出結果を調査します。
監査のゴールと対象集団が、別のオペレーターでも有効な検出結果の判断基準を理解できる程度に具体化されてから実行してください。
## 実行と確認
1. **Analyze → Audits** に移動し、対象の監査を開いて **run now** を選択します。キューに追加されたというレスポンスが返れば、ディスパッチャーが間もなく処理を開始します。
2. 新しいランを開き、ステータス、ウィンドウ、所要時間、検出件数、レポートを確認します。
3. エビデンスセッションを選択して、正確なトレースを表示します。
4. 監査ページに戻って設定を編集したり、スケジュールを無効化したり、過去のランを調査したりできます。
```bash theme={null}
fp audits run checkout-reliability
fp audits runs checkout-reliability --limit 10
fp --json audits runs checkout-reliability
fp audits findings --audit checkout-reliability
```
ラン履歴、検出結果、トリアージコマンドについては [`fp audits` リファレンス](/ja/reference/cloud-cli#audits) を参照してください。
## 実行前の確認事項
* 選択した時間ウィンドウ内にセッションが存在することを確認する。
* 環境およびエージェントのフィルター設定を検証する。
* 参照コンテキストが最新の状態であることを確認する。
* ゴールが望ましい結論ではなく、障害モードを記述していることを確認する。
## ランのレビュー
まずランのステータス、セッションの対象範囲、モデル分析が実行されたかどうかを確認します。次に、各検出結果の深刻度、説明、エビデンスセッション、補足クエリ、推奨される防止策を調査します。
検出結果のステータスを使用して、承認、ミュート、却下、解決、再オープン、または作業の割り当てを行います。検出結果が却下された場合でもエビデンスは保持してください。その判断がなぜ下されたかを後から確認できます。
## 空のランまたは遅延したランの解釈
| ランの状態 | 意味 | 対処方法 |
| -------------------------- | ---------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| 分析が実行されたが検出結果がゼロ | 設定された感度において、選択したエビデンスからは検出結果が得られなかった。 | スコープに代表的なセッションが含まれているか確認し、ゴールやコンテキストが曖昧すぎなければ、結果は健全であると判断する。 |
| モデル分析がスキップまたは失敗した | ランはゼロ件の検出結果で完了するが、エージェント型の調査は実行されていない。決定論的なクレデンシャルおよびPIIスキャンは引き続きランの統計にマッチ件数を報告するが、検出結果は作成しない。 | 分析サービスまたは設定を修正して再実行する。空の結果を対象集団が健全である証拠として解釈しないこと。 |
| モデル分析が無効化されている | ランはゼロ件の検出結果で成功する。決定論的スキャンはモデル分析の代替にならず、検出結果も作成しない。 | 検出結果を生成できない監査に依存するのではなく、モデル分析を有効化するか、監査自体を無効化する。 |
| 分析キャパシティがすぐに利用できない | 監査はキューに残り、対象集団をスキップするのではなく再試行する。 | キャパシティが確保されるまで待つか、監査アンカーを分散させる。セルフホスト型のオペレーターは、audit-agent のレプリカ数と対応するディスパッチャーのキャパシティをスケールアップすること。 |
| 再試行ウィンドウを超えてもキャパシティが確保されない | ランはゼロ件の検出結果で処理を断念し、メール配信が有効な場合は失敗通知を送信する。 | 監査フリートが飽和状態にあるか、繰り返し再起動していないか確認する。 |
分析が実行されなかった場合、`since_last` 監査はその未分析のウィンドウを次の成功したランまで開いたままにします。スキップされた分析は障害が解消した証拠にはならないため、既存の検出結果は削除されません。
## 失敗通知について
ランの失敗またはモデル分析ステップの失敗が発生した場合、監査に設定されたメール受信者に通知が送られます。監査にメールチャネルが設定されていない場合、Failproof AI は組織の `alerts.email_default_recipients` 設定にフォールバックするため、監査が無音で壊れていても必ずエスカレーションパスが確保されます。
メールは組織レベルで有効化されており、SMTPが設定されている必要があります。設定されていない場合、失敗はログに記録されますがメールは送信されません。ランの失敗によって、監査の固定スケジュールアンカーが移動することはありません。
すべてのランは、各エージェントに使用された正確な[エージェントコンテキスト](/ja/audits/agent-contracts)をコントラクトスナップショットとして保存します。後から編集を行っても、以前のランに記録されたエビデンス基準は変更されません。
未検証の検出結果から直接ブロッキングポリシーをデプロイしないでください。引用されたトレースを開き、そのルールが安全でない動作と正当な作業を正しく分離していることを確認してください。