要約

  • qlog の RawInfo は、元の全長やペイロード長を残しながら、生の値を省略または切り詰められる。
  • 残った長さはサイズの証拠であり、内容、妥当性、認可、処理結果、原因まで証明するものではない。
  • 収集目的、最小化規則、欠落、時計、観測点、アプリケーション結果を別々に保存して初めて、ログを安全に意思決定へ使える。

インシデント報告には「1,248 バイトの不正な要求が障害を引き起こした」と書かれていた。qlog には確かに length: 1248 が残っていた。一方、data はプライバシー設定によって記録されていなかった。要求の内容も、アプリケーションがそれを不正と判定した記録も、その処理が障害を起こしたという因果もなかった。

確認できたのは、ロガーの定義に従って 1,248 バイトという全長が報告されたことだけだった。報告書は、残された一つの事実に三つの意味を追加していた。

2026 年 7 月の draft-ietf-quic-qlog-main-schema-14 は、IETF QUIC ワーキンググループの現行 Internet-Draft であり、Proposed Standard を目指している。まだ RFC ではない。ファイル、トレース、イベント、時刻、スキーマ、シリアライズなど、ネットワークプロトコルの構造化ログに共通する枠組みを定める。暗号化された wire image の外側からは見えない端点の挙動を、複数の実装や分析ツールが共有しやすくする試みである。

その中で生データの扱いは、観測可能性を最大化する単純な設計ではない。何を残し、何を残さないかを明示的に分離する。

RawInfo は三つの独立した選択を許す

RawInfo には、エンティティ全体の length、ペイロード部分の payload_length、16 進表現の data を置ける。いずれも任意で、互いに独立して記録できる。生の値を省略して長さだけ残すことも、元の長さと先頭数バイトだけを残すことも認められる。

これは欠損ファイルの救済策ではない。センシティブな内容を保持せずにパケット化やオーバーヘッドを調べるための、意図された表現である。data が短い場合でも、長さのフィールドは元の全体を示すべきだとされる。値と長さの不一致は、値が切り詰められたことを表せる。

したがって、分析側は状態を区別しなければならない。値と長さがある。値だけがあり、その長さを計算できる。長さだけがあり、値は省略された。両方あるが値は切り詰められている。この違いを一つの「ペイロードあり」フラグに畳むと、仕様が守ろうとした境界が消える。

サイズから意味への飛躍

長さは有用だ。MTU、フレーム分割、増幅、バッファ利用、転送量の分析に使える。しかし、同じ長さのメッセージは無数にある。長さだけでは、HTTP フィールド、認証情報、コマンド、エラー本文、暗号化前のデータを区別できない。

さらに、qlog イベントの存在はアプリケーション結果ではない。パケットが送信された記録は、対向で受信された証拠ではない。受信イベントは、内容が復号・解析・認可された証拠ではない。状態遷移は、ユーザーが期待した処理を完了した証拠ではない。

原因にも同じ境界がある。具体的なイベント定義が任意の trigger を持つ場合、その値は原因候補を狭める。並列実装では周辺メッセージが時間的に離れるため、単に近くに表示されたイベントより強い手掛かりになる。それでも、trigger がない場面でサイズを原因ラベルの代わりに使うことはできない。

完全な形でも、完全な履歴ではない

生データの省略だけが不完全性ではない。qlog の event_schemas は、トレースに現れ得る名前空間や型をツールへ知らせるヒントである。列挙されたスキーマに属する全イベントが記録される保証はない。Core と分類されたイベントでさえ、すべてのトレースに存在すると期待してはならない。

固定サイズのリングバッファは新しいイベントで古い接続開始イベントを上書きできる。プライバシーやファイルサイズのため、イベント自体が意図的に省略されることもある。仕様はツールに、不完全なログでも適切な出力を行える堅牢性を求める。

ここで「適切」は、穴を推測で埋めることではない。残ったイベントを可能な範囲で読解し、答えられない問いを明示することである。JSON として妥当、スキーマに適合、時刻順に並ぶ、という三条件がそろっても、捕捉されなかった内容は復元されない。

最小化は利用目的と組にする

qlog は、通常なら QUIC や TLS の暗号化された wire image によって守られる情報を明らかにし得る。IP アドレス、接続識別子、Cookie、トークン、鍵、高精度時刻、生または復号後の内容などが含まれる可能性がある。草案は、qlog の取得・閲覧が平文通信へのアクセスに相当し得ると警告する。

だからこそ、生データを減らす判断には合理性がある。アクセス制御、監査、目立つ形での取得開始、保存期間、転送時・保存時の暗号化も推奨される。無制限に全バイトを残すことは、証拠品質の唯一の答えではない。

ただし、最小化した事実そのものを消してはならない。分析者には、そのフィールドがプロトコル上存在しなかったのか、ロガーが取得しなかったのか、取得後に削除されたのか、切り詰められたのかが必要である。さらに、その規則がどの接続、時間、役割、目的に適用されたかを知る必要がある。

実務上は、トレースとは別に取得プロファイルを版管理するべきだ。イベント種別ごとの有効・無効、RawInfo の長さと値の方針、切り詰め上限、匿名化、リングバッファ容量、サンプリング、アクセス権、保存期間、削除処理を含める。これは Daniel Kade による運用提案であって、qlog の隠れた必須項目ではない。

主張を残った証拠の大きさに合わせる

先の 1,248 バイトについて許される表現は明確だ。「このイベントには元の全長として 1,248 が記録され、生の値はこの取得プロファイルにより省略された」。もしパーサー拒否を述べたいなら、対応するイベントやアプリケーションログが要る。認可失敗なら認可層の証拠が要る。障害原因なら、時系列、trigger、対向観測、再現試験、サービス結果のつながりが要る。

この言い方は記事やダッシュボードを弱くしない。何を追加すれば結論が強くなるかを示すからだ。逆に、「サイズが大きかったから攻撃」「内容がないから安全」といった短絡は、観測コストを下げる代わりに判断の責任を隠す。

qlog の価値は、あらゆる秘密を保存することではない。存在する証拠を共通の形で扱い、存在しない証拠を勝手に作らないことにある。長さが残ったとき、長さだけを語れる組織こそ、次に必要な観測を正しく選べる。

出典