1.　はじめに

ネットワークを構築する際には，ネットワーク技術者（以下，単に技術者）は要件を満たすようネットワークを設計する[1]．そして，設計したネットワークの妥当性は，本番環境を模した試験環境を用意し，試験により確認する[2]．しかし，実機による試験では機器の調達や構築に伴う金銭的コストや作業負荷の大きさが問題となる．このような問題に対処するため，我々はネットワーク構成の設計仕様となるネットワーク構成モデル[3]を対象に，実機不要なネットワークシミュレータによる自動検証手法[4]や静的解析による一貫性の自動検証手法[5]を提案してきた．そしてこれらの検証結果を踏まえ，修正を加えたネットワーク構成モデルを機器設定に反映させる手法を提案してきた[3]．その一方で，実機を用いない軽量な検証を提案している既存研究として，ネットワーク機器設定を対象に整合性や一貫性を検証するアプローチの研究[2], [6]がある．そして，これらの手法[2], [4], [5], [6]では，検証可能な内容が互いに異なる．例として，藤田らの手法[5]では主に，機器設定の字句解析や構文のエラーの詳細な原因を指摘可能であり，「設定記述の妥当性」を直接的に検証できる．これに対し，Fogelらの手法[6]では主に，ルーティングポリシーやアクセス制御リストの影響に関するシミュレーション解析が可能であり，「設定による実行時の影響」を検証できる．

そこで本稿では，ネットワーク機器設定とネットワーク機器設定構成モデルの相互変換によるラウンドトリップ・エンジニアリングの実現を推し進めるべく，ネットワーク機器設定の構文解析によりネットワーク機器設定構成モデルを自動抽出する手法を提案する．モデルベースの検証技術[4], [5]とネットワーク機器設定ベースの検証技術[2], [6]の併用を容易化できれば，設計段階における実機や仮想環境を用いない検証と，運用段階に向けてネットワーク機器設定に基づくシミュレーション等による検証を柔軟かつ相互に実施できるようになり，検証の充実化に繋がる．この実現に向けて，ネットワーク構成モデルからネットワーク機器の設定コマンドを生成する方法は既存である[3]．しかしネットワーク機器設定をネットワーク構成モデルに変換する方法は未確立であるため，技術者にとって手動で機器設定とモデルを変換しなければならず，双方の技術の併用には大きな負担が伴う可能性がある．そのため，提案手法によるラウンドトリップ・エンジニアリングの推進により，手動によるモデル作成の負荷の軽減を目指すことに加え，検証の充実化を図る．

なお，ここでのネットワーク機器設定とは，show runnig-config コマンド等でネットワーク機器から得られる情報を指す．また，ネットワーク機器設定構成モデルとは，ネットワーク構成モデルから結線情報を除いて，ネットワーク機器の設定項目のみで構成されるモデルを指す．

提案手法の有効性を評価するため，既存のネットワーク機器設定を入力としてネットワーク機器設定構成モデルを抽出し，抽出したモデルからネットワーク機器設定コマンドの生成を行った．その結果，正しいネットワーク機器設定構成モデルおよび機器設定コマンドが得られたため，ネットワーク機器設定とモデルのラウンドトリップの実現において提案手法が有効である見込みを得た．

本稿の構成について，まず2章では本研究で扱う技術について説明する．次に3章では，本稿で提案する手法を説明し，4章では，ケーススタディとその結果を述べる．そして5章で関連研究に触れ，最後に6章で本稿のまとめと今後の課題を述べる．

2.　準備：ANTLRの紹介

ANTLR [7]とは，構造化されたテキストの読み取りや処理，変換をするための解析器を生成できるパーサジェネレータである．ANTLRによる構文解析のフローを図1に示す．ANTLRに文法ファイルを入力することで，字句解析器および構文解析器を生成する．文法ファイルとは，字句規則および構文規則を記述したファイルのことである．字句規則とは，テキストに出現するトークン（意味を持つ最小単位の文字列に分解したもの）を定義したものであり，ANTLRでは字句解析器の生成に用いられる．字句解析器とは，テキストをトークンに分割するプログラムである．構文規則とは，文の構造を決定する規則を定義したものであり，ANTLRでは構文解析器の生成に用いられる．構文解析器とは，構文解析を行うプログラムのことである．構文解析とは，字句解析器によって得られたトークン列から構文規則に則って構文木を生成する手続きのことである．構文木とは，構文解析で得た文の構造を木構造で表したものである．本研究では，ネットワーク機器設定を構文解析するための解析器を生成するツールとしてANTLRを利用する．

3.　提案手法

本章では，ネットワーク機器設定を解析し，ネットワーク機器設定構成モデルを抽出する手法について説明する．提案手法の全体像を図2に示す．提案手法の利用者は技術者とし，提案手法への入力データとしてネットワーク機器設定と文法ファイル，仕様項目・構文要素対応表（以下，単に対応表）を必要とする．本稿ではネットワーク機器設定は技術者が与え，文法ファイルと対応表は提案手法が提供するものとする．これは，ネットワーク機器設定は構築対象のネットワークに依存するために技術者しか提供できないが，文法ファイルや対応表はベンダや機器（機種）ごとに一度定義すれば，再利用可能であると考えたためである．まず，提案手法への入力となるネットワーク機器設定を説明する（3.1節）．次に，提案手法の最終出力となるネットワーク機器設定構成モデルについて説明する（3.2節）．そして，提案手法が提供する，ネットワーク機器設定の文法ファイルを説明する（3.3節）．

提案手法の手順概要を以下に示す．

• (1) 提案手法は入力されたネットワーク機器設定を構文解析して構文木を生成する（3.4節）．
• (2) 提案手法は仕様項目・構文要素対応表を参照しながら構文木を探索し，ネットワーク機器設定構成モデルを抽出する（3.5節）．

そして，提案手法が対応する範囲と限界について述べる（3.6節）．

3.1　ネットワーク機器設定

本節では，提案手法への入力となるネットワーク機器設定の取得方法について説明する．ネットワーク機器設定とは，ルーターやスイッチなどの機器からコマンドにより取得した設定情報を記述したファイルである．本研究ではCiscoのshow running-configとshow version，show vlan-switch，YAMAHAのshow configで取得できるネットワーク機器設定を扱う．リスト1にshow running-configによるネットワーク機器設定の一部を示す．ここではホスト名の設定，VLANインタフェースへのIPアドレスの割り当て，スイッチポートをアクセスポートとしてVLANの割り当てをしている．なお，スイッチポートはシャットダウンしている．

3.2　ネットワーク機器設定構成モデルとその拡張

ネットワーク機器設定構成モデル[3]とは，オブジェクト指向モデリング言語UML（Unified Modeling Language）のオブジェクト図をベースとしたモデルであり，ネットワークの仕様を表現できる．ネットワーク機器設定構成モデルの文法構造を規定した，UMLクラス図記法をベースとしたネットワーク構成メタモデルを図3に示す．ネットワーク構成メタモデルのクラス構造は，ネットワーク機器を設定するコマンドのモード階層に基づいて構成されており，ネットワーク機器設定との親和性も高い．ネットワーク構成メタモデルを規定する主な概念について図中の番号（1）～（4）に対応させ説明する．なお，（4）については従来の概念から拡張した項目である．

• (1) 関連の強い仕様項目をまとめた仕様項目グループをクラスにより表す（例：Config）．
• (2) 仕様項目グループ内で定義される個々の項目を属性により表す（例：deviceModel）．
• (3) 仕様項目グループ間の関係を多重度や関連（仕様項目グループ間を繋ぐ線）により表す．
• (4) ベンダ間で共通の仕様項目（例：ipAddress）は上位の仕様項目グループ（例：EthernetSetting）に定義し，ベンダ特有の仕様項目（例：accessListNumber）は下位の仕様項目グループ（例：CiscoEthernetSetting）に定義し，これらを汎化により表す．

ネットワーク構成メタモデルの拡張として，本研究で扱うベンダであるシスコシステムズ合同会社（以下，単にCisco）とヤマハ株式会社（以下，単にYAMAHA）2社の共通の仕様項目を上位の仕様項目グループにまとめ，CiscoとYAMAHAそれぞれの機器設定にのみ現れる仕様項目を下位の仕様項目グループに定義する．

ネットワーク構成モデルの要素を図4に示す．ネットワーク構成モデルはネットワーク機器設定構成モデルと結線モデルの2つに分類される．ネットワーク機器設定構成モデルとは個々の機器設定を表すモデルである．結線モデルとは，各機器のポート間の接続情報を表すモデルである．本研究では，ネットワーク機器設定構成モデルを抽出対象とする．なお，これらネットワーク構成モデルの分類については従来手法の拡張によるものである．

ネットワーク機器設定構成モデルの詳細を図5に示す．また，ネットワーク機器設定構成モデルを規定する主な概念について図中の番号（5）～（7）に対応させ説明する．

• (5) 仕様項目グループ値（例：Cf1:Config）をインスタンス仕様により表す．コロン左が仕様項目グループ値名（例：Cf1）を表し，コロン右が仕様項目グループ名（例：Config）を表す．なお，仕様項目グループ値名については仕様項目グループ値間での重複を避ける．
• (6) 仕様項目値（例：1812-J）をスロット値により表す．
• (7) 仕様項目グループ値間の関係はリンク（仕様項目グループ値間を繋ぐ線）により表す．

3.3　文法ファイル

本節では，提案手法に入力する文法ファイルを説明する．本研究では，Ciscoのshow running-configとshow versionとshow vlan-switch，YAMAHAのshow configそれぞれによるネットワーク機器設定の文法ファイル^*1を実現した．リスト1に対する字句規則の一部をリスト2に示す．字句規則では，トークンをコロンの左に記述し，これに分類される文字列や正規表現，トークン，それら組み合わせをコロンの右に記述する．文字列の例は'interface'であり，この例はinterfaceという文字列であることを意味する．正規表現の例は[0–9]+であり，0から9までの任意の数字の1回以上の繰り返しであることを意味する．?は0回または1回の出現を意味する．セミコロンは各規則の定義の記述の終わりを表す．また，異なる文字列等を同じトークンに分類するとき，|（バーティカルバー）を用いる．たとえば，9，10行目では文字列が“access”，“trunk”，“dynamic auto”，“dynamic desirable”のいずれかであった場合にトークンMODE_SETTINGに分類することを示す．

また，リスト1に対する構文規則をリスト3に示す．構文規則では，非終端記号から導出される記号列（1つ以上の非終端記号や終端記号の列）を生成規則として列挙する．非終端記号とは，任意の生成規則の左辺（コロンの左）に現れる記号であり，他の記号列と置換できる記号を指す．終端記号とは，生成規則の右辺（コロンの右）のみに現れ，生成規則によってそれ以上は変換されない記号を指し，本稿ではトークンが該当する．構文規則では，非終端記号を左辺に記述し，非終端記号やトークンからなるパターンを右辺に記述する．なお，右辺において非終端記号やトークンを続けて定義する場合は記号の間に空白文字を入れる．例として，16行目の生成規則では，非終端記号access_vlanから終端記号MODE_SETTING，次に非終端記号vlan_numが導出される．14行目により，非終端記号vlan_numからはトークンVLAN，次にトークンNUMが導出される．

3.4　構文解析

本節では，ネットワーク機器設定の構文解析および生成する構文木について説明する．リスト2とリスト3それぞれに示す字句規則や構文規則から生成した解析器により構文解析を行い構文木を生成する．図6に，リスト1に示したネットワーク機器設定を構文解析して生成した構文木を示す．例として，“ip address 192.168.100.1 255.255.255.0”というテキストについて，“ip”をトークンIP（リスト2の5行目），“address”をトークンADDRESS（リスト2の6行目），“192.168.100.1”と“255.255.255.0”をトークンIP_ADDRESS_NUM（リスト2の14行目）として分割し，生成規則if_ip_address（リスト3の11行目）に従って構文木を生成する．

3.5　モデル抽出

構文解析により生成した構文木に対して，行きがけ順深さ優先探索により機器設定に関する文字列の取得および置換処理を行う．提案手法では，構文木の要素とネットワーク機器設定構成モデルの要素との対応付けと置換処理の内容を表す対応表を設ける．表1にCiscoにおける対応表を示す．対応表の「構文木」列は，置換元となる構文木の要素を特定するための情報を表す．また，「処理ルール」列は，特定した構文木の要素に対する置換処理を表す．そして，「ネットワーク構成モデル」列は，置換先となるモデル要素を特定する情報を表す．

まず，置換手順を以下に説明し，構文木の根ノードからすべて探索し終えるまで繰り返す．

• (1) 対応表の「部分木の根」列に含まれる記号rに到達したとき，rに対応づく「仕様項目グループ」の仕様項目グループ値gを生成する．その後，r以降の探索を続けて「部分木の根」列がrであるような「対象ノードの親」列に含まれる記号pに到達したとき，「対象ノード」列に含まれる記号tがpの直下に存在するかどうかを確認する．たとえば図7の手順1において，“ethernet”到達時に“CiscoEthernetSetting”の仕様項目グループ値を生成する．そして，“ethernet”以降の探索時に“interface_setting”に到達したとき，トークンSHUTDOWNが存在するかどうかを確認する．“interface_setting”下の部分木の探索終了時点で，トークンSHUTDOWNを発見できなかった場合はトークンSHUTDOWNが存在しないと判定する．なお，図7中の“shutdown”はトークンSHUTDOWNが表す文字列である．

  

• (2) 表1の「処理ルール」列によりtの置換を行う．「ノードの有無」列は，tの有無による条件分岐の役割を担う．“有”ではtが存在する場合の処理を表し，“無”ではtが存在しない場合の処理を表す．「置換元」列はtが表す文字列の内，置換したい箇所lを正規表現により表すが，本欄に記載がない場合はtが表す文字列を置換しない．「置換先」列はlを置換する文字列を表す．たとえば図7の手順2において，トークンSHUTDOWNが存在するため，表図1の3行目の処理が選択される．「置換元」列の正規表現“.+”は“1個以上の文字”を意味し，置換先の文字列が“true”であることから，トークンSHUTDOWNが表す文字列“shutdown”が“true”に置換される．
• (3) 表1の「ネットワーク構成メタモデル」列を参照し，置換した文字列を仕様項目値に格納する．格納先は「仕様項目グループ」がgであるような「仕様項目」の内，対象ノードの親pと対応づく仕様項目とする．たとえば図7の手順3において，前の手順で得られた“true”を仕様項目グループ値“CiscoEthernetSetting”の仕様項目値“shutdown”に格納する．

次に，仕様項目グループ値間のリンクの生成方法について説明する．図1の「部分木の根」列に含まれる記号r₁に到達したとき，ここで生成する仕様項目グループ値をg₁と呼ぶ．また，r₁を根ノードとした部分木の探索中に，「部分木の根」列に含まれる記号r₂に到達したとき，ここで生成する仕様項目グループ値をg₂と呼ぶ．そして，g₁とg₂の間にリンクを生成する．このように，構文木の根ノードからすべて探索をし終えるまでに検出された部分木の包含関係に基づいてリンクを生成する．なお，構文木の根となる“file”ノードの探索時には，仕様項目グループConfigの仕様項目グループ値を生成する．

たとえば図6の部分木の探索では，まず“file”ノード探索時に仕様項目グループ値“Config”を生成する．“hostname”ノード到達時に仕様項目グループ値“Hostname”を生成する．そして，“Config”と“Hostname”間にリンクを生成する．

リスト1の機器設定から抽出したネットワーク機器設定構成モデルを図8に示す．図6の構文木の黒枠内が抽出対象となる部分木を表しており，“hostname”ノードを根とする部分木，“ethernet”ノードを根とする部分木，“if_vlan”ノードを根とする部分木それぞれの探索により，仕様項目グループ値“Hostname”，仕様項目グループ値“CiscoEthernetSetting”，“CiscoVlanSetting”が作成され，これらと仕様項目グループ値“Config”の間にリンクが生成されている．また，それぞれの仕様項目値に構文木から得られた置換された値が設定されている．

3.6　本稿の提案範囲

ラウンドトリップ・エンジニアリングでは理想的には，対象とするネットワーク機器の設定項目をネットワーク機器構成モデルが網羅し，それらすべての設定値がすべて正しく抽出できる必要がある．また，その逆にネットワーク機器構成モデルから対象とする機器の設定へと網羅的に正しく変換できる必要もある．

その一方で本稿の提案範囲は限定的であり，先行手法[3]-[5]の対応範囲の機器設定に絞ったものとなっている．具体的な提案範囲を以下に示し，そこからの抽出は達成できている．

• (1) ホスト名設定
• (2) イーサネット設定
• (3) VLAN設定
• (4) VLANインタフェース設定
• (5) スタティックルート設定
• (6) STP（Spanning Tree Protocol）設定
• (7) OSPF（Open Shortest Path First）設定
• (8) ACL（Access Control List）設定（フィルター設定）

先行手法[4], [5]では，イーサネットやVLANを含むインタフェースの設定とSTP設定を検証項目として挙げている．そのため現状の提案範囲で先行手法[4], [5]の検証に使用する機器設定を抽出することは達成できた．

提案手法は現時点では前述した機器設定を対象とし，既存仕様との整合性を考慮しながら提案範囲としている．そのため，今後の拡張として，より広範なベンダやOSへの対応を見据えたモデルの一般化を検討する．

4.　ケーススタディ

提案手法の有効性評価として，提案手法が既存ネットワークからネットワーク機器設定構成モデルを正しく抽出できるかを調査するため，適用事例[8]に対し，対応表によるネットワーク機器設定構成モデルの抽出の精度を確かめた．なお，本研究は先行研究[8]を発展させた研究であるため，先行研究[8]と同じ適用事例を用いた．モデルと機器設定の相互変換が可能であるかの調査として，抽出したネットワーク機器設定構成モデルを先行手法[3]へ適用し，生成した機器設定コマンドの精度を評価した．

4.1　適用事例

適用事例[8]となる既存ネットワークの構成を図9に示す．なお，このネットワークは信州大学ネットワークを模倣したものであり，ルーティングプロトコルであるOSPFを適用している．使用する機器はCisco892J（top，dc），Cisco1812J（campus1～campus7）である．

4.2　手順

以下にケーススタディの手順を示す．

• (1) 適用事例のネットワーク機器設定を提案手法に入力してネットワーク機器設定構成モデルを抽出した．
• (2) 抽出したネットワーク機器設定構成モデルの正しさを確認した．
• (3) 抽出したネットワーク機器設定構成モデルを先行手法[3]に入力してネットワーク機器設定コマンドを出力した．
• (4) 出力したネットワーク機器設定コマンドを実機に投入し，設定の正しさを確認した．

4.3　結果

手順（1）（2）について，適用事例ネットワークに提案手法を適用した結果を述べる．抽出したネットワーク機器設定構成モデルから，ネットワークの構築時に設定した1102個の仕様項目値すべてを抽出し，仕様項目・構文要素対応表にて定義した処理ルールに従って文字列が正しく置換されていることを確認した．また，抽出した仕様項目値に対して，それらが与えられた仕様項目（例：vlanNum = 20の左辺）の種類数を計測したところ，32種類であった．これはネットワーク機器設定構成モデルが規定する仕様項目の総種類数が66種類であったことから全体の約48.5%の仕様項目について仕様項目値の正しい抽出を確認したこととなる．そして，仕様項目グループ値間のリンクの生成については，ネットワーク構成メタモデルで定義した関係と等しいリンクが引かれたことを確認した．例として，図9の赤枠内の機器（campus1）に該当するネットワーク機器設定構成モデルの一部を図10に示す．

手順（3）（4）について，抽出したネットワーク機器設定構成モデルを先行手法[3]に適用した結果を述べる．先行手法[3]の出力として，ACLに関する設定10個を除く機器設定コマンドが生成された．また，生成したコマンドを実機に投入したところ，コマンドが機器に正しく設定されたことを確認した．先行手法[3]への適用結果をリスト4に示す．

4.4　考察

4.4.1　ネットワーク構成モデルの抽出

ケーススタディでは，ネットワーク機器設定構成モデルを正しく抽出することができ，提案手法が有効である見込みを得た．先行手法[4]では，ネットワークシミュレータ上で各機器のリンクを設定する際に結線情報が必要となる．また，先行手法[5]においても複数のノード間の整合性およびプロトコルに依存した一部検証で結線情報が必要となる．そのため提案手法の拡張により，LLDP（Link Layer Discovery Protocol）プロトコルの解析による結線情報の仕様項目グループの自動生成について検討していきたい．また，適用事例ネットワークから抽出したネットワーク機器設定構成モデルの仕様項目値数は1000を超えており，モデルの正しさ確認作業にかなりの時間を要した．そのため，モデルに対して設定値の妥当性を自動で指摘可能な先行手法[5]は，より複雑なネットワーク機器設定構成モデルに対して有効であると考えられる．また，32種類の仕様項目について，仕様項目値が正しく抽出されることを確認したが，残りの34種類についての抽出の正しさの確認は今後の課題となる．未確認の仕様項目は，主にスタティックルート設定やSTP（Spanning Tree Protocol）がある．

4.4.2　先行手法への適用

ACLに関する設定を除き，機器設定コマンドが正しく生成されたことを確認したため，機器設定からのネットワーク構成モデル抽出，ネットワーク構成モデルを入力とする検証および機器設定コマンド生成の繰り返しによるネットワーク管理が可能になると考えられる．ACLに関する機器設定コマンドを生成できなかったのは，先行手法[3]が仕様項目グループ値“CiscoAccessList”の空欄の仕様項目値を参照したことで，コマンド生成に必要な仕様項目値が不足していると判断されたことが原因である．CiscoのACLの設定においては，ポート番号の指定などをコマンドに含めなくても設定は可能である．そのため仕様項目値が一部空欄の状態でもコマンドを生成できるよう先行手法[3]も提案手法に合わせて拡張していく必要がある．また他に，先行手法[3]では，Ciscoのコマンド階層に則したネットワーク構成メタモデルを対象に，グラフ探索アプローチによりコマンド生成を行うため，グラフの探索順序に依存して機器設定コマンドの生成結果が変動する．このことが他のベンダの機器設定コマンドに不具合を生じさせる可能性がある．たとえば，YAMAHAの機器設定コマンドでは，Ciscoにみられるコマンド階層が存在しないが，コマンドの入力順序に制約がある設定があり，当該設定に不具合を生じさせる可能性がある．そのため，提案手法の十分な性能確認が今後の課題となる．

5.　関連研究

ネットワーク機器設定の解析によるネットワークの情報抽出および妥当性の検証について，Fogelら[6]はネットワーク機器設定の構文解析により自動検証を行うツール（Batfish）を提案している．Batfishでは構文解析した機器設定をもとにコントロールプレーンとデータプレーンをモデリングし，機器設定の整合性を検証する．ネットワーク構成モデルベースの検証である藤田らの手法[5]とネットワーク機器設定ベースの検証であるFogelらの手法[6]の特徴的な差異について，表2に示す．検証項目や検証に適した状況に差異がみられることから，機器設定コマンドの生成[3]の活用により機器設定に対して提案手法と各手法[5], [6]を併用できるようにすることで，検証の充実化が期待できる．

ネットワークの一元管理の取り組みについて，NAPALM（Network Automation and Programmability Abstraction Layer with Multivendor support） [9]はマルチベンダ対応のネットワーク機器設定管理用Pythonライブラリである．NAPALMは機器設定の接続や取得，操作をベンダに依存しない統一されたコマンドにより実行できる．NAPALMは機器設定の取得や変更等の運用段階における技術を提供するものであるため検証を目的としていない．その一方で，提案手法では設計段階における検証の充実化を目的としているため，双方の技術の利用方法においては住み分けができるものであると考える．

ネットワーク構成のモデル化の取り組みについて，OpenConfig [10]はYANG言語で定義したベンダニュートラルなデータモデルとネットワーク設定制御プロトコルを使用することによるネットワーク管理の標準化の取り組みを行っている．OpenConfigは，主に運用管理の効率化に焦点を当てている．共通の設定項目を定義し，ベンダ固有の設定を拡張する仕組みを備えており，統一的な設定管理が可能である．しかし，OpenConfigの適用範囲は主に運用管理であり，たとえば，新しいベンダ固有の設定を即時に反映できず，設計段階での詳細な構成定義や検証には必ずしも適さない．本研究が扱うネットワーク機器設定構成モデルは，設計段階でのネットワーク構成の定義と検証に焦点を当てている．特に，異なるベンダ間の設定項目の差分を直接的に共通化せず，オブジェクト指向設計の継承を応用した柔軟な拡張手法を採用し，設定項目の差分を共存させる点で，OpenConfigとは異なるアプローチをとっている．

提案手法は，我々の先行手法[8]を改善したものである．先行手法では，異なる仕様項目グループに同名の仕様項目が存在する場合に対応できていなかったが，これを対応できるようにした．また，ネットワーク構成モデルについて，先行研究[8]の段階からACLに関する拡張が行われたが，それでも提案手法はネットワーク機器設定構成モデルを正しく抽出できることを確認できた．

6.　おわりに

本稿では，ネットワーク機器設定とモデルのラウンドトリップの実現を目的として，ネットワーク機器設定の構文解析によるネットワーク機器設定構成モデルの自動抽出手法を提案した．ケーススタディの結果，提案手法によりネットワーク機器設定から正しくネットワーク機器設定構成モデルを抽出できる見込みを得た．また，抽出したネットワーク機器設定構成モデルを先行手法[3]に適用した結果，正しいネットワーク機器設定コマンドを生成できた．そのため，先行手法[4]導入の容易化やモデルと機器設定の相互変換による柔軟なネットワーク設計が期待できる．

本研究におけるプラクティスとは，異なるベンダの機器設定をネットワーク機器設定構成モデルにより統一的に表現する際の工夫や課題をケーススタディを通じて見出したことである．このプラクティスは将来的に，ネットワーク構成モデルベースの検証手法[5]とネットワーク機器設定ベースの検証手法[6]の併用による検証の充実化を図る際に，モデルと機器設定の相互変換を効率化することに寄与する．見出した工夫として，まず，異なるベンダ間の機器設定をモデル化するにあたり，モデルの無用な肥大化を回避しやすいように，意味の共通な設定項目（例：サブネットマスク）を仕様項目グループ単位では共通化し，表示形式の違いを仕様項目グループ値で許容するような抽象化を図り，異なるベンダ間で統一的に扱う方法を提示した．さらに，ベンダごとの新しい設定項目の追加に柔軟に対応できるよう，UMLの継承により，異なるベンダ間でベンダ固有の設定項目を下位クラスとして共存的に定義できるモデルの拡張方法を示した．たとえ型定義を共存的に行ったとしても，対象ネットワークに必要な下位クラスだけを選択してインスタンス化（仕様項目グループ値作成）をすれば，必要最低限のモデルが得られる利点をねらったものである．その一方で，課題としてベンダごとの機器設定間の差異に応じた文法ファイルの定義方法の柔軟性が求められることや，また，文法ファイルとネットワーク構成モデルを対応付ける作業の負担を軽減するための仕組みが必要であった．

上記のような工夫や課題の改善を積み重ねることで，提案手法により既存のネットワーク機器設定から抽出したネットワーク機器設定構成モデルについて，藤田らの手法[5]を応用することで設計段階での誤設定の早期発見や，異なるベンダの機器が混在する環境における一貫した構成定義と検証のプロセスを確立する．特に，ACLやルーティング設定の競合など，ネットワーク構成の整合性を検証することで，実機適用前のトラブルを低減できると考えられる．また，Batfish [6]などのネットワーク機器設定ベースの検証手法と組み合わせることで，設計と運用の両面からの統合的な検証が可能となり，ネットワーク技術者にとっての実用性が向上すると考えられる．こうした検証手法の発展により，本研究のモデルと機器設定の相互変換を効率化し，ネットワークの設計・運用における検証フローの改善に寄与することが期待される．

今後の課題として，さらなるマルチベンダ対応を踏まえたメタモデルの拡充方法の検討や，機器設定を自動検証する手法を先行手法[4]の応用により実現したい．さらに今後の展望として，ベンダ間の機器設定の差異を踏まえたモデル駆動型の機器移行支援や，生成AIを利用して構文要素と仕様項目の対応付けを自動化する手法についても検討していきたい．

謝辞　本研究にご協力いただいたヤマハ株式会社様に深く感謝申し上げます．