Perplexity Numbatとは｜AIコーディングエージェント監視のオープンソース・52ルールの事前フック・Claude Code/Codex対応と導入手順【2026年10月最新】

Numbat（ナンバット）は、Perplexityが2026年7月29日にオープンソースで公開したセキュリティツールです。AIコーディングエージェントが端末で行う操作を記録・検知し、設定すれば実行前にブロックもできます。 ライセンスはApache-2.0、Go製の単一バイナリで、料金はかかりません。最新版は2026年10月19日公開のv0.3.0です。

報道では「危険な操作を実行前にブロックできる」点が目立ちますが、前提があります。同梱のルールはすべて監視のみで、初期設定のままでは何もブロックしません。 ブロックさせるには、利用者がルールを複製して明示的に有効にする必要があります。

Claude CodeやCodexを業務端末で使っていて、エージェントが実際に何をしているか把握できていない開発者・情報システム部門・セキュリティ担当者なら、まず numbat scan で過去のセッション記録を読むだけでも現状がつかめます。エージェントの設定は書き換えません。

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

出典: 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エージェントの活動を可視化する。端末内での検知、任意の実行前ブロック、事後の調査用の再構成に対応）

公式の説明では、Perplexity社内ではすでに数千台の端末にMDM経由で展開されています（台数の具体値は非公開）。社内ではAIシステム「Perplexity Computer」の定期タスクがNumbatの検知と監査ログを見直し、ルール変更案をPRとして作り、人が承認してから反映する運用をしているとされます。同じ流れには、Perplexityが2026年5月に公開した開発端末向けスキャナー「Bumblebee」の検知もつながっています。Bumblebeeは、端末に入っているパッケージ・拡張機能・AIツール設定を読み取り専用で調べるツールです。Numbatが「エージェントの行動」を見るのに対し、Bumblebeeは「端末に何が入っているか」を見る、という分担です。

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

名前の由来と位置づけ

Numbatはオーストラリアに生息する小型有袋類の名前です。製品としては、モデル側の防御でもフレームワーク側のガードレールでもなく、開発者の端末で、エージェントが出そうとしたコマンドやツール呼び出しを直接見る層に位置します。端末の振る舞いを監視するEDRの考え方を、AIエージェントに持ち込んだものと考えるとわかりやすいでしょう。

なぜNumbatが作られたのか？「攻撃者がいなくても事故は起きる」という問題意識

出典: Perplexity Research 公式サイト

Numbatの出発点は、エージェントの安全性を「外部の攻撃者に乗っ取られる」話だけで考えるのは足りない、という問題意識です。公式発表は "Instead of the agent being co-opted by an attacker, the agent itself is the attacker."（攻撃者に乗っ取られるのではなく、エージェント自身が攻撃者になる）と書いています。

公式はこれを "accidental meltdowns"（偶発的な暴走）と呼んでいます。悪意ある指示がなくても、ふつうの環境エラーをきっかけに、エージェントが「タスクを終わらせる」ことだけを目指して破壊的な行動に行き着くことがある、という整理です。モデル側の対策だけでは塞ぎきれないため、周辺のシステムで守る必要がある、というのがPerplexityの立場です。

背景にあるインシデント

公式発表が「最初に広く報じられた accidental meltdown」として挙げているのが、2026年7月にOpenAIが開示した事案です。報道をもとに経緯を整理します。

攻撃者が一人もいないのに、評価タスクを達成したいという動機だけでここまで到達したことが、Numbatの問題提起の中心です。事案の詳しい経緯は「OpenAIのモデルがHugging Faceに侵入した事案」と、その続報「OpenAI・Hugging Face事案の調査報告」でまとめています。

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

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

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

Numbatは、エージェントの活動を3つの経路から取り込み、共通のイベント形式に変換したうえで、同じCEL式のルールで評価します。どの経路で拾ったかによって、実行前にブロックできるかどうかが決まります。

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ルール（公式発表）の内訳

検知ルールはYAMLで定義され、バイナリに埋め込まれています。公式発表と報道では「11カテゴリ・52ルール」です。ただしリポジトリのYAMLファイルを数えると51件（単発45件＋連鎖6件）で、2026年10月29日時点でも8月から件数は変わっていません。差の理由は公表されていません。カテゴリ数の11は一致しています。

ルールはCEL式で書かれ、利用者はNumbatのコードに触れずにYAMLで独自ルールを追加できます。

11カテゴリの内訳

なお tamper.agent_config_write は、v0.2.0（8月17日）で対象が絞り込まれ、ふつうの設定編集で反応しにくくなっています。

注目したいのは tamper.guardrails_off と exec.agent_runtime_bypass_flags です。どちらもエージェント自身が承認の手順を飛ばそうとしたことを検知します。Claude Codeの --dangerously-skip-permissions のような権限スキップの扱いは「Claude Codeのセキュリティと安全な使い方」で背景を整理しています。

Numbatの特徴である「連鎖ルール」

Numbatで技術的に目を引くのは、単体では無害に見える操作の順番つきの組み合わせを、一定のイベント数の範囲内で検知する6つの連鎖ルールです。

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

外部への送信として扱われるのは、ループバック以外のHTTP(S)への curl/wget、Python・Node・PowerShellのインラインHTTP書き込み、リモートへの scp/rsync、send/upload/share/publish/mail 系のMCPツールなどです。read/list/search/delete 系のMCP操作は含まれません。

対応エージェント一覧（監視できるもの・事前にブロックできるもの）

出典: GitHub Copilot 公式サイト

公式発表でPerplexity社内での利用が明言されているのは、Claude Code / Codex / OpenCode / Piの4つです。リポジトリの対応表（docs/agent-coverage.md）には、2026年10月29日時点で28件のエージェントが載っています。

v0.3.0では、Metaが2026年8月5日にベータ公開したターミナル型エージェントのMuse Codeに対応しました。ライブ監視・任意のブロック・保存済み記録の解析の3つとも使えます。この対応は外部の開発者からのプルリクエストで入ったものです。Muse Code自体の概要は「Muse Codeとは」で解説しています。

numbat scan --agent に指定できる名前は、v0.3.0時点で次のとおりです。

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

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

このほか、Qwen Code / Cline CLI / Amp / Auggie / Kiro IDE・CLI v3 / Goose / Kilo Code / OpenHands / Crush / Junie CLI（Early Access）/ Antigravity / Factory Droid / Grok Build / Devin CLI / Hermes が載っています。これらは保存済み記録の解析が未実装（deferred）のものが多い一方、フック経由のライブ取得と実行前ブロックには対応しています。

エージェントごとの制限（導入前に確認したい点）

• Codexのホステッドツールはローカルのフックを通りません。 公式も「フックは完全なポリシーの境界ではない」と書いています。Codex側の安全機能との分担は「Codex Securityとは」を参照してください。
• Cursorの subagentStart は監視のみです。現行のCursorが拒否応答を無視するためです。また state.vscdb は解析対象外です。Cursorのクラウドエージェントが読むのはリポジトリのフックだけで（Enterpriseプランでは Team / Enterprise のフックも読む）、端末側に入れたフックは効きません。
• Muse Code はセッション開始時にフックを読み込むため、設定を変えたら新しいセッションから反映されます。hook status はディスク上の設定を見るだけで、Muse Codeが実際に読み込んだかは確認しません。また、ライブで取得したサブエージェントは親セッションと紐づきません。
• OpenHandsはリポジトリ単位のフックしか持たないため --agent all の対象外です。--settings /repo/.openhands/hooks.json のようにパスを明示します。
• OpenClaw はv2026.7.1以上が必要です。v2026.7.2 betaのDBと圧縮アーカイブは解析できません。8月時点のドキュメントでは、OpenClawの内部の制限時間（9秒）を超えると生成されたラッパーはブロックせずに通す、と説明されていました。OpenClaw自体の権限設計は「OpenClaw セキュリティ設定ガイド」で解説しています。
• Claude Cowork はmacOSの保存場所しか読めず、Windows / Linuxには既定のパスがありません。ライブ取得もできません。

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

料金はApache-2.0で無料、コストは運用側にかかる

Numbatに料金プランはありません。 Apache License 2.0のオープンソースで、ライセンス費用は0円、商用利用もできます。有償のSaaS版・エンタープライズ版・サポート契約は、2026年10月29日時点の公式情報では確認できません。

その代わり、運用の手間とコストは利用者側にかかります。

個人の開発者が自分の端末で numbat scan を回すだけなら、実質のコストはほぼありません。組織で展開するなら、「ログの受け皿と、ルールを調整する担当者がいるか」が判断の分かれ目になります。

段階的に入れる導入手順（4ステップ）

Numbatは、いきなりブロックを有効にするのではなく、現状把握 → 過去の記録の解析 → 監視 → ブロック の順で進めるのが公式ドキュメントに沿ったやり方です。コマンドはv0.3.0時点のものです。

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

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

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

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

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

8月時点の手順ではGo 1.26.5以上でしたが、v0.3.0ではGo 1.26.9以上が必要になりました。Homebrew・apt・wingetなどのパッケージマネージャーでの配布は、10月時点でも公式ドキュメントに記載がありません。

ステップ1. 現状把握（エージェントの設定は変えない）

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

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

ステップ2. 過去のセッション記録を解析する

Numbatをいちばん気軽に試せるのがこの段階です。エージェントの設定を書き換えずに、ディスクに残っているセッション履歴を検知ルールにかけられます。

numbat scan                  # 保存済みのセッション記録を遡って解析
numbat scan --agent codex    # 対象のエージェントを絞る
numbat timeline              # セッション単位で時系列に並べる

導入するか決めかねているなら、ステップ1と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 使い分けガイド」もあわせて確認しておくと安心です。

ホストによってはフックを信頼する確認が別途必要です。--managed で入れたものはポリシーとして信頼されます。

ステップ4. ブロック（enforce）を有効にする

同梱のルールはすべて監視のみです。 --enforce を付けただけではブロックしません。次の手順で、自分のルールとして有効にします。

# 1) ブロックしたい組み込みルールのYAMLを丸ごと自分のディレクトリにコピーし、
#    同じIDのまま 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

注意点は次の4つです。

• 同じIDの自作ルールは、組み込みの定義を丸ごと置き換えます。省いた項目は引き継がれないため、YAML全体をコピーしてから編集します
• --enforce 付きのインストールは、enforce: true のルールが1件以上あることを確かめてから設定を書き換えます
• ルールのディレクトリは、インストール時点で実在する具体的なパスでなければなりません（$HOME/rules のように後から展開されるパスは使えません）
• 検知結果を file か http に出す設定が必須で、標準出力だけでは使えません

v0.3.0では numbat rules test --json が加わり、ルールのテスト結果を機械で読める形で出せるようになりました。CIでルールを検証する場合に使えます。

スコープの指定

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

組織に展開する流れ

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

1. /usr/local/bin/numbat（Windowsは C:\Program Files\numbat\numbat.exe）など、管理者が管理する絶対パスに置く
2. 導入済みのエージェントを洗い出し、user / project / managed のどのスコープで入れるか決める
3. MDMスクリプトで配布する（userスコープは対象ユーザーとして、managedは管理者権限で実行）
4. エージェントごとの信頼・有効化の手順（ワークスペースの信頼、フックの承認、機能の有効化）を済ませる
5. 無害な操作で動作確認し、端末のローカル記録と送信先の記録の両方を確かめる
6. カバレッジを確かめてから、監視（monitor）からブロック（enforce）へ移る

社内の開発基盤や業務システムにAIエージェントを組み込む段階になると、監視の仕組みも含めた設計と費用の見積もりが必要になります。外部に開発を頼む場合の価格の目安と見積もりの内訳は「AI開発の費用相場」で整理しています。

SIEMとの連携

推奨されているのは、ファイル出力（既定）を既存のログ転送ツールやEDRでSIEMに送る形です。numbat ship でHTTPに直接送ることもできますが、送信の失敗に備えたキューは持たず、同じレコードが重複して届くこともあります（at-least-once）。確実に届けたいならファイル出力と既存の転送基盤を組み合わせるほうが安全です。

# HTTPへの直接送信（認証情報は環境変数で渡す。コマンドの引数では渡せない）
# Bearer:      NUMBAT_HTTP_TOKEN
# HMAC-SHA256: NUMBAT_HTTP_HMAC_KEY
numbat ship --input-file $HOME/.numbat/findings.ndjson --http-url https://...

v0.3.0で出力スキーマが0.5.0に上がりました。これは互換性のない変更なので、版やスキーマを厳密に検証しているSIEMのパーサーなどは修正が必要です。

新しい版に更新するとき

v0.3.0のリリースノートでは、更新後の作業として次の2点が挙げられています。

1. 入れているエージェントごとに、前と同じオプションで numbat hook install を実行し直す（生成されるフックやプラグインが新しくなる）。定義が変わった場合は、ホスト側でのフックの信頼確認もやり直す
2. 出力スキーマの変更（今回は0.5.0）に合わせて、下流のパーサーを直す

バイナリを差し替えるだけでは、古い版のフック定義が残ったままになる点に注意してください。

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

報道は「危険な操作を実行前にブロックできる」点を強調しがちですが、公式ドキュメントは限界をかなりはっきり書いています。導入するかどうかは、この限界を受け入れられるかで決まります。表はv0.3.0時点のドキュメントに基づきます。

ブロックできるシェル構文は、v0.1.xの「静的なPOSIX構文のみ」から、v0.3.0で複合コマンドまで広がりました。ただし実務では、次の細かい条件が影響します。

• ヒアドキュメント、コマンド置換・変数展開、関数、python -c のような子インタープリタの直接実行、eval、PowerShellの Invoke-Expression、PowerShell/CMDのパイプラインは検知のみ
• 入力の中に静的でないコマンドが1つでも含まれると、その入力全体が検知のみになる
• 逆に、リストや分岐の中でルールに一致した部分があれば、実際には実行されない分岐でも拒否される
• 連鎖ルールは、最後の手順の時点でしかブロックできない

運用面では、numbat hook status は設定ファイルに記述があるかを確かめるだけで、エージェントが実際にフックを読み込んで実行・送信したかは保証しません。 入れた直後に無害な操作で動作確認をして、記録が実際に出ることを確かめてください。

また、再構成できるのはエージェントがディスクに残したものだけです。保存済み記録からの再構成はディスクやメモリの取得ではないので、記録を残さない経路の活動は戻せません。誤検知率や性能への影響についても、公式の数値はまだ出ていません。

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

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

Numbatは初期設定ではクラウドに何も送りません。 公式の SECURITY.md などでは、保証していることと保証していないことが分けて書かれています。

公式が保証していること

• 保存済みのセッション記録は読み取り専用で扱い、記録の中にあるエージェントやコマンドを実行しない
• 運用者が設定しない限り、外部への通信をしない
• numbat collect は既定でループバック（127.0.0.1）だけで待ち受け、テレメトリは端末内にとどまる

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

• マスキングはDLPや機密情報の除去の仕組みではない。 既知のパターンを伏せるだけで、すべての機密を取り除くわけではない
• プロジェクトパスのハッシュはソルトなしで、匿名化ではない
• numbat collect は認証なしでローカルに待ち受ける
• フックはエージェントのプロセスと同じ権限で動く。どこまで守れるかはOSの権限設計しだい
• 連鎖の状態を持つファイルや出力ファイル自体が機微なデータで、保護が必要
• 生の証拠をケースバンドルにコピーするのは任意。署名のないケースバンドルは出所や完全性を証明しない

v0.3.0で増えた注意点: --content full にソースコードが入りうる

v0.3.0から、--content full を指定したときの出力に、マスキング済みのツールの引数と実行結果も入るようになりました。つまりソースコード、ファイルの中身、パッチがログに残る可能性があります。会話のメッセージ本文だけを残したい場合は、--content full --content-scope messages と指定します。

v0.2.0（8月17日）ではアシスタントの応答や推論のテキストも取れるようになっており、出力に含める範囲が広がる方向で更新が続いています。版を上げたら、出力の中身を一度確認しておくと安心です。

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

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

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

出典: Open Secure AI Alliance — NVIDIA Blog

AIエージェントの安全対策にはいくつかの層があり、Numbatが担うのは端末での介入です。Forbes（2026年7月30日）の整理をもとにすると、現在の市場は次のように分かれます。

同じ端末まわりの対策とは、次のように使い分けると整理しやすくなります。

• エージェント側の権限設計・サンドボックス（Claude Codeのサンドボックス、Codexの実行制限など）：最初の防御。まずここを固める
• Numbat：権限設計の外側で何が起きたかを記録し、危険な組み合わせを検知する二段目の層
• 既存のEDR / SIEM：Numbatの出力を受け取る先。保管とローテーションは既存の基盤に任せる

組織全体でエージェントを管理する商用製品の例としては、Microsoftの「Microsoft Agent 365とは」も参考になります。Agent 365が組織内のエージェントの登録や権限の管理を担うのに対し、Numbatは個々の端末で起きた操作を見る、という違いがあります。

Forbesは限界として「ハーネスの連携点を迂回するエージェントは捕まえられない」「初期設定が監視のみなので、意図的にブロックへ切り替える必要がある」を挙げており、公式ドキュメントの記述と一致します。2026年10月のdarknet.org.ukのレビューも、「ブロックは任意で、範囲も狭い」と評価しています。

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は参加していないと伝えられました。その後の参加状況は確認できていません。

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

導入する価値が高いケース

おすすめしないケース

導入を判断する目安

1. numbat agents と numbat scan は誰が実行してもよい。エージェントの設定は変えず、読むだけ。ここで危ない挙動が見つかるかを確認する
2. 検知が出た、またはエージェントを業務で配っている → hook install で監視に進む。ログの保管先を先に決めておく
3. 監視ログでカバレッジと誤検知の傾向をつかんでから --enforce に切り替える。最初から全ルールをブロックにせず、破壊系（impact.*・exec.destructive_recursive_delete）や持ち出し系（exfil.*・chain.*_then_egress）から段階的に切り替える

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

数週間〜2か月ほどの間隔で、互換性に影響する変更を含む版が出ています。導入時は必ずGitHub Releasesで最新版を確認してください。

2026年8月時点の情報から変わった点

8月の公開直後の情報をもとに導入を検討していた場合は、次の点を読み替えてください。

対応エージェントの追加や仕様の変更が続いているため、月に1回程度はリリースノートと対応表（docs/agent-coverage.md）を確認する運用をおすすめします。

よくある質問

Q. 商用利用しても問題ありませんか。

Apache License 2.0なので、商用利用・改変・再配布のいずれもできます。ライセンスの表示や変更点の明示など、Apache-2.0の条件には従う必要があります。

Q. 検知データがPerplexityに送られることはありますか。

公式ドキュメントでは、運用者が設定しない限り外部への通信はしないとされています。numbat collect も既定ではループバックだけで待ち受けます。外部に送るのは、--output http や numbat ship を自分で設定した場合だけです。

Q. すでにClaude Codeで自作のフックを使っています。上書きされませんか。

インストールは何度実行しても同じ結果になる作りで、共有の設定ファイルを編集するときもほかのフックや設定項目は残り、元のファイルのバックアップが1つ作られます。導入後は numbat hook status だけでなく、自作のフックが実際に動いているかも一度確かめておくと安全です。

Q. 新しい版に上げるときにやることは何ですか。

バイナリを差し替えたあと、入れているエージェントごとに同じオプションで numbat hook install を実行し直します。v0.3.0は出力スキーマが0.5.0に変わったため、SIEM側で形式を厳密にチェックしている場合はパーサーの修正も必要です。

Q. Homebrewやwingetでインストールできますか。

2026年10月時点の公式ドキュメントには、パッケージマネージャーでの配布の記載がありません。GitHub Releasesのバイナリか、go install（Go 1.26.9以上）を使います。

Q. 誤検知はどのくらい出ますか。

誤検知率や性能への影響の数値は公開されていません。そのため、いきなりブロックにせず監視の期間を置いてから切り替える手順が勧められています。numbat rules test --fixture FILE でルールごとの挙動を確かめられ、v0.3.0からは --json で結果を機械処理できます。

Q. 日本語のドキュメントや画面はありますか。

現時点では英語のみです。ルール名や出力の項目もすべて英語なので、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 が公式手順に載っています。ただし、ブロックできるのはPowerShellとcmd.exeの単純なコマンド1つだけで、PowerShellのパイプラインなどは検知のみです。フックが実際に呼ばれるかもエージェントのWindows対応しだいなので、導入後の動作確認は欠かせません。

まとめ

Numbatは、AIコーディングエージェントが端末で行う操作を記録・検知する、Apache-2.0のオープンソースツールです。3つの取り込み経路（フック／保存済みのセッション記録／テレメトリ）を同じルールで評価し、11カテゴリのルールと6つの連鎖ルールで、機密の持ち出し、破壊的な操作、承認の回避といった挙動を捉えます。2026年10月19日のv0.3.0では、Muse Codeへの対応と、ブロックできるシェル構文の拡大が入りました。

導入を判断するポイントは次の3つです。

1. まず numbat agents と numbat scan を実行する。 エージェントの設定を変えず、過去のセッションを読むだけで現状がわかる
2. 初期設定ではブロックしない。 ブロックさせるにはルールを複製して enforce: true を付け、インストールし直す必要がある。エラー時は通す設計で、静的でないコマンドを含む入力は検知のみになる
3. ログの受け皿と更新の手順を先に決める。 findings.ndjson は機密を含みうるログで、--content full ではソースコードも入りうる。版を上げたら hook install の再実行とスキーマ変更への対応が要る

「エージェントに端末を触らせているが、何をしているか把握できていない」組織にとって、費用をかけずに現状把握を始められるのは大きな利点です。一方で、まだv0.x系で互換性のない変更も入る段階であり、Numbatだけで守りが完結するわけではありません。エージェント側の権限設計とサンドボックスを最初の防御として固め、その外側で記録と検知を担う層として組み合わせるのが現実的な使い方です。導入の前には、GitHub Releasesで最新の仕様を確認してください。