テスト分析フェーズにおける個人的な生成AIとの向き合い方

こちらは anyプロダクトチーム Advent Calendar 2025 19日目の記事になります。

みなさんはじめまして、anyでフレンズとして働かせていただいております、QAエンジニアのさとうと申します。普段はよちよち歩きの子犬がすてんと転ぶショート動画を眺めては癒やされるためだけにパケットを消費しているので、QAエンジニアとして記事を投稿すること自体が初チャレンジとなります。何卒温かい目で見ていただけると幸いです。

any では業務委託で働いている方のことを anyフレンズ と呼んでいます🙋‍♂️

🎄 はじめに…

先日開催された「ソフトウェアテスト自動化カンファレンス2025」に私も参加させていただきました。発表者の皆さまにおかれましては様々な先進的なチャレンジや試行錯誤を重ねながら、AI時代のソフトウェアテスト、そして自動化に立ち向かっておられたことに非常に感銘と刺激を受けることができました。

打って変わって本記事ではそんな先進的なソフトウェアテストとはかけ離れた、泥臭く、土臭く、また汗臭い1人のテスト担当者の奮闘記として読み進めていただけると幸いです。

🧩 前提

弊社では「Qast」というサービスを運営・提供しております。個々人が持つ知識や経験を暗黙知として抱え込まず、組織全体で共有・活用し、新たな知識創造や生産性の向上を支えるナレッジマネジメントサービスです。Qastが提供するサービスの1つとして「こましりチャット」という機能があります。「こましりチャット」では、業務でのお困りごとを気軽にご質問いただき、日々Qastに投稿いただいたナレッジをもとに回答を得ることができるRAGシステムとなっております。今回はこちらの「こましりチャット」での検索範囲を弊社に投稿いただいたナレッジだけでなく、外部のデータソースを取り込んで回答を得られるようにする新規機能の開発にあたり、私なりにどのようにテスト分析を行ったかを書いていきます。

🚪 前段

EMのyueさんから1on1で本機能のご相談を受けたときに「はい、OKです〜」と二つ返事でお受けしたものの、私は対向システム側の仕様や振る舞いに対してゼロと言っても過言ではないほどに前提理解が乏しく、テスト対象を見極めるためのインプットを探しにいくことからスタートすることになります。

社内で整理いただいたナレッジを眺めたり、対向システム側も実際に触ることのできる環境があったため、まずはこのシステムは何ができるのか、何が制約条件として存在し、またリスクとなり得そうかについてのコアな部分を自ら押さえにいくことから始めました。（まだあまり生成AIは出てきません）

幸いにもQastの理解は普段から全社的に利活用していることもあり、また比較的デザインもシステム上の振る舞いもシンプルなものであったため、要求に関してはスッと理解することができました。自社サービス側のファイル同期の仕組みは私には難解な部分もあったのですが、自分の認識をビジュアルで表現しながらPdMや開発メンバーと何度か対話を重ねることで協力して理解を深めることができました。

ところが一転、対向システム側のドキュメントの広大さと、重要な情報が分散している現実に直面し、想像以上に調査が必要になることを思い知らされました。普段私はChatGPTを使用しているのですが、こうしてChatGPTとの密な2ヶ月の幕開けとなったのでした。

テスト分析には様々なアクティビティを含むかと思いますが、今回のテスト分析で最もお世話になったChatGPTの役割は以下の3点です。後続の文章ではこちらの3点について補足していきます。

• テストベースの理解のお供として
• テスト条件抽出と整理の壁打ち相手として
• リリーススコープと制約整理の裏取り相棒として

🧠 テストベースの理解のお供として

対向システム側のGUI上の振る舞いを確認しながら、まずはテストケース全体としてどのようなまとまりで表現すればよさそうかを頭にイメージしながら進めました。ここでのイメージが後続のテスト分析作業での指針となり、私が思い描いたイメージは以下の3つです。実は執筆時点でもテストは継続中なのですが、幸いにして構造を大きく変える必要があるケースは発生していません。（いまのところは）

• 権限に対するテスト
• ドキュメントの構造に対するテスト
• リソースの属性/属性値に対するテスト

これらの3つを軸としてChatGPTと対話を繰り返すことで内部構造に迫っていきました。

• 権限モデルは何を採用しているのか
• どのような権限がシステム上に存在するのか、画面上から確認できるのか、APIやCLIを通じてのみでしかその権限の存在を認知することができないのか
• ドキュメント構造はどのようになっているのか
• 画面上は階層関係で一見表現されているが、内部構造としてもその認識で進めて問題ないのか
• 〇〇が持つ属性や属性値をリストアップのうえ、それぞれに説明を補足してほしい
• … etc

これら以外にも、対向システムの根底にあるデータ基盤やインフラストラクチャーに対して理解を進めるに当たってもかなり密にラリーを繰り返しました。また、今回連携元となるサービスは、対向システムが持つ他のアプリケーションのデータストレージとして位置づけられていたこともあり、関連する周辺のアプリケーションを理解するための補助線としても活用しました。

🤝 テスト条件抽出と整理の壁打ち相手として

ある程度理解が進んだものから具体的なテスト条件をハイレベルテストケースに落とし込んでいきました。テスト設計フェーズでの内容も一部ここに組み込まれています。この段階でのやり取りが最もChatGPTとのラリーが多かったかもしれません。私のプロンプトエンジニアリングの力量不足も多分にありつつですが、どのレイヤー・どのスコープかをきちんと明示したうえでも時折自信満々に違う情報を返してくることがあります。そのため「公式リファレンスを参照して」を必ずプロンプトに渡したうえで、画面を確認する、APIを実際に叩いてレスポンスを確認する、公式リファレンスからの裏を取るといった手動での確認作業も膨れ上がりました。

最終的に、「パターンとして表現したものの前提条件として成立しうるのか…？」「この条件を満たすためには別のデータ基盤上のアイテムが必要になるが、どういったステップを踏めば条件に合致した状態を作ることができるのか…？」といった粗さも抱えたままではあったため、テスト実施者との対話や属人化は許容しつつも不確実性を含むテストケースは自分が担当する判断もこの段階で同時並行して考慮しました。

反面、マルチモーダル機能が強力であったため、粗めにビジュアルで表現したテスト設計書でもスクリーンショットベースでレビューを依頼、対話しながら洗練していくことができました。ほんの一部分ではありますが、実際にChatGPTに渡したスクショはこちらになります。

この粒度の粗さでもしっかりとレビューをしてくれるので、自分としても改善ができている実感を得ながら進めることができました。（「デザインがイケてないね」というフィードバックはそっと胸の奥にしまっておきました）

📖 リリーススコープと制約整理の裏取り相棒として

上述の調査の中で、対向システム上で「上位プランの購入」や「特別なライセンス」などが必要となる機能も多く存在することを知り、社内でリリーススコープの調整ができるよう早期に対象機能をリストアップする作業も進めていました。また、テストの制約上の都合により今回は対象外としたい機能についてもサポート・運用マニュアルや、お客さま向けの資料で補足できるように、発見したものから随時チームメンバーに共有できる状態にしておく必要がありました。「どこかで〇〇機能はXX条件では使用できないってみた気がするな…」「でも明確にそうだったかを言い切るためには公式リファレンスで参照した部分も含めて共有したいな…」といったケースで、ChatGPTに該当箇所を探してもらい情報を補っていました。ただ、こちらも最終的には手作業でカバーする部分も多くあり、特に難しいなと印象に残った点は以下の2つです。

• ChatGPTから返却された回答は公式リファレンス全体としての一部分に過ぎず、改めて公式リファレンス全体を目検すると回答では得られなかった文脈が存在すること
  • たとえば、「〇〇機能はXX条件の場合でも利用できます」と回答があった場合に、「実際にはYY条件も存在することになるので利用できないですよね？」 → 「いいところに気づいたね！そのとおり！」→ 🙄
• 「非推奨」であるか「廃止予定」があるか、また対向システム側が「暗に推奨」しているパターンはなにかを掴む必要があったこと
  • 今後を見据えて、お客さまには対向システム側でもなるべく推奨されるパターンもご認識のうえで連携を進めていただきたい側面もあり、ChatGPTが示したパターンが「非推奨」であるか「廃止予定」であるのかを追加で調査してもらい、改めて公式リファレンスで裏をとる必要がありました。
  • 「暗に推奨」しているパターンは、何日間も公式リファレンスやシステムとにらめっこをしていると「このパターンに関しては言及が薄いな…」「APIからはレスポンス上返却されるけど、画面上にはアイテムが表示されないな…」「画面導線もない、でもURL直打ちではアクセスできるぞ…」といったこともあり、自分の仮説としてこのパターンは非推奨なのではないか、公式からの見識が得られるかなどChatGPTと対話を繰り返しながら公式リファレンス以外のWebページも合わせて確認をする必要がありました。

📊 テスト分析活動のアウトプットとして

これまでのテスト分析活動のアウトプットには色々なアイテムが存在するのですが、PdMやエンジニアメンバーも含めたテストレビューを実施した時点でご覧いただいたアウトプットはこちらになります。

適度にラフに描くことができ、最低限のトレーサビリティが確保でき、チーム内コミュニケーションによる柔軟な変更も可能なため、私は全体像をMiroで表現する場合が多いです。1つ1つの付箋にテスト設計資料へのリンクを貼っており、テストケースの優先度調整や依存関係の整理については一旦ホワイトボードツールでラフに表現するようにしています。

🌱 最後に…

いかがでしたでしょうか。泥臭かったでしょうか。土臭かったでしょうか。汗臭かったでしょうか。

社内の仕様ドキュメントやデザインシステムであれば、AIやMCPフレンドリーな構成を将来的に採っていくという構想もできるかと思いますが、対向システムが存在する場合は共有・公開されているドキュメントの信頼性、文脈や用語を質問者が理解している前提で成立する部分もあり、なかなかコントロールが難しい部分もあるのかなあとも思っています。

テスト分析に限らず、担当者として内部構造に基づいたテスト用のモデルを準備し、テストの関心事の単位でAIに問い合わせるといったある種のクリエイティブな部分はまだまだQAエンジニアとして介在する余地は多分にありそうだなあと改めて思いました。

今回の連携を通じて、自分たちのプロダクトもAIフレンドリーであることが品質の大切な観点としてあらためて意識するようになりました。

最後の最後に少し余談です。定期的にChatGPTに会話分析をお願いしているのですが、今回の要件の過程で「嘘つきじゃん！」と1度だけ伝えたことを今でも大切に覚えていてくれるようで、ずっとフィードバック内容に書かれ続けています。ごめんね。

---

any 株式会社では ナレッジ経営クラウド Qast のエンジニアを絶賛募集中です。

是非 採用ページ をご覧ください！