5.4応答とモデルの解釈

モデル駆動の自動化では、機器とやり取りするのは人間向けのshow出力ではなく、構造化された応答（JSON/XML）とそれを規定するモデル（YANG）です。自動化が「うまくいったのか」を判断するには、応答の形から成否を読み、モデルのどこが何を表すかを掴み、変更差分が結局何を変えるかを読めなければなりません。この節では、暗記でなく提示された応答・モデル・差分の解釈として、この読解力を鍛えます。

5.4.1RESTCONF/NETCONF応答を読む

• RESTCONFはHTTP上でCRUDをHTTPメソッドに対応させる（GET=取得/POST=作成/PUT=置換/PATCH=部分更新/DELETE=削除）。応答はHTTPステータス＋JSON/XML bodyで、200 OKや201 Createdは成功、204 No Contentは本文なしの成功、401は未認証、404はパス（データ）不在、409は競合。ステータスとbodyの両方で成否を読む。
• NETCONFはSSH(通常830番)上でXMLをやり取りし、成功は<rpc-reply> 内の <ok/>、失敗は<rpc-error>（<error-tag>に原因）で表す。設定はcandidate（編集用）→ commit → running（稼働中）のデータストア分離があり、<edit-config>後の<commit>で確定する。「応答が<ok/>か<rpc-error>か」で成否を判断する。
• JSON応答のキー名は名前空間付きで読む：例 "ietf-interfaces:interface": [{ "name": "GigabitEthernet2", "enabled": true }] は「ietf-interfacesモデルのinterfaceリストに、名前GigabitEthernet2・有効なエントリがある」と読める。どのモデルの・どの要素が・どんな値かを落ち着いて対応付ける。

5.4.2YANGモデルの階層を読む

• YANGは機器設定/状態のデータモデル（構造の定義）を記述する言語。主な構成要素は、値を1つ持つleaf、同種leafの並びleaf-list、複数要素をまとめるcontainer、キーで識別される繰り返しエントリのlist（例：多数のinterface）。XML/JSONの実データは、このYANG階層のインスタンスにあたる。
• モデルを読むコツは「これは単一か複数か」「キーは何か」を見ること：list interface { key "name"; leaf enabled { type boolean; } }なら「interfaceは名前をキーに複数持て、各要素はboolean型のenabledを1つ持つ」と分かる。この構造が、応答JSONで[...]（配列＝list）やtrue/false（boolean leaf）として現れる。

5.4.3unified diffを読む

• unified diffは変更前後の差分表現。冒頭の--- 旧 / +++ 新でどのファイルの新旧か、@@ -a,b +c,d @@のハンクヘッダで「旧はa行目からb行、新はc行目からd行」という位置を示す。行頭記号が肝：-＝削除された行、+＝追加された行、（空白）＝文脈（変更なし）。
• diffは正味の変更を読む：- ip address 10.0.0.1 255.255.255.0 と + ip address 10.0.0.2 255.255.255.0 が並べば「IPを.1から.2へ変更」。+だけなら追加、-だけなら削除。Gitのコードレビューやplaybook差分で、この変更が意図どおりか・危険な削除が混じっていないかを読み取る。

あなたは自動化ジョブの失敗を調査しています。ジョブはRESTCONFでインタフェースを有効化するはずでしたが、下流の検証が「IFがdownのまま」と報告しました。まずRESTCONF応答を見ると、PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2 に対し HTTP/1.1 204 No Content が返っています。ここで「本文が空だから失敗だ」と早合点するのは誤りです——204は「本文なしの成功」で、更新自体は受理されています。では原因はどこか。送信した差分（unified diff）を確認すると、意図は「enabledをtrueにする」だったのに、実際のペイロードは次のようになっていました：- "enabled": true と + "enabled": false。つまり正味の変更は「有効→無効」で、trueとfalseを取り違えた内容の誤りです。応答（204）は成功、しかし送った中身が間違っていた——だからIFはdownのまま、というのが正しい切り分けです。ここでYANGの知識が効きます：ietf-interfacesモデルではlist interface { key "name"; leaf enabled { type boolean; } } なので、enabledはboolean型のleafであり、"true"（文字列）でも1でもなくtrue（真偽値）を入れるべきだと分かります。もしこれがNETCONFなら、成否は204のようなHTTPステータスではなく応答XMLの<ok/>か<rpc-error>で読み、<edit-config>後に<commit>でcandidateからrunningへ確定したかまで確認します。この一連の判断——応答の形（204=成功）で通信の成否を、diff（true→false）で内容の誤りを、YANG（boolean leaf）で値の型を——を分けて読めることが、モデル駆動の障害対応の核心です。

5.4.4この節のまとめ

• RESTCONFはHTTPメソッド↔CRUDで、成否はステータス＋body（201作成/204本文なし成功/401未認証/404不在）。NETCONFは<ok/>成功/<rpc-error>失敗で、candidate→commit→running
• YANGはcontainer/list(key)/leaf/leaf-listの構造・型の定義で、応答JSON/XMLはそのインスタンス。boolean leafには真偽値を入れる
• unified diffは@@ハンクで位置、-削除/+追加/空白は文脈で正味の変更を読む。応答の成否・差分の内容・モデルの型を分けて切り分ける