Cisco Catalyst Center SWIM（旧DNA Center）とは｜アップグレード手順と事前チェック・ISSUの条件【2026年10月】

SWIM（Software Image Management）は、Cisco Catalyst Center（2023年まではCisco DNA Center）でCatalystスイッチ・ルーター・ワイヤレスコントローラーのOSイメージを一元管理し、アップグレードまで実行する機能です。「cisco dna swim」と「catalyst center swim」はどちらも同じ機能を指しています。

この記事では、2026年10月時点の現行リリース（3.x系）と保守終了が近い2.3.7.x系の期限を前提に、SWIMの手順、ISSU（無停止アップグレード）を使える条件、失敗時の切り分け、Ansibleでの自動化（ローカルの模擬APIで実測）を順に整理します。

まとめ：SWIMでアップグレードするときの要点

• SWIM＝Catalyst Center（旧DNA Center）のイメージ管理機能。2023年6月に製品名が変わっただけで、機能は同じです。
• 現行は3.x系（3.3.1はControlled Availability、一般提供の最新は3.2.3のSMU）。2.3.7.x系はソフトウェア保守が2026年12月17日に終わり、サポートは2027年6月17日までです。
• 流れは「取り込み→ゴールデンイメージ（3.x系の画面ではstandard）の指定→事前チェック→配布（Distribute）→有効化（Activate）」。3.1.x以降は入口が Provision > Software Image Management に変わりました。配布は帯域を確かめて業務時間中に、リブートを伴う有効化はメンテナンス枠に置きます。
• 事前チェックは3.1.xで14項目、3.2.xで15項目。赤（失敗）が残る機器はアップグレードできません。IOS XE 17.14以降へ上げるときは、MD5認証のSNMPv3などの弱い暗号設定で止まる点に注意します。
• ISSUはSWIMから使える構成が限られます。SD-AccessのCatalyst 9400は2.3.7.9以降・IOS XE 17.12.3以降の単一シャーシ・デュアルスーパーバイザーのファブリックエッジだけが対象で、StackWise Virtualは対象外です。
• Ansibleで自動化するなら、非推奨になった cisco.dnac ではなく cisco.catalystcenter を使います。Playbookが成功で終わっても、更新された機器が0台のことがあります。

SWIMの役割と現行バージョン

DNA CenterからCatalyst Centerへの名称変更（2023年6月）

Ciscoは2023年6月6日のニュースリリースで、Cisco DNA Centerの名称をCisco Catalyst Centerへ変えると発表しました。改名後もAPIのパスは /dna/intent/api/v1/... のままで、Ansibleのモジュールにも dnac の名前が残っています。古い手順書の「DNAC」は製品名としてはCatalyst Centerを指しますが、画面の名前と手順は版によって違います（後述）。

現行リリースと2.3.7.xのサポート期限

Ciscoのリリースノート一覧に載っている3.x系は、2026年10月19日時点で3.3.1・3.2.3・3.2.2・3.1.6・3.1.5・3.1.3です。

2.3.7.xの期限は、CiscoのCatalyst Centerのソフトウェアリリースとサポートの指針に載っている値です（初回のGA/推奨リリース指定は2024-12-17）。3.3.1は営業担当への申請が要る限定提供なので、本番は一般提供の3.2.3系を基準に考えるのが無難です。2.3.7.xでもSWIMは使えますが、保守期限を踏まえてCatalyst Center自体の移行計画を立てておきます。機器の更新先OSが2.3.7.xで扱えるかは、その版のリリースノートの互換性情報で確認します。

SWIMの管理対象と設定バックアップとの区別

SWIMの対象はOSのベースイメージだけではありません。CiscoのPrime Infrastructureからの移行ガイドは、ベースイメージに適用したSMU（パッチ）、サブパッケージ、ROMMON、APのService PackとDevice Packの更新もSWIMが追跡すると説明しています。一方、機器の設定（コンフィグ）のバックアップはSWIMの役割ではありません。IOS XEとIOS XRの違いなど、OS側の整理はIOS-XRとは？Cisco IOS・IOS-XEとの違いと対応機器にまとめています。

画面と用語の版による違い

SWIMの画面は3.1.x系で大きく変わりました。ネット上の手順記事やCisco Validated Design（CVD）のSWIM導入ガイド（2020年、DNA Center 2.1.2.3が対象）は旧画面で書かれているため、自分のCatalyst Centerの版に合わせて読み替えます。

この記事では、版を問わない説明では「ゴールデンイメージ」と書き、3.x系の操作を説明する箇所では画面の表記どおり「standard」と書きます。指しているものは同じで、機種群ごとに「この版にそろえる」と決めた基準のイメージです。

ソフトウェアイメージの取り込み経路と検証

取り込み経路とバージョンごとの制約

3.2.xでは Provision > Software Image Management の Images タブで Import images を押して取り込みます（2.3.7.xは Design > Image Repository）。Importの選択肢は手元のファイルのアップロード、HTTPまたはFTPのURL、ISSU互換性マトリクスのファイルの3つで、これとは別にCisco.comからのダウンロードが推奨されています。

• Cisco.comからのダウンロード：Cisco.comの資格情報（CCO）を登録しておくと、推奨（Recommended）のイメージを一覧から選んでダウンロードできます。CVDは、CCO資格情報が無いとROMMONの更新や推奨イメージの表示、KGVファイルのダウンロードができないと注意しています。
• ローカルファイル：閉域網など、Catalyst Centerがインターネットに出られない環境向けです。
• URL（HTTP／FTP）：社内の配布サーバーに置いたイメージを取り込みます。3.2.xのユーザーガイドは、FIPSモードを有効にしているとURLからは取り込めず、手元のファイルかCisco.comから取り込むよう案内しています。

2.3.7.xのユーザーガイドには「デバイスからのイメージの取り込みは許可されていない」とあります。稼働中の機器のフラッシュにしか無いイメージを使いたい場合でも、いったんファイルとして取り出してから取り込む必要があります。

KGVによる整合性検証

取り込んだイメージは、チェックサムをKGV（Known Good Values）ファイルと照合して整合性を確かめます（Integrity Verification）。一致しないイメージは破損か改ざんの疑いがあるものとして検知されます。CVDは、KGVファイルのダウンロードにもCCO資格情報が必要だとしています。Cisco.comに出られない閉域網では、KGVが新しいイメージに追随しているかを取り込みの前に確認してください。

Image Distribution Serverの台数上限とサイト割り当て

拠点が多い環境では、Catalyst Center本体からWAN越しに全拠点へイメージを配ると、回線と本体に負荷が集中します。外部のImage Distribution Serverは最大3台まで設定でき（System > Settings > Device Settings > Image Distribution Servers）、SFTPとSCPのどちらで配るかもサーバーごとに決められます。ネットワーク階層（サイト・建物・フロア）に関連付けたサーバーは、その配下の全機器への配布を受け持ちます。

ゴールデンイメージ（standard）の指定単位と非準拠判定

デバイスファミリ・ロール・タグ単位の指定

3.2.xでは、Imagesタブでデバイスファミリ（例：Cisco Catalyst 9300 Switch）を開き、対象イメージのメニューから Mark as standard か Mark as standard with conditions を選びます。詳細設定で、デバイスロール（ACCESS・DISTRIBUTION・CORE・BORDER ROUTER・UNKNOWN、全ロール共通はALL）やデバイスタグごとに別のイメージを割り当てられます。コアスイッチは保守リリースの新しい版に早めに上げ、アクセスは1つ前の版に据え置く、といった分け方ができます。2.3.7.xのユーザーガイドは、タグとロールの両方を指定した場合はタグが優先されるとしています。

SMUにもstandardの指定がありますが、3.3.xのユーザーガイドは、対応するベースイメージがstandardでないSMUはstandardに指定できないとしています。先にベースイメージを決め、SMUはそれに従わせる順序になります。

Outdated（非準拠）の判定

基準のイメージを決めると、Catalyst Centerは機種ごとに各機器の稼働イメージと比べ、違う機器を「Outdated」と表示します。逆に、基準を決めていないファミリの機器は比較の基準が無いため、Outdatedとして挙がりません。「更新対象に出てこない機器がある」場合は、まずそのファミリ・ロールに基準のイメージが指定されているかを確かめます。

アップグレード前の事前チェック（Upgrade Readiness）

3.1.xの14項目と3.2.xで増えた1項目

更新対象の機器には、配布の前にアップグレード準備状況の事前チェックが走ります。3.1.xのユーザーガイド（Manage Software Images）に載っている項目は次の14個で、3.2.xのユーザーガイドではこれにxFSU（Extended Fast Software Upgrade）の互換性チェックが加わり15個になっています。

結果はSoftware Image列のOutdatedのリンクに緑か赤のチェックで表示され、赤が残る機器は更新できません。File Transferは既定でHTTPS、次にSCPの順で到達性を確かめます。見落としやすいのはWeak Cryptoで、ユーザーガイドはIOS XE 17.14以降のイメージでは弱い暗号の設定があるとアップグレードがブロックされると明記しています。17.12系から17.15系へ上げる計画なら、MD5認証のSNMPv3ユーザーを先にSHA系へ移しておきます。ほかに引っかかりやすいのは、clock timezone の設定で時刻差の警告が出る（CVDが既知の注意として挙げています）、write memory をしておらずStartup Configが無い、の2つです。Flashの容量不足は、Nexusとワイヤレスコントローラー以外なら警告にとどまり、配布の途中で未使用の .bin・.pkg・.conf ファイルを自動で削除して空きを作ります。

カスタムの事前・事後チェック

標準の項目とは別に、配布と有効化の前後に任意のCLIを実行させる設定があります。更新ワークフローのチェック画面で「add a custom check」を開き、実行タイミング（pre・post・both）、Command Runnerで実行するコマンド、対象の操作（配布・有効化）とデバイスシリーズを指定します。show ip interface brief や show cdp neighbors のように、アップグレード前後で変わってはいけない出力を登録しておくと、「上がったが隣接が戻らない」を作業直後に検知できます。

配布（Distribute）と有効化（Activate）の手順

3.2.xの更新ワークフロー

3.2.xでは、Software Image ManagementのDevicesタブで機器を選んで Update Devices を押すか、Overviewタブの Schedule Update（または Workflows > Image Update）から始めます。ワークフローは次の順に進みます。

1. Task Name：作業名を付ける
2. Select Devices：サイトを選び、対象の機器にチェックを入れる
3. Software Distribution Checks：配布の事前・事後チェックを選ぶ
4. Software Activation Checks：有効化の事前・事後チェックを選ぶ
5. Device Activation Order：有効化の順番（並列・逐次）を決める
6. Schedule Task and Clean Up：有効化を「Now」か「Later」（日時とタイムゾーン）で予約する
7. Summary：内容を確かめて Submit

Schedule Task and Clean Upの「Initiate Flash Cleanup After Activation」にチェックを入れると、有効化の後に稼働イメージだけを残して古いイメージを消します。旧版へ戻す可能性があるうちは外しておくほうが安全です。2.3.7.xでは、インベントリで機器を選んで Actions > Software Images > Update Image から同様のワークフローに入ります。

配布は通常リブートを伴わないので、転送帯域と機器の負荷を確かめたうえで業務時間中に済ませ、リブートを伴う有効化だけをメンテナンス枠に置くのが基本です。CVDの検証（DNA Center 2.1.2.3、Catalyst 9300でIOS XE 16.9.1→16.9.3）では、有効化のリブートで機器が15〜30分ほど到達不能になるとしています。CVDは16.9.1から16.11.1のようなメジャー更新ではROMMONの更新で時間が延びるとしています。ROMMONの更新が要るかは機種と更新経路で変わるので、更新先のリリースノートで確かめてください。

逐次・並列の順序指定と失敗時の中止

2.3.7.x以降は、1つのワークフローの中で機器を「逐次（Sequential）」と「並列（Parallel）」のグループに分け、逐次グループの順番を並べ替えられます。2.3.7.xのユーザーガイドでは、既定は並列グループが先です。Ciscoのブログ（2024年4月）の例では、分配スイッチを含むCatalyst 3650の2台を1台ずつ上げてから、残りのCatalyst 9000系4台を同時に上げています。2.3.7.xの画面では、さらに「Abort on Update Failure」を有効にすると、順番の最初の機器で有効化が失敗した時点で、残りの機器の有効化を止められます。冗長構成を片系ずつ上げる場合は、片系を逐次グループの先頭に置き、この設定を有効にしておきます。片系の失敗に気づかずもう片系まで再起動すると、拠点ごと止まるためです。

ISSU（無停止アップグレード）を使える条件

ISSU（In-Service Software Upgrade）は、冗長化した制御部を片側ずつ切り替えてリブートによる通信断を避ける方式です。機器そのものがISSUに対応していても、SWIMから実行できるかは別に決まっています。

• SD-AccessのCatalyst 9400：2.3.7.xのリリースノートによると、2.3.7.9でIOS XE 17.12.3以降のファブリックエッジに対応しました。対象は単一シャーシ・デュアルスーパーバイザーの構成だけで、StackWise Virtualは対象外です。コントロールプレーンノードやボーダーノードを兼ねる機器も外れます。
• Catalyst 9800：物理の9800のファブリックワイヤレスコントローラーは2.3.7.6で、9800-CLのファブリックワイヤレスコントローラーは2.3.7.9で、いずれもIOS XE 17.3.1以降を条件にISSUへ対応しています。ただし9800側のIOS XE 17.18のリリースノートは、更新先が17.15.1〜17.15.4d・17.18.1・17.18.2の場合はISSUを避け、通常のアップグレードを使うよう求めています（CSCws19380ほか。修正版は17.15.5と17.18.3）。
• 3.2.x以降の手順：更新時にISSUのドロップダウンで「Enable ISSU Upgrade」を選びます。3.2.xのユーザーガイドは、ISSUを「デュアルスーパーバイザーのシャーシ型スイッチ向け」、新しく加わったxFSUを「Catalyst 9300のようなスタック型アクセススイッチ向け」と位置づけ、xFSUはIOS XE 17.18.2以降のCatalyst 9300で使えるとしています。ISSUは長期リリースの中か長期リリース同士（17.3.xから17.6.yなど）でしか使えません。事前チェックのISSU Compatibilityは、稼働イメージと更新先の互換性マトリクスがあるかを見ており、マトリクスのファイルはImage Repositoryから取り込めます。

判断は単純です。機種・構成・IOS XEの版が対応条件を満たし、ISSU Compatibilityが緑で、機器側の既知不具合にも該当しない場合だけISSUを選び、1つでも外れたら通常のリブートで計画する。SD-AccessのCatalyst 9400では、StackWise Virtualや単一スーパーバイザー構成は、ここで引用したISSU対応条件を満たさないため、通常アップグレードのメンテナンス枠を確保してください。稼働中のCatalyst Centerの版で対象が広がっていることもあるので、最終確認はその版のリリースノートで行います。

アップグレードが失敗したときの切り分け

失敗段階別の確認項目と復旧操作

Ciscoの技術ノート226063（Catalyst Center SWIMのトラブルシューティング、2026年6月17日）は、失敗をワークフローのどこで止まったかで分けて調べる手順を示しています。障害ドメインと最初に打つコマンドを整理すると次のとおりです。

同じ文書は、回復を低リスクの操作から順に試すよう求めています。まずインベントリの再同期とコンプライアンスの再実行で解消しないか確かめます。旧イメージで起動している場合は、先に起動モード（Install／Bundle）を確かめます。Bundle modeならブート変数の修正（boot system flash:<target-image.bin> と write memory）を検討します。Install modeの機器は boot system flash:packages.conf から起動するのが前提なので（Catalyst 9300のアップグレード手順）、.binを直接指定せず、show install summary でパッケージの状態を見ます。目的のパッケージが有効なのに未コミットの場合に限って install commit を実行します。別のインストール操作を重ねて始めるのは、状態を把握してからにします。TACへ上げる場合は、タスクID・正確なエラー文言・失敗時刻・現在と更新先の版・Install／Bundleの別・単体かスタックかHAか、を最初にそろえ、TACが障害の経緯を追えるようにします。

通信ポートの確認

配布で止まる原因が経路にある場合は、ポートを確かめます。3.1.xのインストールガイドの通信ポート表では、機器からCatalyst Centerへのイメージ取得はHTTPS（TCP 443）、SFTP（TCP 22）、HTTP（TCP 80）です。同じ表には、PnP・SWIM・EEMなどを使わないならTCP 80を塞いでよいという注記があり、裏を返せばSWIMを使う間は80番を一律に閉じる前提で設計しないほうが安全です。拠点とデータセンターの間にファイアウォールがある場合は、この3つのうち使う方式が通るかを、事前チェックのFile Transferの結果とあわせて確かめます。

AnsibleによるSWIM自動化と模擬APIでの検証結果

SWIMはAPI（Intent API）とAnsibleからもGUIと同じ操作ができます。Ansibleのモジュールがどのような順でAPIを呼ぶかを確かめるため、Catalyst Centerの応答を真似たローカルのHTTPSサーバーに対してPlaybookを実行し、リクエストを記録しました（環境：ansible-core 2.21.5、cisco.catalystcenter 2.13.1、catalystcentersdk 3.2.3.0.4、Python 3.12.13）。実機ではないので、ここで確かめたのはモジュール側の振る舞いだけです。Ansibleでネットワーク機器を扱う基本はAnsibleネットワーク自動化の始め方で説明しています。

cisco.dnacの非推奨化とcisco.catalystcenterへの移行要件

SWIMのAnsibleモジュールは長く cisco.dnac コレクションで提供されてきましたが、Ansible Galaxyの最新版6.51.0（2026年4月23日公開）のメタデータにはDEPRECATED - Use cisco.catalystcenter insteadと書かれています。Ansibleの公式ドキュメントでも、cisco.dnac はAnsible 14の同梱コレクションから削除されたと案内されています。

モジュール名（swim_workflow_manager）とオプションの構造はほぼ同じなので、移行はコレクション名と接続パラメータの接頭辞の置き換えが中心です。ただしPython 3.9のmacOS標準環境ではansible-coreが2.15までしか入らず、cisco.catalystcenter の要件を満たしません。手元で試すなら3.12以上の仮想環境を用意してください。

swim_workflow_managerのPlaybook例

対象イメージをCatalyst Centerへ取り込み済みで、接続先・認証情報の変数を設定し、対象サイトのACCESSロールの機器がCatalyst 9300だけという前提で、1つのタスクで基準イメージの指定から配布・有効化までを指示する例です。配布と有効化はサイトとロールで絞っており、機種では絞っていません。機種が混在するサイトでは、device_series_name や機器のシリアル番号などで対象を明示してください。

- name: SWIM - golden tag, distribute, activate
  hosts: localhost
  connection: local
  gather_facts: false
  tasks:
    - name: Upgrade access switches at one site
      cisco.catalystcenter.swim_workflow_manager:
        catalystcenter_host: "{{ catalystcenter_host }}"
        catalystcenter_username: "{{ catalystcenter_username }}"
        catalystcenter_password: "{{ catalystcenter_password }}"
        catalystcenter_verify: true
        catalystcenter_version: "3.2.3.0"
        state: merged
        config:
          - tagging_details:
              image_name: cat9k_iosxe.17.12.05.SPA.bin
              device_role: ACCESS
              device_image_family_name: Cisco Catalyst 9300 Switch
              site_name: Global/Japan/Tokyo/HQ
              tagging: true
            image_distribution_details:
              image_name: cat9k_iosxe.17.12.05.SPA.bin
              site_name: Global/Japan/Tokyo/HQ
              device_role: ACCESS
            image_activation_details:
              image_name: cat9k_iosxe.17.12.05.SPA.bin
              site_name: Global/Japan/Tokyo/HQ
              device_role: ACCESS
              schedule_validate: false
              activate_lower_image_version: false
              distribute_if_needed: true
              device_upgrade_mode: install

このPlaybookを模擬APIに対して実行すると、モジュールは最初に POST /dna/system/api/v1/auth/token でトークンを取り、イメージ名の照会（GET /dna/intent/api/v1/image/importation）、サイトの照会、デバイスファミリの識別子の取得を経て、ゴールデンタグを POST /dna/intent/api/v1/images/{イメージID}/sites/{サイトID}/tagGolden に本文 {"productNameOrdinal": 1, "deviceRoles": ["ACCESS"]} で送りました。Ansibleでの機器設定の変更全般はCisco機器をAnsibleで設定変更する手順も参考になります。

実測で分かった3つの落とし穴

1. catalystcenter_version は実機の版に合わせる。同じPlaybookで値を "2.3.7.6" に変えると、ゴールデンタグの処理が旧方式のAPIに切り替わり、tagGolden へのPOSTは出ませんでした（模擬APIは新方式の応答しか返さないため、この実行は旧方式の処理の途中で失敗しています）。モジュールのソースは3.1.3.0を境に呼ぶAPIを分けています。実機より新しい値を書くと、存在しないAPIを呼ぶことになります。

2. 存在しないキーは黙って無視される。image_activation_details に存在しないキー（upgrade_order: sequential）を1行足したPlaybookは、--syntax-check を通り、実行しても警告なしで元のPlaybookと同じ35件のリクエストを送り、同じ結果で終わりました。逐次で上げるつもりの指定が効いていなくても、Ansible側では気づけません。一方、device_role に存在しない値（EDGE）を書いた場合は、構文チェックは通るものの、実行時にThe specified device role 'EDGE' is not recognizedの検証エラーで止まりました（終了コード2）。モジュールが値を検査するのは定義済みのキーだけなので、オプション名はモジュールのドキュメントと突き合わせ、本番の前に検証用のCatalyst Centerで対象と結果を確かめてください。

3. 終了コード0でも、更新された機器が0台のことがある。対象の機器が1台も見つからなかった実行では、Playbookの終了コードは0で、結果は "status": "success"、メッセージは「no eligible devices were found」でした。加えてモジュールの説明には、既定ではCatalyst CenterがIMAGEのコンプライアンスで NON_COMPLIANT と判定した機器だけを配布・有効化の対象にし、ゴールデンイメージ未指定（NOT_APPLICABLE）の機器は飛ばすと書かれています。CIで回すなら、終了コードではなく msg と更新対象の台数を assert で確かめる処理を後ろに足してください。

自動化の前提として、事前チェックで弾かれる設定をあらかじめ機器側でそろえておくと失敗が減ります。設定変更の影響を本番の前に検証したい場合は、Batfishでネットワーク設定を本番前に検証する方法が使えます。キャンパスネットワークとクラウド側の構成をまとめて見直したい場合は、弊社のインフラ構築（AWS・Google Cloud・Azure）支援でもご相談を受けています。

よくある質問

DNA CenterからCatalyst Centerへ名前が変わったのはいつですか？

Ciscoが2023年6月6日のニュースリリースで発表しました。製品は同じで、SWIMを含む機能もそのまま引き継がれています。APIのパスやAnsibleの一部モジュールには、今も「dna」「dnac」の名前が残っています。

SWIMでコンフィグ（設定）のバックアップはできますか？

できません。SWIMが扱うのはOSイメージとSMU・サブパッケージ・ROMMONなどのソフトウェアです。アップグレード前の設定の保全は、機器側での write memory と、Catalyst Centerの設定アーカイブで別に行い、作業前の機器設定を取得・エクスポートできることを確認します。Catalyst Center本体のバックアップは、管理システム自体の復旧用として区別してください。「catalyst center backup」で探している場合は、SWIMとは別の機能です。

アップグレードに失敗したら元の版に戻せますか？

技術ノート226063は、作業前に戻し手順を用意しておくことを前提にしています。戻し方は機種と起動モードで異なります。Bundle modeでは正常な.binへのブート指定を検討できますが、Install modeではパッケージの状態を確認し、機種別の公式手順に従ってロールバックまたは旧版の再インストールを行います。フラッシュに旧イメージを残しておかないと戻せないため、容量不足で旧イメージを消す場合は、外部のサーバーにも置いておきます。

ゴールデンイメージの指定は必須ですか？

SWIMで機器をまとめて更新するなら必須と考えてください。CVDは、グローバルやサイト単位でアップグレードする前に、デバイスファミリごとにゴールデンイメージを設定しておく必要があるとしています。Ansibleのモジュールも、既定ではゴールデンイメージとの比較で非準拠と判定された機器だけを更新対象にします。

SWIMを使うのにライセンスは関係しますか？

関係します。3.1.xの事前チェックにはService Entitlementがあり、機器に有効なライセンスが無いと赤になってアップグレードに進めません。更新先のイメージが手持ちのライセンスで使えるかは、Ciscoの販売店か担当窓口で作業前に確認してください。

関連記事

• IOS-XRとは？Cisco IOS・IOS-XEとの違いと対応機器・最新版26.3.1【2026年10月】
• Cisco機器をAnsibleで設定変更する手順：cisco.ios・cisco.nxos・cisco.aciのPlaybook例【2026年10月】
• Ansibleネットワーク自動化の始め方：network_cliで設定変更とバックアップを自動化する手順【2.21系】
• Batfishとは？ネットワーク設定を本番前に検証するOSSの仕組みと使い方