2025年12月の記事 では、DeepAuditをコード監査、PentestGPTを稼働中の対象への侵入テストとして対比しました。

2026年には、コードから攻撃の手掛かりを探し、稼働中のアプリで実証コード（PoC）を試す仕組みも登場しています。 PoCで攻撃が成立するかを確かめ、その結果を変更ごとの自動検査（CI）に取り込みます。 Strix とShannon の更新を見ると、発見した脆弱性の根拠を残す仕組みが増えています。 一方、攻撃を試す段階では大規模言語モデル（LLM）の安全制限が実行を止めることもあります。

以下は2026年10月7日時点で、Strix v1.7.0とShannon v3.4.0の公式資料を中心に整理した内容です。 実際のペンテストや、検出性能の比較は行っていません。 サーバー側のモデル制限や商用サービスの提供内容は、その後も変わり得ます。

Shannonはコードで見つけた疑いを検証環境で確かめる

Shannonは、ソースコードから攻撃経路を探し、稼働中のWebアプリやAPIに対して実際の攻撃を試みます。 ブラウザを操作したりコマンドを実行したりして、攻撃が成立するかを確認します。

v3.4.0のREADME は「実証した攻撃がなければ報告しない」と説明しています。 ソースコードへのアクセスを前提とするため、URLだけを渡す黒箱型のスキャナとは入力条件が異なります。

2026年9月のv3.0.0 では、コードを実行せずに調べる静的解析（SAST）をエージェントで進める仕組みを追加しました。 アプリの構造、信頼境界、データの流れを把握し、疑わしい箇所に調査を絞ります。

現在は、稼働中のアプリの調査とコード解析から脆弱性の候補を集め、重複を整理してから攻撃を試します。

攻撃の成立を確認できなかった候補は最終報告から除き、確認できたものをPDF、Markdown、JSONなどで出力します。 ただし、公式READMEは、LLMのレポートには根拠の弱い説明や誤りが含まれる場合があるため、人によるレビューが必要だと注意しています。

GitHub ActionsやGitLab CI/CDで深刻度のしきい値を使う場合も、コード解析が出した仮説だけでは失敗扱いにしません。 攻撃が成立したことを示すstatus: exploitedの項目だけを判定に使います。 静的解析の候補と、リリースを止める根拠を分ける設計です。

Shannonはローカル実行とCIをつないだ

Shannon Open Sourceは、ローカルのCLIとDockerワーカーで実行します。

対象のリポジトリは読み取り専用で一時コンテナへマウントされ、結果はローカルのワークスペースへ保存されます。 ただし、稼働中のアプリに対する操作まで読み取り専用になるわけではありません。 安全性の説明 は、ユーザー作成やフォーム送信でアプリの状態が変わる可能性があると説明しています。 本番環境での実行は明示的に禁止されており、使い捨てのデータを用意した検証環境での実行を求めています。

また、信頼できないコードや攻撃者が用意したコードを読み込ませないよう警告しています。 コード内の悪意ある指示がエージェントを誘導する、プロンプトインジェクションの危険があるためです。 対象へのテスト許可とは別に、読み込ませるコードの信頼性も確認します。

CIでは、チェックアウトしたコードを解析しながら、指定したステージングまたは開発環境を攻撃します。 レポートと実行ログを保存でき、途中で中断した検査と、最後まで実行して脆弱性が見つからなかった検査を区別します。 解析結果を受け渡す標準形式のSARIFも出力し、GitHubのコードスキャンに取り込めます。

2026年3月のv1.0.0 では、npxで起動するCLIと一時ワーカーの構成を導入しました。 9月にはコード解析が拡張され、10月には実行前の確認機能とレポートの読みやすさが改善されました。

v3.4.0 では、認証済みテストの準備を確認する--validate-auth、攻撃を実行できる状態かを確認する事前検査、PDFレポートから発見事項の詳細へ移動するリンクが追加されました。

認証情報やログイン手順に加え、一定時間ごとに変わるワンタイムパスワード（TOTP）、メール認証、対象範囲を設定で渡せます。 ただし、認証できることと、テスト範囲が適切であることは別です。 対象ホスト、使ってよいテストアカウント、実行時間、許可する副作用、停止方法を先に決めます。

OSS版にもコード解析がある

Shannon Open SourceはAGPL-3.0で公開されており、コード解析から攻撃の実証、報告までを単独で行えます。 「コード解析はすべて商用版だけ」と理解すると、3.0以降の構成を取り違えます。

一方、Keygraph Enterprise Platformの説明 では、リポジトリ横断の解析、依存関係と秘密情報の検査、発見事項の一元管理、修正PRの生成と再検証を商用版の機能として挙げています。 OSS版で得られる個別のレポートと、組織全体で修正まで管理する商用版の仕組みは分けて読む必要があります。

正当なテストでもLLMが途中で拒否する

Shannonのモデル設定ドキュメント は、AnthropicとOpenAIのサイバーセキュリティ向け安全制限により、スキャンの途中でモデルが拒否し、実行が中断される可能性を明記しています。

利用するモデルと作業内容に応じて、各社が求める確認や登録を先に済ませます。

Shannonの--validate-modelは、認証情報とモデル設定に加え、利用するモデル提供元がセキュリティテストの依頼を受け付けるかを先に確認します。 この確認ではペンテストもレポート出力も行いません。

Anthropicの説明 では、一般提供モデルでも、安全なコードレビュー、既知の問題の修正、自分のソースコードに対する脆弱性の探索にモデルを利用できます。 一方、実際に攻撃が成立するかを確かめる作業は、安全性を判定する分類器によって中断され得ます。 正当なテストでこの制限に遭遇する利用者向けに、Cyber Verification Programを案内しています。

OpenAIのDaybreak も、認可されたサイバーセキュリティ作業のために本人確認とアカウント保護を求めています。

対象へのテスト許可と、モデル提供元による利用承認は別の条件です。 登録が求められる場合は済ませたうえで、開始前にモデルが作業を受け付けるかを確かめます。 事前確認が通っても、その後の全操作が承認されるという保証にはなりません。

クラウドのLLMを使うなら、ソースコード、認証情報、実行ログがどのプロバイダへ送られるかも確認します。

StrixはCLIから調査を進め、証拠を残す

Strixは、ローカルのコード、GitHubリポジトリ、稼働中のWebアプリ、API仕様を入力にできます。

v1.7.0のREADME は、コードを動かし、偵察、攻撃、PoCによる検証を行うマルチエージェント型のツールとして説明しています。 HTTP通信を調べるCaidoのプロキシ、ブラウザ操作、シェル、Pythonの実行環境をエージェントが使います。

複数のエージェントは発見事項を共有し、調査を分担します。 認証やアクセス制御に加え、競合状態や業務フローの迂回も検査対象として掲げています。 ただし、この一覧は対応を目指す範囲であり、個々のアプリで漏れなく検出できるという保証ではありません。

OpenAPIやPostmanの仕様を渡すと、Strixはそこに定義されたAPIのエンドポイントを読み取れます。 稼働中のAPIも同時に対象にでき、クロールだけでは見つけにくい入口も調査の手掛かりにできます。

コードとステージング環境のURLを両方指定すれば、ソースコードを読む調査と、稼働中のアプリの挙動を確かめる調査を同じ実行で進められます。

一方で、ローカルディレクトリを対象にすると、そのディレクトリはサンドボックスへ書き込み可能でマウントされます。 .gitは除外されますが、エージェントが元の作業ファイルを変更する可能性があります。 CLIドキュメント が先にcommitまたはstashを求める理由です。 検査だけを行う場合でも、元の作業ツリーを保護した複製や専用の作業環境を用意します。

CIでは、プルリクエストの変更ファイルに対象を絞ったquickモードを使えます。

対話画面を使わない実行で--fail-on highのようなしきい値を指定すれば、指定した深刻度以上の問題が見つかったときに、失敗を示す終了コードを返せます。

これは検証環境での定期実行には便利ですが、本番への無条件な攻撃許可にはなりません。

発見事項から実際のHTTP通信をたどる

v1.7.0 では、プロキシを使って検証した発見事項から、根拠となるHTTP通信を参照できるようになりました。

具体的には、発見事項を登録する際、攻撃を示すリクエストだけでなく、通常時など、差分の基準となる通信もhttp_exchange_idsで参照します。 IDには実際に取得した通信記録の値を使い、モデルが捏造しないよう指示しています。

変更を説明するPR では、静的解析だけの発見や、依存関係の既知の脆弱性（CVE）のようにHTTP通信が存在しないケースを対象外としています。 これはプロンプトでモデルに求めるルールでもあり、レポート全体の正しさを機械的に保証するものではありません。

PoCを「生成した」と書くより、どの通信が再現の根拠かを追える方が、レビューと修正確認に役立ちます。

StrixではさまざまなLLM提供元を選べ、Ollama、LM Studio、OpenAI互換サーバなどのローカルモデルにも接続できます。 ただし、ローカルモデルでもテスト対象に副作用は生じ得るため、実行権限の管理は必要です。

--max-budgetは全エージェントのLLM費用、--max-turnsは各エージェントの応答とツール実行の回数を制限します。 非対話型の実行では、予算に達するとstoppedとして終了します。 対話型では一時停止し、利用者がメッセージを送ると予算枠を増やして再開するため、同じ上限指定でも動作が異なります。

費用上限はモデル応答の後に確認され、並列で実行中の呼び出しによって、上限を超える場合があります。 費用もトークン使用量と価格からの推定なので、実際の請求額がこの上限内に収まるとは限りません。 stoppedで終わった検査は、最後まで調べて発見がなかった検査とも区別します。

ローカル版とクラウド版は同じ運用ではない

StrixのOSS版はApache-2.0で公開され、Dockerと利用者のLLM接続先で実行します。 strix viewでは、発見事項、エージェントの構成、過去の実行をローカルの画面で見られます。 画面がローカルにあることと、LLMへの送信がないことは別です。

公式READMEが案内するStrix Cloudには、修正PRの生成、継続テスト、開発ツールとの連携があります。 企業向けプランでは、組織の認証を共通化するSSOや、専用の仮想ネットワーク（VPC）内への配置も選択肢に挙げています。 自動修正や組織向けの管理機能を紹介するときは、ローカルCLIで使える機能と分ける必要があります。

DeepAuditとPentestGPTにも更新がある

前の記事で扱ったDeepAuditとPentestGPTにも動きがあります。

DeepAudit のv3.0.4 は、エージェント間のタスク引き継ぎとブランチ検索を修正しました。 埋め込みモデルのベクトル次元と、監査LLMのタイムアウトも設定可能になりました。 サーバーに意図しない宛先への通信をさせるSSRFへの対策も更新しており、監査ツール自身を保護する作業が続いています。

PentestGPT は、2025年12月のv1.0.0 で自律実行、活動状況を表示するターミナル画面、Dockerでの導入を掲げました。 ただし、現行の構成文書 では、自律フレームワークと従来の対話型pentestgpt-legacyを分け、リポジトリ直下の設定で構築するDockerイメージには、自律型はまだ含まれないと説明しています。 リリース当時の紹介を、そのまま現行版の導入手順として読むのは避けたいところです。

私なら4ツールをこう使い分ける

以下は公式資料から考えた私見で、同じ対象を4ツールで試した結果や性能順位ではありません。 ソースコードが手元にあるかどうかから、質問に「はい」「いいえ」で答えて選びます。 どのツールでも、対象へのテスト許可と操作の範囲、モデル提供元の利用条件、データの送信先、起こり得る副作用を先に確認します。

図は、私なら最初にどのツールを試すかを示したものです。 ツールの用途には重なりがあり、同じ条件で別のツールを選ぶこともできます。 Strixを選ぶ場合も、エージェントに任せる操作の範囲を先に決めます。

• DeepAudit：検証環境を用意する前に、コードから疑わしい実装や攻撃の手掛かりを探したいときに選びます。指摘だけで脆弱性の成立を決めず、稼働環境で別途確かめます。
• PentestGPT：次に何を試すかを人が判断し、対話しながらテストを進めたいときに選びます。対話型を選ぶなら、人が対象と操作を決め、結果を読みながら進めます。自律型を使う場合は別の構成なので、導入するパッケージと実行範囲を先に確認します。
• Shannon：自分たちのコードと使い捨ての検証環境があり、攻撃の成立を確認したものを中心に報告したいときに選びます。その結果をCIの判定にも使えます。本番環境には向けず、レポートも人が確認します。
• Strix：コードや稼働中のWebアプリ、APIの調査を複数のエージェントに分担させたいときに選びます。根拠となる通信を後からたどりたい場合にも候補になります。ローカルコードを渡す場合は書き込み可能な作業領域を隔離し、実行量も制限します。

同じ案件で併用する場合も、前のツールの指摘をそのまま正しいと決めつけず、対象の許可と再現記録を人が確認します。

「見つける」「試す」「止める」を分けて運用する

Shannonはコードで見つけた疑いを攻撃で確かめ、その結果をCIの判定に使います。 Strixは複数エージェントの調査に、通信証拠と実行量の制御を組み込んでいます。 見つけた問題の数だけでなく、その根拠を残して修正につなげる仕組みが整ってきました。

実行前には、LLMが途中で拒否する可能性に加え、Dockerやテストアカウントの権限、データを書き換える操作、費用の上限も考慮する必要があります。

評価するなら、許可を得たステージング環境で、対象ホスト、認証情報、許可操作、停止条件、ログの保管先を固定します。

同じ検証用アプリで、発見事項に再現手順と根拠となる通信またはPoCが残るかを確認します。

その記録を担当者がレビューし、修正後にも再現を試せるところまでを運用に含めます。