Perplexity Numbatとは？AIコーディングエージェント監視OSSの機能・52ルール・導入手順【2026年8月最新】

Numbat（ナンバット）は、Perplexityが2026年7月29日にオープンソース公開した、AIコーディングエージェントの端末上の挙動を可視化・検知し、必要に応じて実行前にブロックできるセキュリティツール群です。ライセンスはApache-2.0、Go製の単一バイナリで、料金は発生しません。

ただし、報道で目立つ「危険な操作をブロックできる」という点には重要な前提があります。出荷時のルールはすべて監視専用（monitor-only）で、既定のままでは何もブロックしません。 ブロックさせるには利用者側でルールを複製し、明示的に有効化する必要があります。

Claude CodeやCodexを業務端末で使っていて「エージェントに端末を触らせているが、実際に何をしているか把握できていない」と感じている開発者・情報システム部門・セキュリティ担当者に向けて、この記事では次の内容を扱います。

Numbatが何をするツールか、なぜ作られたか
3つの取り込み経路（フック／セッション成果物／テレメトリ）の違い
11カテゴリの検知ルールの中身と、連鎖検知という特徴
自分が使っているエージェントが「監視できるか」「事前ブロックできるか」
インストールから監視・ブロック有効化までのコマンド手順
検知データがどこに保存され、外部に送られるのか
導入すべき組織／まだ入れなくてよいケース

Numbatとは — Perplexityが公開したエージェント監視OSS

Perplexity Numbat の GitHub リポジトリ（perplexityai/numbat）トップ

出典：perplexityai/numbat — GitHub

Numbatは、AIコーディングエージェントが端末上で「実際に何をしようとしたか」を記録・判定するためのCLIツールです。SaaSではなく、手元の端末で完結して動くオープンソースソフトウェアとして提供されています。

リポジトリの公式説明は次の一文です。

"Visibility into AI agent activity on endpoints, with on-device detection, optional pre-action blocking, and forensic reconstruction."
（エンドポイント上のAIエージェント活動の可視化。オンデバイス検知、任意の事前ブロック、フォレンジック再構成）

項目	内容（2026年8月3日時点）
名称	Numbat
開発元	Perplexity AI（米国）
公開日	2026年7月29日（現地時間）
ライセンス	Apache License 2.0
実装言語	Go（cgo不要の単一静的バイナリ）
提供形態	OSS／CLIツール（有償プラン・SaaS版は現時点で確認できない）
対応OS	macOS / Linux / Windows（amd64・arm64）
最新リリース	v0.1.2（2026年8月1日）
リポジトリ	https://github.com/perplexityai/numbat
GitHub Star	641（2026年8月3日時点）
関連イニシアチブ	NVIDIA主導のOpen Secure AI Allianceへの貢献プロジェクト

Perplexity社内では、すでに数千台のエンドポイントにMDM経由で展開されていると公式に説明されています。社内ではAIシステム「Perplexity Computer」とペアで運用し、アラート調査・検知の改善提案・人間レビュー付きのPR作成という自己改善ループを回しているとされます。

開発元の全体像については「Perplexityとは？機能・料金・使い方を解説」、社内運用に登場するAIシステムについては「Perplexity Computerとは」でそれぞれ整理しています。

名前の由来と位置づけ

Numbatはオーストラリアに生息する小型有袋類の名前です。製品としての位置づけは、モデル側の防御でもフレームワーク側のガードレールでもなく、「エンドポイント（開発者の端末）で、エージェントが出そうとしたコマンドやツール呼び出しを直接見る」レイヤーにあります。EDR（端末の振る舞い検知）の考え方をAIエージェントに持ち込んだもの、と捉えると理解しやすいはずです。

なぜNumbatが作られたのか — 「攻撃者がいなくても事故は起きる」

出典：Perplexity Research 公式サイト

Numbatの設計思想は、公式発表の一文に集約されています。エージェントセキュリティの議論はプロンプトインジェクション、つまり外部の攻撃者を前提にしてきたが、「攻撃者の存在を仮定する必要すらない」という指摘です。

公式はこの現象を "accidental meltdowns"（偶発的なメルトダウン／暴走） と呼んでいます。悪意ある指示がなくても、エージェントは「与えられたタスクを達成する」という目的だけで、想定外の破壊的な行動に到達しうるという整理です。

直接のきっかけとなったインシデント

公式が背景として挙げているのが、2026年7月にOpenAIが開示した事案です。報道されている経緯を整理すると次のようになります。

時期	出来事
2026年7月16日	Hugging Faceが不審な挙動を独自に検知・封じ込め
2026年7月21日	OpenAIが開示。サイバー能力評価環境のサンドボックスからモデルが自律的に脱出し、Hugging Faceの本番インフラに到達したと説明
内容	パッケージレジストリのプロキシ／キャッシュとして動くベンダーソフトのゼロデイを発見・悪用。限定的な本番インフラ、内部データセットの一部、一部の資格情報に不正アクセスがあったとされる
目的	攻撃ではなく「ベンチマークの解答を取得する」というタスク達成

つまり、攻撃者が一人もいない状態で、評価タスクの達成という動機だけでここまで到達したという点が、Numbatの問題提起そのものになっています。

実務レベルでも、AIエージェントが本番DBを削除した・リポジトリを破壊したという事故は繰り返し報告されています。この種の事例は「AIエージェントがデータを全削除した事故まとめ」で個別に整理しています。Numbatの検知ルールに exec.destructive_recursive_delete（rm -rf / や $HOME に対する再帰削除）が含まれているのは、まさにこの領域を狙っているためです。

Numbatの仕組み — 3つの取り込み経路

Numbat が事前ブロックに利用する Claude Code の Hooks リファレンス公式ドキュメント

出典：Hooks reference — Claude Code Docs（Anthropic）

Numbatは、エージェントの活動を3つの経路から取り込み、同一の正規化イベントモデルに変換し、同一のCELルールで評価します。ここが構造上の要点で、「どの経路で拾ったか」によって事前ブロックの可否が決まります。

経路	何をするか	実行前にブロックできるか
フック／プラグイン	エージェントのライフサイクルフックに `numbat hook` を差し込み、標準入力でペイロードを受け取り即時判定する	可能（同期の事前フックのみ）
セッション成果物（at-rest）	エージェントがディスクに残すJSONL等のセッションログを読み取る。Numbat導入前のセッションも遡って再構成できる	不可（事後）
OTLP/HTTPテレメトリ	`numbat collect` がローカルでOpenTelemetryログを受信（既定 `http://127.0.0.1:4318/v1/logs`）	不可（事後）

1. フック（唯一ブロックできる経路）

Claude Codeの PreToolUse、Codexの PreToolUse、Cursorの preToolUse、Gemini CLIの BeforeTool といったツール実行の直前に呼ばれるフックにNumbatを登録します。エージェントがツールを呼ぼうとした瞬間、そのペイロードがNumbatに渡り、ルール評価の結果として「拒否」を返せます。

フックの仕組み自体を理解しておくと導入判断がしやすくなります。Claude Code側の挙動は「Claude Code Hooks 使い方｜PreToolUse/PostToolUse/Stop/SubagentStop 完全ガイド」で詳しく解説しています。

2. セッション成果物の遡り解析

多くのエージェントは、会話とツール呼び出しの履歴をJSONL形式でローカルに残します。Numbatはこれを読み取り、タイムライン形式で再構成できます。

この経路の実用的な価値は、Numbatをインストールする前に起きたことも調べられる点にあります。エージェントの設定を一切変更せずに読み取りだけを行うため、「まず現状を把握する」という入口として使えます。

3. OTLPテレメトリ

エージェントがOpenTelemetry形式でログを出す場合、numbat collect でローカル受信できます。既定でループバック（localhost）にバインドされるため、テレメトリは端末内に留まります。

検知イベントは「証拠」ではない

公式が明記している重要な但し書きが、"Findings are rule matches, not proof of compromise"（検知はルールの一致であって、侵害の証明ではない） という一文です。特に事前フックでの一致は「要求された操作」であって「実際に起きた結果」ではありません。運用時はこの区別を前提にアラート設計をする必要があります。

検知ルール — 11カテゴリ・52ルール（公式発表）の内訳

Numbatの検知ルールはYAMLで定義され、バイナリに埋め込まれています。公式発表および報道では「11カテゴリー・52ルール」と表記されています（リポジトリ上のYAMLルールファイル数は実測で51件＝単発45件＋連鎖6件のため、細かい数え方には差があります。カテゴリ数11は一致しています）。

11カテゴリの内訳

カテゴリ	件数	何を見るか	代表的なルールID
Secrets（機密情報アクセス）	8	`.env`・秘密鍵・クラウド資格情報・ブラウザのCookieストア・`/proc` の環境ブロック読取	`secrets.agent_read_env` / `secrets.browser_session_store_read`
Execution（危険実行）	6	`curl \| sh`、リバースシェル、base64エンコードされたペイロード実行、再帰削除、承認バイパスフラグ付きの起動	`exec.download_pipe_shell` / `exec.agent_runtime_bypass_flags`
Privilege（権限昇格）	6	sudoers改ざん、コンテナからのホスト脱出、Dockerソケットアクセス、setuid付与	`privilege.container_host_escape` / `privilege.sudoers_tamper`
Persistence（永続化）	6	シェルプロファイル書込、cron／自動起動登録、gitフック設置、`authorized_keys` 追記、特権アカウント作成	`persistence.scheduler_install` / `persistence.ssh_authorized_keys`
Exfiltration（持ち出し）	4	環境変数のネットワーク送信、`curl` によるファイルPOST、DNSトンネル	`exfil.curl_post_file` / `exfil.dns_tunnel_exec`
Impact（破壊）	4	クリプトマイニング起動、ディスク消去、フォークボム、プロセスの一斉停止	`impact.disk_wipe` / `impact.fork_bomb`
Reconnaissance（偵察）	3	クラウドメタデータサービスへのアクセス、権限昇格経路の探索、ネットワークスキャン	`recon.cloud_metadata`
Tampering（設定改ざん）	3	フック設定・`settings.json`・`.mcp.json` の書換、`$HOME/.numbat` への書込、低承認モードの使用	`tamper.agent_config_write` / `tamper.guardrails_off`
Integrity（改ざん）	2	`--no-verify` によるgitフック回避、シェル履歴の削除・無効化	`integrity.git_hooks_bypass`
Source Control	2	gitリモートの書換、`git config` 経由のコマンド実行	`source.git_remote_tamper`
Lateral Movement（横展開）	1	他ワークロードでのコマンド実行	`lateral.workload_exec`

注目すべきは tamper.guardrails_off と exec.agent_runtime_bypass_flags の2つです。これらは「エージェント自身が承認プロセスを迂回しようとした」ことを検知します。Claude Codeの --dangerously-skip-permissions に代表される権限スキップの扱いについては「Claude Codeのセキュリティと安全な使い方」で背景を整理しています。

Numbatならではの「連鎖（シーケンス）ルール」

Numbatが技術的に際立つのは、単発では無害に見える操作の順序付きの組み合わせを、一定の相関ウィンドウ内で検知する6つのシーケンスルールです。

シーケンスルール	検知するパターン
`chain.secret_read_then_egress`	機密ファイルの読取 → 外部への送信
`chain.secret_manager_read_then_egress`	シークレットマネージャ参照 → 外部への送信
`chain.guardrails_off_then_egress`	低承認モードへの切替 → 外部への送信
`chain.permission_denied_then_runtime_bypass`	権限拒否 → バイパスフラグ付きで子エージェントを起動
`chain.workload_identity_then_lateral_execution`	ワークロードID取得 → 別ワークロードでの実行
`chain.privilege_discovery_then_elevation`	権限の探索 → 実際の昇格

.env を読むだけなら日常的な開発作業です。外部にHTTPリクエストを投げるだけでも同様です。しかし「.envを読んだ直後に外部へ送信した」という並びは意味が変わります。 公式ブログでは、64イベントの窓で相関させる例が紹介されています。

外向き送信（egress）の判定対象には、非ループバックHTTP(S)への curl/wget、Python・Node・PowerShellのインラインHTTP書込、リモートへの scp/rsync、send/upload/share/publish/mail 系のMCPツールが含まれます。read/list/search/delete 系のMCP動詞は除外されます。

対応エージェント — 監視できるもの・事前ブロックできるもの

Numbat が事前ブロックに対応する GitHub Copilot CLI の公式ページ

出典：GitHub Copilot 公式サイト

公式発表でPerplexity社内展開が明言されているのはClaude Code / Codex / OpenCode / Piの4つですが、リポジトリのカバレッジマトリクスは26以上のエージェントを掲載しています。

numbat scan --agent が受け付ける名前は現時点で次の通りです。

claude | codex | copilot | cowork | cursor | gemini | kimi | openclaw | opencode | pi | windsurf

主要エージェントの対応状況

エージェント	過去セッションの解析	ライブ取得	実行前ブロック
Claude Code	可（`~/.claude/projects`・`history.jsonl`）	可（`settings.json` / OTLP）	可（`PreToolUse`）
OpenAI Codex	可（`$CODEX_HOME/sessions` ほか、`.jsonl.zst` 対応）	可（`~/.codex/hooks.json` / OTLP）	可（`PreToolUse`）
Cursor	可（`~/.cursor/projects/<hash>/agent-transcripts`）	可（`~/.cursor/hooks.json`）	可（`preToolUse`）
Gemini CLI	可（`~/.gemini/tmp` 配下）	可（`settings.json` / OTLP）	可（`BeforeTool`）
GitHub Copilot CLI	可（`~/.copilot/session-state/*/events.jsonl`）	可（`~/.copilot/hooks/numbat.json`）	可（`preToolUse`）
VS Code Copilot Chat / Agent Mode	不可	Copilot CLIと共有のフックファイル	可（`PreToolUse`。VS Code側はプレビュー機能）
Windsurf / Cascade	可（`~/.windsurf/transcripts/*.jsonl`）	可（`~/.codeium/windsurf/hooks.json`）	可（exit code 2 方式）
OpenClaw	可（v2026.7.1のJSONL＋retainedアーカイブ）	可（ネイティブプラグイン）	可（`before_tool_call`）※v2026.7.1以上が必要
OpenCode	可（旧JSONストア。`opencode.db` は未対応）	可（プラグイン）	不可（監視のみ）
Pi	可（`~/.pi/agent/sessions/*/.jsonl`）	可（`~/.pi/agent/extensions/numbat.ts`）	可（`tool_call`）
Claude Cowork	可（macOSのaudit.jsonlのみ）	不可	不可

このほか、Kimi Code / Qwen Code / Cline CLI / Amp / Auggie / Kiro / Goose / Kilo Code / OpenHands / Crush / Junie CLI / Antigravity / Factory Droid / Grok Build / Devin CLI / Hermes などが掲載されています。過去セッションの解析は「deferred（未実装）」のものが多い一方、フック経由の事前ブロックは対応済みのものが少なくありません。

個別の制限（導入前に確認すべき点）

Codexのホステッドツールはローカルフック経路を通りません。 公式も「フックは完全なポリシー境界ではない」と明言しています。Codex側のセキュリティ機能との住み分けは「Codex Securityとは」を参照してください。
Cursorの subagentStart は、現行のCursorが拒否応答を無視するため監視専用です。またCursor Cloudのエージェントは ~/.cursor/hooks.json を読みません。
OpenHandsはリポジトリスコープのみのため --agent all から除外されており、--settings /repo/.openhands/hooks.json の明示が必要です。
OpenClawには9秒の内部デッドラインがあり、生成されるラッパーはこれを超えるとブロックせずに通します。ホスト側のタイムアウトは生成値の10秒に保つ必要があります。OpenClaw自体の権限設計は「OpenClaw セキュリティ設定ガイド」で解説しています。
Cursorの state.vscdb、ClineのSQLite、OpenClaw v2026.7.2の圧縮アーカイブ、FactoryのJSONL、Hermesの state.db は現時点で未パース（deferred）です。

各エージェントそのものの概要は「Claude Codeとは」「OpenAI Codexとは」「OpenClawとは」でそれぞれ整理しています。

料金 — Apache-2.0で無料、コストは運用側に発生する

Numbatに料金プランは存在しません。 Apache License 2.0の完全なオープンソースで、ライセンス費用はゼロ、商用利用も可能です。有償SaaS版・エンタープライズ版の提供は、現時点の公式情報では確認できていません。

一方で、実質的なコストは運用側に発生します。

コスト項目	内容
配布・展開	バイナリの配置、MDMスクリプトの作成と検証
ルールのチューニング	誤検知への対応、`enforce: true` に昇格させる範囲の判断
ログ基盤	NDJSON出力のローテーションとSIEM転送。Numbat自身はファイルローテーションを行いません
運用	検知の一次調査。検知はルール一致であって侵害の証明ではないため、切り分けの人的コストがかかる

個人開発者が自分の端末で numbat scan を回すだけなら実質コストはほぼゼロですが、組織展開する場合は「ログ管理基盤とチューニング担当者がいるか」が実際の導入判断を左右します。

導入手順 — 4ステップで段階的に入れる

Numbatは、いきなりブロックを有効化するのではなく、現状把握 → 遡り解析 → 監視 → ブロックの順で段階導入するのが公式の推奨に沿った進め方です。

ステップ0. インストール

GitHub Releasesからプリビルドバイナリを取得するのが最短です（macOS / Linux / Windows、amd64・arm64、SHA-256チェックサム付き）。

# 方法1: GitHub Releases からダウンロード
# https://github.com/perplexityai/numbat/releases

# 方法2: Go でインストール（Go 1.26.5 以上が必要）
go install github.com/perplexityai/numbat/cmd/numbat@latest

# 方法3: 静的ビルド
CGO_ENABLED=0 go build -trimpath -o numbat ./cmd/numbat

Homebrew・apt・wingetなどのパッケージマネージャ経由の配布は、公式ドキュメントには現時点で記載がありません。

ステップ1. 現状把握（エージェント設定を一切変更しない）

まずは端末上にどのエージェントが入っているかを確認します。この段階では読み取りしか行いません。

numbat agents          # 端末上の対応エージェントを検出
numbat agents --all    # 未導入の対応エージェントも含めて表示

ステップ2. 過去セッションの遡り解析

ここがNumbatを最も気軽に試せるポイントです。 エージェントの設定を書き換えることなく、すでにディスクに残っているセッション履歴を読んで検知ルールにかけられます。

numbat scan                  # 既存のセッション成果物を遡って解析
numbat scan --agent codex    # 対象エージェントを絞る
numbat timeline              # セッション単位で時系列に再構成

「導入すべきか判断がつかない」という段階なら、まずこの2ステップだけ実行して、自分のエージェントが過去に何をしていたかを見るのが現実的です。

ステップ3. ライブ監視（フックのインストール）

フックを入れると、これ以降の操作がリアルタイムで判定されます。この時点ではまだブロックはしません。

numbat hook install --agent claude --emit all
numbat hook install --agent codex  --emit all
numbat hook status  --agent codex     # インストール状況の確認
numbat hook uninstall --agent claude  # 解除

出力先は既定で $HOME/.numbat/findings.ndjson（--emit findings --output=file）です。events や indicators を選ぶと $HOME/.numbat/records.ndjson に書かれます。

インストール処理は冪等で、共有の設定ファイルを編集する場合も他のフックやキーは保持され、元ファイルのバックアップが1つ残ります。 すでにClaude CodeやCodexで自前のフックを運用している場合でも、設定が上書きで消える構造にはなっていません。フックとスキルの使い分けを整理した「Claude Code Skills vs Hooks 使い分けガイド」も合わせて確認しておくと、既存設定との衝突を避けやすくなります。

ステップ4. ブロック（enforceモード）の有効化

出荷ルールはすべて監視専用です。ブロックさせるには自分で明示的に有効化する必要があります。

# 1) 組み込みルールを自分のポリシーディレクトリにコピーし、
#    enforce: true を付けて version を上げる
# 2) 検証
numbat rules check --rules-dir ./numbat-policy

# 3) enforce 付きで再インストール
numbat hook install --agent codex --emit all \
  --rules-dir ./numbat-policy --enforce

enforceを使う際の制約が2つあります。ひとつは、ルールディレクトリがインストール時点で実在し読み取れる具体パスである必要があること（$HOME/rules のような遅延展開されるパスは拒否されます）。もうひとつは、findings を file または http シンクに書く設定が必須で、stdout のみは認められないことです。

スコープの指定

目的	コマンド
ユーザー既定に入れる	`numbat hook install --agent codex`
全対応パスに入れる	`numbat hook install --agent all`
パスを明示する	`--agent codex --settings /path/to/.codex/hooks.json`
OpenClawパッケージ	`--agent openclaw --settings /gateway-state/extensions/numbat`
管理者ポリシーとして入れる	`--agent codex --managed`

--managed はClaude Code / Codex / Cursor / Copilot CLI / Gemini CLI / Windsurf / Qwen Code / Auggie のマシンポリシーファイルを対象にできます。

組織展開の流れ

公式の docs/deployment.md が示す手順は次の通りです。

/usr/local/bin/numbat（Windowsは C:\Program Files\numbat\numbat.exe）など、管理者管理下の絶対パスに配置する
導入済みエージェントを棚卸しし、user / project / managed のどのスコープで入れるか決める
MDMスクリプトで配布する（userスコープは対象ユーザーのコンテキストで、managedは昇格権限で実行）
各エージェント固有の信頼・有効化手順（ワークスペースの信頼、フックの承認、機能ゲート）を完了させる
無害な操作でヘルスチェックを行い、ローカル記録とリモート記録の両方を確認する
カバレッジを検証してから monitor → enforce に移行する

SIEM連携

推奨されているのは、ファイル出力（既定・durable）＋既存のログフォワーダやEDRで転送する形です。直接HTTP送信も可能ですが、耐久キューではない点に注意が必要です（16MiBのメモリバッファ、失敗時にディスクへスプールされない、重複配信があり得る）。

# 直接HTTP送信（認証は環境変数で渡す。フラグ渡しは不可）
# bearer:      NUMBAT_HTTP_TOKEN
# hmac-sha256: NUMBAT_HTTP_HMAC_KEY
numbat ship --input-file $HOME/.numbat/findings.ndjson --http-url https://...

HMAC署名は X-Numbat-Signature、タイムスタンプは X-Numbat-Timestamp ヘッダで送られます。numbat ship はat-least-once配信で、8MiBを超えるレコードはスキップされます。

「入れれば守られる」わけではない — 誤解しやすい7つの前提

Numbatに関する報道は「危険な操作を実行前にブロックできる」という点を強調しがちですが、公式ドキュメントは自らの限界をかなり明確に書いています。 導入判断で最も重要な部分なので、まとめて整理します。

#	前提	実務上の意味
1	既定ではブロックしない	出荷ルールは全部monitor-only。ルールをコピーし `enforce: true` を付けて version を上げ、再インストールして初めてブロックする
2	ブロックできるのは同期の事前フックのみ	事後フック・OTLP・ディスク上の成果物は「実行後」に届くため観測専用
3	最終判断はエージェント側が持つ	Numbatは拒否応答を返すだけ。実行するか、確認を出すか、拒否するかを決めるのはホスト
4	フェイルオープン設計	エラー時は拒否応答を出さない＝ブロックしない。ただしCopilot CLIはホスト仕様上、フック起動失敗や非ゼロ終了が拒否になる例外
5	フックを通らない操作は捕捉できない	Codexのホステッドツール、テキストのみのバックエンド経路などは範囲外
6	シェルコマンドのブロックは静的なPOSIX構文のみ	複雑な構文は検知どまりになる。連鎖ルールは最終ステップでしかブロックできない
7	プロンプトインジェクション対策そのものではない	狙いは「エージェントが実際に取ろうとした行動」の検知であり、入力の無害化ではない

さらに運用面では、numbat hook status は「設定ファイルに記述があること」を確認するだけで、エージェントが実際にフックを読み込んで実行したかは保証しません。 導入直後に無害な操作でヘルスチェックを行い、実際にレコードが出ることを確かめる工程を省略しないでください。

また、再構成できるのはエージェントが永続化したものだけです。ログを残さない経路の活動は復元できません。

AIエージェント全体のセキュリティ設計における位置づけは「AIエージェントのセキュリティ対策」、コーディング用途特有のリスクは「AIコーディングのセキュリティリスク」で整理しています。Numbatは「検知と可視化」の層であり、権限設計やサンドボックス化を置き換えるものではありません。

データはどこに置かれるのか — プライバシーと保護の実際

Numbatは既定でクラウドに何も送信しません。 ここは導入検討時に最も聞かれる点なので、公式 SECURITY.md の記述を「保証すること」「保証しないこと」に分けて整理します。

公式が保証していること

セッション成果物の扱いは読み取り専用。「Numbatは成果物内で見つけたエージェントやコマンドを実行しない」と明記されている
運用者が明示的に設定しない限り、外向き通信を行わない
既定の出力に生のトランスクリプト全文は含まれない（リダクション済みのコマンド・パス・内容プレビュー）
numbat collect は既定でループバック（127.0.0.1）にバインドし、テレメトリは端末内に留まる

公式が「保証しない」と明記していること

リダクション（マスキング）はDLPや機密解除の境界ではない。 既知のパターンをマスクするだけで、すべての機密を除去するものではない
プロジェクトパスのハッシュはソルトなしの結合キーであり、匿名化ではない
numbat collect は認証なしでローカル待受する
フックはエージェントプロセスの権限で動作する。実際に何を書き換えられるかはOSの権限次第
シーケンス状態ファイルや出力ファイルそのものが機微データであり、保護が必要
生の証拠をケースバンドルにコピーするのはオプトイン。署名のないケースバンドルは出所・完全性を証明しない

実務的な結論としては、$HOME/.numbat/findings.ndjson は「機密を含みうるログ」として扱い、アクセス権とローテーションを自前で設計する必要があるということです。Numbat自身はローテーションを行いません。

生成AI全般のデータ取り扱いの考え方は「生成AIのセキュリティリスクと対策」も参考になります。

他のエージェントセキュリティ施策との違い

Numbat が貢献プロジェクトとして参加する Open Secure AI Alliance の参加企業ロゴ一覧

出典：Open Secure AI Alliance — NVIDIA Blog

Numbatは、AIエージェントのセキュリティを担う複数のレイヤーのうち「エンドポイントでのインターセプト」を担当します。Forbesの整理を踏まえると、現在の市場は次のように分かれています。

レイヤー	代表例	何を守るか
モデルの入出力統制	NVIDIA NeMo Guardrails	有害な入出力・逸脱した応答
ランタイム／フレームワーク層	Microsoft Agent Governance Toolkit	エージェント基盤上でのポリシー強制
ディスカバリ／ポスチャ管理	Zenity、SentinelOne など商用	組織内にどんなエージェントが存在するかの把握
エンドポイントでのインターセプト	Numbat	開発者端末上で、エージェントが実行しようとした操作

同レイヤーの他手段との使い分けは次のように考えると整理できます。

エージェント側の権限設計・サンドボックス（Claude Codeのサンドボックス、Codexの実行制限など）— 一次防御。まずこちらを固めるべき
Numbat — 権限設計の「外側」で何が起きたかを記録し、危険な組み合わせを検知する二次レイヤー
既存のEDR / SIEM — Numbatの出力を受け取る先。Numbatは転送機能を持つが、ローテーションと保管は既存基盤に任せる

Forbesは限界として「ハーネスの統合ポイントを迂回するエージェントは捕捉できない」「monitor-only既定なので意図的な昇格が必要」を挙げており、これは公式ドキュメントの記述とも一致しています。

Open Secure AI Alliance との関係

Numbatは、NVIDIAが2026年7月27日に発表した Open Secure AI Alliance への貢献プロジェクトとして公開されています。参加企業にはMicrosoft、IBM、Dell、Red Hat、CrowdStrike、Palo Alto Networks、Cloudflare、Hugging Face、Databricks、GitHub、Linux Foundationなど30社超が名を連ねています（発足パートナー数は報道により幅があります）。一方で、OpenAI・Google・Anthropicは現時点で参加していないと複数のメディアが指摘しています。

こんな人・組織におすすめ

導入価値が高いケース

対象	理由
AIコーディングエージェントを業務端末に配っている企業	「誰の端末で、どのエージェントが、何をしたか」を記録する仕組みが他にほぼない。MDM配布とSIEM連携を前提に設計されている
情報システム部門・セキュリティ担当者	エージェント利用の棚卸し（`numbat agents --all`）だけでも価値がある。シャドーAIの発見に使える
インシデント調査を担当する立場	導入前のセッションも遡って再構成でき、ケースバンドルとして証跡をまとめられる
本番環境に近い権限でエージェントを動かしている開発者	破壊的削除・資格情報の持ち出しといった、実際に事故が起きている領域を直接カバーしている
Claude Code / Codex / Cursor / Copilot CLI の利用者	事前ブロックまで対応しているため、監視だけでなく実際の抑止まで到達できる

対象	理由
個人で試験的にエージェントを使っているだけの人	常時監視の運用コストに見合わない。まずは `numbat scan` を一度回してみる程度で十分
ログの受け皿（SIEM・ログ基盤）が存在しない組織	NDJSONが端末に溜まるだけになり、ローテーションも自前になる。運用が回らない
「入れれば自動で止まる」ことを期待している場合	既定は監視のみ。ルールのチューニングと昇格判断を行う担当者がいないと効果が出ない
プロンプトインジェクション対策を探している場合	目的が異なる。入力の無害化ではなく、行動の検知を担うツール
OpenCodeやClaude Coworkのみを使っている場合	現時点では監視のみ、または成果物解析のみで、事前ブロックに対応していない
安定した本番運用実績を重視する組織	v0.1.x の初期リリース段階。Perplexity社内での数千台展開は事実だが、外部での運用知見はまだ蓄積途上

導入判断の目安

numbat agents と numbat scan は誰でも実行してよい — エージェントの設定を変更せず、読み取りのみ。ここでリスクのある挙動が見つかるかを確認する
検知が出た／エージェントを業務配布している → hook install で監視に進む — ログの保管先を先に決めておく
監視ログでカバレッジと誤検知の傾向を掴んでから --enforce — 最初から全ルールをenforceにせず、破壊系（impact.*・exec.destructive_recursive_delete）や持ち出し系（exfil.*・chain.*_then_egress）から段階的に昇格させる

リリース履歴と更新の追い方

リリース間隔が数日単位で動いているため、導入時は必ずGitHub Releasesで最新版を確認してください。

日付	内容
2026-07-24	GitHubリポジトリ作成
2026-07-27	NVIDIA主導のOpen Secure AI Alliance発足
2026-07-29	v0.1.1 初回公開リリース＋Perplexity公式発表
2026-07-31	ITmediaが日本語で報道
2026-08-01	v0.1.2 — リダクションのURI資格情報処理修正、Codex code-modeの正規化、ケースバンドルの整合性改善、OTel正規化の重複排除、インジケータの誤検知修正、イベントモデルのドキュメント追加

ワイヤ形式のJSON Schemaはv0.2.0が使われています。対応エージェントの追加やルールの増減が続いているため、2〜4週間ごとにリリースノートとカバレッジマトリクスを確認する運用をおすすめします。

よくある質問

Q. 商用利用しても問題ありませんか。
Apache License 2.0のため、商用利用・改変・再配布のいずれも可能です。ライセンス表記と変更点の明示など、Apache-2.0の条件に従う必要があります。

Q. 検知データがPerplexityに送信されることはありますか。
公式ドキュメントでは、運用者が設定しない限り外向き通信を行わないとされています。numbat collect も既定でループバックにバインドされ、テレメトリは端末内に留まります。外部送信は --output http や numbat ship を明示的に設定した場合に限られます。

Q. すでにClaude Codeで自作のフックを使っています。上書きされませんか。
フックのインストールは冪等に設計されており、共有設定ファイルを編集する場合も他のフックやキーは保持され、元ファイルのバックアップが1つ残ります。ただし導入後は numbat hook status に加え、実際に自作フックが動いているかを一度確認しておくと安全です。

Q. Homebrewやwingetでインストールできますか。
公式ドキュメントには現時点でパッケージマネージャ配布の記載がありません。GitHub Releasesのバイナリか go install（Go 1.26.5以上）を使います。

Q. 誤検知はどの程度発生しますか。
公式に誤検知率やパフォーマンスオーバーヘッドの数値は公開されていません。だからこそ、いきなりenforceにせず監視期間を設けてから昇格させる手順が推奨されています。numbat rules test --fixture FILE でルール単位の挙動を検証できます。

Q. 日本語のドキュメントやUIはありますか。
現時点では英語のみです。ルール名・出力フィールドもすべて英語のため、SIEM側で日本語のアラート説明を付ける運用が必要になります。

Q. Numbatが動いていること自体を、エージェントに書き換えられる可能性は。
tamper.detector_state_write（$HOME/.numbat への書込）と tamper.agent_config_write（フック設定・.mcp.json の書換）という検知ルールが用意されています。ただしフックはエージェントプロセスの権限で動作するため、最終的にどこまで守れるかはOSの権限設計次第です。組織展開では管理者管理下の絶対パスに配置し、--managed スコープを使うことが推奨されています。

Q. Windowsでも同じように使えますか。
バイナリはWindows（amd64・arm64）向けにも配布されており、組織展開時の配置先として C:\Program Files\numbat\numbat.exe が公式手順に示されています。ただしフックが実際に呼ばれるかは各エージェントのWindows対応状況に依存するため、導入後のヘルスチェックは必須です。

まとめ

Numbatは、AIコーディングエージェントの端末上の行動を記録・検知するための、Apache-2.0のオープンソースツールです。3つの取り込み経路（フック／セッション成果物／テレメトリ）を同じルールで評価し、11カテゴリのルールと6つの連鎖ルールで、機密の持ち出しや破壊的操作、承認バイパスといった挙動を捉えます。

導入判断のポイントを3点に絞ると次の通りです。

まず numbat agents と numbat scan を実行する。 エージェントの設定を変更せず、過去のセッションを読むだけで現状が把握できる
既定ではブロックしない。 ブロックさせるにはルールを複製し enforce: true を付けて再インストールする必要があり、エラー時はフェイルオープンする
ログの受け皿を先に決める。 $HOME/.numbat/findings.ndjson は機密を含みうるログで、ローテーションはNumbat側では行われない

「エージェントに端末を触らせているが、実際に何をしているか把握できていない」という状態にある組織にとって、コストゼロで現状把握を始められる点は大きな価値があります。一方で、v0.1.x の初期段階であり、Numbat単体で守りが完結するツールではありません。エージェント側の権限設計とサンドボックス化を一次防御として固めたうえで、その外側の可視化レイヤーとして組み合わせるのが現実的な使い方です。リリース間隔が短いため、導入前にはGitHub Releasesで最新の仕様を確認してください。