変更要約: 初版
5.1モデル駆動プログラマビリティとIaC
手作業のCLI設定からInfrastructure as Code（IaC）へ移る価値、宣言的・冪等性・バージョン管理というIaC原則、そして各機器を直接操作するデバイスレベル自動化とコントローラのインテントを介すコントローラレベル自動化の使い分けを、「この運用課題にはどちらの層で自動化すべきか」という判断として学びます。
ネットワーク自動化の出発点は「速く設定する」ことではなく、設定を人が読めるコードとして表現し、再現・レビュー・追跡できる状態にすることです。手作業のCLIは1台なら速くても、100台に同じ変更を安全に、しかも「今どうなっているか」を証跡付きで行うのは困難です。この節ではIaCが解決する課題と、その核となる宣言的・冪等・バージョン管理という原則、そして自動化をデバイス個別に打つのか、コントローラのインテント越しに打つのかという設計判断を、道具の名前でなく解決したい課題から選べるように整理します。
5.1.1IaCの価値
- Infrastructure as Code（IaC）＝インフラの構成（VLAN・ルーティング・ACLなど）をコードとして記述し、そのコードを適用して環境を作る手法。手順書に沿った手作業と違い、同じコードから常に同じ構成が再現でき（再現性）、環境ごとの設定ドリフト（人手のばらつきで各機器がずれる現象）を抑えられる。
- コード化の最大の恩恵はバージョン管理（Git）に載ることだ。誰が・いつ・なぜ変えたかが履歴に残り、レビュー（Pull Request）で第三者確認を経てから適用でき、問題があれば以前のコミットへロールバックできる。ネットワーク変更が「属人的な口伝」から「監査可能なプロセス」に変わる。
- IaCは速度より一貫性・安全性・スケールのための道具だと捉える。1台だけの一度きりの変更ならCLIが速いこともあるが、多数機器への反復適用・変更の証跡・チームでの共同作業が必要になった瞬間、IaCの価値が効いてくる。
5.1.2IaCの原則
- 宣言的（declarative）＝「どうやるか（手順）」ではなく「あるべき最終状態（what）」を記述する。例：「VLAN10が存在し、Gi0/1がそのアクセスポートである状態」を宣言し、現状との差分をツールが埋める。手続き的（imperative）に一手ずつ書くより、状態のずれに強い。
- 冪等性（idempotency）＝同じコードを何度適用しても結果が同じで、既に望む状態なら変更を行わない性質。冪等な自動化は「もう一度流したら二重に作られる／エラーになる」心配がなく、途中失敗後の再実行（リトライ）も安全。IaCツールが「changed=0」を返すのはこの性質の現れ。
- バージョン管理・単一の真実の源（SSOT）＝構成コードをGitに置き、それを唯一の正とする。機器の実機設定は「コードから生成された派生物」と位置づけ、直接手でいじる（out-of-band変更）ことを避ける。手変更を許すとコードと実機が食い違い、再適用時に上書き事故が起きる。
5.1.3デバイスレベルとコントローラレベル
- デバイスレベル自動化＝各機器に直接（NETCONF/RESTCONF/SSH-CLI等で）設定を配る方式。機器ごとに細かく制御でき、コントローラ製品が無くても始められるが、台数分の状態を自分で管理する必要があり、多ベンダ・大規模ではスクリプトが複雑化しやすい。
- コントローラレベル自動化＝Catalyst CenterやNSOのようなコントローラのAPI（インテント）に「望む状態」を伝え、コントローラが配下の多数機器へ翻訳・配布する方式。多ベンダ抽象化・全体整合・大規模運用に強い一方、コントローラ製品への依存とその理解が前提になる。
「IaC＝構成をコード化しGit/レビュー/ロールバック可能に（速度でなく一貫性・監査性）」「宣言的＝あるべき状態を記述」「冪等＝何度適用しても同じ・不要なら変更なし（changed=0）」「デバイスレベル＝各機器へ直接／コントローラレベル＝インテントをコントローラが多数機器へ翻訳」が頻出です。「新しいから自動化」ではなく課題（反復・多数機器・証跡・多ベンダ）から層を選ぶ視点を持ちましょう。
あなたは200拠点・約1,500台（Cisco中心だが一部他ベンダ混在）の企業ネットワークで、「各拠点のゲスト用VLANとACLを標準化し、監査で『いつ誰がどの変更をしたか』を示せるようにせよ」という依頼を受けました。まず現状は、拠点ごとにエンジニアが手でCLIを打ってきたため設定ドリフトが発生し、同じはずのゲストVLANが拠点ごとに微妙に違います。ここで「速いから」と各機器へ手作業や単純スクリプトでCLIを流し直すのは、証跡が残らず・再現できず・多ベンダ差も吸収できないため筋が悪い判断です。正しくは、標準構成を宣言的なコードとして1つ書き、Gitに置いてバージョン管理下でPull Requestレビューを通し、適用は冪等に行う（既に標準どおりの拠点はchanged=0で触らない）——これで「いつ誰がなぜ」が履歴に残り、監査要件を満たせます。次にどの層で自動化するかです。単一ベンダの数十台ならデバイスレベル（NETCONF/RESTCONFで直接）でも管理しきれますが、200拠点・多ベンダ・全体整合が要る本件では、各機器の状態を自前で抱えるのは破綻しやすい。コントローラレベル（例：NSOにサービスとしてゲストVLANを定義し、配下の多ベンダ機器へ翻訳・配布させる）を選ぶと、抽象化された「望む状態」を一箇所で管理でき、ドリフトの再発もコントローラが継続的に是正します。ここで重要なのは、IaCの価値を「設定が速くなる」と誤解しないことです。本件の本質は一貫性・監査性・スケールであり、changed=0が返ること（＝望む状態に既に一致し何もしないこと）こそが、冪等で安全な運用の証なのです。
| 観点 | デバイスレベル自動化 | コントローラレベル自動化 |
|---|---|---|
| 操作対象 | 各機器へ直接（NETCONF/RESTCONF/CLI） | コントローラのAPIへインテントを送る |
| 状態管理 | 台数分を自前で管理 | コントローラが配下を集中管理・是正 |
| 多ベンダ/大規模 | スクリプトが複雑化しやすい | 抽象化で吸収・全体整合に強い |
| 向く場面 | 少数・単一ベンダ・細かな個別制御 | 多拠点・多ベンダ・継続的整合 |
ひっかけ： 「IaCの主目的は設定を速くすること」は誤りです——本質は一貫性・再現性・監査性・スケールで、changed=0（望む状態に既に一致し何も変更しない）が返るのは失敗ではなく冪等性が効いている正常な結果です。また「コントローラレベルのほうが常に優れている」も誤り＝少数・単一ベンダで細かな個別制御をしたい場面では、デバイスレベルの直接操作のほうが素直なこともあります。
5.1.4この節のまとめ
- IaCは構成をコード化してGit/レビュー/ロールバック下に置く手法で、価値は速度でなく一貫性・再現性・監査性・スケール
- 原則は宣言的（あるべき状態を記述）・冪等（何度でも同じ・不要なら変更なし＝changed=0）・バージョン管理/SSOT（コードを唯一の正とし手変更を避ける）
- 自動化の層は課題で選ぶ：少数・単一ベンダ・個別制御はデバイスレベル、多拠点・多ベンダ・継続整合はコントローラレベル（インテント）
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 200拠点・多ベンダの機器で、各拠点のゲストVLANとACLを標準化し「いつ誰がどの変更をしたか」を監査で示せるようにしたい。運用アプローチとして最も適切なものはどれか。
Q2. ある自動化を2回連続で実行したところ、1回目は複数の設定が反映され、2回目は「changed=0」と報告され何も変更されなかった。この結果の解釈として最も適切なものはどれか。
Q3. Cisco中心だが一部他ベンダを含む多数機器に対し、抽象化された「望む状態」を一箇所で管理し、配下機器への翻訳・配布と継続的な整合をさせたい。最も適した自動化の層はどれか。