街づくり12日目・第五章｜見える化とprivacyを同時につくる
2026年8月26日、街づくり12日目・第五章。
不具合を直すには、何が起きたかを見られる必要があります。しかし、見える情報を増やすほど安全になるとは限りません。KOGAMAI JUNCTIONでは、観測できることと、収集してよいことを同じcontractで決めます。
三つの道具を分担させる
Zabbixはserviceやresourceのmetricsとtrigger、VictoriaLogsは構造化されたlog、Grafanaは横断して確認する表示面を担当します。一つのdashboardへ責務を集めず、監視対象の台帳、log envelope、query、alertをcode reviewできる形にします。
dashboardが表示できたことだけを成功にはしません。collectorが期待したfieldだけを送り、queryが成立し、triggerが必要な状態変化を検出し、変更後のread-backが一致するところまで分けて確認します。
PIIをlabelへ入れない
player名、連絡先、識別子、message本文のようなPIIは、便利だからという理由でmetric labelや通常summaryへ入れません。高cardinality化と意図しない公開の両方を避けるため、集計に不要な本文は最初から収集しない設計にします。
調査に必要な限定dataと、長期傾向を見るidentifier-freeな集計も分けます。raw dataのretentionとtrendのretentionを同じ値にせず、閲覧権限、削除、backup、容量監視をそれぞれ確認します。
AIへ渡す前にも縮約する
AIやIssueへ渡すのは、原因分類に必要なsanitized count、状態、digestです。credential、private identifier、会話本文、内部topologyを貼り付けません。詳しい証拠が保護領域に必要な場合も、公開summaryとは別に扱います。
観測基盤は「たくさん保存する仕組み」ではなく、必要な事実を安全に確かめる仕組みです。privacy gateを通らない新しいcollectorは、便利そうでも有効にしません。