要約

  • draft-feng-netmod-naim-01ではCanonical JSONが権威ある記録であり、Markdown Viewは人間向けの再生成可能な表示、LLM Context Viewは意図的に情報を省くAI向け入力である。
  • JSON Schema適合、往復変換、再試行成功、YANGバリデータ合格は、それぞれ特定の入力とツールに関する証拠にすぎない。要求の完全性、WG採用、サーバ実装、操作認可、設定反映、ネットワーク結果を単独では証明しない。

たとえば「主経路が使えない場合だけ予備経路を有効にする」という要求を考える。対話でkeyとwritableを補い、NAIM文書を生成し、エラー報告を一度受けて修正し、YANGが検証を通ったとする。それでも「使えない」の判定主体、復旧時の遷移、規制対象通信の扱いが質問されていなければ、緑色の結果はその空白を埋めない。

NAIM revision 01はNatural AI Interface Modelingを、自然言語の要求とYANGの間に置く意味的中間表現として定義しようとする。直接変換では、configurationとstate、list key、制約式、運用上の前提条件、モジュール間関係が欠落または混同されやすいという問題設定だ。

文書の地位も境界の一部である。Datatrackerでは、Chong Fengによる2026年7月18日更新のactive individual Internet-Draftで、streamなし、intended RFC statusなし、状態はI-D Existsである。草案のヘッダーにはIntended status: Standards Trackとあるが、これは著者が示す行き先であって、NETMOD WGの採用、IETFの承認、RFC化を意味しない。履歴が示すのは改訂の経過であり、実装実績ではない。

正本と二つの派生物

提案ではCanonical JSONだけがNAIM文書内容の規範的な源になる。Markdown Viewはレビュー、版管理、議論のために決定論的に生成される。Markdownを編集入力として受け入れる場合、そこに表現されたフィールドは意味を保って往復し、JSONにだけ存在する値は黙って失われてはならない。衝突は明示的に解決する必要がある。

したがって「往復成功」という一語では証拠が足りない。JSONの正確なバイト列とschema版、変換器の識別子、入出力hash、表示されなかったフィールド、衝突ごとの決定を残すべきだ。往復テストが証明するのは、その変換器が表現対象にした面の保存であって、最初の要求の正しさではない。

LLM Context Viewは別の目的を持つ。名前、意味型、必須性、制約、書込み可否、可視条件、操作、前提条件、副作用を含める一方、NETCONF/RESTCONF要求の組立て、内部metadata、生のJSON Schema、deviation宣言、extension定義を省く。token効率のための非権威的なビューで、Canonical JSONの再構築には使えない。

省略が明記されていることは長所だが、省略が常に無害という意味ではない。対象サーバのdeviationや外部augmentが有効schemaを変える場合、AIは与えられた文脈に忠実でも現場には不適切になり得る。タスクごとに、何を省き、なぜ後段で問題にならないかを記録する必要がある。

Specification、Skill、Toolの責任

Specification層は形式、JSON Schema、ビュー生成規則を定める。Skill層は対話モデリング、要約、YANG生成、逆解析というAI処理を担う。Tool層は従来型の決定論的ソフトウェアで、構造検証、変換、context生成、確認済み文書からのYANG生成を行う。形式を安定させつつSkillを交換できる点は、特定モデルへの固定を弱める。

Validation-Reflection-Retryでは、Toolがpathと期待条件を含む構造化エラーを返し、それをSkillのcontextへ注入して再試行できる。回数には上限があり、残る問題は利用者への具体的な質問に変え、履歴を保存すべきとされる。

ただし再試行の成功は、新しい出力が同じ検査を通ったことしか示さない。難しいoptional fieldを削ったり、もっともらしいkeyを選んだり、解決できない条件をdescriptionに移した可能性がある。初期要求、質問、仮定、default、削除、各診断、Skill・Tool・schemaの版を一緒に残して初めて、成功の範囲を判断できる。

YANG生成後も同じである。RFC 7950はmust、when、leafref、augment、feature、instance制約を規定する。完全なmodule closure、feature、deviation、正負のinstance testを与えればvalidatorは強い証拠を作れる。しかし自然言語の条件が意図したXPathになったか、対象サーバがaugmentを実装するか、actorが認可されているかは判断できない。RFC 8407は設計指針であり、生成物の採用証明ではない。

RFC 8525のYANG Libraryはserverが宣言するmodule set、feature、deviationを示す。それをsource bytes、clientの解決trace、有効schema fingerprintと結ぶ必要がある。RFC 8342はintendedとoperational stateを分ける。設定受付は、装置適用やネットワーク効果と同義ではない。RFC 8259に適合するJSONも、記述対象の真実性までは保証しない。

NAIM自身も、YANGのJSON encodingでも代替でもないと述べる。runtime operation intentは別のNAIM-OP draftに委ねられ、revision 01はAI model、prompt、confidence score、runtime executionを規定しない。

本番で必要なのは、要求と未解決仮定、Canonical JSON、二つのviewと省略ledger、YANGと完全closure、server宣言とclient解決、認可、最後にintended／operational観測、telemetry、rollbackという累積証拠である。

Lu Hengの最小の決定論的共通層という考えは、共通形式の価値と限界を読む助けになる。Running-Code Primacyとreality layersも、文書と実行結果を分けるBTWの分析軸である。Lu HengがNAIMを評価したという主張ではない。

出典