※このブログは、こちらのブログの日本語訳版です。

Cursor AIでコーディングワークフローを最適化する方法を発見しましょう。構造化されたアプローチにより、エラーを減らし、効率を高め、プロジェクトをより効果的に管理できます。

I. はじめに

Cursor AI は、AIエージェントを搭載したコーディングアシスタントとして注目を集めています。しかし実際に使ってみると、多くの開発者が次のような課題に直面しています。

• コンテキスト保持の限界

• 意図しないコードの改変

• 処理速度の遅さ

• 解決策の不十分さ

• スマートとは言えず、バグも残るコミット／ロールバック操作

私自身もこれらの課題に直面してきました。そこで試行錯誤を重ねた結果、Cursor AIを効果的に活用するための実践的かつ構造化されたワークフローを開発しました。今では、これらの問題に悩まされることもなくなり、コーディング作業は軽くなり、コードレビューやプロジェクト管理もより効率的になっています。

この記事では、そのワークフローを各ステップごとの具体例とともに詳しくご紹介します。すぐに実践できるよう分かりやすく解説しますので、ぜひ最後までご覧ください！

原因分析（Root Cause Analysis）

「モデルが切り替わるたびに、開発目標やプロジェクト構造、過去のやり取りを忘れてしまう。」

「Cursor が十分なコンテキストを取得できず、適切な編集ができなくなっている。」

https://forum.cursor.com/t/cursor-ai-needs-persistent-project-memory-smarter-adaptation/69560?utm_source=chatgpt.com

Cursor AIの制限についての不満は、公式フォーラムでも数多く見つけることができます。
その主な原因は――？

Cursor AIが同一セッション内であっても過去のやり取りを記憶できない主な原因は、以下の要素にあります。

1. コンテキストウィンドウの制限：Cursor AIに搭載されているような大規模言語モデル（LLM）は、処理できるトークン数（単語や文字数）に上限があります。この上限を超えると、古い情報が切り捨てられ、過去のコンテキストが失われてしまいます。

2. メモリ管理戦略：パフォーマンスとリソースの最適化のために、Cursor AIは会話履歴の一部を要約・破棄するメモリ管理技術を採用しています。その結果、過去のメッセージや指示を忘れてしまうことがあります。

3. セッションベースの記憶：Cursor AIは異なるセッション間で記憶を保持しません。新しいセッションは、以前のやり取りに関する情報なしで開始されるため、ユーザーは毎回コンテキストを手動で再提示する必要があります。

4. 曖昧なユーザーのプロンプト：あいまいで不明瞭な指示はAIを混乱させ、会話全体の一貫性を保つのが難しくなります。明確かつ具体的なプロンプトを与えることで、この問題をある程度防ぐことができます。

そこで登場するのが MCP (Model Context Protocol) — これはユーザーの意図を明確にし、エージェントの理解力を高める画期的な仕組みです。

Note: MCP（Model Context Protocol）は、Anthropicによって開発されたオープンスタンダードで、AIシステムがさまざまなデータソースと直接接続できるように設計されています。これにより、AIはより適切な情報を取得し、タスクを効果的に実行できるようになります。

II. 実行方法（How to Execute）

1. 準備（Preparation）

• 準備：MCPの導入手順

  プロジェクトにMCP（Model Context Protocol）を組み込むことで、Cursor AIが外部ソースと連携し、文脈理解とタスク実行能力を大幅に向上させることが可能になります。以下は主要なMCPの導入方法です。

✅ GitHub MCP

• リポジトリ: https://github.com/github/github-mcp-server

• トークン取得方法:
  GitHubトークン設定ページ にアクセスし、Personal Access Tokenを発行。

🔹 このMCPにより、GitHubとの連携が簡単になり、関連情報の取得やタスクの割り当てが効率化されます。

✅ Figma MCP

• リポジトリ: https://github.com/GLips/Figma-Context-MCP

• トークン取得方法:

  Figmaにログイン

  「Help and Account」→「Account Settings」

  「Security」タブを開く

  「Personal Access Tokens」から新しいトークンを発行

🔹 フロントエンドで実装すべき仕様をエージェントが理解し、適切にアクションを実行できるようになります。

✅ データベース MCP

使用するデータベースに応じて、適切なMCPを選択してください：

• PostgreSQL:
  https://mcp.so/server/postgres/modelcontextprotocol

• MySQL:
  https://mcp.so/server/SuMiaoALi_mysql-mcp-server/MCP-Mirror

🔹 これらのMCPにより、エージェントはデータベースから必要な情報を取得し、データ指向のタスクをより正確に実行できます。

これらのMCPを整えることで、Cursor AIはプロジェクト全体をより深く理解し、より高度な支援が可能になります。次に、実行ワークフローの各ステップを見ていきましょう。

2. 実行（Execution）

2.1. Task Preparation

入力内容：

• Issueリンクの入力

• 攻略ルールファイル：prepare-task.mdc

出力内容：

• 背景情報の収集（Get all Background）

• タスク処理用チェックリストの自動生成（Create checklist handle task）

このステップでは、エージェントが指定されたIssueとprepare-task.mdcファイルをもとに、以下を実行します：

1. Issueに関連する背景情報（仕様、過去の議論、関連コードなど）をすべて収集

2. そのタスクを処理するためのチェックリスト（ステップや必要リソースなど）を構築

これにより、実装に取りかかる前の理解不足や抜け漏れを未然に防ぐことができます。

✨ 注目ポイント（Key Highlights）

• 目的駆動型（Objective-Driven）
  　タスクに取りかかる前に、まずチケットの「目的」を明確にレビューさせる。曖昧な作業のまま進めることを防止。

• コンテキスト認識（Context-Aware）
  　親タスク、関連Issue、バックエンド／フロントエンドの構成など、点在する情報を横断的に接続。全体像を把握したうえで作業を開始できる。

• 構造重視（Structure First）
  　Issueの「Background」セクションに技術的な詳細を自動で追記。文脈を推測する必要がなくなり、認識の齟齬を回避。

• 実行可能な出力（Actionable Output）
  　抽象的な目的を「Acceptance Criteria」内のチェックリスト形式に変換。何を・どの順序で・どこまでやればよいかが明確に。

• 早期フィードバックループ（Feedback Loop）
  　不明瞭な点や仕様の抜けを初期段階で洗い出し、ブロッカー化する前にチーム内で議論を促進。🔍 Context Analysis Rule: Your Task’s Foundation

このルールは、エージェントに対して以下の複数ソースを自動でスキャンするよう指示します：データベーススキーマ、Figmaデザイン、関連Issue、該当コードなど。これにより、タスクの背景を包括的に理解させます。

コンテキストが明確になった後、エージェントは実装に向けた構造化されたチェックリストを生成します。ユーザーはそのチェックリストをレビューし、必要に応じて編集・拡張したうえで次のステップに進むことができます。

これはいわば「離陸前のチェックリスト」のようなものです。
これを飛ばしてしまうと、実装やテストの段階で方向性がズレたり、手戻りが発生する可能性があります。

💡 なぜこのステップが重要なのか（Why This Step Matters）

このステップは非常に重要です。なぜなら、以下の点に直結するからです：

• タスクの処理精度
  　：目的や背景を正しく理解していないと、的外れな実装になりやすい。

• コード変更の妥当性と網羅性
  　：必要な箇所を正しくカバーできているか、不足や過剰な修正がないかに直結。

• 後工程で書かれるユニットテストの品質
  　：テスト観点の抜けや、そもそも誤った期待値でのテスト設計につながる可能性がある。

MCP（社内のマルチエージェントコントロールパネル）に組み込まれたツールを活用することで、このルールは各タスクが十分な情報と共通認識に基づいてスタートすることを保証します。
つまり、曖昧さや認識ズレを最初の段階で排除し、実装のブレや無駄を防ぐ基盤を築くのです。

✅ 実際のユースケースデモはこちらResult:

.cursor/rules/prepare-task.mdc

---
description: Guide AI to analyze task objectives, gather related information, and update the issue accordingly.
globs: []
alwaysApply: false
---

🎯 Objective
	•	Understand the purpose of the current ticket.
	•	Review parent and related tasks for context.
	•	Gather relevant backend and frontend information.
	•	Update the issue’s Background section with gathered information.
	•	List actionable items as checkboxes.
	•	Update the issue’s Acceptance Conditions or Definition of Completion with these items.

✅ Execution Steps
	1.	Read the Purpose: Examine the “The purpose of this ticket” section to understand the main goal.
	2.	Review Related Tasks: Analyze parent tasks and any related tasks to gather additional context.
	3.	Gather Technical Information:
	•	Backend: Identify related database structures, processing flows, and relevant code modules.
	•	Frontend: Identify related components, state management (e.g., store), and UI elements.
	4.	Update Background: Summarize the gathered information and update the issue’s Background section accordingly.
	5.	List Actionable Items: Based on the information, create a checklist of tasks that need to be completed.
	6.	Update Acceptance Criteria: Add the checklist items to the issue’s Acceptance Conditions or Definition of Completion section.
    7.	Document Issues & Discussions:
	    •	Identify any ambiguities, missing information, or potential challenges.
	    •	Document these issues and initiate discussions with relevant stakeholders to resolve them.

📌 Note: Before executing each step, seek explicit confirmation to ensure accuracy and alignment with project goals.

2.2 タスク実行（Task Execution）

入力内容：

• Issueリンク

• 実行ルールファイル：execute-task.mdc

出力内容：

• 機能の実装完了（Complete feature）

• ステップごとの順次処理（Process in turn step by step）

• チェックリストの更新（Update process checklist when done）

• Issueへのコメント追加、コミットのハッシュ記録（Add comment into issue, hash commit）

✨ 実行ルールの注目ポイント（Key Highlights of the Execution Rule）

• ✨ 実行ルールの特長（Key Highlights 詳細）

• 目的中心（Objective-Centric）
  　タスクの主目的と期待される成果を明確に定義してから実行を開始。作業ブレを防止。

• コンテキスト認識（Context-Aware）
  　Issueの「Background」セクションを確認し、依存関係や関連データを把握した上で進行。

• チェックリスト駆動（Checklist-Driven）
  　Acceptance Criteria（受け入れ基準）または完了定義に基づいて、順番にチェックを入れながら実行。推測なしで確実に処理。

• 透明な計画提示（Transparent Planning）
  　コードに手を入れる前にアプローチ案を提示し、ユーザーの確認を経てから実行。安心感と合意形成を両立。

• 制御された実行（Controlled Execution）
  　ファイルの追加・編集・削除を行う前に明示的な承認を求め、意図しない変更を防止。

• 段階的なコミット（Incremental Commits）
  　各タスク項目ごとにコミットし、メッセージ形式も明確に準拠。履歴が明快で保守しやすい。

• 進捗の可視化（Progress Visibility）
  　Issueに完了チェックリストとコミットハッシュを自動更新。誰でも進捗を一目で確認可能。

• ユニットテストは別ルールで管理（Unit-Test Deferred）
  　このフェーズでは実装に集中し、ユニットテストは別ルールで明確に管理。責任範囲を分離して効率化。

🛠️ タスク実行ルール：計画から進捗へ

このルールは、エージェントがAcceptance Criteria（受け入れ基準）や完了定義（Definition of Completion）に基づくチェックリストに従って、厳密にタスクを実行するように設計されています。

何かアクションを実行する前に、エージェントは必ず実行プランを提示し、ユーザーがそれをレビュー・承認・修正できるプロセスを踏みます。
これにより、「勝手に進めてしまう」といったリスクを排除し、コントロールされた・納得感のある開発が可能になります。

確認が取れると、エージェントは以下のようにステップ・バイ・ステップで実行を進めます：

• 必要な変更を加える
  　チェックリストの指示に従って、コード・設定・構成などを適切に更新。

• 各ステップ完了ごとにコミット
  　標準化されたフォーマットに沿ってコミットメッセージを記述し、履歴を一貫性のある形で記録。

• Issueを更新
  　完了した項目にチェックを入れ、該当するコミットハッシュをコメントとして投稿。進捗が即座に可視化される。

あなたが常に主導権を握っています。
エージェントは面倒な実装作業を担当しますが、実行プランの承認が得られるまで、一切の変更は行いません。

この構造化されたプロセスにより、一貫性（Consistency）、トレーサビリティ（Traceability）、そして実際の進捗管理（Real Progress Tracking）がすべて自動的に確保されます。
手動での管理作業に時間を取られることなく、プロジェクトは整然と前進します。

.cursor/rules/execute-task.mdc

---
description: Execute tasks by understanding objectives, reviewing background, processing checklist items, confirming changes, committing code, and updating progress.
globs: []
alwaysApply: false
---

🎯 Objective
	•	Comprehend the task’s main goal.
	•	Review the Background section to understand context and related data.
	•	Process items in the Acceptance Conditions or Definition zqof Completion checklist.
	•	Confirm each file addition, modification, or deletion before execution.
	•	After each task, commit code following the project’s commit message conventions.
	•	Update the issue by checking completed items and commenting on progress, including the commit hash.
	•	Note: Unit tests are not to be written during this phase.

✅ Execution Steps
	1.	Understand the Task Objective: Analyze the task description to identify the primary goal.
	2.	Review Background Information: Examine the Background section to gather context, dependencies, and relevant data.
	3.	Present Proposed Approach:
	•	Before initiating any changes, outline the planned approach for the task.
	•	Seek explicit confirmation to proceed with the proposed method. 
	4.	Process Checklist Items:
	•	Iterate through each item in the Acceptance Conditions or Definition of Completion.
	•	If an item is already checked, skip it.
	•	If unchecked, perform the necessary actions to complete it. 
	5.	Confirm Changes:
	•	Before adding, modifying, or deleting any files, seek explicit confirmation.
	•	Proceed only after receiving approval.
	6.	Commit Code After Each Task:
	•	After completing each checklist item, commit the changes.
	•	Use commit messages that adhere to the project’s conventions.
	7.	Update Progress:
	•	Mark the completed checklist item by checking its box in the content issue tracker.
	•	Add a comment summarizing the progress, including the commit hash.

2.3 ユニットテスト実行（Task Unit Test）

入力内容：

• Issueリンク

• テストルールファイル：test-task.mdc

出力内容：

• テスト計画の策定（Plan test）

• 3段階に分けたユニットテストの実装（Unit test for 3 levels）

• Issueへのコメント追加、コミットハッシュの記録（Add comment into issue, hash commit）

✨ テストルールの注目ポイント（Key Highlights of the Testing Rule）

• フルサイクルカバレッジ（Full-Cycle Coverage）
  　完了したIssueはすべて、ユニットテスト・結合テスト・API／コンポーネントテストで裏付けされることを保証。
  　対象は バックエンド（NestJS） と フロントエンド（NextJS） の両方。

• 厳格なテスト階層構造（Strict Architecture）
  　ユニット → 結合 → API/コンポーネント の3層構造を強制し、責任の分離とテスト意図の明確化を徹底。

• 整理されたディレクトリ構造（Organized Structure）
  　テストは src/modules/**/tests/ 配下にモジュール単位＆テストタイプ別で整理。発見性・保守性に優れる。

• シナリオ駆動型設計（Scenario-Driven）
  　実装前に、テストの前提・入力／出力・期待される影響を含む詳細なシナリオを必ず作成。

• 段階的コミット（Incremental Commit Workflow）
  　各テストは個別にコミット・プッシュされ、Issueに概要とコミットハッシュをコメントとして追記。高いトレーサビリティを実現。

• 最終テストサマリー（Final Test Summary）
  　すべてのテスト完了後、テスト総数・カバレッジ補足・関連コミットハッシュをIssueにまとめて報告。

• 品質優先の運用ルール（Quality-First Enforcement）
  　カバレッジ80%以上を基本とし、スナップショットテストは必要最小限に限定。DIが難しい箇所ではMock／Spyの活用を推奨。

このルールは、テスト実装における規律と透明性を強制し、テストを「ついで」や「後回し」にするのではなく、
体系的かつレビュー可能なプロセスへと変革します。

🧪 自動テスト生成ルール（Automated Test Writing Rule）

このルールにより、エージェントは事前に定義された各レイヤーごとのステップに基づいて、
ユニットテスト・結合テスト・APIテストを順に実装できるようになります。

エージェントは以下のように動作します：

1. 各テストタイプ（ユニット → 結合 → API）を順に処理

2. 各関数単位でテストを実装し、完了後にコミット

3. Issueに詳細なコメント（内容の要約＋コミットハッシュ）を追加

これにより、明確なテスト責任・変更履歴・進捗の可視化が担保され、
開発チーム全体でレビュー・追跡・改善がしやすいテストプロセスが構築されます。

これにより、すべてのテストは追跡可能・レビュー可能・元のタスクと完全に紐づいた状態になります。
その結果、長期的な信頼性が確保されるだけでなく、将来的なデバッグやリファクタリングもスムーズに行えるようになります。

バックエンドであれフロントエンドであれ、このルールはテストの一貫性とカバレッジを強制し、
チームがリグレッション（機能の逆行）を防ぎつつ、安心してリリースできる体制を支援します。

結果（Result）:

.cursor/rules/test-task.mdc

---
description: |
  Write comprehensive unit tests for issues. Ensure coverage for backend and frontend logic, components, and integration. Maintain consistent documentation and reporting throughout the process.

globs: []
alwaysApply: false

🎯 Objective:
  - For each completed issue, write and document a full suite of tests.
  - Ensure backend and frontend both follow 3-layer test architecture.
  - Track test progress clearly in GitHub Issues with commit hash and checklist updates.

✅ Test Types Required:

  🔧 Backend (NestJS):
    1. Unit Test: Isolated logic test (e.g., services, utils).
    2. Integration Test: Service flow with DB/mock dependencies.
    3. API/Controller Test: HTTP endpoint test via e2e or supertest.

  🖼️ Frontend (NextJS):
    1. Unit Test: Logic (e.g., composables, utils).
    2. Component Test: Render + UI behavior of individual components.
    3. Integration Test: Workflow coordination, pages interaction.

📂 Test File Structure:
  - All test files **must be placed inside**:
    `src/modules/**/tests/`
  - Each module should contain its own test folder:
    - Example: `src/modules/user/tests/user.service.spec.ts`
    - Example: `src/modules/loan/tests/loan.integration.spec.ts`
  - Group test files by type (unit, integration, api).

🛠️ Execution Flow:
  1. Read the related issue, its comments, and all PRs from branches named:
     `{feature|fixbug}/AP-{issueNumber}-xxxx`

  2. Draft testing scenarios and describe each test in a checklist:
     - What context does it test?
     - Input/Output description.
     - Where is it used?
     - What state does it affect or depend on?

  3. Pause for review/feedback before implementation.

  4. Write tests one by one.
     - For each finished test function:
       - Add a descriptive comment.
       - Push the change.
       - Post a comment in the issue with a summary.

  5. Once all test types are complete:
     - Commit all changes.
     - Push and update the issue:
     - Mark all checklist items done.
     - Update content issue of part `Test & Coverage` final summary with test count and commit hash

🧠 Notes:
  - Use strict coverage threshold (80%+ where applicable).
  - Group tests logically and place files in `/__tests__/` or alongside code.
  - Use mocks/spies/fakes where real dependency injection is not feasible.
  - Snapshot test only when meaningful (e.g., components with conditional rendering).

例外処理（Exception Handling）

現実がチェックリストと食い違った場合は、以下の軽量プレイブックに従って対応します：

III. 結論

🔄 マイクロコミットによるコンテキスト制御

タスクをより小さなアクションに分割し、それを即座にコミットすることで、Cursor AIはコンテキストをより効果的に追跡できます。たとえコンテキストの一部が失われた場合でも、コミット履歴や過去のメッセージを活用して、エージェントがすばやく再同期できるのです。この方法はまた、タスクの引き継ぎやコラボレーション、障害の切り分けにも役立ちます。

現在のワークフローは、従来のモデルに従っています。

準備 → 実装 → テスト（ユニットテストおよび統合テスト）

しかし、近年注目を集めている代替モデルもあります。

準備 → テスト → 実装

⚖️ モデルの比較

🔔 アップデート

Cursor はバージョン 1.0 をリリースし、いくつかの重要な機能が追加されました。中でも注目すべきは「メモリー（Memories）」で、これによりエージェントがルールの定義をセッションをまたいで保持・活用できるようになりました。

詳細はこちらをご覧ください： Cursor v1.0 Changelog

🙌 ご覧いただきありがとうございました

ここまで読んでくださった方、本当にありがとうございます！

この解説が、Cursor AI をより効果的に活用し、開発ワークフローの摩擦を減らし、より明確な作業プロセスを築く手助けになれば幸いです。

このガイドはご自由に共有・フォーク・リミックスして、ご自身のプロセスに取り入れてください。そして次回のブログでは、エージェントを活用した「テストファースト」ワークフローに深く踏み込んでいきますので、お楽しみに！

Happy building! 🚀