TL;DR（最初に要点）
- AIで“手作業がゼロ”にはならない。でも要件の質は確実に上がる。
- 要件の質が上がると、後工程（実装・QA・説明）の往復が激減。結果的にチーム生産性3.2倍経大きく貢献。
- コツは ①土台となる業務フローの整備 → ②Cursor×MCPの最小セット → ③軽量プロンプト＋品質ゲート の三段構え。
1. はじめに：こんな悩み、ありませんか？
- 要件がうまく伝わらず、差し戻しが多い
- ドキュメント作成に時間がかかる
- 仕様説明のやり取りが減らない
私も以前は同じでした。正直、「また口頭で補足すればいいや」と考えて実践していましたが、説明することで逆に私も含めてチーム全体で時間がかかっていました。
この記事では、現役PMの私が実際に使っているCursor × MCP × 業務フローの組み合わせを、成功談だけでなくつまずきポイントも含めて、体験談ベースで共有します。
2. 本記事で得られること
- Cursorで要件の質を上げる具体的な方法
- Cursor × MCP 連携の始め方と、構成の実例
- AI活用を支える業務フロー整備のコツ
- 実際に使っているプロンプト例、AI活用後の工程の詳細と考え方
3. なぜ「時間短縮」ではなく「要件の質」なのか
最初は「AI＝時間短縮」と思っていました。が、私の場合チケット作成時間はあまり短くならなかったです。理由は以下です。
- 全エンジニア向けチケットをAI経由でJira化 → 単純に件数が増えた。１チケットあたりの作成時間は短縮
- 出力は全件レビュー＆必要に応じて修正（プロンプト改善による削減の余地はある）
では何が良くなったかというと、要件の質が明らかに上がりあました。要件の質が上がる→後工程の質問と差し戻しが減る→実装/QAのスループットが上がる、という流れで、最大で3.2倍の生産性向上があったスプリントもあります。（※詳細は以下の記事を参照）
Before（よくある失敗パターン）
- 事業部の依頼チケットをほぼそのままエンジニアへ
- 背景・完了条件をざっくり記載し、非機能要件は抜けがち
- 上記の結果、実装・QAでの問い直しや仕様ラリーが多発
After（AI活用後）
- 背景・完了条件・非機能要件まで網羅した下書きがAIによる爆速で出力される
- 仕様ラリーが激減、一部タスクは「エンジニア×AI」でそのまま実装可能
- PMの“説明業務”が減り、意思決定と優先度調整に時間を割ける
4. まずは土台：AI活用を支える業務フロー
AI設定を触る前に、情報が自動で集まり、見える場所に整理される流れを用意します。ここが甘いと、AIの精度も運用の楽さも半減します。
ツールの役割分担（私の現場）
- Notion：事業部を含む“全員が見える”一次受付。依頼はまずここに起票
-
Jira：開発チームの実行面。エンジニアは基本こちらを見る
- Notion→Jiraはローコード連携で主要プロパティを同期（2重管理の摩擦を最小化）
依頼〜開発のオートメーション
- 事業部メンバーがGoogleフォームに入力
- ZapierでNotionチケット自動生成＋Slackスレッド自動作成
- 追加情報はSlackスレッドで収集
- エンジニア依頼はJiraに変換し、Notionと相互リンク
このフロー、実は弊社PMMの小川さんによる神構築です。これがあるだけで、AIの入力素材が揃い、以降の運用が段違いに楽になりました（感謝）。
業務設計のコア
- 起票のフォーマット化で抜け漏れを予防（背景・目的・要望/バグ内容等）
- Slackスレッド自動立ち上げで“追い質問”を早期に回収
- 具体情報の収集を徹底：AIは“それっぽい”推測をするため、具体性をより重視して情報を揃える
5. Cursor × MCP：最小セットの作り方
Notion／Slackに集めた情報を材料に、CursorでJiraチケットの下書きを作ります。
私のMCP連携
- Notion：依頼・要望の一次集約を参照
- Slack：起票通知と追記スレッド、その他の関連スレッドを参照
- Jira：関連する過去のJiraチケット、バックログの依存チケットを参照
- GitHub：関連PRや過去修正の参照
プロジェクトのclone
- 関連リポジトリはローカルにcloneし、コード・設定・履歴を参照可能に
- バグや調査系タスクは、Cursorが再現や原因当たりまで手伝ってくれることも
.cursor/rulesの記載
リードエンジニアの陳（Chen）さんによる整備。これがあることで、コードを読む必要があるケースや、過去の実装を参照しながら要件を書くときの動きがとてもスムーズになります。設定内容は記事リンクに詳しいですが、私の環境でもそのまま使っています。
6. 具体的なプロンプト例と設計方針、簡単に呼び出す方法（※要改善）
プロンプト設計、私流の工夫
- タスク / ストーリー / バグ / コンソール作業など、チケット種別ごとにフォーマット作成
- 情報過多にならないよう、なるべく簡潔なアウトプットとなるように作成指針を指示
- Notion, Slackのリンクを貼る場所を準備、URLを貼るだけでも完結するように
- Jiraチケットは自動作成ではなくコピペする（※結局全文チェックするため）。そのために、以下の指示をする
- URLはテキストリンクではなくそのまま記載してもらう（Jiraが自動変換してくれる）
- マークダウンはCursor上で展開してもらう。コピペできれいに整形される
- リンク情報以外も記載できるよう、補足情報欄を設置。なるべく記載するようにしている。
運用の小ワザ：プロンプトはclipyのスニペットに登録し、/bug /story /ops のように呼び分けると、簡単にそれぞれのプロンプトを呼び出せます。
実際のプロンプト例（バグチケット作成用）
以下の情報（Notionバグレポート、Slackスレッドの会話等）をもとに、Jiraのバグチケットを以下のテンプレートに従って作成してください。
NotionバグレポートURL：
SlackスレッドURL：
補足情報：
作成指針（必ず守ってください）:
- **簡潔性**：各項目は必要最小限の情報に絞る
- **明確性**：技術者以外にも理解できる表現を使用
- **完全性**：バグ修正に必要な情報は漏らさない
- **実用性**：実際の調査・修正作業で参照しやすい形式にする
- **緊急性**：バグの影響範囲と優先度を明示する
- 具体性：添付画像や必要なURL情報は、URL形式のまま記載
（※URLの前後にはスペースを入れる）
出力形式：マークダウン形式ではなく、Jiraにそのままコピーできるようにチャットに展開してください。
テンプレート:
---
## サマリ（Summary）
【形式】[緊急度][影響範囲] - [バグの箇所]で[問題の現象]が発生するバグを修正する
【例】[高][全ユーザー] - 患者詳細画面で処置記録が表示されないバグを修正する
## 説明（Description）
バグの発見経緯、SlackやNotionでの議論の要点、原因の推定状況などを簡潔に記述
### 再現手順（Steps to Reproduce）
バグを確実に再現できる具体的なステップを番号付きで記載
【例】
1. 管理者権限でログインする
2. 患者一覧から特定の患者を選択する
3. 「処置記録」タブをクリックする
### 期待される動作（Expected Behavior）
本来どのように動作すべきか
【例】処置記録一覧が時系列順で表示され、各記録の詳細が確認できる
### 実際の動作（Actual Behavior）
現在発生している異常な動作
【例】処置記録一覧が空白で表示され、エラーメッセージも表示されない
### 環境情報（Environment）
- ブラウザ / OS：
- アプリバージョン：
- ユーザー権限：
### 影響範囲・重要度（Impact & Priority）
- 影響範囲: 対象ユーザー数、対象機能
- 重要度: 低 / 中 / 高 / クリティカル
- 業務への影響: 定性的・定量的に簡潔に記述
### 修正作業内容（Fix Tasks）
実施する調査・修正作業をチェックリスト形式で記載
【例】
[ ] エラーログとネットワークログの確認
[ ] フロント/バックエンドの該当箇所調査
[ ] コード修正の実装
[ ] テスト環境での確認
### 完了条件（Definition of Done）
チェック可能な修正完了の条件を記載
【例】
[ ] すべての再現手順で期待通りに動作すること
[ ] 関連機能に影響がないことを確認
[ ] UI/結合テストを実行し、通過
### 関連情報（Related Information）
作業時に参照すべき外部情報をリンクまたは箇条書きで記載
- スクリーンショット・ログ等:
- 関連チケット:
7. AIと共に生きる：信用しすぎない、でも活用する
上記の設定を行い、プロンプトを使えば、ある程度は品質の高いチケットを作れます。ただし、それだけで全部うまくいくわけではありません。特に気をつけたいのはハルシネーションです。
-
課題
- そもそもAIに完璧なインプットを渡すのは難しい
- 不完全なインプットからAIが“推察”で補ってしまい、不正確な出力になることがある
- しかも不正確でも自信満々に見える
以下、それぞれへの対策です。
①インプットの質／それによる不正確なアウトプットへの対策
対策：完璧なインプットは諦め、AIのアウトプットを修正する。
限られた時間で集められる情報だけを投げ、出力を人間が必ず確認するほうが早いです。私はAIのアウトプットを全件読み、
- 意図していない内容の修正
- 不足情報の追記
- 自分で確かめきれない箇所への注釈（※AI生成で要注意である旨） を行っています。
※「自分で確かめきれない箇所への注釈」とは：AIが「このコード／データを修正してください」と具体に言及したが、その正確性を私が判断できない場合に、AIの提案であることと要確認であることを明記しておく運用です。
②不正確でも自信満々なアウトプットへの対策
対策：エントロピー（不確実性）を表示するプロンプトを入れる。
弊社エンジニアの宮田さんの“神プロンプト”を参考に、出力の末尾に自信度（エントロピー）の出力を必須化しています。これにより、どの部分に自信がある/ないのかを見抜きやすくなりました。
参考記事：もうすぐ出るはずなので、乞うご期待！
8. おわりに：まずは「1チケット」から試してみよう
AI活用の成果は仕組みで決まりますが、 仕組みは小さな1ステップから始まります。まずは肩の力を抜いて、以下を小さく始めてみてください。
- 1件、普段書いているJiraチケットをCursorに書かせてみる （プロンプト丸パクリでOK！）
- 全文レビューをし、プロンプトを改善する（※頑張りすぎない）
- clipyでプロンプトのスニペットを作ってみる
- 要望フォームをNotion連携で自動化してみる
肩の力は抜いたまま、まずは1チケット。次の自分を助ける仕組みを、少しずつ増やしていきましょう！この記事が少しでもPMの皆さんの参考になれば幸いです！
Views: 0
