要約

  • RFC 9682 は、ファイル内に規則が一つもない構文を認める一方、指令の処理後には入口となる規則が存在するという条件を残している。
  • 模型のように部品を組み合わせる仕組みでは、部品だけの検査結果は完成品の検収にならない。選んだ依存先、ルート、生成されたモデルを特定する必要がある。

検収資料として一つのファイルが届いたとする。「規則は最低一つ」という従来の確認項目で調べると不合格になる。ところが提出側は、規則は別のモジュールから取り込むので、このファイルにはなくてよいと言う。

ここで問うべきなのは、どちらが厳格かではない。何を、どの段階で検査しているのかである。まだ部品であるものに完成品の条件を当てはめれば、正当な構成を拒む。部品の検査を緩めたことを完成品の承認と取り違えれば、必要な確認が消える。

これは架空の検収場面だが、技術的な根拠は具体的だ。CDDL は CBOR や JSON のデータ構造を記述するための言語で、その文法更新には「条件をなくさず、適用する場所を変える」という判断が含まれている。

ゼロを認める相手はファイルである

文法を記述する ABNF では、繰り返し回数の下限を省くとゼロを含み、下限を一にすれば最低一回が必要になる。この小さな表記差が、解析器が受け取れる入力を変える。RFC 5234 第 3.6 節

2024 年 11 月の RFC 9682 は、CDDL ファイル内の規則数をゼロ以上にした。モジュール指令によって規則がすべて供給される場合があるためだ。ただし第 3.1 節は、指令をすべて処理した後には入口を与える規則が必要だとする。付録 B.2 にも、修飾されたバイト文字列の内容を外側の構文処理後に扱う段階的な設計がある。RFC 9682

空の入力ファイルと、完成しているのに入口のないモデルは同じではない。前者を認めるために後者まで使えると説明するのは誤りだ。また、警告を消すためだけに無関係な規則を加えると、意図された入口があるかという本来の問いから遠ざかる。

基礎的な CDDL では最初に定義した規則がルートとなり、それはグループではなく型でなければならない。名前を必ず start にするという意味ではない。アプリケーションがどこまでデータを検査するかは別の設計判断であり、言語のこの条件と混同できない。RFC 8610 第 2.2.4、4.2、5 節

この区別から、受け入れ判定は二つの誤りを避ける必要がある。部品に不要な入口を強制しないこと。そして、完成したモデルの入口が用途に合っているかを見落とさないことだ。規則の個数だけでは、その両方を確かめられない。

ファイルの外側にも選択がある

2026 年 9 月 7 日に確認したモジュール構造の提案は、同月 2 日付の draft-ietf-cbor-cddl-modules-07 である。作業中の Internet-Draft であり、成立した RFC ではない。RFC 9682 が参照した草案とも版が異なる。

この草案では、指令を基礎的なツールにはコメントとして読める形で記す。互換性を意識した方法だが、指令に依存する入力をどのツールでも同じモデルにできるという保証ではない。さらに、参照元のディレクトリや優先順位の一般的な決め方は文脈に委ねている。ある実装例は現在のディレクトリから探し、次に内蔵の集合を使う。CDDL Module Structure、第 07 版

したがって、トップレベルのファイルが同じであることだけでは、同じ対象を検査した証拠にならない。同名の依存先がどこで見つかったか、どの版を採ったかが結果に関わる。草案の別の例では、コマンドラインからルートを選び、入力ファイルなしで先頭規則を合成している。ここでも選択は添付ファイルの中だけには収まらない。

これらは文書上の例であり、本稿が実装を動かして確認した結果ではない。それでも、検収の単位を考える材料にはなる。提出物を構成する情報の一部が環境にあるなら、環境を特定せずに提出物だけを保存しても、後日の再現には足りない。

再現できる承認にする

推奨したいのは、個々のファイルの成功表示を増やすことではなく、完成したモデルの生成条件を残すことだ。参照した内容、探索設定、処理器、選択したルート、最終出力を結び付ければ、別の担当者も判断の対象を確かめられる。これは編集上の運用提案であり、RFC が要求する新たな帳票ではない。

名前空間を分ければ名前の衝突を管理しやすい。しかし、それだけで参照した内容の出所が確かになるわけではない。信頼できる出所を使っていても、選んだルートが目的に合うとは限らない。互いに異なる問いを、一つの「検証済み」に押し込めない方がよい。

失われやすいのは異常そのものより、その時点で何を受け入れたかの説明だ。担当者が替わり、内蔵の規則集が更新され、ローカルのファイルが整理された後で同じ状態を再建するのは難しい。成功時にも組み立て条件を残す理由は、そこにある。

本稿は特定事業者の障害や攻撃を報じるものではなく、導入率も算出していない。技術文書から確認できるのは条件の移動と設計上の注意点だ。そこから導く実務上の結論は、検査の移動先で同じ条件を確実に引き受ける、という限定されたものである。