> ## 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. # 監査 — エージェント的改善検出 > AgentEye 監査 — エージェント的改善検出のドキュメント。 監査は、**セッションをまたいで**エージェントログを分析し、改善すべき点を見つけ出す定期実行ジョブです。アラートが既知のメトリクスをほぼリアルタイムで監視するのに対し、監査は*調査*を行います。設定したスケジュールに従い、対象ウィンドウに対して決定論的なポリシーチェックを実行した後、**AI信頼性エージェント**をセッションに対して投入します。エージェントはデータ自体にクエリを発行し、不審なトランスクリプトを読み込み、（必要に応じて）小規模な分析スクリプトを実行し、各発見の根拠を添えた**改善提案**をまとめます。 「エージェントの何を修正・改善すべきか」という問いへの答えには監査を使い、特定のしきい値を超えた瞬間に通知を受け取るにはアラートを使ってください。すべての改善提案はその根拠となった正確なセッションとクエリにリンクされており、ワンクリックで再発検知用のアラートをあらかじめ入力済みの状態で作成できます。 ダッシュボードの画面は **`//audits`**（サイドバー → *analyze* → *audits*）で、`audits:read` / `audits:write` 権限によって制御されています。 *** ## 実行の仕組み 各実行は、決定論的なベース層とエージェント的な調査層の2層構成になっています。 ### 1. ポリシーパス（決定論的） モデルが動作する前に、監査は対象ウィンドウに対して**SQLポリシーチェック**の小規模なカタログを実行します。これは既知の問題パターンにフラグを立て、一致したイベントの*件数*や*セッション*を報告する有界集計クエリです（一致したテキスト自体は報告しません）。カタログには以下が含まれます。 * イベントペイロード内の**シークレット／認証情報漏洩** — AWSアクセスキー、`sk-…` APIキー、PEM秘密鍵、JWT／ベアラートークン、`KEY=…` 形式の認証情報代入。 * **プロンプトインジェクションのマーカー** — "ignore previous instructions"、"reveal your system prompt" など類似表現。 * **PII** — SSN形式の数値（ヒューリスティック）。 * **ツール権限の拒否**および**ツール呼び出しのループ暴走**。 ポリシーヒットは kind `policy` のフィンディングとして永続化され、**常に表示されます**（1回の実行あたりの上限でトリミングされることはありません）。また、AIエージェントの最初の手がかりとして渡されます。この層はモデルを必要としないため、AIエージェントが利用できない場合でも監査は最重要のセキュリティシグナルを生成します。 ### 2. エージェント的調査（AI） 次に監査は**自律型信頼性エージェント**を実行します（ダッシュボードアシスタントと同じClaude Agent SDKサービスを使用し、監査専用のプロンプトが設定されています）。監査の**スコープ**（選択されたエージェント×環境）と**時間ウィンドウ**が与えられると、エージェントは以下を行います。 * アナリティクステーブルに対して読み取り専用のSQLクエリを実行する。 * 代表的なセッショントランスクリプトをいくつか読み込む。 * 必要に応じて、SQLでは表現できない分析（エラーのクラスタリング、分布の計算、取得済みペイロードの精査など）のために、**ネットワークアクセス・ファイルシステムアクセスなし、シークレットスクラブ済みの隔離されたインPodサンドボックス**内で短いPythonスクリプトを作成して実行する。 * 証拠のある**改善点**を記録する。 エージェントは監査の**感度**（低 / 中 / 高）に基づき、エラークラスタリング、ベースラインとの差異、トランスクリプト内のゴール失敗、ツールの誤用、品質/コストのトレードオフ、カバレッジのギャップなど、複数の調査軸から調査を行います。すべての改善提案は**証拠を引用しなければなりません**。エージェントが実際に調査したセッションIDや実行したSQLが根拠として必要です。サーバーは引用されたセッションの存在を検証し、**存在する証拠がない改善提案は破棄します**。エージェントは調査しますが、捏造はしません。 各改善提案には以下が含まれます。 * **推奨事項**（具体的な変更内容 — プロンプトの調整、ツールスキーマの修正、リトライポリシー、ガードレール、評価カバレッジの拡充など） * **期待される効果**と**工数**の見積もり（低 / 中 / 高） * **重大度** — `big`（オペレーターへの通知が必要）、`medium`（実行レポートに含める）、`small`（ダッシュボードのコンテキスト） * 安定した**フィンガープリント**（問題のカテゴリ＋スコープから生成され、今回の実行のセッションには依存しない）。これにより、証拠が変わっても同一の問題が実行をまたいで追跡される。 * 単純な決定論的監視で再発を検知できる場合は、ワンクリックで作成できる**アラートの提案**。 > **AIレイヤーはオプションですが推奨されます。** 監査パイプラインにAIエージェントが設定されていない場合でも、実行は行われ、ポリシーフィンディングは永続化されます。エージェント層については、黙って合格とするのではなく、「分析利用不可」と正直に報告します。 ### 障害モード 改善提案は組織の持続的な**障害モードカタログ**に分類されます（新しいモードの提案も可能）。モードによりパターンに実行をまたいだ安定したIDが付与され、長期的な再発追跡が可能になります。 ## トリアージのライフサイクル フィンディングページ（`/audits//findings/`）では： | アクション | 効果 | | -------------------------------- | -------------------------------------------------------------------------------------- | | **acknowledge（確認）** | フィンディングを表示したまま優先度を半分にする。 | | **resolve（解決）** | 修正済みとしてマークする。パターンが後日実際に再発した場合は**new**として再オープンされる — リグレッションは目立つ形で通知され、静かに履歴に埋もれることはない。 | | **mute（ミュート）** / **dismiss（却下）** | 永続的な抑制：パターンのフィンガープリントが記録され、実行をまたいでも二度と表示されない。mute は「既知・許容済み」に、dismiss は「有用でない」場合に使用する。 | | **reopen（再オープン）** | 抑制／解決をクリアし、パターンを再度ランキング対象にする。 | 低シグナルのノイズは、エージェント的改善に対する1実行あたりのフィンディング上限（`top_k`）で監査ごとに制御されます。ポリシーフィンディングはセキュリティ上重要であるため上限をバイパスし、常に表示されます。上限によって除外されたものは実行の統計にカウントされます — 静かに破棄されるものはありません。 ## スケジューリング * **頻度**（`schedule_interval_secs`）：1時間ごとから1週間ごと。**デフォルトは毎日**。監査はアラートよりも意図的に粗い粒度になっています — エージェント的調査はウィンドウ全体をスキャンし、実行に数分かかります。 * **ウィンドウ**：固定のローリングルックバック（例：「各実行で過去7日間をスキャン」）または**前回実行以降**（デフォルト）のいずれか。後者は前回の成功実行が終了した時点から引き継ぎ、境界イベントを取りこぼさないよう小さなオーバーラップがあります。 * 次の実行は前回実行が**完了**してから1インターバル後にスケジュールされるため、実行が遅くなっても同じ監査が並行して実行されることはありません。 * 監査ページの**今すぐ実行**ボタンで即時実行をキューに入れられます。 ## モデルの選択 監査を作成する際に、**オペレーターがエージェントサービス用に設定したモデルの一覧**から調査に使用するモデルを選択できます。モデルが1つだけ設定されている場合はキャプションとして表示され、複数ある場合は選択できます。未設定の場合は設定済みのデフォルトが使用されます。 ## 通知 実行によって**新しい**フィンディングが見つかると、監査は組織に設定されたチャンネルに通知します。アラートパイプラインと同じ `alerts.enabled_channels` ゲートと設定を使用します。 * **Slack** — 重要な（`big`）新規アイテムの概要とディープリンク。 * **Email** — 新しい改善提案（重大度上位、各アイテムの推奨事項、ディープリンク）を一覧にした**監査レポート**。監査に**email**チャンネルが設定されており、新規フィンディングが1件以上ある場合に送信される。 再発しているが既知のフィンディングについては再通知しません。 ## 設定リファレンス 監査定義はダッシュボード（`/audits/new`）またはAPIで管理します。監査ごとの設定には、スケジュールの頻度とウィンドウ、スコープ（`{"environments": [...], "agent_ids": [...]}`）、感度（`low` / `medium` / `high`）、通知チャンネル、1実行あたりのフィンディング上限（`top_k`）、モデル（`llm_budget.model` 経由）が含まれます。オペレーターレベルのサーバー設定（タイムアウト、サンドボックス、エージェントサービスURL）は [deployment.md](/ja/agenteye/deployment) に記載されています。 ## API すべてのエンドポイントは組織スコープで、標準のベアラーキー認証を使用します（[api-keys.md](/ja/agenteye/api-keys) を参照）。 | エンドポイント | 権限 | 目的 | | ------------------------------------ | ------------------------------ | -------------------------------------------------------------------------------------- | | `GET /audits` · `POST /audits` | `audits:read` / `audits:write` | 監査定義の一覧取得 / 作成。 | | `GET` / `PUT` / `DELETE /audits/:id` | read / write / write | 監査の参照、編集、削除。 | | `POST /audits/:id/run` | `audits:write` | 監査を即時実行キューに入れる。 | | `GET /audits/:id/runs` | `audits:read` | 実行履歴（ウィンドウ、ステータス、統計、フィンディング数）。 | | `GET /audits/findings` | `audits:read` | 組織全体のフィンディング。`audit_id`、`status` でフィルタリング可能。優先度順にソート。 | | `GET /audits/findings/:fid` | `audits:read` | フィンディングの詳細（推奨事項、証拠、優先度）。 | | `POST /audits/findings/:fid/status` | `audits:write` | トリアージ：`{"action": "ack" \| "mute" \| "dismiss" \| "resolve" \| "reopen" \| "assign"}`。 | 「監査は実行されたが何も見つからなかった」「コードサンドボックスが無効になっている」「監査メールが届かない」などについては [troubleshooting.md](/ja/agenteye/troubleshooting#audits) を参照してください。