AIにQAを任せるのではなく、QAしやすい状態をAIに作らせる ~ Verification-Driven AI Engineeringから、ソフトウェアQAの工程支援を考える ~

この記事で考えたいこと

AIによって、要求、設計、コード、テストケース、レビューコメントなど、さまざまな開発成果物を生成しやすくなっています。

これはとても便利です。
一方で、生成される成果物が増えるほど、それを誰が、どのように確認するのかという問題も大きくなります。

AIが大量に成果物を作る。
しかし、人間のQAが最後に一件ずつ確認する。

この形のままだと、AIによって開発速度が上がったとしても、QA活動そのものがボトルネックになる可能性があります。

では、AI時代のQA支援とは何なのでしょうか。

私は、AIにQAの最終判断を任せることではないと考えています。
むしろ、QAが判断するために必要な根拠、不足、矛盾、未確認事項、残リスクを、AIに前倒しで整理させることではないか。

言い換えると、

AIにQAを任せるのではなく、QAしやすい状態をAIに作らせる

ということです。

ここでいう「QAしやすい状態」とは、成果物そのものだけでなく、根拠、不足、矛盾、未確認事項、残リスクが確認できる状態です。

この記事では、Verification-Driven AI Engineering: Workflows and Reference Architecture という論文を読んで考えたことを、ソフトウェアQAに引き寄せて整理してみます。
本稿で参照する資料は、SSRNに掲載されたプレプリントです。確立した業界標準としてではなく、AI時代の検証を考える新しい提案として参照します。
論文へのリンクは、末尾の「参考」に記載します。

なお、この記事は完成した理論ではありません。
論文から読み取れることと、そこから私が考えた仮説を分けながら、今後考えたい問いを残すための関連考察です。

論文はソフトウェアQAだけを対象にしたものではない

最初に注意しておきたいのは、この論文が、ソフトウェア開発のQAだけを対象にしたものではないという点です。

論文では、AIエージェントがコードや科学的解候補を大量に生成する状況を対象に、生成された候補をどのように検証可能にするかが扱われています。適用例もソフトウェア開発に限らず、科学AIワークフローを含んでいます。

つまり、この論文は「ソフトウェアQAのための論文」というより、AIが大量に生成する候補を、どう検証可能な形に分解し、検証をスケールさせるかを扱うAI Engineeringの論文だと理解しました。

この記事で考えたいのは、その verification-driven という考え方を、ソフトウェアQAに引き寄せると何が見えてくるか、ということです。

論文から読み取れること

論文から読み取れる中心的な問題意識は、AIによって「生成」はスケールする一方で、「検証」はスケールしにくい、ということです。

AIエージェントは、多数の候補を生成できます。
しかし、その候補をすべて人間が確認するのであれば、最終的には人間判断のところで詰まります。

論文では、この問題に対して、verification-driven AI engineering という考え方を提案しています。そこでは、検証可能性を first-class design objective として扱い、問題を最初から検証しやすい単位に分解することが重視されています。

この記事では verification-driven を、「最後にまとめて検証する」のではなく、「最初から検証しやすい形に問題や工程を設計する」考え方として読みました。

特に興味深いのは、論文が示すワークフローです。

論文では、大きく次の2つの流れが示されています。

design-time problem decomposition
runtime execution

design-time problem decomposition では、問題を実行時に検証しやすい sub-step に分解し、各ステップに verifier や、次に進めてよい水準などを対応づける考え方が示されています。

runtime execution では、その分解計画に従って処理を進め、検証結果に応じて再試行や人間判断へのルーティングを行います。

つまり、最終成果物が出てから検証するのではなく、問題の分解やワークフローの設計時点で、検証しやすさを組み込むという考え方です。

また、論文では、AIが解を生成する部分と、その解を検証する部分を分け、検証結果に基づいてワークフローを進める考え方も示されています。

ここまでを、この記事では論文から読み取れる範囲として扱います。

そこからソフトウェアQAに引き寄せて考えたこと

ここからは、論文そのものの主張ではなく、私がソフトウェアQAに引き寄せて考えた仮説です。

ソフトウェア開発でも、AIが支援する範囲は広がっています。

要求の整理。
影響分析。
設計案の作成。
テストケースの生成。
レビューコメントの下書き。
差分説明の生成。

こうした成果物がAIによって大量に作られるようになると、人間のQAが最後にまとめて確認する方式は、だんだん厳しくなるのではないでしょうか。

そこで考えたいのが、工程ごとの verifier です。

ここでいう verifier は、AIが出した成果物の正しさを最終判定するものではありません。
むしろ、次工程へ渡す前に、QAが判断するための材料がそろっているかを確認する仕組みです。

また、ここでいう verifier は、単一のAIツールというより、チェックリスト、ルール、テスト、静的解析、トレーサビリティ確認、AIによる整理などを組み合わせた検証機構として考えています。

たとえば、次のようなことを確認します。

• 根拠は残っているか

• 未確認事項は明示されているか

• 矛盾はないか

• 判断理由は説明できるか

• 代替案や棄却理由は記録されているか

• 残リスクは見える形になっているか

これは、AIにQAを任せる話ではありません。

AIによって、QAが判断しやすい状態を作る。
QAが最後にすべてを掘り返さなくてもよいように、各工程で確認すべき情報を前倒しで整理する。

それが、AI時代のQA支援の一つの形になるのではないかと考えました。

工程ごとの verifier という仮説

工程ごとの verifier を考えるとしたら、まずは次のようなものがありそうです。
ここでいう工程は、固定的な開発フェーズだけではなく、成果物を次へ渡す単位や判断を確定する単位も含めて考えています。

要求分析 verifier

要求分析 verifier は、要求が次工程に渡せる状態になっているかを確認するものです。

たとえば、次のような観点です。

• 曖昧語だけで終わっていないか

• 受け入れ条件があるか

• 未確認事項が明示されているか

• 前提条件が書かれているか

• 利害関係者に確認すべきことが残っていないか

ここで重要なのは、要求をAIが「正しい」と判定することではありません。

要求を見たQAや設計者が、何を確認すべきか判断しやすい状態になっているか。
その材料をAIに整理させることです。

たとえば、「高速に応答すること」という要求があったとします。

要求分析 verifier は、それを見て、

高速とは何ms以内か
どの条件下での応答か
受け入れ条件はあるか
未確認事項として残すべきか

のような観点を抽出するかもしれません。

これは最終判断ではなく、QAや関係者が確認するための入口です。

設計 verifier

設計 verifier は、設計判断が説明可能な状態になっているかを確認するものです。

たとえば、次のような観点です。

• 採用案が明示されているか

• 代替案が検討されているか

• 棄却理由が残っているか

• 制約条件が記録されているか

• テスト可能な単位に分かれているか

AIが設計案を出したとしても、その案だけを見て品質を判断するのは危険です。

なぜその設計にしたのか。
他の案はなかったのか。
何を制約として見たのか。
何をリスクとして残したのか。

これらが分からないと、QAは設計を確認しにくくなります。

設計 verifier は、設計の正しさを決めるものではなく、設計判断をレビュー可能な形に整える支援として考えられます。

テスト設計 verifier

テスト設計 verifier は、テストケースが要求、リスク、境界値、異常系などと対応しているかを確認するものです。

たとえば、次のような観点です。

• 要求との対応があるか

• リスクの高い箇所が確認されているか

• 境界値が考慮されているか

• 異常系や例外条件が抜けていないか

• テスト対象外とした理由が残っているか

AIがテストケースを大量に生成できるようになるほど、この観点は重要になります。

大量のテストケースがある。
しかし、なぜそのテストが必要なのか分からない。
どの要求やリスクに対応しているのか分からない。
何を確認済みで、何が未確認なのか分からない。

この状態では、テストケースが増えてもQAしやすくなりません。

テスト設計 verifier は、テストケースそのものを増やすのではなく、テストケースを評価しやすい状態に整える役割を持つのではないかと考えています。

従来のチェックリストと何が違うのか

ここで疑問になるのが、工程別 verifier は従来のチェックリストと何が違うのか、という点です。

これはかなり重要な問いです。

私は、チェックリストを古い仕組みとして否定したいわけではありません。
むしろ、チェックリストは verifier の一部になり得ると思っています。

従来のチェックリストは、人間が確認すべき観点を一覧化するものです。
これは今でも有効です。

ただし、AI時代に考えたい verifier は、チェック項目を並べるだけではありません。

チェックリスト、ルール、テスト、静的解析、トレーサビリティ確認、差分抽出、根拠の整理、未確認事項の抽出などを組み合わせて、QAが判断しやすい状態を作る実行可能な検証機構に近いものではないかと考えています。

たとえば、要求分析 verifier なら、単に、

曖昧語がないか確認する

というチェック項目を持つだけではありません。

AIが要求文から曖昧語を抽出し、受け入れ条件の有無を確認し、未確認事項として整理し、関係者に確認すべき問いの候補を出す。

そこまでできると、QAは「どこを確認すべきか」を探すところではなく、「その確認事項をどう判断するか」に集中できます。

つまり、チェックリストは確認観点を支えるもの。
verifier は、その確認観点を実行可能な形にし、QAが判断するための材料を整えるもの。

この違いがあるのではないかと思います。

verifier自身を誰が保証するのか

ただし、ここで大きな問題が残ります。

verifier自身の妥当性は、誰が保証するのでしょうか。

もし要求分析 verifier が、重要な曖昧さを見逃すとしたら。
もし設計 verifier が、代替案の検討不足を検出できないとしたら。
もしテスト設計 verifier が、重要な異常系を「対象外」と誤って整理するとしたら。

その場合、AIが作る「QAしやすい状態」そのものが歪んでしまいます。

つまり、verifier は作って終わりではありません。

QA、設計者、テスト担当、ドメイン専門家が、verifier の観点や出力を継続的に見直す必要があります。

また、実際のレビュー結果、不具合、手戻り、見逃しなどを使って、verifier が本当に役に立っているかを評価する必要もあるはずです。

ここは、今回の記事では結論を出しません。

むしろ、AI時代のQAを考えるうえで、かなり大きな問いとして残ります。

verifier自身を、誰が、どの周期で、どの証拠に基づいて保証するのか。

これは今後、じっくり考えたいテーマです。

現時点で残る問い

この記事では、Verification-Driven AI Engineering の考え方を、ソフトウェアQAに引き寄せて考えてみました。

ただし、まだ仮説の段階です。

現時点では、少なくとも次の問いが残ります。

verifierの妥当性をどう測るのか

verifierが出した結果は、どのように評価すればよいのでしょうか。

検出率を見るのか。
見逃しを見るのか。
レビュー工数の削減を見るのか。
手戻りの減少を見るのか。
不具合流出の抑制を見るのか。

何をもって「このverifierは妥当」と言えるのかは、まだ整理が必要です。

自動検証可能なものと、人間判断が必要なものを誰が分類するのか

論文では、人間判断が必要な検証を局所化する考え方が示されています。

しかし、ソフトウェアQAに引き寄せたとき、何をAIやツールで確認し、何をQAやドメイン専門家が判断するのかを分類する必要があります。

この分類自体も、かなり重要なQA活動になるはずです。

工程をまたぐ判断をどう扱うのか

要求分析、設計、テスト設計は、きれいに分かれているようで、実際にはつながっています。

要求分析 verifier で未確認とした事項が、設計 verifier に影響する。
設計 verifier で残した制約が、テスト設計 verifier の観点になる。
テスト設計 verifier で見つかった不足が、要求や設計に戻る。

このように、工程をまたぐ判断やフィードバックをどう扱うかも、大きな論点です。

おわりに

AIが開発成果物を大量に生成できるようになるほど、人間のQAが最後に一件ずつ確認する方式は厳しくなっていくかもしれません。

そこで必要になるのは、AIにQAの最終判断を任せることではないと思います。

むしろ、QAが判断しやすい状態をAIに作らせること。

要求分析、設計、テスト設計といった工程ごとに、根拠、不足、矛盾、未確認事項、残リスクを整理し、次工程へ渡せる状態かを確認する。

そのような工程別 verifier の考え方は、AI時代のQA支援を考える入口になるのではないでしょうか。

もちろん、verifier自身をどう保証するのか、自動検証と人間判断をどう分けるのか、工程をまたぐ判断をどう扱うのかといった問いは残ります。

それでも、AIにQAを任せるのではなく、QAしやすい状態をAIに作らせる。

この方向は、今後の「AI時代のQA」を考えるうえで、育てていきたい仮説だと感じました。

この考察の背景となる、品質保証・思考プロセス・AIとQAについての連載全体はこちら：
車載ソフトウェア品質保証を考える：連載まとめ

参考

• Verification-Driven AI Engineering: Workflows and Reference Architecture - SSRN
  Qinghua Lu, Liming Zhu, Suyu Ma, Helen Power, Robert Speight, “Verification-Driven AI Engineering: Workflows and Reference Architecture,” 2026.

• Verification-Driven AI Engineering: Workflows and Reference Architecture - ResearchGate