「最新のネットワーク構成図を出してください」と言われて即答できるインフラチームはほとんどない。Visioやdraw.ioで手書きされた図はインフラ変更のたびに陳腐化し、半年後には実態と乖離する。Scanopy（スキャノピー） はこの問題を根本から解決する、ネットワーク図を自動作成・自動更新するセルフホスト型OSSだ。Rust製のスキャナーがネットワークを能動的に走査し、L2（物理）・L3（論理）・Workloads・Applicationsの4視点で「いま実際に動いているもの」を自動可視化する。AGPL-3.0、★4.8k、Docker Compose一発で起動できる手軽さが評価され、自宅ラボから企業オンプレまで広く支持を集めている。
この記事ではセルフホスト型ネットワーク可視化OSS Scanopyを、「①何ができるか ②何を解決するか ③何を代替できるか」の3点から解説します。AI時代の自動化ツール全体像についてはAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方をご覧ください。
・ScanopyはRust製エージェントレスのスキャナで、ネットワークを定期的に走査して「自己更新するネットワーク図」を自動作成・自動更新するOSS（AGPL-3.0、★4.8k）
・230以上のサービス定義を内蔵し、Home AssistantからPostgreSQL、Dockerコンテナ、Active Directoryまで自動検出。L2／L3／Workloads／Applicationsの4ビューで可視化する
・何を代替するか＝draw.io／Visioの手作業、Excelのアセット台帳、手動更新前提のNetbox。「図を描く」から「図を取得する」への転換を、Docker Composeで2分で試せる
Scanopyとは：ネットワーク図を自動作成・自動更新するセルフホストOSS
Scanopyは「Network diagrams that update themselves（自己更新するネットワーク図）」をキャッチフレーズに掲げる、ネットワーク自動可視化のOSSだ。2026年4月時点で★4.8k、231フォーク、Rust（61.7%）+ Svelte（23.5%）+ TypeScript（9.9%）で実装されている。ポイントは、インフラ図を「書く」のではなく「取得する」発想へ移行できる点にある。
従来のネットワークドキュメンテーションでは、構成変更のたびに人間が図を描き直す前提だった。Scanopyはこの前提をひっくり返す。スキャナデーモンをネットワークに1台置くと、定期的にネットワークを走査し、発見したホスト・サービス・依存関係を自動で図に反映する。つまり「ドキュメントを書く工数」そのものをゼロに近づけるツールだ。
「自己更新」とは、スキャンを一度きりで終わらせず、スケジュールに沿って繰り返し実行し続けることを指す。新しいサーバーを追加すれば次回スキャンで図に現れ、退役させたホストは応答が途絶えた時点で図から消える。人間が「図を更新する」というアクションを一切挟まずに、ネットワークの現状と図が常に同期している状態を保てる。これは監視ツールが「メトリクスを取り続ける」のと同じ発想を、トポロジ（構成）に対して適用したものだと言える。
Scanopyが自宅ラボから企業オンプレまで幅広く採用されている背景には、この「置いておくだけで勝手に最新になる」という運用の軽さがある。Rust製でメモリ・CPUフットプリントが小さく、Raspberry Piクラスの小型機やLXCコンテナ上でも動く。導入のハードルが低いため、まず自宅の1サブネットで試し、有用性を確認してから社内ネットワークへ展開する、という導入パスを取りやすい。
Scanopyで結局「何ができる」のか
Scanopyができることを一言でまとめると「ネットワークの現状を、人手をかけずに常に最新の図として保つ」ことだ。具体的には次を自動で行う。
・サブネット内のホストをARP／ICMP／TCPで発見し、生きている機器を洗い出す
・開いているポートとバナー応答から、そのホストで動いているサービスを230以上の定義で識別する
・SNMP・LLDP／CDPでスイッチのポート結線やVLANを取得し、物理・論理トポロジを描く
・Docker Engine APIでコンテナを検出し、Workloads（ワークロード）として可視化する
・以上を4つのビューに整理し、SVG／Mermaid／Confluence形式でエクスポートする
設計思想：「lspciやnetstatの出力を、ネットワーク全体に拡張したらどうなるか」という発想に近い。インフラの「いまの状態」を能動的に可視化する“active observability”の系譜であり、Terravisionのように静的コード（IaC）を描画する系統とは補完関係にある。
Scanopyが解決する課題と何を代替できるか
ネットワークドキュメントの世界には、長年変わらない痛点がある。Scanopyはこれを「軽量デーモン1台で完結するエージェントレス・アーキテクチャ」で解決する。
・手書き図は即座に古くなる：VLAN追加・サブネット変更・サーバー入れ替えのたびに図を更新するのは現実的でない。書いた瞬間から鮮度が落ちる
・IaC（Infrastructure as Code）でも完璧ではない：Terraform化されていない手動変更（ドリフト）は図に反映されない。「あるべき姿」は分かっても「実際の姿」は分からない
・エージェント方式は導入コストが高い：監視対象すべてにエージェントを入れる必要があり、スイッチ・IoT機器・レガシー機器に対応しづらい
・SaaSは情報セキュリティ要件で使えない：オンプレ機器の内部情報を外部SaaSに送れない組織が多い
デーモンを1サブネットに配置すればポートスキャン・SNMP問い合わせ・サービスバナー検出を自動で行い、サーバー側のWebUIに集約してビジュアライズする。対象機器側には一切インストール不要（エージェントレス）なので、スイッチやNAS、古いアプライアンスまで丸ごと拾える。エージェントを入れられない機器こそドキュメント漏れの温床になりがちだが、Scanopyはそこを外側から観測してカバーする。
課題の構造をもう少し掘り下げると、ネットワークドキュメントは「作った直後がピークで、以降は減価し続ける資産」だという点に尽きる。手書き図もIaCコードも、作成時点のスナップショットに過ぎない。運用が続く限り機器は入れ替わり、暫定対応で開けたポートは閉じ忘れられ、テスト用に立てたコンテナは放置される。Scanopyはこの「時間とともに広がる乖離（ドリフト）」を、能動スキャンによって毎回埋め直す。ドキュメントの鮮度を人間の規律に依存させないことが、最大の価値だと言える。
Scanopyは「何を代替できる」のか
導入判断を明確にするため、Scanopyが置き換える対象を整理する。
| 従来やっていたこと | 代替するScanopyの機能 | 得られる変化 |
|---|---|---|
| draw.io／Visioで手書きの構成図 | スキャンによる4ビュー自動生成 | 「書く工数」がゼロに近づく |
| Excel／CSVのIPアセット台帳 | ホスト・サービスの自動インベントリ | 台帳と実態の乖離が消える |
| 手動更新前提のNetbox（Source of Truth） | 実態スキャンで常時更新 | 「更新し忘れ」がなくなる |
| 属人的な「あのサーバー何だっけ」記憶 | Workloads／Applicationsビュー | 引き継ぎ・障害対応が速くなる |
| ポートスキャンの手動棚卸し | 定期スキャン＋差分検知 | シャドーIT・想定外公開を継続監視 |
重要なのは、Scanopyは「理想（IaC）」を描くツールではなく「実態（active scan）」を描くツールだという点だ。Terravisionのようなコード描画系とは競合ではなく補完関係にあり、両方を持つと構成ドリフトの発見が容易になる。
Scanopyのアーキテクチャ：エージェントレス×単一デーモン×4ビュー
Scanopyの構成は驚くほどシンプルだ。スキャナデーモンとサーバーUIの2コンポーネントで完結し、対象機器側には何もインストールしない。
(VLAN A / B / C)"] -->|"ARP / ICMP / TCP / SNMP"| B["Scanopy Daemon
(Rust)"] B --> C["Scanopy Server
(Svelte+TS UI / Rust API)"] C --> D["Topology Store
(SQLite / Postgres)"] C --> E["WebUI
localhost:60072"] E --> F["L2 view"] E --> G["L3 view"] E --> H["Workloads view"] E --> I["Applications view"] C -->|"SVG / Mermaid
Confluence export"| J["外部ドキュメント"]
複数拠点ある場合は、各サブネットにデーモンを分散配置できる。VPN／オンプレ／クラウドが混在する環境でも、各セグメントの代表ホストにデーモンを置けば全体像が見える。データはサーバー側の Topology Store（SQLite または PostgreSQL）に集約され、WebUI（デフォルト localhost:60072）から4ビューで閲覧できる。
スキャンに使うプロトコル
Scanopyがエージェントレスで情報を取れるのは、複数の枯れたプロトコルを組み合わせているからだ。
・ARP／ICMP：同一L2セグメント上の生存ホストを発見。MACアドレスとIPの対応も取得する
・TCPポートスキャン：デフォルトでtop-1000ポートを走査し、開いているポートを列挙する
・サービスバナー検出：ポート応答のバナーを230以上のfingerprint定義と照合し、サービスを識別する
・SNMP v2c／v3：スイッチ・ルータのインターフェイス情報、VLAN、隣接テーブルを取得する
・LLDP／CDP：機器間の物理隣接関係を辿り、「どのスイッチのどのポートに何が刺さっているか」を描く
・Docker Engine API：コンテナホストに問い合わせ、稼働中コンテナをWorkloadsとして取り込む
いずれも枯れた標準プロトコルであり、対象機器に特別なソフトを入れる必要がない。逆に言えば、これらのプロトコルがファイアウォールで遮断されていると情報が取れないため、スキャナの配置場所（どのセグメントに置くか）とアクセス制御の設計が精度を左右する。
スキャンのスケジューリングと分散デーモン
デーモンとサーバーはトークン認証で通信し、デーモンはスキャン結果をサーバーのAPIに送り、サーバーがそれをトポロジとして統合・保存する。この分離構成のおかげで、スキャナは「観測する場所」に、サーバーUIは「見る場所」に、それぞれ自由に配置できる。
複数拠点・複数VLANを持つ環境では、各セグメントの代表ホストにデーモンを分散配置し、共通のサーバーに集約するのが基本形だ。デーモンごとにスキャン対象レンジとスケジュールを設定できるため、「本番セグメントは1時間ごと、検証セグメントは1日1回」といった強弱をつけられる。スキャン負荷とネットワークへの影響を抑えたい場合は、頻度を落とすかスキャン対象ポートを絞る。
4つのビュー
| ビュー | 内容 | 想定ユーザー |
|---|---|---|
| L2（Physical） | スイッチポート、物理結線、ARPテーブル | NWエンジニア、配線担当 |
| L3（Logical） | サブネット、VLAN、ルーティング、ブリッジ | NW設計、クラウド管理者 |
| Workloads | ベアメタル／ハイパーバイザ／コンテナ | SRE、サーバー運用 |
| Applications | サービス・アプリ・依存関係 | SRE、開発者、PM |
「同じネットワークを4つのレイヤーで見られる」点がScanopy最大の強みだ。L2でケーブル配線図、L3でVPC構成、Workloadsでコンテナ密度、Applicationsで依存関係——同じスキャンデータから異なるストーリーが引き出せる。
L2ビューはスイッチポートと物理ケーブル接続を表示する。LLDP／CDPを使って隣接機器を辿るため、「どのスイッチのどのポートに何が刺さっているか」が一目でわかる。古い配線図と現実の差分を発見するときに最も役立つ。
L3ビューではサブネット・VLAN・ルーティング関係を表示する。DMZと内部LANの境界、VPN経由の他拠点接続などが一画面で把握できる。クラウド管理者がオンプレ・クラウドハイブリッド環境を整理するときに有効で、アドレス設計の重複や使われていないセグメントの発見にも役立つ。
Scanopyが自動検出できるもの：230以上のサービスと4ビューの実例
Scanopyは内蔵の「サービス指紋（fingerprint）」データベースで、ポートスキャンとバナー応答からサービスを自動識別する。READMEで言及されている230以上の定義はカテゴリ別に整理されており、自宅ラボのHome Assistantから企業のOracle DBまで幅広い。
検出可能なサービスのカテゴリ別例
| カテゴリ | 代表的な検出対象 |
|---|---|
| データベース | PostgreSQL／MySQL／MariaDB／MongoDB／Redis／Elasticsearch |
| Web／LB | Nginx／Apache／HAProxy／Traefik／Caddy |
| コンテナ | Docker（Engine API）／Kubernetes API server／Portainer |
| 自宅／NAS | Home Assistant／Plex／Jellyfin／Synology DSM／TrueNAS |
| 監視／ロギング | Prometheus／Grafana／Loki／InfluxDB |
| エンタープライズ | Active Directory／LDAP／Exchange／SMB |
| ネットワーク | OpenWrt／pfSense／OPNsense／VyOS |
| 開発支援 | GitLab／Gitea／Jenkins／SonarQube |
ホームラボ向けOSSと企業向けOSSの両方をカバーしているため、規模を問わず使える。検出ルールはYAMLでカスタム可能で、社内独自のサービスを追加することも難しくない。標準ポート以外で動かしているサービスや、社内製の内製アプリも、fingerprintを1つ書けば以降は自動で分類される。
独自サービスの検出ルールを追加する
fingerprintの考え方はシンプルで、「どのポートで、どんな応答が返ってきたら、どのサービスと判定するか」を宣言的に書くだけだ。イメージとしては次のような形になる（実際のスキーマはバージョンで異なるため、公式定義を確認して調整する）。
# 社内の内製ダッシュボードを検出するルール例
- name: internal-dashboard
category: 開発支援
match:
port: 8443
banner_contains: "X-Internal-Dashboard"
icon: dashboard
このようなルールを足しておけば、非標準ポートで動くサービスも「未識別ホスト」ではなく正しいサービス名で図に現れる。組織固有のミドルウェアやレガシーな業務アプリを、標準の230定義に上乗せして育てていける点は、企業導入で効いてくる。「未識別」を1つずつ潰していく作業が、そのまま社内ネットワークの棚卸しになる。
Workloadsビューはベアメタル／VM／コンテナの実体を表示する。Dockerホストごとのコンテナ密度、Hyper-V／ESXiホストでのVM配置などが一覧化される。「このサーバー、何が動いていたっけ」という属人的な記憶依存が消える。Docker Engine APIを許可しているホストでは、コンテナ名・イメージ・ポートまで拾えるため、コンテナ乱立の棚卸しにも効く。
Scanopyのセルフホスト導入：Docker Compose・Proxmox・Unraid
Scanopyの最短手順はDocker Composeだ。サーバー＋デフォルトのスキャナデーモンが1コマンドで立ち上がる。
# docker-compose.yml をダウンロード
curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml
# 起動
docker compose up -d
# ブラウザでアクセス
open http://localhost:60072
初期ログイン後、対象サブネットを登録するだけでスキャンが開始される。デフォルトではARP／ICMP／TCP top-1000ポートのスキャンが走り、数分〜十数分でトポロジが可視化される。スキャンは定期実行されるため、以降は放置していても図が自動更新される。
WebUIでの初期セットアップの流れはおおむね次の通りだ。まずスキャン対象のサブネット（例：192.168.1.0/24）を登録する。次にスキャン間隔を設定する（最初は手動またはやや長めの間隔にして挙動を確認し、慣れたら短くするのが安全）。スイッチやルータの詳細を取りたい場合はSNMPの認証情報を登録し、Dockerホストを可視化したい場合はEngine APIへのアクセスを許可しておく。ここまで設定すれば、あとはScanopyが定期スキャンで図を更新し続ける。運用中に触るのは、通知先の追加やビューの見方くらいで、日々の「図のメンテナンス」という作業自体が発生しなくなる。この「設定は最初だけ、あとは自動」という運用モデルこそがScanopyの本質だ。
docker-compose.yml の構成例
公式が提供している構成は以下のような形（本記事執筆時点の構造を参考に整理）。
services:
scanopy-server:
image: scanopy/scanopy:latest
container_name: scanopy-server
restart: unless-stopped
ports:
- "60072:60072"
environment:
SCANOPY_DB_URL: sqlite:///data/scanopy.db
SCANOPY_LOG_LEVEL: info
volumes:
- ./scanopy-data:/data
scanopy-scanner:
image: scanopy/scanner:latest
container_name: scanopy-scanner
restart: unless-stopped
network_mode: host # ホストNICでスキャンするためhostモード推奨
environment:
SCANOPY_SERVER_URL: http://scanopy-server:60072
SCANOPY_TOKEN: ${SCANOPY_TOKEN}
network_mode: hostはARPやICMPでL2情報を取得するために重要だ。コンテナデフォルトのbridgeネットワークでは、対象セグメントのARPテーブルが取れず、L2ビューが空になる。
SQLiteからPostgreSQLへ、リバースプロキシとSSO
小規模・自宅ラボならデフォルトのSQLiteで十分だが、本番運用では次の構成に寄せると安定する。
・DBをPostgreSQLに切り替え：SCANOPY_DB_URL をPostgres接続文字列に変更し、バックアップをPostgreSQL側の戦略に乗せる
・リバースプロキシでHTTPS終端：Caddy／Traefik／NginxをScanopyの前段に置き、TLS証明書の管理を外側で行う
・SSO連携：OIDC／SAMLと直接統合したい場合は、リバースプロキシ層（oauth2-proxy等）で認証を挟むのが一般的
・ポート変更：ports マッピングを書き換えれば60072以外にも変えられる
・バックアップ：SQLite運用なら ./scanopy-data を定期バックアップ、Postgres運用ならDBダンプを取得する
Proxmox／Unraid環境での導入
Scanopyは自宅ラボ層からの支持が厚く、Proxmox LXCテンプレートやUnraidコミュニティアプリも提供されている。Proxmoxの場合は次のスクリプトで自動セットアップできる（コミュニティ製ヘルパースクリプト）。
# Proxmox helper script (要確認、実行前に内容を読むこと)
bash -c "$(wget -qLO - https://github.com/community-scripts/ProxmoxVE/raw/main/ct/scanopy.sh)"
UnraidユーザーはCommunity Appsから「Scanopy」を検索してインストールするだけで、テンプレート設定済みの状態で起動する。Proxmoxクラスタや複数拠点では、各セグメントにスキャナデーモンを分散配置し、1つのサーバーUIに集約する構成が定番だ。
初回スキャンのチューニングとよくあるつまずき
起動しても図が思ったように出ない、というのは初回でよくある。原因はたいてい次のいずれかだ。
・L2ビューが空：スキャナがbridgeネットワークで動いていてARPが取れていない。network_mode: host になっているか確認する
・スイッチのポート情報が出ない：SNMPの認証情報が未登録。WebUIでコミュニティストリング（v2c）または認証情報（v3）を対象デバイスに登録する
・一部ホストが見えない：スキャナの居るセグメントからICMP／TCPが到達できていない。ファイアウォールでスキャナのソースIPを許可する
・コンテナが拾えない：Docker Engine APIへのアクセスが許可されていない。対象ホスト側でAPIの公開範囲を確認する
まずは1つの小さなサブネットに絞ってスキャンし、意図通りにホスト・サービスが出ることを確認してから対象を広げると、原因の切り分けが楽になる。スキャン対象ポートを絞る・頻度を落とすといったチューニングも、対象を広げる前にこの段階で決めておくとよい。
Scanopyの使い方：実運用・監視通知・エクスポート・AI連携・セキュリティ活用
導入後、Scanopyが最も価値を発揮するのはどんな場面か。実運用のユースケースと落とし穴、そして周辺連携を整理する。
効果が大きいユースケース
・インフラ移管・引き継ぎ時：「これ何だっけ」がゼロになる。担当者交代時の暗黙知を可視化する
・VLAN／サブネット監査：使われていないアドレス、想定外のサービスが鮮明になる
・コンテナ密度の俯瞰：DockerホストごとのコンテナリストとリソースをWorkloadsビューで一覧できる
・アプリケーション依存関係の発見：「Aがダウンしたら何が困るか」を依存マップから事前把握できる
・アタックサーフェスの可視化：意図せず公開されているポート・サービスをセキュリティチームが即座に確認できる
注意すべき落とし穴
・エージェントレスはスキャン頻度に依存：毎時のスキャンならその時点での精度。短時間で起動・停止するコンテナは逃すことがある
・ICMP／ARPがブロックされる環境：ファイアウォール設定によってはL2情報が取れない。スキャナのソースIPをホワイトリスト化する必要がある
・AGPL-3.0の制約：自社プロダクトに組み込んで再配布する場合、AGPLの公開義務を確認すること。商用利用は商用ライセンスの取得を推奨
・公開ポート＝サービス確定ではない：バナー偽装や非標準ポートのケースでは検出ミスが起こり得る
監視・通知連携：ネットワークの変化を検知する
Scanopyは可視化ツールとしてだけでなく、ネットワーク状態の変化検知にも活用できる。新規ホスト出現や予期せぬサービス公開を検知し、Webhookで通知できる。
# Webhook通知の設定例（REST API経由）
curl -X POST "http://localhost:60072/api/v1/notifications/webhook" \
-H "Authorization: Bearer ${SCANOPY_TOKEN}" \
-H "Content-Type: application/json" \
-d '{
"name": "slack-network-changes",
"url": "https://hooks.slack.com/services/XXX/YYY/ZZZ",
"events": ["host.discovered", "service.discovered", "host.disappeared"],
"filters": {
"subnet": "10.0.0.0/8"
}
}'
これにより「夜中に未知のホストが社内ネットワークに出現した」「想定外のSSHポートが開いた」といったイベントを即座に検知できる。シャドーITの発見やセキュリティ監査の自動化に効く運用だ。
エクスポートとAI連携：Mermaid／Confluence／LLM入力
Scanopyのもう一つの強みはエクスポート機能だ。SVG・Mermaid・Confluence形式での出力に対応しており、生成された図を社内Wikiに直接貼り付けたり、Markdown文書に組み込める。
# REST API経由でMermaid形式エクスポート
curl -X GET "http://localhost:60072/api/v1/topology/export?format=mermaid&view=l3" \
-H "Authorization: Bearer ${SCANOPY_TOKEN}" \
-o topology.mmd
さらに発展形として、出力したMermaidや構造化JSONをLLMの入力として渡すユースケースが2026年に注目を集めている。ChatGPTやClaudeに「このネットワーク構成のリスクを教えて」と聞かせれば、構成の弱点を指摘してもらえる。REST APIでSVG／Mermaidを取得できるため、GitHub Actionsの定期実行で社内Wikiに自動同期し、インフラ図を「Pull Requestで差分レビューする」運用も組める。AI×インフラ可視化の最前線として、Scanopyのエクスポート機能は重要な接続点になる。
セキュリティ活用：シャドーITとアタックサーフェス管理
CISO・セキュリティチーム視点でScanopyを見ると、「アタックサーフェスを継続的に把握する」用途で価値が大きい。社内ネットワーク内の未知ホストや非承認サービスは、シャドーITとなり攻撃の足がかりになる。
| シナリオ | Scanopyでできること |
|---|---|
| 個人持ち込み機器の検知 | 新規MAC／新規ホスト出現を即座に通知 |
| 開発用に開けたままのポート発見 | 公開サービスの定期スキャンと差分検知 |
| 古いOS／脆弱バージョンの一覧化 | バナーから検出されるバージョンを集計 |
| ペネトレーションテストの事前情報 | テスト前後の差分を自動取得 |
| 監査対応 | 「定期的にスキャンしている」エビデンス化 |
外部の脆弱性スキャナ（Faraday、OpenVAS等）と組み合わせれば、「検知→評価→対応」のループを内製で組める。セキュリティ視点での「ネットワーク可視化＝アタックサーフェス可視化」という発想は、サプライチェーンセキュリティ完全ガイドで扱う「攻撃面の最小化」とも通底する。Scanopyの結果を脆弱性管理プラットフォームと連動させると相乗効果が高い。
Applicationsビューはサービス間の依存関係を可視化する。「Redisが落ちたら何が困るか」「DBへ書き込んでいるのは誰か」が依存マップから読み取れる。SREや障害対応の現場で価値が大きい。
障害対応の初動では「何がどこに依存しているか」を素早く把握できるかどうかが復旧時間を左右する。属人的な記憶や古いWikiに頼ると、影響範囲の見落としが二次障害を招く。Applicationsビューを常に最新に保っておけば、アラートを受けた瞬間に依存の上流・下流を確認でき、「このサービスを再起動すると誰に影響するか」を事前に見積もれる。ポストモーテムでも、障害当時の依存構成を根拠付きで説明できる。4ビューのなかでも、Applicationsビューは「日々の運用で最も参照される画面」になりやすい。
Scanopy vs Netbox・LibreNMS・Terravision：比較と使い分け・導入判断
ネットワーク可視化／管理OSSは多数存在するが、Scanopyは「スキャンベースの自己更新」に特化している点で独自性がある。
| ツール | 取得方式 | 強み | 弱み |
|---|---|---|---|
| Scanopy | エージェントレス能動スキャン | 自己更新、4ビュー、Rust製で軽量 | スキャン頻度依存 |
| Netbox | 手動入力／API | DCIM機能、ソース・オブ・トゥルース | 手動更新が必要 |
| LibreNMS | SNMP受動／ポーリング | メトリクス収集、長期実績 | UIが古め、可視化はシンプル |
| NetAlertX（旧Pi.Alert） | ARPスキャン中心 | 自宅ラボ向け、軽量 | サービス検出が浅い |
| Terravision | Terraform（IaC）を描画 | コード=図のSSoT | 実態（drift）は見えない |
「インフラの理想（IaC）」と「インフラの実態（active scan）」は別の情報源で、両方持っておくのが理想だ。Terravisionが理想図、Scanopyが実態図として組み合わせると、driftを発見しやすい運用になる。監視メトリクスが主目的ならLibreNMS、DCIM台帳を厳密に管理したいならNetbox、自宅の端末検知だけならNetAlertXという棲み分けになる。「常に最新の全体像を自動で欲しい」ならScanopyが最も素直な選択肢だ。
これらは排他的ではなく、役割の違うレイヤーとして重ねられる。たとえばNetboxで「あるべき台帳」を管理しつつ、Scanopyの実態スキャン結果とAPI経由で突き合わせれば、台帳に載っていない機器（＝管理外の資産）を自動で洗い出せる。LibreNMSで性能を監視し、Scanopyで構成を可視化し、Terravisionでコード上の設計を描く——という三層構成にすれば、「設計・実態・性能」の三点セットが揃う。Scanopy単体でも十分に価値があるが、既存のNW管理スタックに“実態レイヤー”を1枚足す、という発想で導入するとハマりやすい。
Scanopyを選ぶべきケース・選ばないケース
選ぶべきケース。
・ネットワーク図のメンテナンスに疲れており、自動更新に移行したい
・自宅ラボ／中小規模オンプレ／VPC内部を、エージェントレスで丸ごと可視化したい
・シャドーITや想定外のポート公開を、継続的に監視したい
・生成した図をWiki・CI・LLMに流し込んで運用を自動化したい
選ばないほうがよいケース。
・パブリッククラウド（AWS／GCP／Azure）のAPIレベルの構成が主対象 → 各社のArchitecture Diagram機能やTerravisionが向く
・秒単位のメトリクス監視・アラートが主目的 → LibreNMS／Prometheus系が本業
・厳密な資産台帳（シリアル番号・保守契約まで）を人手で管理したい → NetboxのDCIMが適切
まとめ：「インフラ図を書く時代」を終わらせる選択肢
ネットワーク図は、書いた瞬間から古くなる宿命を抱えていた。Scanopyは「描く」のではなく「取得する」発想で、その宿命を断ち切るOSSだ。AGPL-3.0で完全にオープンソース、Docker Composeで2分で起動、Rust製で軽量、4つのビューで多面的に可視化、エクスポートでAI連携も可能。自宅ラボから企業オンプレまで規模を問わず適用でき、★4.8kという数字が示すとおりコミュニティの支持も厚い。
導入コストの面でも、AGPL版なら金銭的な負担なくフル機能を試せる。まず自宅ラボや検証セグメントで動かし、有用性を確かめてから社内展開する、という無理のないパスを取れるのが強みだ。企業として本格運用する段階になれば、プロジェクトの持続性のために商用ライセンスやSaaS版「Scanopy Cloud」を検討すればよい。ベンダーロックインを避けつつ、必要になった時点でサポートを買える——このグラデーションがOSSとしてのScanopyの安心感につながっている。
「最新のネットワーク図を出してください」と言われたとき、自信を持って「URLをどうぞ」と答えられる体制を、まずはローカルの docker compose up で試してみる価値がある。ネットワーク図の自動作成・自動更新は、もはや手作業に頼る領域ではなくなりつつある。自宅ラボから企業オンプレまで規模を問わず、Scanopyはその移行を後押しする有力な選択肢だ。
参照ソース
- scanopy/scanopy (GitHub) - 本体リポジトリ
- Scanopy Official Site - 公式サイト・ドキュメント
- Scanopy Live Demo - 動作デモ
- Scanopy: Self-Hosted Network Scanner That Builds a Live Topology Map (noted.lol) - サードパーティの紹介記事
- Stop Drawing Network Diagrams Manually – Scanopy (Virtualization Howto) - 実運用での評価
