次に何を修正すべきか、推測をやめよう
アラートは既知の問題を検知します。監査は未知の問題を検知します。設定したスケジュールに従い、監査はすべてのエージェントセッションを横断的に読み取り、修正すべきパターンを探し出します。ログをひたすらスクロールして問題を見つけようとする時間ではなく、発見した内容への対処に時間を使えるようになります。 1回の実行で、本番環境でエージェントを実際に壊す障害モードを調査します：- エラークラスター：共通の根本原因を持つ同じ障害の繰り返し。
- ベースラインからのドリフト：既知の正常ウィンドウから静かに乖離していく挙動。
- トランスクリプト内のゴール失敗：技術的には完了したが、本来の目的を果たせなかった実行。
- ツールの誤用：不適切なツールの選択、不正な引数、または呼び出しを無駄に消費するループ。
- 品質とコストのトレードオフ：より安く得られる出力に対して過剰な費用をかけている箇所。
- カバレッジのギャップ：どのevalやアラートも監視していない挙動。
すべての推奨事項には根拠が伴う
発見内容を盲目的に信頼する必要はありません。各推奨事項には、その根拠となった正確なセッションとそれを発見したSQLが引用されています。主張を逆算して検証する手間なく、ワンクリックで証拠を開いて問題を確認できます。 認証情報の漏洩に関する発見では、さらに一歩踏み込んでマッチした個別のイベントへのリンクが提供されます。クリックすると、セッション内のその正確な瞬間に直接ジャンプでき、長いトランスクリプトの先頭からスクロールする必要はありません。リンクにはイベント名が表示されますが、検出された秘密情報は発見内容に書き込まれることはないため、発見内容を読むことで認証情報が二重に記録される心配はありません。セッションが保持期間を過ぎてイベントが存在しない場合も、誤操作かと悩ませることなく、ページに明確に表示されます。 これが監査の誠実さを保つ仕組みでもあります。サーバーは引用されたすべてのセッションの実在を確認し、根拠が成立しない推奨事項はすべて破棄します。監査は調査するものであり、でっち上げはしません。リストに載るのは実在して再現可能な問題であり、重要度順にランク付けされ、最大の改善効果を持つものが先頭に表示されます。修正をガードレールに変える
問題を修正することは成果の半分に過ぎません。もう半分は、同じ問題がひっそりと再発しないようにすることです。すべての発見には再発アラートを下書きするワンクリックショートカットが付いており、調整可能な適切な初期トリガーがあらかじめ入力されています。発見をクローズしてアラートを有効化すれば、次にそのパターンが現れたとき、将来の監査で再発見するのではなく、通知を受け取れます。どこで使えるか
監査はダッシュボードの/<org-slug>/audits（サイドバーから analyze → audits）にあります。実行結果と発見内容の閲覧には audits:read 権限が必要です。監査の作成・編集・トリアージには audits:write 権限が必要です。監査のスコープとケイデンスを設定し、次のスケジュール実行を待たずにすぐ結果が欲しいときは Run now をクリックしてください。