PentAGIは、VXControlがMITライセンスで公開している自律型のペネトレーションテスト実行システムです。VXControlは、本体をオープンソースで公開しつつ有償のVXControl Cloudを併営する開発チームです。役割の異なる複数のAIエージェントが連携し、隔離されたDockerコンテナの中で情報収集から検証までを進めます。ただし公開情報は英語のREADMEとリリースノートに分散しており、どの版で何が動くのか、導入に何を用意すべきかが読み取りにくい状態です。
この記事では、GitHubリポジトリ github.com/vxcontrol/pentagi の一次情報をもとに、2026年9月時点のPentAGIを整理します。
まとめ
- 最新リリースはv2.1.0(2026年5月29日・UTC基準)で、2025年末のv1.0.0が公式に「Production Release」と位置づけられています。README上に「早期アルファ」の表記はもう残っていません。
- 導入経路は対話式インストーラーと docker compose の手動構築の2つ。要件は2 vCPU・4GB RAM・20GB空き容量と軽く、既定では127.0.0.1の8443番だけを開きます。
- LLMは10種類以上のプロバイダーに対応し、OpenRouterなどのアグリゲーターは LLM_SERVER_ 系の環境変数に集約できます。Ollamaでのローカル実行では num_ctx を110000にしたモデルを自分で作る必要があります。
- 最大の注意点はエージェントへのDockerの渡し方です。DOCKER_SOCKET でホストのソケットをバインドマウントすると、自律エージェントにホスト全体を掌握する権限を渡すことになります。
- コード本体はMITですが、VXControl Cloud Servicesの利用には別途ライセンスキーが必要です。無償で完結する範囲と有償の範囲は分かれています。
以下、現在地とリリース経緯、内部構成、Dockerでの導入手順、LLMと埋め込みの設定、そして最も事故が起きやすいDocker権限の渡し方の順に見ていきます。
PentAGIの現在地とv2.1で使える範囲
PentAGIは2025年1月に最初のアルファ版が公開されたプロジェクトで、2026年9月7日時点でGitHubのStarは22,477、Forkは2,974に達しています。mainブランチの最新コミットは2026年8月6日で、開発は継続しています。実装はバックエンドがGo、フロントエンドがReactで、REST APIとGraphQL APIの双方をBearerトークン認証付きで提供します。
アルファ版からv2.1.0までのリリース経緯
| 版 | 公開日(UTC) | 主な内容 |
|---|---|---|
| v0.1.0 | 2025-01-07 | 最初の公開アルファ |
| v0.3.0 | 2025-06-25 | 最初の公開ベータ |
| v1.0.0 | 2025-12-31 | Production Release/インストーラー追加 |
| v1.1.0 | 2026-01-17 | LiteLLM経由の接続/Windowsパス対応 |
| v1.2.0 | 2026-02-25 | 利用状況分析のREST API |
| v2.0.0 | 2026-04-11 | プロバイダー4種/実行中の切替/監視Beta |
| v2.1.0 | 2026-05-29 | ファイル管理/ナレッジベース/ツール可視化 |
v2.0.0ではDeepSeek・GLM・Kimi・Qwenが正式サポートに加わり、実行中のフローを止めずにLLMプロバイダーを切り替える運用ができるようになりました。v2.1.0では利用者が持ち込んだファイルをワーカーコンテナへ同期する仕組みと、エージェントが実行した個々のツール呼び出しをリアルタイムに追える機能が入っています。「早期アルファなので本番では使えない」という前提で見送っていた組織は、判断の土台が変わっている点を押さえておく必要があります。
第三者検証で指摘された導入の重さと、その後に追加された公式ガイド
Ostorlabは2026年1月30日に、オープンソースのAIペンテストツール8種を脆弱なバンキングアプリ vulnbank.org に対して試した結果を公開しています。この検証でPentAGIは「セットアップが長く複雑で、ドキュメントが限られており手順が不明瞭なため、vulnbank.orgに対してツールを走らせることが難しかった」と評価され、実際の診断結果を出せた組にはStrixとCAIが挙げられました。つまり検出能力ではなく、動かすところまでの難易度が壁になったという指摘です。
この検証はv1.1.0前後の時期にあたります。その後、導入から設定・プロバイダー検証・初回ログインまでを通しで解説する installation_configuration.md というガイドが2026年6月4日にリポジトリへ追加され、READMEの各節は各ステップの詳細リファレンスとして残る形になりました。導入の重さ自体は、後述するとおり監視スタックやナレッジグラフを別のcomposeファイルで足していく構造に起因するもので、必要な範囲だけ立ち上げれば回避できます。
BAS製品ではないという公式の線引き
READMEには能力の境界を明示した節があり、PentAGIはCALDERA型のBAS(侵害・攻撃シミュレーション)製品ではなく、事前定義のキャンペーンや攻撃プランを持つものでもないと書かれています。エージェントが攻撃スクリプトを自ら書き起こす類の話は将来構想として扱うよう明記されており、フローのレポート出力もWeb表示・クリップボードへのコピー・Markdown・PDFに限られ、JSON形式のエクスポートは公式にサポートされていません。既存のBASツールの置き換えとして検討している場合は、この線引きを先に確認しておくのが安全です。
マルチエージェント構成と暴走を止める仕組み
PentAGIはオーケストレーターが全体を統括し、サブタスクごとに researcher(調査)・developer(検証コードの作成)・executor(実行)のいずれかの役割を割り当てて処理を進めます。実行結果はPostgreSQLとpgvector拡張に蓄積され、次回以降のタスクでベクトル検索によって再利用されます。Neo4jとGraphitiを使ったナレッジグラフは任意機能で、有効にするとエージェントの応答とツール実行がフロー単位のナレッジとして自動的に取り込まれます。
診断そのものを担うツールは、隔離されたワーカーコンテナ側で動きます。READMEはnmapやMetasploit、sqlmapを含む20種類以上のセキュリティツールを内蔵すると説明しており、ペンテスト用タスクの既定イメージは vxcontrol/kali-linux、汎用タスク用の既定イメージは debian:latest です。外部情報の収集にはTavily・Firecrawl・Traversaal・Perplexity・DuckDuckGo・Googleカスタム検索・Sploitus・Searxngの8系統と、専用の隔離ブラウザ(scraper)を使います。監視系はOpenTelemetryで収集した指標をVictoriaMetrics・Jaeger・Lokiへ流し、Grafanaで可視化する構成です。
ツール呼び出し上限とReflectorという常時有効の歯止め
自律実行で怖いのは、エージェントが同じ操作を繰り返して課金だけが伸びる状態です。PentAGIには設定に関係なく常時働く上限があり、Assistant・Primary Agent・Pentester・Coder・Installerといった汎用エージェントは MAX_GENERAL_AGENT_TOOL_CALLS(既定100回)、Searcher・Enricher・Memorist・Generator・Reporter・Adviser・Reflector・Plannerといった限定用途のエージェントは MAX_LIMITED_AGENT_TOOL_CALLS(既定20回)でツール呼び出しが打ち切られます。
あわせてReflectorが常時有効になっており、LLMが3回続けてツール呼び出しを生成できなかった場合に介入して、正しいツールの使い方か終了用のツールへ誘導します。上限に近づいたときの打ち切りも、Reflectorが後始末を含めて進める設計です。
小型モデルで有効にすべき実行監視とタスク計画
これとは別に、既定では無効のBeta機能が2つあります。実行監視は同一ツールの連続呼び出しが5回、総ツール呼び出しが10回に達するとメンター役のエージェントが自動的に介入し、別の進め方を提案します。タスク計画のほうは、専門エージェントが着手する前に3〜7ステップの実行計画を作らせ、subtaskの範囲外へ逸れるのを防ぐ機能です。
EXECUTION_MONITOR_ENABLED=true
EXECUTION_MONITOR_SAME_TOOL_LIMIT=5
EXECUTION_MONITOR_TOTAL_TOOL_LIMIT=10
AGENT_PLANNING_STEP_ENABLED=true
READMEはこの2つを、32Bパラメータ未満のモデルを使う場合の必須設定として扱っています。Qwen3.5-27B-FP8での検証では、トークン消費と実行時間が2〜3倍に増える代わりに、結果の網羅性と正確さが2倍に改善したと報告されています。逆に大型の商用モデルを使う場合は、まず無効のまま試して費用対効果を測るのが妥当です。
Dockerでの導入手順
システム要件は2 vCPU・4GB RAM・20GB以上の空き容量とインターネット接続で、DockerとDocker Composeがあれば動きます。Podmanもサポートされていますが、ルートレスモードではscraperが443番を使えないため別途ポートの変更が必要です。
対話式インストーラーを使う場合
推奨経路はターミナルUIのインストーラーです。Linux(amd64・arm64)、Windows(amd64)、macOS(Intel・Appleシリコン)向けにpentagi.comから配布されており、システム確認、.envの生成、LLMプロバイダーと検索エンジンの設定、認証情報とSSL証明書の生成、composeでの起動までを順に進めます。
mkdir -p pentagi && cd pentagi
wget -O installer.zip https://pentagi.com/downloads/linux/amd64/installer-latest.zip
unzip installer.zip
sudo ./installer
インストーラーはDocker APIを操作するため、rootで実行するか、実行ユーザーをdockerグループに入れる必要があります。ただしdockerグループへの追加はroot相当の権限を与える操作なので、本番環境ではsudoでの実行かルートレスDockerを選ぶほうが安全です。
docker composeで手動導入する場合
既存の構成管理に載せたい場合は手動導入を選びます。設定ファイルの雛形を取得し、APIキーを埋めてから起動する流れです。
mkdir pentagi && cd pentagi
curl -o .env https://raw.githubusercontent.com/vxcontrol/pentagi/master/.env.example
curl -O https://raw.githubusercontent.com/vxcontrol/pentagi/master/docker-compose.yml
docker compose up -d
起動後は https://localhost:8443 にアクセスし、初期アカウント [email protected] とパスワード admin でログインします。パスワードは初回ログイン時に変更してください。ログイン画面からの自己登録は用意されておらず、複数人で使う場合は管理者がユーザー管理用のREST APIから追加します。
LangfuseやGraphiti、監視スタックを併用する場合は、それぞれ別のcomposeファイルを追加で起動します。このとき先に docker-compose.yml を起動してネットワークを作っておかないと、pentagi-network が見つからないというエラーになります。Ostorlabが指摘した導入の重さはこの多段構成に由来するもので、まずは本体のcomposeだけで動作を確認し、必要になった段階で足していくのが実務的です。なお本番用途では、ワーカーを別サーバーに分離する2ノード構成が公式に推奨されています。
LLMプロバイダーと埋め込みの設定
対応プロバイダーはOpenAI・Anthropic・Google AI(Gemini)・AWS Bedrock・Ollama・DeepSeek・GLM・Kimi・Qwen・MiniMaxとカスタムエンドポイントで、少なくとも1つを設定すれば動きます。設定はサーバー側の環境変数が基本ですが、v2系ではWeb画面のProviders設定からエージェントごとのモデル選択や実行時パラメータを編集・テストできるようになりました。APIキーや接続先そのものは引き続き .env 側の管理です。
num_ctx 110000の専用Ollamaモデル作成手順
ローカル推論でつまずきやすいのがコンテキスト長です。PentAGIの一般的なワークフローは約64Kトークンを消費しますが、複雑な診断シナリオに備えて110Kのコンテキストサイズを前提にしています。Ollamaの既定モデルはこれを満たさないため、num_ctxを引き上げたモデルをModelfileから作成します。
FROM qwen3:32b-fp16
PARAMETER num_ctx 110000
PARAMETER temperature 0.3
PARAMETER top_p 0.8
PARAMETER min_p 0.0
PARAMETER top_k 20
PARAMETER repeat_penalty 1.1
このファイルを保存して ollama create qwen3:32b-fp16-tc -f Modelfile_qwen3_32b_fp16_tc を実行します。num_ctxはモデル作成時にしか設定できず、作成後の変更も実行時の上書きもできない点が要注意です。既存モデルのまま動かして途中で文脈が切れる不具合を追いかけるより、先に専用モデルを作っておくほうが早く済みます。
アグリゲーター経由で使うときのLLM_SERVER_系の設定
OpenRouter、DeepInfra、Atlas Cloud、OpenCodeといったアグリゲーター経由で使う場合、専用の環境変数群は用意されておらず、OpenAI互換のエンドポイントとして LLM_SERVER_ 系にまとめて指定します。Dockerイメージには各サービス向けの設定ファイルが同梱されているため、.envで参照先を指すだけで済みます。
LLM_SERVER_URL=https://openrouter.ai/api/v1
LLM_SERVER_KEY=your_api_key
LLM_SERVER_MODEL=
LLM_SERVER_CONFIG_PATH=/opt/pentagi/conf/openrouter.provider.yml
モデル名は設定ファイル側で役割ごとに指定するため、LLM_SERVER_MODELは空のままにします。READMEはこの LLM_SERVER_ 系を実験的機能と位置づけており、将来的な変更を明記している点は把握しておいてください。
埋め込みプロバイダー切替時のetesterによるreindex
プロバイダーごとに埋め込みベクトルの次元数と性質が違うため、運用途中で埋め込みプロバイダーを差し替えると、古いベクトルと新しいベクトルが混在してナレッジ検索の結果が壊れます。PentAGIには埋め込みの検証と再構築を行う etester ユーティリティが同梱されており、切り替え時は flush か reindex を実行します。
docker exec -it pentagi /opt/pentagi/bin/etester test -verbose
docker exec -it pentagi /opt/pentagi/bin/etester reindex
同様に、LLMプロバイダー側の疎通と役割ごとのツール呼び出しを検証する ctester も用意されています。個別の関数やエージェント部品を直接呼び出して挙動を確かめたい場合は ftester を使います。フローを1本走らせて失敗するより、設定直後にこの2つを流して切り分けるほうが、原因追跡にかかる時間を短くできます。
エージェントにDockerを渡すときの権限設計
PentAGIの診断ワークフローでは、サンドボックスの内側からdockerコマンドを使いたい場面があります。この渡し方が、導入時に最も慎重な判断を要する箇所です。READMEは2つの方法を挙げたうえで、リスクの差が大きいと明記しています。
推奨されるのは、TLSで保護したdind(Docker in Docker)デーモンをサンドボックスから参照させる方法です。ソケットは一切マウントせず、接続先だけを環境変数で渡します。
DOCKER_INSIDE=true
DOCKER_SOCKET=
DOCKER_INSIDE_HOST=tcp://10.0.0.5:3376
DOCKER_INSIDE_TLS_VERIFY=1
DOCKER_INSIDE_CERT_PATH=/etc/docker/dind/certs/client
PentAGIはこれらを各ワーカーコンテナへ DOCKER_HOST・DOCKER_TLS_VERIFY・DOCKER_CERT_PATH として注入し、証明書ディレクトリを同じパスへ読み取り専用でバインドする仕組みです。サンドボックス側の追加設定は要りません。
一方、DOCKER_SOCKET でソケットをバインドマウントする方法は非推奨とされています。理由は2つあります。1つはブート順のレースで、マウント元のソケットがまだ存在しない状態でワーカーが起動すると、Dockerがそこにディレクトリを作ってしまい、手作業で消すまでdindが起動しなくなります。もう1つが影響範囲です。このレースを確実に避けられるのは常に先に存在するホスト側デーモンのソケットを渡した場合ですが、それは自律的に動くエージェントにホストのDocker APIを与えることを意味します。特権コンテナを起動してルートディレクトリをマウントすれば、PentAGI自身を含むノード全体が掌握されます。DOCKER_SOCKET を使ってよいのは、ホストのデーモンを信頼できる単一ノードの開発環境に限られます。
ネットワーク面では、PentAGIは既定で127.0.0.1にバインドされ、外部から到達できません。社内の別マシンから使う場合は PENTAGI_LISTEN_IP を 0.0.0.0 にし、PUBLIC_URL と CORS_ORIGINS にはサーバーの実IPを書いたうえでコンテナを作り直します。READMEはこの2つに 0.0.0.0 を書かないよう明示しています。診断対象と同一セグメントに置く構成では、この公開範囲を先に決めておくべきです。Kali Linuxの導入と取り扱いと同じく、ツールを動かす環境そのものを攻撃面にしない設計が前提になります。
ライセンスとVXControl Cloudの線引き
PentAGI本体はMITライセンスで、商用利用・改変・再配布に制限はありません。ただしライセンスの範囲はコードに対するもので、VXControl Cloud Services(脅威インテリジェンスやAIサポートなどのプレミアム機能)を使うには別途ライセンスキーと利用規約への同意が必要です。SDKのコードはMITでも、サービスへのアクセスは登録制という構造で、.env にも INSTALLATION_ID と LICENSE_KEY の項目が用意されています。クラウド連携を使わなければ、この2つは空のままで構いません。
もう1つ確認が要るのは、ワーカーコンテナに同梱されるツール群のライセンスです。vxcontrol/kali-linux イメージに含まれるMetasploitやnmapにはそれぞれ固有の条件があり、PentAGIがMITであることと、診断業務での商用利用可否は別問題です。有償の診断サービスに組み込む場合は、使用するツール単位で条件を確認してください。
導入判断としては、自社データを外部に出さずにセルフホストで完結させたい組織、既存の診断プロセスの初期工程を自動化したい組織に向きます。逆に、対話しながら手順を学びたい用途ではコパイロット型のPentestGPTのほうが素直で、既存のAIクライアントから既存ツールを呼び出したいだけならMCPサーバー型のHexStrike AIが候補になります。いずれの場合も、検証環境は自社が管理権限を持つ対象に限定し、第三者のシステムへ無許可でスキャンをかけないことが前提です。
よくある質問
PentAGIは無料で使えますか?
本体はMITライセンスのオープンソースなので、ソフトウェア自体のライセンス費用はかかりません。ただし動かすにはLLMプロバイダーのAPIキーが最低1つ必要で、その利用料は別途発生します。TavilyやFirecrawlなどの検索APIを併用する場合も同様です。外部への課金をゼロにしたい場合は、Ollamaによるローカル推論とDuckDuckGoの組み合わせという選択肢があります。脅威インテリジェンスなどのVXControl Cloud Servicesを使うときだけは、MITとは別枠でライセンスキーと利用規約への同意が必要です。
PentAGIの最新バージョンはどれですか?
2026年9月時点の最新リリースはv2.1.0で、UTC基準の公開日は2026年5月29日です。v1.0.0が2025年12月31日にProduction Releaseとして公開されて以降、v2.0.0でDeepSeek・GLM・Kimi・Qwenの4プロバイダー対応と実行中のプロバイダー切り替えが加わり、v2.1.0でファイル管理・ナレッジベース・ツール呼び出しの可視化が入りました。現在のREADMEに早期アルファといった記述はありません。
Ollamaだけでローカル完結の運用はできますか?
できます。ただしLLMと埋め込みが別設定である点に注意してください。OLLAMA_SERVER_URL にローカルサーバーを指定しただけでは、埋め込みプロバイダーの既定が openai のままなので外部APIを呼び続けます。EMBEDDING_PROVIDER=ollama も合わせて設定するのが正解です。加えて num_ctx を110000にしたモデルをModelfileから作る必要があり、32Bパラメータ未満のモデルでは実行監視とタスク計画の有効化がREADMEで必須とされています。READMEが例示するQwQ 32B FP16は推論に約71.3GBのVRAMを要するため、GPUの見積もりは先に済ませておくべきです。
PentAGIの公式ドキュメントはどこにありますか?
中心はGitHubリポジトリのREADMEです。導入から設定・プロバイダー検証・初回ログインまでを通しで解説したガイドは examples/guides/installation_configuration.md にあり、ワーカーノードの分離やvLLMでのローカル構成といった個別のガイドも同じ examples/guides/ 配下に置かれています。REST APIの仕様書は起動後にWeb UIと同じホストの api/v1/swagger/index.html から参照でき、日本語の公式ドキュメントは提供されていません。
PentestGPTとどちらを選ぶべきですか?
判断軸は自律度と実行環境です。PentAGIはサンドボックス化したコンテナ内でエージェントが自律実行するため、定型工程の委任に向きます。PentestGPTは手元のターミナルでの操作を前提としたコパイロット型で、テスターが各手順を判断する運用に向きます。手順を人が握り続けたいならPentestGPT、実行まで任せて監査ログで追いたいならPentAGIという整理になります。導入コストの面では、単体のCLIで完結するPentestGPTのほうが軽い点も考慮してください。