まず、コンテキストウィンドウとは何だろう？そして、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は、現在のファイル、他のファイルの意味的に類似したパターン、セッションからのその他の情報など、モデルが関連性があると推定するコードベースの部分を自動的に取り込みます。 しかし、取り込むことができるコンテキストは大量にあるため、タスクに関連することがわかっているコンテキストを手動で指定することは、モデルを正しい方向に導く有効な方法です。

​
@記号

明示的なコンテキストを提供する最も簡単な方法は@記号を使うことです。特定のファイル、フォルダ、ウェブサイト、その他のコンテキストを含めたいことが分かっている場合に最適です。より具体的であればあるほど良いです。コンテキストをより精密に扱う方法の詳細は以下の通りです：
記号例使用例欠点
@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の機能を拡張し、外部システムと連携させよう。
  • コンテキストが不十分だと幻覚や非効率性につながり、関係のないコンテキストが多すぎるとシグナルが薄まってしまう。最適な結果を得るために適切なバランスを保とう。