要約

  • vCon overview の revision 02 と core の revision 04 は、なお作業中の Internet-Draft である。作成者が会話の範囲を定義し、主要四領域はいずれも省略できる。
  • JWS は署名対象の payload の完全性と、信頼方針の下での署名鍵の保持を示せる。会話を漏れなく捕捉したこと、当事者の本人性、同意の現在性、分析の精度までは自動的に示さない。
  • amended がつなぐのは署名済み状態の履歴である。意思決定には、個々の主張を情報源、対象範囲、目的、権限主体へ結び付ける会話証拠台帳が別途必要になる。

監査担当者の手元には、整然とした三つの vCon がある。最初は録音、次は文字起こし、最後は当事者名の訂正と感情分析を含む。JWS はすべて有効で、後の版は前の UUID を amended で参照している。取得できた音声の SHA-512 も content_hash と一致した。

しかし、転送前の別チャネルは 403 で取得できない。本人名への訂正を行ったのは認証元ではなく文字起こし会社だった。分析には vendor があるだけで、モデル、言語、設定がない。録音への同意は存在するが、感情推定を人事評価へ使う目的は書かれていない。

署名検証は一つも失敗していない。それでも、この資料から結論を出すべきではない。暗号が弱いのではない。完全性という答えに、真実性と権限という別の質問を重ねたことが問題なのである。

draft-ietf-vcon-overview-02 は 2026 年 9 月 30 日付、draft-ietf-vcon-vcon-core-04 は同年 9 月 7 日付で、IETF Virtualized Conversations ワーキンググループの Internet-Draft だ。RFC でも完成規格でもない。会話に関するデータを JSON でまとめ、通信基盤、分析事業者、セキュリティドメインをまたいで扱えるようにする。その移動性が有用であるほど、受け手は「何の保証が一緒に移動したか」を細かく見なければならない。

「検証済み」を五つに分解する

一つ目は完全性で、いまの payload が署名時のバイト列と同じかを問う。二つ目は署名者の認証で、鍵と証明書チェーンが誰またはどのドメインへ結び付くかを問う。三つ目は取得・加工の来歴で、各要素をどのシステムが観測、生成、変換したかを問う。四つ目は意味上の正しさで、名前、時刻、文字起こし、推定が現実と合うかを問う。五つ目は権限で、その主体が収集、変更、開示、利用を行ってよいかを問う。

JWS が直接扱うのは第一であり、適切な信頼方針があれば第二にも寄与する。vCon の構造は第三の証拠を運べる。第四と第五は payload 外部の判断だ。誤った記述も正しく署名できるし、正しい記録も目的外に使えば権限を欠く。

したがって、画面上の単一の緑色ラベルは危険である。「payload 完全性は有効」「署名証明書は受理」「捕捉範囲は未確認」「本人性は保留」「利用目的は不許可」と分けるべきだ。状態の粒度が、証拠を権力へ化けさせない。

会話の境界は観測事実ではなく編集判断でもある

overview は、一つの vCon が一本の録音だけでも、メッセージから通話、フォローアップメールまでの経路全体でもよいとする。SMS のように自然なセッション境界がない媒体では、作成者が始点と終点を選ぶ。

さらに parties、dialog、attachments、analysis はすべて任意だ。当事者定義を欠く録音も有効な表現になり得る。core は recording、recording-set、text、transfer、incomplete を区別し、情報が乏しい場合の placeholder も認める。一つの recording が通話の一部または特定チャネルしか含まない場合もある。

これはデータ最小化や段階的導入に役立つ。しかし、形式が妥当だから完全だとは言えない。欠落は意図的な最小化、障害、あるいは都合のよい選別のどれでもあり得る。署名が固定するのは選ばれた範囲であり、選ばれなかった部分の不存在ではない。

重要な利用では、主張する開始・終了時刻、チャネル、転送区間、収集システム、既知の欠落、取得方針、範囲を決めた責任者を記録する。呼制御イベント、message ID、録音装置の稼働記録、別ドメインのログで裏付ける。

overview は dialog を会話の “ground truths” と呼ぶ。これは派生分析に対する一次資料という位置付けであり、センサーが現実を余さず捉えたという意味ではない。真正な録音であっても、決定的な区間を含まないことはある。

party の名前と本人確認を同じ状態にしない

Party Object は名前、電話番号、メール、SIP URI、DID、UUID、位置情報を持てる。validation は検証データそのものを公開せず、どのように本人性を確かめたかを記録する。プライバシー上の分離として有用だが、受け手が根拠を評価する必要は残る。

署名された validation が「資格情報」と記していても、どの資格情報をいつ、どの保証水準で、どのアカウント状態に対して確認したかは分からない。署名はその記述を誰が引き受けたかを示すのであって、確認手続そのものを再実行しない。

依拠する本人主張ごとに、情報源、検証イベント、証拠参照、時刻、保証水準、責任ドメインを結ぶ必要がある。表示名と「自然人を特定済み」は別の状態だ。

永続 UUID も、付与した namespace の中で意味を持つ。組織内で担当者を横断照合できても、可搬コンテナへ入っただけで普遍的身元にはならない。後続版がエイリアスを実名へ変更したなら、その署名者が本人情報を変更する権限を持つかを別に確かめる。

ハッシュは残っても、参照先は失われる

dialog、attachment、analysis はインラインにも HTTPS の外部参照にもできる。content_hash と SHA-512 によって、取得したバイトが署名済み参照と一致するかを確かめられる。

一方、core は外部データの安全な保管、アクセス制御、資格情報の受け渡しを範囲外とする。403 なら現在の利用者は読めず、404 なら保存方針で消えた可能性がある。ハッシュは正しいまま、証拠だけが検査不能になる。

運用表示は少なくとも「署名参照の完全性」「実際の取得可否」「現在の目的に使う権限」を分ける。ファイルの安全性、デコード、時間的な網羅性も別だ。

長期証跡で vCon と hash だけを保存すると、「特定のバイトが存在したというコミットメント」は残るが、後日の再検査能力は残らない。実体を管理下で保管するか、持続的アクセスを約束するか、証拠能力の期限を明示する必要がある。

分析の出所は精度保証ではない

Analysis Object は文字起こし、翻訳、要約、感情、レポートを扱う。core は分析形式を一律に規定せず、vendor を必須とし、product と schema を任意で持たせる。overview も、実装によって品質と解釈が大きく異なると説明する。

この情報は作成元とデータ形式の判別に役立つ。しかしモデル版、プロンプト、locale、閾値、前処理、入力スナップショット、人手修正までは示さない。署名済みの感情ラベルが、そのベンダーの出力として真正でも、判断材料として正しいとは限らない。

派生結果には個別の受領記録が要る。入力オブジェクトの index と hash、vendor、product、schema、モデルまたは規則版、設定、locale、出力 hash、confidence の意味、人手確認、許可目的を残す。この会話証拠台帳は Daniel Kade の運用提案であり、Internet-Draft の規範要件ではない。

形式の柔軟性は将来の分析を受け入れるための長所だ。同時に、JSON 適合性へ品質判定を委ねられないことも意味する。

同意は歴史的記録であり、現在の万能許可ではない

overview は同意と来歴を会話の重要な文脈として扱う。privacy primer と lawful-basis の草案は通知、目的、法域を検討する。ただし、署名済み vCon を普遍的な適法証明書へ変えるものではない。

同意の主張には、誰が、どの方法で、いつ、どの方針を見て、どの収集・分析・共有・保存目的へ同意したか、どの法域で、撤回されたかという時系列がある。処理の根拠が同意以外の場合もある。適用判断は現地のガバナンスに属し、本稿は法的結論を出さない。

署名は「その時点でその主体がこの同意主張を記録した」ことを認証できる。現在の用途を覆うか、主張者にその権限があるか、撤回後に何を止めるかは別の判断だ。

明日の撤回で昨日の署名が無効になるべきではない。履歴の完全性は維持しつつ、現在の処理権限を変えるのが正しい分離である。

改訂チェーンは状態を保存するが、最新版を裁定しない

署名済み vCon を直接変更すれば署名が壊れる。そこで新しい instance version を作り、前版を深くコピーして追加・修正し、amended から旧 UUID、必要なら URL と hash を参照する。複数の security domain が順番に寄与して署名できる。

このチェーンは各時点のコミットメントを保存する。コピー漏れがないこと、index の意味が維持されたこと、訂正が正しいこと、新しい署名者にそのフィールドを変える権限があることまでは保証しない。受け手は前版を取得・検証し、オブジェクト単位で差分を比較し、変更権限を評価する。

redaction では問題がさらに明確だ。core はテキスト、音声、映像の具体的な削除手法を範囲外とし、正確さの assurance を作成・署名主体へ委ねる。正直な署名者でも、attachment、analysis、未知 extension 内の個人情報を見落とせる。

「最新の署名版」を「権威ある版」と同義にしてはいけない。分析サービスは transcript を追加できても、party identity を書き換える権限はないかもしれない。

extension の無視可否は処理目的で変わる

extension は新しい項目を追加し、既存の意味を変え、廃止もできる。非互換 extension は critical へ列挙し、未対応の processor は処理せず拒否または報告しなければならない。

互換性は文脈依存でもある。transcriber は未知項目を無視してよい場合があるが、redactor は個人情報を取り残さないため、すべてのデータ項目を理解する必要がある。同じ vCon が前者には使えて後者には使えない。

extension 一覧、critical、registry と実装の版、実行する操作、無視または拒否した理由を記録する。JSON の parse 成功は、意味を理解した証拠ではない。

コンテナの隣に会話証拠台帳を置く

意思決定ごとに、vCon UUID、payload hash、形態、範囲と欠落、寄与システム、署名者と証明書状態、信頼方針、本人性証拠、捕捉範囲、外部取得と権限、分析入力と設定、目的根拠、extension 能力、前版と差分、決定責任者と巻き戻し経路を一つに束ねる。

観測と転記を混ぜない。「取得したバイトの SHA-512 が一致」は観測だ。「資格情報で本人確認済み」は検証イベントに結ぶまで payload 内主張だ。「品質監査にこの日まで利用可」はローカルな権限判断だ。

受理手順は 範囲 -> 取得 -> バイト検証 -> 署名者特定 -> 主張権限 -> extension -> 系譜 -> 主張検証 -> 目的許可 -> 依拠記録 -> 撤回監視 となる。

冒頭の案件なら、暗号検証結果は保持する。欠けたチャネルが必要な判断は止める。本人変更は証拠待ちで隔離する。感情分析は保存しても高影響判断へ使わない。歴史上の同意は真正な記録として残し、新用途は改めて許可を得る。