AIで開発やテストケースの作成が速くなっても、重大な不具合を見つけられるとは限りません。わたしたちギグワークスクロスアイティは、AIを利用した開発を実践し、AI駆動開発の研究にも取り組んでいます。E2Eテストでは業務上のリスクを踏まえて検証対象を選び、想定した故障を検出できるか確かめます。テストの安定性と公開後に見つかった障害も、次のテストを設計する手掛かりです。

【関連記事】AI開発がうまくいかない理由とは？Superpowersは何を変えるのか

ギグワークスクロスアイティは、AIを利用した開発を実践するとともに、AI駆動開発の研究に取り組んでいます。AIによって開発やテストケースの作成が速くなっても、重大な不具合まで検出できるとは限りません。E2Eテストの品質を判断するには、リスクに基づいて検証対象を選び、想定した故障をテストが検出できるか確かめる必要があります。さらに、テストが安定して動くか確認し、公開後に見つかった障害を次のテスト設計に反映します。

テスト件数とカバレッジだけでは品質を測れない

E2Eテストでは、利用者の操作からデータの更新まで、業務が正しく進むか確認します。AIを使えば操作手順や入力値を変えたテストを短時間で作れますが、似た条件ばかりを試しても、重大な障害を見逃しかねません。

カバレッジで分かること、分からないこと

要件カバレッジとは、定義した要件のうち、対応するテストを用意できた要件の割合です。シナリオカバレッジは、対象とする業務シナリオのうち、テストで実行したシナリオの割合を指します。コードカバレッジは、テストで実行した命令や分岐の割合です。どの指標も未検証の範囲を見つける手掛かりになりますが、テストが不具合を検出できるかまでは分かりません。

例えば、シナリオ一覧に通常の購入と取消しだけを載せていれば、その2件を実行した時点でシナリオカバレッジは100％になります。通信が切れた直後の再送や二重クリックが一覧から漏れていても、数値には現れません。要件にテストを割り当てただけでは、そのテストが正しい結果を確かめているか分かりません。

コードカバレッジが高くても、テストが不具合を見つけられるとは限りません。権限確認の処理が実行されていても、他人の情報が表示されたときにテストが失敗するよう設計されていなければ、不具合を見逃します。ISTQBのシラバスは、コードを実行した事実だけでは欠陥の検出を保証できないと説明しています。

要件やシナリオが一覧から漏れていれば、カバレッジの計算にも表れません。割合を集計する前に、要件や利用者の操作、過去の障害、製品リスクを照らし合わせ、検証対象に漏れがないか確認しましょう。コードカバレッジは未実行の処理を探すのに役立ちます。E2Eテストでは、業務上の結果に加え、システム間でデータが正しく連携しているかも確かめます。

「正しい結果」を決めずにテストすると不具合を見逃す

E2Eテストで「画面が表示される」「エラーが出ない」ことだけを確かめても、注文金額や保存されたデータの件数が間違っていれば不具合を見逃します。権限のない利用者が操作できてしまう場合もあります。予約画面に「予約完了」と表示されても、残りの枠が減っていなければ、別の利用者も同じ枠を予約できてしまいます。画面の表示に加えて、予約件数と残りの枠数が正しいかを確認しましょう。

ISTQBの2026年版アジャイルテストシラバスも、要件、コード、リスクのカバレッジを目的に応じて使い分けるよう示しています。コードカバレッジを品質の代わりにせず、実行や保守に時間のかかるE2Eテストは重要な業務フローやシステム連携に絞る考え方を紹介しています。

正常系の入力値を増やす前に、利用者に損害が及ぶ条件や業務が止まる条件を洗い出しましょう。重大な障害につながる動作を特定し、それを検出するテストと、テストで確認する結果を決めます。

「予約できる」という要件に加えて、満席なら予約を確定できないこと、本人以外は予約を変更できないこともテストで確かめましょう。画面に表示される内容だけでなく、保存されるデータがどう変わるかも決めておきます。

実装とテストで同じ誤解を引き継がない

実装コードを作ったAIに同じ会話でテストも作らせると、仕様の誤解がテストにも引き継がれるおそれがあります。例えば、取消期限を「予約前日まで」と定めた仕様を「当日まで」と取り違えると、誤った取消処理を正しいと判定するテストが作られます。

2026年に公表された研究では、仕様だけをもとにテストを作った場合、不具合の検出率は約25％でした。誤ったコードを先に生成し、それをもとにテストを作った場合は約14％でした。この研究はPythonのプログラミング課題と単体テストを対象としており、業務システムのE2Eテストを調べたものではありません。実装の誤りがテストにも引き継がれると、不具合を見つけにくくなる可能性があります。

実装コードを確認する前に、業務要件と受入条件から重要なシナリオと期待結果を決めましょう。テスト設計には別のAIを使うか、実装時の会話履歴を引き継がない新しい会話を使います。先に決めた期待結果と実装を照らし合わせれば、同じ誤解をもとに実装とテストが作られるのを防ぎやすくなります。期待結果は、業務担当者とテスト担当者が確認して確定します。

テストには、操作手順だけでなく、作成されるデータの件数や閲覧できる利用者も記します。処理が完了したか分からないまま同じ要求を再送した場合に、どうなるべきかも決めておきましょう。実装後にテストコードを作る場合も、あらかじめ決めた期待結果に沿って作成します。実装の動作を見てから期待結果を決めると、実装に含まれた誤解をテストでも正しいと判定しかねません。

重大なリスクを選び、テストが故障を検出できるか確かめる

リスクベーステストでは、障害が起きたときの影響を考えて、検証する対象と順番を決めます。故障ベーステストでは、重大な損失につながる故障を想定し、その状況を再現したときにテストが失敗するかを確かめます。

発生の可能性と影響から優先順位を決める

優先順位を決めたら、リスクごとに適切なテストを割り当てます。E2Eテストでは、通信の遅延や再送による二重処理、他人の情報へのアクセス、取消済みデータの再処理などを確認します。外部サービスの停止でデータの一部だけが更新される問題や、同時操作による在庫と予約の不整合、日付や時差による締切の誤判定も検証対象です。

リスクごとに、障害が起きる条件、利用者や事業への影響、障害時に保つ状態、検出するテスト、担当者を記録します。たとえば、決済完了直後に応答が途切れ、同じ要求が再送されても、請求と決済記録がそれぞれ1件だけ残ることを期待結果にします。こうしてリスクごとに期待する結果を決めておけば、テストで何を確かめたのか明確になります。

リスクカバレッジとは、重要なリスクのうち、対応するテストに合格し、期待した結果を確認できたものの割合です。ただし、人命にかかわる障害、法令違反、大規模な情報漏えい、金銭の消失につながるリスクは、全体の割合だけでは判断できません。こうしたリスクを確認するテストが未実施または不合格なら、ほかの指標が高くてもリリースを承認しない運用が必要です。

エラーを起こし、検出できるかを確かめる

決済処理の正常系で商品や金額だけを変えても、二重請求を見つけられるとは限りません。サーバーで決済が完了した直後に応答を遮断し、クライアントから同じ要求を再送します。請求と決済記録がそれぞれ1件だけ作られ、在庫も1回だけ更新されたかを確認すれば、二重請求につながる故障を検証できます。

Mutation Testingは、条件式の反転、権限確認の削除、重複防止処理の無効化など、コードに意図的な不具合を加え、既存のテストが失敗するか確かめる方法です。Mutation Scoreは、有効な変異のうちテストが検出した割合を示す指標です。Metaは、プライバシー違反などの故障を再現する変異と、その故障を検出するテストを生成しています。

外部サービスやメッセージキューを含むシステムでは、Fault InjectionやChaos Engineeringを使って、タイムアウトや応答の欠落、メッセージの重複・順序変更、処理中の再起動などを起こします。業務全体に影響する故障はE2Eテストで確かめ、再試行回数や例外処理の細部はAPIテストや結合テストで調べます。故障の細部までE2Eテストで確認すると、実行時間が延び、失敗の原因も分かりにくくなります。

組合せテストで条件の相互作用を調べる

境界値や予約状態、利用者の権限、端末、外部サービスの稼働状態をすべて組み合わせると、テスト数は急増します。NISTの調査では、調べたソフトウェア障害の多くは1個または2個の条件に関連し、発生に必要な条件が増えるほど該当する障害は少なくなりました。

pairwise testingでは、任意の2条件の値の組合せを、テスト全体で少なくとも1回ずつ確認します。t-way testingでは、対象を任意のt個の条件の組合せまで広げます。こうした手法を使うと、多くの条件の相互作用を効率よく調べられます。一方、二重請求や権限違反のように想定できる故障は、発生条件を指定したテストで直接確かめましょう。条件の組合せを網羅しても、正しい結果を確認できなければ不具合を見逃します。

指標ごとに何を測るか明確にする

テストの網羅性や安定性、公開後の障害を把握するには、指標ごとに何を測るのか決めておきましょう。

• リスクカバレッジ：特定した重要リスクのうち、対応するテストが合格し、期待どおりの結果を確認できたものの割合
• 重要シナリオカバレッジ：必須とした業務フロー、状態遷移、権限、障害条件のうち、合格したテストで確認できた項目の割合
• Mutation Score：注入した有効な変異のうち、対象のテスト群が検出した割合
• フレイキーテスト率：同一コミット、同一条件の初回実行と再実行で、成否が反転したテストの割合
• 本番流出欠陥率：テスト工程と本番で見つかった欠陥の合計に対する、本番で見つかった欠陥の割合
• Change Fail Rate：公開後に緊急修正やロールバックが必要になった変更の割合

Mutation Scoreは、単体テスト、APIテスト、E2Eテストのどのテスト群で測定したかも記録します。単体テストが検出した変異をE2Eテストだけの成果として数えると、検出能力を誤認します。フレイキーなテストが再試行で合格しても、初回の失敗を集計に含めます。GitLabも同じコミットで失敗後に成功したテストをフレイキーとして検出しています。重要なテストを一時的に隔離した場合は、隔離した件数と期間を記録します。隔離中も失敗原因を調べ、製品の不具合を環境の問題として見過ごさないようにします。

本番流出欠陥率には、重大度別の件数も添えましょう。全体の欠陥率だけでは、件数が少ない重大な障害を把握しにくいためです。DORAは変更による不安定さを測る指標としてChange Fail RateとDeployment Rework Rateを挙げています。カバレッジが上がっても本番の障害が減らない場合は、見落としているリスクがないか、テストが正しい結果を確認しているかを見直しましょう。

品質管理の実践例

店舗や施設の予約システムを例に考えます。利用者は空き枠を検索して予約し、店舗担当者は予約枠と予約状況を管理します。主な機能は空き枠検索、予約、変更、取消し、認証、予約確認の通知です。

予約業務で起こり得る重大な障害と、それによる損失を洗い出し、AIに渡す仕様とテストの期待結果を開発前に決めます。機能を小さく分けて実装し、重大な故障を検証してから公開範囲を広げます。

「正しい結果」を決める

予約システムでは、定員を超える予約、確定後の再送による二重予約、他人による予約の閲覧・変更・取消しを防ぎます。取消期限を過ぎてから予約を取り消せる問題や、予約枠の変更後に確定済み予約との整合性が崩れる問題も想定します。通知の不達で予約の成否が分からなくなる場合や、時差によって日付や時刻を誤る場合も検証が必要です。最後の1枠を複数人が同時に予約すると、定員を超えてしまうおそれがあります。

最後の1枠に2人が同時に申し込んだ場合、予約が確定するのは1人だけです。もう1人には満席と表示し、確定した予約を1件、残りの枠を0件として記録します。通知や監査記録も、確定した予約に対して1件ずつ作成されることを確認しましょう。画面表示だけでは予約数と定員が一致しているか分からないため、保存データも調べます。

予約には、仮押さえ、確定、取消し、利用済み、来店なしの状態を設けます。仮押さえは期限後に失効します。取消済みの予約は再び確定できず、利用済みの予約も変更できません。状態遷移に加え、実装方法によらず満たすべき条件を仕様に定めます。

• 定員：同じ予約対象で時間帯が重なる予約の件数を定員以下に保つ
• 重複防止：同じリクエスト識別子で確定処理を再送しても、予約を1件だけ作成する
• 権限：利用者が操作できる予約を本人のものに限る
• 残りの枠数：予約の確定、取消し、仮押さえの失効を正しく反映する
• 通知：通知の送信に失敗しても、確定した予約を取り消さない

仕様を基準に実装とテストを進める

最初は1店舗、1種類の予約対象、固定の営業時間に絞り、空き枠の検索から予約確定、管理画面での確認までを実装します。取消しや予約変更、複数店舗、通知、決済は段階的に追加します。変更を小さく分けると、コードを確認しやすくなり、問題が起きても原因を特定しやすくなります。

実装を担当するAIには、承認済みの仕様や状態遷移、APIの取り決め、データの制約を渡します。テストの案を作るAIには、実装コードではなく、業務要件や重大なリスク、状態遷移、受入条件を渡します。同じAIを使う場合も、実装時の会話履歴を引き継がない新しい会話でテストを設計します。予約数や権限、締切時刻、同時操作で期待する結果は、業務担当者とテスト担当者が決めます。

E2Eテストでは、予約が正しく成立し、業務を続けられるかに関わるシナリオを確認します。通知サービスが停止した場合は、予約を成立させたうえで、通知を保存して復旧後に再送する仕様にします。

1. 予約の成立：利用者が空き枠を予約し、管理画面にも同じ予約が表示される
2. 最後の1枠：2人が同時に操作しても、一方だけが確定し、残枠が正しく更新される
3. 確定直後の通信断：同じ要求を再送しても、予約は1件だけ作成される
4. 他人の予約へのアクセス：閲覧、変更、取消しのいずれも拒否される
5. 通知サービスの停止：予約は成立し、通知は復旧後に重複なく送られる

営業時間の境界や取消期限、日付変更、定員の計算は単体テストで確認します。データベースの一意制約やトランザクション、同時更新、通知の再試行は、APIテストや結合テストで調べます。E2Eテストでは、利用者が画面で操作した結果、予約情報が正しく保存され、必要に応じて外部サービスと連携できるかを確かめます。

テストで故障を検出できるか確認して公開する

重複を防ぐ条件を無効にする、権限確認を削除する、取消期限の比較条件を逆にするなど、コードに意図的な誤りを加えます。通知の送信失敗によって予約まで失敗する変更も試し、テストが失敗するか確認しましょう。どのテストも失敗しなければ、正常系のテストが何件合格していても、そのリスクを検出できていません。

変更のたびにCI/CDで静的解析、単体テスト、APIテスト、重要なE2Eテストを実行します。重要なE2Eテストが再実行で合格したり失敗したりする場合、再試行後の合格だけでリリースを承認してはいけません。原因を調べ、同じ条件で安定して合格することを確認してから公開します。

本番公開は一部の店舗から始め、予約成功率や重複予約数、予約確定APIのエラー率、処理時間、通知の失敗数を監視します。異常が見つかったら公開範囲を広げず、必要に応じて旧バージョンへ戻します。新旧のバージョンを少しずつ切り替えて比べる方法なら、問題が起きたときの影響を抑えられます。公開後に見つかった障害はリスク一覧に加え、同じ障害を防ぐテストを追加します。

まとめ

AIを使うと、実装やテスト作成を速められます。その分、業務で何を正しい結果とするか、どの障害を優先して防ぐかを決める力が欠かせません。E2Eテストの品質は、テストの件数やカバレッジだけでは判断できません。重大な故障をテストで見つけられるか、同じ条件で安定して動くかを確かめましょう。公開後に見つかった障害も、次のテスト設計に生かします。

エンジニアには、業務上の損失を見極め、期待する結果を仕様に定める力が求められます。業務に合ったテストレベルを選び、公開後の障害を次の検証に反映する判断も欠かせません。AIが作ったテストの数を増やすだけでなく、重大な故障を検出し、結果を信頼できるテストを設計することが、これからの品質管理を支えます。こうした力をどう身に付け、キャリアに生かすかも考えていきましょう。仕様を業務に合わせ、障害時にも業務を続けられる設計を考える力が、エンジニアの専門性になります。

参考文献

ISTQB, Certified Tester Foundation Level Syllabus v4.0.1

ISTQB, Certified Tester Advanced Level Agile Tester Syllabus v2.0

Meta Engineering, LLMs Are the Key to Mutation Testing and Better Compliance