ソフトウェア開発プロジェクトのセットアップにおいて、本質的なフィードバックループは「開発者とテストスイート」の間にあるのではありません。それは「機能を記述する人（アナリスト、開発者、テスター）」と「それを使う人」の間にあります。ユニットテスト、統合テスト、コードレビュー、CIパイプラインといった他のすべては、直接の対話が不可能だったり速度が足りなかったりする場合に、そのループ内を近似し翻訳するために存在します。エンタープライズシステムでは常にそうですが、将来のユーザーの「ニーズ」と、コード・データ・出力の間の「意味的な距離」があまりに大きく、文脈が広大かつ特定的なため、誰も一人では完結できないのです。

今日の「AI革命」（私はこれを、LLMベースのエコシステムの急速な進化と捉えるのが好きですが）の最もトリッキーな点の一つは、この距離においてさえ飛躍をもたらすと約束していることです。そこでの議論が些細なことや特定の事柄に終始する場合、意味論（セマンティクス）は単なる弱い制約に過ぎなくなります。私は、こうした前提の背後に隠された問題に注意を向けたいと思います。私の考えでは、ゲームの本質は変わりません。ルールの一部は変わりますが、「ニーズをソフトウェアに翻訳する」というビジネスの核心には、「雰囲気で理解するなんてことはあり得ない」という事実が厳然と存在します。Curt氏とは多くの各論で意見が合わないかもしれませんが、彼が最も重要なメッセージを語ってくれたと思っています。

2つの問いの不変性

テストエンジニアが「この機能をどうテストすべきか」と問うとき、その問いは構造的に「核心となる機能は何か（あるいは非機能要件、これはひどい言い回しですが一般的です）、そしてなぜそれが顧客にとって、あるいはミッションにとって重要なのか」という問いと同一です。これらは2つの問いではなく、プロセスの中の2つの立場から表現された「同じ問い」なのです。2番目の問いに対する明確な回答から導き出せないテストは、有用なテストではありません。Vモデルには用心してください！テストに変換できない機能記述は、使い物になる仕様書ではありません。

これはテストに関する観察ではなく、コミュニケーションに関する観察です。テストデザインレビューの機能は、どんな手法であれ、システムの「共有されたメンタルモデル」の不一致がコードやテストデータとして固定される前に、そのズレを露呈させることにあります。テスティングの用語では、バリデーション（妥当性確認）とベリフィケーション（検証）の目的を明確に区別します。実務において、特に「KISS（シンプルにしておけ、愚か者）」アプローチを好む人々と話すとき、私たちはその言葉の真意を捉えきれていないことがあります。テストエンジニアが要件に対してテストを定式化できないとき、その失敗はシグナルです。つまり、その要件には隠れた前提、曖昧さ、あるいは矛盾が含まれているということです。テストデザインのプロセスとは、自然言語の記述からこれらの隠れた性質を抽出するための構造化されたプロトコルなのです。

エラーの修正は容易だが、概念的な問題はそうではない

エラーとは、局所的な逸脱です。計算の間違い、Nullチェックの漏れ、オフバイワンエラーなどです。静的解析、自動テスト、リンターはこれらのエラーを確実に捉えます。それらの検出コストは何十年も低下し続けており、今後も下がり続けるでしょう。LLMによるコード生成支援は、これをさらに加速させる要因となります。生成されるコードの構文的な質は概して高く、一般的なエラーパターンは学習データの中に十分に反映されているからです。

一方で、概念的な問題とは、システムの「モデル」における逸脱です。要件の誤った解釈を正しく実装してしまった機能、ドメイン概念を正確に表現しているが実はその概念自体が間違っていたデータ構造、実際には合意されていない契約に基づいて2つのサービスを理路整然と接続してしまった統合パターンなどがこれにあたります。静的解析ではこれらを検出できません。自動テストも、正しい仕様に基づいて書かれていない限り検出できません。仕様が間違っていればテストも間違っており、テストはパスしてしまうからです。

このアシンメトリー（非対称性）——エラーは見つけられるが、概念的な問題は見つけられない——こそが、ソフトウェア品質における永続的で構造的な課題です。これはツールが進化しても軽減されません。むしろ激化します。デリバリーサイクルが速くなることで、概念的な問題がコード化される前にそれを浮き彫りにするためのコミュニケーションに割ける時間が減少します。AI支援ツールは、要件理解の精度を高めることなくコード生成のスループットだけを向上させます。結果として、エラーのリスクに対する概念的問題のリスクの比率が高まっていくのです。

仕様のバリデーターではなく、増幅器としてのAI

LLMベースのコーディング・ドキュメントツールは、現在の能力レベルでは、プロンプトのコンテキストにあるものを高品質に増幅する「増幅器」です。プロンプトに表現された意図に合致する、構文的に正しくスタイルが適切なコードを生成することには長けています。しかし、プロンプトに表現された意図が「顧客の頭の中にある意図」と一致しているかどうかを検証することについては、不得手です。

これは批判ではなく、原理的にそれらが何であるかというツールの動作範囲の説明です。Transformerの背後にある数学や学習プロセスを少し理解すれば、こうしたツールに投影されすぎた過度な期待を修正できるでしょう。しかし、それはまた別の機会の話です。信号増幅器は信号とノイズを等しく増幅します。もしLLMコーディングツールへの入力に概念的に誤った仕様が含まれていれば、出力は「より大きく、洗練され、フォーマットの整った、概念的に誤った仕様」になります。実装エラーの検出率は高くなりますが、概念的エラーの検出率は低いかゼロになります。この環境におけるテストエンジニアの役割は、エラー検出においてツールと競うことではありません。「この仕様は顧客が必要としているものを正しく反映しているか？」という、ツールが答えることのできない問いを投げ続ける規律を維持することなのです。

品質インフラとしての短いフィードバックループ

チームコミュニケーションにおける実践的な意味合いはこうです。「何をなぜ作るのか」と「それをどう検証するのか」の間のフィードバックループを、「コードを書く」と「デプロイする」の間のループよりも短く保たなければなりません。AIコーディングツールを使用するスプリントベースのチームにおいて、これはテスト分析会議（あるいはそれに類する対話）が、コード完了後ではなく「ストーリー定義時」に行われることを意味します。開発者、テストエンジニア、プロダクトオーナーが同じ部屋（物理的または仮想的）にいて、受入基準が書かれる瞬間に立ち会う必要があります。なぜなら、その瞬間こそが、最小のコストで概念モデルを修正できる時だからです。

この議論は哲学的なものではなく、経済的なものです。受入テスト中に発見された概念的問題を修正するコストは、ストーリー定義中に修正するコストよりも桁違いに高くなります。LLMツールを通じて大量のコードを生成するチームでは、コミュニケーションへの投資単位あたりのコード生産量が増加します。これは、概念的問題の「欠陥あたりのコスト」が比例して増加することを意味します。コミュニケーションへの投資はコードの量に合わせてスケールしませんが、テストへの投資はスケールさせなければなりません。これは、プロジェクトのあらゆる成果物で手を汚してきた人々には周知の警告ですが、上位管理職には必ずしも完全には理解されないかもしれません。私は、現実のデリバリーという泥臭い現場に片足を置きつつ、もう片方の足でビジョンに触れ続けていることを誇りに思っています。しかし、現実世界に根ざした意思決定がなければ、どんなテクノロジーを投入したとしても、物事は混乱に陥るだけなのです。