はじめに

IT基盤部ネットワークグループ （以下NOC）の岡崎です。本記事では、NOCにおける終わりなきアラート対応という課題に対し、LLMを活用した自動化システムの開発に取り組んでいる現在進行形の挑戦についてご紹介します。

複雑に絡み合った障害、そして担当者の経験と勘に依存する原因調査──。多くの運用チームが同様の課題に直面している状況において、NOCにおける自動化の必要性は現実的な課題から生まれています。

具体的には、管理する拠点数が増加しており、その管理コストが大きな課題となっています。アラート自体の件数は減ってきているものの、拠点数の増加により全体の管理負荷は増大しています。さらに、アラートの内容も多様化しており、対応方法が担当者の経験・勘に依存するケースが増えています。新人の方が一人前になるまでの時間も長くなりがちです。

結果として、手作業による切り分け作業が業務全体を圧迫する状況になっています。読者の皆さんも、「アラート対応に追われて、本来やりたい改善作業に手が回らない」という悩みを抱えている方も多いのではないでしょうか。

このような背景から、アラート対応の自動化に向けた検討を開始しました。しかし、アラート対応は単純な作業ではありません。ログの読み解き、メトリクス分析、過去の経験との照合による原因推測など、複雑なプロセスを経て行われます。

「この複雑なプロセスを、果たしてLLMに任せることができるのか？」

そんな疑問を抱いていた時、ClineやCursor、新しいLLMモデルの登場により、これまで「不可能」と思われていた複雑な業務の自動化に光明が見えてきました。LLMがログやメトリクスを横断的に解析し、原因候補を提示することで、人的推論時間の大幅な削減が期待されます。この期待が、Alert Agent PoC立ち上げの動機となりました。

これらの最新技術から得られた気づきを整理していく中で、ある仮説が浮かび上がってきました。

「アラート対応のワークフローを徹底的に言語化し、LLMにインプットすれば、一次対応は自動化できるのではないか」

この仮説に基づき、PoC (Proof of Concept) を実施し、現在はプロダクション導入に向けた改良を継続しています。本稿では、この取り組みの背景、アプローチ、および得られた知見と今後の展望について紹介します。

なお、技術的な実装詳細については次回の記事で詳しく説明予定です。今回は「なぜこの取り組みを始めたのか」「どんなアプローチをとったのか」という全体像に焦点を当てています。

仮説の源流：日常のAIツール体験からの気づき

本取り組みの核心となる「ワークフローの言語化」という仮説は、ここ1〜2年で登場した開発者向けAIツールから得られた実体験に基づいています。

開発者向けAIツールからの衝撃

最初に衝撃を受けたのは Cline でした。Clineはコーディングエージェントとして、コード編集、探索、ターミナル実行を自動化してくれます。今までは、自分でコードをコピペして渡してあげないといけなかったコーディングアシスタントが、エージェンティックにコード探索からターミナル実行まですべてこなすことができるようになったのです。

とくに衝撃的だったのは、その仕組みが極めてシンプルであったことでした。プロンプトによりLLMの出力を制御し、LLMにツール実行可能な状態にしただけ。そして、ターミナルの実行権限という極めて強力な権限をLLMに委ねたことも大きな衝撃でした。

ここから得られた重要な知見は、LLMが利用可能なツール整備とその利用方法についてプロンプトとして渡すことで、LLMに複雑なことを実行させることが可能になるということでした。この経験により、「アラート対応もLLMにやらせることができるんではないか」と思うようになり、Alert Agentの開発に取り掛かることになりました。

また、この時期にClineを上手に利用する手法などがSNSで拡散され、これを見て更なる気づきを得ました。優秀なエンジニアの思考やワークフローをプロンプトとして適切に言語化し、LLMに渡すことで、より複雑なことも実行可能になるのではないかという仮説を持ったのです。

この仮説をより強固にしたのは、Claude Code の登場でした。Claude Code は、ベースモデルが同じ他のコーディングエージェントとは一線を画すコーディング能力を有しており、その理由が内部プロンプトによるものだと確信できたからです。Claude Code で開発を行った時の挙動を見ると、優秀なエンジニアの開発ワークフローが言語化されてプロンプトとして組み込まれていることが明らかでした。この体験により、プロンプトによる複雑なワークフローの遂行が確実に可能だと確信を持つことができました。

これらの経験から、決定的な気づきを得ました：

プロンプトエンジニアリングによって、優秀なエンジニアのワークフローを適切に言語化し、適切なツール整備を行うことで、LLMに複雑な業務を委ねることができる

つまり、「モデル性能が低いから実現できない」のではなく、「ワークフローの言語化とツール整備が不十分だから課題解決できない」というケースが多いということです。

この確信に基づき、私たちチームメンバーのアラート対応のワークフローを適切に言語化し、必要なツール整備を行うことで、Alert Agent を実現できると確信を持って取り組んでいます。

ネットワーク分野におけるゲームチェンジャー：Gemini 2.5 Pro

しかし、実際にAlert Agentを実現する上で大きな課題がありました。ネットワーク分野における既存LLMの知識不足です。

ネットワーク分野でのLLM活用が簡単ではなかった最大の理由は、ハルシネーションが非常に多いということです。Gemini 2.5 Pro 以前のLLMは「それらしい回答」を頻繁に生成するため、そのまま実用するには課題がありました。

具体的に、それまでのOpenAIの4o、o1や、Claude 3.7 Sonnetにネットワーク機器（CiscoやJuniper）のことを質問した時の問題は深刻でした。存在しないコマンドを平然と提示したり、設定初期化や重要な設定削除につながる危険なコマンドを注意喚起なしに提案したり、CiscoとJuniperのコマンド体系を混同したりと、実用性は皆無でした。

ところが、Gemini 2.5 Pro がゲームチェンジャーとなりました。

最初にJuniper SRXのセキュリティポリシー設定について相談した時の衝撃は忘れられません。Gemini 2.5 Proは、Juniperの実際のコマンド体系に完全準拠した正確な構文、設定からコミット、確認という正しいワークフロー、適切な警告、そして問題が発生した場合の復旧方法まで含む包括的な回答を提供してくれました。実際にJuniperの公式ドキュメントを参照した上での、実用的な回答でした。

さらに重要だったのは、Gemini 2.5 Proが「存在しないものは存在しない」と明確に断言するようになったことです。これまでのLLMの場合、ユーザーの要求に対して存在しないコマンドを平然と提案していましたが、Gemini 2.5 Proは「そのようなコマンドは存在しません」「代替手段として〜があります」といった具合に、正確性を重視した回答を提供してくれました。

とくに印象的なのは、Geminiの「お節介気質」です。単にコマンドを教えるだけでなく、「なぜそのコマンドが必要なのか」「実行前に何を確認すべきか」「実行後に何をチェックすべきか」まで、まるで隣にいるシニアエンジニアのように詳細に説明してくれます。

この体験により、ネットワークを扱うAlert Agentの実現がより現実的なものになりました。アラート対応において、正確なコマンドと適切な注意事項を自動生成できることは、人的ミスの削減と対応品質の向上に直結します。

その後のLLMモデルの登場により、Gemini以外のモデルでもモデル自体の性能向上やRAGによりネットワーク知識が十分なLLMが登場していますが、Geminiのこの「お節介気質」（詳細な注意事項や確認手順を必ず含めてくれる特性）は、NOCの一次対応において極めて重要な特徴です。そのため、私たちはGemini 2.5 ProをベースにしたAlert Agentを構想しています。

コンセプト：ワークフローの言語化とは何か

本取り組みの核心概念である「ワークフローの言語化」について、もう少し詳しく説明します。

これは、担当者の頭の中にある「暗黙知」を、LLMが理解できる「形式知」に変換するプロセスです。

従来のアラート対応は、アラートを見て「あ、このパターンね」と経験で判断し、関連するログやメトリクスを確認して、過去の経験と照らし合わせて原因を推測し、対応策を実施するという流れでした。このプロセスの多くが「経験と勘」に依存しており、言語化されていませんでした。

一方、ワークフローを言語化すると、アラート内容から初期仮説を生成し、仮説に基づいて必要な情報を特定・収集し、収集した情報を統合して原因を推定し、推定した原因に基づく具体的な対応案を提示する、という明確なステップに分解できます。

各ステップで「何を考えるべきか」「どの情報を見るべきか」を明文化することで、LLMが同じプロセスを実行できるようになります。

Alert Agent の全体像

Alert Agent は、Slack 経由で受信するアラートを起点として、原因特定から対応案提示までを段階的に処理します。

上図は、Agent が実行する7つのステップとその判定ロジックを示しています。特に中央の菱形「情報十分性判定」からのフィードバックループが、本システムの核心的な機能である反復的な仮説検証プロセスを表現しています。

基本的な流れは以下の7つのステップで構成されています：

1. アラート認識: Slackでアラートを受信し、基本情報を解析
2. 仮説生成: アラート内容から複数の原因仮説を生成
3. 情報収集: 各仮説の検証に必要なデータを自動収集
4. 情報十分性判定: 収集した情報で根本原因を特定できるかを判定
5. 根本原因分析: 十分な情報に基づいて根本原因を特定
6. 推奨アクション: 特定した原因に対する具体的な対応手順を提示
7. 最終レポート生成: 包括的な分析結果をレポート形式で出力

特に重要なのは、ステップ4の「情報十分性判定」です。ここで情報が不十分と判定された場合、自動的にステップ2の「仮説生成」に戻り、新たな仮説の検討や追加の情報収集を行います。この 仮説生成→情報収集→十分性判定 のループにより、確実性の高い原因特定を実現します。

設計のポイントは、各ステップで「何をするか」「どう判断するか」を明確に定義したことです。これにより、LLMが迷うことなく、一貫性のある処理を実行できるようになります。

PoC で見えてきた可能性

短期間でプロトタイプを開発し、実際のアラートデータを使った検証を実施しました。使用した技術は Python、LangChain、そして Google の Vertex AI です。

実際にテストしてみると、予想以上の結果が得られました。従来は10分以上かかっていた複雑なケースでも、Agent による対応時間は2~5分に短縮されました。

実際の動作例をご覧ください。Cisco Aironetアクセスポイントのping疎通不可アラートに対し、Alert Agentは以下の処理を自動実行しました：

この例では、Alert Agentがアラート概要の整理、影響範囲の特定、具体的な対応手順の提示、原因分析、収集データの要約、そして深刻度と確実性の判定まで、包括的な一次対応を2分程度で完了しています。とくに注目すべきは、ファイアウォールのインターフェイス状態確認やPrometheus監視データの取得といった、従来は手作業で行っていた情報収集作業も自動化されている点です。

なお、この例では上流ファイアウォールの情報が2台別々のホストとして表示されていますが、これはPoC初期段階でのネットワークトポロジ理解の課題によるものです。現在はこの点も改善されており、詳細については次回以降の記事で解説予定です。

さらに別の例では、同じくアクセスポイントの障害でも、仮説ベースのアプローチがより明確に示されています：

この例では、「上流スイッチのポート障害または電力供給停止」と「アクセスポイントのハードウェア障害」という2つの仮説を立て、それぞれを検証した結果、後者が原因であることを特定しています。注目すべきは、仮説検討→値取得→仮説に対する検証というMVPループを完璧に実行している点です。このような体系的な仮説検証により、確実性レベル5（最高レベル）での判定を実現しました。

さらに重要な機能として、Alert Agentは誤検知の適切な判定も行えます：

この例では、帯域幅使用率のアラートに対して3つの仮説を検証した結果、アラートシステム自体の設定不備による誤検知であることを特定しています。注目すべきは、対象インターフェイスが実際には無効化されており、実トラフィックも閾値を大きく下回っているという矛盾を発見し、「false_positive」という明確な判定を下している点です。これにより、不要な対応やエスカレーションを回避できます。

得られた学びと課題

PoCを通じて、いくつかの重要な学びを得ました：

1. ワークフローの言語化が最重要 - LLM活用以前に、プロセスの体系化がボトルネックとなることが分かりました。「なんとなくやっていること」を言語化するのは、想像以上に難しい作業です。

2. データ品質の重要性 - 入力データの品質が、出力品質の上限を決定します。不正確なデータからは正確な結果は得られないという原則は、LLMにおいても変わりません。

3. 部分自動化でも十分価値がある - 全工程を自動化しなくても、一部のステップをLLMが担うだけで、大幅な効率化が実現できることが分かりました。

一方で、現在の課題も見えてきました：

• データソースの拡充: 現在参照できる情報源が限られている
• 複雑なケースへの対応: まだ対応できないパターンがある
• 運用体制の整備: 実際の業務に組み込むための体制作り

今後の展望：本当に「人間不要レベル」まで行けるのか？

現時点では、Alert Agent は万能ではありません。しかし、人的試行錯誤を計算資源に置き換えることで、想定を超える効果を実現できることが分かりました。

短期的な目標としては、以下の取り組みを進めています：

• より多くのアラートパターンへの対応
• データソースの拡充による精度向上
• 実運用に向けた体制整備

長期的には、「ワークフローとコンテキストを完全に言語化した後、本当に『人間不要レベル』まで一次対応を自動化できるのか？」という点を検証したいと考えています。

これは技術的な挑戦であると同時に、運用の在り方そのものを問い直す取り組みでもあります。

今回の取り組みで証明できたのは、「ワークフローの言語化 × LLM」という比較的シンプルな組み合わせでも、運用プロセスの根本的な変革が可能であることです。とくに、段階的アプローチ（いきなり全自動化を目指さず、部分的な活用から始める）、ワークフローの見える化（LLM活用を機に、従来の手順を整理・改善する）、継続的改善（小さく始めて、徐々に精度を向上させる）といったポイントは、他のチームでも応用可能だと考えています。

まとめ：新たな挑戦への招待

LLMを活用したAlert Agentは、まだ発展途上の技術です。しかし、PoCを通じて見えてきた可能性は、私たちの期待を大きく上回り、終わりなきアラート対応に対する革命の第一歩のように感じました。

何より印象的だったのは、「ワークフローを言語化してLLMに伝える」というシンプルなアプローチで、これまで「不可能」と思われていた複雑な業務の自動化に道筋が見えたことです。

アラート対応に限らず、多くの運用業務において、同様のアプローチが有効である可能性があります。皆さんの現場でも、「これ、毎回同じような手順でやってるな」「この判断プロセス、言語化できるかも」といった業務があるのではないでしょうか？

もしそんな業務があれば、ぜひ一度「ワークフローの言語化」から始めてみてください。LLMを使わなくても、業務の整理・改善につながりますし、将来的な自動化への第一歩にもなります。

技術的な実装詳細については、次回の記事で詳しく解説予定です。プロンプト設計のコツや、実際のコード例なども紹介しますので、ぜひお楽しみに！