大規模なコードベースで作業するのは、小規模なプロジェクトとは異なる種類の課題を生む。Cursor自身のコードベースをスケールさせてきた経験と、巨大なコードベースを運用するユーザーからの知見の両方から、増す複雑さに対応するうえで有効なパターンをいくつか見つけた。 このガイドでは、大規模コードベースで役立つとわかったテクニックをいくつか順に紹介していく。

​
Chat を使って、慣れていないコードを素早くキャッチアップしよう

大規模なコードベースを読み解くのは、とくに初めて触れる場合は大変。目的の箇所を見つけるために grep したり、検索したり、あちこちクリックして回ることが多いよね。Chat を使えば、知りたいことをそのまま質問して探し物にたどり着けるし、動作のしくみも詳しく解説してくれる。 ここでは、Cursor のコードベースのインデックス化に関する実装の詳細を見つけるのを手伝ってもらい、理解しやすいようにサンプルまでお願いしている。

​
ドメイン固有の知識に関するルールを書こう

新しくコラボレーターをコードベースに迎えるとしたら、すぐに意味のある貢献を始められるように、どんなコンテキストを渡す？ この問いへの答えは、Cursorが理解するうえでも価値が高いはず。どの組織やプロジェクトにも、ドキュメントだけでは取りきれない潜在知識がある。Rulesをうまく使うのが、Cursorに全体像を確実に伝えるいちばんの方法だよ。 たとえば、新しい機能やサービスの実装手順を書いているなら、将来のために短いRuleとして残しておくのを検討してみて。
Boilerplate
---
description: Add a new VSCode frontend service
---

1. **Interface Definition:**
   - `createDecorator` を使って新しいサービスのインターフェースを定義し、エラーを避けるために `_serviceBrand` を必ず含めること。

2. **Service Implementation:**
   - 新しい TypeScript ファイルでサービスを実装し、`Disposable` を継承して、`registerSingleton` でシングルトンとして登録すること。

3. **Service Contribution:**
   - サービスをインポートして読み込むための contribution ファイルを作成し、メインのエントリポイントで登録すること。

4. **Context Integration:**
   - アプリ全体でアクセスできるように、コンテキストを更新して新しいサービスを含めること。
Cursorに守ってほしい共通のフォーマット規約があるなら、globパターンに基づいて自動で適用されるRulesを検討しよう。
Formatting
---
globs: *.ts
---
- パッケージマネージャーは bun を使う。スクリプトは [package.json](mdc:backend/reddit-eval-tool/package.json) を参照
- ファイル名は kebab-case を使う
- 関数名・変数名は camelCase を使う
- ハードコード定数は UPPERCASE_SNAKE_CASE を使う
- `const foo = () =>` より `function foo()` を優先
- `T[]` より `Array<T>` を使う
- デフォルトエクスポートではなく名前付きエクスポートを使う（例: `export const variable ...`, `export function ...`）

​
計画作成のプロセスに常に寄り添う

大きな変更では、精度が高くスコープが明確な計画づくりに普段より多めに思考を割くと、Cursor の出力は大きく良くなる。 同じプロンプトのバリエーションを何度か試しても欲しい結果が出ないなら、いったん引いて、同僚向けの PRD を書くつもりでゼロからより具体的な計画を作るのを検討しよう。たいていの場合、難しいのは何を変えるべきかを見極めることで、これは人間が得意なタスク。適切な指示があれば、実装の一部は Cursor に任せられる。 AI で計画作成プロセスを強化する方法のひとつが Ask モードの活用。計画を作るときは、Cursor で Ask モードをオンにして、プロジェクト管理ツール、社内ドキュメント、走り書きのメモなど、持っているコンテキストを全部投げ込もう。コードベースで含めたいと分かっているファイルや依存関係を洗い出す。統合したいコード片を含むファイルでもいいし、フォルダまるごとでもいい。 プロンプト例はこんな感じ:
Planning prompt
- create a plan for how we shoud create a new feature (just like @existingfeature.ts)
- ask me questions (max 3) if anything is unclear
- make sure to search the codebase

@Past Chats (my earlier exploration prompts)

here's some more context from [project management tool]:
[pasted ticket description]
モデルには、計画の作成、人間への質問によるコンテキスト収集、過去の探索プロンプトやチケット記述の参照を求めている。変更の意図を理解してより良い計画を統合できるので、claude-3.7-sonnet、gemini-2.5-pro、o3 のような思考系モデルを使うのがおすすめ。 ここから、実装に入る前に Cursor の助けを借りて計画を反復的に練り上げていこう。

​
目的に合ったツールを選ぼう

Cursorを効果的に使ううえで大事なのは、やりたいことに合ったツールを選ぶこと。何を実現したいかを考えて、フローを保てるアプローチを選ぼう。
ToolUse caseStrengthLimitation
Tabすばやい手動の変更完全なコントロール、高速単一ファイル
Inline Edit1ファイル内での限定的変更焦点を絞った編集単一ファイル
Chat規模の大きい複数ファイル変更文脈の自動収集、深い編集やや遅い、コンテキストが重い
それぞれのツールには得意領域があるよ:
  • Tab は、自分で舵を取りつつサクッと直したいときの定番
  • Inline Edit は、コードの特定セクションに絞って集中的に変えたいときに強い
  • Chat は、広い文脈をCursorに把握してほしい大きめの変更にぴったり
Chatモードを使うとき（少し遅く感じるかもだけど超強力）、良いコンテキストを渡して助けてあげよう。真似したい類似コードを指すには @files、プロジェクト構造の理解を深めるには @folder を使ってね。大きな変更は怖がらずに小さな塊に分けよう——新しいチャットを立て直すとフォーカスと効率を保てるよ。

​
まとめ

  • 変更範囲は絞って、一度に欲張らない
  • 可能なら関連するコンテキストを添える
  • Chat・Inline Edit・Tab はそれぞれ得意分野で使い分ける
  • 新しいチャットはこまめに作る
  • 計画は Ask mode、実装は Agent mode