## 概要 [[LINE株式会社|LINEヤフー株式会社]] のデータセンターネットワーク運用チームが、人手前提のアラート一次対応というボトルネックと、複数チームでの自動化乱立という課題に対し、[[Apache Airflow]] を中核とした内製 NW アラート対応基盤 [[oyakata]] を構築した事例を報告する。発表者は [[上岡 輔乃]]。JANOG58(2026-07-15)での発表。 ## 主要メッセージ - **人手前提の運用から「基盤上で自動実行し必要な時だけ人に渡す」運用への転換**(p.53): 22,000 台以上のデータセンターネットワークで、アラート一次対応の人手ボトルネックと、チームごとの自動化乱立という 2 つの課題を抱えていた。 - **Apache Airflow を NW 運用の共通基盤として採用**(p.25-27, 33): Operator という抽象化単位に NW 運用ロジックを実装する設計とし、基盤開発チームが共通 Operator を開発・提供、各 NW チームがそれを使ってワークフローを実装する分業モデルを構築した。実行履歴の可視化、待機・承認を含むワークフロー制御、コードによる決定的処理と LLM Agent 処理の Task 単位での組み合わせが採用理由。 - **Airflow 単体の限界を補う内製 API "oyakata"**(p.34-39): Airflow は UI/API/cron の 3 手段でしか起動できず、監視システムからのアラート受信で直接起動できない。また、アラート種別とワークフローの紐付け管理や、単一事象由来の複数アラートに対する重複起動防止も Airflow 単体では実現できない。この 3 つの不足機能を内製 API "oyakata" が補う。 - **NetBox 連携によるアラート重複排除**(p.42-48): 同一事象で L2/L3 や対向ポート等から複数のアラートが発生する問題に対し、対象機器と NetBox から取得した対向ポート情報の双方に `{hostname}:{interface}` 形式のタグを自動付与し、タグが一致すれば重複とみなしてワークフロー起動をスキップする(発生順不同でも機能)。 - **ワークフロー内への LLM Agent 組み込みパターン**(p.31-32): (1) アラートチケット検索 → 関連アラート判定 Agent → 既存チケットへの追加/新規作成を分岐するパターンと、(2) アラート分類特化 Agent → 専門家 Agent による調査確認 → エスカレーション/クローズを分岐するパターンの 2 種を採用。Agent の更新のみで対応範囲を拡張できる点をコードによる自動化に対する優位点として挙げる。 - **本番導入で一次対応の 90% 以上を自動化**(p.54): 複数 NW チームへの本番導入により、アラート一次対応の 90% 以上を自動対応へ移行した。導入時は監視担当者による対応と oyakata による自動対応を並行稼働させる移行期間を設け、この期間にワークフローの挙動確認・改善を行った(p.52)。 - **自動化の成熟と運用知見の継承のトレードオフ**(p.56): NW 運用がワークフロー・LLM によって自動化されるほど、新メンバーが運用知見を継承しづらくなるという課題を指摘。oyakata はワークフロー・実行状態の可視化はできるが、可視化が知見継承を自動的に保証するわけではないとする。 - **今後の展望**(p.55): アラート対応にとどまらず NW 運用全体の自動化・効率化を目指す設計とし、oyakata 勉強会・Agent Skill 提供・共通ワークフロー提供により実運用への定着を図る。 ## 視覚的に重要な図表 **p.21 Operator/Task の具体例** ![[_attachments/janog58-pr-auto-nw-monitoring/page-021.png]] SSHOperator でコマンド実行し、結果を SlackAPIPostOperator で通知する DAG コード例。Operator が個別処理を抽象化し、Task がその実行単位であることを示す。 **p.28 ワークフロー実装例(dcnw_ps_alert)** ![[_attachments/janog58-pr-auto-nw-monitoring/page-028.png]] PSU アラート対応の DAG。チケット起票・構成管理DB照会・過去発生状況確認・DC作業影響確認・複数故障時のエスカレーションを自動実行する。従来人手 5〜10 分だった対応が自動化により 1〜2 分・工数ゼロになった。 **p.39 Airflow + API = oyakata の構成** ![[_attachments/janog58-pr-auto-nw-monitoring/page-039.png]] NW 機器 → 監視システムからのアラートを oyakata API が受け、Airflow REST API 経由でワークフローを起動する全体構成。「様々な自動化・業務を束ねる」という意味で "oyakata"(親方)と命名。 **p.43 アラートの重複排除(1/3)** ![[_attachments/janog58-pr-auto-nw-monitoring/page-043.png]] NetBox 連携によるタグ付与の仕組み。対象機器の `hostname:interface` と、NetBox から取得した対向ポート情報の双方に同一タグを付与し、重複判定に用いる。 **p.54 導入結果** ![[_attachments/janog58-pr-auto-nw-monitoring/page-054.png]] 課題1(人手によるボトルネック)は複数 NW チームの一次対応を oyakata に載せ 90% 以上を自動対応へ移行、課題2(自動化の乱立)は NW チームが運用知識の実装に注力できる共通基盤 oyakata の整備で解消したとまとめる。 ## 概念・実体への接続 - [[Apache Airflow]] — oyakata の基盤ワークフローランナー。DAG/Operator/Task/Provider/Sensor の概念を採用。 - [[oyakata]] — 本発表の中心となる内製 NW アラート対応基盤。 - [[NetBox]] — アラート重複排除のタグ付与元。 - [[LINE株式会社]] — 発表企業(LINEヤフー株式会社)。 - [[上岡 輔乃]] — 発表者。 - [[ワークフロー自動化]] — Apache Airflow を用いた NW 運用自動化の具体事例として接続。 - [[アラート集約]] — NetBox タグベースの重複排除は、意味類似度・統計・LLM に依らない属性ベース手法の一例として接続。 - [[ネットワーク監視]] — データセンターネットワークのアラート対応自動化事例として接続。 ## 限界・不確実点 - p.11 のワークフローランナー比較表は複数ツールを列挙するが、比較軸・評価値の詳細な数値は画像上でも簡潔な○×表現にとどまり、選定の定量的根拠は口頭説明に依存する可能性がある(transcript なし)。 - LLM Agent の具体的な実装(使用モデル、プロンプト設計、精度評価)はスライド上で言及されておらず、「関連アラート判定」「アラート分類」「専門家調査」という役割分担の説明にとどまる。 - 音声・動画の transcript は取得していない(公式ページ・スライド画像のみを情報源とする)。質疑応答の内容(p.58 の議論したいこと自体は論点提示であり、実際の回答は不明)。