はじめに
エンジニアというのは、5分で終わる単純作業を、2時間かけて自動化するスクリプトを書いてしまいがちな生き物である。
「次からは一瞬で終わるはず」という未来への投資のつもりで、実際にはその"次"が来ないまま終わる、というのは誰もが一度は通る道だと思います。
この記事は、自分がまさにそれをやらかしたうえで、さらに一歩奥の「そもそも自動化が効く場所じゃなかった」というところまで踏み込んでしまった話です。
記事執筆のタスクをアサインされ、ネタに悩んでいた頃、参加していた JAWS DAYS NOCで「撤収時の設定削除にAnsibleを使う」という話が出てきました。
そこから思いついたネタが「Ansible でネットワーク機器を自動化してみる」でした。
去年の秋ごろ、200ユーザー規模のイベントネットワーク(NOC)をワンオペで構築したことがありました。
Cisco ISR1100、NEC IX3315、IKEv2/IPsec、複数VLAN、QoS、etc、手動でコンフィグを投入しました。
「これをAnsibleで自動化したらどれだけ楽になるか」というテーマなら、過去のつらさを引き合いに出しつつ前向きにまとめられそうだな、と思いました。
狙いとしては「Ansibleで省力化やってみた、便利!」系の記事を想定していました。
そう思って Cisco ISR1100 のロールを VLAN / ACL / QoS / IKEv2 / BGP と書き始めました。
書いていく中で、ある違和感がだんだん大きくなっていきます。
「これ、自動化が効く場所じゃないのでは?」
その違和感が固まりつつあるタイミングで、別件の構築案件が舞い込んできました(後日譚で詳述する Build with AI in Kwansai 2026 の NOC がそれです)。
リソースを2つに割けないのでこのAnsibleプロジェクトはcloseすることになり、結果として今この文章を書いています。
つまりこの記事は、自動化を礼賛する記事を書くつもりだったのに、書けば書くほど"これは機械に渡すべき作業ではなかった"という結論に近づいていった話です。
当初想定していた前向きな記事とは正反対のものになりましたが、その方が自分にとっても次の判断の役に立ちそうなので、忘れないうちに残しておきます。
自動化は正義だけど、やる場所を選ばないと冪等性の請求書だけが届く、という話です。
作ったもの
ターゲットは、過去にワンオペ構築で使ったCisco ISR1100です。
当初は同じ構成で入れていたNEC IX3315も自動化対象にする予定でしたが、
- IX3315はBGP on IKEv2/IPsecとNAPTにしか使っていない
- Ansibleプラグインが貧弱で、改善するコストの方が手動の負担より重い
という理由で途中でAnsible管理対象から外し、cisco.ios.* モジュールが充実しているISR1100に集中することにしました。
「自動化記事を書く」というお題に対してすら、最初の路線変更はもう"自動化の縮小"の方向だった、というのは後から見ると示唆的です。
ISR1100 に対しては以下のロールを書きました。
- VLAN設定
- ACL設定
- QoS (MQC)
- IKEv2 / IPsec
- BGP
物理〜L3までを Playbook で叩けるようにして、ネットワーク全体のフロー図(Mermaid)も書きました。
一式そろえれば、イベント当日に Playbook を流すだけで上から下まで構成が入る、という絵を描いていたわけです。
ちなみに副産物として、NECのWebマニュアルが廃止されPDFのみになっていた問題に対応するため、PDFからOCRでテキストを抽出するGoスクリプトも書きました(章番号・ページ番号・段組みのノイズを取るために上下クロップ＋画像2分割アプローチを採用)。
コーディングエージェントにIX3315のマニュアルを渡すための準備で、これは普通に役に立ちました。
自動化の本命は不発でも、周辺で生まれた小道具は別の文脈で生き残ることがある — このあたりは記録しておきたいところです。
その１: 冪等性の請求書だけ届く
Ansibleの一番おいしい所は冪等性です。
何度流しても同じ状態に収束する、ドリフトを検知して直せる、構成をコードで管理できる。
だからこそ運用フェーズで効いてきます。
でもイベントNOC構築は違います。
- 機材は会場に持ち込んで設営する
- イベントが終わったら撤収する
- 次のイベントは別の会場で別の機材
- Playbookを「再度流す」タイミングが、来ない
つまりPlaybookを書くコスト(冪等性を担保するコスト)は払っているのに、それを回収する"2回目"が永遠に来ない。
ワンショットの構築で冪等性に金を払うのは、ほぼ寄付でした。
その２: 土台が毎回変わる
もう一つの違和感は、Ansibleのロール設計が前提にしている「土台が安定している」という条件が、イベントNOCではほぼ成立しないことでした。
イベントNOC構築で毎回変わるもの:
- 要件: 規模、提供サービス、SLA
- 機材: ベンダー、型番、世代がバラバラ。借り物だったりもする
- 環境: 会場のラック、電源、空調、物理配線
- 上流回線: ISP、帯域、ハンドオフ形態、固定IPの有無
- 制約事項: 予算、納期、会場ルール、運用体制
ロールを書くというのは「何を変数にして、何を固定にするか」を決める作業です。
でもイベントNOCの場合、固定だと思っていた土台側が次の現場で平気で変わる。
すると、
- 抽象化を上げる → ほぼCLIを叩くだけのラッパーになって書く意味が薄い
- 抽象化を下げる → 次の現場で機材が変わった瞬間に書き直し
という板挟みになります。
変数化するための"安定した軸"そのものが存在しない領域でした。
その３: 自動化は"似たもの大量"のレバレッジ装置だった
ここまで来てようやく腹落ちしたのは、自動化が効く条件は実は2軸あるという話です。
| 軸 | 自動化が効く条件 |
|---|---|
| 量 | 同じようなものを大量に作る(1台より100台、1拠点より100拠点) |
| 変化の幅 | 要件変更が"差分"で済む(土台は同じ、パラメータだけ変わる) |
効く例:
- 全国チェーンの店舗ネットワーク100店舗(同じ機材・同じ構成・住所とVLANだけ違う)
- データセンターのサーバープロビジョニング(同じOS・同じ役割・ホスト名だけ違う)
- マルチテナントSaaSの環境払い出し(テンプレ化された土台に顧客名を入れるだけ)
今回のイベントNOC構築は:
- 量 = 1(イベント毎に1セット)
- 変化の幅 = 土台ごと変わる(差分じゃなくて作り直し)
→ 自動化のおいしい所が両軸ともゼロ。
エンジニアは「複雑だから自動化したい」と思いがちですが、これは順序が逆で、自動化は"単純な作業を大量に"やるときに効く道具なんだ、と書いて初めて気づきました。
複雑なもの一点ものに自動化を当てると、複雑さを変数として抱え込むだけになって、結局そのコードを書いた人にしかメンテできない別の属人化を生みます。
その４: イベントNOCはそもそも"自動化したくない場所"だった
ここまでは「自動化が効かない理由」を技術的な観点で書いてきました。
でも一歩引いて考えると、もっと根本的なことに気づきます。
イベントNOCは、そもそも自動化したくない場所だったのです。
イベントの裏側には、毎回いろんな人がワイワイ集まります。
常連のベテランもいれば、その日が初参加のビギナーもいます。
そして毎回、要件も課題も違う。
- 「今回はこういうトポロジーにしよう」とその場で議論する
- ビギナーには「このVLANの設定やってみる?」と簡単なタスクを渡す
- 詰まったら横でベテランが手元を見ながら口頭で教える
- 終わったら撤収して打ち上げに行く
つまり、設営作業そのものが**"成長機会の現場"であり"コミュニティ"**なんです。
新しい人がネットワーク機器に初めて触れる入り口で、ベテランが手を動かしながらナレッジを渡していく場。
ここに完璧なPlaybookを持ち込んで「実行ボタンを押すだけです」とやってしまったら、何が起きるでしょうか。
- ビギナーが手を動かす機会が消える
- 「なぜこの設定が必要か」を肌で学ぶ場が消える
- 横で教える/教わるという関係性が消える
- 結果として、次のイベントを支える人材が育たなくなる
技術的に効く/効かない以前に、自動化は"その場の人間関係と学びの設計"を壊しに行く。
これは ROI の話ではありません。
場の意味の話です。
「自動化は正義」は本当です。
ただしそれは「人手でやる退屈な反復作業を機械に渡す」ことが正義だという意味であって、「人が手を動かすこと自体に意味がある場」まで機械に渡すべきだ、という意味ではありません。
イベントNOCは後者でした。
だから「自動化に向いていない」というよりも、自動化されてはいけない場所だった、というのが一番しっくりくる言い方だと思います。
(※ この原稿を書いた直後、後述のとおり別のイベントNOCを実際にまわすことになりました。
事後に確認すると、この「場所」論は実感として裏取りできています — 副次目的にしていた"育成"は現場で機能し、シニア側も RFC や仕様書だけでは見えない挙動を複数のインシデントを通じて学びました。
自動化してはいけない場所は、同時に"人が育つ場所"であり"現場知が溜まる場所"でもあった、というのが事後の一番の収穫でした。)
じゃあイベントNOC構築では何を使えばいいのか
イベントNOC構築のような"複雑な一点もの"に必要なのは、たぶん自動化ではなく、
- 構成図と手順書: 物理〜論理を一望できるドキュメント
- チェックリスト: 当日の設営・疎通確認を抜け漏れなくやるためのもの
- 過去案件の知見: 似たケースをどう解いたかの引き出し
- 設計レビュー: 流す前に間違いを潰す
- 人の段取りと役割分担: 誰が何を触るか、ビギナーにどのタスクを渡すか
要するに、コードではなくドキュメントと人の段取りが効く領域です。
それも単なる作業効率の話ではなくて、その４で書いたとおり"人が育つ場所"としての意図を含んだ段取りです。
逆に、運用が始まって"同じことを繰り返すフェーズ"に入ったら、そこで初めて自動化が刺さります。
設営フェーズと運用フェーズは別物として考えるべきでした。
今回の判断と、それでも得たもの
このAnsibleプロジェクトはcloseします。
リソースの都合で別の構築案件に集中することになったので、ロール群は棚上げです。
書いた本人としては悔しさはあります。
でも書いてみないと「ここは自動化が効かない場所だ」とは気づけなかったので、この経験自体は無駄ではなかったと思っています。
具体的に得たもの:
- 自動化が効く条件を自分の言葉で説明できるようになった(量 × 変化の幅)
- イベントNOCに必要なのはコードではなくドキュメントと段取りだと整理できた
- イベントNOCは"人が育つ場"でもあって、自動化は時にその場を奪いに行くことに気づけた
- 次に自動化を選ぶときの判断基準ができた
タイトルに戻ると、「自動化は正義」は嘘ではありません。
同じ正義でも、それが効く場所と効かない場所があるだけ。
今回はその境目を、コードを書きながら学んだ話でした。
次の案件では、自動化を入れる前にまず「これは"似たもの大量"か?」「土台は安定しているか?」を自問することにしています。
後日譚: 実際にやってみた (Build with AI in Kwansai 2026 NOC)
冒頭で触れた"舞い込んできた別件"の中身がこれです。
2026年4月19日(日)に大阪で開催された Build with AI in Kwansai 2026 のためのNOCでした。
会場参加300人 + オンライン100人、計400人規模で、Google の最新 AI をテーマにしたトークセッションとハンズオンを終日開催する、GDG Greater Kwansai 主催のイベントです。
Ansible で再現しようとしていた構成 (200ユーザー規模) より、人数も大きく、設計もずっと巨大で、ずっとエキサイティングな案件でした。
会場 (国際工科専門職大学 大阪キャンパス) の既設回線はプロキシこそ抜けてくれるもののポート制限等が残るため、エンジニアが集まるイベントとしては「制限のないインターネット」を提供したかったのです。
そのために通信の出口 (NAPT) を VPN で自宅と GCP に逃がす — というのが設計の基本コンセプトでした。
とくに目玉は IPv6 のデュアルプレフィックス RA でしたが、それ以外も書ききれないくらい盛りだくさんだったので、要点だけ並べておきます。
-
IPv6 デュアルプレフィックス RA + ソースベース PBR (今回の目玉): 会場のクライアントが SLAAC で完全に異なる2つの GUA を同時に持ちます。
1つは自宅 ISP (OPTAGE) から DHCPv6-PD で取得した /64、もう1つは GCP VPC の外部 IPv6 /64。
会場のルーター (r3) が両プレフィックスを同じ VLAN で RA 広告し、送信元アドレスを見て出口を切り替える仕組みです (OPTAGE src は wg0 → 自宅 → OPTAGE へ、GCP src は wg1 → r2-gcp → NAT66 → Google backbone へ)。
GCP 側は GCP データプレーンの /96 制約に阻まれるため NAT66 を噛ませています。
preferred-lifetime のバイアスで一般 Internet 向けは OPTAGE が優先され、GCP サービス向けの通信だけ GCP 経由に流れます。
自宅回線が落ちても、GCP経由で会場のv6通信は生き残る — これがこのマルチホーミング設計の最大の恩恵です。
なお、この手法は JANOG57 の会場ネットワーク でも採用された比較的新しい設計で、RFC 6724 の未解決課題 (端末側で「どのプレフィックスをどのゲートウェイに紐付けるか」が保証されない) があるためコミュニティイベント規模での実運用例はまだ少ないのが実情です。
本構成では r3 を唯一のゲートウェイにしてサーバー側の PBR で振り分けることで、その問題を回避しています -
VyOS 3拠点 eBGP フルメッシュ: 自宅 / GCP / 会場 を WireGuard メッシュで結び、3台の VyOS で eBGP フルメッシュを構成しています。
WireGuard 直接リンクが落ちたら GCP 経由に自動フォールバックします。
GCP 側は e2-micro 上に自前の GCE イメージで VyOS を載せていて、マーケットプレイス版の ~$100/月 を回避して ~$7/月 で運用しています -
法執行機関対応のログ保存: NetFlow v9 (5-tuple)、DNS クエリログ、DHCP forensic log、NDP テーブルダンプを 180 日 GCS 保管しています。
コンプライアンス要件を最初から設計に織り込みました
そして注目すべきは、この構成のどこにも Ansible はいないということです。
同じ"イベントネットワーク構築"でありながら、自動化ではなくドキュメントと設計と人の段取りで進めました。
本文で書いた「自動化が効く場所 / 効かない場所」の判断を、そのまま次の現場で実践した格好になります。
で、実際どうだったか
NOC 体制はシニア2名 + 初心者3名の計5名、かなり野良の即席編成でした。
結果としては:
-
主目的 (動くネットワークの提供) は達成。本番中に発生した障害は都度対応で乗り切りました
-
副次目的の"育成"も一定の手応え: 初心者3名がシリアルコンソールでのスイッチ設定、ケーブル長計算、AP配置計画といった実機タスクを現場でこなしてくれました
-
シニア側も、RFC や仕様書だけでは見えない"運用してこそ判明する挙動"を複数収穫しました。本番中に遭遇した代表的な3件は、
- GCP Trust & Safety の DoS 判定がマシンタイプの egress 上限に連動せず、capacity 比 1/50 でも発火すること — インシデント記録
- RFC 4541 §3 (link-local scope を MLD snooping 対象外とする推奨) を、古い IOS 15 系・Allied Telesis 実装が守らないこと — インシデント記録
- Cisco Aironet の Wave 1 / Wave 2 世代差 (型番百位) が WLC 側では吸収されず、WPA3 等の対応可否が AP ハードに依存すること — インシデント記録
いずれも事前には想定できず、走らせて初めて手に入る類の知見でした。
つまり、本文で「自動化してはいけない場所」と書いたその場所は、実際に走らせてみると**同時に"人が育つ場所"であり"現場知が溜まる場所"**でもあったわけです。
事前の仮説 (自動化ではなくドキュメントと段取りで進める) は、当日動かす現場としても、組織に残す知見としても、だいたい正解だったと思います。
反省もあります。
一番大きかったのは「シニアが"当然"と思って言語化しなかった定石が、後輩に伝わらず小トラブルになった」という問題で、これは自動化論とは別軸で、次の NOC 運用ハンドブックに織り込む宿題になりました。
いずれにせよ、コードではなく人と段取りに投資するという方向性は、この現場を経て確信に変わりました。
なお、本節で触れた設計・インシデント記録・運用ドキュメントはすべて GitHub で公開しています。
興味があれば 全体設計 (docs/design/architecture.md)、IPv6 デュアルプレフィックス詳細 (docs/design/gcp-integration.md)、NOC 振り返り (docs/operations/noc-retrospective-2026-04.md) あたりを起点にどうぞ。
- 日時: 2026年4月19日(日)
- 会場: 国際工科専門職大学 大阪キャンパス (大阪市北区梅田3-3-1)
- 主催: GDG Greater Kwansai
Discussion