AI脆弱性診断の結果はどう検証する？修正・テスト・承認の実務フロー
制作会社から「AI診断で脆弱性を見つけ、修正しました」と報告を受けたとき、何を確認すれば本番反映を承認できるでしょうか。「重要度：高」と表示されていても、修正を急ぐべきか、その修正で問い合わせフォームや顧客ポータルが止まらないかは、表示だけでは判断できません。
制作会社側にも、AIが出した多数の候補から何を採用し、どのような成果物として顧客へ説明するかという課題があります。AIによる脆弱性診断は、検出件数や処理速度だけではなく、検証と承認を含む一連の業務として設計する必要があります。
脆弱性の発見後に法的な報告や個人情報保護上の対応が必要かどうかは、発生した事象や契約関係などによって異なります。その判断は、個別事情に応じて弁護士や情報セキュリティの専門家などへご確認ください。本記事では、WEB制作・保守の領域に絞り、AIの検出結果、修正差分、テスト結果を人が検証し、本番反映を承認・記録する工程を扱います。
AIによる脆弱性診断と修正は、どこまで行えるのか
Claude Code Securityで確認できる工程
Anthropicは2026年2月20日、コードベースを走査して脆弱性を検出し、修正パッチを提案する「Claude Code Security」を限定的なリサーチプレビューとして発表しました。発表時点の対象は、EnterpriseおよびTeamの顧客と、優先アクセスを申請するオープンソースリポジトリのメンテナーです。
公式発表によると、検出結果には重要度と確信度が付けられます。AIが自ら検出結果を再検討し、その内容を立証または反証することで、誤検知の除外を試みる工程も説明されています。利用者はダッシュボード上で検出内容と修正案を確認し、採用するかを判断します。
ただし、AIによる再検討があるからといって、誤検知がなくなるわけではありません。検出率、誤検知率、見逃し率について、今回確認した公式発表には定量的な数値が示されていません。対応する言語やフレームワーク、WordPressのプラグインやテーマに同じ精度で対応できるかも確認できていません。
重要なのは、Anthropicが「人の承認なしには何も適用されない」と説明している点です。ソースコードだけでは判断できない事情を踏まえ、最終判断を開発者に委ねる設計です。公式発表上も、AIだけで検出から本番反映までを完結させる運用は想定されていません。
また、発表時点では限定的なリサーチプレビューです。一般提供済みの完成機能と同一視せず、実際に利用を検討する際は、その時点の提供プラン、利用地域、対応範囲を公式情報で確認する必要があります。
アルバータ州政府の事例で報告された流れ
Anthropicは2026年7月6日、カナダ・アルバータ州政府のTechnology and Innovation省によるClaude Codeの導入事例を公表しました。同省は、州政府の27省庁にまたがる約1,280のアプリケーションと、約3,400のコードリポジトリを管理していると説明されています。
事例記事によると、まずルールエンジンで既知のパターンに該当する候補を抽出し、その候補をClaude Codeが再確認しました。検出候補には該当するファイルと行番号を付け、開発者が調査できる形にしています。AIが修正案を作り、テストやビルドまで行う場合もあり、自動テストが不足したシステムでは修正の安全性を確かめるテストを先に作成したと報告されています。
それでも、パッチが自動的に本番へ反映されたわけではありません。Anthropicは、すべてのパッチについて、反映前に同省のエンジニアがレビューし、承認したと明記しています。この事例から確認できるのは、少なくとも「候補検出」「該当箇所の提示」「修正案の作成」「テスト」「技術者によるレビューと承認」という流れです。
同記事には、約50のエージェントを並列稼働させ、4億6,600万行のコードを約20時間で走査したことや、従来の方法では約6.5年かかったという推計も掲載されています。ただし、これはAnthropicが紹介した個別事例と当該チームの推計です。第三者が同一条件で行った比較試験の結果としては確認できていません。
対象システムの規模、コードの構成、既存テスト、使用言語、診断方法が異なるため、この処理時間を一般的な士業サイトや顧客ポータルの期間短縮見込みとして使うことはできません。導入判断では、目立つ処理件数よりも、自社の対象環境で人の確認にどれだけ時間がかかったかを見る必要があります。
AIの検出結果を制作会社が検証する方法
NISTが2022年に公開したSecure Software Development Framework（SSDF）Version 1.1は、特定のAI製品や士業サイトに限定されない、一般的なセキュア開発の指針です。SSDFのPW.7では、人によるコードレビューとツールを使ったコード分析のどちらを使うか、または両方を使うかを決める考え方が示されています。
さらに、発見事項と推奨修正を開発ワークフローや課題管理システムへ記録し、優先順位を付けること、既存の分析・テスト結果をピアレビューの一部として確認することも示されています。AI診断を導入する場合も、出力を受け取っただけで完了とせず、既存のレビュー工程へ組み込むことが重要です。
検出根拠と攻撃経路を確認する
制作会社や担当技術者が最初に確認するのは、検出名ではなく、その根拠です。少なくとも次の情報を一つの課題票にまとめます。
- 脆弱性の種類
- AIが付けた重要度と確信度
- 該当するファイルと行番号
- 問題となるデータの流れ
- 再現に必要な条件
- 外部から到達できる攻撃経路
- 採用または見送りの判断理由
例えば、AIが入力処理の問題を「重要度：高」と判定しても、その処理が外部公開された問い合わせフォームから到達できるのか、管理者だけが利用できる画面なのかで、実際の影響は変わります。反対に、確信度が低い候補でも、認証や顧客データに関係するなら詳しい確認が必要になる場合があります。
誤検知として見送る場合も、候補を一覧から消すだけでは不十分です。「対象の処理には外部入力が到達しない」「別の箇所で入力値を検証している」など、判断した根拠を残します。後日の仕様変更で前提が変わったときに、再確認しやすくなるためです。
対象範囲と業務への影響を確認する
次に、その検出が本番、検証、開発のどの環境に関するものかを明確にします。士業サイトでは公開ページだけでなく、問い合わせフォーム、ログイン、管理画面、会員ページ、顧客ポータル、外部API連携も確認対象になり得ます。
修正によって変わる可能性がある機能も洗い出します。特に確認したいのは、次のような処理です。
- 利用者や管理者の認証
- 権限による閲覧・操作の制御
- フォームの入力値検証
- 受付通知や自動返信メールの送信
- 書類のアップロードとダウンロード
- 顧客情報の表示・更新
- 外部サービスとのデータ連携
対応順位は、AIが表示する重要度だけでは決められません。実際の攻撃経路、公開範囲、扱うデータ、業務停止時の影響、代替手段の有無を制作会社が確認し、サイト所有者へ説明したうえで決める方法が考えられます。
認証、権限、顧客データに関係する重大な問題については、通常の制作担当者だけで判断できるとは限りません。どの条件に該当したら情報セキュリティの専門家へ確認を依頼するか、あらかじめ決めておくと判断を止めずに済みます。
修正差分をコードレビューする
AIが提案した修正案は、そのまま採用せず、変更前後のコード差分を担当技術者がレビューします。確認するのは、脆弱性の原因を解消しているか、表面上の症状を隠しただけになっていないかという点です。
加えて、修正によって別の問題を持ち込んでいないかも確認します。新しいライブラリへの依存、必要以上の権限付与、入力検証の欠落、例外処理の変更、ログへの機密情報出力などが確認例です。
「AIが作成した修正だから採用する」「重要度が高いから即時反映する」という判断は避けます。採否を決める主体は制作会社や担当技術者であり、その理由と確認者を記録します。AIの役割は、調査や修正の候補を提示するところまでと整理すると、責任分担が明確になります。
修正案を本番反映する前に必要なテストと承認
検証環境で再現テストと回帰テストを行う
修正案は、本番環境へ直接適用しません。本番に近い設定を持つ検証環境で、まず修正前に問題を再現できる条件を記録します。その後、修正を適用し、同じ手順で問題が再現しないことを確認します。
ただし、脆弱性が再現しなくなっただけでは、修正の確認は終わりません。問い合わせフォームの修正であれば、正常な送信、自動返信、管理者への通知、入力エラー、長い文字列や空欄の処理なども試します。顧客ポータルであれば、利用者と管理者の権限を分け、閲覧、更新、ファイル操作、ログアウト後のアクセスなどを確認します。
回帰テストでは、修正箇所に直接関係する機能だけでなく、同じ認証、データベース、メール送信、ファイル保存を利用する主要機能も対象にします。修正によって従来動いていた機能が停止していないかを確かめるためです。
NIST SSDFのPW.8では、実行可能なコードをテストし、脆弱性が残っていないことや、ソフトウェアがセキュリティ要件を満たすことを確認する考え方が示されています。ただし、SSDFは固定的なサイト診断チェックリストではありません。組織の業務要件、リスク許容度、費用、実現可能性に合わせてテスト範囲を調整する必要があります。
AIが生成したテストの不足を人が補う
AIがテストコードを生成できても、そのテスト自体がサイトの仕様や利用者の操作を十分に反映しているとは限りません。AIが作成した修正とテストが同じ誤った前提に基づいていれば、テストに通っても必要な確認を満たしていない可能性があります。
制作会社は、仕様書、過去の不具合、実際の操作手順をもとに、正常系、異常系、権限別、入力境界値のテストを追加します。既存の自動テストが不足している場合は、修正前には失敗し、修正後には成功するテストを加える方法も考えられます。
テスト記録には、少なくとも対象機能、操作条件、期待する結果、実際の結果、実施者、確認日を含めます。「テスト済み」という一文だけでは、どの範囲まで確認したのかをサイト所有者が判断できないためです。
本番反映前に承認ゲートを設ける
本番反映前には、制作会社とサイト所有者が同じ条件を確認できる承認ゲートを設けます。例えば、次の項目をすべて確認してから反映を承認します。
- 検出根拠と再現条件が確認されている
- 影響する機能やデータが説明されている
- 対応順位を決めた理由が記録されている
- 修正差分を担当技術者がレビューしている
- 必要な再現テストと回帰テストが完了している
- 未解決事項と確認できなかった範囲が明示されている
- 本番反映前のバックアップが用意されている
- 問題発生時のロールバック手順がある
- 技術的な確認者と本番反映の承認者が記録されている
バックアップは、存在することだけでなく、復元対象、保存場所、取得日時を確認します。ロールバック手順には、誰が戻すのか、どの状態へ戻すのか、反映後のどの症状を中止判断の基準にするのかを含めます。
本番反映後は、問い合わせ、ログイン、メール送信、ファイル操作などの主要機能を再確認し、エラーログや監視結果も確認します。問題がなければ対応を完了として記録し、異常があれば事前に決めた手順で元へ戻します。
サイト所有者と制作会社は何を確認し、何を記録するか
AI・制作会社・サイト所有者の役割を分ける
AI診断を導入するときは、ツールの機能より先に、担当者と承認者を決めます。編集部では、役割を次のように分ける方法が実務へ取り入れやすいと考えます。
- AIは、脆弱性候補、該当箇所、修正案、テスト案を提示する
- 制作会社や担当技術者は、技術的な妥当性、攻撃経路、影響範囲、修正差分、テスト結果を確認する
- サイト所有者は、業務への影響、停止時間、対応順位、残存リスクの説明を受け、本番反映を承認する
- セキュリティ専門家は、認証、権限、顧客データなどに関係する重大な問題を必要に応じて確認する
行政書士事務所などのサイト所有者が、ソースコードを直接読んで修正の妥当性を判断する必要はありません。その代わり、どの業務へ影響するのか、どのテストを行ったのか、元へ戻せるのかを制作会社へ説明してもらいます。
中小企業診断士が顧客企業のDX導入を支援する場合も、AI製品の導入だけで終わらせず、検出結果を誰が検証し、誰が順位を決め、誰が本番反映を承認するかを業務フローとして整理するとよいでしょう。
制作会社から受け取りたい4つの成果物
サイト所有者は、制作会社から最低限、次の4点を受け取る形式を決めておくと確認しやすくなります。
- 検出一覧
- 修正差分
- テスト結果
- 未解決事項
検出一覧には、重要度と確信度、該当箇所、影響範囲、再現条件を記載します。修正差分には、何をどのように変更し、誰がレビューしたのかを記録します。テスト結果には、実施項目、結果、実施者、確認日を含めます。未解決事項には、見送った候補、確認できなかった範囲、残存リスク、今後の対応予定を示します。
さらに、各検出へ採用または見送りの理由、対応状況、担当者、承認者、本番反映日、ロールバック方法を付けると、後から判断の経緯を追いやすくなります。NIST SSDFが示す、発見事項と推奨修正を記録して優先順位を付ける考え方にも沿った運用です。
サイト所有者が制作会社へ尋ねること
専門知識がなくても、サイト所有者は次の質問で業務上の判断材料を集められます。
- どの機能とデータが影響を受けますか
- 認証、権限、メール送信、ファイル操作に変更はありますか
- 検証環境でどの操作をテストしましたか
- 顧客向け業務が停止する可能性と想定時間はどの程度ですか
- 問題が起きた場合、どの状態へ、誰が戻しますか
- 未解決の検出や確認できていない範囲は残っていますか
- 認証、権限、顧客データに関する問題を専門家へ確認しましたか
- 本番反映後、どの画面とログを誰が確認しますか
「修正済みですか」という質問だけでは、確認範囲や残存リスクが分かりません。管理画面や課題管理システムで4つの成果物を開き、上の質問への回答が記録されているかを見ることが具体的な確認方法になります。
AI脆弱性診断を導入する前に決めておくこと
製品とデータ処理条件を確認する
AIサービスへソースコードや設定ファイルを送信する場合、内部構成や接続情報に関係するデータが含まれる可能性があります。導入前に、対象製品の提供条件、対応言語、フレームワーク、利用プランとともに、送信するデータの範囲を確認します。
保存場所、保持期間、学習利用、委託先、越境移転などの条件は、製品やプラン、契約によって異なる可能性があります。今回の取材資料だけでは、Claude Code Securityを含む個別サービスの条件を断定できません。利用を検討する組織が、最新の公式資料と契約条件を個別に確認してください。
確認できない項目は空欄にせず、「不明」と記録します。条件が解消する前に本番のソースコードや設定ファイルを送信しない、認証情報や顧客データを診断対象から除外する、といった運用条件を決める方法が考えられます。
診断権限と実施範囲を合意する
実サイトに対する診断は、サイト所有者の許可、制作・保守契約、ホスティング事業者の規約などに左右されます。実施前に、対象環境、期間、手法、負荷、緊急連絡先を合意し、記録します。
サイト所有者から依頼を受けていても、制作会社の契約範囲に診断や修正が含まれているとは限りません。外部サービスや共用サーバーへ影響する可能性もあります。実施可否は個別の契約や規約に基づいて確認し、無許可の診断は行いません。
小規模な試行で評価する
編集部では、最初から本番システム全体を対象にするのではなく、権限を限定した検証用リポジトリや、影響の小さい対象から試す方法が現実的だと考えます。
試行では、検出件数だけでなく、次の内容を記録します。
- 人が候補を確認するために要した時間
- 誤検知として見送った件数と理由
- 採用した修正案と見送った修正案
- AIの案に追加したテスト
- 修正によって発生した不具合の有無
- サイト所有者へ説明できる成果物を作成できたか
- 従来の工程から減った作業と増えた作業
AIによって初期スクリーニングや修正案の作成を支援できても、人によるレビューが新たな負荷になる場合があります。検出件数や処理速度だけではなく、確認から承認までの総工数で評価することが大切です。
また、1回のAI診断で将来にわたる安全性が保証されるわけではありません。定期診断、ソフトウェア更新、依存関係の管理、ログ確認、バックアップ確認へつなげ、未解決事項を課題管理システムなどで継続して管理します。
まとめ
AIによる脆弱性診断は、コードベースから候補を探し、該当箇所や修正案、テスト案を提示する工程を支援できる可能性があります。一方、AIの出力だけで修正完了や安全性を判断することはできません。制作会社が検出根拠、影響範囲、修正差分、テスト結果を確認し、サイト所有者が業務影響と残存リスクの説明を受けて本番反映を承認する工程が必要です。
サイト所有者がコードを直接読む必要はありません。今日から、制作会社との課題管理画面や保守報告書を開き、次の順序で確認を始めてください。
- AIによる診断や修正支援を利用しているか、利用している場合は対象範囲を制作会社へ確認する
- 「検出一覧・修正差分・テスト結果・未解決事項」の4点を提出物として決める
- 技術的な確認者と、本番反映を承認する責任者を分けて記録する
- 検証環境、直近のバックアップ、ロールバック手順の有無を確認する
- 認証、権限、顧客データに関する問題をセキュリティ専門家へ引き上げる条件を決める
- 本番反映後に確認する画面、主要操作、エラーログと担当者を決める
現在の報告書に4つの成果物や承認者の欄がなければ、次回の修正案件から様式へ追加することが最初の一歩です。「AIが修正したか」ではなく、「誰が根拠と差分とテスト結果を確認したか」を記録できる運用へ変えることで、AIを保守工程の中に位置付けやすくなります。
出典一覧
- Anthropic「Making frontier cybersecurity capabilities available to defenders」（2026-02-20）
- Anthropic「Government of Alberta uses Claude to find and fix cybersecurity vulnerabilities across government systems」（2026-07-06）
- NIST「Secure Software Development Framework（SSDF）Version 1.1（NIST SP 800-218）」（2022-02-03）
この記事はAIが生成し、編集長のチェックを受けて公開しています。
