Designing Network Automation at Scale

01 - 自動化という必然

Mon, 01 Jan 0001 00:00:00 +0000

1. 自動化という必然#

「自動化すべきか、せざるべきか、それが問題だ。」

Software-Defined Networking (SDN)とDevOpsが登場して以来、ネットワーク自動化は必要なのか、贅沢なのか、それとも過剰な設計なのかという議論が絶えない。答えは「場合による」。ハイパースケーラーには必須だ。選択の余地がなかった彼らは2010年代初頭にすでに着手していた。中小企業には完全な自動化はまったく不要かもしれない。ほとんどのネットワークはその中間に位置する。文化、スキル、ツールの成熟度、ビジネスの優先事項、これらすべてが採用のスピードを左右する。今日、これらの要因がそろいつつある。自動化は避けられない流れになっている。

ある地域物流会社のネットワークチームは、自分たちが「自動化プラットフォーム」と呼ぶものを3年かけて構築した。VLANプロビジョニング、BGPネイバー設定、デバイスハードニング用のAnsibleプレイブック。コードはGitで管理され、変更はピアレビューを経て、デプロイは数日ではなく数分で完了した。あらゆる指標において、彼らは自動化を正しく実践していた。

そして会社が競合他社を買収し、一夜にして規模が2倍になった。新しいサイト、2つの新ベンダー、自社の命名規則と衝突する命名規則。新環境に対してプロビジョニングプレイブックを初めて実行したとき、エッジケースで失敗した。修正した。また別の箇所で失敗した。買収から6週間後、1人のエンジニアが手動でネットワークを運用するよりも、自動化のメンテナンスに多くの時間を費やすようになっていた。

振り返りの場は居心地が悪かった。ツールは失敗していなかった。Ansibleは問題なかった。失敗していたのは目に見えないものだった。ネットワークがどうあるべきかという単一の記述が存在しなかったのだ。各プレイブックは命名規則、IPアロケーション戦略、ベンダー挙動に関する独自の前提を抱えていた。環境が変わると、すべての前提が同時に崩れた。チームは既存のネットワークを自動化していたのであって、変化に適応できるプラットフォームを構築していなかった。

これがあらゆる自動化の停滞の根本にあるパターンだ。組織は、今日の問題のために構築した自動化が明日の障害になる地点に必ず差し掛かる。

1.1. 完璧な嵐#

自動化はもはや任意ではない。ハイパースケーラーは爆発的なArtificial Intelligence (AI)成長に対処している。数十万のCentral Processing Unit (CPU)とGraphics Processing Unit (GPU)が高速イーサネットを通じて通信している。エンタープライズやサービスプロバイダーは、レガシーインフラ、新サービス、クラウド/オンプレミス/エッジの拡散、コスト増大に悩まされている。

02 - 設計原則

Mon, 01 Jan 0001 00:00:00 +0000

2. 設計原則#

あるネットワーク自動化チームが6ヶ月かけて、本当に誇りに思えるシステムを構築した。構造化データモデルからインテントを取得し、テンプレートエンジンでデバイス設定を生成し、ポリシーライブラリに照らして変更を検証し、完全なロールバック機能を備えたNETCONF経由でプッシュする。アーキテクチャ的には盤石だった。経営陣へのデモも好評だった。そしてネットワーク運用チームに引き渡した。

導入は一向に進まなかった。オペレーターはCLIを使い続けた。理由を尋ねると、答えは一致していた。「実行する前に何が起きるかわからない」「何か問題が起きたとき、何が起こったのか把握できない」「出力の読み方がわからない」。自動化チームは技術的には印象的なものを作り上げたが、運用面では不透明だった。ドライランモードも、人間が読めるような変更プレビューも、オペレーターが認識できる言葉で書かれた監査証跡も存在しなかった。システムはまだ信頼を得ていないのに信頼を求めるブラックボックスだった。6ヶ月分のエンジニアリングの成果は使われないまま放置された。

この結果はほとんどのチームが認めるよりもはるかによく起きる。自動化はバグや設計の欠陥だけで失敗するわけではない。それに依存しなければならない人々が信頼しないために失敗する。ここでは、ネットワーク自動化を信頼性高く、スケーラブルで、安全なものにする基本的な設計原則を探っていく。これらは抽象的な理論ではない。導入されて真の価値をもたらす自動化と、無視されて最終的に放棄される自動化の違いだ。

これらの原則の多くは他のソフトウェアプロジェクトにも当てはまる。しかしネットワーク自動化は重要なインフラを支えるという独自の特性を持つ。ネットワークエンジニアは慎重さ、精度、手動検証に基づくモデルを使ってこれらのシステムを数十年にわたって構築・保守してきた。今、私たちは彼らに根本的に異なるモデルを採用するよう求めている。それには信頼が必要だ。

2.1 信頼を築く#

具体的な原則に入る前に、信頼について話しておこう。信頼はネットワーク自動化を成功させるための礎だ。それなしには、導入はほぼ不可能になる。

なぜ信頼がこれほど重要なのか？なければ、ネットワークエンジニアはあなたの自動化を採用しないからだ。自動化が置き換える手動プロセスと少なくとも同等の信頼性（さらにその他のメリット）を提供すると信じてもらう必要がある。

さらに難しいのは、自動化システムを構築するエンジニアが深いネットワーク経験を持っていない場合が多いことだ。だから自動化は、ネットワークエンジニアチームにとって安全で、信頼でき、カスタマイズと管理がしやすいという強く明示的な特性を埋め込むことで補完しなければならない。

シンプルにまとめると、必要な4つの基本特性は以下の通りだ。

Predictable（予測可能）: 一貫した決定論的な結果。エンジニアは「実行」を押す前に何が起きるかを知る必要があり、毎回同じ動作が得られなければならない。
Reliable（信頼性）: エラーを適切に処理する。障害から回復する。予期しない状況下でも、規模が大きくなっても、操作が安全に完了する（またはロールバックする）ことを保証する。
Usable（使いやすさ）: 過度な複雑さなしにエンジニアが動作を検証、理解、制御できるインターフェース。ガードレール付きで。
Understandable（理解可能）: ブラックボックスであってはならない。インテント、ステップ、結果、判断を、人間の信頼を築く形で公開しなければならない。

graph BT
 %% ===== Middle Layer =====
 subgraph L2[**特性**]
 direction LR
 B1[予測可能]:::layer2
 B2[信頼性]:::layer2
 B3[使いやすさ]:::layer2
 B4[理解可能]:::layer2
 end

 %% ===== Top Layer =====
 subgraph L1[" "]
 direction TB
 A[信頼]:::layer1
 end

 %% ===== Connections: Behavior → Outcome =====
 B1 --> A
 B2 --> A
 B3 --> A
 B4 --> A

 %% ===== Styling =====
 classDef layer1 fill:#ffcccc,stroke:#b8860b,stroke-width:2px,color:#000;
 classDef layer2 fill:#ffe6cc,stroke:#4682b4,stroke-width:1.5px,color:#000;

03 - アーキテクチャ的思考

Mon, 01 Jan 0001 00:00:00 +0000

3. アーキテクチャ的思考#

この章は本書の基盤を紹介する。このマインドセットを採用する必要がある理由を説明し、Network Automation Forum（NAF）が提唱する参照フレームワークを紹介し、自分のプロジェクトでどう活用するかを示す。

第2部ではこれらのトピックを深く掘り下げる。この章では、各構成要素を詳述する前に全体像を把握できるよう、概要を紹介するにとどめる。これが重要な理由は、各構成要素を説明したとき、全体像があると点と点をつなぎやすいからだ。

しかし筆者はWHATを知る前にWHYを理解することを強く信じているので、まずアーキテクチャを活用する理由を理解しよう。

3.1. 参照アーキテクチャが重要な理由#

「教育を受けた者だけが自由だ。」 エピクテトス

ネットワーク自動化ソリューションは複数のピースの組み合わせで、それぞれが役割を担う。ネットワーキングの世界では、あらゆる問題を解決しようとするシンプルなモノリシックなソリューションに慣れ親しんでいる。ある程度はそれが正しいかもしれないが、単独で多様な課題とユースケースすべてを解決できるものはない。だから、ユースケースが最も一般的なものでなければ、カスタマイズや拡張が必要になるかもしれない。

明確な参照アーキテクチャがなければ、チームは予測可能な一連の問題に直面することが多い：

重複した努力: 複数のチームが同様のツール（データソース、重複したスクリプト、冗長なモニタリングシステム）を独立して構築し、リソースを無駄にして一貫性のないインターフェースを生む。
統合のギャップ: ツール同士がきれいに連携せず、高コストなカスタム統合作業を強いられる。
責任の不明確さ: どのツールがオブザーバビリティ、オーケストレーション、状態管理を担当すべきかが不明確で、混乱と責任のなすり合いにつながる。
拡張の難しさ: 新しい機能やツールの追加がシステム全体の再考を必要とする。
知識のサイロ化: 異なるチームが異なるメンタルモデルを使い、新しい人のオンボーディングやソリューションの保守が難しくなる。

参照アーキテクチャはこれらの問題を、自動化システムをどのように整理すべきかという単一の明確なメンタルモデルを提供することで解決する。それが定義するのは：

各コンポーネントが何をすべきか → その責任
コンポーネントがどのように相互作用するか → インターフェースとデータフロー
どこで選択できるか → どのツールを使うか
どこで一貫性が必要か → コンポーネント間の通信方法

参照アーキテクチャはネットワークエンジニアにとって新しいものではない。私たちは皆、親しみ深いOSIモデルとともに育ってきた。OSIモデルを使うことで、各レイヤーが異なる責任と関心事を持つため、ネットワーク問題を診断して理解するための段階的なレイヤードアプローチが得られる。ネットワークの専門家は、この懸念事項の分離が複雑なシステムを管理可能にすることを直感的に理解している。

ネットワーク自動化でも、連携して機能するソリューションの開発と相互接続を導くための同様のものが必要だ。チームが一貫した決定を下し、プロジェクト間でコンポーネントを再利用し、毎回ゼロから考え直すことなく自動化の能力を進化させる助けになる。

3.2. ネットワーク自動化アーキテクチャ#

これを踏まえると、アーキテクチャが必要だ。しかしセクションタイトルの「A（一つの）」に注目してほしい。アーキテクチャは一つだけではなく、多くある。アーキテクチャは単なる参照フレームワークだ。思考を整理し、一貫した決定を導く方法。筆者は3つのイニシアティブに貢献してきた：

Network to Code参照アーキテクチャ：NTCアーキテクチャチーム（筆者が4年間参加）が主導した集合的な取り組みで、幅広いユースケースにわたって効率的で理解しやすいネットワーク自動化をサポートするよう設計されている。
O’Reilly「Network Automation and Programmability」第2版：共著者のMatt Oswalt、Scott S. Lowe、Jason Edelmanとともに本書のすべてのコンテンツの点と点をつなぐ取り組み。
NAFフレームワーク：Wim Henderickx、Dinesh Dutt、Claudia de Luna、Ryan Shaw、Damien Garrosとともに主導した、NAFの傘下のコミュニティプロジェクト。初心者と経験豊富な実践者の両方が構造化された再現可能な方法で自動化ソリューションを構築できるようにすることを目標としている。

これらのイテレーションを通じて、一貫性を維持し各進化から学ぶことに注力してきた。3つのアプローチすべてが有用だ。しかし、NAF Frameworkを現在のベストプラクティスとして使用することを提案する。コミュニティ主導で、ベンダーに依存せず、広く適用可能だ。長年の集合的な学習を統合し、積極的に活動する成長するコミュニティによって維持されている。

04 - Source of Truth

Mon, 01 Jan 0001 00:00:00 +0000

4. Source of Truth#

新しいサービスを週末までに本番稼働させる必要があった。変更内容は単純だった。新しいVLAN、新しいサブネット、ファイアウォールルールの更新、エッジルーターへのBGPコミュニティの追加。担当のネットワークエンジニアは何をすべきかを正確に把握していた。ところが実際には、5つのシステムにまたがる4日間の調整作業が待っていた。サブネットを予約するIPAMツール、サービスを登録するCMDB、新しいポリシーを適用するファイアウォール管理プラットフォーム、BGPコミュニティを設定するルーター構成システム、そして新しいしきい値を追加する監視プラットフォーム。各システムはそれぞれ独自のインターフェース、独自のデータモデル、独自の承認ワークフローを持っていた。共通の参照点がなかったため、エンジニアは手動でコンテキストを持ち回るしかなかった。あるシステムから値をコピーして次のシステムに貼り付け、途中でデータが変わっていないことを祈りながら。

6カ月後、そのサービスは廃止された。VLANは削除され、サブネットも解放された。しかしファイアウォールルールはそのまま残った。そのルールがそのサービスに紐付いていたことを誰も覚えていなかった。BGPコミュニティは2台のエッジルーターに残り続けた。監視のしきい値は低優先度のアラートを出し続けたが、NOCはいつしかそれを無視することを学んでいた。時間とともに、ネットワークには孤立した設定が積み重なっていった。完全に追跡されず、完全に削除されず、共通の意図の記録に紐付けられることもなかった変更の残骸が。

これが、Source of Truth なしにネットワークを運用するということの実態だ。一度の劇的な障害ではなく、じわじわと積み重なる不整合。すべての変更が複数の分断されたシステムの更新を必要とし、何が関連しているかを追い続けるものが何もない状態。

すべての自動化システムは一つの問いから始まる。実際に何をしようとしているのか? ファイアウォールルールを展開するとき、IPアドレスを追加するとき、VLANを設定するとき、あなたは何らかのインテントの表現に基づいて行動している。その表現こそが Source of Truth だ。つまり、何が展開されるべきかを示す、唯一の信頼できるバージョン。

信頼できる Source of Truth なしでは、ネットワーク運用は属人的な知識の塊になってしまう。エンジニアは何が展開されているかで意見が食い違う。スプレッドシートは実際に動いているものと矛盾する。2つの異なる自動化システムが同じデバイスに対して競合する変更を加える。何かが壊れると、考古学者のような作業が始まる。「なぜこう設定されているのか? 誰が承認したのか? いつ変わったのか?」

本章では、デバイスが数十台であれ数十万台であれ機能し、データを必要とするすべての人(人間、自動化、他のシステム)に提供し、データの正確性と信頼性を維持し、複数のソースからのデータ収集の複雑さを処理できる Source of Truth の構築方法を解説する。6つの構成要素を取り上げる。Modeling、Consumption、Enforcement、Versioning、Aggregation、Design-Driven だ。これらが組み合わさることで、ネットワーク自動化の堅固な基盤が生まれる。既存のネットワークをこのシステムに取り込む際の実践的な課題にも触れ、実際に利用可能なソリューションも紹介する。

4.1. 基本原則#

Source of Truth は3つのことを行う。インテントをどう表現するかの方法を定義し、そのインテントがどこに存在するかを定め、それを長期にわたって信頼できる状態に保つ方法を確立する。これがなければ、他の構成要素は共通の参照点を持たない単独ツールの集まりになってしまう。これがあれば、それらは連携して機能する。

4.1.1. ゴール#

Source of Truth が果たすべき6つの役割がある。

必要なすべてを把握する。ネットワークの全体像を保存する。設定、資産、トポロジー、サービス、IPアドレス、回線、デバイス仕様、認証情報、メンテナンスウィンドウ、コンプライアンス要件、所有者情報。現在稼働しているものだけでなく、計画中のものと廃止予定のものも含める。このデータがスプレッドシートや担当者の頭の中ではなく一か所に集まって初めて、自動化システムは賢い判断を下すために必要なコンテキストを手にできる。
オペレーターがビジネスの言葉で考えられるようにする。スタッフはビジネスレベルで作業すべきだ(「新しいブランチを追加する」や「MPLSサービスをセットアップする」など)。Command Line Interface (CLI) レベルで作業するのではなく。裏側で、システムが実際のデバイス固有の設定を導き出す。こうすることで、人は低レベルの詳細ではなく、達成しようとしていることに集中できる。
人とシステムが簡単にデータにアクセスできるようにする。自動化がデータを取得・更新できるよう Application Programming Interface (API)(Representational State Transfer (REST), GraphQL)が必要だ。人間が閲覧・編集できるよう Web UI と Command Line Interface (CLI) も必要だ。すべての人に対して、見るべきものだけが見えるアクセス制御が必要だ。数百の自動化ワークフローが同時に動き、数十のスタッフがデータを編集し、外部システムが同期していても、一貫性とパフォーマンスが保たれる必要がある。

05 - Execution

Sat, 01 Nov 2025 00:00:00 +0000

5. Execution#

Playbookは何カ月も完璧に動作していた。ラボの10台のアクセススイッチに対してエンドツーエンドで2分、毎回クリーンな結果。チームが800台のスイッチの全インベントリにロールアウトすることを決めたとき、誰も問題を予想しなかった。最初の600台のデバイスは問題なく更新された。そしてジョブが遅くなった。そして止まった。RADIUSサーバーが突然150件の同時SSH認証リクエストを受け取り、接続を拒否し始めた。Ansibleは150台のデバイスの実行途中でハングした。エンジニアがジョブを強制終了した。

次に来たのがより難しい問題だった。600台のデバイスのどれが更新されて、どの150台がそうでないか、誰にも分からなかった。実行状態が記録されていなかった。Playbookを再実行して、冪等性が助けてくれることを願った。その時は助かった。しかしこのインシデントは重要なことを明らかにした。実行レイヤーはラボ向けに設計されており、ネットワーク向けではなかった。速度、並列処理、エラー境界、状態追跡、何も考慮されていなかった。自動化は機能していた。実行アーキテクチャが機能していなかった。

多くの人はネットワーク自動化を「同じデータを使って、人間としてCLIに接続せずに、ネットワークで何かをする」と考える。ネットワーク自動化を始める多くの人がそこから始めると思う。そしてそれが Execution ブロックの行うことだ。しかし本書全体で見てきたように、ネットワーク自動化はこの最初のステップより大きく、Executionはアーキテクチャ内のひとつのコンポーネントに過ぎない。

Execution ブロックは最も危険な操作(設定変更や再起動など)のためにネットワークと直接やり取りする。だからこの章を飛ばさないこと。正しく行うことが重要だ。

この章では、このブロックが提供するゴールと柱、それを達成するために必要な内部機能について解説する。

5.1. 基本原則#

5.1.1. コンテキスト#

Executionはどのようにアクションを実行するかを定義する。何を行うかはIntentブロックから、いつ行うかはOrchestrationから来る。

初期のネットワーク自動化プロジェクトでは、特定のデバイスとインターフェース名に対してインターフェースをバウンスするスクリプトが最初の成果となることがある。その旅は、はるかに洗練されたシステムへと成長する可能性がある。

5.1.2. ゴール#

実行システムが実際に行うべきことは何か? 5つのことが重要だ。

適切なデータを準備する。 何かを実行する前に、何を実行するか(インテント)、どこで実行するか(どのデバイスに)、どのようにアクセスするか(認証情報、接続の詳細)を知る必要がある。これはSource of Truth(第4章で詳述)からインベントリを取得し意図された状態をフェッチすることを意味し、時には現在の状態を把握するためにオブザーバビリティデータをクエリすることも含む。この統合なしでは、実行エンジンはただ盲目的にコマンドを実行するだけだ。精神的健康のために、それは避けること。
今すぐでも後でも、必要なときに開始する。 即時の実行が必要なこともある。エンジニアが「デプロイ」をクリックして、すぐに実行されることを期待する。また、実行を待機させるべき場合もある。メンテナンスウィンドウ中にデプロイする、デバイスがオンラインになるまで待つ、オブザーバビリティからのイベントに反応する、などだ。システムは同期と非同期の両方のトリガーをサポートする必要がある。
時間の経過とともに状態を追跡する。 ネットワーク全体の操作は瞬時ではない。数時間かけて数百台のデバイスにデプロイすることがある。どのデバイスが成功したか? どれが失敗したか? どれがまだ保留中か? 状態管理はまた冪等性(同じタスクを2回実行しても同じ結果)、ロールバック(行ったことを元に戻す)、再開(失敗後に中断した場所から再開)を可能にする。状態追跡なしでは、すべての実行が一発勝負のギャンブルになる。
スケールで確実に実行する。 5台のデバイスで動くスクリプトは500台ではしばしば壊れる(または劣化する)。並列実行、エラー処理、リトライ、レート制限、ドライラン機能が必要だ。システムは部分的な失敗を適切に処理し、何が問題だったかを明確にフィードバックし、ネットワークを未定義の状態に放置しないこと。操作によって異なる戦略が必要だ。高速で並列なものもあれば、低速でシリアルなものもある。
あらゆるネットワークデバイスやプラットフォームで動作する。 ネットワークにはおそらくCisco、Arista、Juniper、クラウド Application Programming Interface (API)、Linuxボックス、ファイアウォール、ロードバランサーがある。それぞれが異なるプロトコルを使い、異なる操作パターンを持つ。実行レイヤーはそれらすべてへのアダプターが必要で、残りの自動化が違いを気にしなくてもよい共通インターフェースを持つ。

これらのゴールを念頭に置いて、実際に必要なアーキテクチャ機能は何か?

5.1.3. 柱#

各ゴールは特定の機能に対応する。

データ統合レイヤー。 実行エンジンは孤立して存在しない。Source of Truth(インベントリ、認証情報、インテント)、オブザーバビリティシステム(現在の状態、ヘルスメトリクス)、そして潜在的に他のシステム(チケット、変更管理、承認ワークフロー)へのプログラム的なアクセスが必要だ。これは Application Programming Interface (API) クライアントの実装、認証の安全な処理、データの適切なキャッシング、実行開始前に必要なものがすべて揃っているかの検証を意味する。

Preface

Mon, 01 Jan 0001 00:00:00 +0000

06 - オブザーバビリティ

Mon, 01 Jan 0001 00:00:00 +0000

6. オブザーバビリティ#

あるサービスプロバイダーのコアルーターで、ファンモジュールが夜間に無音で故障した。アラートは何も発生しなかった。ラインカード上の熱管理サブシステムが温度上昇を検知し、ハードウェアを保護するためにフォワーディングASICのスロットリングを開始した。本番トランジットリンクのスループットが40%低下した。監視システムは何も捉えなかった。ポーリングしていた温度センサーはシャーシスーパーバイザー上のものであり、個々のラインカード上のものではなかったのだ。SNMPポーリングは5分おきに実行されており、デバイスは正常と報告されていた。インターフェースカウンターはスループット低下を示していたが、そのリンクはずっと容量に余裕があったため、そのパターンに対するしきい値が設定されていなかった。

3時間後、顧客SLA違反がチケットを生成した。オンコールエンジニアがルーターにSSHし、ローカルアラームログでファンの故障を発見し、ファンモジュールを再起動した。ファンコントローラーが再起動し、熱スロットリングは数分で解除された。トラフィックは回復した。SLA違反が文書化され、顧客に通知され、インシデントはクローズされた。

根本原因は最後まで確認されなかった。調査が始まるころにはルーターは何時間も正常稼働していた。ラインカードの温度データもスロットリングイベントの記録もなく、どの監視システムにもスループット低下とファン故障を関連付ける手段がなかった。インシデントレポートの結論は「ハードウェア問題と推測、ハードウェアリセットで解決」だった。6ヶ月後、別のルーターで同じ事象が起きた。

この失敗はしきい値の欠如ではなかった。チームには数千ものしきい値があった。失敗は対象範囲の不完全さにあった。監視システムは従来からポーリングしていたソースからデータを収集していたが、デバイスの動作に影響しうるすべてのソースからは収集していなかった。3種類のシャーシすべてでgNMI経由のラインカード温度データは利用可能だった。ファン故障のためのランブックを誰も書いていなかったから、誰もその収集パスを設定しなかったのだ。

従来のネットワーク監視は壊れているものを監視する。インターフェースは上がっているか？CPUは90%を超えているか？このサービスは応答しているか？それは有用だが、リアクティブだ。障害を待ち受けているだけである。

オブザーバビリティは異なる。なぜ壊れているのか、あるいは壊れかけているのかを理解することだ。「あのデバイスがダウンしている」ではなく「なぜダウンしているのか、何がそれで壊れているのか、ビジネスへの影響は何か」という問いに答える。ネットワーク自動化において、オブザーバビリティはフィードバックループになる。何かを観察し、システムがそれを検知し、対応を決定し、アクションを実行し、修正が機能したことを検証する。このサイクルが繰り返されることが「クローズドループ自動化」だ。

本章では、ネットワークで起きていることを把握するために必要なすべてをカバーする。どのデータを収集するか、どうやって収集するか、どう保存するか、どうアラートを出すか、そして意思決定に本当に役立つ形で人々に見せる方法を説明する。

従来のオールインワンプラットフォーム（SolarWinds、LibreNMS）、クラウドサービス（Datadog、New Relic）、オープンソースのピースから自前で構築するスタック（Prometheus、Grafanaなど）のいずれを使う場合でも、基本的なアーキテクチャは同じだ。これらのパターンを理解することで、自分のスケールとチームに合ったアプローチを選択できる。

注記: このセクションでは、例示のためにさまざまなベンダーやソリューションに言及している。これは推薦ではなく、あくまで説明目的である。

6.1. 基礎#

低レベルの詳細に入る前に、ネットワーク自動化戦略の中におけるネットワークオブザーバビリティの基礎を確立し、そのゴール、支持する柱、およびスコープを定義する。

6.1.1. コンテキスト#

おそらく、すでにネットワークを監視しているだろう。Simple Network Management Protocol (SNMP)を使い、System Logging Protocol (Syslog)を見て、リンク使用率を示すダッシュボードを持っている。それが監視だ。物事が機能しているかを教えてくれる。

07 - オーケストレーション

Mon, 01 Jan 0001 00:00:00 +0000

7. オーケストレーション#

ネットワークチームはすべてを正しく行っていた。堅固な信頼できる情報源（SoT）があり、すべての操作に対してテスト済みのPlaybookがあり、それらを実行するための明確なランブックがあった。書類上では、新しいVLANサービスのデプロイは完全に自動化されていた。実際には、半日と特定のエンジニア一人が必要だった。

そのエンジニアはシーケンスを知っていた。まず、SoTデータが完全であることを検証する。次に事前チェックPlaybookを実行する。次に出力を確認し、失敗したデバイスを探し、続行するかどうかを決める。次にデプロイメントPlaybookをトリガーする。次に待つ。次に検証Playbookを実行する。次にServiceNowチケットを手動で更新する。途中でデバイスが失敗した場合は、他のデバイスが気づく前にロールバックする。彼女はそれをすべて、誰も完全に内面化していない共有ドキュメントのランブックにステップごとに持っていた。

彼女が休暇に入ると、デプロイメントが止まった。ジュニアエンジニアがシーケンスを試みて順序を間違えると、ネットワークは6時間部分的な状態のままだった。自動化は存在していた。調整は依然として手動だった。

それがこの章が解決する問題だ。オーケストレーションは、自動化ツールのコレクションを一体として動作するシステムに変えるビルディングブロックだ。他のブロックを調整し、いつ実行するかを決定し、障害を優雅に処理し、すべての決定を追跡し、エンジニアが手でフローを管理しながら中間に立つことなくこれらすべてを行う。

7.1. 基礎#

7.1.1. コンテキスト#

これまでカバーしてきたすべてのビルディングブロックはそれぞれ1つのことを得意とする。SoTはインテントを保持する。Executorはそれを適用する。コレクターは状態を取得する。オブザーバビリティはその状態を理解する。それぞれは専門家であり、専門家にはコネクターが必要だ: 各ブロックがいつ行動すべきかを決め、結果をどう処理するかを決め、何かがうまくいかないときにどう回復するかを決めるもの。

そのコネクターがOrchestratorだ。

第3章では、他のすべてを調整するブロックとしてNAFフレームワークの中心に置いた。第5章はExecutorが設定変更をどう適用するかを示した。第6章はオブザーバビリティが結果をどう検証するかを示した。本章ではオーケストレーターが両方をどう順序付けし、その間で起こりうるすべての問題をどう処理するかを示す。

オーケストレーションなしには、自動化を実行していない。誰かが正しい順序で、正しいタイミングで、正しい方法で解釈して呼び出さなければならないスクリプトを実行しているだけだ。それは名ばかりの自動化だ。

7.1.2. ゴール#

オーケストレーターは5つのゴールを達成する必要がある:

マルチブロックワークフローをエンドツーエンドで調整する。 デプロイメントは単一のアクションではなく、シーケンスだ。SoTのインテントを検証し、事前チェックを実行し、設定を実行し、結果を検証し、ステークホルダーに通知する。オーケストレーターがフルシーケンスをまとめて保持する。
人間の開始の有無にかかわらず、自動的にイベントに反応する。 ServiceNowの承認、オブザーバビリティのアラート、スケジュールされたコンプライアンスのスキャン: これらはすべて人間が手動で開始しなくてもワークフローをトリガーできる必要がある。
耐障害性とスケーラブルな実行。 800のスイッチを並列で操作するワークフローは確実に完了しなければならない。再起動を生き延びなければならない。成功したデバイスの作業を失うことなく部分的な障害を処理しなければならない。
改ざん防止の可視性を提供する。 オペレーターは今何が実行されているかを見る必要がある。監査員は先月何が実行されたか、誰がトリガーしたか、どのバージョンのワークフローが実行されたか、すべてのステップが何を生成したかを見る必要がある。両方のニーズが同じシステムから満たされなければならない。
ワークフロー定義を本番ソフトウェアとして管理する。 800のスイッチにデプロイするワークフローは不用意に変更できない。ロジック自体が、本番で動作する他のコードに適用されるのと同じ規律で永続化、バージョン管理、テスト、本番へのプロモーションが必要だ。

7.1.3. 柱#

5つの柱がこれらのゴールを支える:

ワークフローエンジン: 多段階プロセスの定義、実行、追跡
トリガーレイヤー: 手動、スケジュール、イベント駆動、Webhook
耐障害性実行: ワークフローが再起動を生き延びる。数百のデバイスにわたってデバイスごとのボトルネックなしにリトライ、ロールバック、並列操作をサポートする
監査とオブザーバビリティ: すべてのステップをログに記録し、すべての決定を追跡可能にする
パイプライン管理: ワークフロー定義を本番で安全に永続化、バージョン管理、プロモーションする

7.1.4. スコープ#

オーケストレーターは調整する。行動しない。

スコープ内:

他のビルディングブロックの調整
ワークフローロジックとステップ依存関係の定義
複数のソースからのトリガー処理
実行状態の追跡と監査証跡の生成
ステップが失敗したときのロールバック決定の管理

スコープ外:

08 - プレゼンテーション

Mon, 01 Jan 0001 00:00:00 +0000

8. プレゼンテーションレイヤー#

VLAN自動化は6週間稼働していた。ネットワークチームはそれを誇りにしていた。毎朝、アプリケーションチームから3〜4件の新しいサービスリクエストが届き、ネットワークチームの誰もキーボードに触れることなくオーケストレーターが処理した。デプロイメントは機能した。スイッチは設定された。ネットワークは健全だった。

エスカレーションは木曜日に届いた。アプリケーションチームのリードが、ポータルで「提出済み」と表示されているのにVLANリクエストが3〜5営業日かかる理由を尋ねていた。ネットワークチームはキューを確認した: 保留中のリクエストはゼロで、すべてのデプロイメントは成功していた。自動化は受信から20分以内にすべてのリクエストを処理していた。しかし、ServiceNowチケットはまだ「進行中」と表示されていた。チケットを更新する統合を誰も書いていなかったからだ。

自動化は仕事をしていた。結果が見えなかっただけだ。

1週間後、チームはアプリケーションチームがリクエストを直接提出してステータスを確認できるクイックなセルフサービスポータルをデプロイした。正午までに1時間で47件のVLANリクエストを受け取った。すべて有効だった。すべて正しくフォーマットされていた。問題は、ポータルに認証モデルがなかったことだ。URLを持っている誰からでも提出を受け付けた。すべてのリクエストはプラットフォーム全体の管理者権限を持つ単一のAPIトークン下で実行された。レート制限もなく、承認ゲートもなく、誰が何を提出したかの監査証跡もなかった。

自動化は機能した。アクセスモデルが機能しなかった。

これら2つの失敗はどちらもプレゼンテーションの失敗だ。1つはフィードバックループの欠如で、もう1つはガードレールの欠如だ。本章はそのギャップを埋める。

8.1. 基礎#

8.1.1. コンテキスト#

これまでカバーしてきたすべてのビルディングブロックは内側を向いている: 他のブロックに向けて、またはプラットフォームを構築して運用するエンジニアに向けて。Source of Truth (SoT)は自動化システムのためにネットワークインテントを保持する。ExecutorはデバイスにChangesを適用する。Observabilityは結果を検証する。Orchestratorはそれらすべてを調整する。これらのブロックそれぞれにUIとAPIまたはその両方があり、プラットフォームを構築して運用する人々のために設計されており、それとやり取りする必要があるすべての人のためではない。

09 - ネットワーク

Mon, 01 Jan 0001 00:00:00 +0000

9. ネットワーク#

VLANの自動化はラボで3週間稼働していた。3台のスイッチ、ベンダーごとに1台ずつ、すべてのワークフローが通過した。チームは自信を持っていた。最初の本番実行で、800台のキャンパススイッチのうち23台が失敗した。すべてHPEだった。すべて、誰もドキュメント化していなかったファームウェアバージョンを実行していた。

PlaybookはVLAN設定をプッシュした後、各デバイスからのエラーレスポンスを確認していた。モダンなHPEファームウェアでは、すでに存在するVLANはエラーコードduplicate-vlanを返す。この古いファームウェアバージョンでは、同じ条件がvlan-existsを返した。Playbookはduplicate-vlanをべき等シグナルとして扱うように書かれていた。つまり「これはすでに存在している、問題ない」という意味だ。vlan-existsを処理するようには書かれていなかったので、そのレスポンスを失敗として扱った。HPEフリートの3分の1が失敗を報告した。ロールバックはクリーンに実行された。ネットワークチームが実際に設定されたスイッチとそうでないスイッチを手動で監査する間、アプリケーションチームのチケットはさらに3時間オープンのままだった。

自動化は間違っていなかった。ネットワークに、誰もドキュメント化していなかった意見があったのだ。

6ヶ月後、同じチームはBuilding Bを反映したcontainerlabトポロジーを持っていた: 24台のスイッチ、一致するベンダーイメージ、HPEノードはSource of Truth (SoT)に記録された本番ファームウェアバージョンにロックされていた。そのトポロジーに対するVLANワークフローの最初のテスト実行で、8台のHPEノードがまさにそのエラーコードで失敗した。チームはHPEアダプターのべき等レスポンスのリストにvlan-existsを追加した。再実行: 24台のノードすべてが通過した。本番デプロイメント: 800台のスイッチ、ゼロの失敗。

違いは良いコードではなかった。現実を反映したテスト環境だった。

本章ではパート2を通じて常に暗黙的だったブロックを扱う: ネットワーク自体だ。これまで構築してきたすべてのビルディングブロックは自動化チームによって設計され、ドキュメント化されたインターフェースに従って動作する。ネットワークは受け継いだものだ。それには癖があり、多様なインターフェースがあり、ファームウェアの不整合があり、ベンダー、プラットフォーム、ソフトウェアの世代によって異なる機能がある。第9章は2つの問いを扱う: 自動化を確実にするためにネットワークに何が必要か、そして本番に触れる前に自動化ロジックをどう安全に検証するか？

9.1. 基礎#

9.1.1. コンテキスト#

第3章では、NAF Frameworkの7つのブロックの1つとしてネットワークを導入した: 自動化チームが「所有」しない唯一のブロック（ネットワークエンジニアリングのスコープにある）。彼らはそれを設定し、観察し、そのインテントをモデル化するが、オペレーティングシステム、データモデル、またはAPIインターフェースは構築しなかった。その依存関係は、その上のプラットフォームのすべての設計決定を形作る。

10 - プラットフォームエンジニアリングとCI/CD

Mon, 01 Jan 0001 00:00:00 +0000

11 - スケールと信頼性

Mon, 01 Jan 0001 00:00:00 +0000

12 - セキュリティ、ガバナンス、コンプライアンス

Mon, 01 Jan 0001 00:00:00 +0000

13 - 文化的変革

Sun, 19 Apr 2026 00:00:00 +0000

13. 文化的変革#

会議の招待メールが木曜日に届いた。件名は「ネットワークチーム体制の更新」だった。ジョルディはネットワークエンジニアとして15年のキャリアを積んでいた。CCIEを取得し、3度の買収、2度のNOC統合、そして社内のケーススタディとなるほど深刻なBGPルーティングインシデントを生き抜いてきた。彼はこれが人員に関する連絡だと思っていた。

違った。

マネージャーが説明したのは、ネットワークチームがプラットフォームエンジニアリング部門の下に再編されるということだった。チーム名は「ネットワーク自動化プラットフォーム」に変わる。仕事の内容も変わる。手動プロビジョニングは減り、プロビジョニングを担う自動化システムを構築・運用することが中心になる。新しい職務記述書はすでに書かれていた。タイトルは「ネットワークプラットフォームエンジニア」だった。

その夜、ジョルディは家に帰って職名を検索した。結果のほとんどはクラウドの求人やコンテナオーケストレーションインフラを指していた。1時間読んで、内容の半分くらいは理解できた。Pythonスクリプトを書いたことはなかった。Gitが実際に何なのか知らなかった。興奮すべきか恐怖を感じるべきか、判断がつかなかった。

その年の終わりには、ジョルディは2つの自動化ワークフローを本番環境にリリースし、ルーターを一度も設定したことのないソフトウェアエンジニアが書いた数百行のコードをレビューし、チーム初のアーキテクチャ決定記録を書いていた。彼はソフトウェア開発者ではなかった。彼は分類が難しく、もっと価値のある何かになっていた。ネットワークと、それを運用するシステムの両方を理解するエンジニアだ。

この章はその変革について書かれている。ジョルディ個人の変革だけでなく、組織全体の変革についてだ。第1章から第12章で扱った技術は、それ自体では動かない。ネットワークエンジニアリングが伝統的に育ててきたものとは異なるスキル、役割、協働の仕方を持つ人々が必要だ。技術を正しく実装することは難しい。組織の変革を正しく進めることはさらに難しく、自動化の取り組みが失敗するのも、多くの場合そこにある。

13.1 アイデンティティの危機#

文化的変革で最も難しいのは、Gitを覚えることではない。長年の深いCommand Line Interface (CLI)習熟によって築き上げたアイデンティティを手放すことだ。

ネットワークエンジニアリングは、習得が難しく偽れない専門性を中心に職業文化を形成してきた。障害時のBGP収束の挙動を理解すること。深夜2時にスパニングツリーのトポロジー変更をデバッグすること（そしてスパニングツリーは今でも現役だ）。アプリケーションチームがチケットを起票し終わる前に、パケットキャプチャを読み取ってわずかなMTUの不一致を特定すること。これらは年月をかけて培った高度なスキルであり、強いプロフェッショナルとしてのアイデンティティを生み出してきた。

自動化はその専門性の表面を揺るがす。よく設計された自動化プラットフォームがVLANプロビジョニング、設定ハードニング、ゼロタッチデバイスオンボーディングを処理するようになると、それらのタスクを手作業のCLIで長年習熟したエンジニアは、矛盾のように感じる選択を迫られる。自動化を使って自分が得意なことを置き換えるか、自分を定義するスキルを守るために自動化に抵抗するかだ。

これが**クラフツマンのジレンマ (Craftsman’s Dilemma)**だ。ある技術に深く習熟しているほど、その技術を隠す抽象化は道具ではなく脅威に感じられる。ベンダー固有のCLIの細部をすべて知っているネットワークエンジニアが抽象化レイヤーに抵抗するのは非合理ではない。完全に合理的な判断だ。専門性を馴染みのないものと交換するよう求められているのだから。

このジレンマを解く視点の転換がある。自動化は深いネットワーク知識を置き換えない。それを必要とするのだ。違いは、その知識がどこでどのように活かされるかだ。BGP収束を深く理解するエンジニアは、自動化された世界でも劣らない価値を持つ。信頼性の高いBGP閉ループ自動化を設計できる唯一の人物だからだ。スキルは実行から設計へ、コマンドの入力からどのコマンドをどの条件で実行すべきかを定義することへと移る。

「ネットワークを設定する」から「ネットワークを設定するシステムを構築する」へのこの転換こそ、この章の核心にある文化的変革だ。スキルのギャップではない。認識のギャップだ。

flowchart LR
 classDef legacy fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
 classDef emerging fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

 A["**ネットワークエンジニア** - 設定を実行する - 深いデバイス専門知識"]
 B["**ネットワークプラットフォームエンジニア** - 自動化システムを設計する - コードに埋め込まれた専門知識"]

 A -->|"認識の転換"| B

 class A legacy
 class B emerging

この移行を成功させるエンジニアは、ソフトウェア開発者になろうと決意した人ではない。特定のベンダーのエッジケースで自動化が失敗し続ける理由を知りたいと思い、症状の裏にあるシステムを理解するまでその問いに向き合い続けた人だ。設定する方法だけでなく、インテントからデバイスへ設定がどのように伝わるか、障害がどう伝播するか、システムがどう回復するかを知りたいという好奇心こそが、この移行を可能にするマインドセットだ。それはまた、自動化以前の優れたネットワークエンジニアを際立たせていたマインドセットでもある。レシピを適用するだけでなく、プロトコルを理解したいと思う人たちのものだ。

その好奇心の報酬は、個人が手作業で到達できる規模を超えた影響力だ。800台のスイッチを対象に正しく動作する単一の自動化ワークフローは、チームが1週間の手動変更ウィンドウで完了できる以上の仕事を数分でこなす。そのワークフローを構築したエンジニアはそれに置き換えられていない。その人の専門知識が、眠っている間も動き、定型作業を確実にこなし、判断を要する問題のためにエンジニアリングの余力を生み出すシステムに埋め込まれたのだ。手作業のCLI習熟がどれだけ積み上がっても生み出せない、より強力な立場だ。

ネットワーク自動化はプロビジョニングを加速するだけではない。それを構築したエンジニアの知識を記録する。10分で書いたBGPセッションチェックには15年の運用経験が込められている。そのチェックは、作者がオンコール中であれ、休暇中であれ、すでに退職していても正しく動作する。自動化はエンジニアを引き留めない。エンジニアが知っていることを引き留める。この違いは、シニアエンジニアがチームを離れるたびに、どれほどの組織の知恵が失われたかを考えるときに重要になる。

第1章では、自動化の障壁として変化への恐れと誤ったスキルが挙げられていた。これらの障壁は、マネージャーがチームを再編したからといって消えるわけではない。役割の定義、スキルの育成、そして深いネットワーク専門知識が新しいモデルでより価値があることを組織が示す方法として、意図的な取り組みが必要だ。

14 - プロダクトとしての自動化

Tue, 05 May 2026 00:00:00 +0000

14. プロダクトとしての自動化#

チームの仕事に対する考え方を変えることになったその会話の6ヶ月前、ネットワークプラットフォームチームは本当に印象的な成果を上げていた。2年間の継続的な努力により、ブランチのオンボーディングをエンドツーエンドで処理するプロビジョニングプラットフォームが完成していた。サイトリクエスト用のセルフサービスインターフェース、デプロイ前に設定ミスを検出するクローズドループ検証ワークフロー、そして300拠点全体のサービス健全性を追跡する運用ダッシュボードが揃っていた。チームは24時間の変更ウィンドウから40分の自動デプロイへと進化させた。彼らはそれを誇りに思っていたし、誇りに思うべきだった。

そこへ事業開発チームが小売チェーンの買収を完了させた。120の新規店舗が6ヶ月以内にネットワーク接続を必要としていた。インフラ担当リードがシンプルなメールを送ってきた。「この件は自動化プラットフォームを頼りにしている。どうすれば開始できるか？」

ネットワークプラットフォームチームの最初の内部反応は自信に満ちていた。これは自動化できる。ワークフローがある。テンプレートがある。ツールは実績がある。

しかし、メールに返信しようとしたときの2回目の反応は自信を欠いていた。インフラ担当リードは自動化が技術的に可能かどうかを聞いているのではなかった。彼らは別の質問をしていた。店舗オンボーディングのSLAとは何か、つまりサイト情報が提出されてから店舗が接続を受けるまでのコミットメントは何か？デプロイが途中で失敗した場合のエスカレーションパスは誰か？インフラ担当リードのチームが、ネットワークチームに直接尋ねることなく監視できるステータスページやダッシュボードはあるか？プラットフォームのキャパシティはどうか、20件の同時デプロイを処理できるか、それともリクエストをバッチ処理する必要があるか？そして最も不快な質問：プラットフォームインシデント中にオンボードされた店舗はどうなるか、自動的に修復されるか、それとも誰かが各店舗を監査する必要があるか？

ネットワークチームには自動化があった。しかし答え（ビジネス/プロダクトの観点での）がなかった。

このギャップ、つまり「動く自動化を構築した」と「他のチームが依存して計画を立てられるサービスを提供する」との間の差が、本章のテーマである。

14.1 ケイパビリティからプロダクトへ#

第13章では、チームが自動化を組織的ケイパビリティとして構築するために、人材、役割、仕事の進め方をどのように変革するかを説明した。その変革は必要だ。しかしそれだけでは不十分だ。

ケイパビリティとはチームができることだ。プロダクトとは、他のチーム（またはいずれはサードパーティのエンティティ）が依存できるものだ。その違いは技術的な品質についてではない。小売チェーンオンボーディングプラットフォームは技術的に優秀だった。違いは、プロバイダーとコンシューマーの関係にある。ケイパビリティはその作者のために存在する。プロダクトはそのユーザーのために存在する。

ネットワークチームのアウトプットは変化した。自動化以前のアウトプットはデバイス設定だった。プロビジョニングされたルーター、拡張されたVLAN、適用されたACL。そのアウトプットのコンシューマーはデバイス自身であり、成功の証拠はpingが通ることや、アプリケーションが動作することだった。自動化によってアウトプットは変わる。ネットワークチームのプロダクトは、他のチームが消費するネットワークサービスになる。ネットワークとのすべてのインタラクション、ブランチサイトのプロビジョニング、新しいアプリケーション向けのセグメント拡張、セキュリティポリシーの適用、VLANへの会議用アクセスの一時付与、インターネットエクスチェンジでのピアリング接続の追加、これらはすべて変更チケットではなくサービスリクエストになる。デバイス設定は実装の詳細だ。サービスがアーティファクトだ。

これが**ネットワークサービスをプロダクトとして (Network Service as Product)**パターンだ。サービスがプライマリのアーティファクトであり、下層のネットワークは実装だ。これはソフトウェアエンジニアリングでは新しくない。APIはインフラを抽象化し、呼び出し元はどのサーバーがリクエストを処理するかを知らないし、気にしない。しかし、これは歴史的にデバイス、ベンダー、プロトコルを中心に仕事を整理してきたネットワークチームにとっては大きな転換だ。ルーター設定スキルにアイデンティティを定義してきたエンジニアが、今やサービスデリバリーケイパビリティにアイデンティティを定義するよう求められている。このリフレームは第13章セクション13.1の職人のジレンマに直結する。古いクラフトの専門家こそが、最も急いでリフレームを行う必要がある人物であり、それを完全に実行するエンジニアはより価値が下がるのではなく、より価値が上がる。

このプロダクトの技術的な拠点は、第8章で説明したプレゼンテーションブロックだ。セルフサービスインターフェース、APIサーフェス、Webhook統合、ロールベースのアクセスモデル、これらはサービス契約がコンシューマーに見える場所だ。第14章では、技術的なインターフェースを超えて、それを取り巻く組織的・ビジネスモデルにズームアウトする。インターフェースにはどんなコミットメントが伴うか？壊れたときは誰が所有するか？サービスはどのように進化するか？次に何をするかは誰が決めるか？

14.2 プロダクトの定義#

ネットワーク自動化をサービスに変えようとするチームに一貫して現れる2つの失敗モードがある。

1つ目は過剰露出だ。インターフェースが実装の詳細を露出させ、コンシューマーがそれを使うためにネットワークの内部を理解しなければならない。VLAN ID、サブネットマスク、OSPFエリア番号を要求するブランチプロビジョニングサービスはサービスではない。ウェブフォームを持つCLIだ。小売チェーンの設備コーディネーターは、OSPFエリアが何であるかを知らないし、知る必要もない。

2つ目は過剰制限だ。インターフェースがネットワークチームが想定した正確なユースケースしか処理できないほど制約されている。テンプレートから逸脱したリクエストには例外プロセスが必要だ。恒久的な小売拠点とは異なる接続要件を持つ期間限定のポップアップストアをプロビジョニングする必要がある設備コーディネーターは、セルフサービスできない。チケットを提出する。チケットはネットワークチームに届く。自動化のメリットがそのコンシューマーに届いていない。

**サービス契約パターン (Service Contract Pattern)**は、インターフェース定義を明示的、バージョン管理済み、意図的に境界設定することで、両方の失敗モードを解決する。サービス契約には3つのコンポーネントがある。

インプットサーフェス: コンシューマーが提供するもの。ネットワーク用語ではなくビジネス用語で表現される（申し訳ないが、これは重要なことだ）。ブランチサイトリクエストは、ロケーション名、物理的な住所、サイト階層（標準、スモール、ポップアップ）、および有効化日を受け取る。VLAN IDは受け取らない。この契約はビジネスの意図をネットワークの実装に内部で変換し、その変換が自動化プラットフォームの責任だ。階層の定義は永続的ではない。一時的な小売キオスク向けに定義されたポップアップ階層は、異なる接続要件を持つポップアップイベントスペースには対応しない。インプットサーフェスは、コンシューマーチームと同じケイデンスでロードマップとともにレビューされなければならない。そうすることで、階層が最初に契約が書かれたときにネットワークチームが想定したユースケースではなく、実際のユースケースを反映するようになる。
アウトプットサーフェス: コンシューマーが観察するもの。成功した完了と失敗の両方を含む。適切に設計されたアウトプットサーフェスは「ステップ14のうち7番目でデプロイ失敗：gNMIプッシュがエラーコード400で拒否されました」を露出させない。「有効化失敗：このアドレスの物理回線がまだキャリアによってプロビジョニングされていません。予想完了日：[SoTからの日付]。あなた側のアクションは不要です。回線がオンラインになったときにシステムが自動的に再試行します」を露出させる。自動化は単に成功や失敗するだけでなく、コンシューマーが理解できる用語でオブザーバブルなライフサイクルイベントを発行する。
内部依存関係: サービスが内部で追跡するもの。コンシューマーには見せないが、チームは管理しなければならない。キャリアからの回線状態。このサービスとインフラを共有している隣接サービス。新しいサイトのSoTレコードと自動監視を駆動するインベントリレコードとの整合関係。回線がキャリアメンテナンスに入ったとき、ネットワークチームはどのサービスが影響を受けるか、それがどんなSLO露出を生み出すかを知る必要がある。コンシューマーはサービスへの影響を知る必要があるかもしれないが、それを引き起こした実装の詳細を知る必要はない。

flowchart LR
 classDef consumer fill:#d9e8f5,stroke:#4a7fa5,color:#1a2e3b
 classDef contract fill:#f5e8d9,stroke:#a57a4a,color:#1a2e3b
 classDef internal fill:#d9f5e8,stroke:#3a8a5a,color:#1a2e3b

 subgraph Consumer["コンシューマーインターフェース"]
 IN["インプットサーフェス<br/>ロケーション、階層、日付<br/>ビジネスの意図"]
 OUT["アウトプットサーフェス<br/>ステータス、ライフサイクルイベント<br/>ビジネス言語"]
 end

 subgraph Contract["サービス契約"]
 TRANS["変換レイヤー<br/>意図から実装へ<br/>VLAN、サブネット、OSPFエリア"]
 end

 subgraph Internal["内部依存関係"]
 CIRC["回線状態"]
 SOT["SoT整合性"]
 NEIGHBOR["隣接サービス"]
 end

 IN --> TRANS
 TRANS --> OUT
 TRANS --> CIRC & SOT & NEIGHBOR
 CIRC & SOT & NEIGHBOR -.-> OUT

 class IN,OUT consumer
 class TRANS contract
 class CIRC,SOT,NEIGHBOR internal

サービス契約が定義されたら、次の問いはそれが時間とともにどうなるかだ。

15 - 閉ループ自動化

Mon, 01 Jan 0001 00:00:00 +0000

16 - 自己修復ネットワーク

Mon, 01 Jan 0001 00:00:00 +0000

17 - 自律ネットワーク

Mon, 01 Jan 0001 00:00:00 +0000

著者について

Sun, 10 May 2026 00:00:00 +0000

Christian Adell について#

CoreWeave スタッフネットワークデベロッパー | スペイン、バルセロナ

Christian Adell は、ネットワーク自動化に応用されたソフトウェア開発を中心にキャリアを築いてきました。大規模なネットワーク自動化ソリューションの設計・実装において豊富な経験を持ちます。

📞 連絡先#

GitHub: chadell
LinkedIn: christianadell
Twitter: @chadell0

📖 出版書籍#

Christian は、ネットワーク自動化に関する複数の影響力ある書籍の著者・共著者です：

Network Programmability and Automation, 第2版

Network Automation with Nautobot

Modern Network Observability

Network Automation Cookbook, 第2版

🎤 講演・コミュニティ活動#

Christian は主要なネットワーキング会議やコミュニティイベントで積極的に講演を行っています：

法的事項

Sun, 10 May 2026 00:00:00 +0000

法的事項#

著作権表示#

本サイトのコンテンツ（テキスト、図、例を含む）は、著者の知的財産であり、クリエイティブ・コモンズ表示-非営利-改変禁止 4.0 国際ライセンス (CC BY-NC-ND 4.0) のもとで提供されています。

以下のことが自由にできます

共有 — 適切なクレジットを表示した上で、あらゆる媒体・形式で素材を複製・再配布すること

以下の条件に従う必要があります：

表示 — Christian Adell Querol のクレジットを適切に表示し、ライセンスへのリンクを提供し、変更を加えた場合はその旨を示すこと。
非営利 — 素材を商業目的で使用しないこと。
改変禁止 — 素材をリミックス・変形・加工して配布しないこと。

重要事項

翻訳には著作権者の事前書面による許可が必要です
商業利用には別途ライセンス契約が必要です
二次的著作物は明示的な許可なしに作成できません

本ライセンスの範囲を超える許可については、chadellgmailcom までご連絡ください。

謝辞#

本書は、惜しみなく時間と専門知識を提供してくださった多くの方々の貢献によって豊かになっています。

レビュー

（準備中）

翻訳

本書は複数の言語で提供されています。すべての翻訳は、AI 支援ツールを使用して初稿を作成し、その後、ネットワークエンジニアリングの知識を持つ母語話者の協力者によって校閲されました。彼らの作業により、技術的な内容の正確性と、各読者にとって自然な言語表現が確保されています。

言語	校閲者
Español	Christian Adell
Русский	Artem Kovalchuk, Mikhail Garin
Català	Christian Adell
Français
中文	Yujia Gao, Lancheng
Deutsch
Português
Italiano
日本語
한국어
العربية
हिंदी
Ελληνικά

翻訳のレビューや修正に貢献したい方は、chadellgmailcom までご連絡ください。