要約

  • RFC 9996 は application/protobuf と application/protobuf+json を登録し、シリアライズ済みオブジェクトのバイナリ表現と ProtoJSON 表現を分けた。
  • 任意の version は将来のワイヤー符号化版のための値で、スキーマ言語の世代や .proto の改訂を示さない。ワイヤー互換のビットでも意味は異なり得る。
  • Daniel Kade は、メッセージ選択、スキーマのダイジェスト、公開権限、互換性判定、デコーダー方針、変換履歴、採否を分けて結ぶ「スキーマ文脈受領証」を提案する。

失敗しない誤読がいちばん見つけにくい

構文エラーなら処理は止まり、運用者は異常を認識できる。厄介なのは、受信したボディーが正当な application/protobuf で、ライブラリも問題なくオブジェクトを返す場合だ。送信側のフィールド 5 が権限範囲、受信側のフィールド 5 が数量なら、同じワイヤー列が異なる業務判断を起こす。

RFC 9996 はこの意味合わせを保証していない。2026年7月に IETF のコンセンサスを表す Informational RFC として公開され、バイナリ用の application/protobuf と ProtoJSON 用の application/protobuf+json を登録した。複数の歴史的な x- 名に代わる、共有可能な表現名を整える仕事である。

文書は対象を明記する。メディアタイプが運ぶのはシリアライズ済みオブジェクトであり、IDL やオブジェクト定義を運ぶなら適切なテキスト型を使う。受信者は外側の表現を特定できるが、番号から意味を復元する定義は別経路で得なければならない。

これは登録の欠陥ではなく、役割分担である。汎用のメディアタイプ登録が、あらゆる企業やプロジェクトのスキーマ統治まで引き受けるべきではない。ローカルな責任は、その限定された役割を誇張しないことにある。

version=1 にスキーマ版を読み込んではならない

encoding パラメーターは、二つの表現を整合させる。application/protobuf の既定値は binary、application/protobuf+json は json で、後者には charset=utf-8 が必須である。サブタイプと反対の値はエラーにしなければならない。

もう一つの任意パラメーター version の既定値は 1 だ。ただし RFC が指すのはワイヤー符号化仕様の版であり、スキーマ言語の版ではない。現在の Protobuf ワイヤー符号化にこのパラメーターで区別する複数版はなく、将来拡張のために用意されている。

Proto2、Proto3、Edition 2023、Edition 2024 は IDL の進化である。互換なワイヤー表現を共有できても、意味上の差は残る。RFC は未知の enum 値の扱いを例に挙げる。ある世代で無効とされた値が、別の世代では未知値として保持される。

したがって version=1 を「schema v1」や「Edition 2024」と表示する運用は、証拠を増やすのではなく別の概念を上書きしている。パッケージ名、メッセージ型、.proto の内容、改訂、承認者、ダイジェストは一つも示されない。

ワイヤー互換性は依存の承認ではない

Proto3 言語ガイド は、ある定義で符号化したフィールドを別定義で復号したことを、簡素なワイヤー形式そのものは検出できないと説明する。フィールド番号の再利用は、パース障害だけでなく、個人情報の漏えいやデータ破損につながり得る。

Protobuf の互換性規則は有用だ。削除した番号を予約し、バイナリ経路で未知フィールドを保持し、安全な型変更を限定すれば、分散システムを段階的に更新できる。だが、その規則は「誰が変更してよいか」「どの例外を誰が承認したか」「どの利用者が影響を受けるか」を決めない。

JSON では別の境界も現れる。ProtoJSON 仕様 は、バイナリよりスキーマ進化の保証が弱いとする。未知フィールドを扱えず、フィールド名と enum 名がワイヤーに現れる。バイナリから JSON への変換で未知フィールドが失われることもある。

正しい application/protobuf+json であることは、変換前の全情報を保っている証明にならない。どこで変換したか、どのスキーマを参照したか、何を無視したかを別に残す必要がある。

IANA の権限は名称の調整にある

IANA メディアタイプ登録簿 は、公開トークン、パラメーター、参照仕様、用途、変更管理者を維持する。RFC 9996 は application/x-protobuf、application/x-protobuffer、application/x-protobuf+json を非推奨の別名とした。

正式名称は、コンテントネゴシエーション、API 記述、フィルタリング、Web セキュリティを改善する。+json は一般処理系にも JSON 由来であることを伝える。バイナリと JSON の異なる規則が同じ曖昧な名に隠れなくなる。

同時に、登録項目にはスキーマ ID、ダイジェスト、メッセージ型、作成者、署名、利用承認がない。バイナリ型には magic number もファイル拡張子もない。IETF が変更管理者であっても、各 HTTP ボディーを IETF が発行したことにはならない。

IANA が答えるのは「この表現を何と呼ぶか」である。「誰がこのバイト列を作ったか」「どの定義で読むか」「行動してよいか」ではない。後者まで登録簿に帰属させると、公開名称の信頼を、審査されていない個別業務へ貸し出すことになる。

セキュリティ機構も守備範囲を持つ

RFC 9996 は Protobuf 自体がセキュリティ、プライバシー、完全性、圧縮を提供しないと述べる。TLS は通信路を守れるが、アプリケーションが期待するスキーマのダイジェストを伝えない。メモリー上限は悪意ある入力のコストを抑えても、正しく構成されたフィールドの誤解釈を防がない。

Web ではコンテンツスニッフィングを防ぎ、ProtoJSON に +json と UTF-8 を正しく指定する必要がある。これによりブラウザーの扱いは改善するが、スキーマの出所は証明されない。バイト列への署名が有効でも、受信者が署名者と同じ定義を使ったとは限らない。

Any の type URL も万能ではない。スキーマ取得用に参照できる構想だったが、RFC 9996 は広く使われる実装がその参照解決をサポートしていないと記す。ローカル契約の選択子にはなっても、普遍的な発見・認証基盤ではない。

本当の決定はパーサーの外で行われる

各サービスには、どこかに正本がある。ソースリポジトリ、パッケージ登録簿、API カタログ、ビルドルール、非公開スキーマサービス、デプロイマニフェストなどだ。所有者が変更を提案し、互換性を審査し、リリース権者が成果物を承認し、運用者が配備する。

RFC 9996 が一つの仕組みを強制しないのは適切である。問題は組織側が選択を記録しない場合だ。コンテナに入っていた定義が事実上の契約になり、ライブラリ更新が意味を変えても、業務責任者は意思決定に参加できない。

損失を負う主体と、意味を選ぶ代理人がずれる。これはデータ処理に隠れたエージェンシー問題である。メディアタイプ、パース成功、通信相手の認証、スキーマ承認は、それぞれ異なる事実として扱わなければならない。

スキーマ文脈受領証を残す

秘密の .proto を公開ヘッダーに載せる必要はない。世界共通のスキーマ統制機関も不要だ。Daniel Kade が提案するのは、復号結果に依存する地点で残す小さなスキーマ文脈受領証である。

最初に、受信したメディアタイプと評価した全パラメーターを記録する。次に、メッセージ型を何で選んだかを書く。API endpoint、RPC メソッド、queue topic、Any URL、ローカル規約などを明示し、Content-Type が選んだように見せない。

三番目に、スキーマパッケージ、言語世代または Edition、改訂、改変不能なダイジェストを結ぶ。秘密スキーマなら内容を公開せず、管理された参照とダイジェストだけを監査面に出せる。

四番目は配布元とリリース権限だ。リポジトリまたは namespace、責任者、リリース事象、署名・完全性、失効や後継を記録する。既知の URL と現在の支配権は別である。

五番目に互換性判断を保存する。旧新のダイジェスト、規則とツール、破壊的変更、例外、承認者、影響範囲を含める。六番目はデコーダーの実装版、未知フィールド、enum、UTF-8、資源上限と解釈を変えるオプションだ。

七番目にバイナリ・JSON 変換、フィールド単位コピー、正規化、秘匿化、再シリアライズと既知の損失を書く。可能なら入力と出力のダイジェストを結ぶ。八番目に TLS や署名の検証を、スキーマ同一性と分けて置く。

最後に、採用、隔離、拒否、ロールバック、置換のどれか、責任者、適用範囲、理由、訂正先を残す。メッセージ本文は保存しなくてよい。

これは Daniel Kade の編集上の提案であり、RFC、IANA、Protobuf プロジェクトの要件ではない。メディアタイプの価値を損なわず、その外にある権限を外にあるまま検証可能にする。

証拠の限界

確認した資料は登録内容、規定動作、文書化された互換性リスクを示す。新タイプの導入率、具体的事故、特定サービスの欠陥、最適なスキーマ登録方式は示さない。

RFC 9996 は Standards Track ではなく Informational である。本稿は Protobuf に進化機構がないとも、JSON が常に危険とも、type URL が無価値とも、非公開スキーマを公開すべきとも主張しない。

主張は限定的だ。メディアタイプの妥当性、ワイヤー互換性、スキーマ権限は別の証拠である。足りない結合を、パース成功から推定してはならない。

情報源