セキュリティチームが AI スキャンツールを導入した翌日、数百件もの修正待ちリストが届きました。経営層には検知能力が大幅に向上したように見えても、開発チームが直面するのは一連の現実的な問題です。どの脆弱性を優先すべきか、誰が修正を担当するのか、テスト環境のスケジュールを確保できるのか、システムを停止してデプロイできる時間帯はいつなのか。こうした点を事前に明確にしなければ、AI が脆弱性を発見するスピードが上がるほど、対応待ちリストも速いペースで膨らんでいきます。
TechOrange の報道によると、Bank of America は AI が明らかにしたソフトウェアの脆弱性に対応するため、第 2 四半期に外部請負人員を 1,000 人追加し、既存の社内人員 3,000 人と共同で作業に当たりました。関連するモデルは、リスクが低度から中度の脆弱性を数百件から数千件発見でき、従来であれば修正に数週間かかっていた問題の一部も、現在では数日以内に対応しなければなりません。この事例が企業に示す教訓は明確です。AI セキュリティツールを導入する前に、検出された脆弱性を修正し切るだけの能力が自社にあるか、対応プロセス全体を適切に管理できるか、さらにすべての操作履歴を後から確認できるかを検証する必要があります。
修正対応力を把握してから、スキャン範囲を決める
多くの企業はツールを評価する際、どれだけの脆弱性を発見できるか、どのコードをスキャンできるかを先に確認しますが、その後に発生する作業まで計算に入れていません。脆弱性を発見した後も、チームはリスクを確認し、システム責任者を特定し、コードを修正してテストを手配し、最終的にデプロイのタイミングを決める必要があります。問題がベンダー提供のパッケージにある場合は、調達部門、法務部門、ベンダーの窓口担当者が対応に加わることもあります。スキャンレポートはあくまで作業の出発点であり、脆弱性を発見しただけでリスクが低下したと考えるべきではありません。
管理者はまず、社内見積システム、カスタマーサービスの管理画面、工場の品質管理システムなど、特定の種類のシステムを選んで処理能力を検証できます。最初からすべてのコードをツールでスキャンするのではなく、既存のチームが 1 週間に何件の脆弱性について判定、修正、テスト、デプロイまで完了できるかを記録し、作業が最も滞りやすい工程を特定します。この段階で見栄えのよい修正率を追求する必要はありません。重要なのは、対応待ちリストが急増したとき、どの部門の作業が最初に既存のスケジュールへ組み込めなくなるかを把握することです。
修正の優先順位を決める際も、ツールが示すリスクスコアだけを基準にしてはいけません。企業は、システムの重要度、外部公開の有無、アクセス可能なデータ、現在講じている防御策、修正に失敗した場合に想定される停止時間も評価に含め、最終的にはセキュリティ担当者とシステム責任者が確認する必要があります。チームが一種類のシステムに関する対応事項さえ合意した期限内に処理できない場合は、スキャン範囲を急いで拡大せず、まず作業分担とデプロイ時間帯を見直すべきです。
修正プロセスのどの段階で人による確認が必要か？
AI は、脆弱性の説明整理、関連コードの集約、作業チケットの準備を支援できます。しかし、リスクレベルは引き続き人が判定し、修正内容の確認から本番環境へのデプロイまでを一貫して自動承認すべきではありません。プロセスを次の 4 段階に分け、各段階の担当者、必要な情報、完了とみなす基準、期限を超過した場合の対応を明文化することを推奨します。
脆弱性の分類：まず AI が、影響を受けるシステム、流出する可能性のあるデータ、推奨されるリスクレベルを整理し、その後、セキュリティ担当者が優先順位を引き上げるべきか、引き下げるべきかを確認します。情報が不足している場合は、作業チケットを差し戻して追加資料を求める必要があります。モデルに推測させたまま処理を進めてはいけません。
修正担当の割り当て：システム責任者は、案件を社内の開発チーム、ソフトウェアベンダー、外部請負業者のいずれが担当するかを確認し、相手が閲覧できるコードと文書の範囲を事前に制限する必要があります。作業チケットには期限も明記します。依存パッケージに関する問題や、変更できないレガシーシステムに関する問題の場合は、代替措置の決定者も明示しなければなりません。
テストと検証：テスト担当者は変更内容に基づき、脆弱性が解消されているかを確認すると同時に、ログイン、見積、受注、製造ラインとの連携など、既存の機能に影響が生じていないかも検証します。修正担当者が自分の成果を単独で承認してはならず、テストの証跡も同じ作業チケットに添付する必要があります。
デプロイの承認：システム責任者は、リスク、テスト結果、システム停止による影響に基づいてデプロイのタイミングを決定します。変更リスクが高い場合や、中核業務に影響する可能性がある場合は、本番環境を更新する前に再度承認を得る必要があります。EgentWrX では、繰り返し実行できる作業チケットとしてタスクを作成できるほか、複数のタスクをワークフローとして連携し、次の担当者へ引き継ぐ前に人による承認を設定できます。指定された担当者が確認するまで、後続の処理は実行されません。企業はまず、一種類のシステムについて 4 段階のプロセスを明文化し、実際の案件を使って、各承認ポイントに本当に担当者が割り当てられているかを一つずつ確認できます。
外部委託人員が増えた後、脆弱性リストをどう管理すべきか？
外部請負業者を活用すれば修正要員を補えますが、彼らがアクセスする脆弱性リストには、社内ソフトウェアやベンダー提供コードの弱点も含まれます。調査資料では、請負業者がどの程度の期間業務に従事する予定か、担当者が退職した際にアカウントと権限をどのように処理するか、リアルタイムの脆弱性データへのアクセス履歴を誰が監査するかを確認する必要があると指摘されています。企業が秘密保持契約を締結するだけで、アカウントの有効期限やデータの閲覧範囲を設定していなければ、プロジェクト終了後も不要な権限が残る可能性があります。
企業はまず、請負業者のアクセス台帳を作成し、少なくとも所属企業、閲覧可能な部門とデータの範囲、承認者、利用開始日、有効期限を記録できます。請負業者に脆弱性リスト全体を開示する必要はなく、アカウントの共有も認めるべきではありません。セキュリティ担当者または監査担当者は毎月アクセス履歴を抜き取り調査し、誰がデータを閲覧、ダウンロード、変更したかを確認する必要があります。プロジェクト終了時や担当者の退職時には、アカウントの無効化、権限の回収、アクセス履歴の再確認を完了条件に含めるべきです。
EgentWrX では、組織と役割に応じて、ユーザーが実行できる操作と閲覧できるデータを制限できます。また、EgentWrX は AI Agent と管理者の操作に関する監査ログを保存し、記録が改変されていないかを検証することも可能です。ただし、プラットフォームの仕組みは、社内における責任分担の代わりにはなりません。企業は引き続き、外部委託人員によるデータアクセスを誰が承認するのか、誰が定期的に記録を確認するのか、異常を発見した際に誰が権限を停止して関係部門へ通知するのかを明確に指定する必要があります。
最後に、企業が AI セキュリティツールを評価する際は、新たに発生する修正、テスト、システム停止、外部委託管理の業務もコストに含めなければなりません。Bank of America は第 3 四半期に、ソフトウェアの修正とマネーロンダリング対策に関するコンプライアンス対応を合わせて 2 億米ドル以上支出しました。ただし、原文では両者の金額が個別に示されていないため、この数字をそのままソフトウェア修正費用とみなすことはできません。より現実的なのは、まず一種類のシステムで一連のプロセスを数回通して実施し、各段階で投入した人員と待ち時間を記録したうえで、スキャン範囲を拡大するか判断することです。そうすることで、AI がさらに多くの脆弱性を発見する前に、既存のプロセスが実際にどの程度の作業量へ対応できるのかを把握できます。
よくある質問
AI が発見した脆弱性は、すべて直ちに修正する必要がありますか？
すべての脆弱性を同時に修正する必要はありませんが、各案件を必ず分類と担当割り当てのプロセスに進める必要があります。企業は、ツールによる評価、システムの重要度、データが露出する範囲、既存の防御策、システム停止の影響を総合的に評価し、セキュリティ担当者とシステム責任者が対応期限を確認する必要があります。低リスクの案件がリソースを占有し、本当に緊急性の高い修正作業が遅れる事態を避けなければなりません。
AI Agent にコードの修正からデプロイまでを自動実行させてもよいですか？
AI Agent に、コードの修正から本番環境へのデプロイまでを一貫して自動実行させることは推奨されません。AI Agent に情報整理、作業チケットの準備、プロセスの連携を任せることはできますが、リスクの判定、テスト結果、デプロイのタイミングについては、引き続き指定された担当者が承認すべきです。中核システムを更新する前には、ロールバック方法とシステム停止の計画も確認する必要があります。
外部請負業者には、どのような権限が必要ですか？
請負業者に必要なのは、指定された案件を処理するために必要なコード、文書、テスト環境へのアクセス権限のみです。企業はアカウントごとに、データの閲覧範囲、承認者、有効期限を設定し、アカウントの共有を禁止する必要があります。また、プロジェクト終了時や担当者の退職時には、アカウントを無効化して権限を回収し、アクセス履歴を再確認しなければなりません。
既存のチームが、AI によって増加する脆弱性の件数に対応できるか、どう判断すればよいですか？
まず一種類のシステムを選んで処理能力を検証し、脆弱性の分類、修正、テスト、デプロイの各段階で必要となる人員と、案件が各段階でどの程度待機しているかを記録します。案件が特定の段階で継続的に滞留している場合は、スキャン範囲を拡大する前に、担当者、完了条件、デプロイ時間帯を見直すべきです。ツールが発見した脆弱性の件数だけで判断してはいけません。
参考資料
- AI が発見した脆弱性は誰が修正する？Bank of America が請負人員 1,000 人を追加し、異例となる修正要員の規模を公表 — AI が明らかにした脆弱性に対応するため、Bank of America が投入した修正要員、コスト、外部委託管理のリスクについて報じた TechOrange の記事。
