変更要約: 初版
3.1Cisco SDKとネットワーク管理API
SDK（言語別ライブラリ）が生のREST呼び出しをどう抽象化するか、そして主要なネットワーク管理プラットフォーム——Meraki（Dashboard API）・Catalyst Center（Intent API）・ACI（APIC）・Catalyst SD-WAN・Cisco NSO——の守備範囲を、「この要件にはどのプラットフォームのAPIを選ぶか」という判断として学びます。
Ciscoは製品ごとに管理APIを公開していますが、試験で問われるのは「各APIの仕様を暗記しているか」ではなく、目の前の自動化要件に対してどのプラットフォームのAPIを呼べば解けるかという判断です。同じ「デバイス一覧を取る」でも、クラウド管理のMerakiと、企業アクセス網を統制するCatalyst Center、データセンタSDNのACIでは呼ぶ相手が違います。この節ではまず、生のrequestsを書く代わりに使えるSDKの意味を押さえ、次に主要プラットフォームの守備範囲を「どの課題に効くか」で並べます。
3.1.1SDKとは何を肩代わりするか
- SDK（ソフトウェア開発キット）＝あるAPIを特定言語から扱いやすくするライブラリ群。生の
requests.get(url, headers=...)で自分がURL・認証ヘッダ・ページネーション・エラー処理を書く代わりに、dashboard.organizations.getOrganizationDevices(org_id)のようなメソッド呼び出しで同じ結果を得られる。CiscoはMeraki(meshtasticではなく公式meraki)やWebex等でPython SDKを提供する。 - SDKの利点は抽象化と一貫性——認証やページ送りの定型処理を隠し、戻り値をその言語のデータ構造（Pythonなら
dict/list）で返す。ただし裏側は結局同じREST APIなので、SDKが未対応の新機能や細かな制御が要る場面では生のREST/RESTCONFに降りる判断も要る。SDKは万能ではなく「定型を速く安全に書く」ための道具と捉える。
3.1.2主要な管理プラットフォームの守備範囲
- Meraki＝クラウド管理型。ネットワーク機器（MX/MR/MS等）をクラウドのダッシュボードから集中管理し、Dashboard API（REST・APIキー認証）で組織/ネットワーク/デバイス/クライアントを操作する。拠点が多くクラウドで一元管理したい要件に強い。
- Catalyst Center（旧DNA Center）＝オンプレのコントローラで企業アクセス網（有線/無線）を統制する。Intent APIで「意図」ベースの操作（デバイス一覧・トポロジ・ポリシー・アシュアランス）を提供。ACIはデータセンタ向けSDNで、コントローラAPICがファブリックを宣言的に管理する。
- Catalyst SD-WAN（旧Viptela）＝WANをオーバーレイで束ね、コントローラ（vManage）のREST APIでポリシー/テンプレートを制御する。Cisco NSOはマルチベンダのサービスオーケストレーション基盤で、YANGサービスモデルとNETCONF/CLIで多様な機器へ設定を展開する（Cisco以外も含む横断自動化）。
「Meraki＝クラウド管理・Dashboard API」「Catalyst Center＝オンプレ・Intent API（旧DNA Center）」「ACI＝データセンタSDN・APIC」「Catalyst SD-WAN＝旧Viptela・vManage」「NSO＝マルチベンダのオーケストレーション」の対応が頻出です。「どの範囲（クラウド/アクセス網/DC/WAN/横断）を管理するか」でプラットフォームを引けるようにしましょう。
あなたは全国200拠点を持つ小売チェーンの運用自動化を任されています。要件は「(1)各店舗のクラウド管理ネットワークからオンライン状態のデバイス一覧を毎朝取得、(2)本社データセンタのアプリ用テナント（EPG）をコード化して展開、(3)新規に加わった非Cisco機器も含むWAN拠点へ標準サービス設定を一括投入」の3つです。ここで「Ciscoの自動化だから全部Catalyst CenterのIntent APIで」とまとめて考えるのは誤りで、各要件が指す管理ドメインが違う点を見抜く必要があります。(1)は店舗機器をクラウドで束ねている以上、MerakiのDashboard API（organizations 配下の getOrganizationDevicesStatuses 等）を叩くのが素直で、店舗ごとにコントローラを置く発想は過剰です。(2)はデータセンタSDNの話なので、テナント/EPGを宣言的に扱うACIのAPICへ向けます——ここでMerakiのDashboard APIを探しても対象がありません。(3)はマルチベンダかつサービス単位の一括展開が肝で、YANGサービスモデルで異機種へ配信できるCisco NSOが最適です（単一機器へのCLI流し込みでは非Cisco混在と標準化に耐えません）。もし企業の有線/無線アクセス網のアシュアランスやトポロジを取りたい要件が加われば、そのときこそCatalyst CenterのIntent APIの出番です。要点は、プラットフォーム選定が「新しいから」「有名だから」ではなく、管理対象のドメイン（クラウド/DC/WAN/アクセス網/横断）に一致するAPIを選ぶ判断だという点です。
| プラットフォーム | 管理ドメイン | API/コントローラ | 選定のヒント |
|---|---|---|---|
| Meraki | クラウド管理ネットワーク | Dashboard API（REST・APIキー） | 多拠点をクラウドで一元管理 |
| Catalyst Center | 企業アクセス網（有線/無線） | Intent API（オンプレ・旧DNA Center） | 意図ベースの制御/アシュアランス |
| ACI | データセンタSDN | APIC | テナント/EPGの宣言的管理 |
| Catalyst SD-WAN | WANオーバーレイ（旧Viptela） | vManage REST API | WANポリシー/テンプレート制御 |
| Cisco NSO | マルチベンダ横断 | YANGサービスモデル＋NETCONF/CLI | 異機種へサービス単位で一括展開 |
ひっかけ： 「SDKを使えばRESTとは別の独自プロトコルで通信するので速い」は誤りです——SDKは裏で同じREST APIを呼ぶラッパーであり、抽象化と定型処理の肩代わりが価値です。また「Cisco機器の自動化はすべてCatalyst Centerで賄える」も誤り＝クラウド管理はMeraki、DC SDNはACI/APIC、マルチベンダ横断はNSOと、管理ドメインごとに対象APIが異なります。
3.1.3この節のまとめ
- SDKは生のRESTを言語ネイティブなメソッドに抽象化する道具。裏は同じREST APIで、未対応機能や細かい制御では生のREST/RESTCONFに降りる
- Meraki＝クラウド/Dashboard API、Catalyst Center＝アクセス網/Intent API、ACI＝DC SDN/APIC、Catalyst SD-WAN＝WAN/vManage、NSO＝マルチベンダ横断
- プラットフォーム選定は管理対象ドメインに一致するAPIを選ぶ判断であり、「有名だから」で1つに寄せない
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 全国200拠点をクラウド管理型ネットワークで運用しており、毎朝すべての拠点のデバイスのオンライン状態を一括取得して監視ダッシュボードに反映したい。呼び出すべきAPIとして最も適切なものはどれか。
Q2. チームメンバーが「Cisco NSOはCisco機器専用だから、混在環境ではベンダごとに別々のツールを併用するしかない」と述べた。この理解に対する最も適切な指摘はどれか。
Q3. データセンタのSDNファブリックに、新しいアプリ用のテナントとエンドポイントグループ（EPG）を宣言的に定義して展開したい。操作対象として最も適切なコントローラ/APIはどれか。