生成AI開発の検収で失敗しない方法
──発注者のための納品物チェックリストと承認ゲート設計

この記事で分かること（一行洞察）
「動く」コードと「使える」コードは別物──この差を検収の段階で見抜くために、AIに詳しくない経営層・事業責任者でも使える「検収5項目」と、形だけの承認を防ぐ品質ゲートの3動作（止める・承認する・残す）を解説する。

はじめに：「動いた」と「使える」は、まったく別の話

AIが書いたコードを外注先から受け取り、「問題なく動作します」と言われた。しかし本番環境に移行した途端、思わぬ不具合が次々と露見した──そんな相談が、当社に届く件数は2025年から倍増しています。

「動く」コードと「使える」コードは別物です。この差が生まれる最大の原因は、検収の設計にあります。AI生成コードに対応した検収基準を持たないまま、従来の「動作確認だけ」の受け入れ検査を続けているケースが大半なのです。

本記事では、AIに詳しくない経営層・事業責任者の方を対象に、外注AI開発の検収で「何を、どう確認すればよいか」を具体的に解説します。

第1章　なぜAI時代の検収は難しいのか

1. AIコードは「ほぼ正解」に見える

AI生成コードの失敗は「ほぼ正解なのに微妙にズレている」が大半です。大外れであれば誰でも気づけますが、見た目は整っており、デモも通る。しかし本番データや高負荷、特殊な操作パターンに触れたときに初めて問題が現れます。

コードレビューツールの実測データ（2025年）によると、AI生成コードを含む開発成果物は人間のみが書いたコードと比較して約1.7倍の品質問題を含むとされています。当社支援実績においても、AI生成コードを含む案件での検収後修正コストはそうでない案件の2倍以上になるケースが目立ちます。

2. 従来の検収基準がAI生成コードに追いついていない

「仕様どおりか」「バグはないか」を確認する従来の検収は、人間が設計・実装することを前提に設計されています。しかしAI生成コードには固有の問題パターンがあります。

• 一見動くが、特定の条件下でのみ壊れる
• 顧客データへの不正アクセスを許す欠陥が混入している（人間なら気づく箇所も、AIは無視する）
• 新機能を追加したことで既存の機能が壊れている（しかし確認されていない）
• コードが冗長で、後から人間が修正・保守できない

3. 「どこにAIを使ったか」が見えない

外注先がAIをどのように利用したかを発注者が把握できないケースが増えています。利用実態が不明なままでは、どのリスクに備えればよいかも判断できません。

第2章　2026年の潮流：検収と品質統治が「発注者の責任」になりつつある

経済産業省は2025年2月、「AIの利用・開発に関する契約チェックリスト」を公表しました。AIコードの検収に関しては、「AI利用状況の透明性確保」「人間によるレビュー責任者の明確化」が具体的なチェックポイントとして挙げられています。

また欧州のAI規制（EU AI Act）では、一定のリスク水準以上のAIシステムに対して人間による実効的監督を義務化しており、2026年8月からは適用範囲が拡大しています。

「AIが書いたからベンダーが全責任を負う」という認識は、今後通用しなくなる可能性があります。発注者側にも、検収プロセスの設計と実施責任が求められる時代が来ています。

第3章　経営層が確認すべき、外注AI開発の「検収5項目」

技術的な詳細を知らなくても判断できる、実践的なチェックリストです。発注前に外注先へ「検収条件」として提示することを推奨します。

① AI利用宣言

「このプロジェクトで、どこにAIを使ったか」を書面で示してもらいましょう。設計・コーディング・テスト生成のどの段階でAIを利用したかが明記されていることが最低限の条件です。明文化された証跡を求めてください。

② 人間レビューの責任者と範囲

AI生成コードに対して「誰が、どの範囲を、どのような観点で最終確認したか」を確認します。「チーム全員が見ました」では不十分です。担当者名と確認範囲を書面で求めましょう。

③ テスト証跡（自動テストの結果）

「テストは通っています」という言葉だけでなく、自動テストの実行結果レポートを受け取ってください。テストカバレッジ80%以上を最低条件として発注書に明記することをお勧めします。

④ セキュリティスキャン結果

AI生成コードはセキュリティ上の問題を含みやすいことが示されています。スキャンツールによる自動チェック結果で、「High」「Critical」評価の問題件数がゼロであることを確認してください。

⑤ 「壊れていない確認」──既存機能への影響チェック

新機能を追加したことで既存の機能が壊れていないかを確認するのが最後のステップです。「新しいものを足したとき、今まで動いていたものが動かなくなっていないか」を証明するテスト結果を求めましょう。

第4章　「止める・承認する・残す」──品質ゲートの3動作

検収を形式的な書類確認で終わらせないために、発注者が外注先に求めるべき「3つの動作」があります。

• 止める：AIが生成した成果物を、問題があれば先に進めない
• 承認する：確認が取れた成果物のみ次のステップへ進める
• 残す：どの判断をいつ下したか、記録として残す

この3動作が「形だけの承認」にならないようにするには、各ゲートにおいて人間が実際に判断できるだけの情報と時間が確保されている必要があります。発注者として「品質ゲートを通過した証跡を受け取る」ことが、検収を設計する最初の一歩です。

当社では、この仕組みをAI-HITL5 FrameworkのHITL5 CODE規格として体系化し、実プロジェクトに展開しています。（AI-HITL5 Framework ／ ディレクトリジャパン株式会社 提唱 ／ 2026）

AIコーディングそのものの品質管理設計（ベンダー側の5層構造）については、「AIコーディング導入後にオフショア品質が落ちる理由──HITL5 CODE 5層ゲートが解決する」もあわせてご参照ください。

第5章　当社支援実績より：検収設計で防げた3つのトラブル（すべて匿名化）

事例1：「動いた」が「使えなかった」──本番移行後のデグレ発覚

大規模リニューアル後、既存の受注管理機能が一部動作しなくなった事例。「動いた」は確認された。しかし「既存機能が壊れていないか」は確認されていなかった。本番移行後の発覚となり、ロールバックと再修正コストが発生しました。事前に「既存機能への影響確認レポート」を検収条件に加えることで、本番前の検知が可能でした。

事例2：「動いた」が「安全に使えなかった」──セキュリティ問題の発覚

外注先が大量にAI生成コードを利用して開発したWebアプリケーション。「動作する」ことは確認できた。しかし顧客データへの不正アクセスを許す欠陥が複数含まれていたことは、検収時のセキュリティスキャンで初めて判明しました。リリース前に修正できたことで、情報漏えいリスクを回避できました。

事例3：「完成」と言われたが30%が未テスト

「開発完了・テスト済み」として納品された成果物のテストカバレッジを確認したところ、対象コードの30%以上が自動テストの対象外でした。「動いた」は合っていた。しかし「すべての機能が十分に検証された」とは言えない状態でした。テスト証跡を検収条件にすることで、このような「完成未満」の納品を事前に防ぐことができます。

まとめ：まず明日、発注書に1行加えてください

AI時代の検収は「成果物が仕様どおりか」だけでなく、成果物の品質を左右した「プロセス」を確認するものへと進化します。

5項目すべてを一度に整備するのは難しいかもしれません。まず明日できることは1つだけです。次のAI開発案件の発注書に「AI利用箇所の書面開示を納品条件とする」と1行加えてください。それだけで外注先のAI利用が可視化され、検収の起点が生まれます。

外注先選びの段階から品質を担保する方法は「オフショア開発会社の比較──『開発体制と役割』から見た4タイプとその違い」もご参照ください。

よくある質問（FAQ）