この記事は、SaaS事業者・情報システム担当者が「受付窓口と真偽判定」を整備する工程に役立てていただくことを想定しています。パッチ適用工程については姉妹記事「フロンティアAI要請から考えるパッチ運用」を参照してください。
2026年に入り、欧米のバグバウンティプラットフォームでは「AIが生成した低品質・虚偽の脆弱性報告」が急増しています。Nextcloudは2026年4月、AI生成とみられる無効な報告の増加によりトリアージ担当の負荷が膨らんだとして、HackerOne上のバグバウンティの報奨を停止したと公表しました。これに先立ちcurlも同様の理由で報奨プログラムの終了を表明しています（各プロジェクトおよび報道の公表ベース）。同様の問題は国内のSaaS事業者にも広がる可能性があります。フロンティアAIの性能が上がるほど、真偽判定できない受付体制のコストは大きくなります。
今、何が起きているか
AIが脆弱性を探索・報告できる環境が整った結果、バグバウンティプログラムには「PoC（実証コード）なし・再現手順なし・存在しないエンドポイントを前提にした報告」が増えています。HackerOneの公表によれば、2026年3月の同プラットフォームへの報告件数は前年同月比で約76%増となった一方、実際に有効と確認された報告の割合はおおむね25%前後で横ばいでした（HackerOne公表ベース）。報告量が増えても本物の脆弱性の割合が大きく上がるわけではなく、受付側の優先度判定の精度がコストを左右します。
受付担当者が1件1件を手動で確認する体制では、フロンティアAIが普及するほど持続不可能になります。
SECURITY OPERATION
日常の脆弱性運用、情シス1人で回せる体制にしませんか？
月次棚卸・重大度判定・パッチ適用代行まで含む「セキュリティ運用伴走」プラン。単発対応からの卒業で、止まらない運用体制を作ります。
AI生成レポート判別チェックシート
受付段階で「人手をかけて再現確認すべき報告」と「機械的に保留・却下できる報告」を切り分けるための観点表です。1つの赤信号だけで却下するのではなく、複数の観点が同時に当てはまる報告を優先的に保留・追加情報要求に回す運用をおすすめします。
| 判別観点 | 具体チェック | 赤信号の例 |
|---|---|---|
| 再現手順の具体性 | 番号付きステップで、入力値・前提条件・期待される結果まで書かれているか | 「特定の入力で認証を回避できます」とだけ書かれ、実際のリクエストやパラメータが示されていない |
| 該当コード/バージョンの実在性 | 指摘されたファイル・関数・エンドポイント・バージョンが自社の実装に実在するか | 自社が採用していないフレームワークの一般的な関数名や、存在しないパスを前提にしている |
| PoCの動作 | 添付された実証コードや手順を検証環境でなぞると、実際に事象が再現するか | PoCが汎用的なペイロード例の貼り付けで、自社環境では何も起きない |
| 文体の定型性 | 説明が抽象的な一般論に終始し、自社固有の事情に触れていないか | 製品名を差し替えれば他社にもそのまま使える定型文で、同一構成の報告が短期間に複数届く |
| 報告者実績 | 過去の有効報告の有無、プラットフォーム上の評価、連絡への応答性 | 実績がなく、追加情報の要求に具体的な回答を返さない、または回答もAI生成とみられる |
このチェックは「AIが使われたから却下する」ためのものではありません。AIを補助に使った精度の高い報告も増えています。判別の目的は、再現性と自社資産への該当性が確認できない報告に人手の検証時間を奪われないようにすることです。
受付工程で先に設計する4つの判断軸
1. 受付窓口と初期フィルタの分離
報告の受け付け口（フォーム、メール、プラットフォーム）と、初期フィルタを行う人・ツールを分けます。最低限必要な情報（再現環境、CVSSセルフ評価、影響を受けるコンポーネント名・バージョン）を必須入力にするだけで、大量生成的な報告の多くは自然に除外されます。
| 必須入力項目 | 目的 |
|---|---|
| 再現手順（番号付きステップ） | AI生成の汎用記述を除外する |
| 影響コンポーネントとバージョン | 自社資産への照合を即時化する |
| 実証コード（PoC）または再現スクリーンショット | 偽陽性の初期除去 |
| 報告者の連絡先と開示タイムライン | 誠実な報告者との区別 |
2. 重複・既知判定の自動化
受け付けた報告が既知の脆弱性（CVE番号や自社の既対応チケット）と一致するか、受付時に自動照合します。JVN（Japan Vulnerability Notes）やNVDとの突き合わせをAPIで自動化しておくと、手動確認を大幅に削減できます。
3. 再現性確認の基準と期限
真偽判定で最も時間がかかるのは「再現できるかの確認」です。再現確認の担当者、環境、期限（例：受付から5営業日以内）を先に決めます。期限を超えた場合の処理ルール（追加情報要求→自動クローズ等）も文書化しておきます。
| 重要度 | 再現確認期限の目安 | 期限超過時の処理 |
|---|---|---|
| 緊急（CVSSスコア9以上、悪用確認） | 当日中 | エスカレーション必須 |
| 高（スコア7〜8.9） | 3営業日 | 上長への状況報告 |
| 中・低（スコア4〜6.9） | 10営業日 | 追加情報要求後クローズ |
4. 優先順位の調整変数
CVSSスコアだけでは実際のリスクを反映できません。下記の変数を加えた「調整スコア」で優先順位を決めます。
| 変数 | 優先度を上げる条件 | 優先度を下げる条件 |
|---|---|---|
| インターネット公開 | はい | 内部限定 |
| 悪用確認（CISA KEVやJVN掲載） | あり | なし |
| 扱うデータ | 個人情報・決済情報 | 社内限定データ |
| 代替策の有無 | なし | WAFや認証強化で緩和済み |
| パッチ提供状況 | 未提供 | パッチあり |
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
受領から確定・却下までの対応プロセス
判断軸を決めても、担当者ごとに処理の流れが違うとトリアージの品質は安定しません。受領から結論までを5つの工程に固定し、各工程で「次にどこへ送るか」を明文化しておきます。
- 受領：受付窓口（フォーム・メール・プラットフォーム）で必須入力をチェックします。再現手順や影響コンポーネントが欠けている報告は、この時点で追加情報要求のテンプレートを返します。
- 一次判定：上記の判別チェックシートと既知・重複の自動照合（JVN／NVDとの突き合わせ）を適用します。明らかな重複や該当性のない報告はここで保留・却下に振り分けます。
- 再現：一次判定を通過した報告だけを、決められた担当者と検証環境で再現確認します。重要度に応じた期限（後述の期限表）を適用し、再現できれば確定、できなければ追加情報要求へ戻します。
- 確定／却下：再現できた報告は深刻度評価と優先順位付けへ進めます。再現できず、追加情報の要求にも応答がない報告は却下とします。
- 記録：受領日時、判定理由、再現可否、対応者、結論を一件ごとに残します。AI生成とみられる報告の傾向（定型文のパターン、発信元）も記録しておくと、初期フィルタの精度改善に使えます。
工程ごとに「誰が担当し、何営業日以内に次工程へ送るか」を決めておくと、報告量が増えても処理時間のばらつきを抑えられます。
却下・保留の運用ルール例
以下はあくまで設計の「例」です。自社の体制やリスク許容度に合わせて閾値や期限は調整してください。
- 即時却下の例：自社に実在しないコンポーネントやバージョンを前提とし、追加情報要求にも具体的な回答がない報告。判別チェックシートの赤信号が3つ以上同時に当てはまる報告。
- 保留（追加情報要求）の例：再現手順や実証コードが不足しているものの、影響コンポーネントが自社資産に実在し、悪用された場合の影響が大きい報告。回答期限（例：7営業日）を設け、期限超過で自動クローズとします。
- 優先確認の例：インターネット公開資産に関する報告で、個人情報・決済情報を扱う経路に影響する可能性があるもの。再現できていなくても担当者を割り当て、当日中に一次確認します。
- 却下時の通知の例：却下する場合も、判定理由を一文で添えて返信します。誠実な報告者との関係を保ち、後日同種の真の脆弱性報告を逃さないためです。
却下・保留の判断は属人化しやすいため、判定理由のコードや定型文をあらかじめ用意し、記録工程と紐づけておくことをおすすめします。
国内で参考にすべき一次情報
日本の脆弱性報告の基本的な枠組みは、IPAとJPCERT/CCが共同で運営する「情報セキュリティ早期警戒パートナーシップ」に整理されています。自社製品が脆弱性の対象となった場合の届出・公開フローはこのガイドラインに沿って設計します。また、2026年3月にIPAが公開した「脆弱性対処に向けた製品利用者向けガイド」では、ライフサイクル全体での脆弱性管理のアプローチが整理されています（詳細はガイドライン全体の管理工程を扱う姉妹記事「ソフトウェア脆弱性ライフサイクル管理」で取り上げています）。
受付体制を外部委託する場合の確認事項
PSIRTやCSIRTの機能をセキュリティベンダーに委託する場合、受け付けた報告が自社の資産台帳と突き合わせられるか、トリアージの基準と期限が合意できるかを先に確認します。脆弱性診断の費用と進め方では、外部委託の範囲決めを含めた実務選択肢を整理しています。
GXOはどう支援するか
GXOでは、受付フォームの設計、JVN/NVDとの自動照合設定、トリアージ基準の文書化、社内PSIRT体制の立ち上げを含めて支援します。初回相談では、現在の脆弱性報告受付状況、自社製品・サービスの公開範囲、セキュリティ担当者の体制を確認し、どの工程から着手すべきかを優先順位化します。
よくある質問
Q1. バグバウンティプログラムを持たない企業にも関係しますか？
関係します。バグバウンティがなくても、メールやウェブフォーム経由で「セキュリティ上の問題を発見した」という連絡は届きます。対応窓口と優先度の判断基準がなければ、重大な脆弱性への対応が遅れます。
Q2. CVSSスコアだけで優先順位を決めてよいですか？
不十分です。CVSSは深刻度の一つの指標ですが、自社のインターネット公開状況や悪用の有無によって実際のリスクは大きく変わります。本記事の調整変数表を加味して判断することをおすすめします。
Q3. AI生成の虚偽報告はどう見分けますか？
再現手順が番号付きステップで書かれておらず、存在しないエンドポイントや一般的なフレームワーク名だけを記述している報告は要注意です。実証コード（PoC）の提出を必須にし、自社の実際のコンポーネント構成と照合することで大部分を除外できます。本記事の判別チェックシートでは、再現手順の具体性・該当コードの実在性・PoCの動作・文体の定型性・報告者実績の5観点を整理しています。
Q4. AIを使った報告は一律で却下してよいですか？
おすすめしません。AIを補助に使いつつ、再現手順や実証コードが具体的で自社資産に実在する事象を指摘した有効な報告も増えています。却下の基準は「AIが使われたか」ではなく「再現性と自社への該当性が確認できるか」に置くことをおすすめします。
Q5. 保留にした報告はいつまで持ち続ければよいですか？
回答期限を先に決めておくことをおすすめします。たとえば追加情報を要求してから一定の営業日（例：7営業日）応答がなければ自動クローズとし、その判定理由を記録に残します。期限と処理ルールを文書化しておくと、保留案件が滞留して重大な報告の確認が遅れる事態を防げます。
参考情報
- IPA「脆弱性対処に向けた製品利用者向けガイド（2026年3月）」：https://www.ipa.go.jp/security/guide/vuln/index.html
- IPA「情報セキュリティ早期警戒パートナーシップガイドライン」：https://www.ipa.go.jp/security/guide/vuln/partnership_guide.html
- JVN（Japan Vulnerability Notes）：https://jvn.jp/
- YesWeHack「Scaling Bug Bounty triage in the AI era」（報道ベース）：https://www.yeswehack.com/security-best-practices/scaling-bug-bounty-triage-ai
脆弱性報告の受付窓口と真偽判定の仕組みを整えませんか
GXOでは、受付フォームの設計からトリアージ基準の文書化、JVN自動照合の実装まで、PSIRTとCSIRTの立ち上げを一連で支援します。