Skip to Content
Docs08. コーディングエージェントテスト工程での活用
中級se-practicetestingquality-assurance更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

テスト工程での活用

この記事の目的

企業システム開発のテスト工程(テスト設計・テスト実装・実施・エビデンス整理)で、AI コーディングエージェントコードベースを読み、ファイルを編集し、コマンドを実行して検証するループで開発タスクを遂行する Agent。コード補完と異なり「タスク単位の委任」を受けられる。をテスト観点出し・ケース生成・テストコード/データ生成・エビデンス整理に使い分けられるようになります。あわせて、テスト工程特有の落とし穴である「エージェントが書いたコードを同じエージェントがテストする自己検証の罠」を避け、品質保証責任を人が握り続ける運用を持ち帰れる状態を目指します。

対象読者

  • テスト設計・テスト実施を担当し、テスト仕様書・エビデンスに品質責任を負う SE
  • 生成 AI でテストを効率化したいが、「生成したテストをどこまで信じてよいか」で迷っているテスト担当・品質保証担当

前提知識

本文

概要: テスト工程での使いどころと分担

テスト工程は、観点・ケース・コード・データ・エビデンスと成果物が多く定型的なため、発散・下書きの効くエージェントと相性が良い工程です。ただし「テストの妥当性を保証する責任」は人にあり、ここが揺らぐと工程の意味が失われます。

テストの活動エージェントの役割(発散・下書き)人の役割(確定・責任)
テスト観点出し観点表ドラフト・境界値/異常系の列挙観点の網羅性判断・過不足の確定
テストケース生成仕様書からのケース生成ケースの妥当性・仕様との突合
テストコード/データコード・データの生成期待値の正しさ・データの妥当性
エビデンス整理実行結果の集約・体裁整え合否判断・提出物の最終責任

なお、エージェント自体の品質を測る話は コーディングエージェントの評価 が、開発フローに常設する回帰テストは 回帰テストと評価データセットの管理 が正本です。本記事は「テスト工程の作業にエージェントを使う」話に絞ります。

テスト観点出しと境界値の列挙

テスト設計の入り口である観点出しは、発散が効く代表例です。

  • 観点表のドラフト: 仕様や機能一覧を渡し、テスト観点表のドラフトを生成させます。正常系・異常系・境界値・非機能(性能・セキュリティ)・状態遷移など、忘れがちな観点の洗い出しに向きます
  • 境界値・同値分割の列挙: 入力条件を渡し、境界値・同値クラス・組み合わせの候補を列挙させます。人が見落としやすい端点・組み合わせ爆発の候補出しに使えます
  • 網羅性の確定は人: 挙がった観点は候補です。本案件で必要な観点はどれか、業務要件・リスクに照らして過不足を決めるのは人です。エージェントは業務固有の重要度を知りません

テストケース生成と、その検証責任

仕様書からテストケースを生成できますが、ここが最も検証責任が問われる部分です。

  • 仕様書からの生成: 機能仕様・設計書から、テストケース(前提・手順・期待結果)を生成させます。定型的なケースの下書きを速く作れます
  • 期待値こそ人が確かめる: 生成されたケースの期待結果が正しいかは、仕様に照らして人が確認します。エージェントは仕様を誤解し、もっともらしい誤った期待値を書くことがあります。「テストがあること」ではなく「期待値が正しいこと」が品質の要です
  • 仕様の穴が露呈する: ケース生成中に「仕様から期待値が決まらない」箇所が出たら、それは仕様の曖昧さのサインです。テスト工程での発見を上流(要件定義・設計工程での活用)へ戻します

テストコード・テストデータの生成

テストコードとデータの生成は省力化の候補ですが、生成量だけで効果を判定せず、期待値の確認・修正・実行までの工数で比較します。

  • テストコード生成: 単体テスト・結合テストのコードを生成させます。定型的なアサーションやセットアップの記述を省力化できます
  • テストデータ生成: 境界値・異常系を含むテストデータや、匿名化したダミーデータを生成させます。本番データをそのまま使わない代替としても有効です(本番データの扱いは経路と契約に従う)
  • 期待値の独立性を保つ: テストコードの期待値を、実装の出力からそのまま起こさないようにします。実装が返した値をそのまま期待値にすると、「実装が正しい」ことの検証になりません。正当性の期待値は仕様から導きます(次項の自己検証の罠)。一方、リファクタリング・移行の等価性を確かめる characterization テストは、現行の観測入出力を基準にします。これは不具合を正しいと認めるテストではありません。レガシー理解と同様に、不一致・既知の不具合を別に記録し、修正時の期待値は要件と承認に基づいて決めます

自己検証の罠

テスト工程で最も注意すべきが、**「エージェントが書いたコードを、同じエージェントが同じ思い込みでテストする」**自己参照です。

  • 同じ誤解が両方に乗る: 実装とテストを同じエージェントが同じ仕様理解で生成すると、仕様を誤解していた場合に実装もテストも同じ方向に間違い、テストが緑でも仕様を満たしません。テストが「実装の追認」になってしまいます
  • 緩和策: (1) 期待値を人が仕様から確定する、(2) 実装とテストの生成を分離し、テスト側には実装コードでなく仕様を根拠として渡す、(3) 独立した観点(境界値・異常系)を人が追加する、(4) 重要機能はレビュー観点を変えて人がクロスチェックする
  • 緑を信頼の証拠にしない: 「テストが通った」はエージェント生成物では品質の十分条件になりません。テストの妥当性を人が見て初めて、緑に意味が出ます

エビデンス整理の自動化

エビデンス(テスト実施記録)の整理は、定型的で量が多く、自動化の効果が見えやすい作業です。

  • 結果の集約・体裁整え: 実行ログ・スクリーンショットの集約、結果一覧の作成、提出書式への整理を支援させます。手作業のコピー&貼り付けを減らせます
  • 合否判断は人: エビデンスの整形は任せられますが、合否の判断・提出物としての最終確認は人が行います。エビデンスは品質責任の裏付けであり、ここを機械任せにはしません
  • 改ざん・捏造への注意: 「エビデンスを作って」と曖昧に頼むと、実行していない結果をもっともらしく生成しかねません。実行結果の集約に限定し、実データに基づくことを人が担保します

品質保証の責任は人が握る

テスト工程全体を貫く原則は、品質保証責任の非委譲です。

  • テストは要求への適合と欠陥について判断する証拠を集めますが、合格だけで欠陥がないとは保証しません。本記事では、期待値と検証範囲を確定する担当者を置きます。法的な責任分担は契約・適用法に基づいて別途確認します
  • 「テストを AI で作った」ことは効率化ですが、「品質を AI が保証した」ことにはなりません。生成物の妥当性レビューを経て初めて、テスト工程の成果になります
  • 効率化の効果(工数削減・観点網羅の向上)は、体感でなく測って示します(コーディングエージェントの評価の考え方)

実務での注意点

アンチパターン

  • 生成したテストの「緑」を品質の証拠にする → 期待値の妥当性を見ずに合格と判断する → 期待値を仕様から人が確認し、妥当性レビューを経る
  • 実装とテストを同じエージェントに同じ根拠で作らせる → 仕様誤解が両方に乗り、テストが実装の追認になる → 期待値を人が確定し、テスト生成には仕様を根拠に渡す
  • 正当性テストの期待値を実装の出力だけから起こす → 「実装が正しい」ことの検証にならない → 要件・仕様から独立に導く。等価性を確認する characterization test は、現行の観測挙動を別の基準として記録する
  • 「エビデンスを作って」と丸投げする → 未実行の結果を捏造しかねない → 実行結果の集約に限定し、実データに基づくことを人が担保する
  • テスト観点の網羅性をエージェント任せにする → 業務固有の重要観点が抜ける → 観点は候補として扱い、過不足を人が確定する

チェックリスト

  • テスト観点は候補として扱い、業務要件に照らして過不足を人が確定した
  • 生成テストケースの期待値を、仕様に照らして人が確認した
  • 正当性テストの期待値は要件・仕様から独立に導き、等価性用の characterization test は現行挙動の記録と区別した
  • 実装と正当性テストの生成を分離し、テスト側の根拠を要件・仕様にした
  • エビデンスは実行結果の集約に限定し、合否判断と最終確認を人が行った
  • 「テストが緑」ではなく「テストが妥当」を品質の基準にした
  • テスト工程での効率化の効果を測って示している

関連トピック

参考資料

TODO・未確認事項

なし

要件定義・設計工程での活用レガシーコード理解と仕様復元