最近は、Claude CodeやCodexなどを使ってAIにコードを書かせることが当たり前になってきました。
そんな中で皆さんは、何をもって「システムの品質が担保されている」と考えるでしょうか。
以前はどうやって品質を説明していたか
ちょっと昔のシステム開発では、以下のような数字を見ることが多かったと思います。
- 単体試験のコードカバレッジ
- ソースコードのステップ数に対する試験項目数
- ソースコードのステップ数に対する不具合数
- 工程ごとの不具合数
これらの値をIPAのソフトウェア開発データ白書などに掲載されている統計値と比較して、
「テスト密度や不具合密度が一般的な範囲から大きく乖離していないため、品質上の問題はない」と判断していました。
つまり
「Javaで何kステップのソースを書いたから、何件くらいの試験項目数が作られるはずだ」
「さらにその内何件くらい不具合が出れば、ちゃんと試験されているはずだ」
というような考え方です。
もちろん当時から、数字が基準内なら品質が保証されるという単純な話ではありませんでしたが、
少なくともこの値を使ってお客様に「品質が担保できています」と説明していた時代がありました。
（今でも大規模なプロジェクトや昔から続くウォーターフォール開発のシステムなどでは現役の手法だと思います）
AI時代にマッチしているのか
コーディングAIを使えば、少し指示するだけであっという間に数千行のコードや大量のテストコードを生成してくれます。
そうなると、コード量に対して十分な数のテストをしたかという、量を中心とした評価は、
品質の根拠として以前ほどの説得力を持たなくなっていると言えるでしょう。
コードカバレッジについても同様で、昔のようにカバレッジが高いから品質が高い、と簡単には言えません。
もし最初に、AIに誤った仕様をインプットしていたとしたら、その誤解に沿った実装とテストがセットで大量に作られる可能性があります。
その結果として「カバレッジ100%、全テスト成功、でも仕様を満たしていない」ということが十分あり得ます。
このように昔からの手法で品質を表せなくなった私たちは、何をもって品質が担保されていると判断するべきなのでしょうか。
でも、これは新しい話なのか
改めて、新しい品質の担保基準が必要なのかと考えたところで、
結局求められているものは昔から変わらないのではないかと気付きました。
必要なのは「要求を満たしていると確認できること」です。
昔から使われているV字モデルという考え方でも、要求や設計と、それを検証するテスト工程を対応付けて考えます。
つまり、出来上がったコードからそれが動くことを確認するだけではなく、要求・仕様を起点として、それを満たしていることを確認するという考え方です。
振り返ってみると、白書との比較も、品質が高いことを証明するものというより、
「この機能だけ不具合がゼロなのはおかしい」「ここだけテストが極端に少ない」といった異常に気付くための道具だったように思います。
数字そのものが品質を表していたわけではなく、品質の根拠はもともと要求を満たしているかどうかにあったわけです。
AI時代になって、まったく新しい品質保証の考え方が必要になったわけではないのかもしれません。
むしろ、昔から言われてきた
- 要求とテストのトレーサビリティ
- 実装と検証の独立性
- リスクに基づいたテスト
- 人間によるレビュー
といった基本的な考え方が、これまで以上に重要になっているように思います。
AI時代の「独立性」
この中でも、AI時代に特に意味が変わったと感じるのが「実装と検証の独立性」です。
昔から、作った人とテストする人を分けるという考え方はありました。
自分で作ったものを自分でテストすると、同じ思い込みでテストしてしまうからです。
AIの場合、これがもっと極端に起こります。
同じAIに一連の会話の流れの中で実装とテストの両方を書かせた場合、同じ誤解が含まれやすくなります。
先ほどの「カバレッジ100%、でも仕様を満たしていない」はまさにこういったケースを指しています。
そのため、AIを使うときは次のように作る側と確かめる側を意識的に分けることが重要だと思います。
- 実装したAIとは別のセッション（別のエージェント）に、実装ではなく要求・仕様からテスト観点を出させる
- 受入条件（何ができたら完成か）は人間が決め、テストとして実行できる形にしておく
- 人間はテストコードを1行ずつ読むのではなく、テスト観点が要求を網羅しているかをレビューする
また、AIにはテストが失敗したときに、実装ではなくテストの期待値の方を書き換えて通してしまうことがあります。
せっかく独立に作ったテストも、実装側のAIが書き換えてしまえば意味がありません。
受入テストはAIに変更させない、テストの期待値の変更は必ず人間がレビューする、といったルールで、確かめる側を守ることも必要です。
「どう作るか」はAIに任せても、「何が正しいか」の定義は人間が持つ。
ここを分けておけば、AIが大量にコードやテストを作っても、それを要求に照らして確かめることができます。
ただし、独立性で防げるのはAIの誤解までです。
仕様そのものが誤っていたり曖昧だったりすれば、別のAIも同じ仕様から同じ誤りを含んだテストを作ってしまいます。
だからこそ、受入条件は人間がお客様と合意したうえで決める必要があります。
一方で、仕様の曖昧な点や矛盾をAIに洗い出させるのは得意分野なので、仕様を固める段階でもAIを活用できると思います。
AIで速く作るだけではなく、AIで品質も上げる
AIで大量のコードを書くようになった今でも「AIが書くコードは信用できない」「AIはもっともらしい顔で間違える」といった意見はあります。
では、AIによる開発速度向上は品質を犠牲にして成り立っているのでしょうか。
これまでの開発では、
「もっとテストした方がいい」
「影響範囲をもっと調査した方がいい」
「レビューをもっとしっかりやった方がいい」
と分かっていても、結局は人間の工数が必要でした。
そのため現実には、やった方がいいけどそこまでやる時間がない、ということが少なくありませんでした。
単体試験は省略して結合試験でまとめて確認しよう、なんてことも実際の現場ではよくあることでした。
しかしAIはコードだけでなく、
- テスト観点の洗い出し
- 変更の影響範囲の調査
- 仕様と実装の比較
などにも利用できます。
つまりAIによって、実装コストだけではなく、品質を確認するためのコストも下げられるということです。
AIコーディングというと、これまで10日かかっていた実装を3日で作れるといった生産性の話になりがちですが、その浮いた7日をすべてコスト削減と考える必要はありません。
その一部を、今まで工数の問題でできなかった品質活動に使うこともできるのです。
ただし、ここで前の節で述べた独立性が重要になります。
実装したAIにそのままテストやレビューをさせるのではなく、仕様を起点に、別の視点から確かめさせることで初めてAIによる品質活動に意味が出てきます。
また、AIが生成する量に対して、人間がすべてを詳細にレビューするのは現実的ではありません。
金額計算・権限・個人情報・外部連携など、リスクが大きい箇所に人間のレビューを集中させる。
これも昔からあるリスクベースの考え方ですが、AI時代にはより重要になると思います。
では、何を示せば良いのか
ここまでの話を踏まえて、最初の問いに戻ります。
白書との比較の代わりに、お客様に何を示せば私たちは「品質を担保した」と言えるのでしょうか。
私は、どれだけテストしたかという量ではなく、
「誰が正しさを定義し、何を使って独立に確かめ、どこを重点的に見たか」を示すことだと考えています。
具体的には、例えば以下のようなものです。
| 観点 | 品質保証の根拠 | 何を示せるか |
|---|---|---|
| 要求との対応 | 要求と受入テストのトレーサビリティ | 各要求に対して検証手段が定義され、検証が実施されていること |
| 機能の正しさ | 受入テスト・E2Eテストの結果 | 定義した利用シナリオや期待結果を満たしていること |
| テストの有効性 | ミューテーションスコア | コードに意図的な変更を加えた際に、テストがその変化を検出できる度合い |
| コード上の問題 | 静的解析の結果 | 使用した解析ルールの範囲で、検出可能な問題がどの程度残っているか |
| セキュリティ | 脆弱性スキャンの結果 | 使用した検査手法・対象範囲において、既知の脆弱性や問題が検出されていないか |
| 検証の独立性 | 実装とは独立した観点で作成したテスト | 実装時の思い込みや誤解を、そのまま検証側に持ち込むリスクを抑えていること |
ミューテーションテストはあまり馴染みがないかもしれませんが、コードにわざと小さなバグ（> を >= に変える等）を埋め込み、テストがそれを検出できるかを確認する手法です。
テストがちゃんと間違いを見つけられるかを測れるため、AIが量産したテストの質を確かめる指標として相性が良いと思います。
また、カバレッジやテスト件数が不要になるわけではありません。
低すぎたら明らかに足りないという最低ラインの確認や、昔の白書比較のような異常に気付くための道具としては今でも使えます。
ただ、それ単体を品質の根拠として示すことは難しくなった、ということだと思います。
なお、表とは少し性質が異なりますが、リリース後の障害発生率や復旧時間も合わせて示せるとよいと思います。
これはリリース時点の品質というより、問題が起きても早く気付いて直せる体制があることを示すものです。
まとめ
AI時代になって、コード量やテスト量といった量の指標だけで品質を説明することは、以前より難しくなっています。
一方で、要求からテストを考えること、要求とテストを紐付けること、実装と検証を分けること、リスクの高いところを重点的に見ること、といった昔からの原則はむしろ重要になっています。
そしてAIをこれまでコスト的に難しかった品質活動にも使えるようになれば、より高い品質を目指せるのだと思います。
「何をもって品質を担保するのか」。
その答えの一つは、「量ではなく、正しさの定義と、それを独立に確かめた構造を示すこと」ではないかと考えています。
AI時代だからこそ、改めてソフトウェア品質の基本に立ち返る必要があるのかもしれません。
参考
- IPA「ソフトウェア開発データ白書2018-2019」
-
IPA「ソフトウェア開発分析データ集2022」
- 白書の後継である本データ集も、事業終了に伴い2022年版が最終版となっています。