netbox-validation

NetBox Validation

NetBox Validation は、インテント（NetBox データ）、構成分析（レンダリングされた構成）、グラフ分析（インフラストラクチャの依存関係）の 3 つのエンジンを使用して、宣言型ポリシーに照らしてインフラストラクチャデータを継続的に検証します。デバイスごとの結果、集約された検出結果、コンプライアンススコアを生成します。

NetBox Validation に関する知識が古くなっている可能性があります。 名前、API フィールド、ポリシーパックの内容、エンジンの機能はリリースごとに変更されます。事前学習済みの知識より、情報の取得を優先してください。

現在のプラグイン： 1.14.3（2026-10-06）。NetBox 4.7 のサポートは 1.14.0 で追加されました。このプラグインが宣言する対応範囲は NetBox 4.4～4.7.x で、ドキュメントでは NetBox 4.5 以降（NetBox Cloud）が必要とされています。NetBox 4.7 では 1.14.0 以降を実行してください。バージョン情報を参照してください。

情報取得元

情報源	URL／方法	用途
Validation のドキュメント	https://netboxlabs.com/docs/validation/	全般的なリファレンス、エンジン、チェックカタログ、ポリシーパック
Validation REST API	https://netboxlabs.com/docs/validation/api-reference/	エンドポイントの詳細
NetBox Platform MCP	構成されている場合 — 5 つの検証ツール	検証の実行、コンプライアンスの照会、ポリシーの管理
NetBox MCP server	構成されている場合 — 読み取り専用アクセス	デバイス、ポリシー、スコアの確認

最初に：接続を確認する

Validation プラグインがインストールされており、トークンにアクセス権があることを確認します。

curl -s -H "Authorization: Bearer $NETBOX_TOKEN" \
  "$NETBOX_URL/api/plugins/validation/policies/" | python -m json.tool

ポリシーのページネーションされたリスト（または空の結果）が表示されます。404 が返された場合、Validation プラグインはインストールされていません。403 が返された場合、トークンに検証権限がありません。

---

基本概念

オブジェクト階層

Policy (scope + rules + triggers)
  -> Run (execution of a policy against devices)
    -> Results (per-device, per-check pass/fail/warning/error/skip)
      -> Findings (aggregated failures, actionable items)
        -> Compliance Scores (per-device, per-policy, 0-100%)

ポリシー

Validation ポリシーは、何を、どこでチェックするかを定義します。スコープフィルターには、サイト、リージョン、サイトグループ、デバイスロール、プラットフォーム、タグがあります。ルールを含み、エンジンの切り替え、トリガー、cron スケジュールを制御します。

ルール

各ルールでは、次の項目を指定します。

フィールド	説明
engine	intent、config、または graph
category	チェックのグループ — addressing、redundancy、standards、completeness、security_intent、topology、reachability、power、infrastructure、routing、security、baseline、overlay
check_name	実行する特定のチェック（例：no_duplicate_ips）
severity	critical、high、medium、low、または info
parameters	チェック固有の設定（しきい値、パターン、期待値）

ルールでは、独自の roles フィルターと platforms フィルター（ID のリスト）を使って、ポリシーのスコープを任意で上書きできます。

3 つのエンジン

エンジン	チェック数	評価対象	データソース	主な強み
インテント	44	NetBox データの関係性	NetBox ORM	高速で、外部依存関係がない
構成	35	レンダリングされたデバイス構成	構成分析エンジン（NetBox Config Templates 由来）	構造分析、到達可能性
グラフ	16	インフラストラクチャの依存関係グラフ	NetBox ORM	影響範囲、障害ドメイン

3 つすべてのエンジンを 1 つのポリシー内で併用できます。構成エンジンとグラフエンジンは、Premium ティアのお客様が利用できます。構成エンジンは NetBox Config Templates からレンダリングされた構成を分析します。有効にする前に、デバイス、プラットフォーム、またはロールを通じてテンプレートをデバイスに割り当ててください。

実行ステータス

ステータス	意味
pending	作成済みで、実行待ちです
running	チェックを実行中です
passed	すべてのチェックに合格しました
failed	1 つ以上のチェックに失敗しました
error	実行中にエンジンエラーが発生しました

プラグイン 1.12.0 以降、各実行は NetBox のバックグラウンドジョブに紐付けられ、ジョブのタイムアウトが適用されます。また、実行途中でワーカーが失われた孤立した実行は、running のまま残されず、回収されます。

各実行には job_id（コアのバックグラウンド Job）が公開されます。プラグイン設定の job_timeout（デフォルトは 3600s）と run_retention_days（デフォルトは 180、<= 0 で無効）がこれを制御します。期間を過ぎた完了済みの実行は、毎時実行されるハウスキーピングジョブによって削除されます。このジョブは実行中の実行を削除せず、各ポリシーの最新の実行を常に保持します。

結果ステータス

デバイスごと、チェックごとの結果は、pass、fail、skip、warning、error のいずれかです。結果には expected、actual、message、remediation、extra（エンジン固有の詳細情報）が含まれます。

検出事項のライフサイクル

open -> acknowledged -> resolved
                    \-> suppressed

ステータス	使用する場合
open	新規で、レビューが必要な場合
acknowledged	レビュー済みで、修正が計画されている場合
resolved	修正され、合格した実行によって確認された場合
suppressed	意図的な例外として、リスクが受け入れられた場合

コンプライアンススコア

score = passed / (passed + failed + error) x 100

スキップされたチェックは除外されます。スコアは（デバイス、ポリシー、実行）ごとに算出され、時系列で追跡されます。

---

クイックリファレンス — よく使うワークフロー

実行の作成と実行

実行を作成しても、実行は開始されません。次の 2 段階のプロセスを行います。

# Step 1: Create the run — policy, trigger AND status are required (400 without "status")
RUN=$(curl -s -X POST "$NETBOX_URL/api/plugins/validation/runs/" \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"policy": 1, "trigger": "manual", "status": "pending"}')

RUN_ID=$(echo $RUN | python -c "import sys,json; print(json.load(sys.stdin)['id'])")

# Step 2: Execute it (synchronous — returns when complete)
curl -X POST "$NETBOX_URL/api/plugins/validation/runs/$RUN_ID/execute/" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

実行エンドポイントは同期処理で、完了した実行（ステータス、件数、スコア）を返します。ポーリングは不要です。pending（または error）の実行のみ実行できます。完了済みの実行を再実行すると、400 が返されます。

ポリシーパックのインストール

# List available packs (a bare JSON array)
curl "$NETBOX_URL/api/plugins/validation/policy-packs/" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

# Install a pack (creates policy + all rules)
curl -X POST "$NETBOX_URL/api/plugins/validation/policy-packs/addressing-ipam/install/" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

コンプライアンススコアのクエリ

# Fleet-wide latest scores
curl "$NETBOX_URL/api/plugins/validation/compliance/" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

# Scores for a specific device, newest first
curl "$NETBOX_URL/api/plugins/validation/compliance/?device_id=10&ordering=-measured_at" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

# Scores for a specific policy
curl "$NETBOX_URL/api/plugins/validation/compliance/?policy_id=1" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

検出事項のフィルタリング

# Open critical findings from the latest run of each policy
curl "$NETBOX_URL/api/plugins/validation/findings/?latest=true&status=open&severity=critical" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

# Acknowledge a finding
curl -X PATCH "$NETBOX_URL/api/plugins/validation/findings/42/" \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"status": "acknowledged"}'

ブランチに対する実行

curl -X POST "$NETBOX_URL/api/plugins/validation/runs/" \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"policy": 1, "trigger": "manual", "status": "pending", "branch_id": 5}'

検証エンジンは main からルールを読み込み、ブランチのコンテキストでチェックを実行します。その際、ブランチのオーバーレイデータが反映されます。

対象を絞った実行（スコープを限定）

# Target specific site(s)
curl -X POST "$NETBOX_URL/api/plugins/validation/runs/" \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"policy": 1, "trigger": "api", "status": "pending", "target_sites": [9]}'

# Validate a single device across all matching policies
curl -X POST "$NETBOX_URL/api/plugins/validation/runs/validate-device/" \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"device": 101}'

YAML のインポート／エクスポート

# Export a single policy
curl -X POST "$NETBOX_URL/api/plugins/validation/policies/1/export/" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

# Import a policy from YAML
curl -X POST "$NETBOX_URL/api/plugins/validation/policies/import/" \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d @my-policy.yaml

---

ポリシー管理

ポリシーのスコープ設定

ポリシーでは、次の項目を任意に組み合わせてデバイスのスコープを設定します。

スコープフィールド	API フィールド	効果
サイト	sites	これらのサイトにあるデバイスのみ
リージョン	regions	これらのリージョン内のサイトにあるデバイスのみ
サイトグループ	site_groups	これらのグループ内のサイトにあるデバイスのみ
デバイスロール	roles	これらのロールを持つデバイスのみ
プラットフォーム	platforms	これらのプラットフォーム上のデバイスのみ
タグ	device_tags	これらのタグを持つデバイスのみ

各項目には NetBox オブジェクト ID のリストを指定します。スコープフィールドは AND 条件で結合されます。スコープが空の場合、すべてのアクティブなデバイスが対象です。不明なフィールドはエラーにならず、黙って無視されます。そのため、scope_sites を含む本文を送信すると、エラーなしでスコープなしのポリシーが作成されます。書き込み後は、レスポンスから sites／roles を読み戻してください。

curl -X POST "$NETBOX_URL/api/plugins/validation/policies/" -H "Authorization: Bearer $NETBOX_TOKEN" -H "Content-Type: application/json" \
  -d '{"name": "Leaf Baseline", "sites": [1, 2], "roles": [3], "device_tags": [7]}'

選択肢フィールド（ルールの engine、category、severity、実行の trigger、status、結果の status、severity、検出事項の severity、category、status）は、読み戻す際に {"value", "label"} オブジェクトとして返されます。書き込み時には、単独の文字列を指定します。ポリシーの latest_run サマリー内にある status／trigger は、単独の文字列です。x["status"] ではなく、x["status"]["value"] を比較してください。

エンジンの切り替え

ポリシーフィールド	デフォルト	効果
enable_config_engine	false	このポリシーのコンフィグ分析チェックを有効にします
enable_graph_engine	false	このポリシーのグラフレジリエンスチェックを有効にします
trigger_on_cr_submit	true	変更リクエストの送信時に実行します
trigger_on_branch_merge	false	ブランチのマージ時に実行します

意図チェックは常に実行されます。コンフィグチェックとグラフチェックを実行するには、ポリシーで該当するエンジンが有効になっており、かつデプロイメントレベルでも利用可能である必要があります。

ポリシーパック

事前構築済みのポリシーパックをワンクリックでインストールできます。

• 14 個のスターターパック（113 個のルール）— アドレッシング、ケーブル配線、データ品質、命名、冗長性、セキュリティ意図、リーフ／スパインのベースライン、設定分析、変更前設定、BGP 属性、電源／ネットワーク／完全なレジリエンスに対応します
• 9 個のコンプライアンスフレームワーク（177 個のルール、プレミアム）— CLOS Fabric、TIA-942、NIS2/DORA、NIST 800-53、NERC CIP、PCI-DSS、MANRS、ISO 27001、HIPAA Security Rule（2026）

スターターパックはデフォルトで一覧に表示されます。フレームワークパックは、プラグイン設定 enabled_policy_packs に "compliance" が含まれている場合（デフォルトは ["starter"]）にのみ表示され、インストールできます。無効なカテゴリをインストールしようとすると 403 が返されます。GET /policy-packs/ は count／results を含まない、JSON 配列のみを返します。各エントリには slug、name、description、category（starter | compliance）、policy_count、rule_count、engines、installed、installed_policy_ids が含まれます。インストールしたパックは通常のポリシーとルールを作成します。インストール後に、スコープ、パラメーター、トリガー、スケジュールをカスタマイズしてください。references/policy-packs.md を参照してください。

ルールとポリシーの削除

プラグイン 1.13.0 以降、DELETE /rules/{id}/ と DELETE /policies/{id}/ を実行しても、過去の実行結果は保持されます。結果には rule_name と check_name のスナップショットが残り、実行履歴とコンプライアンススコアには policy_name が保持されます。削除後は rule／policy の FK フィールドが null になるため、FK が設定されていると仮定せず、*_name フィールドを参照してください。実行履歴が存在していても、ポリシーパックのアンインストールは拒否されなくなりました。パックのポリシーは削除されますが、その実行履歴はスナップショットされたポリシー名のもとに保持されます。実行履歴の削除（DELETE /runs/{id}/）は、破壊的な処理となる唯一の方法です。この操作では、その実行履歴の結果、検出事項、コンプライアンススコアがカスケード削除されます。

複製とインポート

# Clone a policy (copies all rules and scoping)
curl -X POST "$NETBOX_URL/api/plugins/validation/policies/1/clone/" \
  -H "Authorization: Bearer $NETBOX_TOKEN"

# Import from YAML
curl -X POST "$NETBOX_URL/api/plugins/validation/policies/import/" \
  -H "Authorization: Bearer $NETBOX_TOKEN" \
  -H "Content-Type: application/json" \
  -d @my-policy.yaml

---

検証トリガー

トリガー	方法	備考
手動	API で作成して実行するか、UI で「今すぐ実行」を選択します	2 段階です。作成（trigger: "manual"、status: "pending"）してから実行します
ブランチのマージ	trigger_on_branch_merge: true	NetBox Branching のブランチが main にマージされたときに実行され、マージされたデータのリグレッションを検出します
変更リクエストの送信	trigger_on_cr_submit: true（デフォルトで有効）	NetBox Changes の変更リクエストが送信されたときに実行され、マージ前の安全性を確保するために CR のブランチを対象にします
スケジュール	schedule の cron — 0 2 * * *（毎日 02:00）、0 */6 * * *（6 時間ごと）、0 0 * * 0（毎週）	main を対象とします（ブランチコンテキストなし）。最小間隔は 5 分です

実行時の trigger の値：manual、api、schedule、branch、merge、cr。

実行スコープ

すべての実行で、対象を任意に絞り込めます。

フィールド	型	効果
target_sites	サイト ID のリスト	これらのサイトにあるデバイスのみを対象にします
target_devices	デバイス ID のリスト	これらの特定のデバイスのみを対象にします
target_tags	タグ ID のリスト	これらのタグが付いたデバイスのみを対象にします

対象フィールドはポリシースコープと AND 条件で組み合わされます。対象を絞り込むことのみ可能で、広げることはできません。（公開 API リファレンスでは target_tags にタグのスラッグが示されていますが、エンドポイントでは他の対象フィールドと同様に NetBox のタグ ID を指定します。）

---

コンプライアンスと検出事項

スコアのディメンション

コンプライアンススコアは、デバイス（複数のポリシーを横断）、ポリシー（複数のデバイスを横断）、サイト／ロール（?site_id=、?role_id=）、時間（コンプライアンスダッシュボードおよび /compliance/trend/ で 7 日／30 日／90 日の推移）でクエリできます。

検出事項の集約

検出事項は、関連する失敗を実行可能な項目にまとめます。たとえば、5 台のデバイスで no_duplicate_ips が失敗した場合、1 つの検出事項に 5 台すべてがまとめられます。グラフエンジンの検出事項は失敗箇所ごとにまとめられます（電源フィードまたは共有障害ドメインごとに 1 つの検出事項）。各検出事項には affected_devices、is_new、recurrence_count、first_seen、policy_id／policy_name、has_blast_radius が含まれます。

重大度のエスカレーション

グラフエンジンの検出結果は、影響範囲に基づいて重大度が自動的に引き上げられます。

保護されていないデバイス数	エスカレーション
1--2	変更なし
3--5	medium -> high
6--10	high -> critical
10+	常に critical

検出結果のトリアージ

1. 重大度で検出結果をフィルタリングします（critical を優先）。現在の検出結果のみを対象にするには ?latest=true を使用します
2. 詳細を確認します：影響を受けるデバイス、expected と actual、remediation
3. グラフの検出結果については、影響範囲カードを確認します
4. 修正する予定の検出結果を確認済みにします
5. NetBox で根本的な問題を修正します
6. 検証を再実行して確認します
7. 検出結果を解決済みにします

---

統合パターン

変更前の検証パイプライン

1. Create Branch          (netbox-branching)
2. Make changes           (normal NetBox API with X-NetBox-Branch header)
3. Submit Change Request  (netbox-changes) -> validation auto-runs
4. Review validation results
5. Approve CR, merge branch
6. Post-merge validation auto-runs (optional)

マージ前の安全性を確保するには、trigger_on_cr_submit: true を設定します。マージ後の検証には、trigger_on_branch_merge: true を設定します。

ブランチコンテキスト

ブランチに対して検証を実行する際は、実行時に branch_id を渡します。エンジンは main からルールを読み込み、ブランチのコンテキストで（追加、変更、削除の提案を確認しながら）チェックを実行します。

構成分析では、差分分析（到達性の喪失、BGP セッションの破損、ルーティングのリグレッション）のために、main とブランチの両方から構成をレンダリングします。

MCP を介したエージェント連携

NetBox Labs Platform MCP Server は、5 つの検証ツールを提供します。

ツール	用途
run_validation	ポリシーの実行を作成して実行します。必要に応じてブランチまたはデバイスを対象にできます
get_compliance_analytics	コンプライアンススコア、傾向、ディメンション別スコア
get_findings_analytics	重大度、ステータス、カテゴリ、ポリシーでフィルタリングした検出結果
import_validation_policy	YAML からポリシーをインポートします
clone_validation_policy	すべてのルールとスコープ設定を含むポリシーを複製します

REST API への直接アクセスを優先するエージェントは、ベアラートークン認証を使用して REST エンドポイントを利用できます。

エージェントワークフローパターン

Agent creates branch -> makes changes -> runs validation
  Pass -> creates change request for human review
  Fail -> reads findings, self-corrects, re-validates

検証は、エージェントが人間のエンジニアと同じポリシーフレームワークの範囲内で動作することを保証する、自動化されたセーフティネットを提供します。

---

アンチパターン

間違い	失敗する理由	代わりに行うこと
実行が開始されると思い込んで実行を作成する	実行を作成すると、ステータスは pending に設定されます	作成後に /runs/{id}/execute/ に POST します
実行の作成時に trigger または status を省略する	どちらも必須です — 400 {"status": ["This field is required."]}（公開 API リファレンスでは status が省略されていますが、エンドポイントでは引き続き必須です）	リクエストボディは常に {"policy": <id>, "trigger": "manual", "status": "pending"} です（trigger には "api" または "schedule" を指定できます）
scope_sites／scope_roles／scope_tags でポリシーのスコープを設定する	未知のフィールドは通知なく破棄され、ポリシーはスコープなし（すべてのデバイス対象）で作成されます	sites、regions、site_groups、roles、platforms、device_tags（ID のリスト）を使用し、レスポンスから sites／roles を読み取ります
選択肢フィールドを文字列だけで比較する	status、trigger、engine、category、severity は {"value", "label"} として返されます	["value"] を比較し、書き込む際は文字列だけを指定します
ブランチの整数 ID をブランチ検証に使う	実行の作成時に指定する branch_id ではブランチの整数 ID が必要ですが、X-NetBox-Branch ヘッダーでは schema_id を使用します	コンテキストごとに正しい識別子を使用します
エンジンを有効にせずに設定／グラフパックをインストールする	設定／グラフルールの結果は skip になります	ポリシーで enable_config_engine／enable_graph_engine を設定します
スターターパックのみが有効な状態でコンプライアンスパックをインストールする	POST .../install/ は 403 を返します	プラグイン設定 enabled_policy_packs に "compliance" を追加します
skip を失敗として扱う	スキップはスコアから除外され、検出事項も作成されません	結果の message を読み取ります — Config Template がない、電源ポートがない、またはエンジンが利用できません
ターゲットのスコープ指定によってポリシーのスコープが広がると思い込む	ターゲットのフィールドとポリシーのスコープは AND 条件で適用されます	ターゲットでできるのはスコープを絞り込むことだけです — ポリシーのスコープ外のデバイスは除外されます
実行後に完了するまでポーリングする	実行は同期処理です — 完了時に応答が返ります	応答を直接読み取ります。ポーリングは不要です
デバイスをターゲットにしてグラフチェックを実行し、処理量が減ると期待する	グラフエンジンはサイト内のすべてのデバイスを読み込みます	グラフの処理が多いポリシーでは、サイトをスコープ指定して実行します

---

API エンドポイントの概要

エンドポイント	メソッド	目的
/policies/	GET, POST	ポリシーの一覧表示と作成
/policies/{id}/	GET, PUT, PATCH, DELETE	ポリシーの管理
/policies/{id}/clone/	POST	すべてのルールとスコープ設定を含めて複製
/policies/{id}/export/	POST	YAML としてエクスポート
/policies/import/	POST	YAML からインポート
/policies/export-all/	POST	すべてのポリシーをエクスポート
/policies/{id}/run-for-site/	POST	サイトを対象に実行 — {"sites": [...]}。作成して実行
/policies/{id}/run-for-devices/	POST	デバイスを対象に実行 — {"devices": [...]}。作成して実行
/rules/	GET, POST	ルールの一覧表示と作成（policy_id、engine、category、severity、is_active でフィルタリング）
/rules/{id}/	GET, PUT, PATCH, DELETE	ルールの管理
/runs/	GET, POST	実行の一覧表示と作成（policy_id、status、trigger、branch_id、has_branch、created_after/before でフィルタリング）
/runs/{id}/	GET, DELETE	実行のステータスと概要。DELETE すると、実行とその結果、検出事項、スコアが連鎖的に削除されます
/runs/{id}/execute/	POST	保留中の実行を実行
/runs/validate-device/	POST	デバイスに一致するすべてのポリシーを実行
/results/	GET	結果（run_id、device_id、rule_id、status、severity、engine でフィルタリング）
/findings/	GET, POST	検出事項（run_id、severity、status、category、policy_id、device_id、site_id、role_id、branch_id、is_new、latest、q でフィルタリング）
/findings/{id}/	GET, PUT, PATCH	検出事項のステータスを更新
/findings/summary/	GET	ステータス、重要度、カテゴリ別の検出事項数（フィルターを反映）
/findings/bulk-update-status/	POST	{"ids": [...], "status": "..."} — ステータスを一括変更
/findings/matrix/	GET	未解決の検出事項数をカテゴリ × 重要度で集計（?site_id=、?role_id=）
/compliance/	GET	コンプライアンススコア（device_id、policy_id、run_id、site_id、role_id でフィルタリング）
/compliance/summary/	GET	フリートのスコア、デバイス数、検出事項数
/compliance/trend/?days=N	GET	コンプライアンススコアの日次推移
/compliance/breakdown/?group_by=site|role|policy	GET	ディメンション別にスコアを集計（削除されたポリシーも、スナップショット時の名前で履歴が保持されます）
/compliance/distribution/	GET	デバイスのコンプライアンススコアのヒストグラム
/compliance/worst-performers/?limit=N	GET	スコアが最も低いデバイス
/policy-packs/	GET	パックの配列（slug、category、rule_count、engines、installed、installed_policy_ids）
/policy-packs/{slug}/	GET	policies[] と rules[] を含むパックの詳細
/policy-packs/{slug}/install/	POST	パックをインストール（カテゴリが有効になっていない場合は 403）
/policy-packs/{slug}/uninstall/	POST	パックをアンインストール

すべてのエンドポイントは /api/plugins/validation/ の下にあります。

---

バージョンに関する注記

Plugin 1.14.x（2026-09 – 2026-10）

• 1.14.0：NetBox 4.7 をサポート（4.4～4.7.x に対応）。
• 1.14.1：plugin-catalog のメタデータのみ。
• 1.14.2：ルールの category に routing、security、baseline、overlay が追加されました（同梱パックでは、addressing、redundancy、standards、completeness、security_intent、topology、reachability、power、infrastructure と併せて使用）。
• 1.14.3（2026-10-06）：ユーザーから見える変更はありません。

NetBox 4.7 (2026-09-02)

• プラグイン 1.14.0+ が必要です。チェックはNetBoxのデータをサーバー側で評価するため、チェック名とパラメーターに変更はありません。
• 変更されるのは、エージェントが検出結果を修正する際に使用するコアREST APIです。選択肢型のカスタムフィールドは {"value", "label"} として読み取られます（生の値を書き込んでください。custom_field_populated / asset_documentation_complete の失敗後に該当します）。デバイスの読み取りでは、デフォルトで config_context が含まれます（4.7.3以降では ?omit=config_context で省略できます）。?exclude=config_context は無視されるため、?fields= を使用してください。また、サービスでは protocol + ports の代わりに port_mappings（["tcp/443"]）を使用します。一括修正に失敗した場合は、オブジェクトごとのエラーが index で返されます。netbox-api-integration を参照してください。
• NetBox 4.7でブランチコンテキストを使用するには、netbox-branching 1.2.x が必要です（NetBox 4.4～4.6では1.1.x）。netbox-branching を参照してください。

プラグイン 1.12–1.13 (2026-08)

• 1.12.0：実行ライフサイクルを強化（ジョブのタイムアウト、孤立した実行の回収、実行とジョブの関連付け）。1.13.0：実行履歴を失わずにルールとポリシーを削除可能に。

---

参考資料

参考資料	読み込むタイミング
references/api-patterns.md	ポリシー／実行／結果のライフサイクルに関するAPIの完全な例が必要な場合
references/check-reference.md	95種類すべてのチェックの名前、パラメーター、またはエンジンの詳細が必要な場合
references/policy-packs.md	パックのカタログ、スラッグ、インストール／カスタマイズのガイダンス、フレームワークの詳細が必要な場合