# ワークフロー自動化 ## 定義 ワークフロー自動化は、人間が手順書・Runbook・TSG・運用プロセスとして実行していた複数ステップの作業を、機械が状態を見ながら実行・分岐・検証する取り組みである。SRE 文脈では [[トイル]] 削減と [[インシデント管理]] の反復作業削減に直結する。 ## 横断的知見 - [[TSG自動化]] は、トラブルシューティングガイドを LLM エージェントが実行するワークフロー自動化の具体例である。FLASH、LLexus、StepFly は、オンライン監督・事前計画・DAG 化など異なる設計を示す。 - StepFly は TSG をオフラインで DAG 化し、QPP と並列実行でワークフローの実行効率を上げる。([[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) - agentic SRE のワークフロー自動化は、単純な手順実行ではなく、観測・計画・実行・検証・巻き戻しを含む。[[Transactional No-Regression]] や [[エージェント運用安全性]] と接続する。 - **汎用ワークフローランナーを「共通基盤」として複数チームに開放する産業実装**: [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤|LY Corporation の oyakata(JANOG58, 2026)]] は、FLASH/StepFly/LLexus のような専用 TSG 実行エンジンではなく、汎用ワークフローランナー [[Apache Airflow]] を Operator という抽象化単位で拡張し、基盤開発チームが共通 Operator を提供・各現場チーム(NW チーム)がそれを使ってワークフローを実装する分業モデルを採る。これは「LLM エージェントが TSG を解釈・実行する」学術系の設計群とは異なる、既存の汎用オーケストレーションツールを土台に現場実装力を活かす経路であり、コードによる決定的処理(SLA 非依存・柔軟性に限界)と LLM Agent 処理(柔軟だが精度ばらつき)を同一 DAG 内の Task 単位で混在させられる点が採用理由として挙げられている。(Source: [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]] p.30, 33) - **自動化の成熟が運用知見の継承を難しくするという懸念は、TSG 品質問題と表裏の関係にある**: [[TSG自動化]] 側の知見が「人間向け手順書を AI が実行可能な形に翻訳する難しさ」を共通の壁として挙げるのに対し、oyakata の発表(JANOG58, 2026)は逆方向の懸念——**自動化が進むほど新メンバーが運用知見そのものを獲得する機会が減る**——を提起する。ワークフローの実行状態を可視化しても、可視化が知見継承を自動的に保証しないという指摘は、TSG 自動化が前提とする「良質な TSG があれば実行は代替できる」という枠組みの外側にある、自動化の長期的な人材育成コストを示す。(Source: [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]] p.56) - **1995年のISP運営における手作業手順書からのスクリプト化は、TSG自動化が現代扱う「人間向け手順書をエージェントが実行可能な形にする」問題の最も原始的な形態である**: [[TSG自動化]]側の知見は「人間向け手順書をAIが実行可能な形に翻訳する難しさ」を共通の壁として挙げるが、[[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]](Adam Jacob, 2011)が語る1995年のISP運営の逸話はこの問題の前史にあたる。「顧客の重要情報を電話で取得する」「顧客情報をデータベースに保存する」「顧客のアカウントをadduserコマンドで作成する」という3ステップの手順は、サポートエンジニアの机にテープで貼られた紙として運用されていたが、システム管理者のケビンがこれを`addcustomer`という単一のスクリプトに自動化した。この事例は、TSG自動化がLLMエージェント+DAG化(StepFly等)という高度な手法で扱う「手順書の実行可能化」を、1995年時点では「手書きの手順を読み、1つのスクリプトに手続き型で書き下す」という最も単純な形で解決していたことを示す——問題の骨格(人間向け手順→機械実行可能な形式への変換)は同一だが、ch5の時代には自動化の主体は人間のエンジニア(ケビン)自身であり、現代のTSG自動化研究が扱う「エージェントが手順書を解釈する」という部分は存在しない。(Source: [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] §5.1.1.2, [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]]) ## 未解決の問い - TSG 品質が低い場合、自動化エージェントは手順を修正すべきか、人間に差し戻すべきか。 - 並列実行された運用ステップが互いに干渉する場合、ロックやトランザクション境界をどう設計するか。 - ワークフロー自動化で削減されたトイルが、監視・例外処理・モデル監督という新しい残余タスクに置き換わらないか。 - oyakata が指摘する「自動化成熟 vs 知見継承」のトレードオフに対し、学術系の TSG 自動化研究(FLASH の hindsight integration 等)は解決策を提示しているか。可視化を超えて知見継承を積極的に支援する設計(自動生成された Runbook のレビュー、Agent の判断根拠の教材化等)は検討されているか。(Source: [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]] p.56) ## 関連 - 概念: [[TSG自動化]] / [[インシデント管理]] / [[agentic SRE]] / [[トイル]] / [[自動化のアイロニー]] / [[エージェント運用安全性]] - エンティティ: [[Apache Airflow]] / [[oyakata]] / [[Adam Jacob]] - ソース: [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]] / [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]] / [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]] / [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]] ## 出典 - [[@2025__arXiv__StepFly - Agentic Troubleshooting Guide Automation for Incident Diagnosis]] - [[@2016__OReilly__SRE Book - Chapter 7 Automation at Google]] - [[@2026__JANOG58__ネットワーク監視の自動化はどこまでできるのか - Apache Airflowによるアラート対応基盤]] p.30, 33, 56 - [[@2011__OReillyJapan__ウェブオペレーション - Chapter 5 コードとしてのインフラ]](アダム・ジェイコブ, 2011, §5.1.1.2 — 1995年のISP運営における手作業手順のスクリプト化)