結論：AIで開発が速くなるほど、発注者側の検収条件が重要になる
AIコーディングにより、画面、API、テスト、ドキュメントの作成速度は上がっている。しかし、速度が上がるほど、発注者がRFPと検収条件を曖昧にしたまま本番投入するリスクも増える。
AI生成コードは、人が書いたコードと同じく、脆弱性、ライセンス、保守性、テスト不足、責任分界の問題を持つ。違いは、見た目の完成度が高く、レビュー不足でも「動いているように見える」ことだ。
GXOでは、AI生成コードを使う開発を、DX・システム開発、システム開発の稟議・ROI診断、セキュリティ検収を含む開発管理のテーマとして扱う。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
RFPへ入れるべき条件
| 項目 | RFPに書くべきこと | 理由 |
|---|---|---|
| AI利用範囲 | 設計、実装、テスト、ドキュメントでAIを使う範囲 | 責任分界を明確にする |
| レビュー体制 | AI生成部分も人間がレビューすること | 自動生成のまま本番化しない |
| 脆弱性診断 | SAST、依存関係診断、手動レビューの範囲 | 既知脆弱性混入を防ぐ |
| SBOM | 利用ライブラリ、バージョン、ライセンス一覧 | 保守と脆弱性対応に必要 |
| テスト条件 | 単体、結合、権限、異常系、性能の合格基準 | 「動く」だけの納品を防ぐ |
| 保守責任 | AI生成コードも保守対象に含めること | 納品後の責任逃れを防ぐ |
| 禁止事項 | 機密情報を外部AIへ入力しないこと | 情報漏えいを防ぐ |
RFPにこの条件を入れておけば、AIを使う開発会社を排除する必要はない。むしろ、AIを使うなら、品質保証と説明責任まで含めて提案できる会社を選ぶべきである。
検収で見るべきポイント
-
AI生成コードの利用範囲が説明されているか
-
権限チェック、入力検証、エラー処理が実装されているか
-
依存ライブラリとバージョンが一覧化されているか
-
重要機能に異常系テストがあるか
-
セキュリティ診断の結果と修正証跡が残っているか
-
保守担当者がコード構造を説明できるか
-
納品後の脆弱性対応SLAがあるか
特に業務システムでは、権限、承認、個人情報、外部連携、帳票出力、データ更新が絡む。AI生成コードかどうかに関係なく、検収条件は業務リスクに合わせて作る必要がある。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
発注者が避けるべき失敗
失敗1：AI利用を禁止するだけで終わる
AI利用を禁止しても、実際に使われているか確認できなければ意味がない。禁止よりも、利用範囲、レビュー、ログ、納品条件を決める方が現実的である。
失敗2：画面が動いたら検収してしまう
画面が動くことと、本番で保守できることは違う。権限、異常系、性能、ログ、データ整合性まで検収対象にする。
失敗3：保守費用を見積もりに入れていない
AIで初期開発が速くなっても、保守性が低ければ運用費は上がる。発注前にシステム開発の稟議・ROI診断で初期費用と保守費用を分けて見るべきである。
90日で検収体制を作る
1〜30日目：RFPテンプレートを更新する
AI利用範囲、レビュー、脆弱性診断、SBOM、保守責任をRFPに追加する。既存の開発会社にも、次回見積もりから条件として提示する。
31〜60日目：検収チェックリストを作る
業務別に、権限、データ更新、外部連携、帳票、ログ、異常系をチェックリスト化する。受入テストをベンダー任せにしない。
61〜90日目：開発・セキュリティ・運用を同じ表で見る
開発速度だけでなく、脆弱性、保守、障害対応、運用負荷を含めて投資判断する。DX・システム開発では、この前提を要件定義から組み込む。
GXOに相談すべきタイミング
-
AIを使う開発会社に発注したいが、RFPや検収条件がない
-
既存システム改修で、品質・セキュリティ・保守が不安
-
見積もりの妥当性や保守費用を社内稟議に説明したい
-
AI生成コードを含む開発体制を監査したい
GXOは、DX・システム開発とシステム開発の稟議・ROI診断を通じて、RFP、見積比較、検収条件、保守設計まで支援する。
関連記事
参考資料
-
AI生成コード時代のRFP・検収条件を整備しませんか
開発速度だけでなく、脆弱性、保守責任、SBOM、検収条件、運用費まで含めて発注前に整理します。