変更要約: 初版
5.2テスト・CI/CDと自動化ツール
ネットワーク変更を安全に流すためのCI/CDパイプライン（lint→テスト→デプロイ）、仮想環境で試すCisco Modeling Labs（CML）と状態を検証するpyATS、そしてAnsible（エージェントレス・冪等）・Terraform（宣言的・状態管理）・Cisco NSO（マルチベンダ・サービスモデル）の得意分野を、「このパイプライン段は何を守っているか」「この要件にはどのツールか」という判断として学びます。
自動化は「間違った設定を、より速く・より広く配る」危険も併せ持ちます。だからこそ、変更を本番へ届ける前に機械的に検証する仕組み（テストとパイプライン）が要ります。この節では、ネットワーク変更を安全に運ぶCI/CDの各段が何を守っているのか、仮想環境CMLとテストフレームワークpyATSの役割、そしてAnsible・Terraform・NSOをそれぞれ「何が得意か」で選ぶ判断を、道具比較の暗記でなく要件との突き合わせとして整理します。
5.2.1CI/CDパイプラインの段
- CI（継続的インテグレーション）＝変更をコミット/Pull Requestするたびに自動でビルド・検査・テストを走らせ、壊れた変更を早期に弾く仕組み。ネットワークでは、まず
yamllint等のlint（構文/書式検査）で「そもそも文法が正しいか」を機械確認する段が入る。ここで落ちれば本番に届く前に止まる。 - CD（継続的デリバリ/デプロイ）＝テストを通過した変更を自動で（あるいは承認後に）本番へ配布する段。典型的な順序は
lint → 仮想環境でテスト → 承認 → 本番デプロイ → 事後検証。各段は「前段を通ったものだけ次へ」進むゲートであり、どこで落ちたかが原因の切り分けになる。
5.2.2テストの道具：CMLとpyATS
- Cisco Modeling Labs（CML）＝実機さながらの仮想ネットワークをシミュレートする環境。パイプラインの「テスト段」で、本番と同じトポロジをCML上に作り、変更を本番の前に安全に試す（サンドボックス）。物理機材を用意せずに検証でき、壊しても本番に影響しない。
- pyATS（+Genie）＝Cisco製のネットワークテスト自動化フレームワーク。機器の
show出力を構造化データにパースし、「BGPネイバがEstablishedか」「インタフェースがupか」といった期待状態を機械的に検証（アサーション）する。変更前後の状態を比較して回帰（想定外の劣化）を検出するのに使う。
5.2.3構成/オーケストレーションの道具
- Ansible＝エージェントレス（対象に常駐ソフト不要・主にSSH/API）で、YAMLのplaybookに「望む状態」を書いてpush型で適用する構成管理ツール。多くのモジュールが冪等に作られ、ネットワーク機器（
ios_config等）の設定・取得に広く使われる。学習/導入が比較的容易。 - Terraform＝宣言的にインフラを定義し、状態ファイル（state）で「今作ってあるもの」を追跡して差分だけを適用するプロビジョニングツール。クラウド資源やインフラの作成/破棄のライフサイクル管理に強い。「あるべき姿」と「実体」の差分管理（plan/apply）が中核。
- Cisco NSO（Network Services Orchestrator）＝マルチベンダのネットワークをサービスモデルとして抽象化し、「L3VPNを一本作る」といった上位の意図を配下の各機器設定へ翻訳・配布・整合するオーケストレータ。多ベンダ・大規模のサービス提供と継続的な整合維持に強い。
「CI/CD＝lint→CMLでテスト→承認→本番→事後検証のゲート」「CML＝仮想ネットワークで本番前に安全に試す」「pyATS＝show出力を構造化し期待状態を検証（回帰検出）」「Ansible＝エージェントレス/YAML/push/冪等」「Terraform＝宣言的/状態管理/プロビジョニング」「NSO＝マルチベンダのサービスモデル・オーケストレーション」が頻出です。各ツールを得意分野で選び分けましょう。
あるチームのCI/CDパイプラインは、Gitへの変更提案（Pull Request）ごとに次の順で動きます：(1) yamllint で playbook の書式検査 → (2) CML 上に本番同型のトポロジを起動し変更を適用 → (3) pyATS で「全BGPネイバがEstablished」「対象IFがup」を検証 → (4) 人の承認 → (5) 本番へ Ansible で適用 → (6) pyATS で本番の事後検証。ある日、あるPRが段(3)で失敗して止まりました。ログを読むと、CMLに変更を当てた後の検証で「ある拠点のBGPネイバがIdleのまま」だったのです。ここで重要なのは、この失敗はパイプラインの故障ではなく、むしろパイプラインが本来の仕事をした証だという解釈です。もしこの検証段が無ければ、その設定ミスは本番の全拠点へ配布され、実際にBGPが落ちてから気づくことになりました。段(3)（CML＋pyATS）は「本番に触れる前に、仮想環境で期待状態を機械検証する安全網」であり、どの段で落ちたかが原因の所在を教えてくれます——段(1)なら文法、段(3)なら振る舞い、段(6)なら本番固有の差分、という具合です。もしこのチームが「速く出したいから検証段を飛ばそう」と考えたら、それは自動化の危険（誤設定を速く広く配る）を最大化する判断であり、本末転倒です。ツール選定も同様に得意分野で決まります：機器へ冪等に設定を配る本体はAnsible、期待状態の検証はpyATS、仮想の試験場はCML、もし多ベンダのサービス（L3VPN等）を抽象化して回すならNSOが中核になります。
| 道具 | 役割/得意分野 | 選ぶ場面 |
|---|---|---|
| Ansible | エージェントレス・YAML playbook・push・冪等な構成管理 | 機器へ設定を冪等に配布/取得したい |
| Terraform | 宣言的・状態管理・作成/破棄のプロビジョニング | （クラウド）資源のライフサイクルを管理したい |
| Cisco NSO | マルチベンダのサービスモデル・オーケストレーション | 多ベンダのサービスを抽象化し整合維持したい |
| CML | 仮想ネットワークのシミュレーション（試験場） | 本番前に変更を安全に試したい |
| pyATS | show出力の構造化と期待状態の検証（回帰検出） | 変更前後の状態を機械検証したい |
ひっかけ： 「パイプラインのテスト段でPRが落ちた＝自動化の欠陥」は誤りです——それは本番に届く前に誤設定を止めた正常な働きで、どの段で落ちたか（lint＝文法／CML+pyATS＝振る舞い）が原因の所在を示します。また「Ansibleは対象機器に専用エージェントの常駐が必要」も誤り＝Ansibleはエージェントレス（主にSSH/API）です。状態ファイルで資源ライフサイクルを追うのはTerraformの特徴です。
5.2.4この節のまとめ
- CI/CDは
lint→CMLでテスト→承認→本番→事後検証のゲート列。テスト段での失敗は誤設定を本番前に止めた正常な働き - CMLは本番前に安全に試す仮想試験場、pyATSはshow出力を構造化し期待状態を検証（回帰検出）する
- ツールは得意分野で選ぶ：Ansible（エージェントレス/冪等な構成配布）・Terraform（宣言的/状態管理のプロビジョニング）・NSO（マルチベンダのサービスオーケストレーション）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. CI/CDパイプラインが `lint → CMLでテスト → 承認 → 本番へAnsible → pyATSで事後検証` の順で動く。あるPRがCMLでのテスト段で「ある拠点のBGPネイバがIdleのまま」と検出されて停止した。この結果の解釈として最も適切なものはどれか。
Q2. 機器へ設定を配布する自動化ツールとして、対象機器に専用エージェントを常駐させたくなく、YAMLで「望む状態」を書いてSSH/API経由で冪等に適用したい。この要件に最も適したツールはどれか。
Q3. 変更適用の前後で「全BGPネイバがEstablished」「対象インタフェースがup」といった期待状態を、機器のshow出力を構造化データにして機械的に検証し、想定外の劣化（回帰）を検出したい。最も適したツールはどれか。