第5章 · インフラと自動化·v1.0.0·更新 2026/7/20·読了目安 約16分
変更要約: 初版
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の価値が効いてくる。