> ## Documentation Index
> Fetch the complete documentation index at: https://docs.starfort.io/llms.txt
> Use this file to discover all available pages before exploring further.
# トレースのモニタリング（Opticon）
> Opticon → Tracing を使って、すべての Guard 評価を、そのアクション、ポリシーヒット、メタデータとともに確認します。
**Opticon** は Starfort のモニタリングアプリです。すべての Guard 評価について**トレース**を記録するため、各リクエストが何であったか、Guardian がどのように判断したかを正確に確認できます。
プロジェクト（またはその Guardian）から **Opticon** リンクで Opticon を開き、左ナビゲーションで **Tracing** を選択します。
## トレース一覧
各行は 1 件の Guard API ／ Desktop Agent 呼び出しを表し、入力、Guardian の出力、レイテンシ、**タグ**、そして**スコア**を表示します。Desktop Agent 呼び出しの場合、トレースの **session** は一致した [Control Profile](/ja/v1.3/admin/control-profiles) の名前であり、その **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 キー、モデル設定、プロセスタイプ）。
`BLOCK` または `MASK` タグでフィルタリングすると、何が検出され、どのポリシーが検出したかを正確に確認できます — ポリシーのチューニングや[トラブルシューティング](/ja/v1.3/desktop/troubleshooting)の際に非常に役立ちます。
## Opticon Fail-Safe (Fail-Open / Fail-Closed)
トレースの記録は本来**非同期**です。Opticonがダウンまたは無応答でも、Guard判定（PASS / MASK / BLOCK）はそのまま返され、記録だけが失われます — 観測プレーンはfail-openです。しかし監査が必須の運用では、このギャップが問題になります。記録されていないリクエストは、監査できないリクエストだからです。
v1.3からは、トレースの記録が最終的に失敗したときの動作を、**Project Settings → General**の**Opticon Fail-Safe**設定で**プロジェクト単位**に選択できます:
| モード | 記録方式 | 記録が最終的に失敗した場合 | 優先する価値 |
| -------------------- | ----------------------- | ------------------------------------ | --------- |
| **Fail-Open**（デフォルト） | 非同期ベストエフォート — 従来の動作 | 記録のみ失われ、判定はそのまま返される | 可用性・レイテンシ |
| **Fail-Closed** | 記録の成功がレスポンスの**前提条件**になる | 該当リクエストを**BLOCK**に格下げ — コンテンツは配信されない | 監査性 |
Fail-Closedの記録試行は\*\*有界（bounded）\*\*です — 時間とリトライの上限内でのみ行われるため、Opticonが無応答でもレスポンスが無限に待たされることはなく、BLOCKに帰結します。Opticonが正常に復帰すれば、操作なしで自動的に通常動作へ戻ります。
このポリシーが**プロジェクト単位**なのは、トレースがプロジェクトのOpticonバインディングを通じて記録されるためです — どのProject Guardianにもマッピングされずプロジェクトに到達し、観察・ロギングのみされるパケットも、このバインディングで記録されます。同じ会社内でもプロジェクトごとに監査姿勢が異なることもあります。
**適用されないケース** — Fail-Closedは、トレースが*存在すべき*なのに記録できなかった場合にのみ適用されます。そもそもトレースを生成しないリクエストは影響を受けません:
* Opticonロギングを明示的にオフにしたentry（意図されたオプトアウトであり、障害ではない）
* そもそもトレースを生成しないパス（認証失敗、決定論的ゲート、未サポート入力、上限超過の拒否）
* Opticonバインディングが構成されていないプロジェクト
ブロックの適用方法は他のfail-closedブロックと同じです。API呼び出し元はブロックレスポンスを受け取り、Desktop Agentはパケットを配信しません（設定されていればユーザーに通知）。
## 保持期間と Opticon が行わないこと
Opticon はランタイムデータのみを表示します。組織、プロジェクト、メンバーの管理はすべてコンソールに存在します。Opticon からそれらを**作成・削除することはできません**（Starfort が信頼できる唯一の情報源です）。コンソールのロールはここでも引き継がれます。
トレースの**保持期間**は Opticon で設定されますが、トレースが**手動で削除されることはありません** — トレースごとの削除も一括削除もなく、プロジェクトを削除してもそのトレースは削除されません。削除されるのは保持サイクルによってのみです。これは記録を完全な状態に保つための設計です。（ガバナンス変更 — 誰が設定を変更したか — は、別途の[監査ログ](/ja/v1.3/admin/audit-log)にあります。）