Summary

  • dialog の本文を除き殻だけ残す方法は、時刻、参加者、継続時間、索引を保てる。その一方で、一つの発言に混在していた非機密の主張まで失い、場合によっては参加者や位置そのものを漏らす。
  • VCON core の前版参照、外部内容のハッシュ、署名は、版の系譜とバイト列と署名者を確認する仕組みである。機密箇所をすべて発見したことや、置換値が真実であることは証明しない。
  • 重大な行為に使う派生記録には、機械可読な変換レシートと利用制約が要る。本稿の最小レシートは運用上の提案であり、draft-rosenberg-vcon-redaction-00 が既に標準化した要件ではない。

殻が保存するもの、奪うもの

会話を監査するとき、位置は重要である。誰がいつ話し、どの発言の後に何が起きたかが分かれば、意思決定の流れを追える。そこで本文だけを取り除き、dialog のメタデータを残す方法は合理的に見える。

ところが自然な発言は、機密部分だけで完結しない。「二重請求なので返金してほしい。口座番号は……」という一つのターンには、保護すべき識別子と残すべき異議申立てが同居する。殻を残しても、顧客が二重請求を訴えた事実は消える。逆に保護対象が証人であれば、話者と時刻を残すだけで秘匿目的を損なうことがある。

2026年9月29日付の draft-rosenberg-vcon-redaction-00 は、この選択をいくつかの独立した軸に分ける。編集をソフトウェアに明示するか、影響位置を示すか、参加者を示すか、人やモデルが編集を見抜けるか、内容を除去するかタグを付けたまま残すか、である。

ただし文書の地位は限定して読まなければならない。これは Informational を意図する個人 Internet-Draft の第00版で、用途と要件を議論する文書である。RFCではなく、VCONワーキンググループ採択文書でも、IETF合意でも、実運用の証拠でもない。

core が結べるのは版と版の間

VCON core の第04版は、redacted オブジェクトが未編集または編集の少ない前版を UUID で参照すべきだとする。アクセス制限付き URL と内容ハッシュを追加でき、URL があるならハッシュが必須となる。派生版は作成者が署名すべきである。配列要素を完全に削除する場合は、後続索引を動かさないため空要素を残すことが推奨される。

この仕組みは有用だ。UUID は系譜を示し、ハッシュは参照先バイト列の変更を検出し、署名は誰が派生版を主張したかを示す。空要素は既存の参照位置を守る。

しかし core は、テキスト、音声、映像をどう編集するかを対象外としている。有効な JWS 署名は、鍵の持ち主がそのバイト列に署名したことを示すだけだ。検出漏れがないこと、残った文が正確であること、合成した声や口座番号が原発言であることまでは保証しない。空要素もまた、発言の位置を知らせる信号になり得る。

署名、変換の正しさ、元の真実性、受信者の利用方針、実際の行為は別の問いである。検証可能な対話に関する関連草案も、署名は署名者を示すが内容の真実性を保証しないと明記し、実行環境、記録者、保存、検証者、意思決定者を別の信頼境界として扱う。

編集方法ごとに失う証拠が違う

dialog 全体の削除は内容を強く隠すが、索引をずらし、参照を壊し、発言があったという事実すら薄くする。残った会話が自然につながれば、人は欠落にも気付かない。

殻の保持は順序と存在を示すが、混合目的の発言を丸ごと失う。参加者と位置を残すため、保護目的によっては情報を出し過ぎる。

XXX や REDACTED のような可視置換は編集を示唆する。しかし普通の文字列に過ぎず、原発言が同じ語だった可能性がある。言語をまたげば慣例も変わる。機械が型や範囲を安全に推測することはできない。

もっと自然な置換は、人目に付きにくい代わりに、作り物を観測事実のように見せる。草案は返金会話の口座番号を例にする。後続エージェントがもっともらしい偽番号へ送金すれば、秘匿は成功しても業務は失敗する。

タグ付けは元データを残し、受信者の認可に応じて隠す方式である。証拠は豊かに残るが、表示器、エクスポート処理、再共有先のどれか一つがタグを無視すれば漏えいする。技法の名称だけでは、安全な推論範囲は決まらない。

派生版に添える変換レシート

本稿は、高い影響を持つ利用の前提として、派生版とは別に署名された変換レシートを提案する。これは第00版の確定仕様ではなく、Daniel Kade による運用上の分析である。

最低限、元 VCON と派生 VCON の識別子およびコミットメント、ポリシーの版と目的、正確な機械可読位置、変換前のデータ型または意味クラスを含める。各位置について、削除、殻保持、可視置換、もっともらしい置換、タグ、暗号化のどれを行ったかを宣言する。

さらに、位置と参加者を意図的に残したのか抑えたのか、処理者、署名鍵の適用範囲、処理時刻を記録する。すべての位置指定の検証結果を残し、解決不能が一件でもあれば重大利用を閉じる。支払、アカウントや資格情報の変更、法的帰属、出所を区別しない学習には、もっともらしい置換値を使わないという制約も必要だ。

RFC 6901 の JSON Pointer は位置を指せるが、解決失敗時の処理はアプリケーションに委ねる。RFC 7515 の JWS は完全性と署名者を支え、RFC 8785 は JSON の正規化を再現可能にする。それでも検出の網羅性は証明できない。制御された原本照合、サンプリング、テキスト・音声・映像間の整合性試験は別に要る。

Lu Heng の reality layers に従えば、原会話、目的別のプライバシー表示、変換者の主張、後続行為は別の現実である。後続行為にも独自のレシートを発行し、派生版のコミットメント、変換レシート、ローカル方針、実際の効果を結ぶべきだ。系譜は責任を見えるようにするためにあり、層同士を同一視するためにあるのではない。

出典と限界

対象草案は初期の議論文書で、位置指定、失敗処理、署名、正規化、認可などに未解決部分がある。本稿は特定のコールセンター、モデル提供者、編集製品、VCON実装を評価しない。個別法域での適法性も断定しない。GDPR第5条とNIST SP 800-122は、最小化、正確性、保護を同時に考える背景であり、本稿のレシートを法的に承認するものではない。