🤔

Cursorのコンテキスト管理を効率化する手順の検討(開発日記 No.065)

に公開

関連リンク

はじめに

昨日はDevSecOpsの考え方を取り入れた開発体制についてドキュメントを整備しました。これまでの数日間で、プロジェクト概要、コーディング規約、自動記録ガイドなど、いくつかの重要な開発ドキュメントが揃ってきました。
今日は、これらの蓄積されたドキュメントを、AIコーディングアシスタントであるCursorと連携させ、日々の開発作業(特にGitHub Issue単位のタスク)で効率的に活用する方法を考え、その手順をドキュメントにまとめることにしました。

背景と目的

Cursorは非常に強力なツールですが、新しい会話スレッドを開始するたびに、プロジェクトの背景知識やルールを改めて伝える必要がありました。特に、これまで作成してきた複数の開発ドキュメント(全体ガイドライン、コーディング規約、自動記録ガイドなど)の内容を毎回参照させるのは手間がかかります。
この手間を省き、かつCursorが一貫性を持って開発ルールや背景知識を理解した上で応答・コーディングしてくれるように、効率的なコンテキスト管理方法を確立することが目的です。具体的には、以下の状態を目指します。

  • 小さなタスク(GitHub Issue単位)ごとに会話スレッドを新規に立ち上げても、毎回背景説明やドキュメントを手動で読み込ませる必要がない。
  • Cursorが既存の開発ドキュメントの内容を自律的に理解し、タスク遂行に活用する。

検討内容

まず、どうすればCursorに毎回同じ情報を効率よく伝えられるか考えました。最初は、会話の最初に定型文として「これらのドキュメント(@file1.md, @file2.md...)を読んでね」と指示する方法を思いつきました。これはシンプルですが、毎回どのファイルを指定するか考えたり、コピー&ペーストしたりするのが少し面倒に感じました。

もっと良い方法がないか、Cursorの機能を調べてみることにしました。そこでCursorの公式ドキュメントを参照したところ、「Rules」機能と「@Docs」機能があることを発見しました。

  • Rules: プロジェクトごと、あるいはユーザーごとに、常に適用させたいルールやコンテキストを定義できる機能。特に「Project Rules」は .cursor/rules ディレクトリに設定ファイルを置くことで、プロジェクト固有のルールをバージョン管理できるようです。
  • @Docs: URLを指定して外部ドキュメントをCursorにインデックスさせ、@Docs シンボルで簡単に参照できる機能。

これらの機能を使えば、毎回手動でファイルを指定するよりもずっとスマートに、かつ自動的にコンテキストをCursorに与えられるのではないかと考えました。具体的には、常に参照してほしい基本的な開発ドキュメントはProject Rulesで指定し、頻繁に使う外部ドキュメントは@Docsに登録、そしてタスク固有のドキュメントだけを会話開始時に @file@Docs で指定するという方針です。

この方針に基づき、具体的な手順をまとめたガイドラインを作成することにしました。

実装内容

検討した結果を元に、Docs/dev-docs/Cursor_Context_Management_Guide.md という新しいドキュメントを作成しました。

最初は前述の通り、カスタム指示と @ コマンドの組み合わせを想定した内容(v1)を作成しました。しかし、公式ドキュメントを調査した結果、より洗練された方法として Rules と @Docs 機能の活用が有効だと判断し、ガイドラインの内容を大幅に更新しました(v2)。

更新後のガイドライン (v2) の主なポイントは以下の通りです。

  1. Cursor Rules の活用:

    • User Rules: 個人の基本的な設定(応答言語など)。
    • Project Rules: プロジェクト固有のルールや主要ドキュメントへの参照を .cursor/rules/ 配下の .mdc ファイルで定義。これにより、常に開発ガイドラインやコーディング規約などをCursorに意識させることが可能になります。
    • Project Rules の設定例として、主要な開発ドキュメントを参照させるルール (DocsReferenceRule.mdc) を具体的に示しました。
    # .cursor/rules/DocsReferenceRule.mdc の例
    ---
    description: 主要な開発ドキュメントの参照を促すルール
    alwaysApply: true # 常に適用する
    ---
    
    開発を進めるにあたり、以下の主要ドキュメントの内容を常に考慮してください。
    必要に応じて `@Docs/dev-docs/[ドキュメント名].md` で内容を確認してください。
    
    - @Docs/dev-docs/Overall_Development_Guidelines.md (全体的な開発ガイドライン)
    - @Docs/dev-docs/Coding_Standards.md (コーディング規約)
    - @Docs/dev-docs/Auto_Logging_Guide.md (自動記録ガイド)
    
    `Auto_Logging_Guide.md` に従い、会話ログは `Docs/dev-records/` 内の日次開発日記に記録してください。
    不明な点や複数の選択肢がある場合は、勝手に判断せず質問してください。
    GitHub Issue に基づいて作業する場合、その Issue の目的と受け入れ基準を理解するように努めてください。
    
  2. @Docs 機能の活用:

    • 頻繁に参照する外部ドキュメント(APIリファレンスなど)を登録し、@Docs で簡単に呼び出せるようにします。
  3. タスク開始時の指示の標準化:

    • 新しい会話スレッドを開始する際の、具体的な指示のテンプレートを定義しました。Rulesでカバーされる基本情報に加え、タスク固有のドキュメントを @ で指定します。
    Issue #[Issue番号] 「[Issueタイトル]」 の開発を開始します。
    
    Project Rules および User Rules が適用されているはずです。
    このタスクに特に関連するドキュメントとして以下を読み込んでください:
    @Docs/dev-docs/[タスク特有のドキュメント.md]
    @Docs/[登録した外部ドキュメント名] (もしあれば)
    
    これらのコンテキストを踏まえ、タスクを進めてください。不明な点があれば質問してください。
    

作成したガイドラインの全文は以下の通りです。

# Cursor コンテキスト管理ガイド (v2)

## 1. 目的

このガイドは、Cursor を使用した開発において、GitHub Issue などの小さなタスク単位で会話スレッドを新規に立ち上げる際に、毎回背景説明や関連ドキュメントを手動で読み込ませることなく、既存の開発ドキュメント(`Docs/dev-docs/` 配下など)の内容を Cursor が効率的に理解し、自律的に活用するための手順を定めることを目的とします。

これにより、以下の効果を目指します。

-   開発効率の向上(コンテキスト読み込み時間の短縮)
-   指示の精度向上(開発ルールや背景知識の反映)
-   開発ドキュメントの活用促進と一貫性の維持

## 2. 現状の課題

-   Cursor の各会話スレッドは基本的に独立しており、過去の会話履歴やワークスペース内のドキュメント知識を自動的に引き継がない。
-   新しいタスクを開始するたびに、関連する開発ドキュメント(コーディング規約、自動記録ガイド、プロジェクト概要など)を `@` コマンドなどで手動指定する必要があり、手間がかかる。
-   どのドキュメントを読み込ませるべきか、毎回判断が必要になる。

## 3. 提案する解決策:Cursor Rules と @Docs/@file の活用

Cursor が提供する **Rules 機能****@Docs 機能**、および従来の **@file 機能** を組み合わせることで、コンテキスト管理を効率化します。

**基本的な考え方:**

1.  **常に適用すべきルールや参照すべき基本ドキュメントは「Cursor Rules」で定義する。**
    -   **User Rules**: 個人の開発スタイルや常に守るべきグローバルなルール (例: 応答言語、基本的なコーディングスタイル) を定義します。 [参考: Cursor User Rules](https://docs.cursor.com/context/rules#user-rules)
    -   **Project Rules**: プロジェクト固有のルール、規約、参照すべき主要ドキュメントへのポインタなどを定義します。`.cursor/rules` ディレクトリに `.mdc` ファイルとして保存し、バージョン管理します。[参考: Cursor Project Rules](https://docs.cursor.com/context/rules#project-rules)
2.  **頻繁に参照する外部ドキュメントや社内ドキュメントは「@Docs」に登録する。**
    -   URL を指定してカスタムドキュメントを Cursor にインデックスさせ、`@Docs` シンボルで簡単に呼び出せるようにします。[参考: Cursor @Docs](https://docs.cursor.com/context/@-symbols/@-docs)
3.  **個別のタスクで特に重要なコンテキストは「@file」または「@Docs」で具体的に与える。**
    -   タスクに直接関連するローカルファイルは `@file` で、登録済みの外部ドキュメントは `@Docs` で指定します。

## 4. 具体的な手順

GitHub Issue など、新しい開発タスクを開始する際の具体的な手順は以下の通りです。

1.  **Cursor で新しい会話スレッドを開始します。**
2.  **User Rules の設定(初回のみ、または更新時):**
    -   `Cursor Settings > Rules` で、個人用の User Rules を設定します。
        ```text
        # 例:
        応答は常に日本語でお願いします。
        技術的な説明は簡潔に、必要であれば参考リンクを示してください。
        ```
3.  **
GitHubで編集を提案

Discussion