大規模なコードベースを扱うと、小規模プロジェクトとは異なる新たな課題が出てくる。Cursor 自身のコードベースをスケールしてきた経験と、巨大なコードベースを運用しているユーザーから得た知見から、増す複雑さに対処するための有用なパターンをいくつか見つけてきた。 このガイドでは、大規模コードベースで役立つことがわかったテクニックをいくつか紹介していく。

​
Chat を使って不慣れなコードを手早く把握しよう

大規模なコードベースを読み解くのは、特に初見だと骨が折れる。目的の箇所を見つけるために grep したり検索したり、あちこちクリックして回ることになる。Chat を使えば、知りたいことを質問して探し当てられるし、仕組みについての詳しい解説も得られる。 ここでは、Cursor のコードベースのインデックス化の実装詳細を探すのを手伝ってもらい、理解しやすいようにサンプルまで出してもらっている。

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

新しいコラボレーターをコードベースにオンボードするとしたら、意味のある貢献をすぐ始められるように、どんな背景情報を共有する？ この問いへの答えは、Cursorにとっても貴重な情報。どんな組織やプロジェクトにも、ドキュメントだけでは取り切れていない暗黙知がある。ルールを効果的に使うことが、Cursorに全体像を正確に把握してもらういちばん確実な方法だよ。 たとえば、新機能やサービスの実装手順を書いているなら、将来のためにそれを残す短いルールも併せて用意しておこう。
ボイラープレート
---
description: 新しい VSCode フロントエンドサービスを追加する
---

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

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

3. **サービスの組み込み:**
   - サービスをインポートしてロードするための貢献（contribution）ファイルを作成し、メインのエントリポイントで登録する。

4. **コンテキスト統合:**
   - アプリ全体からアクセスできるよう、新しいサービスをコンテキストに追加する。
共通のフォーマットパターンがあって、それをCursorに確実に守らせたいなら、globパターンに基づくルールの自動適用を検討してみて。
フォーマット
---
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モードをオンにして、プロジェクト管理ツールや社内ドキュメント、頭の中のメモでも何でも、持っているコンテキストを全部流し込もう。コードベースのどのファイルや依存関係を取り込むか、あらかじめ含めたいものを洗い出しておくといい。統合したいコード片を含む特定のファイルでもいいし、場合によってはフォルダ丸ごとでもOK。 次はプロンプトの例:
計画用プロンプト
- 新機能の作り方について計画を立てて（@existingfeature.ts と同様に）
- 不明点があれば質問して（最大3件まで）
- コードベースを必ず検索して

@Past Chats（過去の探索用プロンプト）

[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 は、広いコンテキスト理解が必要な大きな変更にぴったり
Chat モードを使うとき（体感は少し遅めだけど、とても強力）、良いコンテキストを渡してうまく使おう。真似したい似たコードを指すなら @files、プロジェクト構造を把握させるなら @folder を使ってね。大きな変更は遠慮せず小さく分割しよう。新しいチャットに分けて進めると、フォーカスと効率を保てる。

​
Takeaways

  • 変更範囲は絞って、一度にやりすぎない
  • 可能な限り関連するコンテキストを共有する
  • Chat、Inline Edit、Tab はそれぞれの得意分野で使い分ける
  • チャットはこまめに新規作成する
  • Ask モードで計画し、Agent モードで実装する