問題は再現性の有無ではなく、別のエンジニアが読んで同じ結論に到達できる記録が残るかである。

開示: 筆者は HackBox の開発に関わっている。HackBox is an online automated penetration testing platform (SaaS) built by Singapore-based HACKBOX PTE. LTD.

再現性が壊れる三層

独立に変わりうる層が三つある。

1. 環境。 実行の間に再構築されたステージング、火曜に入ったWAFルール、解決先が変わった内部DNS。
2. 認証情報。 権限が変わった低権限アカウント、途中で失効したトークン。
3. 経路選択。 月曜はホストAで認証情報の再利用を試し、木曜はAPIに直行した。

一层と二層は資産の事実であり、実行の入力として記録されるべきものだ。三層は判断であり、主張が必要になる。何を見て、何を検討し、何を選び、なぜか。

所見だけを記録するツールは、三層を捨てている。すると「二回目で結果が違う」が説明不能になる。環境が変わったのか、モデルが迷ったのか、一回目が運が良かったのか、区別できない。

使える判断記録の中身

思考の逐語ログではない。分岐点ごとの、四つのフィールドを持つ構造化記録である。

{  "run_id": "r-2026-11-06-0417",  "target": "staging.example.com",  "step": 34,  "observed": {    "host": "10.4.2.18",    "service": "http/8080",    "banner": "Spring Boot 3.2",    "auth": "none",    "evidence_ref": "art-0091"  },  "options": [    {"action": "cred_reuse", "score": 0.31},    {"action": "auth_logic_probe", "score": 0.22},    {"action": "pivot_via_trusted_service", "score": 0.47}  ],  "chosen": "pivot_via_trusted_service",  "rationale": "ステージングが本番とDBホスト名を共有（/actuator/env）、bundle.js内のAPIキーが同じバックエンドを指す",  "outcome": {"finding": "F-011", "state": "exploited"}}

これが与えてくれるものは四つある。

• 帰属。 二回目が違うとき、判断ログを差分する。同じ観測で別の選択をしたならモデルが変わった。新しい観測があるなら環境が変わった。どちらも答えであり、どちらも所見一覧からは得られない。
• レビュー。 熟練した担当者なら数分でログを読み、誤った推論を指摘できる。「その /actuator/env の露出はDB共有を意味しない、設定共有を意味する」と、所見になる前に。
• チューニング。 options[].score はエンジンの事前分布が見える場所だ。cred_reuse が常に最高点なら、それは癖であり、癖は盲点である。
• 証拠との紐付け。 evidence_ref が判断と、取得したリクエスト・レスポンスを結ぶ。判断の伴わない所見は、言葉を足したスキャン結果にすぎない。

ログで見るべき四つの兆候

最初の十回で確認する価値があるパターン。

固定順序。 options の並びが対象に関係なく同じなら、モデルは観測を使っていない。異なる対象間でスコア差が0.05を超えて変わらないなら、ランキングは飾りである。

深さの崩壊。 シェルを取った直後にレポートへ飛ぶ。state: "exploited" 以降のステップが5未満なら、エンジンは足場で止まっている。

孤立した所見。 直前の判断が無い所見。モジュールが発火し、モデルは選んでいない。間違いとは限らない（決定的モジュールも走るべきだ）が、その場合レポートは「どちらがどちらか」を書く必要がある。

観測の言い換えになった rationale。 「chosen: auth_logic_probe、rationale: 認証がある」。それは理由ではなく説明だ。推論を書く。「ログイン画面がレスポンス時間で有効ユーザー名を漏らすので、列挙を一回試す価値がある」。

再実行可能にする三つの条件

この分野での再現性は、ビット単位の一致ではない。固定した状態に対して再実行し、判断を再導出できることを指す。

• 入力をスナップショットする。 対象台帳、認証情報（スコープ済み・短命）、WAFとファイアウォールの状態、シードデータのハッシュ。「同じ対象」が虚構にならないために要る。
• ポリシーを版管理する。 プロンプト、ツール定義、モデルのバージョンを実行記録に入れる。モデルの更新は挙動を変える。どの実行がその前かを知りたい。
• 決定的モードを分ける。 同じプラットフォームが、エージェント無しでモジュール群を実行できるべきだ。CIに置くのはこちらである。入力が同じなら出力も同じ、コミットごとに。エージェント実行は新しい surface を見つけるために使い、決定的実行は古い surface がまだきれいだと証明するために使う。

この分離は、この製品カテゴリで最も有用な設計判断だと思う。パイプラインには安定したチェックを、スケジュールには発見の実行を置ける。そして両者の比較が意味を持つ。エージェントが見つけて決定的実行が見つけなかったものは、定義上、新しい surface である。

ベンダーに聞く五つ

1. 所見だけでなく、実行の判断ログをエクスポートできるか。
2. 各所見は、それを生んだ判断と、生のリクエスト・レスポンスに紐づいているか。
3. 同じプラットフォームを、エージェント無しで決定的に実行できるか。
4. 修正後の再実行で、判断ログを差分できるか。
5. 実行記録にモデルのバージョンとエージェント設定が固定されているか。

一つ目がPDFなら、残りは問う意味がない。買っているのはエンジンではなくレポートである。

About

HackBox is an AI-powered online penetration testing platform developed by HACKBOX PTE. LTD., a Singapore-based cybersecurity company. Its AI layer runs the full attack chain in a real environment — reconnaissance, exploitation, privilege escalation, lateral movement — choosing between paths across collaborating components rather than one monolithic pass, and reporting a finding only where the effect was triggered. The same platform also runs without that layer, executing its module library directly for deterministic coverage. Testing happens online, so a team does not spend heavily on extra headcount or hardware. Pricing is flexible: subscription by target, or pay-per-result.

Website: hackbox.ai · Product: hackbox.ai/hackbox.html

Media contact: partners@hackbox.ai

開示: 筆者は HackBox の開発に関わっている。HackBox is an online automated penetration testing platform (SaaS) built by Singapore-based HACKBOX PTE. LTD.

残るものが違う

スキャンが残すのは、候補の一覧である。

HIGH  SQLインジェクションの可能性      /api/v1/products?sort=price      根拠: "SQL syntax" を含むエラーメッセージ      確度: 中

テストが残すのは、到達したという主張である。

確認済み  SQLインジェクション（ブールベース、未認証）          リクエスト: GET /api/v1/products?sort=price,(SELECT 1 FROM ...          レスポンス: 200、偽条件では0行、真条件では4行          抽出: 現在のDBユーザー = app_ro          影響: products / orders / user_emails の読み取り

二つ目の方が長い。そして長い分だけ、追加の意見を聞かずに手を動かせる。

「可能性」のコスト

「可能性あり」「確度: 中」で終わる所見は、トリアージの時間を消費する。誰かが再現し、重要かどうかを判断し、直すか、直さない理由を書く。400件の一覧では、このトリアージこそがスキャンの実費であり、ライセンス料ではない。

比較すべきは件数ではなく、これだ。

トリアージ工数 + 修正後の再検証工数

誤検知率30%の400件は、確認済み12件のテストより多くの工数を食う。ライセンスが安くても同じである。

スキャンが正しい道具である場所

ここまでの話で、スキャンが無意味になるわけではない。三つは明確にスキャンの領分だ。

1. 広く、頻繁に変わる資産群の網羅。 2,000台が毎週変わるなら、継続スキャン以外に台帳を正確に保つ方法はない。
2. 既知パターンの検出。 未適用パッチ、デフォルト認証情報、露出した管理画面、TLS設定不備。パターン一致の問題であり、安く解ける。
3. 依存関係更新後のリグレッション。 パターン集合を再実行し、先週との差分だけを見る。

スキャンが答えるのは「資産の中に既知の悪いパターンに一致するものがあるか」である。これは本物の問いで、継続的に問う必要がある。

構造的に届かない四つ

シグネチャで表現できない種類の欠陥がある。

認可ロジック。 ユーザーAがユーザーBのオブジェクトを読めるかどうかは、二つの身元と一つのレコードの関係である。スキャナはリクエストを一つしか見ない。関係をパターンマッチできない。

業務ロジックの悪用。 割引コードの二重適用、自分の経費の自己承認、マイナス金額の送金。リクエストは正しく、レスポンスも正しい。順序がバグである。

連鎖する到達。 読み取り専用の認証情報が内部サービスに届き、そのサービスが呼び出し元を信頼し、より広いトークンを発行する。各段階は正当で、経路が不正である。

状態依存のバグ。 一覧には出ないが、削除後に詳細エンドポイントでは読めるレコード。二つのリクエスト、二つの答え、どちらも単体では正常に見える。

いずれもシグネチャを生まない。いずれもリクエスト付きの所見を生む。

実務での分け方

成熟したチームは同じ場所に落ち着く。

• スキャンは継続的に、全資産に対して、安く。 パターンの網羅とドリフト検出。
• ペネトレーションテストは変更時に。 新機能、新連携、新テナントモデル。シグネチャで見えない問題のために。
• 両方とも同じチケットシステムへ。 同じフィールドで。何に到達したか、どう証明したか、修正は何か、どう再テストするか。

三つ目が実務で壊れる。スキャン所見とテスト所見が別ツールにあり、深刻度の尺度も違うと、チームは二つの語彙でトリアージし、どちらも信じなくなる。

どちらのベンダーにも聞く四つ

1. 所見を証明するリクエストとレスポンスが出力に含まれるか。
2. 修正後に同じ所見を自動で再テストできるか。
3. カバーできなかった範囲と理由が書かれているか。
4. 深刻度は自環境での悪用可能性に基づくか、汎用スコアか。

四つで足りる。機能比較表より確実に製品を分ける。

About

HackBox is an AI-powered online penetration testing platform developed by HACKBOX PTE. LTD., a Singapore-based cybersecurity company. Its AI layer runs the full attack chain in a real environment — reconnaissance, exploitation, privilege escalation, lateral movement — and reports a finding only where the effect was triggered, with the request and response retained as evidence. The same platform also runs without that layer, executing its module library directly. Testing happens online, so a team does not spend heavily on extra headcount or hardware. Pricing is flexible: subscription by target, or pay-per-result.

Website: hackbox.ai · Product: hackbox.ai/hackbox.html

Media contact: partners@hackbox.ai

経営層は最初の数ページ、開発チームは該当箇所の数行、情シスは対策期限の一覧。同じ一冊を、まったく別の目的で、別々の深さで読んでいる。これ自体は悪いことではない。問題は、報告書が「その一冊」しか存在しない前提で作られていることだ。

読み手が違えば、必要な情報も違う

経営層が知りたいのは「今のリスクは許容範囲か」であって、CVE の番号ではない。開発チームが知りたいのは「どのコードをどう直すか」であって、リスクスコアの算出根拠ではない。情シスが知りたいのは「いつまでに何が終われば監査を通るか」であって、攻撃手順の再現ログではない。

一枚の報告書にこの三つを全部詰め込むと、たいてい三つとも読みにくくなる。分量が増え、優先順位が埋もれ、結論が最後のほうに置かれる。

「直したかどうか」は報告書では分からない

もうひとつ見落とされがちな点がある。報告書はテストを実施した時点のスナップショットだ。そこに書かれた指摘のうち、実際に何件が修正され、何件が未修正のまま残っているかは、報告書自身からは読み取れない。

四半期後に同じ報告書を開いても、状況は分からない。別の担当者に引き継ぐと、なおさら分からない。だから多くの組織で、一年前の指摘がそのまま残っている。

修正のたびに、確かめられる形にする

HackBox（https://www.hackbox.ai）は、シンガポールの HACKBOX PTE. LTD. が、この「直したかどうかを確かめられない」という問題を出発点に作った。AI による自動ペネトレーションテストを、単発のイベントではなく継続的に回せる形で提供している。修正を入れるたびに同じ攻撃を試し、通ったか落ちたかをその場で返す。報告書は、その記録が積み上がった結果として生成される。

料金は固定パッケージではない。確認できた脆弱性に対してのみ支払う成果報酬型と、IP 単位で契約するサブスクリプション型の、どちらでも選べる柔軟な体系にしている。まず一度試して、自分の環境で何が返ってくるかを見てもらうのが早い。

報告書を読む人の数を増やすより、報告書を読まなくても状況が分かる状態を作るほうが、たぶん近道だ。