受託開発のAI時代における品質保証｜実務ガイド

「GitHub Copilotを開発に導入したら、コード量は1.5倍になったのにレビュー工数も増えて、結局リリースが遅れた」「クライアントから『AIで作ったコードでも瑕疵担保責任は同じですよね？』と聞かれて即答できなかった」。受託開発の現場でAIコーディング支援ツールの利用が広がるなか、こうした声をPMの方から伺う機会が増えました。受託開発のAI時代における品質保証は、従来の単体テスト・結合テスト・受け入れテストの延長では捉えきれない論点を含んでいます。本記事は、生成コードの検証技術・契約上の責任範囲・クライアントへの説明責任という3層構造で、現場のPMが今日から組み立てられる品質保証の実務ガイドとしてまとめました。

受託開発でAI活用が進むほど品質保証が難しくなる3つの理由

AIコーディング支援はエンジニアの生産性を底上げする一方で、品質保証の難度を確実に押し上げています。理由を分解すると、技術・契約・コミュニケーションの3層に分かれます。

理由1: 生成コードは「正しそうに見えて間違っている」確率が高い

AIが出力するコードは構文が整っており、命名規則も妥当で、一見してレビューしやすい体裁です。しかし要件との照合という観点では、人間のエンジニアが手で書くコードよりも誤りが発見されにくい性質があります。これは「もっともらしさ」と「正しさ」が一致しないためです。境界値の扱い、null安全性、想定外の入力に対するフォールバック処理など、要件書には明記されないがドメイン知識として暗黙に共有されている部分で、AIは独自の補完を行います。

レビュアー側も、人間が書いたコードであれば「なぜこう書いたのか」を著者本人に確認できますが、AI生成コードでは設計意図が記録に残らず、レビューが表層的になりがちです。高橋寿一氏は『知識ゼロから学ぶソフトウェアテスト』第10章でAIをとりまくテストについて、「AIソフトウェアのテストは基本的に普通のソフトウェアテストと同じ構造を持つ」としつつ、検証の観点はむしろ厳しく設計する必要があると論じています。

実務でよくあるパターンとして、AIが「業界標準的な実装パターン」で書いたコードが、自社の既存システムの作法と微妙にずれているケースがあります。例えば日付フォーマットがyyyy/MM/ddで統一されているシステムに、AIがyyyy-MM-dd形式を混ぜ込むと、画面表示は問題なく見えても、CSV出力や外部連携処理で初めて齟齬が顕在化します。こうした「動くけれど揃っていない」コードは、テスト工程の後半まで発見されにくく、発見時の修正コストが高くなります。

理由2: 契約上の責任範囲が従来の枠組みで割り切れない

受託開発契約の多くは2020年4月施行の民法改正で契約不適合責任の枠組みに移行しました。仕様書との不一致や、契約の趣旨に照らした品質欠如があれば、修補・代金減額・損害賠償の対象になります。ここで論点になるのが「AIが生成したコードに含まれていた既知の脆弱性」「学習元コードのライセンス侵害リスク」「再現性のないバグ」をどこまで受託側が負うか、です。

民法上は受託側がツール選定の責任を負うのが原則ですが、AIツールの利用がクライアントから明示的に要請されたケースや、共同開発の建付けで実施したケースなど、ケースバイケースで責任の所在が変わります。契約書に「AI活用範囲と責任分界点」を明記していないと、リリース後のトラブル時に交渉が長期化する事例が増えています。

特に問題になりやすいのが「再現性のないバグ」です。AIが生成したコードに含まれる微妙な競合状態やタイミング依存の不具合は、再現が難しく、原因究明に時間がかかります。再現困難な不具合は本来、瑕疵の存在自体を立証する側が難航するのですが、AI生成コードであることを契約上どう扱うかが事前に整理されていないと、「AIが書いたのだから受託側で全て直すべき」という主張と「再現できない以上修補義務はない」という主張が衝突します。事前合意の有無で交渉コストが大きく変わるため、契約段階でのすり合わせが重要です。

理由3: クライアントが「AIだから安心」「AIだから心配」のどちらにも振れる

経営層からの「AIで効率化できるはずだから工数を圧縮してほしい」という圧力と、現場担当者からの「AIが書いたコードを本当に信用していいのか」という不安が、同じプロジェクトの中で両立することがあります。受託開発のPMはこの両端の温度差を受け止め、品質保証の根拠を技術用語抜きで説明する力が求められます。

「AIを使ったか／使わなかったか」ではなく、「どこにどのテストを通したか」「どんな検証プロセスを経たか」を説明できる状態にしておくことが、信頼維持のコア能力になります。

例えば「コーディング工数の30%をAI支援で短縮したが、テスト工数は従来比10%増で実施し、レビュー観点を5項目追加した」といった事実ベースの説明ができれば、クライアントの不安は具体的な納得感に変わります。逆に「AIを活用して効率化しました」だけで終わると、品質に対する裏付けが見えず、不信感の原因になります。

受託開発のAI時代における品質保証の全体像 — V字モデル再定義

従来のV字モデルは要件定義から受け入れテストまでを一直線に結んだプロセスでした。AI活用が前提となる現在は、左辺（要件・設計）と右辺（テスト）の間に「AI生成成果物の検証ループ」を組み込む必要があります。

左辺の変化: 要件をAIが解釈できる粒度まで分解する

AIにコード生成を任せる前提では、要件定義を従来よりも構造化された形で記述する必要があります。曖昧な要件をAIに渡すと、AIは「もっともらしい解釈」で補完してしまい、後工程で発覚する手戻りが発生します。

具体的には、機能要件を以下の3層で文書化することが有効です。

• 業務要件（ユーザーが達成したいゴール）
• 機能要件（システムが提供する振る舞い）
• 受け入れ基準（合否を判定する観点）

受け入れ基準を「正常系・異常系・境界条件」の3視点で先に書いておけば、AIへの指示文（プロンプト）の品質も上がり、生成コードと受け入れテストの整合性が確保しやすくなります。

例として、ECサイトのクーポン適用機能を実装する場合、要件を以下のように分解しておきます。

• 業務要件: ユーザーが購入時に割引を受けられる
• 機能要件: 入力されたクーポンコードが有効期間内かつ未使用なら、設定された割引率を商品合計に適用する
• 受け入れ基準（正常系）: 有効なコードで指定の割引率が適用される
• 受け入れ基準（異常系）: 期限切れ・存在しない・既使用のコードでは適用されずエラーメッセージが表示される
• 受け入れ基準（境界条件）: 有効期限ちょうどの日時、最低利用金額ちょうど、複数クーポン同時適用時の優先順位

この粒度で要件が書かれていれば、AIに渡すプロンプトも自然と詳細になり、生成コードに対するテストケースも要件から1対1で導出できます。

右辺の変化: テスト層ごとに「AIが書いたか」を意識する

V字の右辺、つまりテスト工程では、テストレベルごとに「AI生成コードに対する追加の確認観点」を上乗せします。

テストレベル	従来の主目的	AI時代に追加すべき観点
単体テスト	関数単位の正常動作	プロンプトに含めなかった暗黙ルールの逸脱検出
結合テスト	モジュール間連携	命名規則・例外処理パターンの統一性
システムテスト	機能・非機能の総合確認	ライセンス・依存ライブラリの混入チェック
受け入れテスト	クライアント観点の合否判定	AI活用範囲の説明とトレーサビリティ提示

中央のループ: 生成→検証→再生成の反復管理

受託開発のAI時代における品質保証では、要件と実装の間に「AI生成と検証の小さなループ」が複数回回ります。このループを回した回数・通過したテスト・残った課題を記録に残せる仕組み（プロンプトとレビュー結果のログ管理）が、後工程の信頼性を支えます。

IPAが運営するAIセーフティ・インスティテュート（AISI）は、AIシステムの安全性評価ガイドラインを継続的に整備しており、開発プロセス全体での記録性が今後ますます重視されると示唆しています（参考: AIセーフティ・インスティテュート公式サイト）。

なお、品質保証の体制を見直そうとしても、社内に専任のテストエンジニアがいないために動き出せないケースも多くあります。社内体制の選択肢を整理した記事としてテストエンジニアがいない開発会社が取れる3つの選択肢も参考にしてください。

AI生成コードの品質を担保する5つのテスト観点

ここからは具体的なテスト観点に落とし込みます。AI生成コードを通常コードと同じテストプロセスに乗せるのは前提として、追加で意識すべき5つを示します。

観点1: 暗黙仕様の境界値テスト

AIは要件書に明示された数値範囲については正しく扱う傾向がありますが、「業務上当たり前」とされている暗黙の境界（営業日、消費税の端数処理、年度切り替え時刻など）で躓きます。同値分割と境界値分析を、暗黙仕様にこそ重点的に適用してください。

特に注意したい暗黙境界の例を挙げます。

• 月末判定（28日／30日／31日／うるう年2月29日）
• 営業日・祝日カレンダー（年末年始、ゴールデンウィークの跨ぎ）
• 消費税計算の端数処理（切り上げ／切り捨て／四捨五入）
• 文字コード（半角カナ、絵文字、サロゲートペア）
• タイムゾーン（サマータイム、UTC変換）

これらは要件書に書かれていなくても、業務上当然に正しく動くことが期待されます。AIが生成したコードがこれら全てに対応しているとは限らないため、テスト計画に暗黙境界のチェックリストを組み込んでおくと安心です。

観点2: 学習データ起因の偏りに対するメタモルフィックテスト

AIが過去のオープンソースコードから学習しているため、特定のパターン（例: SQL文字列連結、英語圏前提の日付フォーマット）に偏った実装を提案することがあります。同じ業務ロジックに対して入力をわずかに変化させたとき、出力が想定通り対応関係を保つかを確認する「メタモルフィックテスト」の発想が有効です。高橋寿一『知識ゼロから学ぶソフトウェアテスト』では、メタモルフィックテストをAI時代の新しいテスト技法として紹介しています。

観点3: 例外処理・null安全性のコードレビュー観点

AI生成コードはハッピーパス（正常系）に強く、例外処理は雑になりがちです。try-catchの握りつぶし、nullチェック漏れ、リソース解放忘れといった「動くけれど壊れやすい」コードが混入します。レビュー観点を以下のように標準化しておくと検出率が上がります。

• 例外を握りつぶしていないか（最低限ログ出力があるか）
• 外部依存呼び出し前後でnull/undefined判定があるか
• ファイル・接続・トランザクションの解放が確実か
• 非同期処理のエラーが伝播するか

観点4: ライセンス・脆弱性スキャン

AI生成コードに、学習元のOSSライセンスに抵触する記述や、既知の脆弱性パターンが混入していないかを機械的に確認します。GitHub Advanced Security、Snyk、OWASP Dependency-Checkなどのツールを、CIパイプラインに組み込むのが現実的です。受託開発では納品物全体に対する責任を負うため、生成コードか手書きコードかを問わず、同一基準でスキャンを通すことが原則です。

観点5: トレーサビリティ確保のためのプロンプト・レビュー記録

「このコードはどのプロンプトから生成され、どのレビューを経て採用されたか」を残しておくと、後でバグが発覚したときの調査時間が大幅に短縮されます。GitのコミットメッセージにAI生成箇所を明記する、PRテンプレートに「AI活用区分」のチェック項目を入れる、といった軽量な仕組みで十分機能します。

これらの観点を、すべて自社で内製化するのが難しい場合は外部のテスト専門会社に部分委託する選択肢もあります。費用感の目安はテスト代行の費用相場と中堅IT企業のリアルな見積もりで具体例とともに解説しています。

AI生成コードと契約不適合責任・瑕疵担保責任の整理

技術論と並ぶもう一つの軸が契約論です。2020年改正民法以降、受託開発契約では「契約不適合責任」が中心概念になりました。AI活用を前提とした契約では、以下の論点を契約書または覚書に明記しておくことを推奨します。

論点1: AIツール選定の責任主体

開発に使用するAIツール（GitHub Copilot、Cursor、ChatGPTなど）の選定責任を、受託側・委託側のどちらが負うかを明示します。受託側が選定する場合は「業務遂行のための合理的なツール選定の範囲内で」という限定を付けるのが一般的です。クライアント指定のツールを使う場合は、ツール起因の不具合・情報漏洩リスクを委託側に帰責する条項を入れます。

論点2: 生成コードの著作権・ライセンス

AI生成コードの著作権の帰属、第三者ライセンスの混入が判明した場合の対応（差し替え・損害賠償の範囲）を定めます。多くの生成AIサービスは利用規約で「出力物の著作権は利用者に帰属する」と明記していますが、学習データのライセンス侵害責任については別途整理が必要です。

論点3: 検収基準への明記

検収条件に「AI生成コードか手書きコードかを問わず、合意したテスト計画書に記載のテストを全項目通過していること」と明記すると、後で「AIで書いたから品質が低くて当然」といった理屈が通らなくなります。クライアント側にもこの基準を事前合意してもらうことで、検収段階のトラブルを未然に防げます。

論点4: 不具合発覚時の対応窓口

リリース後に発覚した不具合について、修補期限・代替案提示の手順を契約に書き込みます。AI起因と判断される不具合（学習データの誤り、生成時の幻覚など）も、契約不適合の判定は「成果物が契約に適合しているか」で行うため、原因がAIであることは免責事由になりません。これは現場のPMが特に誤解しやすいポイントです。

論点5: 情報セキュリティ

クライアントの機密コードや顧客データを、AIツールに入力してよいかどうか、入力する場合の匿名化基準を明記します。総務省・経済産業省が公表する各種AIガイドラインや、IPAのAI推進に関する取り組み（参考: IPA AIの推進）を参照しつつ、自社のセキュリティポリシーに落とし込むのが現実的です。

法的論点については弁護士の関与が望ましく、本記事の整理はあくまで実務上のチェックリストとして捉えてください。

受託開発のAI時代における品質保証を支えるQA体制モデル

中小規模の受託開発会社にとって、専任QA組織を持つことは現実的でない場合が多いはずです。ここでは段階的に体制を強化していくためのモデルを示します。

モデルA: 兼任型（プロジェクト規模 〜30人月）

PMまたはテックリードがQA役割を兼任し、テスト計画・受け入れ基準の設計を担います。AI活用の判断もこの役割が一括して握ります。チームメンバーは開発・テストを兼任し、リリース前の1〜2週間を集中テスト期間として確保します。

このモデルの弱点は、リリース直前にテスト工数が偏ること、PMの稼働が逼迫してテスト品質が落ちることです。リリース直前の対処法についてはリリース直前にテストが間に合わない時の判断軸で詳細に整理していますので、慢性的に間に合わないチームは合わせてご覧ください。

モデルB: QAリード設置型（プロジェクト規模 30〜100人月）

専任ではないものの、QAの責任を持つメンバーを1人指名します。このQAリードがテスト計画の標準化、テストケース管理ツールの導入、AI生成コードのレビュー基準作成を担います。開発メンバーは引き続きテストを兼任しますが、QAリードがテストの優先順位と打ち切り基準を判断する権限を持ちます。

モデルC: 内製＋外部委託のハイブリッド型（プロジェクト規模 100人月以上）

社内のQAリードが計画・基準を作り、テスト実行の大部分を外部のテスト専門会社に委託するモデルです。AI生成コードに対する観点設計は社内、リグレッションテスト・互換性テストなど反復作業は外部、という役割分担が現実的です。クライアントによっては「複数ベンダーの目」を入れることで品質説明力が増す効果もあります。

ハイブリッド体制の作り方や費用感、ベンダー選定のポイントについては中小企業向けテスト代行の選び方で詳しく解説しています。

体制設計の判断基準

どのモデルを採るかは、月次のテスト工数の振れ幅で判断するのが実践的です。直近6か月のプロジェクトでテスト工数のピーク／平均が2倍以上に振れているなら、ピーク対応を外部に逃がせるハイブリッド型を検討する価値があります。

具体的な判断シートとして、以下の項目を四半期ごとにチェックすると、体制移行の判断材料が蓄積できます。

• リリース直前1週間のテスト残業時間（チーム平均）
• リリース後30日以内に発覚した不具合件数
• クライアントから品質に関する指摘・問い合わせを受けた回数
• AI生成コードに起因すると判断された不具合の比率
• テスト計画書・テストケースの作成にかかった工数

これらの数値が悪化傾向にあるなら、体制の見直しを検討するタイミングです。逆に安定している場合は、現状の体制を継続しつつ、AI活用範囲の拡大を段階的に進める方針が取れます。

なお品質保証体制を補強するうえで、テスト工程の現状データを参照する場合は、IPAが公開してきたソフトウェア開発分析データ集が業界平均との比較に役立ちます。

クライアントへの説明責任を果たす品質保証の伝え方

受託開発のPMにとって、技術的な正しさだけでは品質保証は完結しません。クライアントが納得する形で「うちの会社はこう品質を担保しています」を提示できることが、受注継続にも次案件獲得にも直結します。

説明資料の3部構成テンプレート

提案書・報告書には以下の3部構成を組み込むことを推奨します。

第1部: AI活用範囲の明示

• どの工程でAIを使うか／使わないか（例: コーディング支援は使う、テストケース生成は人手）
• 使用ツール名と利用区分（社内アカウント／クライアント環境）
• 入力情報の取り扱い方針（機密情報の入力可否）

第2部: 品質担保プロセスの可視化

• レビュー体制（誰が、何人で、何を見るか）
• テスト計画（テストレベル別の観点と通過基準）
• AI生成コードに対する追加チェック項目
• ライセンス・脆弱性スキャンの実施タイミング

第3部: 説明責任の担保

• プロンプト・生成履歴の保存期間
• バグ発生時の調査フロー
• 第三者検証の有無（外部テスト会社の関与等）

クライアントへの会話例

経営層から「AIで効率化して安くしてほしい」と言われた場合の返答例として、「AIによる開発スピード向上は確かに見込めますが、品質保証の工程は同等以上を維持するため、全体工数の圧縮幅は概ね1〜2割を上限と想定しています。これを超えた圧縮を行うとリリース後の不具合対応工数が増え、結果的に総コストは上がる傾向があります」といった伝え方が、現実的な期待値調整になります。

「AIで作ったコードでも安全ですか？」という問いに対しては、「使用したかどうかではなく、どんなテストとレビューを通したかで品質を保証しています」と原則を伝えた上で、上記の3部構成資料を提示すれば、技術用語に不慣れな相手にも納得感を持ってもらえます。

さらに踏み込んだ質問として「他社ではAIを使った開発でトラブルが起きた事例があると聞いたが、御社は大丈夫か？」と問われることもあります。この場合は、自社のリスク管理体制を3つの観点で簡潔に説明します。第一に「AIが生成したコードも人間が書いたコードと同じテスト基準を適用していること」、第二に「ライセンス・脆弱性スキャンを自動化していること」、第三に「リリース後に問題が発覚した場合の対応フローが事前に定義されていること」です。この3点を提示すれば、抽象的な不安を具体的な安心材料に置き換えられます。

社内向けのナレッジ整備

クライアント説明の質を上げるには、社内のPM間で説明テンプレートを共有することが効果的です。1人のPMが工夫した説明資料を、社内Wikiやドキュメント管理ツールに集約し、新規案件のキックオフ時に参照できるようにしておくと、組織全体の説明力が底上げされます。

テスト関連のノウハウを体系的に蓄積したい場合は、テストに関するホワイトペーパー集も社内勉強会の素材として活用いただけます。

自社だけでAI品質保証が難しい場合の選択肢

ここまで紹介した内容を完全に内製化するのは、中規模以下の受託開発会社にとってハードルが高いのが実情です。最後に、外部リソースを使った現実的な進め方を整理します。

段階1: テストプロセスの第三者レビュー

自社で作ったテスト計画書・テストケースを、外部の専門家にレビューしてもらう形式です。実行は自社で行うため費用を抑えられ、AI生成コードへのテスト観点が漏れていないかを客観的にチェックできます。

段階2: スポット委託

リリース前の集中テスト期間だけ、外部テスト会社に作業を委託します。受け入れテスト・互換性テスト・回帰テストなど、明確に切り出せる範囲を選ぶと費用対効果が出やすくなります。

段階3: 継続パートナーシップ

複数プロジェクトを通じて同じテスト会社と継続的に組み、社内のQAリードと外部チームが連携してテスト戦略を回します。AI活用の方針も含めて長期的な品質保証パートナーになる形態です。

どの段階から始めるかは、現状のテスト工数の逼迫度合いと、クライアントへの説明責任の重さで判断してください。「次回案件からまず一度、第三者の目を入れてみる」だけでも、社内では気付かなかった改善点が見えてくることが多くあります。

まとめ — AI活用時代の受託開発QAは「説明できる品質」への転換

受託開発のAI時代における品質保証は、生成コードの技術検証だけでなく、契約上の責任範囲とクライアントへの説明責任を同時に設計する仕事です。本記事で扱った3層構造、5つのテスト観点、QA体制モデル、契約論点、説明資料テンプレートを、自社の状況に合わせて取捨選択していただければ、明日からの実務に役立てられるはずです。

特に強調しておきたいのは、「AIを使ったかどうか」を品質保証の論点にしないことです。「どんなテストとレビューを通したか」「その記録は残っているか」「クライアントに説明できるか」という、説明可能性の確保こそが、AI時代に受託開発が信頼を維持するための核です。

社内のテスト体制やQAプロセスの見直しを検討されている方は、現状の課題整理から一緒に進められますので、お気軽にご相談ください。実プロジェクトの体制や工数に即した形で、無理なく始められる進め方をご提案いたします。

テスト体制についての無料相談はこちらから