変更要約: 初版
3.3デバイスAPIとモデル駆動プログラマビリティ
IOS XE/NX-OSのオンボックスAPI、そしてモデル駆動の三本柱——YANG（データモデル定義）・NETCONF（XML/SSH・データストア）・RESTCONF（HTTP+JSON/XML・CRUD↔HTTPメソッド）——の役割分担を、応答の解釈と手法選択として学びます。あわせてDevNetの学習/検証リソース（Sandbox・Code Exchange・Learning Labs・API docs）を押さえます。
従来のネットワーク運用はCLIにshow/configureを打ち込む人手作業でしたが、モデル駆動プログラマビリティは機器の設定/状態を構造化データとして読み書きする世界です。ここで混乱しやすいのが、YANG・NETCONF・RESTCONFの三者の関係。役割が違うのに「どれもモデル駆動」で一括りにすると、応答の読み方も手法の選択も誤ります。この節では三者を「モデル（YANG）」「XML/SSHのプロトコル（NETCONF）」「HTTPのプロトコル（RESTCONF）」として整理し、加えて実機なしで試せるDevNetリソースを押さえます。
3.3.1デバイス上のAPI（IOS XE / NX-OS）
- IOS XEは
netconf-yang/restconfを有効化すると、機器自身がNETCONF（TCP830）やRESTCONF（HTTPS443）のエンドポイントを提供し、外部スクリプトからモデル駆動で設定/状態を扱える。CLIに依存しないプログラマブルな入口が機器に開く。 - NX-OS（Nexus）も同様にNETCONF/RESTCONFに対応し、加えてスイッチ上でPython/Bashを直接動かすオンボックス自動化やNX-APIを持つ。要点は「近年のCisco機器は設定を構造化データとして読み書きできる」ことで、手打ちCLIのスクレイピングに頼らずに済む。
3.3.2モデル駆動の三本柱：YANG / NETCONF / RESTCONF
- YANG＝データモデルを定義する言語。設定/状態の階層構造を
container/list/leafで表す（例：インタフェースのlistの中にnameやenabledというleaf）。YANG自体はプロトコルではなく、何を（どんな構造のデータを）扱うかの型定義であり、NETCONF/RESTCONFの両方が同じYANGモデルを共有する。 - NETCONF＝XMLをやり取りするプロトコルでSSH（TCP830）上に動く。データストアの概念を持ち、
candidate（編集用の下書き）へ変更を適用してcommitでrunningへ反映できるため、トランザクション的な設定変更（途中失敗のロールバック）に向く。操作は<get>/<edit-config>等。 - RESTCONF＝HTTP(S)上でRESTの流儀に沿い、JSONまたはXMLを扱う。CRUD操作がHTTPメソッドに対応する（取得=GET／作成=POST／置換=PUT／部分更新=PATCH／削除=DELETE）。URLでYANGのリソース階層を表し、
curlやブラウザ、requestsから扱いやすい。単一リソースの手軽なCRUDに向き、複雑なトランザクションはNETCONFが得意。
3.3.3DevNetの学習・検証リソース
- DevNet Sandbox＝実機を持たなくても、Meraki/Catalyst Center/IOS XE等の無料の検証環境にAPIで接続して試せる。学習やPoC、スクリプトの動作確認に使う（本番に触れずに安全に練習できるのが利点）。
- Code Exchange（再利用可能なサンプル/リポジトリのカタログ）・Learning Labs（手を動かすチュートリアル）・API docs（各プラットフォームのリファレンス）・フォーラムが揃う。要件に対し「まずSandboxで試し、Code Exchangeの雛形を流用し、docsでエンドポイントを確認する」という進め方が現実的。
「YANG＝モデル（型・container/list/leaf）」「NETCONF＝XML/SSH(830)・candidate/runningデータストア・トランザクション」「RESTCONF＝HTTP+JSON/XML・CRUD↔GET/POST/PUT/PATCH/DELETE」の役割分担が頻出です。DevNetはSandbox（無料検証環境）・Code Exchange・Learning Labs・API docsを区別しましょう。
あなたはIOS XEルータ群の運用を自動化する担当で、2つのタスクを受けました。「(1)あるルータの特定インタフェースの説明(description)だけをスクリプトから素早く1つ更新、(2)複数のルーティング/ACL設定を1回の変更として一括投入し、途中で1つでも失敗したら全部やめて元に戻す」。まず前提として、対象ルータでnetconf-yangとrestconfが有効か、ip http secure-serverが入っているかを確認します。(1)は単一リソースの手軽なCRUDなので、RESTCONFが向きます。PATCH /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet2 に{"ietf-interfaces:interface": {"description": "..."}}のJSONを送れば部分更新でき、curlやrequestsから数行で済みます（丸ごと置換したいならPUT、取得だけならGET）。ここで全体をPUTしてしまうと、送らなかったフィールドが消えるリスクがあるので、部分更新はPATCHという判断が肝です。一方(2)はトランザクション的な一括変更＋失敗時ロールバックが要件で、これはRESTCONFの単発CRUDでは担保しにくく、NETCONFのデータストアが正解です。変更をcandidateデータストアに<edit-config>で積み、問題なければcommitでrunningへ反映、途中で失敗すればcandidateを破棄してrunningは無傷、という原子性が使えます。実機がまだ手元に無い段階では、いきなり本番に打たずDevNet SandboxのIOS XE環境で応答を確かめ、Code Exchangeの雛形を流用してから本番へ——という進め方が安全です。つまり判断の軸は「単発の手軽なCRUDならRESTCONF(+適切なHTTPメソッド)／原子性の要る一括変更ならNETCONF(candidate→commit)」であり、モデル(YANG)は両者が共有する共通の型として効いています。
| 観点 | NETCONF | RESTCONF |
|---|---|---|
| トランスポート | SSH（TCP830） | HTTP(S)（443） |
| データ形式 | XML | JSON または XML |
| 操作 | <get>/<edit-config> 等 | GET/POST/PUT/PATCH/DELETE |
| データストア | candidate/running 等（トランザクション向き） | 直接running（単発CRUD向き） |
| モデル | YANG（共有） | YANG（共有） |
ひっかけ： 「RESTCONFで単一フィールドだけ変えるにもPUTを使う」は要注意です——PUTはリソースの置換なので送らなかったフィールドが失われ得ます。部分更新はPATCHが適切です。また「YANGはNETCONF専用のプロトコル」も誤り＝YANGはプロトコルではなくデータモデル定義で、NETCONFとRESTCONFの両方が同じYANGモデルを共有します。
3.3.4この節のまとめ
- IOS XE/NX-OSは
netconf-yang/restconfで機器自身がプログラマブルな入口を開き、設定/状態を構造化データとして扱える - YANGは共有モデル（型）、NETCONFはXML/SSH・データストアでトランザクション、RESTCONFはHTTP+JSON/XMLでCRUD↔HTTPメソッド（部分更新は
PATCH） - DevNetのSandbox（無料検証環境）・Code Exchange・Learning Labs・API docsで、本番に触れず安全に試して雛形を流用する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. IOS XEルータの1つのインタフェースの説明(description)だけをスクリプトから素早く更新したい。既存の他フィールドは消したくない。RESTCONFでの操作として最も適切なものはどれか。
Q2. 複数のルーティングとACLの変更を1回の作業として適用し、途中で1つでも失敗したらすべて取りやめて変更前の状態に戻したい。この要件（原子性・ロールバック）に最も適した手法はどれか。
Q3. 実機を持たないチームメンバーが、Catalyst CenterのIntent APIを呼ぶスクリプトを本番に触れずに練習・検証したいと言っている。最も適切に案内できるDevNetリソースはどれか。