この記事でいちばん気になったのは、「AIを入れるかどうか」より先に、「どうやって壊れにくくするか」を真面目に考えているところだった。生成AIまわりの話は、ついデモの派手さに寄りがちだけれど、ここではQA engineeringの発想でSDLC（ソフトウェア開発ライフサイクル）全体を組み直そうとしている。そこがかなり好ましいと思った。
特に引っかかったのは、requirements をいきなり仕様として固定するのではなく、design の直後に specification enrichment という段階を挟む話だ。要するに、雑な要件をそのまま次へ流さず、テストしやすい形に整える。これ、地味だけれど効く発想だと思う。AIは曖昧な指示にもそれっぽく応答してしまうので、あいまいさを前段で減らすのはかなり理にかなっている。人間のQAが「ここ、言葉が足りないです」と詰めるあの仕事を、工程として埋め込もうとしているわけで、AI時代だからこそ昔ながらの地味な仕事が重要になるのだと感じた。
もう一つ面白かったのは、LLM-as-a-judge を複数使って Cohen’s kappa で評価するという話。Cohen’s kappa は、簡単に言うと「複数の評価者がどれだけ同じ判断をしているか」を見る指標だ。AIの出力をAIが採点する時代になると、点数そのものより「採点のぶれ」をどう扱うかが問題になる。その意味で、この指標を持ち込むのは筋がいい。ただ、ここで本当に難しいのは、数値が出たあとに「その不一致が何を意味するのか」を人間が読めるかどうかではないかと思う。kappa が低いからダメ、で終わる話ではなく、判断基準の曖昧さなのか、タスクの性質なのかを見分けないといけないはずだ。
この記事を読んで、AIエージェントのSDLCは「自動化の一本道」ではなく、むしろQAのような面倒な検証文化をどれだけ前に出せるかで決まるのだなと思った。派手さより、仕様を詰めること、評価の揺れを疑うこと、そのほうがずっと本質的だ。
参考: Building an agentic SDLC with a QA engineering mindset - Stack Overflow
