運用

デプロイ形態

• 単一マシンの docker compose。既定の compose コマンドが本番ビルドを生成します （nginx がコンパイル済みフロントエンドを配信、バックエンドは最小バイナリイメージ）。
• データベースは PostgreSQL。スキーマは単一の baseline migration で完全定義され、 起動時の自動マイグレーションはゼロ——未知の既存スキーマバージョンには 起動拒否で応じます。
• 現行設計はバックエンド単一インスタンスが前提。マルチレプリカ / HA は未対応です。
• TLS は外部 ingress（リバースプロキシ）で終端。アプリケーションは TLS-ready の 契約を保ち、動作する例を同梱しています。

出荷時の安全基準

これらの基準はデプロイフローに組み込まれており、設定で無効化できません：

• 公開のブートストラップ資格情報は内蔵されません。初期管理者パスワードは デプロイ担当者が設定し、初回ログインで変更が強制されます。
• 本番ビルドは JWT シークレットが内蔵の開発既定値のまま（または長さ不足）だと 起動を拒否します。quickstart.sh は新しい値を自動生成します。
• 保存される機微データは KEK / DEK のエンベロープ暗号化。鍵台帳、ローテーション ガバナンス、KEK 切替ステートマシンつき。

バックアップ

アプリケーションデータ（監査記録・録画・データベース）は DATA_PATH で指定した 単一ディレクトリ配下に集約され、バックアップ範囲はそのディレクトリと .env （鍵設定を含む）に収れんします。詳細なバックアップと復元の手順、アップグレード 手順、プラットフォーム自身の特権資格情報のローテーションは、メインリポジトリの docs/ops/ にある四つの運用手順書に成文化されています。

監査完全性の運用前提

証跡チェーンのチェックポイントは syslog でオフホストに固定されます——これが意味を 持つには、オフホストの syslog コレクターが必須の付帯設備です。監査データと その完全性アンカーが同じマシンにあると、「マシン管理者が改ざんして痕跡を均す」は 検出不能の領域に戻ってしまいます。独立した syslog の宛先（SIEM か最小構成の syslog サーバー）を計画してください。

境界も知っておいてください：外部 syslog は補助コピーであり、一次監査ストアの 代替ではありません。宛先が落ちても接続は塞がれません——イベントは有界バッファを 流れ、あふれれば監査失効警告が上がります。

可観測性

GET /metrics が Prometheus 形式で運用指標を公開します（意図的に /api の外に 置かれ、設定ゼロでは外部に露出しません）。録画ストレージの使用量も可視化。 三種類の監査イベントは RFC 5424 syslog で外部 SIEM にも転送できます。

保持と削除

監査データには保持ポリシーがあり、期限切れデータはチェックポイント区間単位で バッチ削除されます。削除自体が監査され、tombstone が残るため、悪意ある削除と 区別できます。