研究開発共通ネットワークの運営業務効率化に向けた取り組みについて

以前の記事で、ネットワーク開発戦略プロジェクトの業務についてご紹介しました。本プロジェクトでは、研究開発環境運営業務として研究開発共通ネットワークの運営を行っています。本記事では、その運営業務効率化に向けた取り組みについてご紹介します。

研究開発共通ネットワークは、各研究開発プロジェクトが共通的に必要とする機能である研究開発拠点間のコネクティビティを提供しています。大学のキャンパスやオフィスにおいて、各部局が利用するネットワークが共通的な物理ネットワーク上に、役割や与えられた権限に基づいて論理分割・多重収容されているのと同じように、NTCの各開発プロジェクトの異なるコネクティビティ要件に対応しています。
本プロジェクトの業務従事者は、これまでの知識や経験に基づいて運営業務にあたりますが、研究開発共通ネットワークの利用増加に伴うネットワーク構成の複雑化、組織としての知識・経験の継承、更なる生産性向上に同時に対応していくことが課題となっています。同じような課題に頭を悩まされている情報システム管理者も多いのではないでしょうか。
こうした課題背景から、本プロジェクトでは自動化ツールや最新デジタル技術の活用によって省力化・無人化領域を拡大していくことを目指しており、以降の記事では、その一環で取り組んでいることの一例を紹介いたします。

先の課題の解決に向けた一例として、ここからは研究開発共通ネットワークを新たに利用するユーザグループに対する新規テナントの構築を省力化するための取り組みを紹介いたします。
図1に示すネットワーク概念図を基に、今回の取組みスコープを具体的に説明します。上段と下段のノードはユーザグループが使用する端末を直接収容し、中段のノードはそのユーザトラヒックを中継します。各ノードの型式はそれぞれ異なり、ユーザトラヒックを分離するための論理識別子の設定状態もまちまちです。このような状態を初期状態として、拠点A、B、C間でイーサネット通信を行うための新規テナントを構築するためのコマンドシナリオを自動生成することを目標としています。

次に、以前の記事でも説明した生成AIシステムの構成例(図2)をもとに、コマンドシナリオを自動生成する仕組みを実装するために試みた取組みの一部を説明します。

ステップ1　ナレッジベースを正確に参照するための情報モデルの定義
最初のステップでは、旧来プレゼンテーションツールやスプレッドシートによって管理・表現されていたネットワーク管理情報をマシンリーダブルな情報モデルへ置き換えます。LLMにコマンドシナリオを正確に出力させるためには、対象となるネットワークのトポロジやプロビジョニング情報を正確に解釈させることが前提となります。このステップではそのための準備をします。

ネットワークトポロジ情報
ネットワークを構成するノードのロケーション、型式といった情報に加えて、ノード間のコネクション情報を構造化データとして定義します。図3a、3bに宣言的に記述されたネットワークトポロジ情報のサンプルと、その情報を基に描画出力された図を示します。このように、機械にとっても人間にとっても理解しやすい形で情報を整備します。

プロビジョニング情報
次にネットワークを構成する各ノードの情報として、インターフェース、論理識別子、ネットワークアドレスといった情報を構造化データとして定義します。人間にとってスプレッドシートは馴染みがあり気軽に扱うことができますが、ここではLLMによる可読性を考慮し厳密にDBスキーマを定義します。ただしスキーマを複雑にしすぎると、LLMが読み取りエラーを起こす傾向があるため微調整する必要があります。

ステップ2　コマンドシナリオ生成に必要な情報を取得するフローの設計
次のステップでは、コマンドシナリオを生成するために必要となるフローを定めます。ステップ1で定義されナレッジベースに整備されているデータが、検索拡張生成の仕組みによって上手く抽出できるかテストとデバックを繰り返す必要があることから、小さな単位でフローを設計します。(図4)

LLMに期待する役割としては、フロー1～3においてはコマンドシナリオの生成に必要なパラメータをナレッジベースから取得するためのSQLクエリの生成、フロー4ではそれまでに取得したパラメータと内部知識を統合した最終的なコマンドシナリオの生成となります。

ステップ3　プロンプトの設計
最後のステップでは、ステップ2で設計したフローと対になる形でプロンプトを設計します。今回使用した具体的なプロンプトの一部を図5に示します。実際には、それぞれのプロンプトに対して検索拡張生成を有効に機能させるためのDBスキーマや期待する形で回答を出力させるためのテンプレートを付帯情報として組み込みます。ここでも、小さな単位でプロンプトを設計し、テストとデバックを繰り返しながら調整していきます。

以上のステップで生成AIシステムの実装を進めることで、今回の取組みの目標を概ね達成可能なことを確認でき、コマンドシナリオの素案作成を省力化することは十分可能と考えます。しかし、他の工事へ適用する際には、今回人手で行ったフローの設計についても自動化できるよう実装の見直しが必要になると考えます。
また、業界のトレンドや代替技術が刻々と進展していく中にあって、採用する要素技術やネットワーク情報の管理方法の変更をはじめとした業務プロセスの見直しについては、慎重かつ大胆な判断が求められます。
そうした見直しに向けた判断を少しでも戦略的に行えるようにするために、私たちはこれまで以上に関連技術の動向を広く深く目利きしていく必要があると考えています。