AIペンテストの選び方｜許可範囲・評価指標・報告書の確認項目

AIペンテストを導入するか迷ったら、ツールの速度や検出件数から決めないでください。最初に決めるべきことは、何を守りたいか、どこまでの検査を許可するか、見つかった問題を誰が直すかです。AIを使う検査でも、対象の権利関係、本番への影響、証拠の扱い、報告後の再確認には人の責任が残ります。本記事は、Webサイト・API・社内AIを持つ企業が、外部委託または社内導入の可否を判断するための手順を示します。具体的な侵入手順や攻撃コードは扱いません。

話題となったヒューマンハッカー社の検証は、意図的に弱点を設けたローカルの学習用アプリと自作ポータルを、合成データで調べた自己報告のデモです。限られた条件で自動化の可能性を考える材料にはなりますが、一般的な本番サイトでの成功率、従来の診断より優れている割合、導入費用の相場を示す統計ではありません。自社の調達判断ではデモの数字を宣伝文句として採用せず、検査範囲と成果物を明確にしてください。

AIペンテストを導入すべきか――目的と対象の決め方

ペネトレーションテストは、許可された範囲で実際の攻撃を想定し、どの弱点がどんな影響につながるかを検証する活動です。AIペンテストという語には、AIで結果を要約するだけのサービスから、AIエージェントが観測結果に応じて検査の次の操作を選ぶサービスまで含まれます。両者は安全管理も必要な監督の水準も違います。見積書で「AI使用」とだけ記載されている場合は、AIが決める工程、人が承認する工程、ツールが実際に行う操作を確認してください。

まず「何を確かめたいか」を一文にする

目的を「AI対策をしたい」と書くと、診断の成否を判定できません。「会員権限で他の利用者の情報が見えないことを確かめたい」「公開APIから顧客情報へ到達できる経路を洗い出したい」「AIエージェントが外部文書の指示で社内ツールを動かさないか確認したい」といった形にします。ひとつの契約でWebアプリ、ネットワーク、社内AI、従業員の対応力を同時に網羅するのは難しく、検査方法も異なります。

目的の次は、対象となるデータと業務です。顧客データの扱いを確かめたいなら、実際の個人情報を使わず、同じ権限関係を持つ架空の試験データで検査できるかを判断します。決済や予約のように本番の操作が業務へ直結する場合には、試験環境と本番で同じアクセス制御が働いているかを確認します。試験環境だけ綺麗で本番の設定が違うなら、試験結果から本番の安全性は結論できません。

通常の脆弱性診断と重なる範囲、重ならない範囲

自動診断は既知の検査項目を広く適用しやすく、開発サイクルへ組み込みやすい方法です。ペネトレーションテストは、許可された条件下で個別の弱点が業務上の影響にどうつながるかを確認することに重心があります。AIを組み込んでも、この役割は消えません。自動診断の結果を人が検証する工程や、業務ルールの解釈は必要です。どちらが一律に優れているかではなく、今回の問いに必要な検査を選びます。

たとえば更新漏れが多い状態なら、資産台帳とソフトウェア更新を先に整えます。会員間の権限境界に不安があるなら、役割別のテストケースを作り、専門家が結果を確認する検査を考えます。AIを組み込んだ新しい業務フローを公開する前なら、外部の文章を読み込む位置とツール権限の設計を点検します。既知の重大な欠陥を放置している段階で「AIペンテストに通れば安心」と考えるのは順番が逆です。

導入可否を決める三つの条件

第一に、対象資産の所有者と許可者が分かっていること。第二に、サービス停止やデータ変更を避ける制御を契約と運用の両方に設けられること。第三に、検出後に修正・再検査へ進める担当と予算があることです。どれかが欠けるなら、いきなり自律性の高い検査を行わず、資産棚卸し、設定点検、限定した手動レビューから始める方がよい場合があります。

現在の状態	先に行うこと	AIペンテストの位置付け
公開資産の所有者が不明	ドメイン・API・クラウドの台帳化	範囲を確定するまで保留
既知の重大更新が未適用	検証・更新・動作確認	更新後の残存リスク評価に使う
権限設計に不安がある	役割表と期待動作を準備	許可されたテストで影響を評価
社内AIの新機能を公開予定	入力源、ツール権限、承認点を整理	AI固有の境界も対象へ追加

この表は一般的な編集上の判断例です。法律や業界固有の規制の適用は別途確認してください。特に医療、金融、公共サービスなどで本番環境の停止許容度が低い場合は、所管部門とサービス提供元の条件を優先します。

三つの架空ケースで検査方法を選ぶ

以下はいずれも架空の企業例です。A社は企業紹介サイトと問い合わせフォームだけを運営し、会員機能はありません。課題はCMSの更新履歴が分からないことです。この場合は、まず資産とバージョンを確認し、問い合わせメールの到達やバックアップ復元を点検します。広範なAIペンテストより、既知の設定不備の解消が優先です。実施するとしても、更新後のフォームと管理画面の限定確認から始めます。

B社は会員制の予約サイトを運営し、一般会員、店舗担当、運営管理者の役割があります。会員が別の会員の予約情報を見られないか、店舗担当が他店舗の予約を変更できないかが重要な問いです。検査前に役割表と架空の予約データを準備します。AIを使う検査であっても、役割間の期待値を決めるのは事業と開発の担当者です。報告書では単なるエラーの数より、許可されていない閲覧・変更が確認されたか、どの条件では未確認かを重視します。

C社は社内のAIエージェントに営業資料の検索とメール下書きを任せています。現時点では送信権限がありませんが、将来は顧客管理ツールへの書き込みを検討中です。今行うべきは、外部文書が混ざる入力、検索できる機密情報、下書きの承認者、操作ログの確認です。書き込み権限を追加する前には、ツール側の権限を分け、架空文書とデータを使った評価を行います。既存のWebアプリ診断だけではAI特有の入力とツールの境界を見落とす可能性があります。

どの例でも、検査は安全を保証する儀式ではありません。予算が限られるなら、まず問題が見つかった場合に改修できる範囲へ対象を絞ります。分母となる資産と業務上の影響を決めてから、検査に必要な専門性を買うことが重要です。

許可範囲と検査環境――事故を防ぐ実施条件

自社の担当者が最初に作るべき文書は、ツールの設定表ではなく、検査の許可範囲です。NIST SP 800-115は情報セキュリティのテストと評価を計画・実施し、結果を分析するための技術ガイドです。発行は2008年で、AIエージェント向けの最新仕様を定めるものではありませんが、テスト計画を明文化するという基礎は今も参考になります。Webアプリの確認項目はOWASP Web Security Testing Guideも参照できます。

対象と対象外を同じ精度で書く

対象は、ホスト名、アプリ名、環境、テスト用アカウント、期間、許される操作を明記します。「当社ドメインすべて」のような表現は、委託先や旧プロジェクトのシステムまで含みかねません。対象外には、決済画面、取引先API、メール配信基盤、共有ホスティング上の他社領域などを明示します。サブドメインや外部サービスが同じ見た目で組み込まれていても、管理権限は別の場合があります。

検査会社が未知のURLを見つけた場合、自動で範囲へ追加しない手順にします。担当者へ報告し、管理主体を確認してから必要なら書面で対象を追加します。AIエージェントが自律的に次の対象を選ぶ方式ほど、この停止点を設計する意味があります。承認権限を営業窓口だけに置かず、対象システムの管理責任者と契約担当の双方を含めてください。

本番・ステージング・ローカルの使い分け

本番環境には実際の設定や利用状況がある一方、意図しない更新や大量アクセスが顧客へ影響します。ステージング環境は試験データで検査しやすいものの、本番とアクセス制御や接続先が違う場合があります。ローカル環境は影響を閉じ込めやすいですが、ネットワーク境界や運用設定を再現できないことがあります。どれか一つを「絶対安全」とせず、確認したい問いごとに環境を選び、結論できる範囲を報告書へ書きます。

初回のAIを使った検査は、停止しやすい試験環境で挙動を確認する案があります。その後、本番の設定差分だけを低負荷の確認方法で見るなど、段階を分けられます。試験用アカウントには本番顧客の情報を見せないようにし、作成・失効の担当を決めます。検査後にアカウントが残ると、検査自体が新しい弱点になります。

停止条件を抽象語にしない

「サービスへ負荷をかけない」だけでは、停止の判断が人によって異なります。問い合わせ数やエラー率などの監視指標、アラートの受信者、停止を指示できる人、連絡が取れない時の自動停止、再開承認の方法を決めます。データ書き込み、一括出力、権限変更、外部送信、持続的なアクセスは、明示的に許可しなければ禁止する設計が安全です。証拠が必要な場合も、実データを大量取得するのではなく、架空データの小さなサンプルで業務影響を示せるか検討します。

検査の時間帯を深夜にすれば安全とは限りません。バックアップやバッチが走る時間と衝突することがあります。運用担当がアラートに対応できる時間、委託先が即時停止できる時間、必要な判断者が連絡可能な時間を重ねて選びます。緊急停止後の連絡先は電話とチャットなど二つ以上の経路を用意し、実施前に一度試します。

委託契約に残すべきデータと証拠の扱い

AIサービスへ検査対象の情報を渡す場合、入力データ、生成されたログ、報告書の下書きがどこに保存され、誰がアクセスし、いつ削除されるかを確認します。第三者モデルを利用するなら再委託と越境移転の有無も確認が必要です。入力した情報がモデル学習に使われるか、契約上の設定で除外できるかはサービスにより違うため、製品名だけで判断しません。未公開の脆弱性や認証情報を、一般向けのAIチャットへそのまま貼り付ける運用は避けます。

証拠は問題を修正できるだけの精度で残しつつ、余分な個人情報を含めないことが原則です。画面やログには利用者名、トークン、メールアドレスが写ることがあります。マスキング前の原本を誰が保管するか、修正担当が見る資料には何を伏せるか、保存期限後にどのように廃棄するかを、開始前に決めてください。

作業前の小さなリハーサルを挟む

契約を結んでいきなり全対象へ検査を始めず、双方の担当者が一つの試験用機能で連絡と停止の流れを確認します。検査会社から開始連絡が届くか、社内監視が想定した通知を出すか、停止指示を受けて作業が止まるか、ログを後で照合できるかを確かめます。リハーサルは攻撃を再現するためではなく、管理体制が設計通り動くかを見るためです。問題があれば範囲を広げず、文書と連絡網を修正します。

AIエージェントがツールを動かす場合、画面上の「停止」ボタンで新規の操作が止まっても、既に投入された非同期ジョブが続く設計かもしれません。委託先には、停止後に残る処理と発行済みの権限を説明してもらいます。検査用アカウントに期限を設け、試験後に失効できることも確認します。実施ログは開始時刻と終了時刻、許可した対象、実際にアクセスした対象、担当者の判断が追える粒度で保存します。

責任者を役割で決める

契約責任者は検査対象の管理権限と委託条件を確認します。システム所有者は対象と停止許容度を承認します。運用担当は監視、緊急停止、バックアップを担います。検査担当は許された範囲で作業し、逸脱を見つけたら止めて報告します。開発担当は指摘の修正方法を判断し、事業責任者は未修正リスクの受容や機能停止を決めます。一人が複数役を兼ねる小規模企業でも、誰がどの判断をするかを書き分けます。

特に、検査会社の担当者が見つけた未知の外部サービスを、その場のチャットだけで対象へ追加しないようにします。後から「誰が許可したか」を確認できる承認記録を残します。サービス提供者によっては診断のための事前通知や専用手続きが必要です。対象が自社ブランドの画面に見えても、実際に管理しているのが決済事業者やSaaSなら、自社だけの許可では足りません。権利関係が不明な場合は対象外にして確認を優先します。

ツールと委託先を比べる評価指標

「何件見つけたか」だけを評価指標にすると、実害のない情報を大量に挙げるサービスが有利になります。一方で重大な権限の問題を一件見つけても、誤検知を確認できず修正方法が曖昧なら実務の成果にはなりません。件数、重大度、検証可能性、業務影響、対象範囲、検査の安全性、報告後の対応をまとめて評価します。

検出率より先に、見逃した範囲を記録する

検査対象の画面やAPIのうち、実際に確認できた領域とできなかった領域を分けます。ログイン後の画面を検査する予定だったのに、テスト用アカウントが使えなければ、その範囲について安全と結論できません。多要素認証のため手動での補助が必要な部分、決済連携のため除外した部分も明記します。レポートに「問題なし」と書く場合は、どの方法でどの範囲を見た上での言葉かを求めます。

異なるサービスの検出件数を単純比較する場合、対象、アカウント、時間、検査方法が同じかを確認します。公開されたデモの所要時間や金額を自社の見積もりへそのまま当てはめるのは不適切です。作られた検証アプリは、実務の複雑な認証、分岐した業務ルール、利用者の負荷を再現していないからです。

証拠の質と誤検知の扱いを見る

重要な指摘には、対象の機能、前提となる権限、観測できた結果、想定される影響、修正の方向、再確認方法が必要です。報告書に生の攻撃文字列を大量に添付する必要はありません。開発担当が欠陥の所在と修正の意図を理解できる、安全に扱える資料であることが大切です。検出しただけで実際の影響を確かめていないものは、可能性として分類し、確認済みの影響と混ぜません。

誤検知はゼロである必要はありませんが、委託先がどう検証し、何を未確認として残すかを見ます。AIが「危険」と書いた文章は、モデルの出力だけでは証拠になりません。保存したログや画面、設定、コード上の根拠と突き合わせます。逆に「AIが安全と答えた」ことも安全性の証明ではありません。人が最終的な評価に署名する体制を確認してください。

自動化の範囲と人の監督を点数化する

調達表には、検査前の設定、検査中の操作、異常時の停止、報告書のレビューの四段階で、人の関与を記載します。単なる自動化率より、危険な操作の前に停止できる設計が重要です。たとえば情報を読むだけの低負荷な確認と、データ変更の可能性がある操作を同じ承認条件にしないようにします。監督者が画面に表示されるだけで実際には止められないなら、その設計は「人の監督あり」と評価しません。

評価軸	提出を求める証拠	不十分な回答例
対象の網羅	確認済み・未確認の資産一覧	「全サイトを確認」だけ
重大度	影響と前提条件、根拠	AIの警告文のみ
安全管理	停止条件、監督者、実行ログ	「安全なツールです」だけ
データ保護	保存場所、再委託、削除方法	規約への一般的リンクのみ
修正支援	質問対応と再検査の範囲	PDFの納品で終了

この表は点数を自動で決めるものではありません。会社ごとに停止リスクと機密性の重みが違うため、評価前に配点を決めます。顧客情報を多く持つサービスではデータ保護と権限検査を重くし、公開前の新機能では業務動作への影響や再検査の速さを重くする、といった調整が必要です。

小規模な比較試験で説明の差を見る

複数のサービスを比較するなら、合成データを入れた同じ試験環境で、実施計画と報告の品質を比較する方法があります。結果の件数だけでなく、対象外を守れたか、誤検知を正しく扱えたか、人が止められたか、開発担当が修正に着手できる報告かを確認します。故意に弱点を仕込む場合、その評価だけで本番環境の診断能力を結論できないことを明記します。製品間の優劣を公表する予定があるなら、比較条件をさらに慎重に揃えなければなりません。

評価用アカウントに与える権限がサービスごとに異なると、検出件数の差は性能差ではなく条件差かもしれません。検査時間だけを同じにしても、開始時に与えた資料や操作の上限が違えば比較しにくくなります。比較表には、対象、与えた情報、検査時間、禁止操作、人手の介入、確認された事実、未確認の領域を記載します。AIの推論コストや利用料を比べる場合も、専門家による確認と修正支援を含めた総費用で考えます。

「安い・速い」に隠れやすい作業

見積もりには、事前の対象確認、テスト用アカウントの準備、監視体制、実施時間、重要事項の速報、報告書の説明、修正後の再検査が含まれているかを確認します。検査そのものが短時間でも、社内の準備と改修が必要です。自社の開発者がすぐに対応できないなら、緊急度の高い指摘を受けた後の外部支援費用も予算に入れます。料金が公開されていない会社について、記事や比較表で推測額を示さない方が適切です。

契約前に「一件の重大な問題が見つかった場合、いつ誰に伝わり、どこまで追加料金なしで確認されるか」を質問します。検査中の中断と再開、対象の軽微な変更、報告書の追加説明、再検査の期限に費用がかかるなら、初期見積もりだけでは判断できません。安価なパッケージが悪いという意味ではなく、支払う範囲と自社が行う作業を分ける必要があるということです。

報告書を修正と再検査につなげる実務

検査は報告書の納品で終わりません。指摘に修正担当を割り当て、期限と受入条件を決め、同じ問題が残っていないことを再確認するまでが仕事です。AIペンテストの成果を検出件数で測るだけでは、開発や運用の改善へつながりません。検査を依頼する時点で、改修を実施するチームの時間も予算に含めます。

問題を「直せる単位」へ分ける

報告書の一項目が複数のサービスにまたがる場合、影響を受ける各システムの担当者と設定を分けます。たとえば権限確認の設計に共通の問題があっても、Web画面、API、管理機能では修正箇所とリリース時期が異なります。一方、同じ原因から出た十件の警告を十件の独立した欠陥として数えると、優先順位が見えにくくなります。原因、影響、修正担当を軸にチケットをまとめます。

修正担当は「入力値を確認する」「権限を見直す」といった抽象的なタスクでは着手しづらいでしょう。期待する動作、現状の動作、変更すべき境界、テスト条件を記載します。具体的な攻撃手順を広く共有しなくても、担当者が安全に再現できる試験データと事実関係は必要です。顧客情報が含まれる原本は別管理にし、チケットにはマスクした情報を載せます。

優先順位は重大度と業務条件の掛け合わせ

一般的なスコアだけでは、顧客への実際の影響や変更の容易さは分かりません。匿名で到達できるか、どの情報が見えるか、検知できるか、既に悪用の兆候があるか、修正に伴う停止が必要かを整理します。緊急停止が必要な場合もあれば、影響を抑える暫定措置を入れて次の保守窓で直す場合もあります。その判断を記録し、例外に期限を付けるのはシステム所有者の責任です。

再検査では、一つの指摘だけを機械的に再実行して終わらせません。原因を修正した周辺機能と、運用に影響する代表的な業務操作も確認します。修正が別の利用者の正常な閲覧権限を壊していたら、安全になってもサービスは使えません。検査会社へ再検査を依頼する場合は、何件まで含まれるか、変更後の対象URLも見てもらえるか、期限はいつまでかを契約時に決めます。

報告書の受入チェックリスト

• 対象と対象外、使用した権限、環境、検査期間が記載されている。
• 確認済みの事実、AIの推定、未実施の項目が分かれている。
• 業務影響と、過度に機密を露出しない証拠がある。
• 危険度の理由と、修正の方向が記載されている。
• 誤検知や検証できなかった理由が隠されていない。
• 重大事項の速報経路、質問窓口、再検査条件が分かる。
• 検査用アカウントと一時アクセス権の失効を確認できる。

このチェックリストに複数の空欄があるなら、請求書の処理だけ先に進めず、委託先へ補足を求めます。特にAI生成の説明をそのまま貼った報告書は、裏付けとなる観測事実を確認しましょう。納品後の打ち合わせに開発担当が参加し、実装上の質問を直接できるようにすると、修正着手までの時間を短くできます。

納品から30日後の受入を考える

報告書を受け取った日だけを完了日にしない運用もあります。初週に重大な指摘の暫定措置を決め、翌週までに修正計画と担当者を確定し、30日程度を目安に修正・再確認の進捗を経営層へ報告します。この日数は一律の期限ではありません。重大度、変更難易度、顧客影響によって前倒しや延長が必要です。延長する場合は、なぜ今直せないか、どの影響を抑えるか、誰がいつ再判断するかを残します。

外部委託した検査の成果は、自社の開発プロセスへ反映して初めて長く役立ちます。同じ種類の権限不備が複数見つかったなら、該当箇所だけ直すのではなく、共通の権限判定の設計とレビュー観点を更新します。公開設定の誤りなら、リリース前の確認表へ追加します。AIエージェントの過剰な権限なら、接続するツールの標準権限と承認フローを改めます。再検査で一件が消えたことと、組織として同種の問題が起きにくくなったことを分けて評価します。

試験用アカウントとデータをどう準備するか

検査会社に実在の顧客アカウントを渡す前に、必要な役割を持つ試験用アカウントを用意できないか確認します。会員制サイトなら、別々の一般会員、店舗や組織の担当者、管理者というように、権限の境界を見られる組み合わせにします。各アカウントには架空の注文や予約を紐付け、正常な閲覧範囲と変更範囲を記録します。試験用データは、実在の氏名や連絡先と似た値を偶然使わないよう、誰が見ても架空と分かるものにします。

「実データがないと検査できない」と言われたら、何を確認するために必要なのかを聞きます。多くの権限検査は合成データでも実施できます。ただし本番固有の接続や設定が必要な検証もあります。その場合は、取得する情報を最小化し、マスキングや監督の方法を決め、法務・情報管理担当が承認した範囲に限ります。検査会社へ渡す認証情報は専用の安全な手段で共有し、メール本文や一般チャットへ平文で貼り付けません。

検査が終わったら、試験用アカウント、発行したAPIキー、一時的に許可したIPアドレス、作成した共有リンクを一覧にして失効します。単にパスワードを変えるだけでなく、保存されているセッションやトークンの扱いも確認します。委託先が保管するコピーの削除記録も求めます。開始時に発行物の一覧を作っていないと、この後片付けが漏れます。準備資料には発行日、用途、所有者、失効予定日を含めましょう。

経営層へ報告する一枚の要約

技術報告書とは別に、経営層には「何を検査し、何は未検査で、何が確認され、何をいつ直すか」を一枚で伝えます。最初に対象サービスと検査期間を書き、確認済みの重大な問題、顧客や業務への影響、暫定措置、必要な意思決定を続けます。「AIが危険と判定」といった表現は避け、保存した証拠で確認できた事実を用います。未確認の範囲を省くと、報告を読んだ人が全体を検査済みと誤解します。

たとえば「会員向けAPIの一部で、試験会員Aが試験会員Bの架空データを閲覧できた」という事実なら、権限境界の問題として伝えられます。一方、「全顧客の情報が流出した可能性が高い」と書くには、実際のログや対象データを調べる別の根拠が必要です。試験で見つけた弱点と、過去に実際に悪用されたかどうかは別問題です。後者に疑いがあればインシデント調査として切り分けます。

経営層の承認事項は、修正のための開発工数、必要な一時停止、未修正期間の暫定措置、再検査の予算と予定です。承認後に担当者と期限をチケットへ戻し、進捗を月次で報告します。技術用語を省くことは大切ですが、事実の条件まで消して「危険」「安全」の二語にしないようにしてください。

委託先へ聞く質問と、よくある誤解

見積もり前に聞く十の質問

1. AIが判断する工程と、人が承認する工程はどこですか。
2. 対象外のURLや第三者サービスを発見したら、どう止めますか。
3. 本番環境で許可される操作と、禁止される操作は何ですか。
4. アクセス増加やエラーが起きた際の停止・連絡は誰が行いますか。
5. 実データを使わずに業務影響を示す方法はありますか。
6. 検査データとAIへの入力はどこに保存されますか。
7. 外部AIサービスや再委託先の利用はありますか。
8. 誤検知と未検査領域を報告書でどう区別しますか。
9. 重大な問題は納品日を待たずに知らせてもらえますか。
10. 修正後の再検査と質問対応は費用に含まれますか。

回答を「はい・いいえ」だけで終わらせず、契約書や作業計画書のどこに書かれるかまで確認します。競争見積もりでは同じ前提を各社へ渡さなければ金額が比較できません。対象数、検査用アカウントの有無、環境、期間、報告形式を揃えて質問してください。料金が安くても、人による検証、緊急連絡、再検査が別料金なら総額は変わります。

AIを使えば人による検査は不要ですか？

不要とは言えません。AIは広い範囲の情報整理や繰り返し作業を助けますが、業務仕様の意味、顧客影響、契約上の許可、報告の妥当性は人が判断します。検査で自動化を使う割合が増えても、確認者と責任者の名前を消さないでください。特に「問題なし」という結論ほど、どの範囲を実際に見たかが重要です。

診断会社のデモで短時間に突破できたなら、自社も危険ですか？

自社にも同じ種類の弱点があれば危険はありますが、デモだけでは自社の状態は分かりません。参考にした検証は、ローカルの意図的に弱い環境を用い、横展開や破壊などを検査範囲から除いています。結果を一般化せず、まず自社の資産、権限、更新状態を調べてください。デモを見て焦り、本番環境へ無許可のツールを動かすのは逆効果です。

報告書で「AIによるハッキングが可能」と書かれたら？

「何を確認した結果か」を分解します。特定の欠陥を利用して、試験アカウントから試験データへアクセスできた事実なのか、AIがそう推定しただけなのかを分けます。修正すべき原因は、AIの有無ではなくアクセス制御や公開設定である場合が多いでしょう。問題が再現可能で影響が確認されたなら、AIという言葉の強さに関係なく、担当を付けて改善します。

検査の結果を社外へ公開してよいですか？

公開前に、サービス利用者への影響、未修正の弱点、委託先との契約、個人情報、利用した第三者製品の規約を確認します。改善済みの概要を公表することは透明性に役立つ場合がありますが、攻撃に利用できる詳細や管理画面の情報を残すべきではありません。社外説明は経営、法務、広報、システム担当が事実と時系列を確認して決めます。この記事は公開の法的判断に代わるものではありません。

「重大な問題なし」なら次回は検査しなくてよいですか？

一回の検査で問題が見つからなかったことは、対象範囲と時点を限定した結果です。検査後に新しいAPIを公開したり、権限設計を変えたり、外部サービスへ接続したりすれば、状況は変わります。報告書の未検査領域と実施時点を確認し、次の大きな変更時にどの範囲を見直すかを決めてください。毎回全資産を同じ深さで検査する必要はありませんが、変更の多い箇所と高い権限を持つ箇所は継続して確認すべきです。

検査のない期間も、更新、アカウントの棚卸し、アクセスログの確認、バックアップの復元訓練を続けます。AIを使った診断会社へ一度依頼したことだけでセキュリティ運用を代替できません。報告が良い内容なら、それを「安全の保証書」ではなく、残存リスクと次回の検査計画を決めるための資料にします。

次回の検査日を暦だけで決めるのではなく、新しい公開機能、高権限アカウントの追加、保存データの変更、委託先の変更を再評価のきっかけにしてください。担当者が変わった場合も、前回の対象と除外理由を引き継ぎます。これにより「前回問題なしだった」という言葉だけが一人歩きするのを防げます。

本記事の参照資料は、限定条件の検証記事、NIST SP 800-115、OWASP WSTG、OWASPのエージェント型アプリのリスク整理です。2026年10月23日に確認しました。製品や契約条件は変わるため、購入時に各社の最新資料を照合してください。

関連する実務解説：AIハッキングとは？従来Botとの違いと企業が取るべき防御策、AIを悪用したWebアプリ攻撃に備える｜認証・認可・更新の優先順位も確認してください。

AIスキルで、未来の自分をアップデート！

AIペンテストの判断にも、AIの出力と事実を見分ける力が必要です。WithAIは脆弱性診断サービスではありません。安全なAI活用の基礎を学びたい方は、WithAIの無料学習案内を確認してください。