そこにあるネットワークから始める。
エージェントをインストールせずに、ネットワーク機器と接続を検出します。6種類のデバイスが1つの検出ハブにつながります。
- エージェント不要の検出とトポロジーの文書化
- テンプレート → 比較 → 承認 → 展開
- クラウド、オンプレミス、切り離された環境への導入
業務のために。
進め方を変える。
ArchiFlowが複雑さを明確な次の一歩に変える3つの場面。
実在するネットワークから始める。
- 課題
- 複数ベンダーの機器と古い構成図を持つ拠点の運用を、チームが引き継ぎます。
- 業務で活きる製品
- スキャン範囲と読み取り用の認証情報を定義し、デバイスと隣接機器を検出し、不確かなリンクを確認して、結果を編集可能な図にします。
- 変わること
- 共有台帳とトポロジーの基準状態を得て、後続のスキャンで再確認できます。
変更を確認し、実行へ。
- 課題
- 機種ごとの違いを維持しながら、スイッチ全体で共通設定を更新する必要があります。
- 業務で活きる製品
- テンプレートを準備し、稼働状態と比較し、承認を得てカナリア対象で実行します。展開を続ける前に、結果と差分を確認します。
- 変わること
- 変更を、レビュー済み構成と実行履歴に関連付けたまま保持し、結果が適切でない場合の復旧を評価できます。
新しい機器にも、同じ共有された文脈を。
- 課題
- 機器を撤去し、現地チームが運用センターと連携して後継機を設置します。
- 業務で活きる製品
- 予備機器と対象機器の接続を確認し、関係を交換機へ引き継ぎ、設置後にトポロジーと構成を検証します。
- 変わること
- ドキュメントに稼働中の機器と交換履歴を反映し、次のシフトも同じ運用状況を把握できます。
目的を絞ったシステム。
より大きな全体像の一部。
ネットワークチームのためのワークスペース。既存デバイスを検出し、編集可能なドキュメントを作成して、各変更を構成、アドレス、実行履歴につなぎます。運用担当者は、意図した設計と実際に検出された設備の両方を扱えます。
ネットワークの基盤。
ArchiFlowは、Titansチームが扱うデバイス、リンク、アドレス、構成を共有画面で把握できるようにします。取り組みの中で、その文脈がネットワーク設計と運用担当者をつなぎます。検出で基準状態を定め、レビュー済みの変更と更新される文書で、導入後も有用性を維持します。
01業務フローの全体像
+
顧客データを使わない例：複数ベンダーのスイッチと不完全な構成図を持つ拠点をネットワークチームが引き継ぎます。接続状況を把握してから、共通設定の変更を準備・実行します。
拠点を定義して検出
ネットワーク責任者がアドレス範囲と許可する管理経路を選びます。範囲を限定した認証情報で、対応プロトコルを通じて機器と隣接情報を検出します。
観測された機器台帳と、リンクの信頼度を含むトポロジーを、把握済みの設備と比較できます。
運用モデルを確認
エンジニアが不確かな接続を確認し、検出結果を編集可能な図に変え、拠点、アドレス、接続の不足情報を補います。既存のExcel記録は、列の対応付けと検証を経て取り込めます。
確認済みのデバイス、接続、アドレスが、変更対象機器を選ぶ文脈になります。
構成を準備・比較
エンジニアがCLIまたはJinja2テンプレートを選び、必要なデバイス項目を指定します。構成案を稼働構成と比較し、権限を持つ運用担当者が差分を確認します。
構成案と差分を、実際の機器の文脈で確認できます。
限定的な展開を実行
運用担当者が選んだデバイスでのカナリア実行を承認します。プラットフォーム固有のCLIエラーを含むコマンド出力を確認してから、展開を拡大するか判断します。
実行履歴と構成バージョンで、運用担当者が何が起きたかを確認できます。続行と停止のルールは、合意した変更手順に従います。
検証と引き継ぎ
エンジニアが変更後の構成とトポロジーを確認し、未解決事項を記録して、次回の検出を予定します。復旧が必要なら、その機器シリーズと変更で検証済みの経路を使います。
次のシフトは、現在のモデル、レビュー済み構成、実行履歴を、未完了事項と共に確認できます。
検出した機器から構成案と実行結果まで、確認可能な連鎖を残します。復旧の動作、互換性、受け入れ基準を、対象ネットワークに応じて定めます。
02内側にある機能
+
ネットワークの検出とマッピング
IP範囲のスキャンとSSH、SNMP、CDP、LLDPによる隣接機器の検出で、デバイスとリンクを1つのトポロジーにまとめます。リンクの信頼度が、観測情報と検証が必要な関係の区別に役立ちます。
- 入力
- 許可されたIP範囲、到達可能な管理経路、対象範囲を限定したデバイス認証情報。
- 出力
- デバイスの観測と隣接関係。エンジニアの確認が必要なリンクを信頼度で示します。
更新される設計と文書
編集可能な図では、デバイス、接続、アドレスをネットワークモデルの一部として扱います。検出結果を共有設計へと変え、繰り返しスキャンして文書を更新します。
- 入力
- 検出結果、既存台帳、デバイス・ケーブル・アドレスへの編集。
- 出力
- 構成図と機器台帳を連携し、後のスキャン結果と照合できる、編集可能なネットワークモデル。
IPアドレスとプレフィックス
拠点とデバイスの文脈で、アドレス、プレフィックス、VLANを管理します。割り当て、一括操作、使用状況の表示が、次のネットワーク変更に向けた体系的な基盤になります。
- 入力
- 拠点と設備に関連付けた、把握済みのアドレス空間、プレフィックス、割り当て。
- 出力
- アドレスの割り当てと使用状況の情報により、個別の一覧に頼らず、次の変更を準備できます。
構成テンプレート
CLIとJinja2テンプレートがデバイス項目を利用して、適切な構成を準備します。共有ライブラリとバージョン履歴により、テンプレートと判断の経緯を繰り返しの作業に活用できます。
- 入力
- バージョン管理されたCLIまたはJinja2テンプレートと、選択したデバイスの値。
- 出力
- デバイスごとの構成案。展開前に比較・レビューできます。
バックアップ、差分、構成のずれ
稼働構成を取得し、変更案と比較します。バージョン履歴とデバイス横断の差分表示が、構成のずれの特定と復旧方法の評価に役立ちます。
- 入力
- 取得済みの稼働構成と、変更候補または以前のバージョン。
- 出力
- 構成のずれのレビューと復旧の評価に根拠を提供する、構成バージョンと差分の集約。
段階的・スケジュールによる展開
対象デバイス、変更時間帯、最初のカナリア実行を定義します。実行履歴とコマンド結果を使って変更を評価し、その後に残りの機器へ展開します。
- 入力
- 確認済みの構成、対象デバイス、許可された時間帯、初期カナリア範囲。
- 出力
- 続行、修正、障害調査を判断するための実行履歴とコマンド結果。
台帳、予備機、交換
デバイス、ケーブル、電源装置の台帳を拠点と図面に連携します。機器交換時は、旧機器の撤去を記録しながら、インターフェース、アドレス、ケーブルの関係を新機器へ引き継げます。
- 入力
- 拠点の台帳、利用可能な予備機器、旧機器のインターフェース・アドレス・ケーブルの関係。
- 出力
- 交換後の記録と、ネットワークモデル内で引き継がれた関係。撤去した機器を明示します。
共同作業とAI支援
共同編集と活動ログで、ネットワークチームが文脈を共有します。AIはネットワークデータで質問に答え、レビュー用の変更を準備できます。クラウドまたはローカルモデルの構成は、バージョン、実行環境、データポリシーに依存します。
- 入力
- チームの活動、開いている図、利用者が閲覧できるネットワーク情報。
- 出力
- 共有する業務の文脈と、運用担当者が確認するAIの回答・変更案。利用できるAIモードは導入方式によって異なります。
03つながり続ける情報
+
これらの業務オブジェクトは、作業に使う情報を説明します。公開データベーススキーマやAPI形式ではありません。
拠点、設備、接続
デバイス、インターフェース、ケーブル、拠点の関係が、検出した機器をトポロジーにつなぎます。リンクの信頼度により、観測した証拠と確認が必要な関係を区別します。
変更の影響を受ける機器を見つけ、その情報を次のエンジニアへ引き継ぎます。
アドレスとネットワーク空間
IP、プレフィックス、VLANを、他の台帳オブジェクトと共に管理・取り込みできます。既存の表計算データは、対応付けと検証を経て取り込みます。
割り当てを準備し、テンプレートが依存するネットワーク情報を確認します。
構成とバージョン
テンプレート、構成案、稼働構成、保存されたバージョンが、提案状態と観測状態を表します。比較によって、対象機器の差分を明らかにします。
変更を確認し、対象プラットフォームで検証した復旧経路を評価します。
実行、活動、監査
展開結果、検出処理、構成イベントを運用履歴に残します。公開Trust Centerでは、SIEMへの監査データ出力についても説明しています。
実行結果を理解し、責任をたどり、証跡を既存の監督ツールへ渡します。
04既存システムとの連携
+
機器とOSバージョン
Cisco、Juniper、Arista、Fortinet、Palo Altoなどの機器シリーズへの接続に対応します。検出時に、シリーズごとの機種、バージョン、必要な操作を確認します。
既存台帳とデータ
デバイス、アドレス、拠点、接続を、列の対応付けと検証を伴ってExcelから取り込めます。NetBox連携には、項目ごとの管理責任と同期ルールが必要です。
監視と運用フロー
ネットワークモデルを監視情報やSolarWindsなどのシステムに連携します。追加のAPI連携とイベントの受け渡しは、組織の既存ツールに合わせて範囲を定めます。
導入・管理の方法
導入方式には、単一サーバーのDocker、アプリケーション層とデータ層の分離、切り離されたネットワークへの設置があります。どの環境にも、デバイスへのアクセス経路、シークレット管理、バックアップ、更新手順が必要です。
05権限、管理、例外
+
役割に基づく権限
閲覧、編集、管理を分離し、組織のグループを権限に対応付けます。図の編集権限が、自動的に構成の展開権限を与えるわけではありません。
適切な範囲の認証情報
認証情報プールの範囲を拠点とデバイスごとに定めます。検出と実行に必要なサービスアカウントと最小権限を定義します。
確認できる履歴
変更、実行者、構成、実行結果のつながりを保ちます。バージョン履歴は復旧の評価に役立ちます。復旧経路はデバイスの種類ごとに確認します。
クラウドAIの明確な境界
クラウドAIアドオンはコアの導入とは別に評価します。切り離されたネットワークで利用できると想定せず、動く機能、外部へ出せるデータ、必要な承認を合意します。
計画どおりに進まないとき
日常業務には、検出の確認、テンプレートと認証情報の保守、変更レビュー、文書更新が含まれます。保護機能が未完了や失敗した操作を可視化し、プロジェクトが対応責任者を割り当てます。
検出に不足が残る
到達できないデバイスや不確かなリンクは調査が必要です。運用担当者が接続、認証情報、隣接機器の証跡を確認し、必要に応じてモデルを補完します。スキャン結果は対象範囲のある観測として扱い、すべての資産が検出された証拠とは見なしません。
接続は成功してもコマンドが失敗
ArchiFlowには、通信が成功と報告されても、プラットフォーム固有のCLIエラーを分類する仕組みがあります。運用担当者がコマンド結果を確認して修正を判断します。停止、再試行、復旧の動作は、実際の機器シリーズと操作で確認する必要があります。
展開の一部だけが完了
カナリア実行、構成のバージョン、実行履歴が、展開前の調査を支えます。一部のデバイスだけが変更された場合の対処と、停止条件をプロジェクトで定義する必要があります。バックアップだけで、あらゆる状況に対応できるロールバック手順が確立されるわけではありません。
取り込みデータや交換後のデータの照合が必要
列の検証は取り込み内容の確認に役立ち、機器交換ではデバイス間の関係を新しいモデルへ引き継げます。ただし、競合する記録や交換機に存在しないインターフェースについてはルールが必要です。関係の引き継ぎは構成の移植性を保証しません。
06実装と組織への適合
+
代表的な拠点を選ぶ
ネットワークチームが機器一覧、アドレス範囲、アクセス要件を提供します。初期業務を共に選び、スキャンや変更を許可する範囲を定義します。
検出とモデルを検証
合意した範囲で検出し、既知の台帳と比較します。確認済みトポロジーと解消すべき不足一覧を成果とします。
管理された変更を実行
ネットワーク責任者がテンプレートと試験機器を選びます。拡大前に、権限、承認、コマンド結果、バックアップを検証します。
運用の定期手順を整える
責任者、定期スキャン、変更時間帯、障害対応を定義します。追加拠点への拡大は、レビュー済みの互換性一覧に従います。
導入環境
- 実行環境
- 切り離されたネットワークでのオンプレミス導入と運用。製品ホームページはクラウドAIを、リリース資料はローカルモデルも説明しています。実際の環境に合わせ、AI構成、製品バージョン、更新経路を評価します。
- 既存設備
- ベンダーをまたぐトポロジーと機器。機種、バージョン、管理経路を調査時に確認します。
- 対話にご用意いただくもの
- 代表的な拠点またはネットワーク、機器一覧、アクセス制約、改善対象の運用フロー。
機器と操作を確認
代表的な拠点の機種、OSバージョン、必要な操作を確認します。ベンダー名だけでは互換性を十分に示せません。検出、バックアップ、展開、復旧では、対象範囲を広げる前にそれぞれ異なる検証が必要になる場合があります。
既存システムとの接続を定義
NetBox同期、SolarWinds監視、IDインターフェース、SIEM出力が公開されています。プロジェクトでコネクター互換性、項目の管理責任、グループ対応付け、イベント配信を定めます。ほかの技術プロバイダーのロゴだけで、顧客向け連携がすぐに利用できるとは判断できません。
変更権限は運用担当者に
役割別アクセス、範囲を絞った認証情報、レビュー段階で変更を管理します。コパイロットが操作を提案し、必要な権限を持つ運用担当者が確認します。操作ごとの準備、承認、実行の担当者と、証跡、停止条件、復旧手順を合意します。
導入方式とAIモードを選ぶ
ローカルおよび切り離されたコアの導入が説明されています。ホームページではClaudeを任意のクラウドアドオンとして示し、リリース・信頼性のページではローカルAIにも言及しています。導入バージョン、利用モデル、データ経路を個別に確認してください。切り離された導入でクラウドAIが使えるという意味ではありません。
07適合性に関する質問
+
開始時に正確な構成図が必要ですか？
いいえ。既存ネットワークの検出と台帳の取り込みから始めます。チームが結果を検証し、スキャンだけでは確定できない関係を補います。
ベンダーのすべての機種に対応しますか？
ベンダー名だけでは判断できません。展開を拡大する前に、機種、OS、バージョン、実施する操作（検出、バックアップ、展開、復旧）を確認します。
インターネット接続なしで導入できますか？
ネットワークから切り離した環境にも導入できます。インストールパッケージ、更新手順、デバイスへのアクセスを事前に準備してください。この導入方式では、クラウドAI機能は保証されません。
AIが自動でネットワークを変更しますか？
Copilotは変更を提案し、利用者が確認・承認します。AIが作成した提案にも、利用者の権限と変更プロセスが適用されます。
適合性評価には何を用意すべきですか？
代表的な拠点、機種とバージョンの台帳、アドレス管理方法、監視ツール、変更フローを1つご用意ください。実践的な評価と明確な成果物を定める材料になります。