まず、コンテキストウィンドウって何？それが Cursor で効率よくコーディングすることとどう関係してる？ 少し引いて説明すると、Large Language Model（LLM）は大規模データセットからパターンを学習し、テキストを予測・生成するように訓練された人工知能モデル。これまでに見たものに基づいて入力を理解し、コードやテキストを提案することで Cursor のようなツールを動かしてる。 トークンはこうしたモデルの入出力。単語の一部などのテキスト断片で、LLM はこれを1つずつ処理する。モデルは文章全体を一度に読むわけじゃなく、直前までのトークンに基づいて次のトークンを予測する。 テキストがどうトークナイズされるか確認したいなら、このトークナイザーを使ってみて。 Tokenizer

​
コンテキストって何？

Cursorでコード提案を生成するとき、「コンテキスト」とはモデルに渡される情報（「input tokens」の形）を指し、モデルはそれを使って後続の情報（「output tokens」の形）を予測する。 コンテキストには2種類ある:
  1. インテントコンテキスト は、ユーザーがモデルに何をしてほしいかを定義する。たとえば、システムプロンプトはモデルにどう振る舞ってほしいかを示す高レベルな指示として機能する。Cursorで行われる多くの「プロンプト作成」はインテントコンテキストにあたる。「そのボタンを青から緑に変えて」は明示的なインテントの例で、これは指示的。
  2. ステートコンテキスト は、現在の状態を記述する。エラーメッセージ、コンソールログ、画像、コード片をCursorに提供するのは、状態に関するコンテキストの例。これは記述的で、指示的ではない。
この2種類のコンテキストが現在の状態と望ましい将来の状態を合わせて示すことで、Cursorは有用なコーディング提案を行えるようになる。

​
Cursor でコンテキストを提供する

モデルに関連性の高いコンテキストを渡せば渡すほど、出力は有用になる。Cursor で十分なコンテキストが与えられない場合、モデルは関連情報なしで解こうとしてしまう。典型的には次のような結果になる:
  1. パターンがないのにパターンマッチしようとして幻覚が生じ、想定外の結果になる。これはコンテキストが不足しているとき、claude-3.5-sonnet のようなモデルで頻繁に起こりうる。
  2. Agent がコードベース検索、ファイルの読み取り、ツール呼び出しによって自力でコンテキスト収集を試みる。強力な思考系モデル（claude-3.7-sonnet など）はこの戦略でかなり進められるが、最初に適切な初期コンテキストを与えるかどうかで以後の軌道が決まる。
良いニュースとして、Cursor はコアにコンテキスト認識を備え、ユーザーの介入を最小限にするよう設計されている。モデルが関連すると見なしたコードベースの部分、たとえば現在のファイル、他ファイルの意味的に類似したパターン、セッション由来のその他の情報を Cursor が自動で取り込む。 とはいえ取り込めるコンテキストは多いから、タスクに関連するとわかっているコンテキストを手動で指定するのは、モデルを正しい方向に導くうえで有効だよ。

​
@-symbol

明示的なコンテキストを渡すいちばん簡単な方法が @-symbol。含めたいファイルやフォルダ、サイトなどのコンテキストがはっきり分かっているときに便利。具体的であればあるほど良い。コンテキストをもっとピンポイントに扱うためのガイドは次のとおり:
SymbolExampleUse caseDrawback
@code@LRUCachedFunction生成する出力に関係する関数・定数・シンボルがどれか分かっているときコードベースについて幅広い知識が必要
@filecache.ts読む/編集すべきファイルは分かるが、ファイル内の正確な位置は不明ファイルサイズ次第で、タスクに無関係なコンテキストが多く含まれる可能性がある
@folderutils/フォルダ内のすべて/大半のファイルが関連しているときタスクに無関係なコンテキストが多く含まれる可能性がある
Context Menu

​
ルール

ルールは、自分やチームのメンバーが長期的に参照できる「長期記憶」と考えるといい。ワークフローやフォーマット、その他の慣習といったドメイン固有のコンテキストを記録するのは、ルール作成の良い出発点になる。 ルールは、既存の会話から /Generate Cursor Rules を使って生成することもできる。長いやり取りでプロンプトを多用していたなら、あとで再利用したくなる有用な指示や一般的なルールが見つかるはず。 Rules

​
MCP

Model Context Protocol は、Cursor にアクションの実行や外部コンテキストの取り込みといった機能を追加できる拡張レイヤーだよ。 開発環境によって使いたいサーバーの種類は変わるけど、特に役立つのは次の2カテゴリ:
  • 内部ドキュメント: 例: Notion、Confluence、Google Docs
  • プロジェクト管理: 例: Linear、Jira
もし API 経由でコンテキスト取得やアクション実行ができる既存ツールがあるなら、そのための MCP サーバーを作れるよ。ここに MCP サーバーの作り方 の短いガイドがあるよ。 MCP

​
自己収集コンテキスト

多くのユーザーが取り入れている強力なパターンが、Agent に短期間使い捨てのツールを書かせ、それを実行して追加のコンテキストを集める方法。とくに、実行前にコードをレビューする human-in-the-loop 型のワークフローで効果的。 たとえば、コードにデバッグ用のステートメントを追加して実行し、モデルに出力を確認させると、静的解析では得られない動的なコンテキストにアクセスできる。 Python では、次のように Agent に指示するといい:
  1. コードの適切な箇所に print(“debugging: …”) ステートメントを追加する
  2. ターミナルでコードやテストを実行する
Agent はターミナル出力を読み取り、次のアクションを決める。ポイントは、静的なコードだけでなく、実際の実行時の挙動へのアクセスを Agent に与えること。 Self-Gathering Context

​
まとめ

  • コンテキストは効果的なAIコーディングの基盤で、意図（何をしたいか）と状態（何があるか）で構成される。両方を提供すると、Cursorがより正確に予測できる。
  • 自動コンテキスト収集だけに頼らず、@記号（@code、@file、@folder）を使ったピンポイントなコンテキスト指定で、Cursorを的確に誘導する。
  • 繰り返し使う知識はルールとして体系化してチームで再利用し、Model Context Protocolで外部システムと接続してCursorの機能を拡張する。
  • コンテキストが不十分だとハルシネーションや非効率を招き、無関係なコンテキストが多すぎるとシグナルが希薄化する。最適な結果のために適切なバランスを取る。