AI駆動開発時代に、おさえておきたいQA技法

はじめに

AIを使って実装することが、かなり当たり前になってきました。

画面実装、API実装、リファクタリング、テストコードの追加まで、以前よりずっと速く進められるようになっています。少し前ならそれなりに時間がかかっていた作業も、AIを使えば短時間である程度形になります。

一方で、AI駆動開発には別の難しさもあります。

それは、実装スピードが上がることと、品質を安定して守れることは別だということです。

AIはコードを書いてくれます。テストコードもそれっぽく作ってくれます。ただ、こちらが観点を渡さない限り、どうしても正常系中心の薄いテストになりやすいです。

ぱっと見では十分そうに見えても、実際には次のようなポイントが抜けがちです。

• 境界条件
• 条件分岐の組み合わせ
• 不正な状態遷移
• 例外系や失敗時の挙動
• 実運用で起きやすい事故パターン

AI駆動開発では、テストコードを書くこと自体の難易度は下がっています。
だからこそ逆に、何をどういう観点でテストするべきかを考える力が重要になります。

そこで役立つのがQA技法です。

この記事では、AI駆動開発でテスト実装を進めるうえで、知っておくと実務でかなり使いやすいQA技法を整理してみます。

重要なのは "どの観点でテストを書くか"

AIにテストコードを書かせること自体は、それほど難しくありません。

たとえば、

• この関数の unit test を書いてほしい
• このコンポーネントのテストを追加してほしい
• この仕様に対する E2E テストを書いてほしい

と依頼すれば、ある程度の形にはなります。

ただ、ここで問題になるのは、テストコードが生成できるかどうかではありません。
本質的に重要なのは、どの観点でテストを書くかです。

AIは、明示しない限り、無難なケースに寄りやすいです。

たとえば予約機能なら、次のようなテストは比較的出しやすいです。

• 正常に予約できる
• 必須項目が未入力ならエラーになる
• 送信後に完了メッセージが表示される

でも、実際の不具合はその周辺で起きます。

• 予約可能時間の境界で壊れないか
• 権限によって操作可能範囲が変わるか
• ある条件の組み合わせでだけ不整合が起きないか
• ステータス遷移が不正に進まないか
• フロントでは弾いても API 側で通ってしまわないか
• 通信失敗時に中途半端な状態にならないか

このあたりは、指示しないと漏れやすいです。

つまりAI駆動開発では、
AIがテストを書けるかよりも、
人がテスト観点を整理できるかの方が重要です。

QA技法は、AIに良い指示を出すための土台になる

QA技法というと、テスター向けの知識に見えるかもしれません。

ただ、AI駆動開発では意味合いが少し変わります。

QA技法を知っていると、次のようなことがしやすくなります。

• テストケースを漏れにくく整理できる
• AIへの指示が具体的になる
• 生成されたテストの不足をレビューしやすくなる
• チーム内でテスト観点を共有しやすくなる
• テスト観点をテンプレート化しやすくなる

特に重要なのは、AIに単に「テストを書いて」と依頼するのではなく、

• 同値分割でケースを洗い出して
• 境界値を含めて
• 条件分岐をデシジョンテーブルで整理して
• 状態遷移の不正ケースも含めて

という形で依頼できるようになることです。

この差はかなり大きいです。

まず押さえておきたいQA技法

AI駆動開発でまず知っておくと使いやすいのは、次のあたりです。

• 同値分割
• 境界値分析
• デシジョンテーブル
• 状態遷移テスト
• エラー推測
• チェックリストベースドテスト

どれも、AIにテストを書かせる前の整理にかなり使えます。

同値分割は「無駄に多いケース」を減らすために使う

同値分割は、同じように扱われる値をグループ化して、代表値で確認する考え方です。

AIにテストを書かせると、ケースが妙に多かったり、逆に偏ったりすることがあります。
そのとき、同値分割を知っていると、どのグループを代表させるべきか整理しやすくなります。

たとえば「予約人数は1〜4名まで」という仕様なら、次のように分けられます。

• 0以下は無効
• 1〜4は有効
• 5以上は無効

このようにグループ化しておくと、AIへの依頼もかなり具体的になります。

たとえば、次のように指示できます。

予約人数バリデーションのテストを追加してください。
同値分割で以下の3パターンを含めてください。
0以下は無効、1〜4は有効、5以上は無効。

ただ「バリデーションのテストを書いて」と依頼するより、かなり質が安定します。

境界値分析は「AIが落としやすい境目」を拾う

AIが生成するテストは、代表例には強い一方で、境界条件の詰めが甘いことがあります。

そこで重要になるのが境界値分析です。

たとえば「1〜4名まで予約可能」であれば、本当に見たいのは次のような値です。

• 0
• 1
• 4
• 5

必要であれば、その周辺も見ます。

• -1
• 2
• 3
• 999

実装では、>= と >、<= と < の取り違えがよく起きます。
これはAIが書いたコードでも普通に起こり得ます。

そのため、AIに依頼するときも、境界を明示した方がよいです。

たとえば次のように指示できます。

このバリデーションの unit test を追加してください。
特に境界値として 0、1、4、5 を必ず含めてください。

これでも、かなり実用的なテストになります。

デシジョンテーブルは「条件の組み合わせ漏れ」を防ぐ

AIは1条件ずつのテストは比較的書けますが、複数条件の組み合わせになると漏れが出やすいです。

そういうときに有効なのがデシジョンテーブルです。

たとえば、予約確定メールの送信条件が次の3つだとします。

• 予約が確定している
• 通知設定がONになっている
• メールアドレスが登録されている

この場合、いきなりテストコードを書かせるより、先に条件表を作った方が整理しやすいです。

予約確定	通知ON	メールあり	結果
Yes	Yes	Yes	送信する
Yes	Yes	No	送信しない
Yes	No	Yes	送信しない
No	Yes	Yes	送信しない

もちろん実際には組み合わせはもっとありますが、こうして先に整理することで漏れに気づきやすくなります。

AIへの依頼も、次のように変えられます。

以下の仕様について、先にデシジョンテーブルを作成してください。
その後、各条件の組み合わせをカバーする unit test を作成してください。

AI駆動開発では、いきなりコードを書かせるより、先に整理させる方が精度が上がる場面が多いです。
デシジョンテーブルはその代表です。

状態遷移テストは、業務システムで特に重要

SaaSや業務システムでは、状態を持つ機能が非常に多いです。

たとえば予約ステータスなら、次のような状態があります。

• 仮予約
• 確定
• 来院済み
• キャンセル

このとき重要なのは、各状態が存在することではありません。
本当に重要なのは、どの状態からどの状態へ遷移できるかです。

たとえば、

• 仮予約から確定には遷移できる
• 確定から来院済みには遷移できる
• 確定からキャンセルには遷移できる
• 来院済みから仮予約には戻れない

といったルールです。

AIにこの手のテストを書かせると、状態ごとの単発確認はできても、不正な遷移ができないことが抜けることがあります。

そのため、状態を持つ機能では、先に遷移図や遷移表を整理してから依頼するのが有効です。

たとえば次のように指示します。

予約ステータスの遷移ルールを表にしてください。
そのうえで、許可される遷移と禁止される遷移の両方をテストしてください。

これは業務ロジックの保護という意味でもかなり重要です。

エラー推測は、AI時代ほど価値が上がる

エラー推測は、過去の障害や経験から「ここは壊れやすい」と予測してテストする考え方です。

これはAIが苦手になりやすい領域でもあります。

なぜなら、AIは一般的なコードパターンには強い一方で、プロダクト固有の事故パターンや運用上の怖さまでは持ち込みにくいからです。

たとえば実務では、次のようなケースが危ないです。

• 二重送信
• 戻る操作後の再送
• タイムゾーン差分
• 空文字と null の混在
• 全角半角混在
• 権限の抜け道
• 通信失敗時の中途半端な状態
• 保存成功表示が出たのに実データが反映されていない

こういう観点は、仕様書だけを見ていると出にくいです。

だからこそ、AI駆動開発では、人間側が「過去に壊れたポイント」を持っておく意味が大きいです。

AIが速く実装できるからこそ、過去の障害知見や実運用のクセを持っている人の価値は、むしろ上がると感じています。

チェックリスト化すると、AI開発でも品質が安定する

AI駆動開発は速い反面、変更回数が増えやすいです。
すると、毎回ゼロから観点を考えるのはかなり負担になります。

そこで有効なのが、チェックリスト化です。

たとえば画面実装なら、最低限こうした観点を持っておけます。

• 正常系は動くか
• バリデーションエラーは表示されるか
• ローディング中に二重送信できないか
• 権限がないユーザーに操作が見えていないか
• API失敗時にUIが壊れないか
• 成功表示と実データが一致しているか
• モバイル表示で崩れていないか
• console error が出ていないか

このチェックリストがあると、AIへの依頼テンプレートにも使えます。

たとえば次のように書けます。

以下の観点を含めてテストを作成してください。
正常系、バリデーションエラー、API失敗時、二重送信防止、権限制御、ローディング表示。

この形にしておくと、テスト実装の再現性がかなり上がります。

AIにテストを書かせるときのポイント

AI駆動開発では、QA技法を知っているだけでなく、どう依頼するかも重要です。

あまり良くない依頼は、たとえばこうです。

この機能のテストを書いてください。

これだと、無難な正常系中心になりやすいです。

一方で、少し良い依頼はこうです。

この機能のテストを追加してください。
以下の観点を含めてください。
同値分割、境界値分析、条件分岐の組み合わせ、不正な状態遷移、nullや空文字、二重送信や失敗時の考慮。

さらに良いのは、先に整理させる依頼です。

この仕様について、

1. 同値分割
2. 境界値
3. デシジョンテーブル
4. 想定される異常系
   を先に列挙してください。
   その後、その結果をもとにテストコードを作成してください。

AI駆動開発では、生成されたコードそのものより、その前段の観点整理の方が重要になることが多いです。

まとめ

AI駆動開発では、テストコードそのものは以前よりずっと書きやすくなりました。
ただ、その一方で、観点が弱いままテストだけが増えるリスクもあります。

だからこそ、QA技法を知っておく価値があります。

• 同値分割で無駄なケースを減らす
• 境界値分析で壊れやすい境目を狙う
• デシジョンテーブルで条件の組み合わせ漏れを防ぐ
• 状態遷移テストで業務ロジックを守る
• エラー推測で実務上の事故を拾う
• チェックリストで再現性を持たせる

これらは、テスターだけの知識ではありません。
AIに良いテストを書かせるために、開発者側が持っておくべき観点整理の型です。

AIで実装が速くなる時代だからこそ、
「どう書くか」だけではなく、
「何をテストすべきか」を考える力の重要性は、むしろ上がっていると感じます。