障害調査もエージェントに
さらに同社は、複雑な障害の切り分けにもAIエージェントの適用を進めている。背景にあるのが、大規模なClosネットワークだ。Leaf/Spine構成により多数の経路を持つClosネットワークは冗長性を高めやすい反面、障害確認時に関係するスイッチや経路が膨大になる（図表1）。リージョンをまたぐ通信では、転送に関わるClosスイッチだけで最大60ノード、パスは最大数万通りに達する。Pingだけでは状態を判断しきれず、従来は経験と勘に頼る場面もあった。
図表1 Closネットワークの障害確認の難しさ
そこで同社は、AIエージェントに機器や監視情報を調査させ、原因の絞り込みに活用するアプローチを採る。
重視しているのは、「コードに過度に作り込まない設計」だ。従来のスクリプト自動化では、機器ごとのコマンド出力の違いや構成変更時の例外をコード側で吸収する必要があり、保守負荷が高かった。
AIエージェント方式では、MCPサーバー側のコードは対象機器にコマンドを実行し、結果を返す汎用的な機能だけを持たせる。確認手順に沿って、どの情報を確認し、結果をどう解釈するかはAIエージェントに委ねる（図表2の①）。
図表2 AIエージェントの実装例
確認手順も自然言語で記述する。BGP接続性診断であれば、ネイバー状態やデフォルトルートの確認事項を自然言語の手順としてAIエージェントに読ませる。これにより、表記揺れや例外をすべてコード側で吸収するのではなく、AIに手順を解釈させながら柔軟に確認を進められるようにした（図表2の②）。
図表3は、この障害切り分け支援エージェントの実装アーキテクチャだ。MCPサーバーを介して実機情報、メトリクス、ログ、作業情報を取得し、障害状況を確認する。ただし複雑な障害の発生頻度は高くなく、効果測定は今後の課題となるという。
図表3 AIエージェントによる障害確認アーキテクチャ
1つのチームで運用・開発・構築
先進的な取り組みを可能にした背景には、運用体制もある。「AIエージェントを作るうえで大きかったことは、運用も開発も構築も1つの部署でやっていたこと」と岡田氏は話す。AIエージェントは最初から完璧に動くわけではない。想定通りに動かなければ人手に戻し、確認項目を修正する必要がある。その際、ネットワーク構成や運用上の例外を熟知するエンジニアが自ら改善できる環境が重要となる。
旧ヤフー側には、開発と運用を分けないDevOpsの文化が根付いていた。自ら開発し、使いながら改善するサイクルがあったからこそ、配線情報のデータベース登録など、自動化に必要な手間も受け入れられた。最終的に自分たちの運用負荷が下がるためだ。
現在、岡田氏のチームは担当者十数名ほどの体制で約1万台の装置、約30万リンクを管理している。旧ヤフー環境では24時間監視を担っていた業務委託体制はすでに撤退しており、急ぎでないアラートはAIが処理し、筐体ダウンのような緊急時のみ自動で電話通知が行われる。
一方、旧LINE環境や統合環境では現在もNOCにあたる業務委託チームが監視を担う部分がある。岡田氏はこれらも将来的に無人化していきたい考えだが、関係者が増えるほど調整は難しくなる。NOCに手順書を渡す運用とは異なり、AIで自動化するには、AIが参照できるデータ整備や例外処理のルール化まで、ネットワークの設計・構築・運用を担うチームが関与する必要があるからだ。
