AIがハッカーの代わりにアプリを攻撃する — GitHub 4万スターのOSS「Strix」の正体

ペネトレーションテスト（侵入テスト）は、セキュリティの世界では当たり前の作業だ。専門のエンジニアがシステムに擬似攻撃を仕掛け、脆弱性を見つけ、修正方法を報告する。問題は、これにかかるコストと時間だ。外部のペンテスト業者に依頼すれば数百万円、社内で実施しても数週間。スタートアップや個人開発者には手が届かない。

Strixは、この作業をAIエージェントに任せるオープンソースプロジェクトだ。GitHub上で41,000スターを超え、1日で2,000スター増えた日もある。ペンテストツールとしては異例の注目度で、セキュリティコミュニティの外からも関心を集めている。

人間のペンテスターのように振る舞う

Strixの設計思想は「1つのAIに全部やらせない」だ。

代わりに、複数の専門エージェントをグラフ構造で連携させる。偵察エージェントがアプリケーションの攻撃面をマッピングし、SQLインジェクション担当のエージェントがデータベース周りを探り、XSS担当のエージェントがフロントエンドを攻撃し、検証エージェントが発見された脆弱性を実際に再現する。彼らは並列に動き、文脈を共有する。

人間のペンテストチームがやることを、AIエージェントのチームが代行するイメージだ。

カバー範囲はOWASP Top 10に沿っている。アクセス制御の不備（IDOR、権限昇格）、インジェクション攻撃（SQL、NoSQL、OSコマンド）、SSRF、XSS各種、CSRF、認証バイパス、ビジネスロジックの欠陥——セキュリティ診断で見るべきポイントが一通り揃っている。

見つかった脆弱性には実際に動くProof-of-Concept（PoC）がつく。「理論上の危険性」ではなく「こうすれば実際に突破できる」を示してくれるので、修正の緊急度を判断しやすい。

CI/CDに組み込める

Strixがただのスキャナと違うのは、開発ワークフローに溶け込む設計になっている点だ。

GitHub ActionsやGitLab CIに組み込めば、プルリクエストごとに変更されたファイルだけを対象にした高速スキャンが走る。-nフラグでノンインタラクティブモードに切り替えると、脆弱性が見つかった場合にゼロ以外の終了コードを返す。CIパイプラインが自動で止まる仕組みだ。

これは素直にいい設計だ。セキュリティチェックを「リリース前に手動でやるタスク」から「コードを書くたびに自動で走る仕組み」に変える。DevSecOpsを実践したいが、専任のセキュリティエンジニアがいないチームにとっては理想的なアプローチだろう。

セットアップは簡単、ただし条件あり

インストールは1行だ。

curl -sSL https://strix.ai/install | bash

ターゲットディレクトリを指定してスキャンを実行する。

strix --target ./app-directory

ただし、動作にはDockerと、対応するLLMのAPIキー（OpenAI、Anthropic、Google等）が必要になる。LLMのAPI料金はユーザー持ちだ。フルスキャンを実行すると、エージェント間のやり取りでトークン消費がそれなりに大きくなる可能性がある。具体的な料金は公式に明示されていないが、APIの従量課金という構造上、大規模なアプリケーションに対してフルスキャンを毎日回すのは現実的ではないだろう。

ライセンスはApache-2.0。コードはPythonで書かれており、全体の92.6%を占める。

気をつけるべき点

まず前提として、AIが見つける脆弱性がすべてではない。ビジネスロジックの深い部分や、アプリケーション固有のコンテキストを必要とする脆弱性は、現時点のAIでは見落とす可能性が高い。人間のペンテスターの代替ではなく、補完だと考えたほうがいい。

次に、このツールは実際にアプリケーションを攻撃する。テスト環境で動かすのは当然として、本番環境に向けて実行するのはリスクが大きい。データを壊したり、サービスをダウンさせたりする可能性がある。

また、オープンソースであるがゆえに、攻撃者側がStrixの動作パターンを研究して回避策を練ることも考えられる。防御側と攻撃側の両方に開かれたツールだ、ということは意識しておくべきだろう。

最後に、41,000スターという数字は印象的だが、プロジェクト自体はまだ若い。長期的なメンテナンスや、脆弱性パターンのアップデート頻度がどうなるかは不透明だ。

バイブコーディングの時代にこそ必要になる

Strixが注目を集めている背景には、2026年のAIコーディングブームがある。

LovableやBolt、v0、Cursorのようなツールで「バイブコーディング」——AIにコードを生成させる開発スタイル——が急速に広がっている。だが、AIが生成したコードのセキュリティは誰が保証するのか。生成されたコードの中にSQLインジェクションの脆弱性が紛れ込んでいても、コードの中身を細かくレビューしない開発者は気づかない。

ここにStrixの出番がある。AIが書いたコードを、別のAIがハッカーの視点で攻撃する。バイブコーディングとStrixを組み合わせれば、「書くのもAI、チェックするのもAI」という開発サイクルが成立する。

さらに、Strixのレポートには修正ガイドが含まれている。脆弱性を見つけるだけでなく、どう直せばいいかまで提示してくれる。この修正提案をCursorやClaude Codeに渡せば、修正作業そのものもAIに任せられる。発見→報告→修正のループが人間の手を離れる日は、思ったより近いかもしれない。

ただし、これは「AIが万能になった」という話ではない。AIが見つけられる脆弱性のカバー率が十分に高くなったとき、初めてこのサイクルは実用になる。現時点では、Strixのスキャン結果を過信せず、重要なリリース前には人間のレビューを入れるのが妥当だろう。

セキュリティテストの民主化を本気で進めようとしているプロジェクトだ。専門家を雇えないチームにとっては、ゼロよりはるかにいい。