はじめに
はじめまして、株式会社グロービスの池邊と申します。QAエンジニアとして6年ほど、グロービスのGLOBIS学び放題やグロービス経営大学院 ナノ単科といったプロダクトのQAを担当しています。
「AIがテスト設計を変えるかもしれない」
そんな期待と不安が入り混じった中で、私は一つの実験を始めました。AIコーディングアシスタントの「Cursor」と、私たちの仕様書が眠る「Notion」をMCPで連携させ、テストプロセス全体を効率化できるかどうかを試してみました。
グロービスのQAチームは、開発プロセスに深く関わっており、各プロダクトチームと連携しながら品質向上に取り組んでいます。日々の業務の中で、私はテスト設計における「属人化」や「考慮漏れへの不安」、そして「ドキュメントと実装の間の断絶」といった課題に、より効果的なアプローチがないかと模索していました。
本記事では、その具体的なプロセスと、そこから得られたリアルな学び・反省点を共有します。ただし、これはあくまで一つの実験であり、すべてのチームやプロジェクトに適用できるわけではありません。 読者の皆さんの環境や状況に応じて、参考にしていただければと思います。
今回のゴールと実験の全体像
今回の実験のゴールは、「AIとの協業によって、テスト設計プロセスをどう変革できるか、その可能性と課題を探る」ことです。実際のQAプロセスに沿って、各ステップでAIに"伴走"してもらいました。
実験の流れ
- テスト対象分析 - AIに仕様を理解させる
- テスト要求分析 - AIに質問させて思考を深める
- テスト設計 - 人間による意思決定
- テスト観点出し - 網羅的な観点の整理
- テストケース実装 - 最終成果物の作成
AIと"伴走"した具体的なプロセス
ここからは、皆さんがすぐに試せるよう、具体的な手順やプロンプトを交えながら解説します。
準備：CursorとNotionを連携させる
まず、CursorからNotion上の仕様書を読み込めるように設定します。設定は非常に簡単で、下記の公式ドキュメントを参考に、数クリックで完了します。
📚 参考リンク Notion MCP の連携設定ガイド
Step 1: テスト対象分析 - コンテキストの注入
目的: AIにテスト対象の仕様を深く理解させ、以降の対話の精度を高める「専門家」に育てること。
思考プロセス:
いきなり「テストケース作って」と指示しても、質の低いアウトプットしか返ってきません。人間と同じで、まずは前提となる情報をインプットし、プロジェクトの共通認識を築くことが重要です。
プロンプト:
Notionにある仕様書ページを@で指定し、AIに役割（ペルソナ）を与えます。
あなたは、スクラム開発からビジネス価値の検証まで精通したQAエンジニアです。
@<https://www.notion.so/globisorg/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Notionの上記テストスイートをよく読み込み、まずはテスト対象分析を行なって下さい。
AIの回答（抜粋）:
プラン情報のテストスイートを詳しく分析しました。以下がテスト対象分析の結果です：
テスト対象分析：プラン情報機能
機能概要
プラン情報機能は、ユーザーが契約しているプラン一覧を表示し、プラン管理を行う機能です。
主要機能
- プラン一覧表示
- プラン切り替え
- 再購入・利用再開
...
このように、AIが自ら構造化して要約を返すことで、正しく仕様を理解できたかを確認できます。
Step 2: テスト要求分析 - AIに質問させて思考を深める
目的: AIとの壁打ちを通じて、テスト計画に必要な要求（ビジネス価値、品質要求、制約）を明確にすること。
思考プロセス:
「計画書を作って」と指示するのではなく、「計画を作るために、私に質問して」と依頼するのがコツです。これにより、AIが持つ網羅的な知識ベースから、自分一人では気づきにくい論点を引き出すことができます。
プロンプト:
では次に、テスト要求分析に進んでください。不足情報があれば質問して下さい。
AIの回答（抜粋）:
テスト要求分析に進みます。いくつか確認したい点があります：
1. 品質要求の詳細
- プラン情報機能において、特に重視すべき品質特性は何でしょうか？（機能性、使いやすさ、パフォーマンス等）
2. ビジネス要件
- この機能の主要なビジネス価値は何でしょうか？
- 失敗した場合のビジネスインパクトは？
3. 制約条件
- テスト期間の制約はありますか？
これらの質問に答えるだけで、自然とテスト計画の骨子が固まっていきます。
Step 3 & 4: テスト設計と観点出し - 人間による意思決定
目的: 明確になった要求と制約に基づき、具体的なテスト方針と網羅的な観点を導き出すこと。
思考プロセス:
Step 2で回答した内容（例：テスト期間は3日、高リスクなのは既存機能への影響）をインプットとして与え、AIに具体的な設計案を考えさせます。AIが提案した選択肢に対し、最終的な意思決定は人間が行います。
プロンプト:
（Step2の質問への回答を踏まえ）
テスト設計のための確認事項に回答します。
...
3. 制約条件
- テスト期間の制約はありますか？：実施は３日程度
...
5. テスト実行の優先順位
- 高リスクは表示制御です。既存の信頼性 > 新規購入への導線
...
では、ここまでの設計をもとにテスト観点出しに進んでください。
AIの回答（抜粋）:
...提供いただいた詳細情報を基に、テスト設計書を作成します。
テスト実行順序の戦略
- Day 1: 回帰テスト優先 - 既存機能の信頼性を最優先で確認
- Day 2: 統合テスト - 新機能の動作確認
- Day 3: システムテスト - エンドツーエンド検証と探索的テスト
リスクベースドアプローチ
- 高リスク: 表示制御の不具合 → Day 1で重点検証
...
AIの強みである網羅的な観点出しと、人間の強みであるビジネス文脈を踏まえたリスク判断を組み合わせることで、質の高いテスト設計が短時間で可能になる可能性があります。
Step 5: テストケース実装 - 全ての対話を成果物に
目的: これまでの対話のすべてを集約し、最終的な成果物であるテストケース一覧を作成すること。
思考プロセス:
ここまでのステップは、すべてこの最終アウトプットのための「コンテキスト作り」です。十分なコンテキストがAIの中にあるため、最後の指示は非常にシンプルです。
プロンプト:
はい、テストケース実装に進んでください。テストケースはCSVでアウトプットして下さい。ヘッダーは下記です。
ID, 大項目, 中項目, 小項目, 画面, 条件, 手順, 確認内容, 期待値, 備考, RSpec実装レイヤー
この指示により、これまでの分析、要求、設計、観点をすべて反映したテストケースが生成されます。今回の実験では、約2時間の対話を経て、77件のテストケースが出力されました。
実験から得られた学びと反省点 ✨
今回の実験を通じて、AI活用のリアルな手応えと、今後の課題が見えてきました。
学び①：思考の壁打ち相手としての価値
まず、各ステップの開始時にAIに「質問させる」アプローチは、私の経験では非常に有効でした。AIからの問いに答えることで自身の思考が整理され、考慮漏れを減らせる可能性を感じます。
これは、Googleが提唱するような「AIにペルソナを与え、対話的にタスクを具体化させていく」というプロンプトエンジニアリングの原則にも通じるものがあります。
面倒なドキュメント化や項目出しをAIに任せ、人間はより本質的な思考に集中できる時間は、たしかに増えたように思います。
学び②：プロセスの可視化と共同編集のしやすさ
一連の対話ログは、そのままテスト設計の思考プロセスを記録したドキュメントになります。これにより、設計プロセスが可視化・標準化され、「あの人でなければ分からない」といった属人化を防ぐ効果も期待できます。
また、CursorはGitと連携できるため、この対話ログ自体をGitHubで管理し、チームで非同期にレビューや共同編集を行える点も、私にとっては大きなメリットでした。
作業単位で切り出して、途中で中断・再開したり、他のメンバーに引き継いだりすることが容易になります。
学び③：プロセスの応用性と拡張性
今回試した「分析→要求→設計…」という作業の流れは、様々な規模のプロジェクトに応用できると感じています。
例えば、より大規模なプロジェクトであれば、最初にプロジェクト全体のテスト対象分析・要求分析をAIと行い、そのアウトプットをベースに、各機能群の詳細な分析〜実装をそれぞれ別の担当者がAIと進める、といった階層的なアプローチが取れる可能性があります。
全体の分析内容を各機能で使いまわせるため、一貫性を保ちながら効率的に分業できる可能性があります。
反省点と次の課題
一方で、今回の実験結果を手放しで「成功」とするには、いくつかの課題も見えました。
アウトプットの過剰さ
正直なところ、77件というテストケース数は、今回の機能規模とリスクからするとやや過剰でした。これは、各アウトプットの時点で人間がレビューし、優先度付けや取捨選択を行わないと、AIは網羅性を重視するあまり最後のアウトプットが膨大になる、という特性を示しています。
効率の評価
また、「2時間で77件」という数字も、圧倒的な成果とは言えません。経験豊富なテストエンジニアであれば、この規模の機能なら1時間程度で実装することも可能でしょう。
ただし、これは私の経験に基づく主観的な評価であり、他の方にとっては異なる価値があるかもしれません。
レビュープロセスのジレンマ
上記の「レビューの重要性」とも関連しますが、このプロセスをチームで実践しようとすると、新たな課題が浮かび上がります。
複数人で分担・レビューしながら進めると、レビューの待ち時間がボトルネックになる可能性があります。かといって、一人で全工程を行うと、膨大な情報量を扱うことによる認知的な負荷や、判断の偏りが懸念されます。
このジレンマをどう解決するかは、今後の大きな検討課題です。
まとめ：AIは、使い方次第で最高の「思考のパートナー」になり得るか？
今回の実験を通して、「AIは思考のパートナーか？」という問いに対する私の現在地は、「可能性は大きいが、乗りこなすには技術と経験が必要な、興味深いパートナー候補」といったところです。
AIはテスト担当者を代替する銀の弾丸ではありません。しかし、対話を通じて私たちの思考を深め、面倒な作業から解放してくれる、まさに「伴走者」としてのポテンシャルを秘めていると感じます。
重要なのは、私たちが運転席に座り続け、AIという優秀なナビゲーターをどう使いこなすかを考え続けることです。
この記事が、皆さんの現場でもAIとの新しい協業スタイルを試す、何かのきっかけになれば幸いです。
宣伝
グロービスでは、エンジニア・QAを積極採用中です！個人的には、これまで転職で経験した会社の中で一番「ちゃんと課題解決の話ができる組織」「評価基準が明確な組織」だなと感じています。手前味噌ですが。
ご興味ある方は下記からご連絡お待ちしています！
Discussion