Introduction
同じ仕様書をAIに渡して、テスト設計を頼みます。一度目は、ある項目を「氏名」と書いてきます。二度目に同じ依頼をすると、今度は「名前」と書く。三度目には、その行ごとすっぽり消えている。中身は何も変えていません。渡した紙は同じ一枚です。それでも、AIは呼ぶたびに違う答えを返してきます。
システムを開発したことのあるみなさん は、作ったシステムの品質保証をするため、なにをテストすればいいかと悩んでそして実際に乗り越えてきたことでしょう。そして、AI時代の今日、AIでそれをもっと早く確実にできるのではと期待したこともあるでしょう。ただ、AIの回答が出力の度にかわってしまって、不安に感じたこともあるのではないでしょうか。
これは欠陥ではなく、いまの大規模言語モデルの素の性質です。人間でも 同じ資料を二度要約すれば、選ぶ言葉は毎回少しずつ変わります。ふだんは些細なことですが、テスト設計ではこの「ゆらぎ」が致命傷になりかねません。 最初に作る一枚の表がブレると、その後の工程がドミノのように崩れていくからです。我々が開発してきて最初にぶつかったのは、まさにこの壁でした。
では、呼ぶたびに揺れるAIとどうやって付き合っていったかのか。この記事では、その試行錯誤の裏側をご紹介します。
具体的には、三つの自己チェックの仕組みと、「賢いAIなのにあえて自分では直させない」という一見直感に反する判断の理由。そして、土台を固定するループと中身を改善するループという性質の異なる二つを、あえて混ぜずに噛み合わせることで安定を生み出す考え方――これらを、開発現場の実際のエピソードとともに解き明かしていきます。
目次
すべての基準線になる、一枚の表
SHIFTが開発するテスト設計AIエージェント(以下、「ネムラナイ」)は仕様書を読み込むと、まず「テスト対象フィールドの一覧表」を作成します。社内ではこれをCM(Category Matrix)と呼んでいます。区分1から区分4と、さらにそれぞれの要素の型を並べた、設計全体の出発点です。
このCMが特別なのは、後続のあらゆる工程―テスト観点を洗い出す工程も、テストケースを生成する工程も、カバレッジを測る工程も――が、この一枚を「基準線」として参照し続ける点にあります。
言い換えれば、CMは全員が手元に持つ一本の物差しです。
物差しがしっかり固定されていれば、誰が測っても同じ結果になります。ですが目盛りが測るたびに伸び縮みしたら、測定結果は何ひとつ信用できません。だからCMだけは、何があってもブレさせてはいけない。ネムラナイではこのCMを、「唯一の真実(SSOT=Single Source of Truth)」と位置づけています。
土台が動くと、改善は空回りする
なぜそこまでCMにこだわるのか。CMが毎回変わると、品質を良くしていくはずの改善ループそのものが空転してしまうからです。下の図は、その違いを並べたものです。
| SSOTなし ― CMが毎回変わると | SSOTあり ― CMを引き継ぐと |
|
① 計測がズレる |
① 正確に差分を測れる |
|
② 修正の的が外れる |
② 的確に直せる |
|
③ 同じ問題が繰り返す |
③ 改善が積み上がる |
| → ループが空転する | → 品質が積み上がる |
図1 SSOTがなければ、イテレーション機能は成立しない(CMが毎回変わると3ステップが連鎖して機能不全に陥る)
三つの自己チェックで、ゆらぎを消す
揺らがないようにするには、プロンプトの精度を上げる というのも一つの方法です。
曖昧な指示では、AIに解釈の余地を与えてしまう からです。そしてそのプロンプトはSHIFTが長年培ってきたQAエンジニアのノウハウのエッセンスを取り込んでいます。それだけでも、他社のエンジニアが作った AIエージェントよりも精度と安定性が高いものができている自負があります。詳細は別の記事で書きたいと思いますので、ここでは、それに加えて講じた三つの自己チェックの仕組みを紹介します。
ひとつ目は「セルフ・コンシステンシー」です。同じ抽出を複数回やらせて、共通して出てきたものだけを残します。同じ絵を二回描かせて、両方に共通して引かれた線だけを残すようなものです。気まぐれな一回限りのハルシネーション(思い込みの幻)は、この時点でふるい落とされます。しかも「氏名」と「名前」は、表記が違っても意味が同じだとちゃんと見抜いて同一扱いにします。
ふたつ目は、前回のCMとの意味的な突き合わせです。同じ項目なら前回の表記をそのまま引き継ぎ、本当に新しく増えたものだけを取り込みます。これで「中身は同じなのに表現だけ変わる」ゆらぎを封じます。
| 前回のCM | 今回LLMが抽出 | 確定版CM |
| ログイン画面 |
ログイン画面 |
ログイン画面 |
| 検索フォーム |
検索ボックス |
検索フォーム |
| ユーザー設定 |
ユーザー設定 |
ユーザー設定 |
| 通知一覧 |
通知リスト |
通知一覧 |
| 決済画面 |
(今回は |
決済画面 |
図2 CMの継承イメージ――今回抽出したCMを前回と照合し、同じ意味なら吸収。本当に新しい項目だけ追加する。表記揺れは前回の名前に統合され、項目名がビルド間でブレない
三つ目が、変化の大きさを見張る関門です。前回からの変化率が一定の割合を超えたら、ネムラナイは自分から処理を止めて人を呼びます。この「一定の割合」は、勘で決めたものではありません。過去のビルドデータで検証し、計算の仕方を調整して、止める必要のない変化でうっかり止まってしまうのを大きく減らしつつ、本当に止めるべき変化は一つも見逃さない―そう確かめて選んだ、調整済みのラインです。
「賢く直さない」という、いちばんの賢さ
ここに、直感に反する設計判断があります。ネムラナイは賢いAIなのに、一度CMに入った表現を自分で勝手に直しません。誤字があっても、表現がぎこちなくても、自動では書き換えない。表現の修正は、人が手で編集してレビューを通す道だけに限っています。なぜそんなに頑固なのか。開発者の言葉がいちばん的を射ています。
「LLMは揺れる。それだと、前回の結果より良いものができたかを評価できない。だからSSOT厳守にした」
ここに全部が詰まっています。良くなったかどうかを測るには、測る土台のほうが動いていてはいけない。土台が毎回変わっていたら、出力が良くなったのか、ただ土台がずれただけなのか、永遠に区別がつきません。融通を利かせないことが、結果としていちばん信頼できる――ネムラナイはそう割り切っています。
二つのループを混ぜない――だから安定する
整理すると、ネムラナイには性質の違う二つの自己評価があります。ひとつは「定規を固定する」ループ。いま見てきたCMの安定化がこれです。もうひとつは「測りながら中身を直す」ループ――品質を計測し、AIがレビューし、テストケースを修正し、方針を改善していく流れです。
| 1.測る | 2.直す | 3.改善案 | 4.次ビルドへ |
| 品質計測+LLMレビュー |
テストケースを修正 |
脱落分析 |
改善案を引き継ぎ再設計 |
図3 ネムラナイのイテレーションループ――「測る→直す→改善案の申し送り」に対してビルドをまたいで繰り返し、テストケースの品質を自動で積み上げる
後者はテストケースの中身だけを直し、定規であるCMには決して触りません。この二つを混ぜないのが安定の秘訣です。先に定規を固定するからこそ、測定したカバレッジを信用できます。もし定規ごと動かしてしまえば、CMの行が減ったぶん分母が小さくなって数字だけ良く見える――そんな見せかけの改善に騙されかねません。そして、改善ループも「なんとなく」では止まりません。ネムラナイは明確な数値基準を持っています。ネムラナイはこれらの基準を満たすまで自分で何度もループを回し、満たしたら自分で止まります。
最後に
AIが普及して、様々な可能性が広がる世の中ですが、実際に使って みるとさまざまな課題にぶつかることでしょう。その一つは、「AIの成果物を信用できるか」「誰がそれに責任を持つのか」だと思います。
品質保証の現場では特にそれが顕著に問題視されます。
この記事では 、徹底してブレないように固めた「土台」と、その上で回り続ける「改善のループ」、この二つが噛み合わせることで、何度呼んでも安定したアウトプットを 出させた事例を紹介させていただきました。同じ仕様書から毎回違う答えを返すAIを、信用できる設計パートナーに変えたのは、この自己評価の仕組みそのものなのです。
▶「ネムラナイ」 のサービス詳細・お問い合わせはこちら
https://contents.shiftinc.jp/nemuranai/