fix(audit,models): PHI・長さ上限の検出網の穴を塞ぎ、長さ管理を監査対象から切り離す

[izumacha]

Context

コードレビューで見つけた、PR #183 が副作用として開けた検出網の穴を起点に、6 巡のレビューで芋づる式に見つかった穴をすべて塞ぐ。

発端は、FreeTextMaxLengthAttributeTests が見ていたのが「[Sensitive] が付いた string プロパティ」だけだったこと。#183 で PHI 分類に [NotPhi] という 2 つ目の正当な選択肢が増えた時点で、この形が穴になっていた。新しい string 列に [NotPhi("...")] だけ付けて [MaxLength] を書き忘れると:

検査	結果	理由
AuditedEntityPhiClassificationTests	🟢 緑	[NotPhi] があるので「分類済み」
FreeTextMaxLengthAttributeTests	🟢 緑	[Sensitive] が無いのでそもそも対象外

エスケープハッチを足したぶん既存の検出網が黙って狭くなるという、#183 自身が塞いだのと同じ形の後退だった。この 1 件を追ううちに、同じ形の穴が本番コードにも実在していることが分かった。

実際に見つかった「本物」

• CauseCategory.Description が上限なしのまま残っていた — CauseCategory は監査対象ではないため、どの検査も届いていなかった。nvarchar(max) / text 相当の無制限列。範囲を広げた検査が即座に検出した。
• AuditedEntities がキャスト 1 つで書き換え可能だった — IReadOnlySet で公開しても中身が HashSet のままなので、((HashSet<string>)AuditedEntities).Clear() で監査ログを丸ごと黙らせられた。
• AuditLogsController.AllowedEntityNames が監査対象一覧の写しだった — 監査対象を足すと取り残され、フィルタの fail-open（絞り込みが黙って外れ全件返る）＋ドロップダウン欠落（証跡の行へ画面から到達できない）が同時に起きる。
• 値変換した 4 列（Severity / IncidentType / Status / MeasureType）が両検査から丸ごと外れていた — CLR 型だけで絞っていたため。

主な変更

1. 検出網の判定を「和集合」にする

「文字列列」の判定を CLR 型が string ∪ DB へ文字列として保存される に。片方への置き換えでは外れた側が誰にも見られなくなる（本命は CLR 側 — SerializeChanges が ChangesJson へ書くのは変換前の値なので、暗号化などで string → byte[] に変換した自由記述列は「文字列として保存されない」のに平文が監査ログへ流れる）。

さらに変換後の型が現れる場所は書き方で違う（実測）: HasConversion<string>() は GetProviderClrType()、HasConversion(v => …, v => …) は GetValueConverter()。片方だけ見ると、もう一方の書き方の列が素通りする。

2. 長さ上限の管理範囲を監査対象から切り離す

「どのエンティティを監査するか」と「どのエンティティの列長を管理するか」は別の関心事。前者から後者を導くと、監査ポリシーの変更が無関係な長さ管理まで黙って外す（fail-open）。LengthGovernedEntityTypes() が EF のモデルから名前空間ベースで導出するので、新しいエンティティは何もしなくても検査対象に入る。

3. shadow property を専用検査へ切り出す

LookupSensitiveMask は CLR プロパティの [Sensitive] を読むため、shadow の string 列は原理的にマスクできず必ず平文で書かれる。従来はこれが「分類漏れ」として [Sensitive] を付けろという実行不能な指示で落ちていた。実行不能な指示を出す検出網は、いずれ「直せないので検査を緩める」方向へ倒れるため、対処法（CLR プロパティへ昇格）が違う以上は別の検査が固有のメッセージで落とす。

4. 検出網そのものが死んでいないかを見張る

EveryLengthLimitedEnumColumn_IsActuallyExamined が「見るべき列を全部見たか」を、判定とは独立な手がかり（enum 型でかつ長さ上限を持つ永続化列）で照合する。同じ判定でガードを書くと、判定が狭まったときにガードも一緒に狭まって「違反ゼロ＝緑」で無力化されるため。

5. その他

[MaxLength] と fluent HasMaxLength() の値の一致を固定 / 属性側とモデル側の許容値を意図的に別集合に / ラベル表の網羅性を固定 / Array.AsReadOnly で監査対象を真に不変に / 写しと重複の集約。

検証

変異テスト 8 通り — それぞれ対応する検査だけが赤になることを実測。とくに次の 2 つは、修正前は全件緑で素通りしたことを確認している:

変異	赤になる検査
[MaxLength] 無しの [NotPhi] 列	PersistedStringColumns_MustHaveMaxLength
shadow string 列	PersistedStringColumns_MustHaveBackingClrProperty
値変換された未分類の列	PHI 分類
自由記述列に string → byte[] 変換＋[Sensitive] 除去	PHI 分類
EnumCode を 5 へ縮める	切り詰め検査（3 件）
判定を半分に戻す	網羅ガード（Severity / Status / MeasureType を名指し）
属性(500) と fluent(100) の食い違い	ModelMaxLength_AgreesWithMaxLengthAttribute
ラベル表から 1 件落とす	EveryAuditedEntity_HasJapaneseLabel

CI と同じコマンドをローカルで実行、すべて緑:

dotnet restore --locked-mode           ✅
dotnet build --configuration Release   ✅ 警告 0
dotnet test  --configuration Release   ✅ 496 件（479 → 496）
npm run typecheck                      ✅

CI 3 ジョブ（build-and-test / Docker image build & smoke test / Vercel）もすべて success。

注意（デプロイ時）

CauseCategory.Description に上限を付けたため、Migrations/ を PostgreSQL / SQL Server 向けに再生成する配備では varchar(500) になる。既存行が 500 文字を超えているとマイグレーションが失敗する（Postgres は切り詰めずエラー）。シードのマスタデータは十分短いため実害は想定していないが、runbook に記載しておくのが安全。既定の SQLite は TEXT に長さ制約が無いためマイグレーション本体は空。

🤖 Generated with Claude Code

https://claude.ai/code/session_01AAEwHDpPsNzmEnxHPmzKf5

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
incident-insight	Error		Aug 30, 2026 9:32am
incident-insight-jjt5	Error		Aug 30, 2026 9:32am