PentestAgent を導入前に読む: TUI と MCP 自己増殖で組み立てるペネトレーションテスト用エージェント

誰のためのツールか: 黒箱テストの手作業を LLM に委ねる前提

PentestAgent が解こうとしているのは、偵察からタスク分解までの手作業を LLM エージェントに代行させることだ。README は用途を bug bounty、レッドチーム、ペネトレーションテストと明記している。想定読者は、すでに対象ホストへ nmap や sqlmap を打ち込む環境を持ち、その上に自然言語の指示レイヤーを載せたい実務者である。

前提条件は Python 3.10 以上と、OpenAI、Anthropic、その他 LiteLLM 対応プロバイダの API キーだ。つまりネットワーク越しに外部 LLM へプロンプトを送れることが事実上の必須要件になる。オフライン完結を求める案件では、この時点で選択肢から外れる。ホームページは登録されておらず、README 以外の公式ドキュメントは確認できない。仕様の根拠はリポジトリの README と設定例に限られる点を先に押さえておきたい。

4つのモードが分ける「一度きり」と「自律」と「分業」

TUI から呼べるモードは4つある。`/assist <task>` はツール実行を伴う単発指示、`/agent <task>` は単一タスクの自律実行、`/crew <task>` はオーケストレータが専門ワーカーを spawn するマルチエージェント、`/interact <task>` は対話しながら手順を進めるガイド付きモードだ。

この分け方は実行時間と人間の関与の度合いに対応している。`/assist` は1回の指示で終わる確認作業、`/agent` は対象を渡して任せる調査、`/crew` は複数の視点が必要な広い範囲、`/interact` は判断を挟みながら進めたい場面に向く。README の表では4モードすべてが同じ列に並んでいるが、`/crew` だけは他の3つと構造が異なる。オーケストレータという別の役割のエージェントが介在するためだ。

モード選択はコストにも直結する。`/agent` や `/crew` はツール呼び出しの回数が増え、そのぶん LLM へのトークン消費も増える。TUI には `/memory` があり、トークンとメモリの使用量を確認できる。長時間の自律実行では、このコマンドを挟まないと消費の把握が難しい。

spawn_mcp_agent: エージェントが自分自身の子を産む仕組み

このプロジェクトで最も特徴的なのが `spawn_mcp_agent` だ。組み込みツールの一つで、実行中のエージェントが stdio 経由の MCP サーバとして自分の子コピーを起動する。README によれば、子プロセスはランタイム、LLM クライアント、会話履歴、ノートストアをそれぞれ独立して持ち、 spawn 後に子のツール一式が親の利用可能ツールへ注入される。

引数は `target`、`scope`、`model`、`no_rag`、`no_mcp` の5つ。`scope` は子に渡す対象や CIDR の配列で、`model` は子側の `PENTESTAGENT_MODEL` を上書きする。`no_mcp` の既定値は `true` で、README はこれを推奨としている。子がさらに外部 MCP サーバへ接続すると、プロセスの連鎖と接続先が読みにくくなるためだろう。

注意すべきはタイミングだ。README には、子のツール（`run_task`、`run_task_async`、`await_tasks` など）が使えるようになるのは次のツール呼び出しからだと書かれている。1ターン目で spawn し、2ターン目で委譲する、という順序を守る必要がある。子のサーバ名は `child_agent_1` のように自動で割り当てられ、結果として返る。TUI 側には `/spawn [target] [--scope CIDR] [--model M] [--no-rag] [--no-mcp]` と `/despawn <server_name>` があり、手動での起動と停止もできる。

外部のオーケストレーションフレームワークを挟まずに階層的な分業が組める点は利点だが、そのぶん子プロセスの状態を外から追いにくい。`/despawn` を忘れた子が残り続ける可能性は、設計上避けられない。

インストールと設定: setup スクリプト、.env、Playwright

導入手順は README に具体的に書かれている。リポジトリを clone したあと、Windows なら `.\scripts\setup.ps1`、Linux/macOS なら `./scripts/setup.sh` を実行する。手動の場合は `python -m venv venv` で仮想環境を作り、有効化したうえで `pip install -e ".[all]"` を実行する。ブラウザツールを使うなら `playwright install chromium` が別途必要だ。

設定はプロジェクトルートの `.env` に置く。Anthropic なら `ANTHROPIC_API_KEY` と `PENTESTAGENT_MODEL=claude-sonnet-4-20250514`、OpenAI なら `OPENAI_API_KEY` と `PENTESTAGENT_MODEL=gpt-5` という例が示されている。LiteLLM 対応モデルならどれでも動くと README は述べている。

中継サーバを使う場合は `OPENAI_API_BASE` で OpenAI 互換エンドポイントを指定し、モデル名は `openai/<model-name-on-your-relay>` の形式にする。Anthropic 互換なら `ANTHROPIC_API_BASE` を使う。プロバイダごとの注意書きと埋め込みのオプションは `.env.example` にまとまっているとされている。

起動は `pentestagent` で TUI、`pentestagent -t 192.168.1.1` で対象を指定、`pentestagent tui --docker` でツールを Docker コンテナ内で実行する。プレイブックを使う場合は `pentestagent run -t example.com --playbook thp3_web` という形式だ。

Docker 運用: ベースイメージと Kali イメージの使い分け

ツール実行の隔離は Docker が担う。README は2通りの入手方法を示す。事前ビルド済みイメージを引く方法では、`ghcr.io/gh05tcrew/pentestagent:latest` が nmap、netcat、curl を含むベース、`ghcr.io/gh05tcrew/pentestagent:kali` が metasploit、sqlmap、hydra などを含む Kali 版だ。どちらも `-e ANTHROPIC_API_KEY=...` のように環境変数を渡して `docker run -it --rm` で起動する。

自前でビルドする場合は `docker compose build`、Kali 版は `docker compose --profile kali build` を使い、実行は `docker compose run --rm pentestagent` または `docker compose --profile kali run --rm pentestagent-kali` となる。コンテナ内ではエージェントが terminal ツール経由で `nmap` や `msfconsole`、`sqlmap` を直接叩ける。

ここで実務上の判断が生じる。Kali イメージは強力なツール群を同梱するが、イメージサイズとビルド時間はベースより大きくなる。また Docker がインストールされ動作していることが前提だ。コンテナを使わずホスト上で直接ツールを呼ぶ構成も選べるが、その場合はホスト側にツールを揃える責任が利用者に移る。

MCP と組み込みツール、そして外部検索の API キー

組み込みツールは `terminal`、`browser`、`notes`、`web_search`、`spawn_mcp_agent` の5つ。`web_search` は `TAVILY_API_KEY` を要求する。つまり検索を使うなら LLM プロバイダとは別に Tavily のキー管理が増える。

拡張は MCP（Model Context Protocol）経由で行う。TUI の `/mcp <list/add>` でサーバの一覧表示と追加ができ、`/tools` で利用可能なツールを確認できる。MCP 対応をうたっているが、README からは具体的にどの MCP サーバが動作確認済みなのかは読み取れない。接続先の互換性は自分で確かめるしかない。

セッション中に得た情報は `notes` に蓄積され、`/notes` で表示、`/report` でセッションレポートを生成する。`/conversations` で保存済み会話を一覧・復元できる。調査の記録が会話ログとノートの2箇所に分かれるため、レポート生成時にどちらを根拠にするかを意識しておきたい。

向かない場面と、代替となるアプローチ

このツールが適さない場面は明確だ。第一に、LLM へプロンプトを送れない環境。API キーが必須で、LiteLLM 経由のプロバイダ接続が前提になるため、完全なエアギャップ下では動かない。第二に、子エージェントの増殖を厳密に統制する必要がある案件。`spawn_mcp_agent` は親が子を産み、子がさらに spawn しうる構造で、`/despawn` を漏らせばプロセスが残る。スコープ外への到達を防ぐ仕組みは README からは読み取れず、`scope` 引数がどの程度強制されるのかも不明だ。第三に、再現性が重視される監査。LLM の出力は確率的で、同じコマンドを打っても同じ手順になる保証はない。

代替として挙げられるのは、エージェントを挟まず nmap や sqlmap などのツールをスクリプトで直接呼び出す従来型の自動化だ。違いは探索の進め方にある。スクリプトは事前に決めた手順を順に実行するだけで、結果を見て次の一手を変えることはない。PentestAgent は LLM がツール出力を読んで次のタスクを決める。未知の応答に対する適応力と引き換えに、手順の再現性と実行時間の予測しやすさを失う。どちらが優れているかではなく、対象の性質で選ぶ問題だ。

ライセンスと保守コストの見積もり

ライセンスは MIT。商用利用を含めて比較的自由に扱える条件で、コピーレフトのような派生物への伝播は課されない。ただし MIT は無保証であり、脆弱性診断という性質上、ツールの挙動が対象に与える影響の責任は利用者側にある。ライセンス条文の解釈はここで断定的に述べる範囲を超えるため、配布や組み込みを検討する場合は原条項を確認してほしい。

保守コストで見ておくべき点は3つある。第一に、LLM プロバイダのモデル名は陳腐化する。README の例にある `claude-sonnet-4-20250514` や `gpt-5` は固定文字列で、モデル廃止時には `PENTESTAGENT_MODEL` の書き換えが要る。第二に、依存の広さ。`pip install -e ".[all]"` は全オプションを入れる指定で、Playwright の chromium バイナリも別途落とす。第三に、リリース状況。取得できた範囲では最近のリリース情報がなく、バージョンは README のバッジで 0.2.0 と示されている。0.x 系である以上、更新時の破壊的変更を想定した運用が必要だ。

編集部の結論

採用を検討すべきなのは、すでに Docker と nmap や sqlmap などのツール群を運用しており、TUI から LLM に偵察やタスク分解を任せたいチームだ。逆に、エアギャップ環境や API キーを外部に出せない案件、スキャン対象が厳格なスコープ管理下にあり子エージェントの増殖を追跡できない現場には向かない。導入前に確認するのは、`PENTESTAGENT_MODEL` に指定するモデルが LiteLLM 経由で利用可能か、`docker compose build` で Kali プロファイルがビルドできるか、そして `spawn_mcp_agent` が生成する `child_agent_1` のような子プロセスのログがどこに残るか、の3点だ。

公式情報源

1. GH05TCREW/pentestagent on GitHub
2. Issues
3. License: MIT
4. README