プロダクトの解像度を「実装レベル」まで高めるプロダクトマネージャーの Cursor 活用術

こんにちは、jinjer でジンジャー給与のプロダクトマネージャー（PdM）をしている佐藤と申します。

jinjer のプロダクトマネージャー組織内でも AI を業務で使うのは当たり前になってきており、自分としても AI を普段の業務に組み込む「型」のようなものがある程度できてきました。

それは単なる時短術ではなく、プロダクトの解像度を「実装レベル」まで高めるための活用です。 そこで今回は、ソースコードやドメイン知識を統合し、より本質的なプロダクトマネジメントを行うための Cursor 活用術を、私の事例とともにご紹介しようと思います。

前提： 作業スペースの構成

Cursor を使用するとき、自分は以下のような構成で作業スペースのフォルダを作っています。

.
├── assets                              # md ファイルに挿入する画像や pdf を格納する
│   ├── img
│   ├── markdown                        # ★ PDF から変換されたテキストデータはここへ
│   └── pdf                             # 国税庁の資料などはここへ
├── jinjer-products                     # ソースコードを格納する
│   └── payroll
├── pdm-docs                            # プロダクトごとのチケットや仕様書などを格納する
│   └── products
│       └── payroll
│           ├── .context                # ドメイン知識や共通仕様をまとめたテキスト
│           └── feature-tickets
├── scripts                             # pdf を md に変換するなどの自作スクリプトを格納する
└── templates                           # チケットのテンプレートなどを格納する

この構成を機能させるためのポイントについて解説します。

.context フォルダにプロダクトの周辺情報を食わせる

私はプロダクトマネージャーが Cursor を使う最大のメリットは、適切なコンテキストを与えることで、ソースコードの情報と与えられたコンテキストの情報の整合性を判断しながら回答してくれることだと思っています。

そこで私は、

• .context フォルダにソースコード以外の情報を与える
• Cursor の Project Rules 機能で .context.mdc というファイルを作成し、alwaysApply: true（常時適用） に設定

ということを行なっています。

これにより、チャットを開いた瞬間から Cursor は「jinjer の仕様とソースコード」を前提知識として持った状態になります。
.context には画像のようにヘルプページの内容を markdown 形式に変換したファイルや、後述する法的資料を markdown に変換したものを格納しています。
ヘルプページを読み込ませている理由は、ソースコードだけでは追いづらい「仕様の因果関係」を補完するためです。 特に「ある設定を変更すると、給与計算の結果にどう波及するのか」といったユーザー視点での振る舞いや業務ロジックは、コードを読むよりもヘルプページを参照した方が、AI にとっても文脈を理解しやすいためです。

.context.mdc の中身（クリックで展開）

---
alwaysApply: true
---

# コンテキスト読み込みルール

## 前提

このルールを読み込んだら、ユーザーに「context.mdc を読み込みました!」と必ず伝えてください。

## ルール

ユーザーからの質問や指示に対して、以下のルールに必ず従うこと

### 前提ルール

ユーザーが明示しなくても、jinjer のプロダクトの仕様を回答する。他の人事労務 SaaS の振る舞いではなく、jinjer の仕様を回答すること。

### `.context` の読み込み

以下の資料から jinjer 給与の仕様を読み込む。
ネストが深いフォルダ構造でも、すべてのファイルを読み込むこと。

- ワークスペースの root 直下にある `.context/` フォルダ内のすべてのファイル（サブフォルダも含む）
- `pdm-docs/products/payroll/.context/` フォルダ内のすべてのファイル（サブフォルダも含む）

### ソースコードの読み込み

以下のフォルダのソースコードを読み込むこと。
ネストが深いフォルダ構造でも、サブフォルダ内のすべてのファイルを読み込むこと。

- `jinjer-products/payroll/`: jinjer 給与のソースコード

法的資料を「知識」として取り込む

給与計算のドメインでは、国税庁や厚生労働省から発表される資料（多くは PDF）を元に仕様を定義することが多くあります。しかし、PDF をそのまま Cursor に読ませることは現時点ではできません。

そこで私は、scripts フォルダに自作の変換スクリプトを用意し、PDF 資料を Markdown に変換してから Cursor に読み込ませる運用をしています。変換の精度を検証するにあたり、色々なライブラリを比較検討しましたが、現在は docling というライブラリを使用するのに落ち着いています。

1. 国税庁等の PDF を assets/pdf に配置
2. 変換スクリプトを実行し assets/markdown にテキストデータとして出力
3. 必要に応じて .context フォルダへ集約し、AI の前提知識として固定

活用例 1.ソースコードと法的根拠を照らし合わせた仕様調査

ここからは、実際に私の Cursor 活用例をご紹介します。

プロダクトマネージャーとして新しい機能を設計する際、既存の実装を理解することは非常に重要です。

特に私が担当している給与計算というドメインは、法規制に基づいた厳密なロジックが求められます。「なんとなく動く」では許されず、税法に則った 1 円単位の正当性がシステムとして担保されていなければなりません。

そのため、Cursor を単なるコード検索ツールとしてではなく、「現行実装（Code）」と「法的根拠（Context）」のギャップ分析ツールとして活用しています。

Cursor に、前述した「PDF から変換した Markdown（法的根拠）」と「ソースコード（現行仕様）」の両方を読ませた状態で壁打ちを行います。

例えば、法改正対応などで新機能を追加する場合、以下のような観点で質問を投げかけます。

• 実装との整合性確認: 「国税庁の資料にあるこの計算ルールは、現在のコードではどのように表現されていますか？」
• 仕様の具体化: 「この法的要件を満たすために、現行のデータ構造で不足しているプロパティはありますか？」

これにより、「法律上はこうあるべきだが、現状のシステム構造ではここがボトルネックになる」といった具体的な課題を、開発チームに相談する前の段階で洗い出すことができます。

活用例 2.プロダクトバックログの起票

仕様策定の壁打ちのみならず、実際のチケット作成にも Cursor を介入させております。

jinjer のプロダクトマネジメントチームでは Productboard というプロダクトマネジメントツールと JIRA を連携し、チケット管理を行っています。まず Productboard 上で顧客インサイトを解決するための feature と呼ばれるチケットを作成し、それを JIRA に Push しています。

チケット起票の質を均一化するため、ここでも feature.mdc というルールファイルを読み込ませています。

使用しているルール（feature.mdc）

以下が実際に使用しているルールの内容です。
Atlassian の MCP を活用し、Cursor から直接 Jira の情報を取得・更新できるようにしています。

feature.mdc の中身（クリックで展開）

---
alwaysApply: false
---

# Create Feature Rule

## 前提

このルールを読み込んだら、ユーザーに「feature.mdc を読み込みました!」と必ず伝えてください。

feature チケット起票の際には以下の前提を必ず守ってください。

- 後述の .context の読み込みをした上で既存仕様から矛盾がないこと
- ユースケースを満たす、また考えられる中でユーザーにとって最善の UI/UX を実現していること
- Specs(仕様)欄の記載内容について、開発チームが対応すべきことがわかりやすく簡潔に記してあること(変数や関数名を記載する必要はない)

## ルール

ユーザーからの質問や指示に対して、以下のルールに必ず従うこと

### .context の読み込み

以下の資料から jinjer 給与の仕様を読み込む。
ネストが深いフォルダ構造でも、すべてのファイルを読み込むこと。

- ワークスペースの root 直下にある .context/ フォルダ内のすべてのファイル（サブフォルダも含む）
- pdm-docs/products/payroll/.context/ フォルダ内のすべてのファイル（サブフォルダも含む）

### 作成時の注意点

以下の注意点を必ず守り、feature を作成すること

- Why（背景・課題・なぜ作るのか）が明確に記載されている
- What（何を作るのか）が具体的に定義されている
- 法的根拠・規制要件を法律や国税庁の資料から確認されている
- 最新の税法の情報を取得し、仕様を策定されている

### feature の起票手順

1. ユーザーが「チケット起票」と指示したら、pdm-docs/products/payroll/feature-tickets/ フォルダに ${xxx-xxxxx}-${feature-name}.md というファイル名で markdown ファイルを作成する
2. 作成時の注意点を守り、ユーザーと会話を続けて仕様を策定する
3. ユーザーが「md に転記して」と指示したら、対象の markdown ファイルに templates/feature.md のフォーマットに沿って、内容を記載する
4. ユーザーが「Jira に反映して」と指示したら、markdown の prefix ${xxx-xxxxx} と一致する Jira のチケット番号 xxx-xxxxx の説明欄に markdown の内容で追記する(同時編集が発生することを懸念して上書きはしない)

重要な注意点:

- 絶対に勝手に Jira チケットを作成してはいけない
- ユーザーの指示があるまでは Atlassian の MCP は実行しなくてよい
- JIRA にいきなり feature を作成するのではなく、必ず markdown のファイルを作成すること

### feature チケットのサンプル

チケットを起票するときは以下のチケットを起票時のサンプルとすること

- xxx-21836-労保事業所の料率自動反映機能の追加

### デフォルトプロジェクト情報

atlassian の MCP を使用するときは以下のプロジェクトから feature の情報を取得・書き込みを行うこと

- プロジェクト: xxxxx
- クラウド ID: xxxxx-xxxx-xxx-xxxxx
- プロジェクトキー: xxx

### Jira 統合ルール

Jira との統合は以下のタイミングでのみ実行する:

- Jira 反映時: ユーザーが「Jira に反映して」と指示した際に、対象チケットの情報を取得し、markdown の内容を追記する
- 既存チケット情報が必要な場合: ユーザーが明示的に既存の Jira チケット情報を求めた場合

### データ表示形式

Atlassian MCP を使用して Jira 課題を表示する際は、常に以下を含める

- チケットキー（xxx-xxxxx）
- タイトル/概要
- 関連する場合は簡潔な説明
- 課題タイプ（種別）
- ステータス
- 優先度
- 担当者

この手順により、以下のようなフローで仕様策定が進みます。

1. 要件の壁打ち: 「チケット起票」と投げかけると、Cursor が .context とソースコードを読み込み、法的根拠や既存仕様を踏まえた仕様案を作成
2. Markdown 作成: 指示一つで所定のフォーマット（templates/feature.md）で出力される
3. Jira 連携: 最後に「Jira に反映して」と伝えると、MCP 経由で Jira チケットに内容が追記される

もちろん 1 回のやり取りで期待通りのチケットを起票できるわけではないので、Cursor に作ってもらったチケットを叩き台にさらに壁打ちを進めて、要件を詰めていきます。

活用例 3. ソースコードをもとに開発チームとコミュニケーション

Cursor を使用すると、実際にソースコードを書いていなくても、「年末調整の扶養家族の判定ロジックはこのファイルに書いてあります」と教えてくれるので、開発チームと仕様を議論する際、具体的なコードを参照しながら会話ができます。
仕様書ではなく、実際に動いているソースコードを元に会話ができるので、議論が空中戦にならず、お互いがコンテキストを理解して会話を進めることができます。

仕様について触れている箇所は公開できないため、モザイクばかりになってしまいましたが笑、こんな感じで会話を繰り広げました。

まとめ

今回はプロダクトマネージャーの Cursor 活用事例をご紹介しました。
Cursor は単なる作業効率化のツール手段にとどまりません。プロダクトマネージャーが技術のブラックボックスを恐れずに開き、プロダクトに対する解像度を飛躍的に高める強力な武器となります。

仕様策定や実装確認といった実行フェーズだけでなく、OKR やプロダクトビジョンに基づいたプロダクト戦略の立案といった、より上流の工程における Cursor の活用も検討しています。

このあたりの「戦略策定 × AI」の事例についても、知見が溜まり次第、次回の投稿で詳しくご紹介できればと思います。