はじめに タイミー QA Enabling Gの矢尻、岸、松田です。 ソフトウェアテストに関する国内最大級のカンファレンス「JaSST (Japan Symposium on Software Testing) ‘26 Tokyo」が、2026年03月20日に開催されました。 タイミーには、世界中で開催されるすべての技術カンファレンスに参加できる「KaigiPass」という制度があり、この制度を利用してオフラインで参加しました。 jasst.jp 今年の会場は東京ビッグサイトでした。 本レポートでは、印象に残ったセッションの内容を中心にお伝えします。 JaSST Tokyo 2026 参加レポート — AI駆動QA時代の到来とタイミーの現在地 タイミーの矢尻です。 今回のJaSSTは、前回にもから増して AI関連セッションが圧倒的に多い 回でした。基調講演からクロージングまで、ほぼすべてのトラックでAIが議論の軸となり、AI駆動開発における品質保証（QA for AI-Driven Development = QA4AIDD）が業界全体のメインテーマに昇格した印象です。 タイミーでは社内のQAガイドライン「QA Handbook」を通じてAI時代のQA戦略を先行して整備してきました。本レポートでは、セッション横断で見えた 3つの業界トレンド と、タイミーの取り組みとのフィットギャップを総論的にまとめます。 セッション横断で見えた3つのトレンド 今回、私が視聴したのは以下の6セッションです。 AIがテストチームに加わるとき- 期待、落とし穴、そしてソフトウェア品質の未来 – スペシャルトークセッション『AIと品質保証のこれまでとこれから』 AIがQAエンジニアの仕事を奪うのか？ 生成AI時代、ソフトウェア品質保証のロールと組織はどこへ向かうのか？ 品質を経営にどう語るか 人と関わるロボットの研究開発 –ロボットにおける人間らしさの重要性 – 横断すると、業界の議論は大きく 3つのテーマ に収束していました。 1. AIへの「プロセス要求」と人間の監督 複数セッションで共通して語られたのは、 AIに「何を作るか」だけでなく「どう作るか」を明示する 必要性です。 ベリサーブ様のセッションでは「ハーネスエンジニアリング」として、AIにプロセス要求を与えアクティビティログでオーディットするアプローチが紹介されました。SIG SQAの井芹様は「HITL（Human-in-the-Loop）」と「Everything as Code」をキーワードに、人が適切なポイントで介在するプロセス設計の重要性を強調。安野様のセッションでは、AIが一次スクリーニング（リコール向上）を担い、人間がコンテキストを踏まえた精査（プレシジョン向上）を行う「 2層スクリーニング 」モデルが示されました。 基調講演のGayathri Mohan様も、AIは「ベビーシッター」のように常に監視と調整が必要な存在であると指摘しており、 「AIに任せきりにしない品質保証のプロセス設計」が業界の最大関心事 になっていることを強く感じました。 2. リリース後の継続的品質バリデーション もう一つ、独立した複数セッションで繰り返し言及されたのが、 プロダクション環境での継続的モニタリング です。 ベリサーブ様のセッションでは「フライホイール型品質保証」として、リリース前で完結せず本番環境で継続的にスコアを監視→フィードバック→再リリースを回す「運用型QA」が提唱されました。Adobe様の小島様もAIエージェント評価において、事前テストだけでは限界があり実データでの課題探索が不可欠だと強調。基調講演でも、非決定論的なAIの出力に対して確率論的・メトリクスベースの評価が必要だと語られました。 リリース後の品質バリデーションは、もはや「やるかどうか」ではなく 「いつ・どう始めるか」のフェーズ に入っていると感じます。 3. 品質を経営の言葉で語る 3つ目のトレンドは、 品質と経営の対話 です。 kyon_mm様らのセッションでは、品質を「技術の詳細を説明する場」から「事業の優先順位を決める場」に移すための翻訳プロトコルとして、 バランススコアカード（BSC） 、 Cost of Quality（COQ） 、 NIST AIリスクマネジメントフレームワーク の3つが示されました。ベリサーブ様のセッションでも「QAエンジニアは経営の意思決定に必要な情報を提供する立場に移行する」という見通しが語られ、SIG SQAの伊藤様も「事業戦略と連携した品質戦略策定」を高度化すべきスキルとして挙げていました。 作業をAIに委ね、 QAエンジニアの役割がより上流・経営（ビジネス）寄りにシフトしていく という方向性は、セッションを跨いだ一貫したメッセージでした。 タイミーQA Handbookとのフィットギャップ タイミーでは「QA Handbook」として、 3つの戦略 （Business Reliability / Standardized Process / AI-DLC & QaC）を柱にQA活動を体系化しています。上記の業界トレンドと照合した結果を整理します。 ✅ フィットしている領域 業界潮流 タイミーの対応 評価 Everything as Code / AIフレンドリーな成果物 Gherkin/Markdownでの仕様標準化＋教師データ蓄積 先行 HITL型プロセス設計 Generative Testing Pipeline（Human=意思決定、AI=実装） 先行 プロセス要求＋オーディット DoR/AC/DoD＋壁打ちリファインメント 同期 AI×人間の分業テスト設計 テスト仕様書生成（AI一次生成→人間レビュー） 同期 リスクベースドテスト ISTQB準拠のRPN分析を体系的に整備済み 先行 ⚠️ ギャップがある領域 業界潮流 現状と推奨アクション 優先度 リリース後の継続的品質バリデーション 構想済みだが未着手。CUJベースの指標でスモールスタートすべき 高 品質活動のビジネス価値換算（BSC / COQ） エラーバジェット概念をCOQ文脈で再定義するアプローチが有効 高 AIエージェント評価の体系化 4テスト種類×二軸評価指標を自社AI評価に応用可能 中 非決定論的テストへの対応 パイプラインに統計的評価レイヤーの追加設計が必要 中 まとめ JaSST Tokyo 2026を通じて確信したのは、 タイミーのQA Handbookが掲げる方向性は業界潮流と高い整合性を持っている ということです。Everything as Codeによる教師データ蓄積、HITL型のプロセス設計、リスクベースドテストの体系化は、業界が「これからやるべき」と議論しているものを先行して体系化できています。 一方、 最大のギャップは「リリース後の継続的品質バリデーション」と「品質活動のビジネス価値換算」 の2点。いずれも複数セッションで繰り返し言及され、業界コンセンサスが形成されつつあるテーマです。 今回のJaSSTは、AI駆動開発が「一部の先進企業の取り組み」から「業界標準の議論テーマ」に移行したことを実感する場でした。先行して整備してきた資産を活かしつつ、ギャップの解消に取り組むことで、QA4AIDDの実践をさらに一歩進めていきます。 開発チームとの協業とトレーサビリティ基盤 タイミーの岸です。私からは印象に残った二つのセッションの紹介と感想をお届けします。 開発チームとQAエンジニアの新しい協業モデル：年末調整開発チームで実践する [QAリード施策] / SmartHR speakerdeck.com SmartHRの平澤さん・依田さんによる、開発エンジニアとQAエンジニアとの協業の取り組みについての講演でした。 開発チームによる自律的なQAを支援する施策であり、QAエンジニアが開発チームに入り込んで、最初はQAについて支援しつつ最終的にはチームから抜けていくというものです。 特徴的なのは、チームに参加するQAエンジニア以外に、チーム内からもQAを推進するメンバーを立てるという点でした。このメンバーは「QAリード」と呼ばれ、QAエンジニアとの1on1やチーム内での旗振り、テスト技法の勉強会などを通してQAプラクティスを根付かせていきます。QAリードの役割は目標設定にもきちんと反映されていくとのことでした。人選は指名ではなくチームからの立候補を基本とする形とのことで、SmartHRの開発チームにおける品質意識の高さがうかがえました。 こういったチームの自律性支援はタイミーでも実践の真っ最中です。QAリードの役割やQAエンジニアからの推進の方法など、私たちにとっても参考になる点が多く、とても興味深く聴かせていただきました。 仕様漏れ実装漏れをなくすトレーサビリティAI基盤のご紹介 / コインチェック speakerdeck.com コインチェックの国分さんによる、ドキュメント間のトレーサビリティとそれを検査する基盤についての講演でした。 ドキュメント間には関連性があります。例えば、要求からは仕様が派生し、仕様からは設計、設計からは実装が、また設計からはテストケースも派生します。このため、派生元と派生先は矢印で結ぶことでグラフとして表現できます。ここで、矢印の片方にドキュメントが存在しなかった場合は「アノマリー」となり、何かがおかしいことがわかります。派生先が存在しなければ、実装やテストが漏れている可能性があり、派生元が存在しなければ不必要な成果物が作成されている可能性があるということです。そして、コインチェックではこのグラフを検証するシステムをAIを活用して作っているとのことでした。 AI基盤については、可能な限り人手を抑えつつ、偽陽性・偽陰性を抑えるためのチューニングが行われていました。一方でAIを並列して稼働させるためには何よりも金銭コストがかかり、これを抑えるために敢えて軽量なモデルを使用するなど苦慮されている様子でした。 タイミーにおいては、ドキュメントを作成するかどうかチームによるバラツキがあります。そのためこういった検証基盤については、同じものを作っても定着するかどうかは未知数です。とはいえ、複雑化している仕様をどのように管理していくかは私たちにとっても大きな課題です。こういった取り組みを参考にしつつ、自分たちにマッチする仕組みを開発していくことは重要であると感じました。 要求・暗黙知・越境から見る AI 時代の QA タイミーの松田です。 昨年はタイミーとして登壇する側でしたが、今回は一参加者として様々なセッションに参加し多くの学びを得ることができました。 今回の JaSST Tokyo では AI と QA に関するトピックが多く、参加したセッションにはそれぞれ共通するテーマがあると感じました。私はその共通項を 3つ に整理しました。 要求エンジニアリング — QA の基礎能力としての重要性 暗黙知 — AI への適切なコンテキスト提供 越境 — エンジニアリングと QA の役割の進化 本レポートでは、それぞれの学びについてまとめます。 1. 要求工学(エンジニアリング )— QA の基礎能力としての重要性 こちらは、freeeの苅田さん・栗田さんが発表された「曖昧な要求は仕様かバグか-―ai時代の仕様とテストを考える」の発表から得た学びです。 ここでは 「要求工学(エンジニアリング)」 に関しての発表を軸に話が進みました。 カンファレンスでは要求工学に関する発表があり、その重要性が改めて強調されました。 プロダクトには必ず何かしらの価値が求められます。その価値を言語化し、プロジェクトとして具体化するためには、 要求を適切に言語化 → 仕様を策定 → 設計に落とし込む というフローが欠かせません。この流れは、AI を活用する時代になっても変わらない本質的なプロセスです。 AI がどれだけ進化しても、 「なぜ作るのか」が不明瞭もしくは曖昧であれば、意図通り・要求通りのプロダクトを作ることは困難 です。作るべきものの目的と価値を明確にすることは、AI 時代においても変わらず重要な技術です。 シフトレフトの流れの中で、QA エンジニアは 要求事項の適切性を検証する 役割を担います。要求が適切でない場合、そこには暗黙の前提や仮定が隠されている可能性があります。要求獲得などの技法を活用し、暗黙知を明確に引き出して、必要な情報から作り上げていくことが求められます。 2. 暗黙知 — AI への適切なコンテキスト提供 二つ目は 「暗黙知」 です。 こちらは、チームみらいの安野さんとテクバンの豊田さん・長島さんによるセッション 「AIがQAエンジニアの仕事を奪うのか？」 から得た学びです 現在、AI をできる限り活用し、精度を上げて素早く価値を出すことが大きなトピックになっています。この流れは今後も変わらないでしょう。 しかし、AI に意図通りの価値を出させるには、 適切なコンテキストを渡すこと が不可欠です。そのコンテキストは私たち人間から情報として伝達されます。つまり、どのような情報をどう入力するかが、AI を最大限に活用するための鍵になります。 ここで重要になるのが、 暗黙知の言語化、つまり「暗黙知を形式知に変えること 」です。人間が持つ暗黙知をできる限り言語化し、AI が学習・認識できる状態にする必要があります。 会話やメール、Slackなどのやり取りをログとして集めることも、コンテキストを得るうえで有効だと話されていました。 また、先ほどのfreee様の発表でも相手の真の要求を知るためにヒアリングするなどの「要求獲得」といった話題とも繋がると感じました。 3. 越境 — エンジニアリングと QA の役割の進化 三つ目は 「越境」 です。 チームみらいの安野さんから「QA もエンジニアも、今後同じ作業をし続けるわけではなく、その 業務内容自体が変わっていく」 という話がありました。エンジニアという職業はなくならないものの、担う内容は大きく変化していきます。 「ものを作り上げる」という過程そのものは変わりません。しかし、 どうやって作るのか、なぜ作るのか、作った後にどう運用するのか といった、従来のエンジニアリングよりも幅広い領域に踏み込むことが求められるようになります。 QA においても同様です。プロダクトの品質保証にとどまらず、 プロダクトを通じて自社にどのようなリスクが潜んでいるかを提示する ことが必要になります。 例えば、QA がPdMだけでなく事業部や経営層ともつながり、プロジェクトの意思決定に必要な情報を提示する役割を担うとことも、今後は視野に入れていくことが重要です。 品質保証の 範囲・方法・効果の説明責任 などが、今後のエンジニアの責務の一つとして求められていくと感じました。 まとめ JaSST Tokyo'26 を通じて、以上の 3つのキーワード を持ち帰ることができました。 これらはいずれも、 AI 時代により一層求められる力 だと感じました。今回の学びを今後の業務に活かしていきたいと思います。 おわりに 弊社ではQA、SETの採用も積極的に行っております。 hrmos.co タイミーのQA、ソフトウェアテストについてもっと知りたいという方はぜひカジュアル面談でお話ししましょう。 product-recruit.timee.co.jp

こんにちは、LIFULL QAエンジニアの木住野（きしの）です。 普段はQAエンジニアやUXリサーチャーチームのマネジメントを行っています。 2026年3月20日に開催された JaSST'26 Tokyo へ、QAエンジニア3名（星野、鐘、木住野）が参加しました。 本記事では、印象的だったセッションの紹介と、そこから得た学びを自社QAにどう活かすかについて考察します。 今回はビッグサイト開催 参加の目的 今回の参加目的は、生成AIが急速に普及する中でのテスト技術動向の把握と、自社QAプロセスへの還元です。 特に2026年は、AI駆動開発（AIDD）やLLMを活用した開発が本格化しており、QAエンジニアの役割や品質保証の在り方が大きく変わりつつあります。 この変化の波の中で、私たちが何を観測し、どう行動すべきかを学ぶことが今回の最大の狙いでした。 参加の目的 各メンバーが選んだ注目セッション 鐘：AIDD・SDD時代のQA対応 ―QAは何を品質として観測するのか― セッション概要 QAEとしての気付き 実務への適用案 星野：AIと品質保証のこれまでとこれから セッション概要 QAEとしての気付き 実務への適用案 木住野：Beyond Quality Assurance -AIと拓くQAの未来像- セッション概要 QAEとしての気付き 実務への適用案 セッションから見えたチーム内での振り返り 自社とのギャップ：現在の体制と比較した不足点や強み 今後の注力領域 まとめ 各メンバーが選んだ注目セッション 今回のJaSSTでは、AI時代のQAをテーマにした学びあるセッションが盛りだくさんでした！ その中から、各メンバーが特に印象的だった1つをチョイスして紹介します。 鐘：AIDD・SDD時代のQA対応 ―QAは何を品質として観測するのか― セッション概要 登壇者：小川 椋徹氏（2WINS）、久保 雅之氏（ポールトゥウィン）、後藤 香織氏（ポールトゥウィン） AIが実装だけでなく設計やテストまで担う時代に、QAエンジニアは何を観測すべきか。このセッションでは、4つの議題を通じてAI時代の品質保証について議論されました。 1. 品質が保証されていることの意味 AIは次に来る単語を予測する性質上、必ず一定の割合で不具合を含むコードを生成します。AIがコードを書き、AIがテストしても、それだけで品質を担保することは困難です。95%の正解率を99%に引き上げるという考え方が重要で、そのためには上流工程の段階からしっかり設計しておく必要があります。 2. AIツールのできること、できないこと AIが日進月歩で進化する中でも、変わらず重要なのはドメイン知識やノウハウをちゃんと残すことです。 AIのできること：コード生成、コード解析など AIのできないこと：非機能要件、設計レベルのセキュリティ欠陥、環境依存の問題、ビジネスロジック 3. 品質のエビデンスの再定義 AIで開発スピードが飛躍的に上がっている今、「なぜこのような実装をしたのか」を追跡できるようにすることが重要です。 大規模・長期間プロジェクトでは仕様書が古くなり、小規模・短期間プロジェクトではエビデンスをスキップしがちです。AI開発が早すぎて仕様書が追いつかない問題を解消するには、 自動でエビデンスを残すしくみ が必要です。 4. QAエンジニアの役割の変化 下流はAIが得意ですが、上流はよく間違えます。QAエンジニアはAIツールを駆使して、コードから逆算した仕様の把握や、仕様書の作成・更新を自動化し、AIが苦手とする上流工程をもっと考える役割が求められます。 QAEとしての気付き AIはビジネスロジックやユーザーの利用シーンを考えにくいため、開発のベースである上流の設計をQAがレビューすることで、根本から欠陥を防ぐことが重要だと感じました。 実務への適用案 小規模開発・個人開発でエビデンススキップによる属人化が起きていますが、 「属AI化」 も起きているのではないでしょうか。AIに要件を伝えた後、AIが実装し、AIがテストし、開発者は何を実装したか詳細まで把握していない状態です。 対策として、開発後に必ずAIでドキュメント化させ、依頼した要件と照らし合わせて確認・更新することが必要だと考えています。 星野：AIと品質保証のこれまでとこれから セッション概要 登壇者：須原 秀敏氏（ベリサーブ）、松木 晋祐氏（ベリサーブ）、山﨑 崇氏（ベリサーブ） 台本なしのスペシャルトークセッションとして、AI品質保証の技術的変遷と今後の展望が語られました。 従来の検証技術の限界 LLMのプロダクトにそのまま適用するのはとても難しいと語られていました。 メタモルフィックテスティング ：入力内容を変異させても出力に同じ関係性が維持されているかを検証する手法ですが、出力が多様化しているLLMではルールベースなどのシンプルな評価は難しい。 ニューロンカバレッジ ：内部構造の網羅性に着目しテストデータが内部ロジック（ニューロン）を網羅した（発火させた）か評価する手法ですが、これもLLMに対しては巨大すぎるために適用させるのは難しい。 テストの在り方は変わるのか 実はあまり変わらないのかもしれません。日本の製造業で培われたのは 統計的 品質管理です。 かつてバラツキを制御して抜取検査で品質を評価してきたように、LLMを搭載したプロダクトには決定論的な正誤ではなく、確率的な精度で評価をする必要性があるだけです。 先進的な技術のキャッチアップだけでなく、古典として評価されているような技術書に立ち返り基礎となる考え方と技術を学習する必要性を再認識しました。 サービスの自由度を狭める必要性 サービスの使われ方が多様化しないよう、自由度を狭める必要があります。たとえばIRページにチャットbotを設置する場合、ハルシネーションは法的なリスクがあります。サービスが想定外の利用方法をされないように縛りが必要です。 フライホイール型のQAと継続的な監視 LLMを搭載したプロダクトの場合、リリース後にも精度が下がっていないことを継続的に監視する必要があります。テスト環境よりもコンテキストが明らかに広くなり、外部環境の変化によって使われ方や求められる出力も変化します。だして終わりではなく、フィードバックループを構築する技術が必要です。 QAEとしての気付き 仕様の引き算・制限することの重要性を能動的に広め、リスクヘッジが必要 LLMの精度を保ち続けるための監視（メトリクスの設計） 自身が社内に提供するツールや開発プロセスにLLMを活用する場合もこれらを意識しなければ、生産性や成果物の質に影響が出そう 基礎となる考え方は変わらない。品質保証の古典やソフトウェア工学についてあらためて知識と技術を深めることが重要 実務への適用案 「AIに何をさせないか」の意識を持つことが大切です。社内に配布するツールも同様で、意図しない用途での利用により問題のあるハルシネーションを起こす可能性があります。 木住野：Beyond Quality Assurance -AIと拓くQAの未来像- セッション概要 登壇者：池之上 あかり氏（LINEヤフー）、平田 香織氏（LINEヤフーコミュニケーションズ） AI導入におけるQA組織の現状と課題について、コーチングの技術を用いた組織変革の事例が紹介されました。 対策のアプローチ チームのAIに対する価値観（不安や恐ろしさ）を変える 新しい価値観をチームにインストール 余力による改善活動が増えたなどの効果が見え始めた QAEとしての気付き 私自身はAIを活用することを推進することに躊躇はなく、拡張するツールである認識でしたが、一方でこの発表のようにAIに脅威や不安を感じている人もいるということがわかりました。 組織横断的な改善も多いので、こういった考え方を知れたことが大きかったです。価値観・信念の摩擦といった言語化しづらい障壁についても知れたのが良かったです。 実務への適用案 AIに限らず新しい技術・思想、あらゆる事象は人によって受け入れること自体に障壁がある可能性もあるため、それを考慮してQAチーム、ひいてはLIFULLの開発組織によい変化を作っていきたいと考えています。 セッションから見えたチーム内での振り返り 自社とのギャップ：現在の体制と比較した不足点や強み 不足点・課題 以下の点については改善の余地があると感じました： エビデンス管理の自動化 ：AI開発のスピードに仕様書が追いつかない問題に対して、自動でエビデンスを残すしくみが不足しています。 上流工程へのシフト ：QAエンジニアがより上流工程に関与し、設計レビューを強化する体制が必要です。 組織的な心理的障壁への配慮 ：AIに対する不安や恐れを持つメンバーへの配慮と、組織全体での価値観の共有が必要です。 リリース後の継続的監視 ：LLMを活用したプロダクトにおいて、リリース後の精度監視とフィードバックループの構築が課題です。 今後の注力領域 各メンバーが挙げた「明日から変えたいこと」 AI開発後のドキュメント （鐘）：AIで開発した後、必ずドキュメント化し、要件と照らし合わせて確認する習慣をつける AIに何をさせないかの意識 （星野）：社内ツールでも、意図しない用途で利用されることを防ぐ設計を意識する 新技術受け入れの障壁への配慮 （木住野）：新しい技術や思想を導入する際、人によって受け入れに障壁があることを考慮する まとめ JaSST '26 Tokyoを通じて、AI時代におけるQAエンジニアの役割が大きく変わりつつあることを実感しました。しかし同時に、テストの本質は変わらず、品質保証の基本的な考え方が今後も重要であることを確認できました。 本記事で紹介したセッションをベースにすると以下のような視点で学びがありました。 鐘 : 技術的視点 から、上流工程の重要性とエビデンス管理の課題を指摘 星野 : 検証技術の変遷と本質 から、テストの統計的性質とフィードバックループの必要性を強調 木住野 : 組織・人的視点 から、AIに対する心理的障壁とコーチング手法の重要性を学んだ 私たちが得た最大の気付きは、「AIの進化に合わせてQAも進化しなければならない」という危機感と、「基本を押さえていれば対応できる」という自信の両立でした。 JaSSTで得た外部知見を、自社の品質向上につなげていきます。 最後に、LIFULL では一緒に働く仲間を募集しています。 よろしければこちらのページもご覧ください！ hrmos.co hrmos.co

はじめに こんにちは、チューリングのVLAチームでインターンをしています、法政大学 M1 の永井です。 本記事では、自動運転のVLA (Vision-Language-Action; 視覚-言語-アクション)モデルを学習するための RACER: Rationale-Aware Captioning of Edge-Case Driving Scenarios (エッジケース運転シナリオに対する根拠付きキャプション生成) データセットの概要と構築方法について紹介します。 (日本語訳）自車は、現在の車線を制御している赤信号に従う必要があるため停止を決定した。前方の白い車両が完全に停止