LLMでもいつものテスト技術〜意外と半分はこれまでのテストでした〜

JaSST'26 Tokyo ソフトウェアテストシンポジウム 2026 東京
https://jasst.jp/tokyo/26-about/

【テクノロジーセッション】LLMでもいつものテスト技術〜意外と半分はこれまでのテストでした〜
水谷太一（サイボウズ）

Transcript

1. LLMでも いつものテスト技術 〜意外と半分はこれまでのテストでした〜 JaSST'26 Tokyo 水谷太一 @dog_dog_3dog 1
2. 水谷太一（くつしたいぬ@dog_dog_3dog） サイボウズ株式会社 QAエンジニア 4月から3年目！ 犬が好きです 担当プロダクト サイボウズ Office AI機能 今日話すこと 既存グループウェアにAI機能を追加した際のテストの進め方と気づき LLMアプリのテストでも、これまでのテスト技術が変わらず重要 自己紹介と今日話すこと イントロ 2
3. 「LLMアプリのテスト、何から始めればいい？」ってなりがちだし、自分達もそうだった これまでやってきたQAの基本的な進め方がそのまま力になった 品質特性の理解→リスク分析→テスト計画 と進めれば、不確実性を着実に減らしていけるし、最後は具体的なタスクまで分解できる LLMアプリのテストはわからないことが多いし、ベストプラクティスも定まり切っていない →だからこそ、これまで通りのセオリーに則った進め方で着実に進めていける どうやるかわからないものだからこそ、基本的な部分をしっかりやっていくのが重要 ここから先は、この進め方でリリースまでできた実例を紹介します テストの土台は、LLMアプリでも変わらない イントロ 3
4. • サイボウズ Office • 中小企業向けグループウェア • 追加したAI機能（3つ） • ヘルプAI • 製品の使い方をチャットで質問 • 要約AI • 掲示板やメールの内容を要約 • 校正AI • 文章の誤りをチェック・修正 LLMの基盤はAzure を利用 対象プロダクトとAI機能の概要 イントロ 4
5. 4月末にプロトタイプ → 10月頭にリリース（約5ヶ月） スクラムを採用していて、SWE2人、QA2人、デザイナー1人 チームにLLMアプリのテストの経験者なし 何から手をつければいいかわからない！ やったこと 期間が限られていたため、トップダウンで必要なテストを割り出す方針に → 品質特性の整理とリスク分析を経て、テストスイートを作成 開発当初の混乱 イントロ 5
6. テストスイートを作るまで 6
7. いくつかのガイドラインを読んで、LLMアプリに求められる品質特性を学習し、QAチーム内で共有 一番参考になったのは『生成AI品質マネジメントガイドライン』 • 品質特性がバランスよく体系的にまとまっている • トップダウンでテストの方針を考えるのに向いていた ▲ 生成AI品質マネジメントガイドライン: https://www.digiarc.aist.go.jp/publication/aiqm/ LLMの品質特性やLLMアプリの全体的な品質保証についてやった社内勉強会の資料を公開しているのでぜひ！ Link https://blog.cybozu.io/entry/2026/02/27/113000_1 まずは品質特性を理解する テストスイート作成 7
8. 以下の2つの作業をヘルプチャット機能で実施/テストの大枠が整理できたタイミングでステークホルダー間で合意 1. QA内でブレストしてリスクの洗い出し・優先度付け • 品質特性を補助線にリスクを洗い出し • 重大度（壊滅的・重大など）でマッピング 2. リスクがないことを確認するためにテスト目的を整理 機能がoffの設定をしているのに機能が利用できるリスク →機能がoffの時に機能が利用できないことを確認するテストが必要 3. テストの優先度を策定 • Must：これがないと機能が使えない / お客様に重大な影響がある • Nice to have：あると良い / 後から直せる • リリース時にテスト不要：将来的で良い / そもそもQA試験は不要なものもここに分類 リスクの洗い出しとテストの優先度付け テストスイート作成 8
9. • ▲ ヘルプチャット機能でのリスク分析の一部 リスク分析の結果（例） テストスイート作成 9
10. • ▲ Must / Nice to have / リリース時に担保不要 の3段階に分類 リスク不在を確かめるテスト観点の整理 テストスイート作成 10
11. • ▲ Must / Nice to have / リリース時に担保不要 の3段階に分類 • プライバシー情報が含まれないシステム のためテストからは除外 • 公平性の部分はモデル側のガードレールで担保 リリース後に必要に応じて追加で調整 リスク不在を確かめるテスト観点の整理 テストスイート作成 11
12. 優先度に合わせて、テストスイートの箱を作成 • 中身のテストケースは後から作る • まずはテストが必要な範囲 おおよその工数を割り出し 他機能（要約・校正）はこれを横展開 • ヘルプチャットのテストスイートをベースに軽く調整 • 工数を削減しつつ、テストの大枠を作成 リスク分析からテストスイートの枠へ テストスイート作成 12
13. 「何をテストすればいいかわからない」状態から「何をテストするか」が明確な状態になった 見積もり（SP）を出すことで、テスト実施に必要なスケジュール感も把握 → 従来通りのリスク分析・テスト計画の基礎に則って進めることで、 不確実性を大きく減らすことができた 具体的なテスト技法やツールはリサーチが必要だが、 「何をテストするか？」はこれまで通りのやり方で分析できる リスク分析で不確実性を減らせた テストスイート作成 13
14. 実際にどうテストを進めたか ― 非LLM部分のテスト ― 14
15. LLMの部分はシンプルな機能構成 →テスト工数の大半は非LLMの決定論的な部分に充てていた 認証・権限（セッション切れでAI機能にアクセスできないか、等） 機能のOn/Off制御、アカウント処理 エラー処理・エラー復帰のUX UI・バリデーション（文字数制限、レスポンシブ、差分表示） クロスブラウザテスト Rate Limit（API呼び出し制限）の挙動 → これまで通りのテスト設計・テスト実施で対応した テスト全体のうち、大体はLLMに関係ない テスト（非LLM） 15
16. LLMアプリはエラーの種類が多い • LLM由来のエラー（応答不能・不適切な応答） • コンテンツフィルターによるエラー（入出力のブロック） • 決定論的なエラー（認証切れ・権限不足・入力超過 等） エラーの種類ごとに、どう切り分けてユーザーにどう見せるか → 設計のすり合わせに時間がかかった LLM自体のテストではないが、LLMアプリだからこそ考慮すべきエラーがあった エラー処理は難航した テスト（非LLM） 16
17. テスト対象の大半は、LLMに関係のない従来のテスト領域だった 認証・権限、UI、エラー処理… これらはLLMアプリ特有の難しさはあるものの、 テストの進め方自体はこれまでと同じ いつものテスト技術で外側の土台を固めたことで、 LLM固有のテストに集中できる状態が整った 非LLMテストのふりかえり テスト（非LLM） 17
18. 実際にどうテストを進めたか ― LLM部分のテスト ― 18
19. LLMの応答のテストは2つの方向性から確認 • 応答が機能要件を満たしているか：QAが担当 • セキュリティ：社内のPSIRTに依頼 応答のテストは以下のステップで進めた • 1. 観点の洗い出し • 2. テストデータの作成 • 3. QA内でレビュー • 4. チーム全体（QA以外も含む）で観点＋テストデータを確認 • 5. テスト実施 → 問題がなくなるまでプロンプト修正をQAで実施 LLM部分のテスト ― 何をやったか テスト（LLM） ※LLM品質は他にも多数。今回はリスクと体制から「応答品質/セキュリティ」にフォーカス 19
20. ※ ここからは、自分が担当した校正AIを例に紹介します • 「校正前後で内容が変わらないこと」 = AIが余計なことをしない • 数字・日付・人名・URLが書き換わらない • 内容が増えたり減ったりしない • 言葉の強さが変わらない（「お願いします」→「ご対応お願いします」等） • 注意書きや但し書きが消えない • 「校正ができること」 = AIがやるべきことをやる • 誤字・脱字・転置の検出（「対処療法」→「対療処法」等） • 漢字の変換ミス・同音異字の誤用（「以外／意外」等） • 助詞・活用・敬語の誤り • 句読点の過不足 • ▲ 観点はAIとの壁打ちで校正の誤り分類を洗い出しながら作成 応答品質のテスト観点 ―校正AI テスト（LLM） 20
21. テストデータに入れたい属性を整理 • テキストの長さ / 含まれる情報（人名・URL・日付等） / 文章の種類（掲示・メール・メッセージ） 例：「500字程度 / 社内メッセージ / 砕けた文体 / 人名・日付を含む」 テストデータの作り方 • 1. AIでサンプル文章を生成 • 2. そこにAIで間違いを挿入（誤字・脱字・変換ミス等） テスト実施 一定の水準をクリアするまでプロンプト修正 → 再テストを繰り返した テストデータの作成とテスト実施 テスト（LLM） 21
22. 事前にチームでレビューしたことで、抜けていた観点に気づけた • 校正：人名の表記揺れをテスト観点に追加 • 要約：要約結果の圧縮率をテスト観点に追加 今回は校正・要約という評価しやすい機能＋人手での評価というシンプルな方法だったが、 観点をきちんと設定してからテストに臨む効果は大きかった • 観点を作る過程で「こういうのも見たほうがいいかも」が見えてくる • 機能への理解も自然と深まる テスト設計の基本を丁寧にやることが、LLMのテスト設計でも効いてくる やってみて気づいたこと テスト（LLM） 22
23. まとめ 23
24. LLMアプリでも、テスト対象を分析しテスト観点を考える工程は依然重要 決定論的な、これまで通りのシステムテストでも、LLMに閉じた部分のテストでも 「何を」テストしたいのかをきちんと考えることが重要 「どうやって」テストするかは、その後の話として切り分けるアプローチは有効 LLMのテストは様々技術があり日進月歩でベストプラクティスも決まっていない →「どうやって」から考えると、リサーチばかりに引っ張られてうまくテストがまとまらない 頭の中が「どうやって？」でいっぱいだと、「何を見たいか」という目的が見えてこなくなる 「何をテストしたいか」が明確になり、手を動かしていける 既存のテスト技術の適用と重要性 まとめ 24
25. LLMアプリのテストをやるとしても焦る必要はない これまでやってきたことを愚直に進めれば、きちんと前進できる 「どうやって」テストするかにとらわれずに「何を」テストしたいのかにフォーカスを当てて考える 「何を」テストしたいのかを考えるためには、これまで通りのテスト対象の分析がすごく役にたつ まずは、いつものテスト技術から始めればなんとかなる！ とりあえず、いつものテストから まとめ 25 サイボウズではQAエンジニアを募集 しています！ キャリア採用サイト公開中です
26. ©️ Cybozu, Inc. 26