【第1回】「AIが仕様通りに作ったのに業務パターンが抜け落ちる」——AI時代のソフトウェア品質を考え直す

AIに仕様を渡せば、コードはすぐに出てくる。定義書に書かれたシステム仕様は満たし、テストも通る。ところが、いざ業務で使う段になると、業務要件を満たせていなかったり、細かな業務パターンが考慮されていなかったりする。それらはそもそもシステム仕様に落ちておらず、だからテストでも素通りしてしまう——。

業務システムの開発に関わったことがある人なら、覚えのある状況だと思う。しかも、これは特定の現場の不手際というより、多くのプロジェクトで共通して起きる。やっかいなのは、テストは「正しく」行われていたことだ。定義書に書かれた条件は、確かにすべて満たされている。問題は、そのテストが見ていた「品質」が一面的だったことにある。

品質には3つの軸がある

ソフトウェアの品質は、本来3つの軸で捉えられる。

• ①設計書適合（形式品質） ……設計書・仕様書通りに実装されているか

• ②暗黙要件（経験品質） ……設計書に書かれていないが当然満たすべきことが満たされているか

• ③本質要件（目的品質） ……本質的に求められている要件通りに実装されているか

従来のテストが得意としてきたのは①だ。①のオラクル（正解を判断する基準）は仕様書という形で明示されているので、機械的に検証できる。

一方、②と③のオラクルは明示されていない。②はテスターの経験や業界の常識に、③はビジネスの意図やユーザーの真の目的に宿る。冒頭の「業務要件や細かな業務パターンが仕様に落ちず、テストからも抜け落ちる」現象の正体は、この②③が検証の外に置かれていることにある。

SDD・AIは①を大きく前進させる——だからこそ②③が際立つ

SDD（Spec駆動開発）やAIによるコード生成は、①設計書適合を支える強力な土台だ。仕様から実装やテストを高速に生成し、「仕様通りに作る」精度とスピードを飛躍的に高める。これはソフトウェア開発にとって大きな前進であり、積極的に活用すべきものだ。本稿はSDD・AIを否定するものではなく、それらを前提に、その先を考える。

注目したいのは、①がこれだけ速く正確になったからこそ、これまで①の負荷に隠れていた②③が、はっきりと前面に出てきたことだ。AIは、仕様に書かれていないことや、言語化されていないビジネスの「Why」までは引き受けない。これはAIの欠点ではなく、もともと②③の正解（オラクル）が人間の側に根ざしているからだ。

つまり、問題が新しく生まれたのではない。①が前進したことで、もともとそこにあった②③の輪郭が、くっきり見えるようになった。だからこそAI時代の品質保証の核心は、「正しく作れているか」を後から確かめることよりも、「何が品質なのか」を先に設計し、②③を作り込んでおくことへと移っていく。

「テスト（検証）」から「品質の作り込み」へ

ここで必要になるのが、事後の検証中心の発想（Quality Assurance）から、開発ライフサイクル全体で品質を作り込むエンジニアリング（Quality Engineering）への転換だ。

そしてそれを担う役割として、本編（全文）では「QEアーキテクト」という役割を提唱している。テックアーキテクトが「AIが高速かつ正しく構築できる技術構造・制約」を設計するのに対し、QEアーキテクトは「何を品質として確認すべきか・どう検証するか」を、開発の速度を止めずに設計する。両者は、AIの生成速度を損なわずに品質を作り込むことを共通の目的とする。

全体像

3軸の整理、SDDとAIが各軸に与える影響、②③を確保するための具体的な打ち手（QEハーネス、多層バリデーション、Reference Oracle など）、そしてQEアーキテクトという役割の定義までを、本編（全文）にまとめた。

次回（第2回） は、②③のうち②の「オラクル問題」——なぜ「書かれていないこと」の確認は難しいのか——を掘り下げます。

▼連載の全体像と各回へのリンク（連載インデックス）

本稿および本編は個人の見解であり、所属する組織を代表するものではありません。
問い合わせ先：terumitsu.takahashi.qe [at] gmail.com