# ネットワーク自動化 ## 定義 ネットワーク自動化とは、ネットワークの構成・運用を人間の手作業からソフトウェアによる自動処理へ置き換える取り組みであり、その最も野心的な形態がインテントベースネットワーキング(利用者が個々のコマンドでなく達成したい意図(インテント)だけを示す仕組み)である。著者は、SDN(ソフトウェア定義ネットワーク)の意味を理解する上での転機として、2011年に Scott Shenker がスタンフォード大学で行った講演 "The Future of Networking, and the Past of Protocols" を挙げる。Shenker の主張は、完全に分散されたアルゴリズム(ルーティングプロトコルなど、ネットワーキングの中核)の振る舞いを理解するのは極めて困難であり、データプレーンから切り離された集権型コントローラという新たな抽象化レイヤーが必要だというものだった。中央集権型コントローラはネットワーク全体をあたかも一つの巨大なスイッチであるかのように抽象化して見せるが、分散アルゴリズムの複雑さをコントローラの中に隠蔽すること自体は言うほど簡単ではなく、これが実用的な SDN システム構築の難しさの核心である。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.6) ## Nicira とネットワーク自動化の関係:見落とされがちな成功要因 [[Nicira]] を世に知らしめ [[VMware]] による買収につなげた SDN の代表的ユースケースは「ネットワーク仮想化」とされるが、この成功において「ネットワーク自動化」が果たした重要な役割はとかく見落とされがちである。買収以前の Nicira の顧客は、著者の記憶する限りすべて何らかのネットワーク自動化プロジェクトのために NVP(Network Virtualization Platform)を利用していた。当初の典型的なユースケースは開発者向けクラウドのサポートであり、開発者がセルフサービスのポータルを通じて VM とネットワークリソースを申請する。2012年時点で VM の払い出しに技術的課題はなかったが、ネットワークのプロビジョニングは依然として苦痛極まりない手作業のままだった。Nicira の着眼点は、中央集権型の SDN コントローラが外部に API を公開し、セルフサービスのポータルからそのコントローラを呼び出せるようにしたことにある——中央制御は Shenker の講演ではネットワークをプログラム可能にするためのものだったが、結果として設定の自動化も可能にした。ポータル側は物理的にどのネットワーク機器が各 VM の通信を担っているかを知る必要がなく、VM がデータセンター内を移動しても SDN コントローラが要求されたネットワーク機能を追随させる。(Source: ch.11 §11.6) Nicira 社内では自社製品のドッグフーディングとして、開発者向けのセルフサービスポータル(OpenStack ベース)が用意されていた。ここでは NVP インスタンスが提供する仮想ネットワークの上でさらに別の NVP インスタンスが仮想ネットワークを提供するという入れ子の仮想化になっており、著者らはこれを映画『インセプション』になぞらえて呼んでいた。この仕組みは、スイッチやルータを操作して VLAN を切ったり NAT ルールを書いたりする代わりに、開発者が「VM をこういうトポロジーで相互接続したネットワークが欲しい」という意図(インテント)を示すだけでよいという点で、インテントベースネットワーキングの原点の一つと言える。「インテントベースネットワーキング」という用語自体はもっと後に生まれ、より広義の概念になったが、基本的なアイデアはこの時点ですでに存在していた。(Source: ch.11 §11.6) ## 自動化のスケールアウトと限界 ネットワーク仮想化のビジネスを本格的に拡大しようとした段階で、ほとんどの顧客にとって自動化がまだ現実味のない高嶺の花であることが判明するという逆説が生じた。VMware による Nicira 買収完了(2012年後半)後、顧客とのミーティングで最初に投げかけた質問「御社の自動化戦略はどうなっていますか？」に、ほとんどの顧客はポカンとした顔をするだけだった。Nicira の当初の顧客が並外れて洗練された企業ばかりであり、一般的な企業では考えられない水準ですでに VM のプロビジョニングを自動化していたために、ネットワーク構築における手作業の辛さが際立って見えていたにすぎなかった——NVP の真価が理解されるには、まず前提としてコンピューティングの自動化が完了している必要があった。当時の自動化プラットフォームは驚くほど未熟で、選択肢は OpenStack か VMware の VRA くらいしかなかった。(Source: ch.11 §11.6) 2013年の分散ファイアウォールの登場によるマイクロセグメンテーションという新ユースケースへの道が切り拓かれた結果(第8章「セキュリティ：負の目標」参照)、本来の目的だったネットワーク自動化は主役の座を奪われて舞台の袖に追いやられた。洗練された組織による自動化の好例として、Jeff Mogul率いるGoogleのチームによるNSDI 2020での報告があり、自動化に先立って対処すべき複雑性と、なぜ小規模な組織がネットワーク自動化に踏み込めないのか(手作業の痛みが致命的でなく、リソース確保・投資コストを正当化できない)が読み取れる。マイクロサービスの登場と Kubernetes の台頭によりこの状況はやや好転したが、著者が思い当たるネットワーク自動化の成功事例はいずれも仮想ネットワークの世界に限定される。物理ネットワークの自動化については、業界の構造やインセンティブの仕組みを見る限り完全自動化が近いとは考えにくいと著者は述べる。(Source: ch.11 §11.6) ## 横断的知見 - **SDN の商業的成功経路(自動化)は、研究コミュニティが思い描いたビジョン(集権制御による分散アルゴリズムの単純化)と乖離していたことが、[[ソフトウェア定義ネットワーク]] concept が既に記録する「技術主導 対 商業主導」の対比を、より具体的な因果関係として補強する**: [[ソフトウェア定義ネットワーク]] concept は、OpenFlow が学術研究コミュニティに端を発する技術主導の取り組みであり、Nicira の VMware による買収・Google/Microsoft の SDN 基盤採用という商業的採用が変革を加速させたと記録する。本章はこれをさらに一段掘り下げ、「SDN が最初に商業的な大成功を収めたのは、プライベートクラウドにおけるネットワーク設定の自動化に関する課題への適用であった」「研究コミュニティの大半が思い描いていた当初のSDNのビジョンとは違う形であった」と明記する。つまり技術主導と商業主導の乖離は単なる「起源の違い」ではなく、商業的普及を牽引した具体的な用途(自動化)そのものが、技術を生んだコミュニティの当初の関心(分散アルゴリズムの単純化)とずれていたという、より強い主張である。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.6, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 2 システムとネットワークのアーキテクチャ]]) - **GitOps のインテント記述と、Nicira NVP のインテントベースネットワーキングは、独立した文脈で同じ「意図の宣言」という設計原理に到達している**: [[GitOps]] concept は、構成を宣言的に記述してリポジトリを信頼できる唯一の情報源とするアプローチを扱い、開発者・運用者の役割分離という文脈で論じられる。本ページが扱う Nicira の事例は、開発者が「VM をこういうトポロジーで相互接続したネットワークが欲しい」という意図だけを示せばよいというインテントベースの発想であり、いずれも「実装の詳細な手順ではなく、達成したい状態を宣言する」という点で同型の設計原理を共有する。ただし GitOps はコードリポジトリという静的な文書を正本とするのに対し、NVP のインテント記述はセルフサービスポータル経由の API 呼び出しという対話的な手段を取る点で異なり、両者を統合的に扱う枠組みは本章では示されない。(Source: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2, §11.6) - **同じ著者(Larry Peterson・Bruce Davie)による2冊の書籍が、ネットワーク自動化を「教科書的な技術の系譜」と「実務者の回顧録」という異なる視点から補い合う**: 本ページはこれまでLambdaNote版第11章という実務者視点の一次資料のみに依拠し、NiciraのNVPがネットワーク自動化を実現した経緯とその後の限界を描いてきた。[[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.3.2は同じ著者らによる教科書側の記述であり、SNMPが「監視専用のトランスポートプロトコル」にすぎず構成のプログラマブルな変更をほぼ扱えなかったこと、これに対しOpenConfigはYANGによるデータモデル(SNMPのMIBに相当)を軸に監視と構成を対等に扱う点で質的に異なることを、ゼロタッチ管理(zero-touch management)というビジョンの一部として位置づける。教科書側は「なぜSNMPだけでは自動化に至れなかったか」という技術的な構造(監視と構成の非対称性)を説明し、LambdaNote側はその構造的制約の中でNiciraがどう商業的に自動化を実現したか(セルフサービスポータル経由のインテント記述)という実務上の経路を語る。両者を合わせると、ネットワーク自動化の実現には(1) SNMPの限界を超える構成可能なデータモデル(YANG/OpenConfig、教科書が説明)と、(2) それを実際に使いこなす商業的なユースケースと自動化ツール(NiciraのNVP、LambdaNote版が説明)という2つの層が必要だったことが分かる。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.3.2, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.6) - **gNMI/YANGという教科書の記述は、[[YANG]] entityがLambdaNote第11章から記録してきたAether文脈での採用理由(バージョニング・RBAC)とは異なる、gRPC上でのプロトコルバインディングという技術的な軸を補う**: [[YANG]] entityはこれまでAether向け実行時制御APIの文脈で、YANGの採用理由(ツールセットの充実、バージョニング対応、永続化方式非依存、RBAC対応)を記録していた。第9章§9.3.2は、YANGがXSDの制限版でありXML以外にProtobufs・JSONといった複数のワイヤフォーマットと組み合わせられること、そしてOpenConfigが有力視する具体的なRPC機構がgNMI(gRPC上で動作しHTTPを経由する)であることを述べる。これは[[砂時計モデル]]が論じるHTTPへの収束(既存の横断的知見を参照)が、ネットワーク管理という応用領域にも及んでいることを示す一事例であり、YANGの技術的な位置づけ(データモデリング言語)とgNMIの位置づけ(トランスポート、SNMPに相当する役割)の違いを明確化する。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.3.2, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.2) - **第9章が教科書的に述べる「gNMIがOpenConfigの有力なRPC機構である」という一文は、*Software-Defined Networks: A Systems Approach* 第5章では宣言的構成状態(`rw`)と実行時フィードバック状態(`ro`)を単一のデータモデル階層で扱う、という具体的な設計原理として肉付けされる**: 第9章はgNMIを「gRPC上で動作しProtobufsをデータ表現に使う」という技術的な特徴だけで説明するが、ch.5 §5.3はさらに踏み込み、OpenConfigの各モデルが `rw`(クライアントが読み書きできる構成状態)と `ro`(デバイスのステータスを報告する運用状態)を組で持つこと、そしてこの区別がネットワーク機器インターフェースに共通する基本的な性質であり、OpenConfigは特に `ro` 側をオペレータが追跡すべきネットワークテレメトリデータへ一般化することに注力すると説明する。加えてch.5は、非冪等な運用操作(reboot・ping)や一時的な状態のクリア・設定を担う姉妹インターフェースgNOIを導入し、「永続的な構成はgNMI、一時的な状態・非冪等操作はgNOI」という役割分担を明示する。この`rw`/`ro`の区別と gNMI/gNOI の役割分担は、ネットワーク自動化が単なる「設定の書き込み自動化」ではなく、構成状態・運用状態・非冪等操作という3種類の異なる管理対象を区別してモデル化する必要があることを示す、教科書側の記述には無い具体化である。(Source: [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]] §9.3.2, [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.3) - **Stratumが追跡するOpenConfigモデルの絞り込み(Interfaces・VLANs・QoS・LACPのみ)は、ネットワーク自動化が「全構成状態を自動化する」のではなく「集権型コントローラの関心範囲に応じて自動化対象を意図的に絞る」設計判断であることを具体的に示す**: 本ページがこれまで記録してきたNiciraのNVP事例やゼロタッチ管理のビジョンは、ネットワーク自動化を「手作業の構成作業をソフトウェアに置き換える」という一般論として語ってきた。ch.5 §5.3は、集権型コントローラをサポートするSwitch OS([[Stratum]])が、BGPのようなコントロールプレーンプロトコルの構成には通常関与しないという具体的な線引きを示す——そうしたプロトコルはSDNベースのソリューションではもはやスイッチ上に実装されず、それらの集権型対応物を実装する Network OS(第6章)の対象範囲に残る。つまりネットワーク自動化のスコープは、単一のコンポーネントが全てを自動化するのではなく、アーキテクチャ上の役割分担(Switch OSはデータプレーン構成のみ、Network OSはコントロールプレーンロジック)に沿って分割されることが、Stratumの具体例から確認できる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.3) - **物理ネットワークの自動化事例(KDDI)は、本ページが既に記録する「物理ネットワークの自動化は仮想ネットワークに比べ遅れている」という観察に、具体的な反例と限定条件の両方を与える**: 本ページはこれまでLambdaNote第11章に基づき、Nicira NVPが牽引した自動化は仮想ネットワークの世界に限定され、物理ネットワークの自動化は業界構造上進んでいないと記録してきた。[[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.8が報告する[[KDDI株式会社]]のHaaS Management NW事例は、物理スイッチのZTP(Zero Touch Provisioning)による構築自動化という具体的な反例を示す一方、その適用範囲は「まずユーザートラフィックが乗らない管理ネットワークへ導入し理解を深める」という限定的なスコープにとどまり、KDDIの選定理由も「デリバリー(構築の自動化・納期)」という個別ハードウェア導入の効率化に閉じている。NiciraのNVPが開発者向けセルフサービスポータル経由のインテント記述(「VMをこういうトポロジーで相互接続したネットワークが欲しい」)という抽象度の高い自動化だったのに対し、KDDIの事例はONIE+ZTPによる「機器単体の構築完了までの流れ」(図2.5)という、より低レベルな物理プロビジョニングの自動化である。両者を並べると、「自動化」という言葉が指す抽象度(意図の宣言 対 個々の機器の初期設定投入)が仮想/物理という対立軸とは独立に存在することが分かる。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.8, [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] ch.11 §11.6) - **LINE株式会社のSONiC選択理由「自動化」は、Nicira/KDDIとは異なる第三の自動化像(既存OSSツールチェーンの活用可能性)を示す**: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.7によれば、LINE株式会社がSONiC選択の3ポイントの一つに挙げる「自動化」は、RESTやFRR(FRRouting)が利用可能である点を指す——すなわち、既存のオープンソースツールチェーンとAPIをそのまま使って自動化を組み立てられることが動機であり、Niciraのようなセルフサービスポータル経由のインテント記述でも、KDDIのようなZTPによる初期プロビジョニング自動化でもない。SONiCという1つの技術が、採用企業によって「意図の宣言」「機器の初期構築」「既存ツールチェーンとの親和性」という3つの異なる粒度の自動化価値として語られている点は、本ページが今後の ingest で「自動化」の語をより厳密に腑分けする必要があることを示唆する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.7) ## 未解決の問い - KDDIのZTP事例(管理ネットワーク限定)とLINEのSONiC採用(本番IP CLOSネットワーク)は、いずれも「自動化」を採用理由に挙げるが、適用範囲のリスク許容度が大きく異なる。物理ネットワーク自動化がどこまで本番トラフィックを乗せる領域へ広がるかは、この2社の後続の展開(本書執筆時点では確認できない)を追う必要がある。 - 本章は「小規模な組織はネットワーク自動化に踏み込めない」理由を投資対効果の欠如に帰するが、この閾値(組織規模・ネットワーク規模がどの程度になれば自動化投資が正当化されるか)は定量化されていない。[[自動化のアイロニー]] concept が扱う自動化投資のトレードオフ論と接続できるか。 - Nicira の NVP が体現した「セルフサービスポータル経由のインテント記述」と、GitOps の「コードリポジトリ経由の宣言的記述」は、いずれもネットワーク自動化の異なる実装形態だが、両者を統合した単一のワークフローは実現可能か。本章はこの二つを別々のエッセイ(§11.2/§11.6)で扱うにとどまる。 - 物理ネットワークの自動化が仮想ネットワークの自動化に比べて遅れている理由として、著者は「業界の構造やインセンティブの仕組み」を挙げるが具体的な要因は詳述しない。この構造的障壁の内実(ベンダーロックイン、標準化の欠如、既存投資の埋没費用等)は今後の ingest で確認する必要がある。 - インテントベースネットワーキングという用語がNVP以降どのように定義され直され、SDNのコントロールプレーン設計とどこまで技術的に一体化したかは、本章では扱われない。第5章・第9章の記述との突き合わせが必要。 - ch.5が示す「Stratumはデータプレーン構成のみ自動化対象とし、コントロールプレーンプロトコルの構成には関与しない」という線引きは、Nicira NVPが示した「開発者向けセルフサービスポータルによる自動化」というユースケースとどう接続するか。両者は自動化のレイヤー(Switch OSのデータプレーン構成 対 テナント向けネットワークプロビジョニング)が異なるため単純に比較できないが、この階層関係(どのレイヤーの自動化がどのレイヤーに依存するか)は本書では明示的に整理されていない。 - gNOIが担う非冪等な運用操作(reboot・ping・SetPackage)は、自動化の文脈でどこまで安全にオーケストレーションできるのか。gNMIによる宣言的構成の自動化と異なり、非冪等操作の自動化は誤動作時のロールバックが原理的に難しいはずだが、本章はこの違いを設計論として深掘りしない。 ## 関連 - 概念: [[ソフトウェア定義ネットワーク]](技術的基盤) / [[GitOps]](インテント記述という共通の設計原理) / [[ワークフロー自動化]](運用自動化全般) / [[自動化のアイロニー]](自動化投資のトレードオフ、および[[自動化の皮肉]]も参照) / [[砂時計モデル]](HTTPへの収束という共通軸) / [[プログラマブルデータプレーン]](P4Runtimeによるフォワーディング制御の自動生成という並行事例) - 実体: [[Nicira]] / [[VMware]] / [[Martin Casado]] / [[Scott Shenker]] / [[Kubernetes]] / [[YANG]] / [[gNMI]] / [[Stratum]] / [[SONiC]] / [[KDDI株式会社]] / [[LINE株式会社]] - ソース: [[@2026__LambdaNote__ネットワークシステムについて語るときに我々の語ること - Chapter 11 ネットワーク管理は今やクールな仕事だ]] / [[@2020__SystemsApproach__Computer Networks - A Systems Approach - Chapter 9 Applications]](§9.3.2、SNMPからOpenConfig/gNMI/YANGへの教科書的説明) / [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]](§5.3、gNMI/gNOIの具体的な設計原理) / [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]](§2.2.7-§2.2.8、KDDIのZTP事例・LINEのSONiC選択理由「自動化」) - 書籍: [[ネットワークシステムについて語るときに我々の語ること]] / [[Computer Networks - A Systems Approach]] / [[Software-Defined Networks - A Systems Approach]] ## 出典 - Larry Peterson・Bruce Davie 著, 進藤資訓 訳, 『ネットワークシステムについて語るときに我々の語ること』, ラムダノート, 2026, 第11章 §11.6「ネットワーク自動化はどうなった？」. - Larry Peterson and Bruce Davie, *Computer Networks: A Systems Approach*, 6th edition, Chapter 9: Applications, §9.3.2 Network Management (SNMP, OpenConfig). https://book.systemsapproach.org/applications.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 5: Switch OS, §5.3. https://sdn.systemsapproach.org/stratum.html - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第2章 §2.2.7, §2.2.8.