AIペンテストは何をするのか — デモで、設定から証拠まで通しで見る

「AIにペンテストを任せて大丈夫なのか。人がやるのと何が違うのか」。これは必ず聞かれる。答えを一言で言えば、AIペンテストの強みは「やったことが全部残る」ことにある。どのエンドポイントを、どんな仮説で叩き、通ったのか通らなかったのか。人手の診断では報告書の結論だけが残り、過程はテスターの頭の中に消えることが多い。ここでは Aikido のデモ環境を使い、設定から証拠まで通しで見ていく。

最初に断っておく。以下で使う Pokedex Depot（Web のマーケットプレイス）と VaultPay（Android の決済アプリ）は、Aikido が検証用に意図して脆弱に作ったベンチ用アプリだ。だから Critical が何件、といった件数は普通のアプリの相場ではない。見てほしいのは件数ではなく、仮説の立て方、穴の潰し方、そして見せ方だ。

設定は8ステップのウィザード

セットアップは8段階で、順に埋めていくだけだ。

1. 対象を選ぶ：Web アプリのほか、Android アプリ、AI 機能だけ（エージェントや LLM 機能）、Lovable、Supabase から選べる。AI を組み込んだアプリや Android アプリも同じ土俵でテストできる。
2. スコープ：エントリポイントの URL を入れ、全体か特定部分かを選ぶ。
3. テストユーザー：Google / Microsoft / ID+パスワード / API キー / Magic Link / Custom に対応。「権限ごとに1人ずつ（Admin/Manager/Viewer）足せば権限昇格を試せる」「2テナント分入れればテナント越境を試せる」と画面が誘導してくる。
4. 許可ドメイン：Attackable と Accessible を分けて設定する（後述）。
5. コード連携：リポジトリを繋ぐとホワイトボックスになる。
6. 安全設定：秒あたりリクエスト数の上限と、実施時間帯（即時／業務時間内／時間外／週末）、タイムゾーンを設定する。
7. 深さ：テストの深さを設定する。
8. 確認して実行：設定内容と検証状態を確認して実行する。

テストユーザーの作り方（Google ログイン＋2FA など）は手順が要るので、別記事で扱う。

勝手には攻撃させない

AI に攻撃させる、と聞くと身構える。実際は逆で、範囲外に手を出せない仕組みが何段も入っている。

ドメイン検証が必須。対象ドメインの所有を、CNAME か TXT レコード、または aikido.txt の設置で証明しないと、最後の「Run Assessment」が押せない。未検証のまま確認画面に進むと「Configuration errors detected」で止まる。他人のサイトを勝手に攻撃させない、という一番大事な歯止めがここにある。

許可ドメインは2段。Attackable（実際に攻撃する）と Accessible（動作確認で接続するが攻撃はしない）を分け、それ以外への通信は遮断される。認証プロバイダやタグマネージャは Accessible に、本体だけ Attackable に、という切り分けができる。

負荷も絞れる。秒あたりリクエスト数の上限と、業務時間外・週末といった実施時間帯を指定できる。本番に近い環境でも、影響を抑えて走らせられる。

仮説を立てて、潰す

実行が始まると、多数のエージェントがそれぞれ独立した仮説を持って動く。Pokedex Depot では60、VaultPay では42のエージェントが立った。

一覧には「Starting assumption（何を疑うか）／対象ファイル／脆弱性の型／担当エージェント／結果」が1行ずつ並ぶ。たとえば「read_file ツール経由で任意ファイル読み取りができるか」「X-User-Id ヘッダの改ざんで認証を回避できるか」といった具合だ。そして結果は Exploitable（通った）か No issues found（通らなかった）で記録される。

この「試したが通らなかった」が残るのが効く。カバー範囲が見えるということだから、「何も出なかった」にも根拠が付く。人手の「特に問題なし」より検証可能だ。

本当にログインしてから攻める

攻撃の前に Preflight が走る。渡したテストユーザーで実際にログインできるかを、スクリーンショット付きで確認する工程だ。Pokedex Depot の例では32秒で「Sign Out / My Products / MERCHANT バッジの存在で認証成功を確認」まで記録していた。

認証設定が間違ったまま攻撃に入れば「何も出ない」のは当たり前になる。それを先に潰してから本番に入る。

見つけて、終わりにしない（その1：昇格）

穴を一つ見つけて報告して終わり、ではない。Pokedex Depot の password-reset の例では、まず自分で作ったアカウントで「トークン無しでパスワードを変えられる」ことを実証し、続いて同じ手口を組み込みの ADMIN アカウントに向け、管理者セッションを奪って /admin に到達するところまで自動で深掘りしていた。

この昇格の結果、重大度が自動で引き上げられる。ダッシュボードには「Upgraded: Escalation proved deeper impact」と痕跡が残り、Medium だった評価が Critical に上がっていた。影響を実証したうえでの格上げなので、根拠がある。

見つけて、終わりにしない（その2：再テスト）

修正したら、もう一度同じ攻撃をかけて答え合わせができる。Retest では PoC のコードと「Observed Result（実際にどうなったか）」が付き、Pokedex Depot の例では「まだ通る（still exploitable）」ことを確認していた。修正したつもりが直っていない、を機械的に検出できる。

証拠が verifiable

一つひとつの証拠が具体的だ。Request Log の詳細を開くと、1リクエストが Method / Duration / Response コード / リクエストヘッダ / ペイロード / そのまま実行できる curl コマンドまで展開される。CSRF トークンを実際に取得して正規のフローを踏んでいることも読み取れる。

そして全リクエストの User-Agent に aikido-pentest-agent/1.0 (Agent <UUID>) が入る。これで自社の WAF や SIEM のログと突き合わせられる。「Aikido が見た結果」と「自社が受けた記録」の両方が残るのは、人手の診断ではまず得られない。

Request Logs の総量も見える。Pokedex Depot で約5万件、VaultPay で5,380件。単純なエンドポイントは数件、複雑なところは数千件と、リクエスト数の偏りがそのまま「どこを深く叩いたか」を表す。

出力を出し分けられる

レポートは相手に合わせて5種類から選べる。外部共有向けにスタック詳細を伏せた Simplified Auditor、全指摘と技術詳細と修正履歴まで載せた Detailed Auditor、経営向けの High Level Management、修正の進捗を示す Post-Remediation、そして RFP やデューデリ向けに「ペンテストを実施した事実」だけを示す Letter of Attestation。監査・経営・取引先で、同じテスト結果を使い分けられる。

値段は、おまけだ

機能を見たうえで、最後に値付けに触れておく。テストの実行はクレジット制の有料だが（見積もりとアカウント作成は無料）、初回だけは「Run now, pay later」が使える。保留クレジットを立てて走らせ、条件を満たして High/Critical の指摘が一件も出なければ、その保留分は免除される。

条件は、そのワークスペースで最初のフル評価であること（アプリごとではなく、顧客アカウント単位で一度だけ）・8,000クレジット以下・稼働リポジトリの連携・テストユーザー2つ以上・仕事用メール・設定が正しくテストできる状態だったこと、を全部満たすこと。2回目以降と再テスト、Continuous Pentesting、単一機能に絞ったスコープテストには適用されない。Medium/Low の指摘で「Exploit Further」が使えたのに使っていない場合も、High/Critical に上げられたはずと判断されれば免除されないことがある。詳しい仕組みは別記事にまとめる。

裏返せば、支払いが発生するなら、少なくとも High/Critical の問題が実際のテストで確認されたということだ。予算の説得材料として、これ以上のものはない。

やるかやらないかは、貴方次第。