結論：AIコーディング時代の発注者は「早く作れるか」より「何を検査して納品するか」を見るべき
AIコーディングエージェントや生成AIによるコード生成は、システム開発の現場に急速に入り込んでいる。設計書のたたき台、API実装、テストコード、画面部品、SQL、インフラ設定まで、AIが関与する範囲は広い。
しかし、AIが書いたコードは「もっともらしく見える」ことがある。動くように見えても、認可漏れ、入力検証不足、依存ライブラリの脆弱性、秘密情報の混入、ログ不足、例外処理漏れが残る可能性がある。
発注者が見るべきなのは、開発会社がAIを使うかどうかそのものではない。重要なのは、AIを使った場合でも、どの検査、レビュー、証跡、検収条件を通してから本番に入れるか である。
押さえるべき1点：AI生成コードのリスクは「AIを使うこと」ではなく「AIが作ったものを人間とツールで検査せずに通すこと」である。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
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を使わないでください」とだけ指定しても実効性は低い。むしろ、使う場合のルールと検査条件を明文化した方が現実的である。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
最低限のセキュリティ検収チェックリスト
横にスクロールして確認できます
| チェック | 確認項目 |
|---|---|
| □ | 画面/APIごとに認証・認可テストがある |
| □ | 管理者、一般ユーザー、他部署、未ログインの権限テストがある |
| □ | SASTで重大・高リスク指摘が残っていない |
| □ | DASTまたは簡易脆弱性診断を実施している |
| □ | 依存ライブラリの脆弱性スキャンを実施している |
| □ | SBOMまたはライブラリ一覧を提出できる |
| □ | APIキー、パスワード、秘密鍵の混入検査を実施している |
| □ | エラー時に内部情報を表示しない |
| □ | ログに個人情報や秘密情報を過剰に出していない |
| □ | AI利用時の入力禁止情報とレビュー責任者が明確である |
このチェックリストは、AIを使った開発だけでなく通常のシステム開発にも有効である。AI時代の検収では、納品物だけでなく、作り方と検査証跡を見ることが重要になる。
見積もり比較で確認すべきこと
AIコーディングを使う開発会社の見積もりが安く見える場合、検査工程が抜けていないか確認する必要がある。
横にスクロールして確認できます
| 見積項目 | 安すぎる場合の懸念 | 確認質問 |
|---|---|---|
| 実装 | AI生成で短縮できる | 人間レビューは誰が行うか |
| テスト | 正常系だけなら安い | 権限・異常系・境界値テストは含むか |
| セキュリティ | 省略されやすい | SAST/SCA/秘密情報検査は含むか |
| ドキュメント | 後回しになりやすい | SBOM、運用手順、権限設計書は出るか |
| 保守 | 初期費用から外れやすい | 脆弱性対応とAI生成部分の責任範囲は何か |
AIで開発速度が上がることは悪いことではない。むしろ、正しく使えば品質向上にもつながる。問題は、短縮した工数をレビュー、テスト、セキュリティ検査へ再配分しているかどうかである。
発注者が契約前に聞くべき10の質問
-
AIコーディングツールを使いますか。使う場合、どの工程で使いますか。
-
顧客情報や秘密情報を外部AIに入力しないルールはありますか。
-
AI生成コードは人間がレビューしますか。レビュー責任者は誰ですか。
-
SAST、DAST、SCA、シークレット検出は実施しますか。
-
認可テストは画面/APIごとに実施しますか。
-
SBOMまたは依存ライブラリ一覧は提出できますか。
-
重大・高リスク脆弱性が出た場合、納品前に修正しますか。
-
OSSライセンスの確認は誰が行いますか。
-
本番リリース後に脆弱性が見つかった場合の対応SLAはありますか。
-
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検査、レビュー運用、リリースゲート |
開発費だけで比較すると、セキュリティ検収はコストに見える。しかし、リリース後に個人情報漏えいや認可漏れが発覚した場合、改修費、調査費、信用毀損、停止損失の方が大きくなる。
この記事の要点
-
AIで開発が速くなるほど、検収が弱い会社から事故る
-
発注者は「AIを使うな」ではなく「AI生成コードをどう検査するか」を契約に入れるべき
-
安い見積もりの中に、SAST、SCA、SBOM、認可テストが入っているか確認した方がよい
-
AIコーディング時代の品質は、実装力よりレビューと検査の仕組みで差が出る
次に取り組むべきこと
いきなり問い合わせに進むよりも、まず「RFP・検収条件テンプレート」を整理すると検討が進みます。
-
システム開発の発注前チェックリストで要件整理をする
-
システム開発相談で、AI生成コード利用ルール、検収条件、脆弱性診断範囲を確認する
-
既存案件で不安がある場合は、第三者レビューまたはセキュリティ診断を実施する
いつ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導入まで、発注者側の品質基準を整理します。
※ 開発中案件、納品前レビュー、既存システム診断にも対応
GXOの見解
セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。
GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。
GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。
実務判断のポイント
この記事を読むべきなのは、経営者、CIO、情シス、セキュリティ担当、開発責任者です。単に情報を把握するだけでなく、脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応の相談に進めるべきかを判断するための材料として整理する必要があります。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。AIが書いたコードを本番に入れる会社が増えた今、開発会社に求めるべきセキュリティ検収条件に関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。
GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。
GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、診断、監査、保守契約、月次レポート、緊急対応支援へ接続。さらに、チェックリスト型診断を入口に、継続監視・改善支援へ展開。
相談につながる進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
FAQ
まず何から確認すべきですか？
最初に確認すべきなのは、対象業務、対象データ、責任者、判断期限です。情報収集だけで終えると、導入可否や対応優先順位を決められません。
社内だけで進めるべきですか？
既存業務の棚卸しは社内で進められます。ただし、要件定義、セキュリティ、費用対効果、ベンダー比較が絡む場合は、外部視点を入れた方が手戻りを抑えやすくなります。
GXOにはどの段階で相談できますか？
構想段階、予算化前、RFP作成前、既存システムの見直し段階から相談できます。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応の相談を入口に、実装や運用改善まで整理できます。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
