通話記録フォーマットvConに『Claude Opus 4.6』を例示するエージェントセッション拡張が提案されている
音声・会話記録の標準フォーマット『vCon』に、AIエージェントの内部セッション(プロンプト・ツール呼び出し・推論過程)を記録する拡張を追加するIETF個人ドラフトを読んだ。仕様本文が示す具体例には『Claude Opus 4.6』と『claude-code/1.2.0』というモデル名・ハーネス名がそのまま使われていた。

目次
コールセンターの通話記録などを扱う標準フォーマット「vCon(Virtualized Conversations)」は、IETFのvConワーキンググループが正式に標準化を進めている仕様だ。この土台の上に、AIエージェントが人間との会話の中でどんなプロンプトを受け取り、どんなツールを呼び出し、どんな推論をしたかという「内部セッション」の記録を載せるIETF個人ドラフト「vCon Agent Session」(著者T. McCarthy-Howe氏、VCONIC所属、2026年5月20日提出)の本文を確認した。仕様が示す具体例には、見覚えのあるモデル名が使われていた。
3行まとめ
- このドラフトは、vConの「party(会話の参加者)」「dialog(発話)」「analysis(分析)」「attachments(添付ファイル)」という既存の仕組みだけを使って、自律AIエージェントの内部セッション(プロンプト・ツール呼び出し・ツールの結果・推論過程・ファイルやアーティファクトの来歴)を、人間同士の会話記録と並べて記録する「Compatible vCon extension(vCon互換拡張)」。新しいトップレベルのフィールドは追加しない
- エージェント自身は
role: "agent"を持つvConの参加者(party)として表現され、そのmeta.agent_sessionオブジェクトにmodel_id(例:モデルのベンダー識別子)・provider(例:"anthropic")・recording_agent(記録に使ったハーネスやCLI)を記録する- ドラフト本文が示す実例では、
"name": "Claude Opus 4.6"・"model_id": "claude-opus-4-6"・"provider": "anthropic"・"recording_agent": "claude-code/1.2.0"という組み合わせが、具体的な例としてそのまま使われている
なぜvConに載せるのか——2つの記録を1つにまとめる
ドラフトの導入部は、この統合の理由をこう説明している。
These two records have substantial overlap (parties, turns, artifacts, provenance, signing) and substantial complementarity (vCon has a rich party and consent model; VAC has a rich tool-call and reasoning model). Maintaining them as fully independent containers forces every implementer to invent linkage, duplicate identity, and re-solve consent.
(この2つの記録(人間同士の会話記録と、エージェントの内部セッション記録)は、実質的に重複する部分(参加者・発話・アーティファクト・来歴・署名)と、実質的に補完し合う部分(vConは参加者と同意のモデルが豊富、VACはツール呼び出しと推論のモデルが豊富)の両方を持つ。これらを完全に独立したコンテナとして維持すると、実装者は皆、連携の仕組みを自作し、身元を二重管理し、同意の扱いを再解決しなければならなくなる)
エージェントの内部セッションの記録形式自体は、このドラフトが新たに定義するのではなく、別の関連ドラフト「Verifiable Agent Conversations(VAC)」のCDDLスキーマに準拠させる形を取っている。
"Claude Opus 4.6"が実例として使われている
エージェントを参加者として表現する例が、本文にこう示されている。
{
"name": "Claude Opus 4.6",
"role": "agent",
"validation": "system",
"meta": {
"agent_session": {
"model_id": "claude-opus-4-6",
"provider": "anthropic",
"recording_agent": "claude-code/1.2.0",
"environment": {
"cwd": "/Users/example/project",
"vcs_branch": "main",
"vcs_commit": "abc123def456"
}
}
}
}
model_idとproviderは必須(REQUIRED)、recording_agent(記録を行ったハーネスやIDE、CLI)は推奨(RECOMMENDED)、ソースリポジトリを編集したセッションであればブランチ名やコミットハッシュを含むenvironmentはオプション(OPTIONAL)という位置づけだ。複数のエージェント(オーケストレーターとサブエージェントなど)が参加した場合は、それぞれが別々の参加者として記録されなければならない(MUST)。
エージェントの内部トレースをどう記録するか
ドラフト第6章は、ツール呼び出し・ツール結果・推論・システムイベントといった「内部トレース」を、vConのanalysis[]配列に載せる方法を具体的に定義している。1つのエージェントセッションにつき、対応する全ダイアログターンをまとめて1つのanalysisエントリにするのが基本形(SHOULD)で、そのエントリが必ず含む(MUST)フィールドは次の6つだ。
| フィールド | 内容 |
|---|---|
type |
固定値"agent_trace" |
dialog |
このトレースが対応するダイアログのインデックス配列 |
vendor |
モデル提供元(parties[i].meta.agent_session.providerと一致) |
product |
モデル識別子(model_idと一致) |
schema |
VAC仕様のURL(datatrackerの正規URLなど) |
encoding |
"json"(CBOR使用時は"base64url") |
body |
VACスキーマに準拠したJSONエンコード済みのトレース本体 |
粒度については、ツール呼び出しごとに個別のanalysisエントリを作る「per-tool-call」方式と、サブエージェントの分岐ごとに分ける「per-branch」方式の2つのバリエーションが許容されている(MAY)。ドラフトは、アーカイブ用途にはセッション全体を1エントリにまとめる方式を推奨(RECOMMENDED)し、後から特定の推論エントリだけを削除する「粒度の細かい編集(redaction)」が想定される場合はper-tool-call方式を推奨している。
エージェントがファイルやアーティファクトを変更した場合の記録方法(第7章)も定義されており、attachments[]のpurposeフィールドに使う初期値として3つが登録されている。
| purpose値 | 対象 |
|---|---|
agent_file_change |
エージェントが変更したソースファイル |
agent_artifact |
ファイル以外の生成物(DB書き込み・APIペイロード・生成文書等) |
agent_environment |
エージェント実行環境のスナップショット(作業ディレクトリの一覧・パッケージマニフェスト等) |
依拠する土台の1つ(VAC)がすでに失効・アーカイブ済みだった
このドラフトが「内部トレースのスキーマ」として正規参照(Normative Reference)している別のIETF個人ドラフト「Verifiable Agent Conversations」(著者Henk Birkholz・Tobias Heldt・Orie Steele)を、IETF Datatrackerで直接確認した。結果、こちらは「Expired Internet-Draft (individual)」「Expired & archived」(失効・アーカイブ済み)と表示されていた。最新版は2026年2月25日付で、Datatracker上の最終更新表示は2026年8月29日(この記事の確認直前)となっている。
つまり、vCon Agent Sessionドラフトのanalysisエントリのbodyが準拠すべきとしているCDDLスキーマの提供元自体が、記事執筆時点で失効した個人ドラフトということになる。vCon Agent Session側のドラフト本文がこの依存関係の状態変化(VAC側の失効)を認識して更新されている形跡は、rev00(2026年5月20日提出)のままである以上、確認できない。
一方で、vCon本体(土台となるコア仕様)は事情が異なっていた。参照文献に挙がっているdraft-ietf-vcon-vcon-coreをDatatrackerで確認すると、こちらは個人ドラフトではなく「Active Internet-Draft (vcon WG)」——IETFのvConワーキンググループが正式に採択した文書で、2026年8月31日時点でrev03(2026年6月30日更新)まで版を重ねている。つまりこの記事が扱っている拡張ドラフトは、「活発なワーキンググループ文書(vCon本体)」の上に「失効した個人ドラフト(VACスキーマ)」を組み合わせて依拠する、という構造になっている。
規制対応という文脈
このドラフトは、自動化された意思決定の監査可能で否認防止性のある記録を求める規制として、EU AI Act・NIST AI RMF・HIPAA・PCI DSS・ISO 42001を動機として挙げている。コールセンターの通話記録という実務に根ざしたvConの枠組みに、AIエージェントの行動記録を接続することで、こうした規制対応の文脈でも使える記録を目指す設計だと読める。
lawful basis・lifecycle関連ドラフトの中身までは確認していない
この記事では、vCon本体(draft-ietf-vcon-vcon-core)とVACスキーマ(draft-birkholz-verifiable-agent-conversations)の2つはDatatrackerでステータスを直接確認したが、同じくこのドラフトが参照しているdraft-howe-vcon-lawful-basis(同著者による関連ドラフト)とdraft-howe-vcon-lifecycleの本文は、この記事では開いていない。「Claude Opus 4.6」という名称が実在するAnthropicのモデル名と正確に一致するかどうかは、この記事の一次ソース調査の範囲を超えるため確認していない(ドラフトの例示に使われているというIETFドラフト本文上の事実のみを、この記事では報告する)。この記事を書いている自分自身は、vConやコールセンター業界の通話記録実務に関わった経験がなく、この拡張が実際にどこまで採用される見込みかについても判断材料を持たない。日本語ではZenn・Qiitaともに、このドラフト単体を扱った記事は検索時点で見当たらなかった。
関連記事: Claude Codeとは──コード生成に留まらない「仕事を渡せる」AIエージェント
感想・指摘はコメント欄へ。
出典・参照資料
AIニュースの解説を動画でも
YouTubeでは注目ニュースの背景を解説し、Xでは新着記事をお知らせしています。
コメント
まだコメントはありません。最初のコメントを書いてみませんか?
AIについて聞きたいことはありますか?
質問箱で無料で受け付けています。回答は公開され、他の方の参考にもなります。
質問箱を見る →新しい記事をメールで受け取る
AIの新しい発表を、出典付きで整理して届けます。