生成AIはネットワーク構築運用をどれだけ楽にするか? Interop Tokyoでの実験が明かした現実と可能性。Cloud Operator Days Tokyo 2025基調講演ほか[PR]

2025年10月8日

生成AIによるプログラミングの支援はすでに多くの開発現場で使われ始めています。ではクラウドやネットワークの運用の現場において、生成AIはどのくらい実用的に使えるのでしょうか?

クラウドの運用などにたずさわるシステム運用管理者に光を当てるイベント「Cloud Operator Days Tokyo 2025」(CODT2025)のクロージングイベントが9月5日に都内で開催され、基調講演に東京大学 情報基盤センター准教授の中村遼氏が登壇。

中村氏は「2025年のShowNetに見る、ネットワークにおける生成AI活用の現在地」と題した講演において、日本最大のネットワーク技術展示会「INTEROP TOKYO 2025」で行われた生成AIを使った実験により、生成AIがどこまでシステム運用の現場で役立つのか、定量的に評価したベンチマーク結果を明らかにしました。

中村氏による基調講演の内容をダイジェストで紹介しましょう。

世界最大規模のネットワークで検証された生成AIの実力

東京大学 情報基盤センターの中村遼氏。

fig

自分は、東京大学の情報基盤センターで准教授をやっています。業務的には、東京大学のキャンパスネットワークの運用をやっているオペレーターです。

同時に、ネットワークとシステムソフトウェア、オペレーティングシステムですね、それらの研究をやっております。例えばネットワークアーキテクチャとかルーティングとかプロトコル、運用、Linuxのネットワークシステムの高速化とかいろんな開発とか、そんなことをやっています。

INTEROP TOKYOのShowNetという、日本最大のネットワーク技術の展示会で作られるネットワークのNOC(Network Operation Center)チームにも、結構前から参加しています。

生成AIによるネットワーク構築・運用支援実験

今回、ネットワークの構築に生成AIがどの程度役に立つのかを人間がベンチマークしました。

実験環境はINTEROP TOKYO 2025のShowNetです。これは世界最大規模のデモンストレーションネットワークで、このネットワークの構築に参加するエンジニアのうち100名を超えるネットワークエンジニアがこの実験に参加して、AIが役に立ったか、役に立たなかったか、というベンチマークをしました。

fig

実験の舞台となったShowNetはINTEROP TOKYOの会場に構築される巨大なネットワークで、20本を超えるラックに様々なベンダーの最新機器を収容し、複数のプロトコルを相互接続させた超複雑なネットワーク環境です。

fig

しかも通常の企業ネットワークとは異なり、異なるベンダーの機器が混在し、最新技術の検証も同時に行われるため、ネットワークエンジニアにとって極めて挑戦的な環境となっていました。

このShowNetの構築に参加するエンジニアの中から100名を超えるネットワークエンジニアがこの実験に参加して、生成AIが役に立った、もしくは役に立たなかった、というベンチマークをしました。

ネットワークの構築運用支援ボットを開発

実際にどういう実験をやったかというと、ShowNet向けに生成AIを使ってチャットボットを実装しました。Microsoft AzureのOpenAIサービスでLLMのモデルはGPT-4oを使っています。

ここにShowNetでのネットワークの構築運用支援ということで3つの機能を付け加えました。

一つは、生成AIがチケットシステムにアクセスしてチケットの内容を確認できる機能。

もう一つが、ベクトルストアにいろんな過去の商品の設計資料とか設定ファイルを入れて、いわゆるRAG(Retrieval Augmented Generation)を組む。すると、ユーザーからの何々について教えて、と質問されると、必要に応じてベクトルストアのデータを検索して、出てきたデータの内容を使って応答を生成します。

fig

例えば、このルーターのインターフェースに設定するディスクリプションはどうすればいいの? って聞くと、AIが調べて応答してくれます。

ベクトルストアには、ShowNetの設計ガイドやルーターとかスイッチのコンフィグ166台分、正味8247行に及ぶMarkdownで書かれたShowNetの設計書などが全部入れてあります。

三つ目が、生成AIによるネットワーク機器のCLI操作です。MCPサーバーを実装して、ShowNetの機器を全部、生成AIが操作できるようにしました。

fig

このとき、生成AIに対してこの機械にどういうコマンドが打てる、みたいなことを全部教えてはいません。インターネット上のデータを学習している生成AIは、シスコとかジュニパーとかHuaweiとか、各ベンダーのコマンドが全部わかってるので、それぞれに適切なコマンドが打てます。

人間がShowNetを構築するときなどに、例えばこのルーターの状態を教えてとか、これはどうすればいいの? とか、何かここが壊れてんだけど何で? と生成AIに聞くと、生成AIは必要に応じてこの機能を使ってネットワーク機器を操作して対応を行います。

69%の割合で生成AIが役に立った

この生成AIによる対応が役に立ったのか、立たなかったのかを人間が評価をつけます。ShowNetを構築する2週間、100名以上のエンジニアがこの実験に参加して評価を行いました。

その結果はどうなったか。これが集計結果です。

fig

「いいね」がついた評価の割合は69%でした。つまり生成AIの応答のうち31%は間違いや使えなかった、という結果です。

結構生々しいラインと言えるのではないかなというふうに個人的には思っています。

実際の生成AIによるネットワーク構築運用支援の例

実際にどういうやりとりがあったのかっていうのもいくつかご紹介したいと思います。

1つ目は、コンフィグの確認と修正です。

現在のコンフィグ、ルーターとかステーションのコンフィグをそのまま生成AIに入れて、これがうまく動かないんだけど、と聞くと、ここが間違っているのでこうすれば直りますよ、みたいなことを教えてくれます。

fig

このとき裏では生成AIが必要に応じてそのルーターにログインしたり、ベクトルストアに入ってるデータを検索したりしています。

例えばNEXUSでeBGPでマルチパスしたいんだけど、このコンフィグだと経路が1つしか入りません。なんで?と、現在のコンフィグレーションを書くと、生成AIが「maximum-paths」コマンドと「router bgp」で不空パスの下図を指定する、あとここには書いてないけど、マルチパスリラックスコンフィグが必要ですよ、と応答してくれます。

実際にこれで動きます。これぐらいのことは全然できます。

生成AIが機器の操作を各ベンダーのコマンドに翻訳

次のユースケースは、機器の状態確認の反復実行です。

ShowNetのネットワークは、ユーザーさんがループさせたりするわけです。そうすると当然ストームコントロールが上がります。それを調べていた人がいました。

fig

まず最初に、オペレータが「Pod5でストームコントロールのSyslogが出ているか確認」と生成AIに指示します。

生成AIには、どこにどういう機器があるのかという情報も与えてあるので、Pod5と指示すれば自動的にPod5にあるスイッチにログインして、ログを確認して、ストームコントロールのログが上がっているかどうかを見て、あれば「ありました」と報告してくれます。

そして同じように「Pod4、6、7、8でもSyslogを確認して」と指示すると、このPodは実は全部、機種もベンダーも違うのですが、それぞれsyslogを確認してストームが起きているかどうかを確認するという、ある意味本質的な操作を各ベンダーのコマンドに翻訳して実行できます。

これがだいたい69%の役に立つ例です。一方で、コマンドの間違いも当然ありますしコンフィグレーションも間違えます。それはやっぱりしょうがない。

果たしてこれが皆さんの環境で役に立つのか、使えるのか使えないのか。

うまく生成AIを動かすにはプロンプトが大事

というわけで、僕たちがShowNetでAIを使ってみて学んだことをいくつか共有したいと思います。

1つ目。ある意味結論ですけど、生成AIにCLIを触らせるとか、チケットを触らせるとか、ベクトルストアとかのツールなども込み込みで、今のいわゆるAIの基盤モデルと呼ばれるものは、60%以上は役に立つと言えると思います。

fig

この役に立つというのは、自然言語で指示すれば機器を操作してくれるという運用支援の側面です。ドキュメントの検索、技術的な説明や解説、調査もできます。

一方で、うまく生成AIを動かすためにはプロンプトがすごく大事です。AIがアクセスできるところにない情報を聞いてもAIは答えられないし、AIが操作できないサーバを何とかしろと言ってもできない。

AIが知っているはずのこと、できることをある把握しておくことが重要になります。

ハルシネーションも起こります。特に曖昧な指示をするとハルシネーションが起きがちでした。ただ、これは人間でも同じじゃないですか。

現在の生成AIは初心者以上、達人未満

そんな生成AIの現在地をネットワーク運用の観点からまとめると、ファインチューニングなどをしてない基盤モデルの感触は「初心者以上達人未満」です。

当然、今の生成AIはインターネット上にあるデータを学習しているので、人間より知識は全然上です。どの人間よりも知識があると思います。

それにスループットも人間より高い。24時間ずっと休みなく働ける。

ただ、トラブルシューティングにおける推論能力、ある事象が発生したときに、その原因を推測する力。

これはやっぱり熟練したオペレーター、達人のオペレーターの方が全然です。これが生成AIの現在地かなと思います。

fig

生成AIを運用に活かすには?

そんな初心者以上達人未満の生成AIを運用に活かすには? 色んなやり方がありますが、1つは、いわゆるToil(トイル)の削減ですね。

繰り返し行う面倒な作業だけれど、なんとなく自動化しきれない、みたいなトイルを撲滅する可能性を大きく上げるのかな、と思います。

fig

もう1つ、生成AIを活用するためにドキュメントの整備がめちゃめちゃ大事だということがよく分かりました。

結局、生成AIの入力は文字列なので、それをいかに整備するか。

皆さん手順書を書いて人間にやってもらいますよね。多分、人間が作業できる手順書だったら、それは生成AIでもできますよね。そういうレベルまで手順書のレベルを上げることが生成AIの活用に大事です。

最後に、生成AIが外部世界と作用するための腕。MCPとかA2Aみたいなやつで、AIに何を触らせるかという部分を作ることも非常に大事です。

というわけで、時間が過ぎましたが、まとめると今の生成AIは7割は役に立ちます。ここからどんどん向上するでしょう。

生成AIをどう運用に関わらせるかという意味では、与えるべき情報、必要なドキュメント、ツールと、あとはそれを外部世界にどうやってインタラクティブさせるかの作り方と、あとは人間と同様に、その曖昧さをどう許容していくかと思います。

というわけでInterop Tokyoではいろんなデモンストレーションや研究を行っています。ぜひ来年、皆さんお越しください。

ありがとうございました。

基調講演以外のセッションも紹介

Cloud Operator Days Tokyo 2025のクロージングでは、基調講演以外にも多数のセッションが行われました。その中の1つとして、NTTデータグループの星尚宏氏とNTTデータ先端技術の山中涼輔氏による「New Relic導入による基幹ネットワーク運用高度化の事例紹介」を紹介します。

fig

New Relic導入による基幹ネットワーク運用高度化

NTTデータグループは大規模な社内ネットワークを展開。その規模は、利用者数はグループ会社を含め約10万人、ネットワークの拠点数は約200拠点、ネットワークのスイッチは3500台、無線APが2500台。拠点に関しては北は北海道、南は沖縄まで全国にあります。

この社内ネットワークを刷新するにあたり、目指す姿としてネットワーク機器の高度化、ネットワークにおける運用自動化、ネットワーク可視化によるクラウド対応などが目指す姿として設定されました。

fig

そうした中で、サービスレベル管理と可用性の向上に向けた社内監視ツールの統合ということで同社はNew Relicの導入を行っています。

現在の同社のネットワーク運用の課題として、複数のツールを使い分ける必要があったため運用者の習熟に時間がかかり、トラブル発生時の迅速な対応を妨げる要因にもなっていたのです。

また、ツールごとに異なる課金体系もコスト増大の一因でした。これらの課題を解決するため、統合的な監視基盤の構築が急務となっていたのです。

New Relic採用の背景

同社が統合的な監視基盤にNew Relicの採用を決定した理由の1つとして、データ容量による課金方式がありました。数千台の機器を監視する場合、後述するドロップフィルタと呼ばれる機能を活用することで大幅なコスト削減が実現可能となりました。

また、導入に先立つPoC(概念実証)では、既存ツールと同等の監視機能がNew Relicで実現できることが確認されました。

fig

SNMPエージェントで情報を一元的に収集

同社はNew RelicをNPM(ネットワーク・パフォーマンス・モニタリング)として活用、将来的にはネットワーク機器以外の監視も視野に入れているとのことです。

主要な情報収集には、SNMPエージェントが利用されています。これにより、スイッチ、ファイアウォール、ロードバランサーなど、多様なネットワーク機器からのCPU、メモリ、インターフェース情報などを一元的に収集しています。

さらに、HTTPベースの外形監視により、サービスへの接続性を多拠点から確認する 「Synthetic Monitoring」や、SSH接続などによるコマンド実行によりSNMPでは取得困難な情報を取得する「New Relic Flex」なども使用。

同製品のクエリ言語であるNRQLによって柔軟に情報を取得した上で、ダッシュボードのカスタマイズも行っています。

fig

同社ではドロップフィルタと呼ばれる機能で必要な情報のみを取得することにより、データ容量に応じた課金体系であるNew Relicのライセンスコストの削減も行っています。

今後の展望

同社は今後さらに、拠点ネットワーク機器への監視対象の拡大や、収集データを活用したリソース消費予測やSLA測定の自動化、運用レポートの自動出力などを実現してさらなる手動作業の削減を目指すなど、さらに機能拡張を進めるとしています。

fig

(本記事はCloud Operator Days Tokyo実行委員会の提供によるタイアップ記事です)

あわせて読みたい

クラウド ネットワーク 機械学習・AI 運用・監視




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本