まず、コンテキストウィンドウとは何でしょうか?そして、それはCursorで効果的にコーディングすることとどのような関係があるのでしょうか? 少し視野を広げて説明すると、大規模言語モデル(LLM)は、大量のデータセットからパターンを学習することで、テキストを予測し生成するように訓練された人工知能モデルです。これは、あなたの入力を理解し、以前に見たものに基づいてコードやテキストを提案することで、Cursorのようなツールを動かしています。 トークンは、これらのモデルの入力と出力です。これらは、しばしば単語の断片である、LLMが一つずつ処理するテキストの塊です。モデルは文全体を一度に読むのではなく、前に来たトークンに基づいて次のトークンを予測します。 テキストがどのようにトークン化されるかを確認するには、このようなトークナイザーを使用できます。 Tokenizer

コンテキストとは?

Cursorでコード提案を生成する際、「コンテキスト」とは、モデルに提供される情報(「入力トークン」の形で)を指し、モデルはそれを使用して後続の情報(「出力トークン」の形で)を予測します。 コンテキストには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

Rules

ルールは、あなたやチームの他のメンバーがアクセスしたい長期記憶として考えるべきです。ワークフロー、フォーマット、その他の規約を含むドメイン固有のコンテキストを捉えることは、ルールを書くための優れた出発点です。 ルールは、/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の機能を拡張し、外部システムと接続しましょう。
  • コンテキストが不十分だと幻覚や非効率性につながり、関連性のないコンテキストが多すぎるとシグナルが希薄になります。最適な結果を得るために適切なバランスを保ちましょう。