ログやセッションファイルの発生源（人間駆動 vs エージェント駆動、対話 vs headless ワンショット等）を、内容ヒューリスティックでなく起動元の直接メタデータフィールドで判別できることがある。内容の形（メッセージ数・定型マーカー・特定エントリ種別の有無）は人間の依頼が混ざり誤除外を生みやすいので、直接フィールドが存在するなら決定的シグナルとして優先し、内容ヒューリスティックはフォールバックに降格する。

見落としやすい失敗条件

• 直接フィールドを採用しても、そのフィールドがファイルのどこに現れるかはクライアント/フォーマットごとに違う。あるクライアントは1行目のメタデータに持つが、別のクライアントでは先頭の bookkeeping エントリ群には無く、最初の実メッセージエントリで初めて現れることがある。
• 「1行目だけ読む」最安走査を全クライアントに流用すると、後者ではフィールドが見つからず判定が発火せず、フィルタが無音の no-op になる（安全側に倒す設計だと全件が素通りして誰も気づかない）。
• 対策: フィールドの所在をクライアントごとに実データで確認し、「先頭行ではなく、それが現れる最初のエントリまで走査する」と手順に明記する。

判別ルールの検証

• 直接フィールドと内容プロキシ候補の両方を実コーパスで分布集計し、1:1 対応・混在ゼロを確認してから直接フィールドを正本にする。魅力的な内容プロキシ（特定エントリ種別など）が人間セッションを何割か巻き込むことを実測で示し、単独 signal から外す。
• 欠落・未知値は安全側（誤除外しない側）に残す。誤判定コストは非対称で、素通りは余分に読むだけだが誤除外は証拠を恒久的に捨てる。