Scanopy完全解説：ネットワーク図を自動生成・自動更新するセルフホストOSS

「最新のネットワーク構成図を出してください」と言われて即答できるインフラチームはほとんどない。Visioやdraw.ioで手書きされた図はインフラ変更のたびに陳腐化し、半年後には実態と乖離する。Scanopyはこの問題を根本から解決するセルフホスト型OSSだ。Rust製のスキャナーがネットワークを能動的に走査し、L2（物理）・L3（論理）・Workloads・Applicationsの4視点で「いま実際に動いているもの」を自動可視化する。AGPL-3.0、★4.8k、Docker Compose一発で起動できる手軽さが評価され、自宅ラボから企業オンプレまで広く支持を集めている。

この記事ではセルフホスト型ネットワーク可視化OSS Scanopyを解説します。AI時代の自動化ツール全体像についてはAI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方をご覧ください。

Scanopyとは何か：自己更新するネットワーク図というアプローチ

Scanopyは「Network diagrams that update themselves」をキャッチフレーズに掲げる、ネットワーク自動可視化のOSSだ。2026年4月時点で★4.8k、231フォーク、Rust（61.7%）+ Svelte（23.5%）+ TypeScript（9.9%）で実装されている。「インフラ図を書く」のではなく「インフラ図を取得する」発想に移行できる点が革新的だ。

従来のネットワークドキュメンテーションは次の問題を抱えていた。

• 手書き図は即座に古くなる：VLAN追加・サブネット変更・サーバー入れ替えのたびに図を更新するのは現実的でない
• InfraCoC（Infrastructure as Code）でも完璧ではない：Terraform化されていない手動変更（drift）は反映されない
• エージェント方式は導入コストが高い：監視対象すべてにエージェントを入れる必要があり、レガシー機器に対応しづらい
• SaaSは情報セキュリティ要件で使えない：オンプレ機器の情報を外部SaaSに送れない組織が多い

Scanopyはこれらを「軽量デーモン1台で完結するエージェントレス・アーキテクチャ」で解決する。デーモンを1サブネットに配置すればポートスキャン・SNMP問い合わせ・サービスバナー検出を自動で行い、サーバー側のWebUIに集約してビジュアライズする。

アーキテクチャ：エージェントレス×単一デーモン×4ビュー

Scanopyの構成は驚くほどシンプルだ。スキャナデーモンとサーバーUIの2コンポーネントで完結し、対象機器側には何もインストールしない。

複数拠点ある場合は、各サブネットにデーモンを分散配置できる。VPN／オンプレ／クラウドが混在する環境でも、各セグメントの代表ホストにデーモンを置けば全体像が見える。

4つのビュー

「同じネットワークを4つのレイヤーで見られる」点がScanopy最大の強みだ。L2でケーブル配線図、L3でVPC構成、Workloadsでコンテナ密度、Applicationsで依存関係——同じデータから異なるストーリーが引き出せる。

230以上のサービス自動検出：何が見えるのか

Scanopyは内蔵の「サービス指紋（fingerprint）」データベースで、ポートスキャンとバナー応答からサービスを自動識別する。READMEで言及されている230以上の定義はカテゴリ別に整理されており、自宅ラボのHome Assistantから企業のOracle DBまで幅広い。

検出可能なサービスのカテゴリ別例

ホームラボ向けOSSと企業向けOSSの両方をカバーしているため、規模を問わず使える。検出ルールはYAMLでカスタム可能で、社内独自のサービスを追加することも難しくない。

クイックスタート：Docker Composeで2分起動

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ポートのスキャンが走り、数分〜十数分でトポロジが可視化される。

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ビューが空になる。

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」を検索してインストールするだけで、テンプレート設定済みの状態で起動する。

使いこなし：実運用での効果と落とし穴

効果が大きいユースケース

• インフラ移管・引き継ぎ時：「これ何だっけ」がゼロになる。担当者交代時の暗黙知を可視化
• VLAN／サブネット監査：使われていないアドレス、想定外のサービスが鮮明に
• コンテナ密度の俯瞰：DockerホストごとのコンテナリストとリソースをWorkloadsビューで一覧
• アプリケーション依存関係の発見：「Aがダウンしたら何が困るか」を依存マップから事前把握
• アタックサーフェスの可視化：意図せず公開されているポート・サービスをセキュリティチームが即座に確認

注意すべき落とし穴

• エージェントレスはスキャン頻度に依存：毎時のスキャンならその時点での精度。短時間で起動・停止するコンテナは逃すことがある
• ICMP／ARPがブロックされる環境：ファイアウォール設定によってはL2情報が取れない。スキャナのソースIPをホワイトリスト化する必要あり
• AGPL-3.0の制約：自社プロダクトに組み込んで再配布する場合、AGPLの公開義務を確認すること。商用利用は商用ライセンスの取得を推奨
• 公開ポート＝サービス確定ではない：バナー偽装や非標準ポートのケースでは検出ミスが起こり得る

セキュリティ視点での「ネットワーク可視化＝アタックサーフェス可視化」という発想は、サプライチェーンセキュリティ完全ガイドで扱う「攻撃面の最小化」とも通底する。Scanopyの結果を脆弱性管理プラットフォームと連動させると、相乗効果が高い。

類似ツールとの比較：Netbox／LibreNMS／NetAlertX／Terravisionとの違い

ネットワーク可視化／管理OSSは多数存在するが、Scanopyは「スキャンベースの自己更新」に特化している点で独自性がある。

「インフラの理想（IaC）」と「インフラの実態（active scan）」は別の情報源で、両方持っておくのが理想だ。Terravisionが理想図、Scanopyが実態図として組み合わせると、driftを発見しやすい運用になる。

4ビューの実例：何がどう見えるか

公式リポジトリ配下に各ビューのスクリーンショットが用意されている。実際の見え方を理解する助けになる。

L2ビューはスイッチポートと物理ケーブル接続を表示する。LLDP／CDPを使って隣接機器を辿るため、「どのスイッチのどのポートに何が刺さっているか」が一目でわかる。古い配線図と現実の差分を発見するときに最も役立つ。

L3ビューではサブネット・VLAN・ルーティング関係を表示する。DMZと内部LANの境界、VPN経由の他拠点接続などが一画面で把握できる。クラウド管理者がオンプレ・クラウドハイブリッド環境を整理するときに有効だ。

Workloadsビューはベアメタル／VM／コンテナの実体を表示する。Dockerホストごとのコンテナ密度、Hyper-V／ESXiホストでのVM配置などが一覧化される。「このサーバー、何が動いていたっけ」が消える。

Applicationsビューはサービス間の依存関係を可視化する。「Redisが落ちたら何が困るか」「DBへ書き込んでいるのは誰か」が依存マップから読み取れる。SREや障害対応の現場で価値が大きい。

実運用での監視・通知連携

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に「このネットワーク構成のリスクを教えて」と聞かせれば、構成の弱点を指摘してもらえる。AI×インフラ可視化の最前線として、Scanopyのエクスポート機能は重要な接続点になる。

セキュリティ視点での活用：シャドーITとアタックサーフェス管理

CISO・セキュリティチーム視点でScanopyを見ると、「アタックサーフェスを継続的に把握する」用途で価値が大きい。社内ネットワーク内の未知ホストや非承認サービスは、シャドーITとなり攻撃の足がかりになる。

外部の脆弱性スキャナ（Faraday、OpenVAS等）と組み合わせれば、「検知→評価→対応」のループを内製で組める。AIエージェント運用が広がる現在では、エージェントが新規ホストを発見した瞬間に脆弱性スキャンを起動するワークフローも実現しやすい。

まとめ：「インフラ図を書く時代」を終わらせる選択肢

ネットワーク図は、書いた瞬間から古くなる宿命を抱えていた。Scanopyは「描く」のではなく「取得する」発想で、その宿命を断ち切るOSSだ。AGPL-3.0で完全にオープンソース、Docker Composeで2分で起動、Rust製で軽量、4つのビューで多面的に可視化、エクスポートでAI連携も可能。自宅ラボから企業オンプレまで規模を問わず適用でき、★4.8kという数字が示すとおりコミュニティの支持も厚い。

「最新のネットワーク図を出してください」と言われたとき、自信を持って「URLをどうぞ」と答えられる体制を、まずはローカルのdocker compose upで試してみる価値がある。自宅ラボから企業オンプレまで規模を問わず、ネットワーク運用の負担は確実に軽くなる。3年運用しても陳腐化しない図はScanopyだけが提供できる。

FAQ

Q. クラウド（AWS／GCP／Azure）の構成も可視化できますか？

A. パブリックIPベースのスキャンは可能ですが、各クラウドAPIとの公式統合は本記事執筆時点で限定的です。クラウド側はTerravisionや各社のArchitecture Diagram機能と組み合わせ、Scanopyはオンプレ／VPC内部のスキャンに使うのが現実的です。

Q. SNMP v3に対応していますか？

A. SNMP v2c／v3に対応しています。コミュニティストリングや認証情報はWebUIから登録でき、対象デバイスごとに切り替え可能です。

Q. AGPL-3.0は社内利用でも何か義務がありますか？

A. 社内サーバーで自社のみが使う場合は、ソースコード公開の義務は発生しません。ただしSaaSとして第三者に提供する場合はAGPLの「ネットワーク経由配布」条項により、改変ソースの公開が必要になります。社内ツールとしての利用は問題ありません。

Q. スキャン対象側に何か影響はありますか？

A. ARP／ICMP／TCP接続の試行が発生するため、IDSで検知される可能性があります。本番ネットワークで動かす際は、セキュリティチームに事前通知し、スキャナのIPをホワイトリスト化することを推奨します。

Q. 商用ライセンス・SaaS版との違いは？

A. AGPL自己ホスト版は機能上の制限はなく、すべて利用できます。商用ライセンスはAGPLの公開義務を回避したい組織向け、SaaS版「Scanopy Cloud」は運用負荷を完全にオフロードしたい組織向けです。プロジェクトの持続性のため、企業利用ならいずれかの有償プランの検討が推奨されます。

Q. 1台のデーモンでスキャンできるノード数の上限は？

A. 公式の明記はありませんが、Rust実装の軽量さから数千ノード規模でも単一デーモンで十分とされています。複数サブネットや多拠点では、デーモンを分散配置して負荷分散できます。

Q. ネットワーク図のエクスポートをCIに組み込めますか？

A. REST API経由でSVG／Mermaid出力が可能なため、GitHub Actionsの定期実行で社内Wikiに自動同期するワークフローが組めます。インフラ図を「Pull Requestで差分レビューする」運用も実現できます。

Q. ScanopyとTerraformを組み合わせるベストプラクティスは？

A. Terraformで構成した「あるべき姿」とScanopyが拾う「実際の姿」をdiffすることで、構成ドリフトを発見できます。ScanopyのJSONエクスポートをCIで取得し、Terraform stateと比較するスクリプトを書けば自動化可能です。

Q. デフォルトポート60072を変更できますか？

A. docker-compose.ymlのportsマッピングを変更するだけで任意のポートに変えられます。リバースプロキシ（Caddy／Traefik）配下に置く場合は、HTTPS終端を外側で行うのが定番構成です。社内のSSO（OIDC／SAML）と連携したい場合は、リバースプロキシ層で認証を挟む方法が一般的です。

Q. データの保管・バックアップはどうすればよいですか？

A. SQLite運用の場合は./scanopy-dataディレクトリを定期的にバックアップします。本番ではPostgreSQLに切り替え、PostgreSQL側のバックアップ戦略に乗せるのが推奨です。

参照ソース

• 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) - 実運用での評価