Opticon → Tracing
トレース一覧
各行は 1 件の Guard API ／ Desktop Agent 呼び出しを表し、入力、Guardian の出力、レイテンシ、タグ、そしてスコアを表示します。Desktop Agent 呼び出しの場合、トレースの session は一致した Control Profile の名前であり、その metadata にはリクエストの URL、HTTP メソッド、Content-Type、ヘッダーが含まれます。入力呼び出しとその出力呼び出しは1 つの Trace ID を共有するため、リクエスト→レスポンスの完全なサイクルを 1 つのトレースとして確認できます。API 呼び出しの場合、session は呼び出し元のsession_id であり、呼び出し元は同じ trace_id を渡すことで 2 つの呼び出しをリンクできます。
タグとスコアにより、フィルタリングと集計が簡単になります:
- アクション —
PASS、MASK、BLOCK - ポリシー結果 — 例:
PII Masking Policy:MASK、TOPIC:BLOCK - 呼び出し元 — 例: API キー名
- ステージ —
process_type:input - スコア — ポリシー名ごと、ポリシータイプで集約
トレースの詳細
トレースを開くと全体像を確認できます: 元の入力、processed_content（外部へ送出された処理済みコンテンツ）、解決された action、検出されたすべての項目、そして呼び出しのメタデータ（API キー、モデル設定、プロセスタイプ）。v1.4 からは、送出が発生する判定（PASS・MASK）では原本ではなく処理済みコンテンツが送られるため、実際に外部へ出た内容は processed_content です — レスポンス形式を参照してください。
MASK トレースの詳細 — アクションは MASK
Opticon Fail-Safe (Fail-Open / Fail-Closed)
トレースの記録は本来非同期です。Opticon がダウンまたは無応答でも、Guard 判定（PASS / MASK / BLOCK）はそのまま返され、記録だけが失われます — 観測プレーンは fail-open です。しかし監査が必須の運用では、このギャップが問題になります。記録されていないリクエストは、監査できないリクエストだからです。 v1.3 からは、トレースの記録が最終的に失敗したときの動作を、プロジェクト設定 → 全般 の Opticon フェイルセーフ 設定でプロジェクト単位に選択できます:
プロジェクト設定 → 全般 → Opticon フェイルセーフ
Fail-Closed の記録試行は**有界（bounded）**です — 時間とリトライの上限内でのみ行われるため、Opticon が無応答でもレスポンスが無限に待たされることはなく、BLOCK に帰結します。Opticon が正常に復帰すれば、操作なしで自動的に通常動作へ戻ります。
このポリシーがプロジェクト単位なのは、トレースがプロジェクトの Opticon バインディングを通じて記録されるためです — どの Project Guardian にもマッピングされずプロジェクトに到達し、観察・ロギングのみされるパケットも、このバインディングで記録されます。同じ会社内でもプロジェクトごとに監査姿勢が異なることもあります。
適用されないケース — Fail-Closed は、トレースが存在すべきなのに記録できなかった場合にのみ適用されます。そもそもトレースを生成しないリクエストは影響を受けません:
- Opticon ロギングを明示的にオフにした entry（意図されたオプトアウトであり、障害ではない）
- そもそもトレースを生成しないパス（認証失敗、決定論的ゲート、未サポート入力、上限超過の拒否）
- Opticon バインディングが構成されていないプロジェクト