JaSST Tokyo 2026参加レポート

こんにちは。品質保証本部タレントマネジメントユニットのtoyoseaです。
2026年3月20日（金）に、東京ビッグサイトで開催されたJaSST Tokyo 2026にSmartHRのメンバーが参加および登壇しました！

今年のJaSST Tokyoは、基調講演から事例セッションに至るまで生成AIをテーマにした発表が非常に多く、QAエンジニアの役割やテストプロセスがAIによってどう変わっていくのか、各社の試行錯誤が垣間見えるシンポジウムでした。

本記事では、その中でも特にSmartHRのQAメンバーの興味を引いたセッションを取り上げ、それぞれの概要と感想を紹介します。すべてのセッションをカバーすることはできませんが、雰囲気の一端でも伝われば幸いです。

SmartHRとしての登壇については過去のブログにてまとめてあります。 tech.smarthr.jp

印象に残ったセッションと各メンバーの感想

ここからは、SmartHRのQAメンバーが特に印象に残ったセッションについて、各セッションの概要と執筆者の所感に加え、参加した筆者以外のメンバーから寄せられた感想も紹介します。

本記事で取り上げきれなかったセッションも、それぞれ示唆に富む内容ばかりでしたので、興味を持たれた方はぜひ公式サイトで登壇資料をチェックしてみてください。

A2）曖昧な要求は仕様かバグか? ―AI時代の仕様とテストを考える

freee株式会社の苅田蓮さん・栗田太郎さんによる企画セッションです。「要求・要件・仕様」という普段我々が当たり前に使っている言葉を、AIが仕様策定やテスト生成にも関わるようになった時代に改めて問い直す、というスタンスの発表でした。

自分たちの普段の業務でも、曖昧な要求に対してどう向き合っていくべきか悩む場面に直面することがあったので、印象に残りました。

SmartHRの他のQAメンバーの感想

要求・要件・仕様それぞれの言葉を使っているが、適切に定義して利用できていないかもしれない、という気付きがあった。
要求・仕様の厳密化を生成AIが担っていく未来において、どこまでの厳密さ（精度）のチューニングができれば任せられるようになるのだろうか。どこまでを任せるべきかの境界点についてみんなどう考えているかに興味をもった。
妥当性をどのように確認していくかが重要になっていく点については登壇者と同じ見解だった。

A3-2）AIがQAエンジニアの仕事を奪うのか？

「チームみらい」の安野貴博さんと、テクバンの豊田悠太さん・長島貴雄さんによるテクノロジーセッションです。「奪われる／奪われない」の二元論ではなく、AIインタビュアーの実例なども交えながら、QAエンジニアの役割がどう変化していくかを前向きに議論する内容でした。

QAエンジニアという職種の将来像を語るセッションは数多くありましたが、その中でも自分たちの業務に持ち帰れる示唆が多かったと感じました。

SmartHRの他のQAメンバーの感想

AIインタビュアーの取り組み面白かった。AIにインプットするための情報は、知識を言語化するところから始まるので、AIインタビュアーとの会話を通じて形式知にしていくのはやってみたい。品質保証の現場に限らず利用できそう。
ユーザー要求の理解やドメイン知識の部分の解像度をいかに上げられるか、なぜ作るか、何を作るかの情報の精度を高める重要性が高まったと感じた。
「QAエンジニアの仕事は無くなりはしないが変化していく」という点は納得感があり、特にAIの活用前提で役割や価値の出し方を再定義していく必要性を改めて感じました。

B3-1）欠陥分析（ODC分析）における生成AIの活用プロセスと実践事例

株式会社SHIFTの石井優さん（CATエヴァンジェリスト）・山腰直樹さん（Executive Test Specialist）・吉澤麻由さん（Test Engineer）によるテクノロジーセッションです。ODC分析という欠陥分析手法において、最も工数を要する「分類」工程に生成AIを適用し、2週間かかっていた作業を1時間に短縮した実践事例が紹介されました。「人間の分類プロセスを仕様としてAIに渡す」というスタンスで、AIの曖昧さを許容する救済カテゴリの設計や、結果と理由をセットで出力させて自己整合チェックを行わせるといった、現場ならではの工夫が具体的に語られていた点が印象的でした。

不具合分析の課題はSmartHRのQAエンジニア間でも話題によくあがるテーマで、応用できそうな具体的な知見を持ち帰れる発表だと思いました。

SmartHRの他のQAメンバーの感想

自然言語の分析では、やはり文章の標準化が重要だと感じた。
- 不具合報告を分析する際、文章の質で分析の精度に差が生じる問題があった。
- 改善のための分析でも、コードレビューのための仕様理解でも、AIが読みにくい文章が足を引っ張る未来に危機感を覚えた。
曖昧さを許容するために救済用カテゴリを設定するのは自分の不具合分析でも取り込みたいと思った。

speakerdeck.com

F3-1）あなたのシステムの壊し方

Ubie株式会社の末村拓也さん（Software Engineer in Test）による公募セッションです。「ぶっ壊すのがテスターの本懐」という熱量で、UI操作・開発者ツール・データ・フォールトインジェクション・カオスエンジニアリングまで、システムを壊すための観点とテクニックを Knowns-Unknowns のフレームで体系的に整理した発表でした。「壊すことは何が起きるかを知ること」というメッセージを軸に、Known-Unknowns を Known-Knowns に変えていく実験としてテストを位置づける視点が印象に残りました。

AI関連のセッションが多い中で、テスト実行そのものの引き出しを増やしてくれる骨太な発表として位置づけられ、明日からの探索的テストに直接活かせるような内容だと感じました。

SmartHRの他のQAメンバーの感想

UIで壊すしかやってなかったなと思ったので、探索的テストの観点をアップデートしようと思いました。
様々な観点での壊し方が紹介されており、壊したい気持ちになりました！開発者ツールはまだ十分に使いこなせていないと感じたので、今後の改善余地があると認識しました。
壊すとは何が起きるかを知ること（名言ですね）。壊し方のTipsを聞いて、こういう観点を更新していきたいという気持ちになりました。

speakerdeck.com

F3-3）バグ重篤度とテストサイズを用いたテストアプローチによるSaaS製品の信頼性とリリース速度の向上

freee株式会社の苅田蓮さんによる事例セッションです。バグの重篤度に応じてテストケースを選定し、それをリグレッションテストとしてCIで自動実行する仕組みを構築したことで、テスト時間の効率化と品質の両立を実現したという実践報告でした。「何を守るべきかを論理的に整理する」というスタンスで、限られたリソースの中で守るべき品質を可視化していくアプローチが語られていました。

SmartHRもSaaSプロダクトを多数抱えており、いかに開発速度を落とさず品質を守るかは喫緊の課題です。重篤度・テストサイズという軸での整理はテスト戦略の策定時に参考にしたいと感じました。

SmartHRの他のQAメンバーの感想

とても良い題材で、バグの重篤度によってテストケースを選定し、選定したテストケースをリグレッションテストとしてCIで自動で実行する仕組みによってテストの時間の効率化と品質の向上に繋がったという発表でした。
バグの重篤度は現状取り入れてないので今後活用シーンを整えて取り入れてみたい。テストサイズは手動テストの最適化にも使えそう。
何を守るべきかを論理的に整理し、より少ないリソースで品質を担保していく取り組みは、AIで開発スピードが上がっている中でリリース速度を落とさないために有用な手段かと思いました。ぜひ取り入れてみたい。

感想

本記事では取り上げきれなかったセッションも含め、全体として昨今のAI開発における潮流に沿った形のセッションが多く、興味深い内容ばかりでした。革新的な発表内容というよりかはアプローチ方法を模索している最中の取り組みも多く、自社でも参考になりそうなセッションが多かったです。またAIをより使っていくにあたりコンテキストの整理が大事になってくるとは思うので、QAエンジニアとして何をしていくべきかについても考えさせられました。

特に「A3-2）AIがQAエンジニアの仕事を奪うのか？」で述べられていた「QAエンジニアの仕事は無くなりはしないが変化していく」というのはまさにその通りだと思っており、1年後のJaSST Tokyoではまた違ったQAエンジニアのAI活用のアプローチが出てくるのではないかと思っています。