【第2回】なぜAIは「書かれていないこと」をテストできないのか——②暗黙要件と"オラクル"の問題

本連載では、品質を3つの軸で捉えます——
①設計書適合（仕様どおりか）
②暗黙要件（仕様に書かれない当たり前）
③本質要件（本当に達成したい目的）

テストはどこから「正解」を得ているのか

テストとは、ある出力が「正しい」かどうかを判定する営みだ。では、その「正しさ」の基準はどこにあるのか。テストの世界では、これを オラクル（正解を判断する基準） と呼ぶ。

①設計書適合のオラクルは、仕様書である。「この入力ならこの出力になるはず」が文書に明示されている。だからテストは機械的に書けるし、AIも仕様を読んで期待値を導ける。①の自動化が大きく進むのは、オラクルが目に見える場所にあるからだ。

②の難しさは「オラクルが存在しない」こと

ところが②暗黙要件には、そのオラクルがない。②は定義上「設計書に書かれていない」要件である。書かれていないということは、何が正しいかの定義そのものが、どこにも存在しないということでもある。これが②のオラクル問題だ。

ここで誤解しやすいのは、「② ＝ 曖昧なもの」ではない、という点だ。②は具体的で、ただ仕様書に書かれていないだけのことが多い。たとえば——

• テスト技術・職人知識：境界値、null、空値、タイムアウト、エラーハンドリング

• 非機能要件：性能、セキュリティ、信頼性、可用性

• 本質的安全設計：フェイルセーフ、防御的設計、フェイルオーバー

• ドキュメント横断の観点：複数の設計書を突き合わせて初めて見える矛盾や抜け

どれも経験者なら「当たり前に確認すること」だ。だが、その「当たり前」は誰かの頭の中や業界の常識として存在し、仕様書には落ちていない。だからテスト設計から漏れる。

AIは、書かれていないものをテストしない

ここがAI時代の勘所だ。AIはテストを生成するとき、記述された仕様から期待値を導く。裏を返せば、仕様に書かれていないことは、テストされない傾向がある。②はまさに仕様の外側にあるため、②こそがAIによる自動化の恩恵を最も受けにくい領域になる。

これはAIの欠点ではない。オラクル（正解の基準）が与えられていないものは、人間でも機械でも判定しようがない、というだけのことだ。むしろ①が高速・正確になるほど、相対的に「書かれていない②」の取りこぼしが目立つようになる——前回触れた構図が、ここでも効いている。

②は「書けば」一部は①に変えられる

希望もある。②の困難が「書かれていない」ことに由来するなら、書けるものは書いてしまえばよい。

• 職人知識は、チェックリストとして言語化できる

• 非機能要件は、業界標準に基づく数値基準として定義できる

• 安全設計は、障害注入テストやカオスエンジニアリングで能動的に確認できる

こうして言語化・構造化できた②は、オラクルを持つ①の領域へ引き上げられ、自動化の対象になる。ただし②のすべてが書けるわけではない。書ききれずに残る②、そして次回扱う③には、別の打ち手が必要になる。

まとめ

②が抜けるのは、担当者の怠慢ではなく、②にはオラクルがそもそも存在しないという構造的な理由による。AIは書かれた仕様からしか期待値を作れないため、書かれていない②は自動化から取り残されやすい。だからこそ、②を「どこまで言語化・構造化してオラクルを与えるか」を設計することが、品質を作り込む最初の一歩になる。

次回（第3回） は、②よりさらに手強い ③本質要件 のオラクル問題——明示的な正解が存在しないとき、何を「正」とするのか（Reference Oracle）——を扱います。

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

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