はじめに

こんにちは、ライブコミュニティ事業本部のYukaです。 現在、プロダクト開発のプロセス改善に、QA（Quality Assurance：品質保証）の視点から取り組み、その実現を目指しています。

この記事の対象読者

この記事はソフトウェア開発に関わる方を対象としています。

• 開発者、QAエンジニア
• プロダクトマネージャー、プロジェクトマネージャー
• プロダクト開発プロセスの改善に興味がある方

背景と課題

2017年のサービス開始以来、 Pococha は8年間で新機能を継続的にリリースしてきました。この長期間のサービス運営により、機能が複雑化し、開発・テスト・品質保証の各工程で求められる専門性も高まっています。

一方で、新しい機能をリリースする際のスピード感は維持しながら、機能開発を続ける必要があります。品質は一定に保ちたい。しかし、複雑化した機能を扱うには、より多くの知識と経験、そして時間が必要になってきました。

そこで、AIを活用することで効率化を図り、専門的な仕事のサポートを得られないかと考えました。

記事の内容

この日々のプロセスを改善するために、生成AIの基礎から学び始めました。

本記事では、生成AIの基礎学習から始まり、Cursorの活用設計について詳しくお話しします。具体的には、PRDは作成されている前提で、PRDのレビューからFSD（機能仕様書）の作成と改善、そしてテストケース作成までのプロセスを詳細に説明していきます。

ツールに依存しない基礎作り

生成AIの活用を考える上で、最初から特定のツールありきではなく、まずは基礎的な部分から理解を深めることにしました。エージェントツールを使う前に、生成AIをツールという観点で考え、その種類を整理しました。

基本となるもの： GeminiやChatGPTなど、対話を通じてさまざまなタスクをこなせるAI
専門的なもの： 特定の目的に特化したツール（Cursor、NotebookLM、Dify、Stable Diffusionなど）

この2つには違いがあって、汎用性のある「基本となるもの」から取り組むことで、今後エージェントなどのツールにも適応できる力がつくと思って学習を始めました。まずは基本的なAIの使い方とプロンプトの書き方を学び、その上で専門ツールを検討する。このアプローチで、ツールに依存しない応用力を身につけようと考えたのです。

この考えに基づき、学んだことをQAメンバーと共有する小さな勉強会を始めました。こうした取り組みについては、後日別記事で紹介します。 この活動を通じて、徐々に実務でAIを使う場面が増え、テスト設計の時間短縮などの成果も出てきました。

今回紹介するCursorの設計は、こうした基礎学習とチーム共有の延長線上にあり、開発プロセス全体の改善につなげていこうと考えました。

Cursorの基本的な仕組み

1. アーキテクチャの全体像：「会社組織」に例えると

Cursorのプロジェクトは、特定の目的のためのファイルやフォルダー一式を格納する箱のようなものです。

これを「会社」に例えると、以下のような構成になっています：

• Project Rules（社内規則）
  会社全体で共有するルール。AIの基本的な振る舞いや、プロジェクト全体の指針を定義

• Task Folders（専門部署）
  「PRDレビュー」「テストケース作成」といった、特定の業務を行うためのフォルダー群

• .cursorrules（業務マニュアル）
  各専門部署（フォルダー）の中にある、その業務専用の詳細な手順書

2. AIの動作の流れ

例えば、AIに「PRDレビューをお願い」と頼むと：

1. 基本理解 - 「社内規則」を読んで、QAエンジニアとしての基本的な立場を理解
2. 詳細把握 - 「PRDレビュー部署」の「業務マニュアル」を読んで、具体的な作業内容を把握
3. 作業実行 - この2つの情報を基に作業を実行
   • 指示が食い違う場合は、より現場に近い「業務マニュアル」を優先
4. 成果出力 - 指摘事項のリストを出力

設計思想：階層的ルール構成

基本的な考え方

このような動作の流れを実現するため、以下のような階層的なルール構造を採用しています。

Project Rules（全体のルール）

基本設定

プロジェクト全体に適用される基本的なルールです。

以下のような内容を定めています：

• AIの役割 - ライブ配信アプリ専門のQAエンジニアとして振る舞う
• 仕事の進め方 - 開発者・QA・ユーザーの視点で分析し、不明点は確認を求める
• 安全面のルール - 本番コードの生成禁止、情報の推測禁止など
• 成果物の基準 - 指摘事項には優先度（P0〜P2）を付け、読みやすい形式で出力
• 人との協力 - 重要な判断の前には確認を求める
• 重要機能の扱い - 決済や個人情報など、リスクの高い機能はとくに慎重に確認

.cursorrules（タスクごとのルール）

詳細設定

各フォルダーにある、そのタスク専用のルールです。

「PRDレビュー」や「テストケース作成」など、それぞれの業務に必要な具体的な手順を記述します。全体のルールと競合する場合は、このタスクごとのルールを優先します。

構造の利点

この階層的なルール構造で、一貫性を保ちながら柔軟な対応を可能にしています。

qa-workflowプロジェクトの構成

開発プロセスで活用するプロジェクトは、以下のようなフォルダー構成を提案します。

上流工程（企画・PO・開発向け）

• 2. PRDレビュー：PRDの曖昧な点やリスクの洗い出し
• 3. PRDのフォーマット調整：PRDを生成AI向けに最適化
• 4-1. プロダクト規模測定：開発規模測定
• 4-2. 機能仕様観点リスト作成：FSD作成の元となる観点リスト作成
• 4-3. 機能仕様リスト作成：観点の分類と優先度付け
• 4-4. 機能仕様作成：機能仕様リストを基にFSD作成
• 4-5. 機能仕様ブラッシュアップ：FSDの改善と指摘事項の整理

下流工程（QA・テスト向け）

• 5-1. FSDレビュー：完成したFSDの横断的レビュー
• 5-2. 機能仕様ブラッシュアップ：レビュー後のFSD改善
• 6. テスト観点作成：テスト観点作成
• 7-1. テストケース設計：テストケース設計
• 7-2. テストケース作成：テストケース作成

各フォルダーには専用の.cursorrulesとテンプレートファイルが配置され、一貫した流れでAIの支援を受けられます。

プロジェクト管理とチーム共有

このqa-workflowプロジェクトはGitHubで管理しており、以下のような運用を行っています：

• バージョン管理： .cursorrulesやテンプレートファイルの変更履歴をGitで管理
• チーム共有： プロジェクト全体をリポジトリで共有し、メンバー間での統一した環境を実現
• 継続的改善： プルリクエストを通じたルールやテンプレートの改善提案と適用
• ドキュメント化： README等で各フォルダーの使い方や更新履歴を記録

これにより、個人の環境に依存せず、チーム全体で同じ品質のAI支援を受けられるようになっています。

プロセス実装の詳細

検証の概要

実際にダミーデータを使用して、プロセスの実装ポイントを説明します。

前提知識：重要な2つの文書

最初に、プロダクト開発における重要な文書について説明します：

• PRD（Product Requirements Document：プロダクト要求仕様書）
• FSD（Functional Specification Document：機能仕様書）

PRD：プロダクトの「なぜ」と「何を」を定義

• 新機能やプロジェクトの目的を明確にする
• ユーザーにとっての価値や解決する課題を示す
• チーム全体で目指す方向性を合意する

FSD：「どうやって実現するか」を具体化

• 画面の動きやデータの扱い方を詳しく説明
• エラー時の挙動など、細かい仕様を定義
• 開発やテストの際の具体的な指針となる

分離の背景と理由

以前の課題

実は以前は、PRDだけで開発を進めていました。 本来PRDは目的（Why）と目標（What）を定めることが主な役割なのですが、開発を進める中で必要な情報を追加するうちに、機能の詳細な仕様まで混在する形になっていました。

発見された問題

一見問題ないように見えましたが、実際には以下の課題が見えてきました：

• 実装に必要な情報の粒度が不足
• 品質を保証するための観点が曖昧
• 本来のPRDの役割（目的と目標の定義）が分かりにくくなる

改善のアプローチ

そこで今回、以下のように役割を明確に分離しました：

• PRD - 本来の役割「目的と目標を定める」に集中
• FSD - 実装や品質保証に必要な具体的な仕様を記述

この分離により、それぞれの文書の役割が明確になり、より良い開発プロセスを目指せるようにしました。

所要時間について

記載している所要時間は、初回導入時を想定した保守的な見積もりです：

• 設定確認やファイル準備の時間
• 失敗・やり直しが発生した場合の時間
• 出力結果のレビュー・確認時間

注意： 慣れてくると、実際の処理時間は記載時間の半分程度になります

上流工程：企画からFSD作成まで

工程の概要

• 対象： 企画・PO・開発チーム
• 総所要時間の目安： 初回3-4時間、慣れると1-2時間
• 主な成果物： PRD（レビュー済み）、FSD（実装可能レベル）

検証に使用したダミーPRD情報

• 機能：「ライバーズクラブ機能の導入」（リスナーが月額課金でライバーを応援できるファンクラブ機能）
• 対象プラットフォーム：Android, iOS, サーバー
• 主要要素：決済フロー、会員権限管理、限定コンテンツ、バッジ表示

2. PRDレビュー

所要時間： 10-15分　成果物： レビュー結果ファイル（5-10件の指摘事項）

.cursorrulesの中身はこのような設定にしています：

• Notionデータベースと連携した事前調査でコンテキストを把握
• 開発者・QA・エンドユーザーの3つの視点による多角的レビュー
• Pocochaの利用規約・ガイドラインとの整合性確認
• 指摘事項は優先度（P0～P2）付きで構造化して出力
• 承認確認後、Markdownファイルとして成果物を自動生成

「レビュー用チェックリスト.md」を活用し、全般的な観点（目的・背景、スコープ、セキュリティ）、機能要件（基本フロー、データ要件、外部連携）、非機能要件（パフォーマンス、セキュリティ、保守性）、その他の観点（テスト要件、ローカライズ、運用・保守）で体系化してレビューの観点を標準化しています。

レビュー結果

• 指摘事項：5件（P0：3件、P1：1件、P2：1件）
  • P0（リリースブロッカー・必須対応）：決済エラー処理、会員権限管理、コンプライアンス遵守
  • P1（重要・早期対応推奨）：限定コンテンツのアクセス制御
  • P2（任意・リソース状況により判断）：バッジ表示の詳細仕様

4-1. プロダクト規模測定

所要時間： 5分　成果物： 規模判定結果（小・中・大の3段階）

.cursorrulesの中身はこのような設定にしています：

• AIに「プロジェクト規模の分析官」としての役割を付与
• PRDを200-250行ごとに区切って段階的に分析
• 規模を「小・中・大」の3段階で判定し、具体的な理由を記述
• 機能の複雑さ、影響範囲、必要なリソースを総合的に評価
• 他の対話や提案は行わず、規模判定のみに特化

このプロセスで得られた規模判定は、後続の機能仕様書作成において重要な役割を果たします。大規模プロジェクトの場合はより詳細な観点を、小規模プロジェクトの場合は必要最小限の観点を抽出します。これにより機能仕様の観点リスト作成時に適切な粒度で活用されます。

4-2. 機能仕様観点リスト作成

所要時間： 15-20分　成果物： 観点リスト（20-40個の観点）

.cursorrulesの中身はこのような設定にしています：

• AIに「ライブ配信サービスのプロダクトオーナー」としての役割を付与
• PRDとプロジェクト規模の分析結果を受け取って観点を洗い出し
• 想定規模に応じた粒度調整（大規模なら詳細に、小規模なら要点に絞る）
• PRDを200-250行ごとに区切って段階的に分析
• テンプレート形式に合わせた観点リストの自動生成
• PRDの主題を含む動的なファイル名での成果物出力

前段階の規模判定を活用し、実装に必要な機能詳細観点を適切な粒度で抽出します。次のFSD作成段階で必要な観点が漏れなく整理され、効率的な仕様書作成が可能です。

「機能仕様観点テンプレート.md」を活用し、基本情報（機能概要、要件・仕様、エラーハンドリング）、詳細仕様（UI/UX、非機能要件）、確認事項（PO・開発チームへの確認事項）で構造化して観点を整理しています。

4-3. 機能仕様リスト作成

所要時間： 15-20分　成果物： 詳細リスト（PO判断事項・開発判断事項に分類）

.cursorrulesの中身はこのような設定にしています：

• AIに「経験豊富なプロダクト戦略家」としての役割を付与
• 観点リストとPRDの両方を受け取って統合理解
• PRDを200-250行ごとに区切って段階的に分析
• 各観点をPOと開発チームの判断範囲で分類
• 優先度（P0～P2）の付与と構造化された出力
• PRDの主題を含む動的なファイル名での成果物出力

抽出された観点を「POが決めるべきこと（What）」と「開発チームが実装時に決められること（How）」に分類し、意思決定の責任範囲を明確にします。優先度付けにより、重要な論点から順に検討を進められます。

4-4. 機能仕様書作成

所要時間： 30-40分　成果物： FSD（実装可能レベル、10-20ページ）

.cursorrulesの中身はこのような設定にしています：

• AIに「経験豊富なテクニカルライター兼システムエンジニア」としての役割を付与
• 機能詳細リストとPRDを受け取って実装レベルのFSDを作成
• 入力要求、FSDドラフト作成・提示、ファイル作成の3ステップ構成
• 承認確認後のファイル自動生成（PRDの主題を含む動的ファイル名）
• 概要・機能要件・非機能要件・その他の標準構成での仕様書作成
• 開発者が実装に着手できるレベルの具体的で抜け漏れのない記述

分類済みの機能詳細リストを基に、開発チームが実装に必要なすべての情報を含んだFSDを作成します。仕様書は標準的な構成に従って整理され、機能詳細や画面仕様、処理フロー、データ要件などが具体的に記述されます。

下流工程：品質保証からテスト作成まで

工程の概要

• 対象： 誰でも（AIの支援により職域を問わず実行可能）
• 総所要時間の目安： 2-3時間
• 主な成果物： テスト観点リスト、実行可能テストケース（.featureファイル群）

1. FSDレビュー

所要時間： 30-40分　成果物： レビューログ（改善提案付き）

.cursorrulesの中身はこのような設定にしています：

• AIに「経験豊富なQAエンジニア兼プロダクトアナリスト」としての役割を付与
• 複数のFSDファイル、親PRD、レビュー観点チェックリストを受け取って一括レビュー
• 3ステップ構成（作業内容確認→レビュー実行・改善提案→成果物出力）
• 機能仕様書の規模に応じた分割レビューによる見落とし防止
• 具体的な改善提案と優先度（P0～P2）付きの構造化された指摘
• 承認確認後のレビューログファイル自動生成

作成されたすべてのFSDを横断的にレビューし、PRDとの整合性や実装可能性を検証します。レビュー観点チェックリストに基づいた体系的な分析により、見落としがちな課題を発見し、具体的な改善提案まで含めた包括的なレビュー結果を提供します。

「レビュー観点チェックリスト.md」をテンプレートとして活用し、具体性と明確性（数値定義、曖昧表現の排除、用語統一）、整合性（PRD・FSD間、データフロー）、網羅性（異常系、境界値、ユーザー操作）、非機能要件（パフォーマンス、セキュリティ、運用・保守）で体系化してレビューの観点を標準化しています。

2. 機能仕様ブラッシュアップ

所要時間： 20-30分　成果物： 改善済みFSD

.cursorrulesの中身はこのような設定にしています：

• レビュー結果を基にFSDの個別改善を対話的に実行
• FSDファイル、解決したい課題、提案フォーマットテンプレートを受け取り
• 3ステップ構成（作業内容確認→解決策提案→FSDへの反映）
• 指摘事項の優先度と影響範囲を考慮した解決策の提案
• テンプレートを厳密に模倣した具体的な解決策の提案
• 承認確認後のFSDファイル直接更新

レビューで発見された課題を1つずつ対話的に解決していきます。提案フォーマットテンプレートに基づいた統一された改善提案により、品質の一貫性を保ちながらユーザーの確認を得てFSDを直接更新し、実装可能な仕様書に仕上げます。

「提案の粒度とフォーマットのお手本.md」を活用し、課題の明確化、観点別の整理、具体的な提案内容を「検討項目」と「提案」のセットで構造化し、開発者が迷わないレベルの明確な仕様定義を提供しています。

3. テスト観点作成

所要時間： 20-30分　成果物： テスト観点リスト（50-80個の観点）

.cursorrulesの中身はこのような設定にしています：

• AIに「QAアナリスト」としての役割を付与
• FSDとテスト観点テンプレートを受け取ってテスト観点を網羅的に洗い出し
• Gherkinではなく上位概念の「テスト観点」に特化
• 品質特性（機能性・信頼性・パフォーマンス・セキュリティ・ユーザビリティ）の多角的考慮
• P0（必須）・P1（重要）観点の重点的な洗い出し
• リグレッションテスト観点の明確な分離
• FSDに記載された仕様のみを根拠とした観点抽出

完成したFSDを基に、実際のテスト実行で必要となる観点を体系的に整理します。単なる機能テストだけでなく、品質特性を考慮した多角的な観点により、リリース後の品質を保証するためのテスト戦略の基盤を構築します。

「テスト観点テンプレート.md」を活用し、基本テスト観点（機能テスト、エラー処理、セキュリティ、コンプライアンス）と詳細テスト観点（UI/UX、パフォーマンス、互換性、運用）で構造化し、統一された観点で網羅的なテスト設計を可能にしています。

4. テストケース設計

所要時間： 40-60分　成果物： Gherkinテストケース（30-50ケース）

.cursorrulesの中身はこのような設定にしています：

• AIに「テスト設計の専門家」としての役割を付与
• テスト観点ドキュメントとPRDを受け取ってGherkin形式のテストケースを設計
• テスト技法（同値分割・境界値分析・状態遷移テスト）の専門知識活用
• 品質特性（機能性・信頼性・パフォーマンス・セキュリティ・ユーザビリティ）の多角的考慮
• 優先度に応じた出力（P0/P1は詳細なGherkin、P2は考慮事項として整理）
• リグレッションテスト観点の追加と明確な分離
• 仕様書に明記された条件のみを基にしたテストケース設計

テスト観点を基に実行可能なテストケースをGherkin形式で具体化します。テスト設計技法と品質特性を考慮した専門的なアプローチにより、実際のテスト実行で使用できる高品質なテストケースを生成します。

5. テストケース作成

所要時間： 10-15分　成果物： .featureファイル群（体系化されたディレクトリ構成）

.cursorrulesの中身はこのような設定にしています：

• AIに「ファイル生成の専門家」としての役割を付与
• テストケース設計ドラフトとPRDタイトルを受け取って複数の.featureファイルに変換
• 指定されたディレクトリ構造と命名規則の厳格な遵守
• ドラフト内容の忠実な変換（変更・追加・削除なし）
• 見出しベースの適切なファイルマッピング
• 機能テスト・非機能テスト・リグレッションテストの体系的な分類
• 優先度（P0/P1）を含むファイル名での管理

設計されたテストケースを実際のテスト実行で使用できる形式に変換します。体系化されたディレクトリ構造により、テストの種類や優先度に応じた効率的なテスト管理が可能です。

実例で見るプロセス全体

ここでは、実際のダミーデータを使用してプロセス全体の流れを画像付きで紹介します。

上流工程の流れ

2. PRDレビュー結果

4-1. プロダクト規模測定

4-2. 機能仕様観点リスト作成

4-3. 機能仕様リスト作成

4-4. 機能仕様書作成

下流工程の流れ

1. FSDレビュー

2. 機能仕様ブラッシュアップ

3. テスト観点作成

4. テストケース設計

5. テストケース作成

このように、一連のプロセスを通じて「ライバーズクラブ機能」のダミーPRDから、具体的なテストケースまでを体系的に作成することができました。

全体のプロセス構成

現在は検証段階として進めています。個人での試行から始めて、今はPO（プロダクトオーナー）の方々が実務でも使ってくれていて、実践的なフィードバックをもらっている段階です。ここから少しずつ、開発プロセス全体の改善につなげていければと考えています。

今の使われ方

1. POの方々の活用例

   • PRDのレビューやFSD（機能仕様書）を作るときに使用
   • テストの観点出しが楽になった
   • 品質面を早めに確認できる

2. 使ってみての反応

   • 「こんな使い方もできる」という発見が増えてきた
   • まだ改善が必要な部分も見えてきた
   • 新しい活用アイデアをもらえている

次のステップ

1. 試してみる範囲を広げる

   • もっと複雑な機能でも使ってみる
   • チームみんなで使い方を考える
   • それぞれの得意分野を活かした使い方を探る

2. 開発の進め方を見直す

   • AIと一緒に仕事をする手順を整える
   • それぞれの役割の新しい形を考える
   • より良い品質保証の方法を探る

おわりに

今回は、Cursorを使ってみて気づいた開発の進め方の変化についてお話ししました。 まだ検証段階ですが、単なるツールの導入を超えて、チームの協力の仕方を変えていけそうな手応えを感じています。 とくに、これまで分かれていた役割の垣根を超えて、チーム全体でより良いプロダクトを作っていける可能性が見えてきました。

次回の予告

次回は「Cursorアシスタントを実際に運用して分かった改善と気づき」として、実際の運用を通じて得られた学びについてシェアしたいと思います。 具体的には：

• 初期設計からどのように改善を重ねてきたか
• チームからのフィードバックと見えてきた課題
• プロンプト設計で学んだこと
• 継続的な改善の進め方

実践から得られた具体的な気づきを交えながらお伝えしていきます。 とくに、プロンプト設計における業務理解の重要性や、AIを「思考パートナー」として活用していく中での発見について、詳しくご紹介できればと思います。