「うちのシステム、大丈夫?」
2026年秋になって連日報道される情報漏洩、サイバー攻撃問題。
顧問先や取引先から、こんな心配の声、脆弱性診断の依頼をいただいています。
その不安は、残念ながら現実的です。ランサムウェア被害の多くは中小企業で、入口の大半は「インターネットに公開しているサイトや機器の弱点」です。そして今、その弱点を探す側がAI を使い始めています。
生成 AI で攻撃コードを組み立てる、AI に脆弱性スキャンを自動で走らせる、ごく自然な日本語でフィッシングメールを量産する——攻撃の自動化・高速化は確実に進んでいます。
一方、防ぐ側の従来のやり方はどうでしょうか。
- 商用の脆弱性診断サービス: 高品質ですが、詳細診断で数万〜十数万円、結果が届くまで数営業日
- 無料の検査ツールを手で回す: ツール自体は無料でも、出力は英語・技術用語だらけで「うちのシステム、大丈夫?」への答えにならない
攻撃者が AI で高速化しているのに、こちらが「月に一度の手動スキャン + 英語レポート」では追いつくことはできません。
1. 攻撃側はもう AI を使っている——だから「AI には AI を」
脆弱性と言われても、どこにどんな”セキュリティの穴”があるのか？脆弱性があったら具体的に何をすればいいのか？
セキュリティの専門家にしかわからない。しかしそんな専門家は身近にはいない。。。
そこで叫ばれるようになっているのが、「AI には AI を」です
攻撃者に見つかる前に、自分のサイトの弱点を AI で見つけ出し、誰にでも分かる言葉で伝える。
AI(AI ペンテスター)に攻撃者の視点で診てもらい、セキュリティの穴を見つけ、どんな対応を取ればいいのかを提案してくれるツールを作ってみました。いわば「AI で AI の攻撃に先回りする」仕組みです
2. 作ったものの全体像
- Web インターフェース(ブラウザから操作)
- 複数サイトを登録 → ワンクリックでテスト開始
- 実行中は経過時間と「今何をやっているか」をリアルタイム表示
- 診断履歴・前回との比較・レポート保存
- 検査ツールの統合(3つのテストに整理)
| # | テスト | 内容 | 目安 |
|---|---|---|---|
| ① | 外部スキャン | ヘッダー/DNS/TLS/技術識別/WordPress/公開パス(自作 Python 層) | 約2分 |
| ② | CVE 監査 | Nuclei(既知脆弱性テンプレート)+ WPScan(WordPress 専用 DB) | 10〜25分 |
| ③ | Strix 動的テスト | AI ペンテスター(Strix)が実際にリクエストを送って検証 | 5〜30分 |
- 日本語レポート生成エンジン
- どこまで対応・放置するとどうなる・対策・修正案・技術的根拠の5項目形式
- 総合評価は A〜E / 100点(長期変動の見える化)
- 重要度・CVE/CWE/CVSS に応じた日本語のリスク説明を自動生成
3. 技術スタック
| 部品 | 採用 |
|---|---|
| Web アプリ | Python / FastAPI + SQLite(ローカルのみ・127.0.0.1 バインド) |
| UI | 単一 HTML + 素の JavaScript(ダークテーマ・日本語) |
| 検査エンジン | 自作 Python レイヤー / Nuclei(Docker)/ WPScan(Docker)/ Strix CLI(Docker サンドボックス) |
| AI(LLM) | OpenRouter 経由でモデルを自由に切替(Anthropic / OpenAI / Google など) |
| 運用 | run.bat 一発起動 / Linux Mint 22.3 + Docker Desktop |
4. 導入ステップ
Step 0: 前提の準備
- Docker Desktop をインストール(Nuclei・WPScan・Strix のサンドボックスすべて Docker で動かすため)
- Strix CLI を導入(自動ペネトレーションテスト用)
curl -sSL https://strix.ai/install | bash - API キーの準備（弊社ではOpenRouterを用いています）
- WPScan の API トークン(任意・無料で1日25回。WordPress の脆弱性 DB 照合に使う)→ https://wpscan.com/register
Step 1: プロジェクトを配置・起動
C:\SecuRangerSuite\
run.bat / requirements.txt
config\allowlist.txt ← 書面許可を得たサイトの許可リスト
app\ ← FastAPI 本体・レイヤー群
data\ ← SQLite DB / nuclei テンプレート
runs\ ← テスト実行ログrun.bat の中身(初回は venv 作成+依存インストールが自動で走る):
@echo off
chcp 65001 >nul
cd /d %~dp0
if not exist .venv (
python -m venv .venv
.venv\Scripts\python -m pip install -q -r requirements.txt
)
.venv\Scripts\python -m uvicorn app.main:app --host 127.0.0.1 --port 8092ダブルクリック → ブラウザで http://127.0.0.1:8092 を開きます。
Step 2: 設定(1回だけ)
⚙ 設定画面で以下を入力:
- OpenRouter API キー — 未入力なら Strix 既存設定(
~/.strix/cli-config.json)をそのまま使う - モデル — 「モデル一覧を取得」で 価格付き一覧(入力$/出力$/キャッシュ読込$)が表示され、行クリックで選択。
例:Anthropic: Claude Sonnet 4.6 - WPScan API トークン — 任意。未入力なら無料範囲(限定的な DB)で動作
Step 3: 許可リストと承認チェック
顧問先サイトの診断は書面で許可を得たサイトだけという運用を、ツール側で強制しています。
config/allowlist.txtに登録されたドメイン/IP のみテスト可能(ドメインはサブドメインも許可)- テスト開始時に許可書の ID・日付の入力が必須(サーバー側で強制。許可リスト外は 403、ID なしは 400 で拒否)
- この ID はスキャン記録とレポート(Markdown 冒頭「承認(書面許可)」)に残り、監査に使えると思います。
Step 4: サイト登録 → テスト実行
- 「＋ サイトを登録」から名前・URL を入力(認証テスト用に WordPressなどの場合、ユーザー名/パスワードも任意で登録可)
- サイト行のボタンからテストを選択 — ①外部スキャン(約2分)/ ②CVE監査(10〜25分)/ ③Strix動的(5〜30分)
- 実行中はライブで「経過時間 + 現在の処理(例:『REST API のユーザー列挙を確認中』)」が表示されます。画面を閉じても完了まで続きます
Step 5: 日本語レポートを読む
完了すると、各指摘が 5項目の日本語で表示されます。
- どんな問題があるか — 何が起きているか
- 放置するとどうなるのか — 攻撃に使われたらどうなるか(重要度・種別ごとの具体的リスク)
- 対応方法は — まず何をするか(緊急/高/中/低で期限感も表示)
- 修正案 — 具体的な修正(例: アップグレード対象バージョン、
.htaccessの追記例) - 技術的な根拠 — CVE / CWE / CVSS / 検証した URL などのエビデンス(技術者向けにそのまま残す)
経営者向けの要約は前の4つ、技術者向けの裏取りは5番目という構成にしてみました。
レポートは MarkdownはもちろんWord形式でも保存・印刷できるようにしました。
5. 実際に動かして分かった「誤検知」という壁
実サイトの診断で、大きな落とし穴がありました。
事象: /shell.php や /backup.sql などが「すべて HTTP 200 で検出」→ レポートは「緊急5件・高8件」の惨状に。
原因: 本番サイトの WAF/リバースプロキシが存在しないパスにも 200 + 同じページ(5569バイト)を返す(通称ソフト404)ため、検査ツールが「全部ある」と誤判定していました。
対策: 存在しないパスで「404 ページのベースライン」を取り、200 応答がベースラインと一致したら誤検知として除外する処理を実装。同じサイトが 14点(E判定) → 98点(A判定) に改善し、残った指摘は実在するものだけになりました。
学び: スキャナーの結果は「200 が返った = 存在する」ではダメ、誤検知のフィルタが必須です。レポートには除外件数も明記しています。
6. 運用上、決めたこと
- 平日のさっと確認は①外部スキャン(2分)で。月次での監査は②CVE監査、深掘りは③Strix動的と使い分ける。
- LLM 費用は予算上限で抑止(テストごとに予算 USD を設定可能にしました）。
- Nuclei/WPScan は破壊系タグは除外・passive モード・レート制限で安全側に設定。それでも共有サーバーでは深夜帯に実施することにしています。
- WPScan の無料 API は1日25回制限。残り5回以下になると画面上にアラートが出るようにしました。
- 「検出なし = 絶対に安全」ではないので、定期的な再テスト(例えば月1回)を行う仕様に。
- 誤検知は必ずあり得るため、修正の実施前に担当者が実機を確認する運用を忘れずに行う。
実は、AI ペンテスター(Strix)は脆弱性を発見した後、修正方法の提案どころか、修正の実施に至るまで自動で進めることができます。
ただし今回のツールでは、そこまでは行わないようにしています。診断は AI とツールに任せ、修正は必ず人が実施・確認する——これが私たちの方針にしています。理由は次の3つです。
- 誤検知が必ずあるから。前章のソフト404のように、自動診断には「見つかった」と誤って判断するケースがつきものです。機械がそのまま「修正」に進めば、実際は存在しない脆弱性に反応して正常な機能を壊すことになりかねません。人の目でちゃんと確認することにしました。
- 修正は「技術」ではなく「判断」が中心だから。影響範囲の確認、リスク受容の判断、費用対効果、本番適用のタイミング——これらはそのサイトの事情を知る人間にしかできません。AI が提案した修正案を、人が裏取りして適用するのが理想的な分担だと思います。
- 守る文化をつくるため。修正はレビューと変更管理と再確認(再診断)をセットにするのが定石です。全部を自動化してしまうと、その習慣が育ちません。
AI・ツールが指摘を発見 → 人がレポートを確認・実機で裏取り → 人が修正を実施 → 再診断でスコア改善を確認(前回比較機能)
「AI には AI を」——AI には攻撃者と同じ速さで弱点を見つけ出す役を、人が確実に穴をふさぐ役を。
この分担をするようにしました。
7. 診断実施に当たって遵守している事項(前・中・後)
脆弱性診断は「見つけること」だけでなく、対象システムの可用性を保ち、データを壊さず、第三者に影響を出さないことが前提です。当方では次の遵守事項を定め、すべての診断の前・中・後に適用しています。
診断実施前——スコープと環境の確定
- スコープの再照合: 診断の対象指定(URL・IP レンジ)が、承諾書に記載された範囲と完全一致しているかをダブルチェックする
→ 本ツールは 許可リスト(allowlist)+ 許可書ID(承認チェック)で、この照合をテストごとにサーバー側で強制しています - 送信元 IP の固定と通知: 診断端末の送信元 IP を固定し、顧客側の監視・運用チーム(SOC・MSP 等)へ事前に周知する
→ 本ツールは 127.0.0.1 バインドのローカル実行なので、送信元は原則社内端末に固定されます - バックアップの確認: 診断開始前に、顧客側で DB およびシステム全体の最新バックアップが取得されていることを確認する
- WAF/IDS の調整確認: 脆弱性そのものを正しく検出できるよう、必要に応じて WAF の検知除外・ホワイトリスト登録が完了しているか確認する
診断実施中——負荷制御と破壊的行為の防止
- リクエストレートの制御: スキャンツールの同時接続数・秒間リクエスト数(RPS)に上限を設け、CPU 高騰やサービス遅延(DoS 状態)を回避する
→ 本ツールは Nuclei を 10 req/s 固定・WPScan をスレッド 2 かつ passive で実行します - 破壊的テスト・データ変更の禁止: DROP / DELETE 等の不可逆な SQL インジェクションや、本番データの消去・更新を伴うパラメータ送信を行わない
→ 本ツールは 破壊系タグ(intrusive / dos / fuzz / bruteforce / rce / sqli 等)をテンプレートから除外しています - メール大量送信の防止: 問い合わせフォーム・パスワードリセット機能の検証時は、実在する第三者のメールアドレス宛に大量送信されないよう、検証用のアドレス・ドメインに限定する
- 深追いの禁止(PoC の最小化): 侵入・権限昇格が可能と判断できた時点で検証を止め、無関係な機密情報の閲覧・ダウンロードや他ノードへの横展開(ラテラルムーブメント)は行わない
- 異常検知時の即時中断: HTTP 5xx の連続発生・極端な応答遅延・顧客からの連絡があった場合は、直ちにすべての診断通信を停止する
→ 本ツールは画面の「中止」ボタンで実行中のプロセス・コンテナを即時停止できます
診断完了後——原状復帰と安全管理
- テストデータのクリーンアップ: 診断用に追加したテストアカウント・投稿データ・セッション情報・検証用ファイル(PoC コード含む)を確実に削除する
- 完了通知と防御設定の復旧: 診断終了を顧客へ速やかに連絡し、一時的に緩和・停止していた WAF やアクセス制御ルールを本番稼働状態に戻してもらう
- 発見した脆弱性情報の厳重管理: 取得した診断ログ・画面キャプチャ・再現手順等のデータは暗号化して保管し、安全な経路(暗号化通信・パスワード保護等)で顧客へ納品する
→ 本ツールはローカル専用で、レポートは Markdown としてサイトごとに管理できます。レポート冒頭に承認(書面許可)の ID・日付が残るため、納品物の出所を追跡できます
8. まとめ
攻撃側はもう AI を使っています。ならば防ぐ側も——「AI には AI を」。攻撃者に見つかる前に、自分たちの手で弱点を見つけ出し、誰にでも分かる言葉で伝える仕組みを整えました。
- 検査ツール(Nuclei / WPScan / Strix など)を1つの Web 画面に統合し、ワンクリックで実行
- AI ペンテスター(Strix)による動的テストで、攻撃者の視点に立った検証を自動実行
- 英語・技術用語の出力を、日本語の5項目レポートに変換し、経営者〜技術者まで読める形に
- 書面許可 + 許可リスト + 承認記録で、IPA ガイドラインに沿った運用が技術的に強制される作りに
- 商用サービスと比べると、費用は LLM 代のみ。ただし人的レビューや第三者としてのお墨付きは商用サービスの価値なので、必要に応じて使い分けが現実的
「うちのシステム、大丈夫?」——その答えは、攻撃者に見つかる前に、AI に診てもらって、見つかった脆弱性をすぐに修正することだと思います。
悪用厳禁：Strix は攻撃(ハッキング)にも使えるツールです。
Strix は、本来セキュリティ診断のために開発された AI ペンテスターですが、裏を返せば他人のシステムを攻撃することも可能となるものです。当方が「AI には AI を」と書いてきたのは、あくまで攻撃者に見つかる前に自社サイトの弱点を発見するためです。逆の使い方をすると、次の犯罪になります。
日本の不正アクセス行為の禁止等に関する法律(平成11年法律第128号)は、第3条で「何人も、不正アクセス行為をしてはならない」と定めています。
同法第2条第4項の「不正アクセス行為」とは、
・他人の識別符号(ID・パスワード)を無断で入力してログインする行為(同項1号)
・アクセス制御機能による制限を免れる情報・指令を入力して突破する行為、すなわち「セキュリティホール(脆弱性)を突いて侵入する」行為(同項2号・3号)を指し、違反者は3年以下の拘禁刑または100万円以下の罰金に処されます(第11条)。
重要なのは、同法が「アクセス管理者(サイト所有者)自身が行うもの、およびその承諾を得て行うものは除く」(第2条第4項)と明確に書いていることです。つまり、今回紹介した許可書ベースの診断運用(許可リスト+承認チェック)は、まさに法律が想定する正当な使い方です。
逆に、許可のないサイトへの診断・攻撃は、たとえ「テスト目的」「AI がやった」であっても犯罪となり得ます。
Strixの悪用は犯罪となります。この記事で紹介したのは、責任を持って守るための使い方だけです。
コメント