JaSST’26Tokyo参加を通してQAエンジニアが考えたこと

はじめに

ソフトウェア内製開発チームでQAエンジニアをしている遠野です。
先日ソフトウェアテストのシンポジウム「JaSST’26Tokyo」へ行ってきました

セッションタイトルからみてもわかるように、今年はAI×テスト の話が中心でした。

わたしも絶賛 AI×品質 について取り組んでいる最中だったため、セッションを通して視野が広がる部分が多かったです。

JaSSTへの参加を経てQAエンジニアが考えていることを共有します。

背景：いまチームでやっていること

JaSSTでの話を共有する前に、チームで取り組んでいる内容について共有します。

わたしが今参加しているチームでは、AI駆動の開発プロセスへ変えていく（試してみる）流れがありました。

もちろんQA、およびテストプロセスに関しても、どこの何をAIにするのか（できるのか）考える必要がありました。

開発中の様々な作業がAIになっていく中で、チームに一人しかいないQAの作業を、たとえ全部AIに置き換えたとしても速さが出せるとは思えませんでした。

どうしたらまともに速さに追いつけるか考えたときに、QAが取り組むべきだと思ったのは「レビュー」でした。

具体的にやっていることは以下のような感じ

1. これまで自分がつくったテストケースをAIに分析させて、「テスト観点」を抽出
2. PBIに対して出したレビューコメントを分析させて、「PBIレビュー観点」を抽出
3. これらの観点をPBIレビューとPRレビューに組み込んでもらう

QAの視点を「観点」として開発プロセスに埋め込んでもらえば、自分（人間）が一人しかいなくても品質が上げられるはずだ。と信じて取り組んでいます。

JaSST’26Tokyoで聞いてきたこと

各セッションで話されていたことはチームの取り組みに活かせそうなものがたくさんありました。

AIがテストを実行することについて

基調講演では、AIにテストを任せるデモや、AIのテストへの活用事例がありました

• 探索的テスト
  • ClaudeにJIRAのユーザーストーリーを渡す
  • コンテキスト理解→テスト対象操作→（mcp使っていいですか？とか確認）→文字入力したりして探索
  • スクショをとって結果を比較
• 自動テストの生成
  • Copilotに「スクラム6(検索機能)に対してテストしてね」と頼む
  • Agentがテストプラン生成 → Playwrightでテストコード作成

AIがテストをどのように進めているのか、デモで流れを知れて参考になりました

AIによるテスト実行のリスク

基調講演をはじめ、他のセッションでもAIでテストすることのリスクが語られていました。

• ハルシネーション
  • AIは「知らない」と言えないように訓練されているため、当てずっぽうの結果を出すこともある。実行結果をしっかり確認しなければならない
    • 「テスト終わりました！」って言ってるけどボタンすら押してないとか
• 非決定論的である
  • 「テスト」は本来決定論的なもの
  • AIの出力は日によって結果が変わる非決定論的なもの
  • 人間が無意識に行っている判断ともまだギャップがあるので、1回の出力結果を鵜呑みにしてはいけない
• 過信してしまう
  • AIの結果をそのまま受け入れることで結果的に時間をロスする
  • 生成されたコードやテストは全部レビューする前提でなければならない
  • 生産性の向上は10倍ではなく10%程度ではないか、という見立てもある

リスクをわかっていても大量の情報量の中では真面目に応答しながら回避できそうにないので、仕組みで回避しなければならないという思いを強めました

“テスト”から”評価”へ変わっていく

トークセッション「AIと品質保証のこれまでとこれから」では、品質保証の考え方そのものが変わりつつあるという話がありました

• 決定論的なテストでは立ち向かえない
  • 「富士山は日本一高い山です」と「富士山は日本で一番高い山です」どちらも正解
  • メトリクスで繰り返し計測して、統計的に判断するしかない
  • 「リリース前に確認すれば安心」ではない
• 継続的に評価し続ける「運用型QA」が増えつつある
  • リリース前に行った評価をプロダクション環境でも満たし続けられるかチェック
  • ズレたら修正、を繰り返して1周するごとにちょっとずつよくなる

統計的な見方は必要だという点にとても納得しました

暗黙知を形式知にする

AIを上手く動かすには、無意識・暗黙知を渡す必要があります。

セッション「AIがQAエンジニアの仕事を奪うのか？」にて具体例が紹介されていました。

• “AIインタビューア”（内製したツールとのこと）
  • ◯◯に対して情報収集してと指示すると、ユーザーへ深堀りする質問をAIがしてくれる
  • 社内の詳しい人へ質問をしにいって形式知化してくれる
  • AIインタビューアのURLを発行して回答してもらうと、配ってから24時間で1000時間分の情報が集められる

たしかに、形式知化にもAIを使えばいいんじゃん！と視野が広がりました

ハーネスエンジニアリング

当日は正直うっすら聞いたことがあるようなないような…という単語でした

• AIによりよい環境を整えるアプローチ
• QAの立場から、品質環境を整えるようなハーネスエンジニアリングのアプローチができる
• AIはプロセス品質も指定・要求してつくらせないとそのときそのときのプロセスでつくってしまう。細かく指定しても、それでも無視することがある

できる限り同じような範囲のアウトプットになるように、仕組みでなんとかすることをいつも意識しているので、引き続き取り組んで行こうと思えました。

今後やりたいこと

JaSSTで聞いた話をもとに自チームの取り組みを振り返ってみると、「観点をプロセスに埋め込む」取り組みはまさにハーネスエンジニアリングの考え方だと思いました。

一方で、PBI作成時やPRレビュー時に埋め込むだけではまだ「ゲート型」のアプローチの域を出ていません。

これからは非決定論的な結果を理解したうえで、継続的に評価できるような仕組みにしていきたいと考えています。例えば、

• レビュー結果を観点ごとにラベリングする
• ラベルごとの検出件数をとる
• レビュー対象側もカテゴリ分けをする
  • 改修規模（変更行数などで）
  • 改修対象：コア機能なのかUIなのかどういう処理なのか
    • まだ分け方のアイデアなし…
    • テスト観点にすでに入っているのでそのあたりと連動させたい

など…開発チームは信頼度スコアなどで人間がレビューする基準をつくったりしているので、
そういったアプローチも参考になりそうです。

JaSSTでデモされていた「AIにテストを任せる」ことは、わたしの手元ではまだほとんどできていませんが、品質観点を埋め込むための考え方が活かせそうだと感じています。

おわりに

JaSSTを通じて、話を聞けば聞くほど、「基本が大事」だと感じました。

AIを使うだけですべてが速くなるわけではなく、使い方を理解したり当てはめてみたりコントロールや調整をしたり評価・見守りをしたり、地道に積み重ねる作業が求められていると思いました。

やっていることに対して方向性が同じだと感じるセッションもあり、間違っていないと少し自信をもてた1日でした。

1日の中では見れていないセッションも多くあるので、アーカイブも見ていこうと思います。

おつかれさまでした