結論

脆弱性診断やセキュリティレビューは、実施することよりも「指摘を潰し切ったことを証明できる状態」にすることが目的です。ベンダーから「対応済みです」という口頭・チケット上の報告だけを受けて完了扱いにすると、再診断で同じ指摘が再発する、監査で是正の証跡を出せない、インシデント時に対応履歴を示せないという3つの問題が起きます。是正完了は、指摘ごとに「是正内容の説明+設定・コードの変更証跡+再テスト結果」の3点セットで確認し、リスク受容する指摘は受容の承認記録を残す運用を型にしてください。

是正完了証明とは

是正完了証明とは、セキュリティ指摘1件ごとに、何をどう直したか(是正内容)、直したことを示す物的証跡(設定画面、コード差分、構成変更記録)、直った状態の検証結果(再診断・再テスト)をセットで文書化したもののことです。ISMSや内部監査の是正処置の考え方と同じ構造で、システム開発の委託では、この提出をベンダー義務として契約または診断計画書に定めます。

AIシステムの診断では、従来のWeb診断項目に加えて、プロンプトインジェクション耐性、出力経由の情報漏えい(学習データ・システムプロンプトの引き出し)、過剰な権限を持つエージェントの動作、APIキーの管理といったAI固有の指摘が出ます。これらは「修正」が設定変更ではなく設計変更になることが多く、是正の確認方法も攻撃シナリオの再実行が必要になる点が特有です。

指摘管理台帳の構造

診断報告書を受け取ったら、指摘を1件1行の台帳に転記して管理します。

是正期限は深刻度別に事前合意します。目安として、緊急(CVSS 9.0以上)は5営業日、高(7.0-8.9)は20営業日、中は次回定期リリース、低は四半期内が実務的な水準です。期限は診断の実施計画書に書き、保守契約の障害対応SLAとは別枠で管理します。

3区分の使い分けとリスク受容の規律

すべての指摘を「修正」で潰すのはコスト的に非現実的で、緩和策(WAFルール、権限制限、監視強化で影響を抑える)とリスク受容(業務影響と発生可能性を評価して受け入れる)を適切に使います。規律が必要なのはリスク受容で、受容の判断者(情報セキュリティ責任者以上)、受容の理由と条件、再評価の時期(次回診断時など)を台帳に記録します。ベンダーが「これは仕様です」「影響は限定的です」と受容へ誘導してくる指摘ほど、発注側の判断記録が重要です。

緩和策で完了扱いにする場合は、緩和策自体の有効性の確認(WAFルールが実際に攻撃をブロックするかのテスト)まで求めてください。「WAFを入れたので大丈夫」は証明になっていません。

再テストの設計

是正確認の再テストは、指摘した診断者(または同等の技術力を持つ第三者)による再診断が原則です。修正したベンダー自身の「確認しました」は、修正と検証の分離という基本原則に反します。定期診断の契約に「是正確認の再診断1回分」を含めておくと、追加費用の交渉なしで回せます。

AI固有指摘の再テストは、同じ攻撃プロンプト・シナリオの再実行に加えて、変形パターン(言い換え、多段の誘導)でも防御が維持されるかを確認します。プロンプトインジェクション対策は単一パターンの遮断では不十分なため、再テストの合格基準を「元の再現手順の遮断+変形Nパターンの遮断」と定義しておくのが実務的です。

契約とスケジュールへの組み込み

この運用を機能させるには、開発契約・保守契約の段階で次を入れておきます。診断の実施時期(受入テスト期間内に1回、以後年1回など)、指摘の是正費用の負担区分(開発起因の指摘はベンダー負担、設計時に合意した構成に起因するものは協議)、是正完了証明の提出義務、深刻度別期限です。特に費用負担は揉めどころで、「診断で見つかったセキュリティ欠陥は原則ベンダー負担、発注側の要求仕様に起因するものは発注側負担」という原則を先に合意しておくと、指摘のたびの交渉が消えます。IPAの「情報セキュリティ早期警戒パートナーシップ」やソフトウェア開発のセキュリティ要件の考え方も、要求仕様にセキュリティを明記する根拠として使えます。

実務チェックリスト

• 診断報告書の指摘を1件1行の台帳に転記したか
• 深刻度別の是正期限を診断計画・契約で合意したか
• 是正を修正・緩和策・リスク受容の3区分で管理しているか
• リスク受容の判断者・理由・再評価時期を記録したか
• 是正証跡(変更説明+物的証跡)を指摘ごとに回収したか
• 再テストを修正者以外が実施したか
• AI固有指摘は変形パターンを含む合格基準で再テストしたか
• 是正費用の負担原則を契約で合意したか

図解で確認するポイント

この記事の画像は、検査で見つかった項目が分類され、是正と再確認の工程を通って完了状態に収束する流れを文字なしで図解しています。指摘の発見から証明までが一本の管理された工程であることを示しています。

AllAI内での次の行動

診断前のベンダー評価はベンダーセキュリティ質問票ガイド、脆弱性診断の発注自体は脆弱性診断RFPガイドが前段のテーマです。運用中の脆弱性管理は第三者コンポーネント開示台帳の整備ガイドと接続します。セキュリティ要件を含む発注整理はAI発注診断から、対応実績のある会社はAI開発パートナーで比較してください。

FAQ

Q. 是正完了証明はどこまで細かい証跡が必要ですか? A. 深刻度で濃淡をつけます。緊急・高はコード差分または設定変更の記録+第三者再テストまで、中・低は変更内容の説明+ベンダー内テスト結果で受け入れ、次回定期診断で網羅確認する運用が現実的です。

Q. ベンダーが再診断費用を追加請求してきます。 A. 診断契約に是正確認の再診断を含めていなかった場合、請求自体は不当ではありません。次回から「初回診断+是正確認1回」をセットで契約してください。なお、ベンダーの実装ミスに起因する指摘の是正作業自体は、契約不適合の枠組みで無償を主張できる場合があります。

Q. クラウドやSaaS側の設定に起因する指摘は誰の責任ですか? A. 責任共有モデルの整理が必要です。インフラ設定を誰が構築・運用しているかで切り分け、構築をベンダーが担ったなら設定不備の是正はベンダー側です。責任分界が曖昧な指摘こそ、台帳で「対象」と「是正担当」を明記する価値があります。

Q. 診断は毎年必要ですか? A. 外部公開のAIシステムなら年1回+大きな構成変更時が目安です。モデルの入れ替え、新しいデータソースの接続、エージェント機能の追加は攻撃面が変わるため、定期診断を待たずに差分診断を検討してください。

出典と確認日

• IPA「情報セキュリティ早期警戒パートナーシップガイドライン」: https://www.ipa.go.jp/security/todokede/vuln/guide.html (確認日: 2026-07-10)
• IPA「安全なウェブサイトの作り方」: https://www.ipa.go.jp/security/vuln/websecurity/about.html (確認日: 2026-07-10)
• 経済産業省「AI事業者ガイドライン(第1.2版)」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
• OWASP「OWASP Top 10 for Large Language Model Applications」: https://owasp.org/www-project-top-10-for-large-language-model-applications/ (確認日: 2026-07-10)