AI開発 セキュリティ指摘の是正完了証明
AI受託開発のセキュリティ指摘に対して、セキュリティ・開発・監査が是正完了を証明する手順、重大度区分、証跡、費用の見方を整理します。

結論
AI受託開発でセキュリティ診断や脆弱性検査の指摘が出たときは、「対応しました」という報告だけで終わらせず、是正完了を証明する証跡を残すことが重要です。セキュリティ、開発担当、監査が、指摘票、是正エビデンス、再検証結果を紐づけて管理すると、本番化やリリースの判断根拠になり、監査でも説明できます。
この記事は、セキュリティ指摘の是正状況が曖昧なまま本番化してしまう発注者向けに、是正の完了を証明する手順をまとめます。証明がないと、直したつもりの指摘が残り、後から問題が再発します。
是正完了証明とは何を示す記録か
是正完了証明とは、セキュリティ上の指摘一つひとつについて、対応内容、対応者、再検証の結果を紐づけ、指摘が解消されたことを示す記録です。作業完了の報告ではなく、「指摘が実際に解消されたか」を第三者が確認できる形で示すための記録です。
証明の前に、セキュリティ指摘の受付、重大度の判定、是正の責任範囲(発注者・ベンダーどちらが直すか)を整理します。誰が是正するかが曖昧だと、指摘が放置されます。
指摘の重大度区分と証跡の対応表
指摘は重大度で区分し、是正と証明の重さを変えます。表はリスク基準に合わせて調整します。
| 重大度 | 例 | 是正・証明のポイント |
|---|---|---|
| 重大 | 認証欠陥、機密情報の露出 | 優先是正、再検証必須、本番前に解消 |
| 高 | 権限設定の不備、ログ不足 | 期限内是正、再検証で確認 |
| 中 | 設定の甘さ、軽微な情報漏れ | 期限内是正、まとめて再検証可 |
| 低 | 推奨事項、改善提案 | 対応方針を記録、繰り越し可 |
| AI固有 | プロンプト経由の情報漏れ、権限外実行 | 入力制御・権限・監視で対応 |
表で区分するだけでなく、AI固有の指摘(プロンプト経由での情報引き出し、想定外の権限で動作、外部への意図しない送信)への対応を文章で確認します。AIは通常の脆弱性検査だけでは拾えない挙動があるため、入力制御、権限、ログ、人間承認、停止条件で対応し、その効果を再検証します。
是正と再検証の進め方
是正は、指摘の受付→重大度判定→是正計画→是正実施→再検証→完了証明の順で進めます。再検証は、同じ指摘が再現しないかを確認し、結果を記録します。重大な指摘は本番化の前に解消し、解消を確認してからリリース判定に進みます。是正が難しい指摘は、リスク受容の判断と、代替の緩和策を記録します。
データ・権限・ログの扱い
是正の証跡には、対応前後の状態が分かる記録を残します。個人情報や機密に関わる指摘では、影響範囲と対応を記録します。是正のために付与した一時権限は、完了後に回収します。指摘票と是正エビデンス、再検証結果を版管理し、指摘ごとの状態(未対応・対応中・完了)を追える状態にします。
費用と判断の見方
セキュリティ是正の費用は、原因がベンダーの実装に起因するなら通常はベンダー負担、発注者の要件変更に起因するなら協議になります。重大な指摘を残したまま本番化すると、事故時の損失や信頼低下が是正費用を大きく上回ります。是正の優先順位は、重大度と業務リスクで判断し、すべてを一律に扱わないことでコストと安全のバランスを取ります。
実務チェックリスト
- 指摘の受付・重大度判定の手順を決めたか
- 是正の責任範囲(発注者・ベンダー)を整理したか
- 重大度ごとに是正期限と証明の重さを決めたか
- AI固有の指摘への対応方針を確認したか
- 再検証で指摘の再現がないか確認しているか
- 重大な指摘を本番前に解消したか
- リスク受容の判断と緩和策を記録したか
- 是正用の一時権限を完了後に回収したか
チェックリストは、診断実施時、是正計画時、本番化前に確認します。指摘票と是正証跡を紐づけて残すと、リリース判定と監査の根拠になります。
図解で確認するポイント
この記事の画像は、セキュリティ指摘から是正、再検証、完了証明までの流れを、複数のカードと接続線で表しています。文字や宣伝を入れず、どの段階でどの証跡を残すかを視覚的に確認できるようにしています。
AllAI内での次の行動
まず AI発注診断 で扱う情報とリスクを整理してください。関連する実務は AI開発 第三者コンポーネント利用の開示台帳 と AI開発 受入不合格の是正期限ポリシー で確認できます。開発会社の比較は AI開発の発注支援、既製サービスの選択肢は AI/SaaS比較 も合わせて確認します。
FAQ
Q. 「対応済み」の報告だけでは不十分ですか? A. 不十分です。同じ指摘が再現しないかを再検証で確認し、対応内容と結果を紐づけて残さないと、直ったかを客観的に確認できません。
Q. AI固有のセキュリティ指摘とは何ですか? A. プロンプト経由での情報引き出し、想定外の権限での動作、外部への意図しない送信などです。通常の脆弱性検査では拾えないため、入力制御や権限、監視で対応します。
Q. すべての指摘を本番前に直す必要がありますか? A. 重大な指摘は本番前に解消します。低リスクの指摘は対応方針を記録して繰り越すなど、重大度で優先順位を付けます。
Q. 是正費用は誰が負担しますか? A. ベンダーの実装に起因するなら通常はベンダー負担、発注者の要件変更に起因するなら協議です。原因を記録して判断します。
出典と確認日
- 独立行政法人情報処理推進機構(IPA)「AIセキュリティ」: https://www.ipa.go.jp/security/ai/index.html (確認日: 2026-07-10)
- 経済産業省・総務省「AI事業者ガイドライン」: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/20260331_report.html (確認日: 2026-07-10)
- 個人情報保護委員会「個人情報保護法についてのガイドライン」: https://www.ppc.go.jp/personalinfo/legal/ (確認日: 2026-07-10)
関連する記事・ガイド
- AI開発会社ガイドBest-of-N: OpusAI開発 本番KPI未達時の契約見直し会議
AIシステムの本番KPIが未達のとき、事業責任者・PM・調達が開く契約見直し会議の論点、証跡、判断、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 検収後クレームの紛争証跡ワークフロー
AI受託開発の検収後にクレームや紛争が起きたとき、法務・PM・経理が証跡を整理するワークフロー、紛争段階、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 障害時ベンダー連絡のエスカレーション表
AIシステムの障害時に、運用・情シス・ベンダーが使うエスカレーション表の作り方、連絡基準、証跡、費用の見方を整理します。
- AI開発会社ガイドBest-of-N: OpusAI開発 運用マニュアル検収の版管理
AI受託開発で納品される運用マニュアルを、運用・品質保証・情シスが検収し版管理する手順、確認項目、証跡、費用の見方を整理します。