DeNAが内製nwcliをAI対応へ拡張　ネットワーク運用を差分管理と擬似機器で自動化

編集: グリットアーツ編集部

公開日：2026年10月14日

3行解説

ニュースの概要

DeNAのIT基盤部ネットワークグループは、2026年10月13日付の技術記事で、内製のネットワーク管理システム「nwcli」の進化を紹介しました。対象はデータセンタ、オフィス、横浜スタジアムなど、数十拠点にまたがる社内ネットワークです。記事では、nwcliをAI時代に合わせて再構成し、設定管理、差分確認、バックアップ、AI Agentとの連携までを一体で扱う運用に広げたと説明しています。

何が新しいのか

新しい点は、nwcliが単なる設定管理ツールから、AIと連携する運用基盤に近い役割へ変わったことです。実装言語はPython中心から、コアをGoに書き直しました。構成も1台のサーバに置く形から、AWS上のECSとLambdaを使う形へ変更しています。さらに、設定の読み出しが遅い機器に対しては、configを丸ごとキャッシュし、kagemusyaという擬似機器でdryrunできるようにしました。

また、IDEALとFACTを分けて管理し、定期的なdiffcheckとfactcheckで状態を揃える設計も特徴です。設定を構造化データではなく生のconfigで扱う方針に変えたことで、共通テンプレートの複雑さを減らし、機器ごとの差をそのまま扱いやすくしています。AIが人の手作業を一部置き換える前提に寄せた結果、運用の中心が「編集」から「差分の判断」に移っています。

グリットアーツ編集部の分析

注目すべきは、Lambda上でAnsibleを動かすために /dev/ptmx と /dev/shm をPythonで再実装し、モンキーパッチで実行可能にした点です。これは発想としては面白い一方、実運用では互換性と保守性の確認が重要になります。Lambdaは便利ですが、実行時間、メモリ、依存ライブラリ、障害時の切り分けに制約があります。PoCでは「どの機器操作までLambdaで安全に回せるか」を先に見極める必要があるとみられます。

もう一つの実務上の価値は、kagemusyaによるdryrunです。実機に触れずに投入コマンドの妥当性を確認できるため、拠点数や機器台数が多い環境ほど効果が出やすい構成です。ただし、擬似機器が再現できるのはあくまでキャッシュされた状態であり、実機固有の挙動や障害時の例外までは完全に置き換えられません。検証の速さと、実機との差分をどう埋めるかが導入判断の分かれ目になります。

日本の現場で考えると

この方式は、データセンタ、オフィス、スタジアムのように拠点が分散し、機器の種類も多い環境と相性がよさそうです。特に、設定変更のたびに実機へ直接入る運用を減らしたい現場では、差分管理とdryrunの価値が大きくなります。一方で、機器ごとに設定を細かく持つため、テンプレートで一括統制したい現場では運用ルールの見直しが必要です。

また、AI Agentに操作権限を持たせる場合は、権限の分離が重要です。記事では、危険な本番操作を避けるために制限付きクライアントを使うとしています。日本の現場では、監査ログ、承認フロー、緊急時の手動切り戻しをどう組み込むかが、AI活用の成否を左右すると考えられます。

導入・検討時に確認したいこと

• Lambdaで実行するAnsibleの対象範囲と、実行時間・メモリ上限に収まるか。
• kagemusyaが再現できる範囲と、実機との差分をどう検出するか。
• IDEALとFACTの更新頻度、diffcheck/factcheckの実行間隔、障害時の復旧手順。
• 機器ごとの生config管理に切り替えた場合の運用負荷とレビュー体制。
• AI Agentに付与する権限の範囲と、本番操作を防ぐ制御方法。

現時点で分かっていないこと

記事からは、Lambda上でのAnsible実行がどの機器・どの処理まで安定して動くのかは分かりません。また、kagemusyaの再現精度や、AI Agentが実際にどこまで自律的に判断するのかも未記載です。運用コストや保守体制の詳細も示されていないため、導入可否は個別検証が必要です。

ネットワーク運用をAIと自動化でどう分けるかは、拠点数や機器の混在度で答えが変わります。既存環境の保守や運用設計を見直す際は、差分管理や検証の置き方を整理しておくことが重要です。

出典: DeNA Engineering