1.　はじめに

情報通信ネットワークは現代社会における重要なインフラの1つであり[1]，設計者の意図どおりに正しく動作することが求められる[2]．そのためには，設計したネットワークが意図に沿った構成となっているかを確認することが重要である．一般には，その確認手段として，実機を用いて本番環境を模した試験環境を構築し，その中で動作を確認する方法が用いられる[3]．しかし実機を用いた試験では，機器の準備や構築に費用や手間がかかる[4]ため，実機を用いない検証手法として，ネットワーク設計時に定められたトポロジや各機器の設定情報を基に検証する手法[3], [5]や，ネットワーク情報を形式的に記述した，ネットワーク構成モデル[6]を活用した，静的検証手法[7]および動的検証手法[8]が提案されている．

これらの手法[3], [5], [7], [8]では，検証可能な項目や得意とする観点が互いに異なる．そのため，複雑なネットワークを検証するには，複数の手法を組み合わせ，それぞれの検証結果を相互に参照しながら整合性を確認することが重要であるが，それぞれの検証結果は異なる情報を基準に提示されるため，相互に参照しながらの検証作業は容易ではない．ここで，検証手法[3], [5]はそれぞれネットワーク機器の設定情報を基に作成したトポロジデータやDatalogに基づいて検証を行うが，静的検証[7]および動的検証[8]は共通してネットワーク構成モデルを基に検証する．この性質により，両手法[7], [8]の検証結果は同一モデル上で相互に関連付けやすく，他の手法と比べて相互に参照しながら検証しやすい．しかし，両検証結果の提示形式には，問題機器の特定における効率性と有効性の観点から課題が残されていると考える．

静的検証では，すべての情報がネットワーク構成モデル上にまとめて表示されるため，構成の全体像や各機器の設定間の関係を把握しづらく，必要な情報を効率的に抽出・把握することが困難であるといった課題がある．一方，動的検証では，リンク障害発生箇所や経路ごとに検証結果が個別に分かれて提示されるため，複数の結果を比較するには都度表示を切り替える必要があり，効率的な確認が困難であるといった課題がある．このように，従来手法[7], [8]の検証結果の提示形式には，情報量の多さによる認知的な負担や，情報の個別提示による比較の困難さの問題がある．

そこで本稿では，静的検証[7]および動的検証[8]の結果を統合し，可視化することで，従来手法[7], [8]における検証結果提示形式の課題を改善し，問題機器の特定における効率性と有効性の向上を目的とした検証結果可視化手法を提案する．提案手法の設計にあたっては，ネットワーク設計者の背景知識を活用し，静的・動的検証手法との親和性を高めるため，広く普及しているネットワーク図ベースの提示形式を採用した．そのうえで，従来手法の提示形式に存在する課題を解決するために，情報可視化の設計指針として広く知られているマントラ[9]に基づいた可視化手法を採用している．マントラとは，情報可視化における基本原則の1つであり，「まず全体を見た後（overview），ズームやフィルタリングを行い（zoom and filter），必要に応じて詳細を見る（details-on-demand）」という三段階の操作を通じて，情報を段階的に理解・操作できるよう支援する設計指針である[9]．本研究ではこの原則を応用することで，検証結果の全体構造と個別の情報を統合的に確認できるインタフェースを実現し，検証作業の効率性と正確性の向上を図る．

提案手法の有効性を評価するために，ネットワーク構築に関する実務経験者を交えた参加者実験を実施した．実験では，問題機器の特定作業において，提案手法と従来手法[7], [8]のそれぞれを用いた場合の結果を比較し，また特定作業終了後に各手法に関するアンケートを実施した．その結果，静的検証結果と動的検証結果を統合して分析する必要があるネットワークにおいて，従来手法と比べて提案手法が有効である見込みを得た．

本稿の構成について，まず2章では本稿で扱う技術およびその技術が持つ課題について説明する．次に3章では提案手法について説明し，続いて4章では提案手法の有効性を評価するための実験とその結果および考察を示す．そして5章で関連研究について触れ，最後に6章でまとめと今後の課題を述べる．

2.　準備

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

ネットワーク構成モデルは，ネットワークの構成情報を形式的に記述するモデルであり，その記法構造を定義したネットワーク構成メタモデルを基に構築される[6]．これらはそれぞれ，UML（Unified Modeling Language）[10]のオブジェクト図記法とクラス図記法を応用して記述される．図1に，ネットワーク構成メタモデルの一部を示す．本モデルの要素を図1中の（1）～（3）に対応させて説明する．

• (1) 仕様項目グループ：ネットワーク構成におけるモードや機能等を単位とした概念構造を表す．（例：Config）
• (2) 仕様項目：仕様項目グループに含まれる項目であり，「項目名：型」の形式で示す．（例：name : string）
• (3) 関係：仕様項目グループ間の関係を表す．

図2に，ネットワーク構成モデルの一例を示す．本モデルの要素を図2中の（4）～（6）に対応させて説明する．

• (4) 仕様項目グループ値：仕様項目グループを値化したもの．また，仕様項目グループ値を区別するためのラベルを識別子と呼び，図中では各四角形の上部に「値名：グループ名」の形式で示す．（例：Cf1 : Config）
• (5) 仕様項目値：仕様項目の値を示し，「項目名＝値」の形式で示す．（例：name＝campus1）
• (6) 関係値：仕様項目グループ値間の関係を表す．

提案手法では本モデルに基づいて，異なる複数の検証結果を一貫した形式で提示する．

2.2　静的検証手法

静的検証手法[7]では，ネットワーク構成モデルの記述を解析することで，記述ミスや不整合などの問題を検出する．表1に静的検証手法の検証項目を示すが，その詳細は文献[7]に任せる．静的検証結果は，ネットワーク構成モデル上の要素が強調され，問題内容をテキストで補足することで示される．さらに，show vlan, show ospfなどのコマンドにより，モデル内容を実機出力に似せて出力できる．

2.3　動的検証手法

動的検証手法[8]では，設計者が作成したネットワーク構成モデル，およびリンク障害発生時における機器間通信の設計仕様（L2L3通信経路設計記述）を入力とし，仮想ネットワークをGNS3（Graphical Network Simulator 3）[11]上に構築して，単一リンク障害を網羅的に模擬する．そして，各機器間の通信経路およびOSPFの状態を取得し，それらとL2L3通信経路設計記述を比較して通信経路やOSPFの状態における不一致の有無を出力する．動的検証結果は模擬したリンク障害箇所ごと，「通信経路」と「OSPF状態」ごとに分類・表示される．そして，L2L3通信経路設計記述と検証結果が対比できるよう示されるが，両者が一致するデータはOKと緑色で示され，不一致なデータはNGと赤色で示される．

動的検証手法では，リンク障害箇所ごとの通信経路およびOSPFの状態を，1つのYAML（YAML Ain't a Markup Language）[12]ファイルとして出力する．リスト1に動的検証結果を表すYAMLファイルの構造を示す．この構造では，最上位キーが障害発生箇所（例：Cf3-Cf4）を示し，その下にcommunication-route（通信経路）およびospf（OSPF状態）の分類がある．「通信経路」では，通信元と通信先をキーとして，通過ノード列がリスト形式で記載される．たとえば，通信元がCf1，通信先がCf4であり，その間にCf2, Cf3を通過していた場合，キーとしてCf1-Cf4が記載され，icmp:というラベルに続いて，リスト形式でCf2, Cf3と記載される．「OSPF状態」では，各ノードごとにインタフェース単位で記述されており，VLAN名，エリアID，ネイバー状態（例：P2P, DR, DOWN）の3要素を持つリストで表現される．たとえばCf1のVLAN10エリア：1のネイバー状態がP2P，VLAN20エリア：2のネイバー状態がDRの場合，キーとしてCf1が記載され，各インタフェースの状態として［VLAN10, 1, P2P］と［VLAN20, 2, DR］がそれぞれリスト形式で記載される．

2.4　静的・動的検証結果の提示形式における課題

表2に，静的・動的検証結果の提示形式における課題をまとめる．静的検証結果の提示形式では以下が詳細な課題と考えられる．

• ・検証結果とネットワーク図の対応関係が不明確
  一般的に，設計者はネットワーク図などのトポロジ情報を基にネットワークを設計する．しかし，静的検証結果はネットワーク構成モデル上に提示されるため，ネットワーク図との対応関係が不明確である．
• ・表示が煩雑になりやすい
  静的検証結果は，ネットワーク構成モデルを基に物理的なトポロジ情報と論理的な機器設定情報が同一の形式で提示されるため，表示が煩雑になりやすい．

また動的検証結果の提示形式では以下が詳細な課題と考えられる．

• ・L2L3通信経路設計記述と検証結果間の比較が直感的でない
  L2L3通信経路設計記述と検証結果の通信経路がそれぞれ文字列で表示されるため，設計者が差異を調べるうえで直感的でない．
  （例）設計仕様と検証結果の通信経路として
  「Cl1 ->Cf1 ->Cf2 ->Cf3 ->Cf4 ->Cf5 ->Cf6 ->Cl6」
  「Cl1 ->Cf1 ->Cf2 ->Cf9 ->Cf8 ->Cf7 ->Cf6 ->Cl6」
  が表示された場合，差異が視覚的に強調されないため，どの部分が異なっているかを直感的に把握できない．
• ・リンク障害箇所ごとの通信経路間が比較しにくい
  リンク障害箇所ごとにその通信経路が表示される．複数の障害箇所の通信経路を同時に表示できるが，文字列間の目視確認が必要なことに加えて，比較したい対象の位置が離れている可能性もあり，設計者が差異を調べるうえで直感的でない．

3.　提案手法：静的・動的検証結果の統合的可視化手法

本章では，2章で紹介した静的検証結果[7]および動的検証結果[8]を，統合的に可視化する手法を提案する．提案手法は，従来手法の課題（2.4節）を改善するために，検証結果の視認性と比較容易性を高めることを趣旨とする．図3に，提案手法の概要を示す．まず設計者は，JSON（JavaScript Object Notation）[13]ファイルとして出力される静的検証手法の検証結果およびYAMLファイルとして出力される動的検証手法の検証結果を提案手法に入力する．その後，提案手法はこれらのファイルをネットワーク図上に統合的に可視化する．

3.1　入力

本節では，提案手法の入力について説明する．入力する動的検証結果は，2.3.2節にて説明した，通信経路およびOSPFの状態を記述したYAMLファイルである．なお，L2L3通信経路設計記述と検証結果のそれぞれでYAMLファイルが得られるため，これらの双方を扱う．

一方，従来の静的検証結果は，モデルエディタ上に示されるのみで，ファイルエクスポートはできなかった．そこで本研究では，静的検証結果をJSONファイルにエクスポートできるよう従来手法を拡張した．JSONファイルは次に詳述するように3種類あり，これらをすべて入力とする．

• ・model.json：ネットワーク構成モデル内の仕様項目グループ値や仕様項目値に関する情報
• ・kanren.json：関係値に関する情報
• ・check.json：静的検証結果

リスト2にmodel.jsonの構造を示し，リスト3にmodel.jsonの例を示す．model.jsonでは，ネットワーク機器の設定を表す仕様項目グループ（例：Config, Vlansetting）ごとに，仕様項目（例：deviceModel, VlanNumber, ipAddressなど）の値（例：cisco1812j, 10, 10.0.1.1など）を示す．なお，idは仕様項目グループ値の識別子であり，kanren.jsonやcheck.jsonが参照．

次に，リスト4にkanren.jsonの構造を示し，リスト5にkanren.jsonの例を示す．このファイルでは，ネットワーク構成モデル上の関係値を，仕様項目グループ値をペアで表す．たとえばリスト5では，仕様項目グループ値VlanSetting/Cf1_VS10が，Config/Cf1と関係することを示す．これは，Cf1の設定がVLAN設定（VS10）と関係することを表す．

最後に，リスト6にcheck.jsonの構造を示し，リスト7にcheck.jsonの例を示す．このファイルは，静的検証結果としてのエラーを列挙する．各エントリは1つのエラーを表しており，errortypeにはエラーの内容を記載し，instancesにはそのエラーに関連する仕様項目グループのキーと仕様項目を記載する．リスト7ではたとえば，「IPアドレスの重複（VlanSetting，同一VLAN）」というエラーが検出されており，VlanSetting/Cf1_VS10およびVlanSetting/Cf2_VS10に設定されたipAddressが重複することを示す．

3.2　検証結果の統合

提案手法では，入力された静的検証結果（JSON形式）および動的検証結果（YAML形式）を統合的に扱うことで，検証観点の異なる2種類の情報をネットワーク図上に可視化する．この統合のためには，両形式における対象機器・構成要素の対応関係を正確に関連づける必要がある．関連付けでは，動的・静的検証結果がいずれもネットワーク構成モデルを介することを活用する．静的検証結果は仕様項目グループ値の仕様項目に与えられ，動的検証結果は通信元から通信先へのノードの連なり（モデル上では，互いに関係がある仕様項目グループ値の連なり）を単位として与えられる．つまり，ネットワーク構成モデル上の仕様項目グループ値等の名前やidをキーに検証結果を関連付けることで実現する．

3.3　検証結果の可視化

本節では，提案手法の可視化における画面構成要素および機能を説明する．図4，図5に提案手法の画面の例を示す．また，表3に提案手法にて表示する要素をまとめる．

3.3.1　マントラとの対応

提案手法では，2.4節で示した課題を解決するため，情報可視化の原則として知られるShneidermanのマントラ「Overview first, zoom and filter, then details-on-demand」[9]を基に提案手法を構成した．

• ・Overview first（まず全体を見る）
  マントラでは，まずユーザが情報全体の構造や概要を把握できる必要があるとされている．そこで提案手法ではネットワーク構成の全体像を把握できるようにネットワーク図を示す．そしてその図は，ネットワーク構成モデルの仕様項目グループに対応した構成要素（ルータ，クライアント）やリンクの表現で構成する．
• ・Zoom and filter（ズームやフィルタリングを行う）
  次にマントラでは，ユーザが関心のある情報に焦点を当てるために，表示範囲の拡大・縮小や情報の絞り込みが可能であることが求められている．そこで提案手法では，ネットワーク図の拡大・縮小機能を提供する．また，設計者が関心のある通信に絞って確認できるように通信経路選択メニュー（図6a）から特定の経路のみを表示する機能を提供する．さらに，設計者は注目すべき箇所が識別しやすいように，設定情報に問題がある機器に赤いバッジを表示し，通信経路選択メニューではL2L3通信経路設計記述と検証結果との不一致がある経路を赤く強調する．

  

• ・Details-on-demand（必要に応じて詳細を見る）
  最後にマントラでは，ユーザが関心を持った要素に対して，必要に応じて詳細な情報を取得できる手段を備えることが重要であるとされている．そこで提案手法では，詳細情報画面（図6b）から任意の機器における詳細な設定情報や検証結果を表示する機能を提供する．

3.3.2　従来手法の検証結果提示形式における課題への対処

提案手法における，2.4節で示した各課題への対処をまとめる．

• ・検証結果とネットワーク図の対応関係が不明確
  検証結果とネットワーク図の対応関係が明確になるように，どの機器でどのようなエラーが検出されているのかを視覚的に確認できる構成とした．図4に示すとおり，提案手法では検証対象のネットワークにおけるトポロジ情報をネットワーク図として表示し，静的検証で検出されたエラーを含むノードに警告バッジ⑥を付与する．また，警告バッジにカーソルを合わせることで，静的検証結果を基に得られた警告の詳細⑦を表示し，詳細情報ボタン⑪から，図6bに示す機器の設定内容やOSPF状態をまとめた詳細情報画面を表示する．
• ・表示が煩雑になりやすい
  表示が煩雑にならないように，物理的な情報と論理的な情報が異なる形式に分離されて表示される構成とした．図4に示すとおり，提案手法では，物理的なトポロジ情報をネットワーク図として可視化し，論理的な設定情報を図6bに示す詳細情報画面にそれぞれ分離して表示する．
• ・L2L3通信経路設計記述と検証結果間の比較が直感的でない
  L2L3通信経路設計記述と検証結果間の差異を直感的に把握できるように，提案手法では図4に示すとおり，L2L3通信経路設計記述に記述された通信経路を青色のリンク③で，動的検証の結果得られた通信経路を赤色のリンク④で示す．たとえば図4のネットワーク図ではCf4-Cf5間の通信において，青色のリンクのみが存在し，赤色のリンクが存在しないことから，L2L3通信経路設計記述ではCf4-Cf5間の直接の通信が記述されているが，動的検証ではCf4-Cf5間の直接の通信が確認できなかったことが分かる．
• ・リンク障害箇所ごとの通信経路間が比較しにくい
  リンク障害箇所ごとの通信経路間を直感的に比較できるように，提案手法では図5に示すとおり，二画面分割表示ボタン⑨および障害発生箇所切り替えボタン⑩を用いることで，左右のキャンバスに異なるリンク障害箇所における通信経路を同時に表示する．

3.4　実装

提案手法は，ReactDiagrams [14]を用いたWebアプリ（以下，提案ツール）として実装した．図7に提案ツールのアーキテクチャを示す．提案ツールは，静的検証結果と動的検証結果を入力することで，これらを内部で統合処理しReactDiagramsによりネットワーク図として描画する．さらに，本ツールのソースコードはGitHubリポジトリ上で管理されており，GitHubへのpushにより，Vercelによる自動デプロイ（CI/CD：Continuous Integration/Continuous Deployment）が実行され，最新の状態が反映される．

4.　評価実験

4.1　実験目的

本評価実験の目的は，設計者による問題機器の特定精度およびユーザビリティの観点から従来手法[6], [7]と提案手法を比較評価することである．

4.2　実験参加者

実践的な評価を行うため，現役の実務経験者を含んだ，ネットワーク構成や設定に関する理解度や経験が異なる11名が参加した．本稿では以降，実験を主導・記録した第一筆者を「実験者」，本実験のタスクに取り組む11名を「実験参加者」と呼称する．実験参加者はその専門性と経験の程度に基づいて，以下の三者に分類した．

• ・ネットワーク実務者（3名）：実務としてネットワークの設計・構築・運用・保守に携わった経験のある者
• ・情報系教員（1名）：大学にて情報工学を専門とする教育・研究に従事
• ・情報系学生（7名）：情報系の学部または大学院に在籍する学生

実験参加者は2グループ（A/B）に分けた．グループ間で実務経験者と未経験者の人数に偏りが出にくいように以下の構成とした．

• ・グループA（6名）：実務者2名，学生4名
• ・グループB（5名）：実務者1名，教員1名，学生3名

以降，実務者および教員をまとめて「専門家」と呼称し，学生は「学生」として扱う．

4.3　適用事例

本実験では，図8に示すように信州大学で運用されているネットワーク構成を模したネットワークを用いた．本事例は先行研究[4], [6]-[8]でも用いられている実践的な事例であり，本研究でも従来と異なる目的で本事例を用いる．このネットワークでは，インターネットへのアクセスポイントに相当するCf1と，データセンタに相当するCf2に加え，7つのキャンパス（Cf3～Cf9）にそれぞれ1台ずつルータを設置し，各ルータの配下にクライアント（Cl1～Cl9）を配置している．ルータ間にはそれぞれ異なるVLANを設定しており，ネットワーク機器間のすべてのリンクに対してOSPFを適用している．OSPFのエリア構成としては，Cf1～Cf2間のリンクをエリア0とし，その他の各セグメントには異なるエリアIDを割り当てることで，通信経路を動的に制御している．さらに，すべてのエリアをエリア0に接続するため，Cf1～Cf2間以外のすべてのルータ間にはVirtualLinkを設定している．

なお，ネットワークトポロジの評価にはTopology Zoo [15]などの公開データセットが用いられることが多い．しかし，これらのデータセットは主に物理的なトポロジ情報を提供するものであり，本研究で対象とするVLAN構成やOSPFのエリア設計，IPアドレスの割り当てといった，実ネットワーク固有の詳細な論理的な機器設定情報を含んでいない．本稿で提案する静的・動的検証の統合可視化手法の有効性を実践的に評価するためには，現場の複雑な設定依存関係を再現した環境が不可欠であったため，データセットを利用するのではなく，実運用されている信州大学のネットワーク構成を模倣し，評価環境として構築するという方針を採用した．

4.4　実験手順

はじめに，実験参加者のネットワークに関する経験を把握するため，事前アンケートを実施した．次に，各実験参加者は2日に分けて作業に取り組んだ．実験参加者は各日でZoomを用い，実験者と1対1でやりとりをした．各日の作業は表4のとおりである．なお，順序効果を緩和するために，グループAは提案，従来の順に手法を使用し，グループBは逆順で使用した．また，出題内容は2パターン（α／β）を用意したが，出題内容間で難易度が揃いやすいように，ネットワーク構成を共通として同一内容の設定ミスを異なる機器に対して適用した．さらには，実験参加者の記憶が薄れやすいように，1日目と2日目は少なくとも1週間を空けた．各日程での実験手順は以下のとおりである．

• (1) 実験者による説明
  実験者が使用手法の位置づけと目的を説明した．また，静的および動的検証により確認可能な項目の概要を示したうえで，その日に使用するツールの操作方法や画面の見方について解説を行った．
• (2) 問題機器の特定作業
  実験参加者は，提示されたネットワーク構成に対し，当該日で指定された手法を用いて，問題のある機器を特定した．作業中には実験参加者の思考過程や着眼点が記録されるよう，操作内容と発話を併せて記録した．
• (3) 事後アンケート
  作業終了後，実験参加者は各手法に対する印象や操作感に関するアンケートに回答した．併せて，ユーザビリティを評価するためにSUSアンケートに回答した．

2日目の実験終了後には，実験参加者に対して1日目の実験内容を想起してもらう時間を設けた．具体的には，1日目に使用した手法の画面を再確認したり，当時のアンケート回答を参照したりすることで，前回の操作内容や印象を思い出してもらった．そのうえで，1日目と2日目に使用したツールを比較し，どちらが問題機器の特定により有効であったかなどを尋ねる比較アンケートを実施した．

4.5　事前アンケート

事前アンケートは，実験参加者のネットワークに関する経験を把握するためのものである．アンケートでは，以下の7項目について，「設定したことがある」「設定値を見たことがある」「聞いたことがある」「知らない」の択一選択式の設問を設けた．

• ・IPアドレス
• ・VLAN
• ・ルーティング（経路制御）
• ・RIP（Routing Information Protocol）
• ・OSPF（Open Shortest Path First）
• ・BGP（Border Gateway Protocol）
• ・MPLS（Multi-Protocol Label Switching）

これらの設問によって，実験参加者の経験や知識が，問題機器の特定精度やツールの評価にどのような影響を与えるかを分析する．特に「IPアドレス」「VLAN」「ルーティング」「OSPF」は，適用事例において実際に使用されている技術である．一方，「RIP」「BGP」「MPLS」は，実験参加者が特定技術のみを予習することを防ぐために設けたダミー項目であり，適用事例とは無関係である．

4.6　問題機器の特定精度の評価

4.6.1　問題パターン

適用事例に対し，3種類の設定ミスをそれぞれ個別の問題として作成した．各問題には異なる機器を対象とした2つのパターン（α／β）を用意した．

問題1：IPアドレスの重複　隣接する機器間で，同一のVLANに同一のIPアドレスを設定する．

• ・パターンα：Cf5のVLAN40に，Cf4のVLAN40と同じIPアドレス（10.0.4.1/24）を設定（変更対象：Cf5）
• ・パターンβ：Cf3のVLAN30に，Cf4のVLAN30と同じIPアドレス（10.0.3.2/24）を設定（変更対象：Cf3）

この誤りは静的検証手法にて誤り箇所を検出可能なため，検出された機器の詳細情報を確認することが重要になると考えられる．

問題2：設定の流し込み先誤り　2台の機器において，VLANおよびOSPFに関する各種設定を互いに入れ替えて適用する．つまり，設定を取り違えて機器に流し込む誤りである．

• ・パターンα：Cf7とCf8のOspfSetting, OspfVirtualLink, OspfInterfaceSetting, Vlan, Vlansettingを完全に入れ替え
• ・パターンβ：Cf5とCf7の設定を同様に入れ替え

この誤りは静的検証手法にて誤り箇所を検出可能であるが，問題機器だけでなく隣接する機器にもエラーを出力するため，複数機器の詳細情報を確認することが重要になると考えられる．

問題3：不要な設定の追加　隣接関係にない複数の機器に，本来不要なOSPFとVLANの設定を追加する．

• ・パターンα：Cf2, Cf4, Cf6, Cf8に以下の不要な設定を追加する．
  • −Cf2：Vlan30，Vlan80の追加；area 2，7のvirtual-linkおよびnetwork設定の追加
  • −Cf4：Vlan20，Vlan50の追加；area 1，4のvirtual-linkおよびnetwork設定の追加
  • −Cf6：Vlan40，Vlan70の追加；area 3，6のvirtual-linkおよびnetwork設定の追加
  • −Cf8：Vlan20，Vlan90の追加；area 1，8のvirtual-linkおよびnetwork設定の追加
• ・パターンβ：Cf2, Cf5, Cf6, Cf7に同様な不要な設定を追加する．

この誤りは問題2と同様に問題機器だけでなく他の機器にもエラーを出力し，また，通信経路に大きく影響を与えるため，静的検証結果と動的検証結果を総合して分析することが重要になると考えられる．

上述の3つの問題は，過去に発生した特定のインシデントそのものではないが，ネットワークの設計・構築の実務経験者が，複数の設計者がネットワーク設定に関わる際，現場で実際に発生しやすく，かつ発見が困難な人的ミス（コピー＆ペーストによる設定漏れや，論理的な設定の取り違えなど）を想定して設計したものである．現場の実践的な検証作業においては，設定ミスが単一機器に留まるものから，隣接機器，さらにはネットワーク全体の動的な経路に波及するものまで，多様な影響範囲を持つエラーを統合的に特定できるかが重要となる．そのため本稿では，数あるネットワーク障害の要因の中から，「単一機器内の局所的なエラー」「隣接機器間の通信を阻害するエラー」「ネットワーク全体の動的ルーティングに波及する広域的なエラー」というように，影響範囲の性質が段階的に異なる3つの問題を意図的に選択した．

4.6.2　精度評価方法

本稿では，実験参加者が設計仕様に反する設定を含む機器をどの程度正確に特定できたかを，Recall（再現率），Precision（適合率），およびF₂ Scoreの3指標に基づいて分析する．Recallは「問題のある機器のうち実験参加者が正しく特定できた割合」を表し，その定義は\[{\rm Recall} = \frac{\textstyle 正しく特定した問題のある機器の数}{\textstyle 問題のある機器の総数}\]

である．Precisionは「実験参加者が特定した機器のうち実際に問題のある機器であった割合」を表し，\[{\rm Precision} = \frac{\textstyle 特定した機器のうち問題のある機器の数}{\textstyle 特定した機器の総数}\]

と定義される．また，F₂ ScoreはRecallをPrecisionよりも重視するための調和平均に基づく総合指標であり，一般のF_βの定義\[F_{\beta} = \frac{(1 + \beta ^2) \ Precision \times Recall}{\beta ^2 \ Precision + Recall}\]

においてβ＝2を代入した\[F_2 = \frac{5Precision \times Recall}{4Precision + Recall}\]

として求められる．

ネットワーク検証において，問題のある機器を見逃した場合，そのまま運用に投入され，通信障害，誤経路選択などの問題が発生する可能性がある．そのため，本稿ではRecall（再現率）を重視し，F₂ Scoreを採用する．これらの指標は，個々の問題（IPアドレスの重複，設定の流し込み先誤り，不要な設定の追加）および手法（提案手法，従来手法）ごとに評価し，その平均値を算出した．

4.7　事後アンケート

事後アンケート（3種類）は，提案手法と従来手法の比較における定量的および定性的評価のためのものである．

4.7.1　SUSによるユーザビリティ評価

ユーザビリティの定量的評価を目的として，SUS（System Usability Scale）[16]に基づくアンケートを実施した．SUSは，ユーザビリティに関する10項目からなるアンケートで構成され，各項目に対して5段階評価（1＝全くそう思わない～5＝非常にそう思う）を行い，最終的に0～100点のスコアが算出される．表5にアンケートの項目を示す．なお，本実験での従来手法では，静的検証手法[7]と動的検証手法[8]を併用しており，ツール単体ではない．そのため，従来手法向けのSUSの各設問で「このツール」という表現を「これらのツール群」と置き換えた．

4.7.2　提案手法の機能別有効性評価

提案手法を使用した日のみ，その表示内容や機能が問題機器の特定において有用であったかを評価する選択式アンケートを実施した．このアンケートでは，以下に示す提案手法の各要素に対して，問題機器の特定において「有効だった」と感じた機能を複数選択式での設問を設けた．

• ・ネットワーク図形式での表示
• ・アイコンやネットワーク図の配置変更機能
• ・問題機器の強調表示（警告バッジ）
• ・各経路の通過回数表示
• ・赤・青のリンクによるL2L3通信経路設計記述と検証結果の通信経路表示
• ・複数経路の重ね合わせ機能
• ・画面の左右分割機能
• ・各種機能をヘッダーのボタンから操作
• ・メモ機能

4.7.3　提案手法と従来手法の比較アンケート

比較アンケートは，以下の観点について選択式（A～C）および自由記述式（D，E）で設問を設けた．選択式のアンケートでは，「提案手法」「従来手法」「どちらでもない」のいずれかを選択させた．また以下の設問における「静的・動的検証手法」は従来手法を表しており，「検証結果表示ツール」は提案手法を表している．

A　どちらの手法が問題機器の特定に有効だと感じたか

B　どちらの手法で見たい情報をすぐに確認できたか

C　どちらの手法で各種情報（機器の設定や経路情報）を比較しやすかったか

D　静的・動的検証結果に関する「良い点」と「イマイチな点」

E　検証結果表示ツールに関する「良い点」と「イマイチな点」

4.8　評価実験の結果

4.8.1　事前アンケートの結果

図9に事前アンケート結果の集計値を示す．ここでは，学生（学生グループ）と実務者・教員（専門家グループ）を分けて集計した．図9から，専門家グループはIPアドレス，VLAN，ルーティングについて全員が「設定したことがある」と回答したことが分かる．一方，OSPFに関しては知識レベルにばらつきがみられ，「設定したことがある」「設定値を見たことがある」「聞いたことがある」といった回答に分かれた．学生グループにおいては，いずれの項目にも「設定したことがある」と回答した人数は2名以下にとどまり，多くの項目で「聞いたことがある」「設定値を見たことがある」という回答が半数以上を占めた．特にOSPFでは「知らない」との回答を複数得た．

4.8.2　問題機器の特定精度の比較

表6に，問題別および手法別のRecall，Precision，F₂の平均値とその差を，差が正のものは青字，負のものは赤字で示す．表6から，問題1ではRecall，Precision，F₂のいずれにおいても従来手法が優位であることが分かる．問題2ではRecallは提案手法が，Precisionは従来手法が優位であることが分かる．また問題3ではRecall，Precision，F₂のいずれにおいても提案手法が優位であることが分かる．

4.8.3　事後アンケートの結果

SUSによるユーザビリティ評価の結果：図10に，提案手法および従来手法それぞれに対するSUSスコアの分布を示す．図10から，提案手法は従来手法と比較して最大値，第3四分位数，中央値，平均値の各観点で高いスコアを得た．専門家のスコアに注目すると，提案手法と従来手法の平均スコアに大きな差はみられなかったが，提案手法のほうがスコアの分布にばらつきがあり，評価が分かれていることが分かる．学生のスコアに注目すると，一貫して提案手法が高い評価を得ており，両手法においてスコアのばらつきは小さいことが分かる．

提案手法に対する機能別有効性評価の結果：表7に機能別有効性評価の結果を示す．なお，有効と回答した人数における専門家と学生の内訳（専門家，学生）を括弧内に示す．最も多くの実験参加者が有効と回答したのは「ネットワーク図形式での表示」（10名）であった．次いで，「問題機器の強調表示（警告バッジ）」および「設計仕様と検証結果の通信経路を赤・青で示すリンク表示」（各9名）も好意的な評価を得た．一方，「アイコンやネットワーク図の配置変更機能」（1名）や「各経路の通過回数表示」（2名）は，有効とする回答が少なかった．また回答の内訳を見ると，4名以下が有効と回答したものは，専門家が支持するものと学生が支持するものが若干分かれたように見える．たとえば，「各経路の通過回数表示」は半分の専門家が支持したが，学生は1名のみの支持に留まった．

4.8.4　提案手法と従来手法の比較評価の結果

表8に提案手法と従来手法の比較評価における選択式の設問の回答結果を示す．「どちらが問題機器の特定に有効であったか」という問いに対して，全員が提案手法を選択した．また，「どちらが見たい情報をすぐに確認できたか」「どちらが各種情報を比較しやすかったか」という操作性に関する問いについても，提案手法を選んだ実験参加者が9名と大半を占めた．なお，従来手法または「どちらでもない」を選択した回答者はすべて専門家であった．

自由記述形式の設問への回答として，以下の意見（要約）が得られた．

• ・提案手法の良い点：ネットワーク全体像を俯瞰しつつ問題箇所や機器情報を視覚的に把握できる点．1つの画面に通信経路や検証結果の情報が集約され必要な項目を選択して確認できる点．UIが使いやすく，自分の見たい情報がどこに格納されているかが分かりやすい点．強調表示により，問題のありそうな機器が一目で分かる点．簡便な操作で複数の通信経路をネットワーク図上に表示できる点．確認した内容をメモに残せる点．
• ・提案手法のイマイチな点：別機器の詳細確認時に項目を開き直す必要があり，不要なモード切り替えが思考上発生する点．2画面分割や障害発生箇所切替など一部機能の使い方が分かりにくい点．通信経路の向きが分からない点．リンク障害を発生させた際，どの部分にリンク障害を発生させたか分かりにくい点．
• ・従来手法の良い点：静的・動的検証結果を明確に切り分けて確認できる点．静的検証において詳細な情報や問題のありそうな箇所が一目で分かる点．時間はかかるが，確実に各要素間のつながりを理解できる点．
• ・従来手法のイマイチな点：情報量が多く必要な情報を探すことが難しい点．ネットワーク全体像の把握がしにくい点．静的・動的検証結果を統合してとらえるのが困難な点．ネットワーク構成を理解するにはネットワーク図を用意し，見比べる必要がある点．

4.9　考察

4.9.1　問題機器の特定精度に関する有効性

表6の結果から，問題によって提案手法と従来手法の優位性が異なることが分かる．問題1はいずれの指標においても従来手法が優位であった．問題1の誤りは機器の詳細情報から判別可能なものであったことから「従来手法の良い点」である「静的検証において詳細な情報が一目で分かる点」が有効に機能したと考えられる．そして，「提案手法のイマイチな点」として「別機器の詳細確認時に項目を開き直す必要がある」ことでの負担が，見落としや誤解に繋がったと考えられる．この結果は，機器ごとに詳細を確認できるよりも，静的検証で指摘のあった項目すべてを一覧できるほうが検証作業として有効なことを示唆するため，指摘があった項目を一覧できるよう機能改善を図る．

問題2の結果は，提案手法が従来手法よりもRecallを高める観点で有効なことを示唆する．提案手法でのPrecisionが相対的に低かったことについて，提案手法ではすべての検証結果を可視化することが既定であり，手動フィルタリングはできるものの「従来手法の良い点」である「静的・動的検証結果の切り分け」に手間が必要である．そのため，既定の表示から疑わしい機器が多く見えてしまった可能性がある．今後は生成AIを導入するなどして，検証結果から推論して必要な情報を絞り込んで可視化する機能等を考案し，Precisionの改善を図りたい．

問3ではいずれの指標においても提案手法が優位であった．問3の誤りは静的検証結果と動的検証結果を統合して分析する必要があるが，提案手法と従来手法の比較評価の結果にて「提案手法の良い点」として「1つの画面に通信経路や検証結果の情報が集約され必要な項目を選択して確認できる点」が挙げられていることから，機器の詳細情報と通信経路を同時に確認するという点において，従来手法と比べて提案手法が有効であったと考えられる．また，問題1から問3にかけて問題機器の数を増やし，検証結果全体を俯瞰しないと問題が見えにくくなるように問題パターンを設定したが，「提案手法の良い点」としての「ネットワーク全体像を俯瞰しつつ問題箇所や機器情報を視覚的に把握できる点」といった提案手法の特徴が，問3での問題機器の特定精度を大きく高めたことに貢献したと考えられる．

4.9.2　ユーザビリティに関する有効性評価

ユーザビリティ評価（SUS）の結果に注目すると，提案手法は従来手法と比較して総じて高い評価を得ていることから，従来手法と比べて提案手法が使いやすいと考えられる．また，提案手法と従来手法の比較評価の結果にて「提案手法の良い点」として「自分の見たい情報がどこに格納されているかが分かりやすい点」が挙げられていることから，従来手法と比べて提案手法では効率的に検証結果を確認できると考える．なお，とくに学生からは提案手法のユーザビリティ評価が高い評価を得たが，これは提案手法のUI設計や情報提示の工夫により，ネットワークに関する経験の浅いユーザでも比較的容易に操作できたことを示唆する．

機能別有効性評価の結果に注目すると，「ネットワーク図形式での表示」や「問題機器の強調表示（警告バッジ）」など，多数が有効と回答した機能に対し，4名以下が有効と回答したものは，専門家と学生が支持するものが若干分かれたように見える．このことから，専門家向けと学生向けとで適切な支援が異なる可能性，あるいは初心者の視点を熟練者の視点へと転換していく支援の必要性が示唆された．

事後アンケートにおける選択式評価では，提案手法が「問題機器の特定」「情報の即時把握」「比較のしやすさ」などの観点で従来手法と比べて多くの支持を得た．自由記述では，ネットワーク全体像の把握や経路・設定情報の視覚化，情報の集約や情報の記載箇所の分かりやすさが言及されており，提案手法が提供する統合的・インタラクティブなインタフェースが選択式評価の支持要因になっている．一方で，詳細情報の閲覧における項目切替や一部機能の使い方が分かりにくいなど操作性に関する課題も指摘されており，詳細情報へのアクセス手順の削減や，各機能のガイドの追加など改善の必要があると考える．

5.　関連研究

田島ら[3]は，実ネットワーク機器から収集した設定情報を基にL1～L3のトポロジモデルを抽出し，実機を用いることなくネットワーク動作を検証する手法を提案している．この手法では，実際のネットワーク環境を模擬した論理的な試験環境を構築することで，設計ポリシや障害時の挙動を机上で評価できる．

Batfish [5]は，入力として与えられたネットワーク機器の設定情報および環境情報をDatalogに基づく論理モデルへと変換し，そこから構成に対応するデータプレーンを導出することで，実機を用いることなく経路整合性や障害時の挙動を検証できる．

これらの関連研究はそれぞれ入力を基に作成したトポロジデータやDatalogといった異なる情報を基準に検証結果を提示するため，同じ構成要素を扱っていても参照する情報の粒度や抽象度が異なり，結果の対応関係を直接比較しにくく，相互に参照し，整合性を確かめながら検証を行うことが困難である．これに対し提案手法では，静的・動的検証結果をネットワーク構成モデルを基に統合し，問題箇所や関連する設定・経路情報を同一の粒度で提示するため，従来は別個に確認する必要のあった情報間の対応関係を直感的に把握でき，問題機器の特定を効率化できる．

また，ネットワークの可視化という観点では，GNS3 [11]において，ネットワーク図上に検証結果を提示するGUIが用いられている．動的検証手法[8]では，GNS3上でリンク障害が1箇所で発生する場合を検証しているため，通常のGNS3の使い方では時間のかかる検証となっている．また，GNS3上では設計仕様および検証結果の経路表示を同時に行うことはできず，提案手法では赤と青のリンクによる表示を行うことで問題機器の特定における効率性と有効性を向上させるという目的を達成している点に貢献がある．

6.　まとめ

本稿では，ネットワーク構成モデルに対する静的・動的検証結果を統合的に可視化する手法を提案した．そして，従来手法との比較実験を通じて提案手法の有効性を検証した．評価実験では，問題機器の特定精度，ユーザビリティ評価（SUS），および定性的評価に基づいて，問題機器の特定における効率性と有効性の分析を行った．

問題機器の特定精度に関する評価では，機器の詳細情報を確認することで問題機器を特定できる場合においては従来手法が優位であった一方，静的検証結果と動的検証結果を統合して分析する必要がある場合においては提案手法が有効である見込みを得た．ユーザビリティに関しては，SUSスコアにおいて提案手法が一貫して高い評価を得ており，特に学生による評価の高さが顕著であった．事後アンケートでは，問題機器の特定や情報比較のしやすさ，表示項目の柔軟な選択，図示された経路情報などが評価され，従来手法と比較して，提案手法の視認性と操作性が利用者にとって有用であることが明らかとなった．一方で，詳細情報の確認に際して操作手順が多い点など，今後の改良が求められる課題も指摘された．また，事後アンケートにて提案手法が「問題機器の特定」「情報の即時把握」「比較のしやすさ」といった観点で評価されていることから，提案手法の各機能が検証作業の効率性や正確性の向上に寄与していると考えられる．

しかし，各機能が与える影響を客観的に評価できていないため，今後は，機能の使用頻度や操作タイミングなどのログを用いた詳細な分析を行う予定である．併せて，提案手法のさらなる操作性改善や，より多様なネットワーク構成・検証内容への対応を進めることで，ネットワーク設計業務における有効性の向上を図る．