まず、コンテキストウィンドウって何？ それが Cursor で効率よくコーディングすることとどう関係してるの？ 少し引いて説明すると、Large Language Model（LLM）は膨大なデータセットからパターンを学習し、テキストを予測・生成するように訓練された人工知能モデル。君の入力を理解して、過去に見たものに基づいてコードやテキストを提案することで、Cursor みたいなツールを動かしてる。 トークンはこうしたモデルの入出力。単語の一部であることが多いテキストの塊で、LLM はそれを一つずつ処理する。モデルは文全体を一度に読むわけじゃなく、直前までのトークンに基づいて次のトークンを予測する。 テキストがどうトークナイズされるか確認したいなら、このトークナイザーを使ってみてね。 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は、現在のファイル、他ファイルの意味的に類似したパターン、セッション内のその他の情報など、モデルが関連すると推定したコードベースの部分を自動で取り込む。 とはいえ、取り込めるコンテキストは膨大にある。だから、タスクに関係あるとわかっているコンテキストを手動で指定してあげると、モデルを正しい方向へうまく導けるよ。

​
@ 記号

明示的なコンテキストを渡す一番簡単な方法が @ 記号。どのファイル、フォルダ、サイト、その他どんなコンテキストを含めたいかがはっきりしてるときに便利。具体的であればあるほどいい。ここでは、コンテキストをもっとピンポイントに指定するコツをまとめたよ:
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の機能を拡張しよう。
  • コンテキストが不足しているとハルシネーションや非効率を招き、無関係なコンテキストが多すぎると信号が薄まる。最適な結果には適切なバランスが重要。