結論：AIコーディング時代の発注者は「早く作れるか」より「何を検査して納品するか」を見るべき

AIコーディングエージェントや生成AIによるコード生成は、システム開発の現場に急速に入り込んでいる。設計書のたたき台、API実装、テストコード、画面部品、SQL、インフラ設定まで、AIが関与する範囲は広い。

しかし、AIが書いたコードは「もっともらしく見える」ことがある。動くように見えても、認可漏れ、入力検証不足、依存ライブラリの脆弱性、秘密情報の混入、ログ不足、例外処理漏れが残る可能性がある。

発注者が見るべきなのは、開発会社がAIを使うかどうかそのものではない。重要なのは、AIを使った場合でも、どの検査、レビュー、証跡、検収条件を通してから本番に入れるか である。

押さえるべき1点：AI生成コードのリスクは「AIを使うこと」ではなく「AIが作ったものを人間とツールで検査せずに通すこと」である。

AI生成コードで起きやすい問題

問題典型例発注者側のリスク
認可漏れログイン確認はあるが、他人のデータを見られる個人情報漏えい、監査指摘
入力検証不足SQL、ファイル、URL、メール入力の検証が弱い攻撃、改ざん、不正操作
秘密情報混入APIキーや接続情報がコードに残る不正利用、クラウド費用増
依存関係の脆弱性古いnpm/PHP/Pythonライブラリを使う既知脆弱性を持ち込む
例外処理不足エラー時に詳細情報を表示する内部情報露出、復旧遅延
テスト不足正常系だけ通るリリース後障害、追加費用
ライセンス不明生成物にOSS由来コードが混ざる法務・商用利用リスク

これらはAI特有の問題だけではない。従来の開発でも起きる。ただしAIで実装速度が上がると、レビューや検査が追いつかないまま納品されるリスクが高まる。

RFPに入れるべきAIコーディング利用ルール

システム開発を外注する場合、RFPや見積依頼に次の項目を入れるとよい。

項目書くべき内容
AI利用有無生成AI、AIコーディングエージェント、コード補完の利用範囲
入力禁止情報個人情報、顧客情報、秘密情報、未公開仕様を外部AIへ入れない
生成コードの扱いAI生成コードも人間レビューと自動検査の対象にする
セキュリティ検査SAST、DAST、SCA、シークレット検出、依存関係監査
SBOM主要ライブラリ、バージョン、ライセンス、脆弱性状況を提出
レビュー証跡PRレビュー、修正履歴、検査結果を納品物に含める
検収条件重大/高リスク脆弱性0件、認可テスト通過、秘密情報0件

「AIを使わないでください」とだけ指定しても実効性は低い。むしろ、使う場合のルールと検査条件を明文化した方が現実的である。

最低限のセキュリティ検収チェックリスト

チェック確認項目
□画面/APIごとに認証・認可テストがある
□管理者、一般ユーザー、他部署、未ログインの権限テストがある
□SASTで重大・高リスク指摘が残っていない
□DASTまたは簡易脆弱性診断を実施している
□依存ライブラリの脆弱性スキャンを実施している
□SBOMまたはライブラリ一覧を提出できる
□APIキー、パスワード、秘密鍵の混入検査を実施している
□エラー時に内部情報を表示しない
□ログに個人情報や秘密情報を過剰に出していない
□AI利用時の入力禁止情報とレビュー責任者が明確である

このチェックリストは、AIを使った開発だけでなく通常のシステム開発にも有効である。AI時代の検収では、納品物だけでなく、作り方と検査証跡を見ることが重要になる。

見積もり比較で確認すべきこと

AIコーディングを使う開発会社の見積もりが安く見える場合、検査工程が抜けていないか確認する必要がある。

見積項目安すぎる場合の懸念確認質問
実装AI生成で短縮できる人間レビューは誰が行うか
テスト正常系だけなら安い権限・異常系・境界値テストは含むか
セキュリティ省略されやすいSAST/SCA/秘密情報検査は含むか
ドキュメント後回しになりやすいSBOM、運用手順、権限設計書は出るか
保守初期費用から外れやすい脆弱性対応とAI生成部分の責任範囲は何か

AIで開発速度が上がることは悪いことではない。むしろ、正しく使えば品質向上にもつながる。問題は、短縮した工数をレビュー、テスト、セキュリティ検査へ再配分しているかどうかである。

発注者が契約前に聞くべき10の質問

  1. AIコーディングツールを使いますか。使う場合、どの工程で使いますか。
  2. 顧客情報や秘密情報を外部AIに入力しないルールはありますか。
  3. AI生成コードは人間がレビューしますか。レビュー責任者は誰ですか。
  4. SAST、DAST、SCA、シークレット検出は実施しますか。
  5. 認可テストは画面/APIごとに実施しますか。
  6. SBOMまたは依存ライブラリ一覧は提出できますか。
  7. 重大・高リスク脆弱性が出た場合、納品前に修正しますか。
  8. OSSライセンスの確認は誰が行いますか。
  9. 本番リリース後に脆弱性が見つかった場合の対応SLAはありますか。
  10. AI生成コードに起因する不具合の責任範囲は契約で明確ですか。

この10問に答えられない開発会社が必ず危険というわけではない。しかし、商談段階で曖昧な場合、納品前後に追加費用や責任分界の揉め事が起きやすい。

社内稟議で使える費用レンジ

対応範囲期間目安費用目安成果物
AI生成コード利用ルール策定1〜2週間30万〜80万円AI利用規程、入力禁止情報、レビュー手順
既存開発案件のセキュリティ検収設計2〜4週間50万〜150万円検収チェックリスト、RFP追記、テスト観点
脆弱性診断・SCA・SBOM整備2〜6週間80万〜300万円診断結果、依存関係一覧、修正計画
DevSecOps導入2〜4か月300万〜1,200万円CI検査、レビュー運用、リリースゲート

開発費だけで比較すると、セキュリティ検収はコストに見える。しかし、リリース後に個人情報漏えいや認可漏れが発覚した場合、改修費、調査費、信用毀損、停止損失の方が大きくなる。

SNSで共有したいポイント

  • AIで開発が速くなるほど、検収が弱い会社から事故る
  • 発注者は「AIを使うな」ではなく「AI生成コードをどう検査するか」を契約に入れるべき
  • 安い見積もりの中に、SAST、SCA、SBOM、認可テストが入っているか確認した方がよい
  • AIコーディング時代の品質は、実装力よりレビューと検査の仕組みで差が出る

記事から商談までの導線

この記事の読者には、いきなり問い合わせよりも「RFP・検収条件テンプレート」が刺さる。

  1. システム開発の発注前チェックリストで要件整理をする
  2. システム開発相談で、AI生成コード利用ルール、検収条件、脆弱性診断範囲を確認する
  3. 既存案件で不安がある場合は、第三者レビューまたはセキュリティ診断を実施する

いつGXOに相談すべきか

  • 開発会社がAIコーディングを使っているが、検査条件が曖昧
  • システム開発のRFPにセキュリティ要件を入れたい
  • AIで作った社内ツールを本番利用してよいか判断したい
  • 既存システムの認可漏れ、脆弱性、依存ライブラリが不安

GXOでは、システム開発、AI開発、セキュリティ診断、RFP整理、DevSecOps導入を組み合わせ、AI時代の開発品質を発注者側から設計する。 → 相談はこちら

関連記事

参考資料

  • ITPro "AI-generated code is fast becoming the biggest enterprise security risk" https://www.itpro.com/software/development/ai-generated-code-is-fast-becoming-the-biggest-enterprise-security-risk-as-teams-struggle-with-the-illusion-of-correctness
  • OWASP Top 10 https://owasp.org/www-project-top-ten/
  • OWASP Software Component Verification Standard https://owasp.org/www-project-software-component-verification-standard/
  • CISA "Software Bill of Materials" https://www.cisa.gov/sbom

本記事は2026年6月18日時点の公開情報と一般的なセキュリティ実務をもとに作成。個別案件の検収条件、契約責任、診断範囲は、対象システムと利用データに応じて設計する必要がある。

AI生成コードを含む開発案件の検収条件、見直しませんか

GXOでは、RFP、セキュリティ検収、AI利用ルール、脆弱性診断、DevSecOps導入まで、発注者側の品質基準を整理します。

AI時代の開発検収を相談する

※ 開発中案件、納品前レビュー、既存システム診断にも対応