こんにちは！TOKIUMでQAチームのリーダーをしている西田です。
6月にnoteにて、AIエージェントの品質保証という未知の領域への挑戦について、私たちが直面している課題と取り組みの方向性をお話しさせていただきました。
前回の記事はこちら
あれから数ヶ月、実際にAIエージェントのテストに取り組み、多くの試行錯誤を重ねてきました。
今日は、その実践の中で得た学びと、正直な失敗談も含めて共有させていただきます。
「動きながら考える」― 複数のAIエージェントテストへの挑戦
前回お話しした通り、AIエージェントのテストには「正しい答え」が存在しません。そんな中、私たちは複数のAIエージェントのテストを同時並行で実施するという、かなりアグレッシブな挑戦に踏み切りました。
「まずはやってみよう」
そう決めて動き出したものの、正直に言えば手探り状態でのスタートでした。しかし、この「動きながら考える」アプローチが、結果として多くの学びをもたらしてくれました。
実践から生まれた4つのブレークスルー
1. リスクベースドテスト ― 「何を守るべきか」の明確化
AIエージェントのテストを始めるにあたり、まず取り組んだのがリスクの可視化でした。
ステークホルダー全員に協力してもらい、テスト対象で懸念されるリスクを徹底的に洗い出しました。「このAIエージェントが誤動作したら、何が起きるのか？」「お客様にどんな影響があるのか？」こうした問いを一つ一つ検討していきました。
洗い出したリスクに優先度をつけることで、リリース判定において重要な判断軸を得ることができました。ユーザーストーリーの達成状況とは別の観点から、「何ができていて、何ができていないのか」を明確に把握できるようになったのです。
QAチームとしても、この取り組みは非常に有益でした。潰すべき「リスク」が可視化されたことで、「このリスクを発生させるには、どんな入力が考えられるだろうか？」という具体的なテスト設計が可能になりました。漠然とした不安から、具体的なテスト項目への落とし込みができたことは、大きな前進でした。
2. 複数人での探索的テスト ― 「多様な視点」の価値
AIエージェントの回答は、同じ質問でも微妙に異なる答えを返すことがあります。この特性を逆手に取り、複数のQAエンジニアが同時に探索的テストを実施する手法を試みました。
異なる視点からのアプローチにより、一人では気づけなかった挙動パターンや、思いもよらない使い方での不具合を発見できました。特に「こんな聞き方をする人もいるかも」という、ユーザー視点の多様性を反映できたことは大きな収穫でした。
3. ランダム命令生成ツール ― カオスエンジニアリングの応用
「AIエージェントにどんな命令を投げたら、どんな反応をするだろう？」
AIエージェントへの入出力をテストするにあたって、多種多様な入力パターンを用意することは必要不可欠でした。当然、試すパターンは多ければ多いほど良いのですが、人間が思いつくパターンには限りがあります。どんなに考え抜いても自分が想像できる範囲しかカバーできないため、このパターンで十分だろうか？」という不安は常につきまといます。この課題を解決するための手段が、AIエージェントへの入力命令をランダムに生成するツールでした。
例えば「来週A社への出張を予定しているので予定を組んで欲しい」という内容の命令をするとします。ランダム生成ツールを使って、
- 言い回しを変える（「明日」「○月×日」「今週の水曜日」のような表現の揺れ）
- わざと誤字脱字を含ませる
- 文中に矛盾を混ぜ込む
といった様々な要素を組み合わせて「概ね意図する内容は同じだけれど文章はまるで異なる」多量の命令を試すことができました。まさに、AIをテストするためにツールの力を借りるという、新しい品質保証のアプローチでした。
4. ペルソナベースのシナリオテスト ― 「誰のための品質か」を明確に
幸いなことに、実際に利用開始されるお客様が決まっていたため、会社規模やチーム規模など、テストに活用できるペルソナ情報が豊富にありました。
「このお客様なら、きっとこう使うだろう」
「この規模の会社なら、こんな質問が多いはず」
こうした想定問答を基にシナリオテストを構築することで、無限にある入力パターンの中から、本当にテストすべき範囲を効果的に絞り込むことができました。
現在進行形の挑戦 ― リアルタイム品質可視化
現在トライしているのは、ハルシネーション率、妥当性、回答完全性、コストなど、計測可能な情報をリアルタイムで確認できる環境の構築です。
「今、AIエージェントはどのくらい正確に答えているのか？」
「コストパフォーマンスは適切か？」
こうした問いに即座に答えられる仕組みがあれば、品質の判断がより客観的になると考えています。これはリリース可否の判断に留まらず、プロダクトに関わる全員、社内だけでなくお客様にとっても利となる活動だと考えています。
正直に語る、3つの苦労と失敗
苦労1：品質水準の「答え」が存在しない
従来のテストでは「期待値」が明確でしたが、AIエージェントには絶対的な正解がありません。「これで十分なのか？」という問いに、誰も確信を持って答えられない状況は、QAエンジニアとして非常にもどかしいものでした。
対SaaSで実施していた従来のテスト設計・テスト実行をそのままなぞろうとすると「テストケースに記載されている期待値と合致しないからNG」「しかし求める回答の70%程度はクリアしているから、厳密にはNGではない。チャットを続けることで解決できる」というように「NGとも言えるがOKとも言える結果」が多く見られました。
詳細なテスト設計を行うことが逆に足枷になってしまうこともある点が、新たな学びでした。
苦労2：変則的なテストスケジュール
「何月何日までに最低限このレベルは達成したい」という、従来とは異なるスケジュール管理が必要でした。明確なゴールが設定しにくい中で、段階的な品質目標を設定し、チーム全体で合意形成していく作業は、想像以上に難しいものでした。
苦労3：バグチケット起票の困難さ
AIエージェントの回答に揺れがあるため、「これはバグなのか、仕様なのか」の判断が非常に困難でした。複数のメンバーから上がってきた報告が、よく整理すると同じ現象だったり、再現が極めて困難な事象も多々ありました。
失敗から学んだこと
最大の失敗は、チーム全体を巻き込めなかったことでした。
既存SaaSのテストを維持しながらAIエージェントのテストにトライするため、参加メンバーを絞って進めていました。しかし、これが結果として大きな問題を生みました。
チーム内でAIエージェントに対する知識差が広がり、急遽人数を増やしたいときの立ち上がりに時間がかかってしまったのです。また、トライしたいことは山ほどあるのに、作業を分担できる状態になっていませんでした。
「その作業を割り振るためには、まず私が方針を決めなければ..….」
「その前段の整理作業を済ませなければ...…」
こんなボトルネックが発生し、スピード感を持って進められない状況に陥ってしまいました。今思えば、最初から全員を巻き込んで、知識レベルを揃えながら進めるべきでした。
手応えを感じた4つの発見
失敗や苦労もありましたが、確かな手応えも感じています。
1. ユーザーストーリーとリスクベースの二軸評価
個々の動作の品質判断は主観的になりがちですが、ユーザーストーリーが達成できているかという観点と、重要なリスクが回避できているかという二つの軸で評価することで、より多角的な品質判断が可能になりました。
「○○の精度が△△%を超えたらOK」といった基準は社内の合意形成次第ですが、「ユーザーが達成したいことが達成できているか」「ビジネス上のリスクは許容範囲か」という複合的な視点により、本質的な品質評価ができるようになりました。
2. ペルソナベースのアプローチの有効性
AIエージェントへの入力パターンは無限にありますが、ペルソナを明確にすることで、テストすべき範囲を効果的に絞り込めました。「誰のための品質か」を常に意識することの重要性を改めて認識しました。
3. 従来手法が活きる領域の発見
AIエージェントとのやりとりが発生しない部分（画面表示・操作・UX）については、今までのQA手法がそのまま活かせることがわかりました。すべてが新しいわけではなく、既存の知識と新しいアプローチを組み合わせることが重要だと学びました。
既存の手法を活用できる部分・できない部分を早々に仕分けることができれば、既存手法範囲は先行してテストを済ませ、AIエージェント固有の検証難易度の高い範囲をじっくりトライしながら検証できます。
4. ステークホルダー間の合意形成の重要性
明確な答えがない活動だからこそ、PdM、開発、PMMとのコミュニケーションが不可欠でした。
また、判断に迷う状況が多く生まれるからこそ、納得感を持って作業に取り組むことが重要だと考えました。
「もし結果が思わしくなくても、その時点でベストな判断をしたという自信があれば、後悔せずに次に向かえる」
ということです。
この考えを共有し、チーム全体で納得感を持って進めることは、モチベーション維持の観点でも非常に重要です。既存のSaaSのQAよりも、さらにコミュニケーションの重要度が高いと実感しています。
これからのQAチームの挑戦
AIエージェントの品質保証は、まだ始まったばかりです。失敗も含めて、すべてが貴重な学びとなっています。
私たちQAチームは、これからも「お客様の時を生む」というTOKIUMのミッションを実現するため、新しい品質保証のあり方を模索し続けます。正解のない道を進むのは不安もありますが、だからこそワクワクする挑戦でもあります。
次回は、現在構築中のリアルタイム品質可視化システムの詳細や、AIエージェントQAのためのメトリクス設計について、より技術的な内容も含めてお話しできればと思います。
最後に、この挑戦を通じて改めて感じたのは、QAエンジニアという仕事の可能性の広がりです。AIという新しい技術と向き合うことで、私たち自身も進化し続けています。
もし、この記事を読んで「自分も挑戦してみたい」と思っていただけた方がいらっしゃいましたら、ぜひ一緒にAIエージェントの品質保証という未知の領域を開拓していきましょう。
正解のないテストだからこそ、一緒に正解を作っていける仲間を、心からお待ちしています。
Discussion