書いた後の検証方法：Doc Testingでコーディング前にギャップを発見する

明確で完全だと思える仕様を書き上げた。それが実際に十分であるかどうか、どうすれば分かるだろうか？

直感的なアプローチは、Agentに渡して実行させ、出力が期待に合致するか確認することだ。しかし、このフィードバックループは長すぎる。Agentがコードを書き、コードをレビューし、逸脱を発見し、仕様の曖昧さまで遡り、仕様を修正し、再実行する。1つの曖昧さを修正するのに1時間かかることもある。仕様に5つの曖昧さがあれば、丸一日が消える。

Doc Testing¹はより短いフィードバックループを提供する。その中核的アイデアは、コードを一切書く前に、AIを使って仕様自体に対する「思考実験」を行うことである。

具体的なアプローチは、ユーザーストーリーをテストケースとして使い、AIに仕様をステップバイステップでウォークスルーさせることだ。各ユーザーストーリーについて、トリガーとなるアクションから出発し、仕様が完全な実行パスを提供しているか確認する。必要なインターフェースは定義されているか？パラメータと戻り値は完全か？例外ケースはカバーされているか？状態遷移は整合しているか？

例えば、決済モジュールの仕様に対して、AIに次のようなユーザーストーリーをウォークスルーさせることができる。「ユーザーが決済リクエストを送信し、決済ゲートウェイがタイムアウトを返し、待機中にユーザーが同じ決済リクエストを再送信する。」仕様が冪等性の処理戦略を定義していなければ、Doc Testingはここで行き詰まり、このギャップが露呈する。

このプロセスのコストはトークン消費のみである。完全なDoc Testingセッションは通常数分で完了する。比較として、Agentにすべてのコードを書かせてから仕様の問題を発見した場合、修正コストは桁違いに高くなる。

Doc Testingには明確な限界がある。AIはウォークスルー中にハルシネーションを起こす可能性がある。仕様が実際には十分な情報を提供していないにもかかわらず、パスが機能すると主張するかもしれない。そのため、Doc Testingの結果には人間のレビューが必要である。その価値は問題発見のコストを劇的に削減することにあり、人間の判断を完全に置き換えることにはない。

Doc Testingで発見されたすべての問題は仕様に書き戻す必要がある。Doc Testingで欠落している境界条件が明らかになった場合、修正は仕様のacceptance_criteriaに対応するエントリを追加することであり、「次回はこれに注意しよう」と心に留めておくことではない。仕様が単一の情報源（Single Source of Truth）である。すべての知識と判断は仕様に捕捉されなければならない。

¹. Doc Testingの概念はKeqian Xu氏（AgentsZoneコミュニティ）によって提唱された。 ↩