AI生成コードの「テスト済み」は信用できるか
──発注者が定めるべき5つの合格基準

「デモで動いていたのに、本番で止まった」──AI活用開発の現場で繰り返されるこのパターンの多くは、テストの合格条件が曖昧なまま検収を通していることに起因します。テストを「あるか・ないか」ではなく「何を証明できているか」で評価する視点を持つだけで、AI開発の品質は大きく変わります。本記事では、発注者が発注前に定めるべき5つのテスト合格基準を具体的に解説します。

「動いた」で終わるAI開発──テストが形骸化するメカニズム

AIを活用したオフショア開発やvibe codingで「開発速度が大幅に上がった」という声が増える一方、「本番環境に上げた途端に止まった」「改修のたびに別の機能が壊れる」という報告も同時に増えています。この二面性に共通するのが、テストの形骸化という問題です。

AIがコードを書き、AIがテストコードを書き、そのテストをAIが通過させる──この構造では「正常な操作しかテストしていない」「テストコード自体が誤った検証をしている」といった問題が発注者には見えません。開発者も悪意があるわけではなく、AIが生成したテストを確認するコストが高いため、形式だけ整えて提出してしまうケースが起きやすいのです。

当社支援実績より、AI生成コードを含む納品物の事前検証において、テストが「動いた」という口頭確認のみで証跡のない状態で提出されたケースは約7割に上ります。「テストしています」という言葉を受け取るのではなく、何をどこまでテストしたかの証跡を受け取る設計が必要です。

合格基準①：カバレッジ率は「何を測っているか」まで確認する

「テストカバレッジ80%以上」は一般的な品質基準として広く使われています。しかしAI生成のテストコードでは、正常系の操作だけを網羅して高いカバレッジ数値を作り出すケースが頻繁に発生します。数字だけを見ると合格しているように見えても、実際には肝心の分岐や異常処理がテストされていません。

発注者として確認すべき質問は「80%のカバレッジはどのシナリオをカバーしているか、テスト一覧として見せてください」です。カバレッジレポートを「種類別・機能別」で受け取るよう契約に明記することで、数値の実態が見えてきます。

合格基準②：異常系・境界値テストが明示されているか

AIが生成するテストコードは「仕様書に書かれた正常なフロー」を優先的に検証するため、異常系・境界値のテストが漏れやすい構造を持っています。本番環境では、想定外の入力や外部サービスの障害が日常的に発生します。これらをテストしていなければ、正式なリリース後に初めて問題が顕在化します。

発注者として確認すべき4種の異常系テストを以下に示します。

• 空白・null・ゼロ値の入力：フォームや検索機能への空入力、数値フィールドへの0入力
• 文字数・サイズ上限を超えた入力：制限を超えた文字列、大容量ファイルのアップロード
• 同時アクセス・タイムアウト：複数ユーザーが同時に操作したとき、ネットワーク遅延が発生したとき
• 外部依存の障害：外部API・データベース・決済システムが応答しないときの挙動

受け取るテスト一覧に「異常系」の列または行が存在するかどうかを、最初に確認する習慣をつけましょう。存在しなければ追加を要求できます。

合格基準③：セキュリティテストの最低3項目

業界統計によれば、AIが生成したコードはセキュリティ面に系統的な弱点を持つ傾向があります。特に認証処理の不備・XSS（クロスサイトスクリプティング）・SQLインジェクションの3領域では、AI生成コードが人間の書いたコードより脆弱なケースが多く報告されています。

これらは、ユーザーが入力フォームを使う機能、ログインが必要な機能、データベースを参照する機能のすべてで確認が必要です。「セキュリティは開発者に任せる」では発注者として不十分で、最低限以下の3点がテストされていることを確認してください。

• 認証・セッション管理：ログインしていないユーザーが保護ページへアクセスできないか、セッション切れ後のアクセス制御は機能しているか
• XSS対策：フォームに悪意あるスクリプトを入力したとき、実行されずにエスケープ（無害化）されるか
• SQLインジェクション対策：検索フォームや入力欄に特殊な文字列を入れてもデータベースが不正操作されないか

セキュリティ面の検収をより詳しく設計したい場合は、AIコード セキュリティ検収の設計ガイドも参照ください。

合格基準④：CI/CDパイプラインでデグレを自動検知しているか

初回の納品時に全テストが通っていても、その後の改修で別の機能が壊れる──これをデグレ（デグレード）と呼びます。AI活用開発では機能追加のサイクルが速くなるため、デグレが発生しやすく、かつ発見が遅れやすい傾向があります。

これを防ぐのがCI/CDパイプライン（継続的インテグレーション／デリバリーの仕組み）です。コードが変更されるたびに自動でテストが走り、問題があれば即座に担当者へ通知します。「先週まで動いていた機能が今週から動かない」という事態を、人間が気づく前に機械が検知できます。

発注者として確認すべき点：

• コードをリポジトリへ追加（プッシュ）するたびに自動テストが走る仕組みが存在するか
• テストが失敗したときに誰に通知が届くか
• CI/CDのログ（実行記録）を発注者も確認できる環境になっているか

AI活用開発における継続的なデグレ防止の詳細については、vibe codingのデグレ防止と継続的ガバナンスもあわせてご確認ください。

合格基準⑤：テストコード自体が人間にレビューされているか

最後の、そして最も見落とされやすい合格基準が「テストコード自体を人間がレビューしているか」です。AIがコードを書き、AIがテストを書き、そのテストをAIが実行して通過させる──この構造では、テストが形式的に存在していても実質的な検証をしていない状態が生まれます。

具体的な問題の例として、テスト関数が「常にtrueを返す」アサーション（検証コード）を含んでいるケースがあります。テストは「通過」しますが、何も検証していません。AIがテストの形を作っても、中身が意味のある検証になっているかは人間が見なければわかりません。

確認すべきこと：

• テストコードのレビューを誰が担当し、その記録（レビュー履歴）はあるか
• テストコードも本番コードと同様のレビュープロセスを通過しているか
• テストが「何を確認しているか」を日本語で説明できるドキュメントがあるか

HITL5 CODEでは「TEST」層にAI/HUMAN/GATEの3構造を設け、テストコード自体の人間レビューを検収プロセスに組み込んでいます。テストが通ることと、テストが正しく設計されていることは、別の問題として扱います。

発注者が受け取るべき「テスト証跡3点セット」と検収設計

ここまで説明した5つの合格基準を実際に評価するために、契約書または発注書に明記すべき成果物があります。「テストしています」という口頭確認ではなく、以下の3点を納品物の一部として受け取るよう設計してください。

• ①テスト実行結果レポート：全テストのPass/Fail一覧、実行日時、テスト環境を含む。最新のコードに対して実行されたものであることが確認できる形式で受け取る
• ②カバレッジレポート：行カバレッジ・分岐カバレッジの種別と数値、対象機能の一覧付き。「全体80%」ではなく機能別の内訳がわかること
• ③CI/CD実行ログ：自動テストが継続的に動いている証跡。「今回だけ手動でテストした」ではなく、パイプラインが稼働していることの証明

これらを「納品物の一部」として契約書に記載することで、開発者側の設計意識も変わります。AI開発における契約と責任分界の設計全般については、AI外注の契約と責任分界ガイドも参照ください。

また、テスト合格基準全般の検収設計フレームワークは発注者のためのAI開発検収基準ガイドでも解説しています。

まとめ：テスト設計は「発注前」に確定させる

本記事で解説した5つのテスト合格基準をまとめます。

• ①カバレッジ率の中身を問う：数値だけでなく「何を測っているか」を種別・機能別に確認する
• ②異常系・境界値テストの存在：テスト一覧に異常系の行があるかを最初に確認する
• ③セキュリティテスト最低3項目：認証・XSS・SQLインジェクションは必須確認
• ④CI/CDによるデグレ自動検知：変更のたびにテストが自動で走る仕組みがあるか
• ⑤テストコード自体のレビュー：AIが書いたテストを人間がレビューした記録があるか

これらの基準は、開発が始まってから要求しても「すでに設計済み」として対応されにくくなります。発注前・契約締結時に合格条件として明記することで、開発プロセス全体の品質設計が変わります。

「テストしています」という言葉を受け取るのではなく、「テスト証跡3点セットを納品物に含める」という設計を発注の段階で仕込む。これが「動く」から「使える」へとAI開発の品質を高める最も確実な方法です。

よくある質問（FAQ）