1.　はじめに

ネットワークは，無数の組織的活動における必要不可欠なITインフラの1つであり[1]，その設計の失敗はますます許されなくなってきている．一般にネットワーク設計の妥当性は，ネットワーク機器での構築と試験を通じて確認する[2]が，実機による試験では，機器の調達や準備に費用や手間がかかる．また，実機を用意できない場合は，ネットワークエンジニアが属人的に机上で妥当性を判断する[3]が，ネットワークプロトコルに基づく機器間の相互作用は複雑であるため[4]，大規模かつ複雑なネットワークほど机上の判断は現実的ではない．そのため，実機を用いない設計確認を支援する方法として，従来からネットワーク機器構成や設定情報のみから設計を検証する研究がある[3], [5]．田島ら[3]の研究ではモデルで抽象化されたトポロジデータを検査することで機器間の設定の一貫性を検査できる．また，Batfish [5]は，すべてのプロトコルの動作をシミュレートしてフォワーディングテーブルを取得し，その後，データプレーンの検証ツールを使用してネットワークの特性を検証する．

検証すべき設計内容の1つとしては，IPアドレスの重複が無いことや対向機器とのVLANが一致していることなどのネットワーク運用ポリシがある．しかし，前述の従来技術[3], [5]では，ポリシ違反の原因となる設定値を直接的に指摘できないため，エンジニアがその設定値を特定しなければならない問題があった．加えて，Batfishが入力にとるような機器設定内容は，一箇所の構文違反で全体が解釈不能になる問題があった．本問題は，文法があるとはいえ，エンジニアが機器設定内容を1つの文章として手動作成することに起因する．

このような問題の改善に資する技術として，我々はこれまでネットワーク構成モデルを提案してきた[6], [7]．ネットワーク構成モデルとは，オブジェクト指向モデリング言語UML（Unified Modeling Language）を応用してネットワークの構成と機器の設定内容を表すモデルである．本モデルの特徴は，機器設定に必要な項目を図式的に構造化して表すため，エンジニアは項目ごとに設定値を与えればよく，異なる項目の設定値が連なる文章を作成する必要がない．この特徴により，設定値の1つに問題があっても全体が解釈不能になることがないため，問題がある設定値のみを指摘できるようになる．しかし，本モデルに対するネットワーク運用ポリシの自動検証方法が確立されていない課題があった．

そこで，本研究ではネットワーク構成モデルを対象として，静的解析によるポリシ違反の検出と原因となる設定値を指摘することを目的とし，自動検証手法の確立を目指す．

提案手法では，ポリシ違反の検出のためにネットワーク構成モデルに基づいた検証を行い，ポリシ違反の原因となる設定値を指摘する．さらには，設計者が，モデルから情報を収集する手間を緩和するため，モデルの内容を実機が出力する形式に変換する．

評価実験として，OSPF（Open Shortest Path First）プロトコルを用いた実運用ネットワークにおいて，設定誤りを加え，提案手法を適用した結果，9割のポリシ違反の検出および，8割のポリシ違反の原因となる設定値を指摘した．提案手法を改善後，実験において提案手法が検出できなかったポリシ違反を検出できるようになったことから提案手法が有効である見込みを得た．また，モデル変換による設計情報の出力が実機から得られる状態の出力と等価であるかを評価した結果，実機の起動順によって変化する状態以外のすべての情報が等価であることを確認した．

提案手法は我々の先行手法[8]を改善したものである．先行手法では，OSPFプロトコルに対応できなかったが，これに対応できるようにした．また，先行研究[8]では検証用に構築したネットワークを対象として先行手法を評価したが，本評価では実運用ネットワークを対象として提案手法を評価した．

本稿の構成は以下のとおりである．まず，2章では本研究で扱う技術について説明する．そして，3章では提案手法について説明する．さらに，4章は，提案手法の有効性を確認するための評価とその結果についてまとめる．5章では関連研究に触れ，6章でまとめと今後の課題を述べる．

2.　準備

本章では，提案手法に用いる先行研究・技術を説明する．

2.1　ネットワーク構成モデル

ネットワーク構成モデル[6], [7]とは，ネットワークのトポロジや各機器の設定内容をUMLオブジェクト図記法により表したモデルである．ネットワーク構成モデルには，仕様項目をUMLクラス図記法により構造的に規定したネットワーク構成メタモデルがある．図1にネットワーク構成メタモデルを示す．主な構成概念として，関連性が強い0個以上の仕様項目（例：num:int）からなる仕様項目グループ（例：VlanSettingをラベルとする大きな四角形）がある．これらの仕様項目は主にCisco製ネットワーク機器のコマンド体系をもとに定義されている[6]．たとえば，OSPFのネットワーク設定（例：network 172.16.1.0 0.0.0.255 area 0）は，モデルではOspfInterfaceSettingで扱う．例中の“172.16.1.0”はIPアドレスを示しており，ipAddress設定値で扱っている．また，“0.0.0.255”はワイルドカードマスクを示しており，wildcardMask設定値で扱っている．そして，“0”はエリアを示しており，areaId設定値で扱っている．

さらに，仕様項目グループ間の関係（例：ConfigとVlanSettingの間の線）がある．

図2にネットワーク構成モデルを示す．本モデルは次の3点を満たすよう作成される．

（1）メタモデルの仕様項目グループを型とした値（以下，ノード；例：Cf1：Configをラベルとする大きな四角形）を作成する．ここでConfigを仕様項目グループ名，Cf1を仕様項目グループ値名と呼ぶ．

（2）グループごとに仕様項目に値（以下，設定値；例：port = 2における2）を与える．

（3）仕様項目グループの関係と整合するようにグループ値間の線（以下，関連線）を記述する．

メタモデルではネットワーク機器間の結線などの物理設計や，各ネットワーク機器の設定内容（例：EthernetSettingやVlan）などの論理設計を1つの記法で一貫的に記述できる．そして，これらの特徴から設定値ごとの検証が常に可能であり，関連線をたどることで機器間の設定の一貫性を検証できる．そのため，本研究ではネットワーク構成の仕様としてネットワーク構成モデルを採用する．

2.2　静的解析

静的解析[5]とは，ネットワーク機器の設定ファイルを直接解析する方法であり，その利点としては新たな設定がネットワークに適用される前に誤りを検出できることがある．たとえば，rcc [9]は，BGP（Border Gateway Protocol）の重複するルータIDの有無や不足するBGPの設定を検出する．ネットワークの設計および妥当性の確認は手作業であるため，このような単純なミスであっても，大規模ネットワークを人手で設計する場合では看過される可能性はままあり，その結果，ネットワークが正常に動作しない可能性がある[10]．本研究では，ネットワーク機器を用いずにネットワーク構成の設計品質を検証できるように，ポリシ違反の検出に静的解析アプローチを採用する．

3.　提案手法

図3に提案手法の概要を示す．提案手法を利用する状況は，ネットワークの設計者（以下，単に設計者）が，ネットワークに適用する新たな設定をネットワーク構成モデル（以下，単にモデル）に記述している状況とする．設計者は提案手法により設定内容の一貫性検証（3.1節）や，実機が出力する形式での設定内容の確認（3.2節）ができる．

3.1　静的解析による一貫性検証

一貫性検証では，設定値の字句規則を満たさない設定値の検出および設定間の矛盾の検出を目的とする．まず，ノード単体での検証（3.1.1項）をし，無効な設定値や必須な設定値の欠如を検出する．ノード単体での検証でエラーが発生しなければ，複数ノードでの検証（3.1.2項）やプロトコルに依存した検証（3.1.3項）を行う．これらの検証結果をもとに設計者がモデルを修正することでネットワークを洗練する．

3.1.1　ノード単体での検証

ノード単体での検証では，モデルから抽出された設定値が，ネットワーク機器に受容される記号列であるか，またノード内の他の設定値との一貫性が保たれているかを検証する．ネットワーク構成メタモデル上の設定値71個中，機器設定に用いられる68個に対して字句や構文の規則を提供する．

提案手法では，検証エラーの原因が設計者に分かりやすいように，表1の分類で字句や構文の規則を整理した．“分類基準を満たす正規表現”の記法はJava 17の正規表現に基づいている．型の分類ではint型とboolean型に対応した正規表現と違反時の出力をそれぞれ示す．キー，形式については設定値ごとに正規表現と違反時の出力が異なるためEthernetSettingノードのaccessVlan設定値とmode設定値を例に示す．表2に仕様項目と字句や構文の規則との関係を示す．表2では，□は規則の定義があることを表し，–は定義がないことを表す．

ノード内の他の設定値との一貫性検証では，表3の内容を検証する．（a）ではEthernetSettingノードが存在し，かつipAddressかsubnetMaskのどちらかに設定値が存在したとき，もう一方にも設定値が存在するかを検証する．（b）も同様である．（c）～（f）については，指定ノード（例：EthernetSettingノード）が存在したときに，必須の設定値（例：port）が欠如しているかを検証する．これら検証の結果，欠如が検出された場合はエラーを表示する．

3.1.2　複数ノードでの検証

複数ノードでの検証では，接続されているネットワーク機器間での設定の不整合やネットワーク全体でのIPアドレスの重複など，機器間の相互作用により異常動作を生じうる設定誤りを検出する．モデルは，機器の物理的接続情報をLinkノードで表現し，IPアドレスやVLANIDなどの詳細な設定を含むため，L1，L2，L3のレイヤを跨る検証ができる．表4^*1に，複数ノードにおける検証項目を示す．本稿ではそのうち2つの項目について検証方法を紹介する．

まず，表4の“allowedVlanの不一致”について検証方法を説明する．allowedVlanとは，トランクポートで許可されているVLANのことである．allowedVlanが対向機器と一致しない場合，EthernetSettingノードのallowedVlan設定値に誤りがあるか，Vlanノードの作成を忘れている可能性があるため，この不一致を検出する．以下にモデル上で“allowedVlanの不一致”を検証する手順を説明する．

• (1) Linkノードから関連線で接続されたEthernetSettingノードのペア（e₁, e₂）すべてに対し，e₁とe₂のmode設定値がともに“trunk”である場合に次の手順に進む．なお，手順（2）～（4）はe₁とe₂それぞれに適用する．
• (2) EthernetSettingノードのallowedVlan設定値からVLAN番号の集合Mを取得する．
• (3) EthernetSettingノードと関連線で接続されたConfigノードを取得し，さらにそこから関連線で接続されたすべてのVlanノードのnum設定値を取得して，VLAN番号の集合Nとする．
• (4) M ∩ Nで得られた結果をリストに格納する．
• (5) e₁とe₂それぞれから得たリストの内容が互いに一致しない場合にe₁とe₂の双方に“allowedVlanの不一致”を指摘する．

次に，“異なる機器間のIPアドレスの重複”について検証方法を説明する．同一セグメント内でIPアドレスが重複している場合，パケットの不着やネットワークパフォーマンスの低下を引き起こす可能性がある．別セグメントにおいてIPアドレスが重複している場合は，セグメント間の通信（VLAN間の通信など）を行う場合に不具合が生じうる．この問題はIPアドレスの変更や，NAT（Network Address Translation）の利用により対処できるが，設計者の見逃しを防ぐために検証すべきである．提案手法では，EthernetSetting，VlanSetting，Client，OspfInterfaceSetting内のIPアドレスの重複に加え，異なる仕様項目グループ間の重複も検出する．以下では，例としてモデル上でSVI（Switch Virtual Interface）を用いてIPアドレスを設定した場合，つまり，VlanSettingのipAddressが設定されている場合の“IPアドレスの重複”の検証方法を説明する．

• (1) すべてのVlanSettingノードを取得し，それらすべてのipAddress設定値をリストLに追加する．
• (2) L内でIPアドレスpに重複がある場合，pをipAddress設定値に持つVlanSettingノード集合D₁を取得する．
• (3) D₁内のvlanNum設定値iがすべて同一の場合，手順（4）に進む．1つでも異なる場合，D₁内のノードすべてに“異なるセグメントにおけるIPアドレスの重複”と指摘する．
• (4) D₁内の各ノードにおいて関連線で接続されたConfigノードを取得し，その集合C₁を得る．さらにC₁内の各ノードにおいて関連線で接続されたEthernetSettingノードにおいてVlan番号がiであるような任意の1つのConfigノードcを得る．このとき，Vlan番号はmode設定値がaccessの場合accessVlanから取得し，mode設定値がtrunkの場合allowedVlanから取得する．
• (5) 次の2つの条件の下，cからネットワーク構成モデルをグラフ探索し，cを含む到達できたすべてのConfigノードの集合C₂を得る．
  条件1　ConfigとEthernetSetting，Linkのノード3種のみ探索可能とする．
  条件2　Linkノードに関連線で接続された2つのEthernetSettingノードのVlan番号が互いに同じである場合のみ，EthernetSettingノード→Linkノード→EthernetSettingノードの経路を探索可能とする．
• (6) C₂内の各ノードにおいて関連線で接続されたVlanSettingノードを取得し，その集合D₂を得る．D₁とD₂の積集合D₃が2個以上の要素を含むとき，“同一セグメントにおけるIPアドレスの重複”をD₃内のVlanSettingノードすべてに指摘する．また，D₁からD₂を引いた差集合が1個以上の要素を含むとき，“異なるセグメントにおけるIPアドレスの重複”をD₁内のVlanSettingノードすべてに指摘する．

3.1.3　プロトコルに依存した検証

プロトコルに依存した検証では，使用するプロトコルに応じた設定の一貫性について検証する．提案手法では，OSPFとSTP（Spanning Tree Protocol）の検証方法を提供する．設計者が，OSPFを使用する場合，エリアIDやOSPFを有効化するインタフェースの設定を行う．このとき対向機器間でOSPFの設定の不整合が起きた場合，OSPFの隣接関係の確立が行われず，パケットの転送が適切に行われない原因となるためOSPFに関連する設定の欠如や不整合を検出する．

OSPFに依存した検証項目を表5に示す．また，以下に“エリアIDの不一致”について説明する．

• (1) Linkノードから関連線で接続されたEthernetSettingノードのペア（g₁, g₂）すべてに対し，g₁とg₂のそれぞれについてipAddress設定値とsubnetMask設定値から対応するOspfInterfaceSettingノードを特定する．このとき，g₁に対応するOspfInterfaceSettingノードをo₁とし，g₂に対応するものはo₂とする．
• (2) o₁とo₂のエリアID（areaId設定値）を比較して，一致しない場合は“エリアIDの不一致”をo₁とo₂に指摘する．

3.2　設計情報の出力

設計情報の出力では，提案手法はモデルを変換し，ネットワーク機器の出力を模倣した形式で出力する．モデルでは，一台のネットワーク機器に対して複数のノードを関連付けるため，ネットワーク機器が増えるほどモデルが複雑になる．そのため，モデル上でネットワーク機器の設定を確認するには時間がかかる．そこで，提案手法では表6で示す機器設定ファイル，VLANの割り当て，OSPFの情報などの9個の状態確認コマンドを提供し，実機の出力形式に倣い，エンジニアが必要な情報を集約などして確認できるようにする．なお，当該の出力形式はCisco 1812Jのものを模倣する．

提案手法では，コマンド実行時の実機の出力形式をテンプレート化し，モデルから抽出した値を埋め込む．インタフェースごとのOSPFの動作状況の出力テンプレートをリスト1に，値を埋め込んだ出力例をリスト3に示す．たとえば，<VlanSetting:vlanNum>（リスト1の1行目）には指定のVlanSettingノードのvlanNum設定値（リスト3では20）を与える．さらに，モデルの設定値から求められる各機器の状態を埋め込む．たとえば，OSPFでは，各L2セグメントに所属するインタフェースに対して，DR，BDRなどのステートを決定し，インタフェースの状態として出力される．DRは当該L2セグメントにおける通信経路の制御を担い，BDRはDRのバックアップを担う．DRとBDRは，ネットワーク機器のOSPFプライオリティ値やルータIDをもとに，各L2セグメントに対して1台ずつ選定される．提案手法では，モデル内のOSPFプライオリティ値やルータIDをもとに，各インタフェースの状態（DRかBDR）を選定し，リスト1の5行目<DR or BDR>に埋め込む．HELLOパケット送信までの経過時間といった時間的情報などネットワーク構成モデルでは扱えない情報もあり，それらは示せない限界があるが，ネットワーク機器の設定に関する情報ではないため，ネットワーク機器の設定を確認するという観点では問題ない．

また，従来ではVLANセグメントを確認するためには，機器個別に情報を取得して集約する必要がある．このような従来の確認方法を踏襲して情報集約の手間を緩和するため，提案手法では，異なる複数の機器の設定内容等が記述されているモデルから，ネットワーク全体にかかるVLAN情報を集約して出力する．

4.　評価

提案手法の有効性を示すために，設定誤りを含んだネットワークに対して，ポリシ違反の検出および原因となる設定値の指摘を行えるかどうかやモデルの変換により．実機の状態出力情報と等価な出力が行えるかを評価した．本評価では，作成されたネットワーク構成モデルや構築されたネットワークの正しさを，ネットワーク運用管理のエキスパート複数名が確認した．

4.1　適用事例のネットワーク

本評価で用いる適用事例のネットワークの構成について詳解する．図4のネットワークは，信州大学で運用されているネットワーク構成を再現したものである．本研究は先行研究[6]を発展させた研究であるため，先行研究[6]と同じ適用事例を用いた．また，先行研究[6]で提供された正しいモデルをもとに，拡張されたモデルに追加の値を記述することで正しいモデルを作成した．本実験において，入力として利用するネットワーク構成モデルの一部を図5に示す．図5のネットワーク構成モデルは図4に示すネットワークをネットワーク構成モデルを用いて表したものである．

適用事例のネットワークでは，ネットワークへのアクセスポイント（top）とデータセンター（dc），7つの各キャンパス（campus1～campus7）にルータを一台ずつ割り当て，各ネットワーク機器間に異なるVLANを設定している．各ネットワーク機器は，インターネットへ接続するためにtopを経由する必要があり，そのためのリンクをリングトポロジを用いて冗長化している．ネットワーク機器間のリンクすべてをOSPFの適用範囲とし，dcとtop間のリンクをエリア0，各セグメントに異なるエリアを割り当てることで通信経路を動的に制御している．さらに，すべてのエリアをエリア0に接続するため，topとdc間以外のすべてのネットワーク機器間にVirtualLinkを設定している．

4.2　実験1：ポリシ違反の検出と原因の指摘精度評価

設定誤りを含むネットワークに対して，ポリシ違反の検出およびポリシ違反の原因となる設定値を指摘する性能を評価した．

4.2.1　準備

実験手順を以下に示す．

手順1　実験者はモデルを16個複製し，それぞれに表7に示す設定誤りを加えた．

手順2　実験者は各モデルを提案手法に入力し，検証結果を得た．

手順3　実験者が検証結果を参照し，加えた設定誤りと設定誤りが引き起こすポリシ違反を検出できているかを確認した．

本評価では，生成AIを利用してモデルに加える設定誤りを生成することで蓋然性を保証した．表7に評価に用いる設定誤りの概要を示す．表7では“AI”は，生成AIが生成した設定誤りを表し，“AI+実験者”は生成AIが生成した誤りをもとに実験者が定めた設定誤りを表す．

生成AIを用いた設定誤りの導出方法について説明する．本評価では，設定誤りの生成にはChatGPTを使用し，ファイル入力をサポートし，実験実施時点（2024年10月）で最新版であったモデルとしてGPT-4oを採用した．ChatGPTを用いた設定誤りの生成手順とプロンプトを以下に示す．

手順1　ChatGPTにプロンプト「これから送る情報はある大学で運用されているネットワークを再現したものである．OSPFプロトコルを採用しているため，エリアを複数に分けた冗長構成が考慮されている運用形態となっている．そのため，一か所でもネットワーク障害が発生した場合には，迂回経路に自動で切り替わるようなネットワーク構成となっている．また，それぞれのネットワーク機器の名前（hostname）を，campus1からcampus7，dc（データセンタ），top（外部ネットワークの出入口）としている．まずこのネットワークの物理結線情報について送ります．次に，このネットワークについて各ルーターのshow running-configの情報を送るので学習してください」としてネットワークの情報を入力する．

手順2　ChatGPTにプロンプト「ネットワークの物理結線情報をおくります」とともに，ネットワークの物理結線情報についてjson形式のファイルで入力する．

手順3　ChatGPTにプロンプト「<ホスト名>の機器設定ファイルを送ります」とともに，当該機器の機器設定ファイルを入力する．これをすべての機器分繰り返す．

手順4　ChatGPTにプロンプト「このネットワークに対して，設定ミスを考えて教えてください．実際に機器にミスを含ませるとしたらどのようなミスを含ませますか？」としてネットワークに対して考えられる設定ミスを出力させる．

手順5　ChatGPTにプロンプト「他にもあるとしたらできるだけ多く含ませてください」として，他の設定ミスを出力させる．

手順6　ChatGPTが一回の応答で今までと異なる設定ミスを出力しなくなるまで手順5を繰り返す．

リスト2に手順2で入力した物理結線情報についてjson形式のファイルを示す．このファイルにおいて“edges”はネットワーク内の物理的な接続を表す配列であり，“node1”と“node2”はそれぞれのネットワーク機器を示す．“hostName”はホスト名，“interfaceName”は使用されるインタフェースを示す．リスト2に示した例では，図4に示すネットワーク機器“top”と“dc”が物理的に接続されており，それぞれFastEthernetのポート2で接続されていることを表している．また，手順3で入力した機器設定ファイルは図4のネットワークをCisco 1812JとCisco892Jを用いて構築し，「show running-config」コマンドで入手したファイルである．次に，出力された設定誤りを複数のネットワーク運用管理のエキスパートと選定した．選定においては，提案手法の対象であるインタフェースの設定誤り，VLANの設定誤り，OSPFに関する設定誤りの中から，モデルに含まれる設定値の誤りや静的解析で検出すべき設定誤りのみを選定した．たとえば，ChatGPTはOSPFの設定誤りとして，“特定のエリアをスタブエリアに設定するべきところを誤って通常のエリアにする”を出力したが，機器の設定情報からのみでは特定のエリアをスタブエリアに設定すべきか判断できないため，本評価では，検証項目に加えなかった．検証項目の例として，表7の“エリアIDの誤設定”について説明する．“エリアIDの誤設定”とは，ルータのエリアIDに誤った値が設定されている状態を指す．その結果，隣接機器とエリアIDが異なってしまうため，隣接関係を形成できず経路情報が正しく交換されない．本実験では，campus3のOSPFを有効化するエリアを設定する際に，本来は“10.0.5.0 0.0.0.255 area 4”と設定すべきところを“10.0.5.0 0.0.0.255 area 3”と誤ったエリアを設定することで該当の設定誤りを再現し，モデルに加えた．

4.2.2　結果

実験の結果および設定誤りの検出に寄与した検証項目を表7に示す．設定誤りの検出に寄与した検証項目とは，どの検証項目が特定の誤りの発見に有効であったかを記載したものであり，たとえば，“エリアIDの誤設定”行の表5-（3）とは，表5の（3）“エリアIDの不一致”によって検出されたものを示す．表7では，〇はポリシ違反の検出およびポリシ違反の原因となる設定値を指摘できたことを表し，△はポリシ違反の検出はできたが，原因となる設定値を指摘できなかったことを表す．×はポリシ違反の検出ができなかったものを表す．たとえば，“エリアIDの誤設定”は．“campus3_OS4とcampus4_OS4のエリアIDが一致していません”と出力され，該当するOspfInterfaceSettingノードの設定値を指摘できた．評価に用いた16個の設定誤りの内，14個（約88%）のポリシ違反を検出し，13個（約81%）の原因となる設定値を指摘できた．

4.2.3　考察

“エリア0の未設定”では，複数のエリア（エリア2～エリア7）でエリア0に接続されていないという検証結果が出力されたが，エリア0が欠如していることを指摘することができなかった．これは，提案手法が定めた検証項目が“すべてのエリアがエリア0に接続されていること”であり，“エリア0が存在すること”という検証項目を定義していなかったためである．さらに，“VirtualLinkの不足”や“未使用インタフェースの開放”に関しては，これらを検出する検証項目を定義できていなかったが，提案手法を改善し，検証項目を定義した．その結果，評価に用いた16個の設定誤りの内，16個（100%）のポリシ違反を検出し，16個（100%）の原因となる設定値を指摘できた．評価に用いた16個の設定誤りの内，約9割のポリシ違反を検出でき，約8割のポリシ違反の原因となる設定値を指摘できたことや，提案手法を改善後，すべてのポリシ違反を検出し，その原因を指摘できたことから提案手法が有効である見込みを得た．一方で，検証項目のうちどの程度が今回の設定誤りの検出に寄与したかを分析したところ，提案した検証項目27個の内，本実験での設定誤りの検出に寄与した検証項目数は13個（約48%）であった．そのため，本実験で評価できなかった14個の検証項目は，その有効性を今後に評価する必要がある．なお，この14個の項目には，モデル作成上で生じうる整合性のチェック（たとえば，Vlanのnumの欠如）が含まれるため，参加者実験で有効性を評価できる可能性がある．また，今回はOSPFを扱うために問題が生じないループに対する検証項目も含まれるため，他の事例に適用することで評価できる可能性がある．そのため，残りの14項目も評価するために，今後は異なる実験方式や適用事例を対象とした評価実験を計画していきたい．また，本評価の適用事例に加える設定誤りにおいて複数のネットワーク運用管理のエキスパートと選定を行った結果，ChatGPTから出力された設定誤りは実際の設計に起こり得る設定誤りを多く含んでいたことを確認した．特に，“誤ったサブネットマスクの設定”は，誤っていた場合でも通信できる場合があるため，気づきにくい設定誤りであることが確認された．このような気づきにくい設定誤りもChatGPTにおいて生成されることが．知見として得られた．

4.3　実験2：モデル変換による設計情報出力評価

モデルの変換により出力される設計情報が実機から取得する状態の出力と等価であるかどうかを評価した．

4.3.1　準備

本実験では，適用事例に対応するモデルを提案ツールに入力し取得した情報と，実機を用いて構築したネットワークで状態確認コマンドを実行し，取得した情報を比較する．

比較した状態確認コマンドは以下の5つである．

• (1) show running config
• (2) show vlan brief
• (3) show ip protocols
• (4) show ip ospf interface
• (5) show ip opsf neighbor

また実機ネットワークの構築について，Cisco892J（top，dc），Cisco1812J（campus1～campus7）を使用した．

4.3.2　結果

提案ツールから取得したインタフェースごとのOSPFの動作状況をリスト3に示し，実機から取得したインタフェースごとのOSPFの動作状況をリスト4に示す．5種類の状態確認コマンドに対して，得られたそれぞれの出力を比較した結果，“DRとBDRに選出された機器”を除いてすべての情報を実機を模した形式で出力できた．

4.3.3　考察

“DRとBDRに選出された機器”で差異が生じた原因として，提案手法ではDRとBDRに選出する機器を各ネットワーク機器のOSPFプライオリティ値とルータIDをもとに選出しているが，ネットワーク機器を起動する順番や設定する順番については考慮していないことが挙げられる．本実験において，DRとBDRに選出されるルータは，機器に設定を投入する順番によって変動していたため，それぞれの出力に差分が生じた．上記のような差分はみられたが，差分を除いたすべての情報が等価であることを確認できたことから，設計者がネットワーク機器情報を確認する方法として提案手法によるモデル変換による設計情報の出力は有効性があったといえる．

5.　関連研究

ネットワーク機器の設定ファイルと構成から検証を行う研究を紹介し，提案手法と比較する．田島ら[3]の研究では，実機を用いずに設計ポリシが反映されているかを検証できる手法を提案している．しかし，ポリシ違反の原因となる設定値を特定支援する性能の評価を行っていない．これに対し，提案手法では，評価において，ポリシ違反が検出された際に，誤っている設定値を指摘できることを示した．

Batfish [5]はネットワーク機器の設定ファイルとネットワーク構成などの補足情報をDatalogという宣言型言語に変換し，データプレーンを生成する．生成されたデータプレーンの関係に対する，マルチパス整合性，障害時の整合性，宛先の整合性を自動で検証する．これに対し，提案手法では，VLANセグメントの重複やduplexの不一致など，その他の整合性について検証している点において優位性がある．

rcc [9]では，BGPの設定に対して，重複するルータIDやルーティング不可な宛先への設定などパスの可視性とルートの有効性に関する正確性の条件を定義し，自動的検出する．これに対し，提案手法では，複数のプロトコルに対して，一貫性検証を行い，ポリシ違反を検出している．

これらの関連研究の共通点として，ツールへの入力にネットワーク機器の設定ファイルが必要である点が挙げられる．この設定ファイルは本来，ネットワーク機器から取得するものであり，新規構築するネットワークに適用する場合は，手作業で設計に対応する設定ファイルを作成する必要がある．しかし，これらの手法では構文的に不完全な設定ファイルに対する検証をしていない．それに対して，我々の提案ツールでは，設計仕様として活用できるネットワーク構成モデルを用いており，設定値の構文的に不完全なモデルの検証を行っている．

6.　まとめ

本稿では，ネットワーク構成モデルを対象とした静的解析による自動検証手法を提案した．提案手法では，ネットワーク構成モデルを入力し，一貫性検証を行うことでポリシ違反の検出と原因となる設定値を指摘する．実運用ネットワークを適用事例として，設定誤りを加え，提案手法の有効性を評価した結果，約88%のポリシ違反を検出し，提案手法の改善後にすべてのポリシ違反の検出および原因となる設定値を指摘できたことから，提案手法が有効であったことを確認した．さらに，モデル変換による設計情報の出力において，ネットワーク機器の起動順や設定順により変動する値を除いて，すべての状態確認コマンドにおいて実機の出力形式を模倣した形式で出力できたことから，設計者がモデルから設計情報を確認する手法として提案手法が有効であったことを確認した．

今後の課題としては，検証項目を拡充し，そのうえで有効性を評価することが挙げられる．たとえば，OSPFのDR，BDRの選出においてルータIDの設定を前提としたため，ループバックアドレスを考慮した検証ができていない．OSPFの認証機能に関しても，認証の有無や認証方式などに基づく対向機器との整合性は検証できていない．また，IPアドレスの重複はいまだ完全ではない．たとえば，IpRouteのipAddress設定値はスタティックルーティングの宛先ネットワークを示すが，今回スタティックルーティングの設定は検証範囲に含めていなかったため，IpRouteのipAddress設定値の重複は検証していない．これらの問題は，メタモデルの表現範囲が狭いことに起因するものもあるため，メタモデルの拡張とともに検証を実現することで改善する必要がある．また，他ベンダに対応した検証が挙げられる．本稿においては評価としてCisco1812JとCisco892Jを対象として実験を行った．ネットワーク構成メタモデルの仕様項目は，Cisco製ネットワーク機器間で共通性の高いコマンド体系を参照している[6]ことから，Cisco1812Jのみならず，広範な機種に応用可能である．しかし，現状のメタモデルはCisco製を中心としたネットワーク機器を対象としている．Cisco製の機器でない場合は，当該機器の設定項目をネットワーク構成モデルにマッピングして設定値を与えることで提案手法を有効に活用できる見込みがあるが，そのマッピングは手動で行う必要があり，メタモデルで表現できない設定項目はメタモデルを拡張する必要もある．そのため，より広範な，他ベンダのネットワーク機器に対応できるようネットワーク構成モデルの拡充を行う研究が進められている[7]．今後は拡充されたネットワーク構成モデルに応じて，提案手法での検証内容も拡充し，有効性を評価したい．

また，我々はネットワーク構築の自動化への取り組みとして，ネットワーク構成モデルを対象とし，実機不要なシミュレータによる自動検証手法[11]や機器設定手順の自動生成[6]を提案してきた．実機不要なシミュレータによる自動検証手法では，提案手法では対象外とした障害時の検証を行っている．提案手法は機器の設定を確認するコマンドを静的解析アプローチで実装したが，この方法には限界がある．たとえば，“show ip route”などのルーティング情報など機器の動作時に得られる動的な情報には対応できないため，今後はネットワーク構成モデルに基づく動的検証手法[11]を組み合わせることで改善を図りたい．そして，その改善した手法の有効性を評価していきたい．