Strixとは｜AIが実際に攻めてPoCで裏取りするOSSペンテスターを実測で解説

「静的スキャナを回すと警告が数百件出るが、そのほとんどが誤検知。かといって手動ペンテストは高コストで、リリースのたびには頼めない」——アプリのセキュリティ検査は長らく、この2つの不満の板挟みでした。Strix（ストリックス）は、この構図を崩すために作られた、自律型AIエージェントによるオープンソースのペネトレーションテストツールです。GitHubスター数は49,006（2026年8月6日時点）に達し、AIセキュリティ領域で最も勢いのあるOSSのひとつになっています。

この記事を読むと、①Strixで何ができるのか（AIエージェントが実際に攻撃してPoCで脆弱性を裏付ける）、②どんな課題を解決するのか（手動ペンテストのコストと、従来スキャナの誤検知の山）、③何を代替できるのか（静的スキャナの補完と、定型的なペンテスト工程の自動化）が分かります。さらに本記事では、公開されているソースコードを読み、Strix自身が外部へ何を送信しているのかを実際に計測しました。攻撃ツールを自社環境に入れる以上、ツール自体の挙動を確かめるのは当然の手順だからです。

サプライチェーンを含む開発セキュリティ全体の考え方は、まずサプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストで土台を掴んでおくと、Strixの位置づけが明確になります。

Strixとは——「PoCがなければ発見なし」で誤検知を切り落とす設計

Strixは、人間のペネトレーションテスターがやることを、AIエージェントに自律的に代行させるツールです。実装はPythonで、PyPIには strix-agent として公開されています。従来の「疑わしい箇所を列挙するスキャナ」とは根本的に発想が異なり、Strixのエージェントは実際にエクスプロイトコードを書き、隔離環境で実行し、成功したら動くPoCを添えて報告します。

READMEはこの狙いを明快に述べています。曰く、手動ペンテストの負担も、従来スキャナの誤検知もなしに脆弱性を見つけて直す、と。ここで鍵になるのが「再現できたものだけを報告する」という思想です。脆弱性を報告する前に、実際に悪用できることを自分で確かめる——だからこそ、上がってくる指摘の確度が高くなります。

この「実証してから報告する」という順序は、地味に見えて運用を大きく変えます。従来は、スキャナが出した大量の候補を人間が一つずつ精査し、本物か誤検知かを判断する必要がありました。Strixはその判断の大部分を、PoCという動かぬ証拠に置き換えます。結果として、セキュリティ担当者の時間は「選別」ではなく「対処」に振り向けられます。

・攻撃を再現する：仮説を立てて終わりではなく、エクスプロイトを実行して裏を取る
・隔離して実行する：攻撃コードはDockerサンドボックス内で動かし、ホストから切り離す
・証拠を残す：再現手順つきで報告するため、開発側が「これは誤検知では？」と差し戻す余地が小さい
・CWEを付ける：報告にCWE分類が付くため、既存の管理フローに載せやすい

READMEが挙げる主要機能のひとつに「マルチエージェント編成」があります。単一のエージェントが全部を抱えるのではなく、複数のAIペンテスターが分担・協調して規模を広げるという設計です。v1.3.0では、この構造をより明確にする変更としてルートエージェントを「統括専任」にし、修正提案の生成をレポート工程へ寄せる調整が入りました（PR #827）。指揮する役と実際に手を動かす役を分けたわけで、strix/skills/coordination/ にエージェント間連携のスキルが置かれているのもこの設計に対応します。

組み込みスキル59本の中身を数えてみる

Strixの「何ができるか」は、リポジトリの strix/skills/ 配下を見るのが最も正確です。2026年8月6日時点の main ブランチで、スキル定義（.md）を実際に数えると59本・10カテゴリでした。

注目したいのは tooling の11本です。ここに nmap・nuclei・sqlmap・ffuf・semgrep といった、実際のペンテスターが日常的に使う定番ツールが並んでいます。つまりStrixは「LLMが単独で攻撃を考える」のではなく、既存のセキュリティツール群をAIエージェントが operator として操作する構造になっています。ここがLLM単体のコード診断との決定的な違いで、偵察・列挙・攻撃の各段階で実績のあるツールの出力を根拠にできます。

また vulnerabilities に llm_prompt_injection.md が含まれている点も、時代を反映しています。LLMを組み込んだアプリケーション自体を検査対象にできるということです。AIを使った攻撃側の現実については、DeepSeek自律攻撃をUnit 42が分析｜460標的で自律フェーズ全失敗、成功3件は手動という実像も併せて読むと、「自律AI攻撃」という言葉の解像度が上がります。

Strixのタイムライン——v1.0.4からv1.4.1までの7週間で変わったこと

Strixは開発が非常に速く、日本語の解説記事が書かれた時点の情報がすぐ古くなります。GitHubのリリースノートから、直近の変更を時系列で整理します。以下の日付はすべてリリースの公表日（UTC）です。

この7週間の変更のうち、導入判断に効くものは3つに絞れます。

1つ目はSARIF 2.1.0出力です。 v1.1.0で追加されました（PR #626）。SARIFは静的解析結果の標準フォーマットで、GitHubのcode scanningがそのまま取り込めます。さらにPR #708では、CWEから導出したSTRIDE分類のタグ付けも加わりました。これにより、Strixの検出結果を既存の脆弱性管理基盤に流し込めるようになります。「面白いツールだが結果の置き場所がない」という導入障壁が、ここで一段下がりました。

2つ目は --max-budget-usd です。 同じくv1.1.0（PR #576）。LLMを使うツールで最大の不安は「気づいたら請求が跳ねている」ことです。自律エージェントは自分で判断して何十回もLLMを呼ぶため、この不安は現実的でした。上限金額を渡せるようになったことで、CIに置いても暴走しないという最低限の保証が得られます。

3つ目はサンドボックスイメージの縮小です。 v1.3.0（PR #474）で、キャッシュ整理・Goのマルチステージビルド・ZAPの同梱取りやめによって、7.2GBから3.8GBへほぼ半減しました。初回実行時にこのイメージを取得する仕様なので、CIランナーで毎回引く場合の待ち時間とネットワーク帯域に直結します。

なお、v1.4.0では「スキャン終了後にローカルビューアをホストし続けるのをやめて終了する」という変更（PR #858）が入っています。CIで回すときにプロセスが終わらないという詰まり方をしていた場合、この版で解消されている可能性があります。あわせて終了コードの意味もドキュメント化されました（PR #871）。CIのゲートとして使うなら、この版以降を前提にするのが無難です。

StrixとSAST・DAST・他のAIセキュリティツールの違い

Strixを評価するときに最も多い誤解は、「SASTの代わりになるか」という問いの立て方です。実際には、両者は検査する対象も出力の性質も違います。

この表から読み取れる要点は、Strixは速さと安さではSAST・DASTに勝てないということです。CPU時間だけで回るSASTを毎コミット実行するのは合理的ですが、LLM課金が発生し探索的に長時間動くStrixを同じ頻度で回すのは現実的ではありません。

一方で、SASTが構造的に苦手な領域があります。IDOR（権限のない他人のデータへアクセスできてしまう欠陥）や、決済フローの順序を入れ替えると成立してしまうビジネスロジックの欠陥は、コードのパターンを見ただけでは判定できません。「このユーザーIDでこのリクエストを投げたら他人のデータが返ってきた」という実際の応答が必要です。ここがStrixの主戦場です。

したがって現実的な構成は、置き換えではなく併用になります。SASTを毎PRで回して既知パターンを潰し、Strixはリリース前や週次など頻度を絞って走らせ、実証が必要な深い欠陥を拾う。SARIF出力があるおかげで、両者の結果を同じダッシュボードに集約できます。

AIを使ったセキュリティ検査ツールという括りでは、OpenAI Codex Securityとは｜使い方と13スキルの中身をApache-2.0公開コードで解説で扱ったツールとも比較されます。ただし方向性は異なり、Codex Security系が「コードを読んで危険を指摘する」側であるのに対し、Strixは「動かして再現する」側に立っています。読む側と攻める側は競合ではなく、検出の網が重なりにくい補完関係にあります。

Strixのインストールと使い方——最初のスキャンまで

Strixの導入は、Dockerが動いていることとLLMのAPIキーがあることが前提です。公式READMEが案内する手順は次の3ステップです。

# 1. Strix をインストール
curl -sSL https://strix.ai/install | bash

# 2. 使用する LLM とキーを環境変数で指定
export STRIX_LLM="openai/gpt-5.4"
export LLM_API_KEY="your-api-key"

# 3. 最初の診断を実行（対象はローカルディレクトリ）
strix --target ./app-directory

初回実行時にサンドボックス用のDockerイメージが自動で取得されます。前述のとおりv1.3.0で3.8GBまで縮んでいますが、それでも小さくはないので、初回は時間に余裕を見てください。結果は strix_runs/<run-name> 配下に保存されます。

なお curl | bash 形式のインストールに抵抗がある場合、strix-agent はPyPIにも公開されているため、パッケージマネージャ経由で導入する選択肢もあります。pyproject.toml の requires-python は >=3.12 で、上限は指定されていません。ただしリリースノートを見ると、v1.1.0で「新規インストールが通るように」依存の openai を <2.45 に固定した経緯（PR #748）や、v1.4.0でIntel macOS向けwheelを維持するため cryptography を <49 に留めた経緯（PR #859）が記録されています。依存解決がタイトなプロジェクトなので、既存環境に直接入れず、専用の仮想環境か隔離環境を用意するのが安全です。

対象の指定方法

Strixが検査できる対象は3種類あります。

・ローカルのコードベース：--target ./app-directory のようにディレクトリを渡す（ホワイトボックス）
・GitHubリポジトリ：リポジトリを指定して取得させる
・稼働中のWebアプリ：URLを渡す（ブラックボックス）

v1.1.0では、大きなリポジトリを扱うためのバインドマウント指定（PR #577）と、対象をファイルで一括指定する --target のリスト形式（PR #711）が加わりました。複数のサービスをまとめて回したい場合はこちらが使えます。

APIキー以外の認証方法

v1.4.0では、従量課金のAPIキーの代わりにChatGPTのサブスクリプションでサインインして推論を通す経路が追加されました（PR #854）。前節のテレメトリ実測で観測された auth_mode というフィールドは、この2方式（api_key かサブスクリプションか）を区別するために存在します。

これはコスト管理の観点で意味が大きい変更です。従量課金のAPIキーはスキャンの規模がそのまま請求額に跳ね返りますが、サブスクリプション経由なら月額の範囲に収まります。個人での検証や、頻度の低い定期検査であれば、こちらの方が予算を読みやすい場面があります。逆にCIで並列に大量に回す用途では、サブスクリプション側のレート制限が先に効くことが考えられるため、用途に応じて選び分けることになります。

コスト面では、同じくv1.1.0の --max-budget-usd を必ず併用してください。自律エージェントは終了条件を自分で判断するため、上限を渡さないとどこまで探索が続くか事前に読めません。

# 予算上限を指定して実行する（暴走防止）
strix --target ./app-directory --max-budget-usd 5

Strix自体は何を外部に送るのか——テレメトリを実測する

攻撃ツールを自社のコードベースに向けて走らせる以上、そのツール自身が何を外部に送っているのかは確認すべき項目です。ここは公式READMEの記述をなぞるだけでは不十分なので、実際にソースを読み、送信内容を捕捉して確かめました。

送信先は2か所、既定で有効

strix/config/settings.py を読むと、テレメトリの設定はこう定義されています。

class TelemetrySettings(BaseSettings):
    model_config = _BASE_CONFIG

    enabled: bool = Field(default=True, alias="STRIX_TELEMETRY")

default=True — つまりテレメトリは既定で有効で、環境変数 STRIX_TELEMETRY によるオプトアウト方式です。送信先は strix/telemetry/ 配下のコードから2か所であることが分かります。

・PostHog：https://us.i.posthog.com/capture/ へJSONをPOST
・Scarf：https://strix.gateway.scarf.sh/<イベント名>/<バージョン>?<クエリ> へPOST

実際に送信内容を捕捉する

コードを読むだけでは「実際に何が飛ぶか」は確定しません。そこで、リポジトリのテレメトリモジュールをそのまま読み込み、HTTP送信部分を差し替えて中身を記録する形で、スキャン開始・脆弱性報告・スキル読み込みの各イベントを発火させました。ホームディレクトリも一時領域に差し替え、実環境を汚さない状態で計測しています。

既定状態（環境変数なし）では、4件のリクエストが観測されました。PostHogへ送られた scan_started の中身は次のとおりです。

{"api_key": "phc_...", "event": "scan_started", "distinct_id": "ea952ee2dc6749bd",
 "properties": {"os": "darwin", "arch": "arm64", "python": "3.12",
 "strix_version": "unknown", "model": "openai/gpt-5.4", "auth_mode": "api_key",
 "scan_mode": "standard", "scan_type": "whitebox", "interactive": false,
 "has_instructions": true, "first_run": true}}

観測できた項目を整理すると次のようになります。

そして含まれていなかった項目が重要です。捕捉した全ペイロードを確認した範囲では、対象のURL・ホスト名・ファイルパス・ソースコード・脆弱性の説明文・LLMへのプロンプトと応答は一切出現しませんでした。公式の strix/telemetry/README.md は「スキャン対象・ファイルパス・URL・ドメイン」「脆弱性の詳細や説明、コード」「LLMのリクエストと応答」は収集しないと明記していますが、この主張はソースと実測の双方で裏付けられました。

識別子についても確認しました。distinct_id に入る値は uuid4().hex[:16] でプロセス起動ごとに生成される乱数で、ディスクに永続化されません。実行のたびに別のIDになるため、継続的な個人追跡には使えない作りです。

オプトアウトは実際に効くか

公式が案内する停止方法は環境変数ひとつです。

# テレメトリ送信を完全に停止する
export STRIX_TELEMETRY=0

同じ計測を STRIX_TELEMETRY=0 を設定した状態で実行したところ、送信は0件でした。PostHog・Scarfとも1件も発火せず、オプトアウトは宣言どおり機能しています。

送信をブロックする場合に知っておくこと

環境変数ではなくネットワーク側で遮断したい組織もあります。その判断に効く実装上の性質が2つあります。

1つ目は、Scarfへの送信がすべてURLのクエリ文字列に載ることです。 PostHogがJSONの本文で送るのに対し、Scarf側は https://strix.gateway.scarf.sh/scan_started/<版>?os=darwin&arch=arm64&python=3.12&session=...&model=openai%2Fgpt-5.4&scan_mode=standard&scan_type=whitebox... という形になります。クエリ文字列は、プロキシやゲートウェイのアクセスログに最も残りやすい部分です。前述のとおり中身に対象情報や秘密情報は含まれないため実害は想定しにくいものの、全URLをログする外向きプロキシを運用している場合、これらの値が可読な状態でログに現れる点は把握しておくとよいでしょう。

2つ目は、送信のタイムアウトが短く設計されていることです。 ソース上の設定は接続2秒・読み取り3秒で、コメントには「テレメトリはビーコンであってユーザーが待つものではない」「終了処理の途中に入るため、ファイアウォールで破棄されるエンドポイントでも終了が遅く感じられない長さにする」という趣旨の説明が添えられています。つまりこの2ドメインをファイアウォールで落としても、Strixがハングすることはなく、最悪でも終了が数秒延びるだけという設計です。環境変数によるオプトアウトとネットワーク遮断のどちらを選んでも運用は成立します。

ひとつだけ、実行して初めて分かった細かい挙動があります。「初回実行かどうか」を判定するためのマーカーファイル ~/.strix/.seen は、テレメトリを無効にしていても作成されます。イベントの引数を組み立てる時点で判定関数が評価され、送信の可否判定はその後に行われるためです。ただしこのファイルは中身のない空ファイルで、識別子は何も書き込まれず、無効時は当然ながら外部にも送られません。プライバシー上の実害はないものの、「何も書き込まれないはず」と考えていると差分検知で驚くことになるので、記録しておきます。

Strixを安全に使うための対策と自環境の確認コマンド

Strixは攻撃を実行するツールです。導入時の対策は、一般的なOSSの導入手順より一段厳しく考える必要があります。

実行前に必ず確認する項目

1. テスト対象の許可を書面で得る。 これが最優先です。READMEも「自分が所有しているか、テストの許可を得たアプリのみ」と明記しています。許可のない対象への攻撃的テストは、日本では不正アクセス禁止法などに抵触するおそれがあります。社内システムであっても、事前にスコープ・実施時間帯・緊急連絡先を合意しておくのが実務です。バグバウンティで使う場合も、各プログラムの規約で自動化ツールの使用が許可されているかを必ず確認してください。

2. 本番環境に向けない。 エージェントは実際にエクスプロイトを試みます。データを壊す・大量のリクエストを送る・意図せぬ状態遷移を起こす可能性があります。ステージング環境か、本番と切り離した検証環境を用意してください。

3. LLM APIキーの権限と予算を絞る。 検査専用のキーを発行し、--max-budget-usd と併用します。

4. テレメトリの扱いを決める。 前節のとおり既定で有効です。送信内容に機微情報は含まれませんが、外部通信そのものを禁じるポリシーの環境では停止が必要です。

5. Dockerの稼働と隔離を確認する。 攻撃コードはサンドボックス内で実行されますが、Dockerソケットの権限設計は自分の責任範囲です。

自分の環境を確認するコマンド

導入済みの環境で、いま何が動いているかを確認する手順です。

# 1) Strix が入っているか・版はいくつか（PATH上の重複も確認）
which -a strix
strix --version
pip show strix-agent 2>/dev/null | grep -E "Version|Location"

# 2) テレメトリ設定の現状を確認（空なら既定=有効）
echo "STRIX_TELEMETRY=${STRIX_TELEMETRY:-(未設定＝有効)}"

# 3) 初回実行マーカーとローカル成果物の有無
ls -la ~/.strix/ 2>/dev/null
ls -d strix_runs/* 2>/dev/null | tail -5

# 4) サンドボックスイメージのサイズを実測（3.8GB前後が v1.3.0 以降）
docker images | grep -i strix

# 5) Strix 由来の外部通信先を洗い出す（送信先の把握）
grep -rn "posthog\|scarf" $(python3 -c "import strix,os;print(os.path.dirname(strix.__file__))" 2>/dev/null) 2>/dev/null | head

which -a を使うのは、パッケージマネージャ経由とインストーラ経由で複数のStrixが同居している場合に、strix --version がPATH先頭の1つしか表示しないためです。古い版が残っていると、修正済みのはずの挙動に当たり続けることがあります。

影響範囲——どの版で何が変わるか

自分が使っている版によって、期待できる挙動が変わります。影響範囲を整理します。

更新はv1.4.0で追加された自己更新機能を使えます。

# 最新版へ更新する（v1.4.0 以降）
strix --update

Strixの導入判断——向くケースと向かないケース

ここまでの内容を、導入判断の形にまとめます。エージェントがどう動くかを整理すると次のようになります。

この図の分岐が、Strixの価値そのものです。再現できなかったものは報告されない——だから届く報告の密度が高くなります。

向いているケース

・自社アプリのリリース前検査：許可の問題がなく、ステージング環境も用意しやすい
・SASTでは届かない欠陥を拾いたい：IDOR・権限昇格・ビジネスロジックの欠陥
・検出結果を既存基盤に集約したい：SARIF 2.1.0出力でGitHub code scanningへ流せる
・LLMアプリ自体を検査したい：プロンプトインジェクション用のスキルが同梱されている
・バグバウンティの一次調査：規約で自動化が許可されている範囲に限る

向いていないケース

・許可を取れない第三者の資産：技術的な可否ではなく法的に不可
・LLMコストを管理できない状況：予算上限を運用に組み込めないなら見送る
・Dockerを動かせない環境：サンドボックス前提の設計なので代替手段がない
・毎コミットの高速フィードバックが欲しい：探索的に動くため時間がかかる。ここはSASTの領分
・外部通信を一切許さないポリシー：LLM APIへの通信自体が必須（テレメトリは停止できるが、推論の通信は止められない）

最後の点は補足が要ります。STRIX_TELEMETRY=0 で止められるのは利用統計の送信だけです。Strixの本体機能はLLMへの問い合わせで成り立っているため、クラウドのLLMを使う限り、検査対象に関する情報はLLMプロバイダへ送られます。完全にネットワークを閉じたい場合は、ローカルLLMを使う構成を検討することになります。この点は、テレメトリの話とは切り分けて評価してください。

まとめ

Strixは、自律AIエージェントが実際にアプリを攻撃し、再現できた脆弱性だけをPoC付きで報告するオープンソースのペネトレーションテストツールです。★49,006（2026年8月6日時点）という数字が示すとおり注目度は高く、開発速度も非常に速いのが特徴です。

本記事で確認できたことを整理します。

・組み込みスキルは59本・10カテゴリ。うち脆弱性25本、nmap・nuclei・sqlmap等の外部ツール操作が11本（リポジトリの実カウント）
・v1.1.0のSARIF 2.1.0出力と--max-budget-usd、v1.3.0のサンドボックス半減が、CI導入の現実性を大きく引き上げた
・Strix自体は既定でPostHogとScarfへ利用統計を送信するが、実測した全ペイロードに対象URL・パス・コード・脆弱性詳細は含まれず、公式の説明と一致した
・STRIX_TELEMETRY=0 で送信は0件になることを実測で確認した
・SASTの置き換えではなく併用が現実解。速さと安さはSAST、実証が要る深い欠陥はStrix

そして最も重要な前提を繰り返します。Strixは許可を得た対象にのみ使ってください。 攻撃を実行するツールである以上、技術的に動くことと、実行してよいことは別の話です。

参照ソース

・usestrix/strix (GitHub) — 本体リポジトリ。スター数・ライセンス・スキル定義の実カウントはこのリポジトリのmainブランチ（2026年8月6日時点）に基づく
・Strix Releases — v1.1.0 / v1.2.0 / v1.3.0 / v1.4.0 / v1.4.1 のリリースノート。タイムラインの日付とPR番号の出典
・strix/telemetry/README.md — テレメトリ方針の公式説明。本記事の実測はこの記述の検証として実施
・Strix 公式ドキュメント — インストール・LLMプロバイダ設定
・strix-agent (PyPI) — 配布パッケージ。バージョンと公開日の確認に使用