ついてくるコンテキスト

Cursorのインデクサーは、Cursorの中では優秀です。タブ補完、インライン編集、チャット、そしてそのウィンドウの中のエージェントは、すでにCursorが開いているワークスペース用に運用しているプロジェクトインデックスの上に乗っています。Cursorがコードを書く唯一の場所で、そのインデックスがすでに正しいファイルを見つけてくれるなら、そこに留まってください。それが正直な「そこに留まる」ケースであり、このページの最初の一文になる資格があります。

この記事は、よくある一週間のもう半分についての話です。同じリポジトリがClaude Codeでも開かれ、Codex CLIから質問され、二台目のマシンでレビューされ、CIで動くエージェントから問い合わせられます。問題は「どちらのインデクサーが優れているか」ではありません。問題は、あるウィンドウでエージェントが信頼するマップが、次のウィンドウで信頼するマップと同じかどうかです。

Maguyvaが、そのついてくるマップです。リモートのMCPコードベース・コンテキストレイヤーです。エージェントは他のMCPツールを問い合わせるのと同じ方法でこれを問い合わせます。結果は行番号付きのランク付けされたパスとして返ってきます。Cursorはエディタのままです。動くのはコンテキストのほうです。

Cursorのインデクサーは何のためにあるのか

Cursorの組み込みインデックスは、モデルの生のコンテキストウィンドウに収まるものだけに頼るのではなく、エディタ内のチャット、エージェント、検索が関連コードを取得できるようにするために存在します。それはIDEにとって正しい設計です。このインデックスはCursorにネイティブなものです。MCPサーバーではなく、他のどのクライアントからもアクセスできません。

その仕組みは、本稿執筆時点のCursorの公開ドキュメントとCursor自身の説明によれば次のとおりです。主要な検索経路は、もはやクラウドのエンベディングインデックスではありません。Cursorのチームはコミュニティフォーラムで、現在のモデルは生きたツリーを自力でも十分に探索できるため、専用のセマンティック/エンベディングベースの検索はgrepベースの検索に取って代わられて縮小されていると述べています。その代わりにあるのがInstant Grepで、n-gram、転置リスト、ブルームフィルタから構築されたローカル検索インデックスであり、メモリマップされたルックアップテーブルに保持されるため、問い合わせはサーバーではなく開発者自身のマシン上で解決されます。

インデックス自体は、リポジトリ自身の.git/cursor/ディレクトリの中に、特定のgitコミットに固定されて存在します。そのコミット以降の変更は再スキャンを引き起こすのではなく、その上に層として積み重なり、ローカルの状態が構築時の対象から大きく乖離したときにだけインデックスは再構築されます。.gitの中にあるため、追跡もプッシュも一切されません──フォルダを削除すれば、インデックスは消えます。gitで追跡されているコンテンツだけが対象になるため.gitignoreは構造上尊重され、.cursorignoreは読み取り経路で強制されます。もうこの経路にはサーバー側のエンベディングのステップも、リモートのベクターデータベースもありません。以前のドキュメントは、チャンクの暗号化、Merkleツリーによる同期、チームメイト間でのインデックス再利用といった、クラウド支援型の設計を説明していましたが、Cursor自身のチームはその設計が縮小されつつあると述べているため、本稿はもうそれを現状として説明しません。

エディタ内で際立った強みは、CursorのExploreサブエージェントです。より高速なモデルを使い、自身のコンテキストウィンドウの中で複数の並列検索を発射し、関連する結果だけを返すことができるため、メインの会話が検索結果で膨れ上がることがありません。これはエディタ内部での本物の強みです。維持してください。

マルチルートワークスペースもサポートされています。開いている各フォルダのコンテキストがAgentに提供されます。worktreeのような一部のgit依存機能はマルチルート設定では無効になり、Cloud Agentsはマルチルートワークスペースをまったくサポートしません。

これらのどれも、Cursorを離れる理由にはなりません。それは、自分が生きている場所で優れているマップについての正確な記述です。

「ついてくる」が実際に意味すること

マップがついてくるのは、同じ質問が複数のクライアントから、開いて確認できる引用付きで、同じ種類の答えを返すときです。

• Cursorで:「parseConfigはどこで定義されていて、誰が呼び出しているか?」
• Claude Codeで、同じリポジトリに対して:同じ質問。
• Codex CLIで、Cursorのウィンドウを一度も開いたことのないレビュー用マシン上で:同じ質問。
• MCPを話すCIエージェントで:同じホスト型スナップショットに対して、同じ質問。

各サーフェスが自分専用のプライベートインデックスを構築するなら、あなたが持っているのは一つのマップではありません。互いにずれていく複数のキャッシュです。エディタのインデックスはディスク上のツリーについては最新かもしれません。CLIセッションは一日遅れているかもしれません。CIジョブは別のチェックアウトを見ているかもしれません。それでもエージェントは自信満々に聞こえ続けます。

Cursorのインデクサーはそれを解決するようにはできていません。エディタの中に生きているため、それが構築するコンテキストはそのエディタのためのものです。CLIやCIパイプライン、別のエディタも必要とする読者は、それらのサーフェス用に別のツールが必要です。それは範囲の事実であり、欠陥ではありません。Maguyvaがその別のツールです。

Cursorのインデクサーの公開された言語数は、本稿が使える資料には明記されていません。Maguyvaは279以上の言語とテキストベースの技術を公開しています。Cursorの価格もここには転載しません。彼らの価格ページを参照してください。Maguyvaは席数ではなくワークスペース単位で課金し、インデックス済みのフットプリントとワークスペースの規模に応じて$0、$19、$49、$149の公開プランがあります。

一つのホスト型マップ、すべてのMCPクライアント

MaguyvaはリモートのMCPサーバーです。GitHubを接続し、リポジトリを選ぶと、クラウドパイプラインがシンボルとグラフのエッジ、そしてランク付けされたマップを構築します。すでに使っているクライアントのMCP設定にAPIキーを追加します。Maguyvaには、Cursorを含む24の文書化されたMCPクライアント向けのセットアップガイドがあり、標準的なMCP設定をサポートする他のMCP互換クライアントにも接続できます。

Cursorが作業場所であれば、Cursorセットアップページがエディタ固有の経路です。同じサーバーがClaude Code、VS Code、Windsurf、Codex CLIなどにも応答します。エディタを乗り換える必要はありません。すべてのエージェントに、検索、シンボル、依存関係分析、ファイル取得、リポジトリコンテキスト、決定論的なユーティリティワークフローにまたがる11の顧客向けMCPツールという、同じツールサーフェスを提供します。セマンティック、構造、グラフ、テキストの検索がランク付けされた結果に融合されます。

それがポータビリティの利点です。今朝Cursorで確認した引用は、今晩Codex CLIが返す引用と同じ形をしています。ファイルパスと行番号。開いてみてください。間違っていれば、それが見えます。正しければ、次の編集には着地する場所ができます。承認された主張は、幻覚編集が減ることであり、すべての編集が正しいという約束ではありません。

鮮度は公開されています。スナップショットにはタイムスタンプが付いているため、エージェントはどのバージョンのツリーを読んでいるかを知ることができます。再構築の頻度は、無料プランでは毎日、有料プランでは毎時です。正直な限界は、同期されていないローカルの作業です。作業ツリーにしか存在しない編集は、まだホスト型マップに入っていません。この限界はどのクライアントから問い合わせても同じであり、それこそがポイントです。クライアント間のずれは、もはや二つ目の隠れた限界ではありません。

ドキュメントは、どのクライアントにも当てはまる有効化ループを示しています。すでに知っているリポジトリをインデックスし、クライアントを接続し、確認できる質問を一つ尋ねる。Cursorで一度それをやってください。実際にレビューの日に使うCLIからもう一度やってください。両方の答えが同じハンドラーを引用していれば、マップはついてきたことになります。

二つのマップが並び立つ方法

両方を使ってください。比較ページ的な意味での代替関係ではありません。

1. ディスク上のプロジェクトのために、Cursorのインデクサーを有効にしたままにしてください。Explore、Instant Grep、そしてエディタ内のエージェントにそれを使わせてください。このループはネイティブで高速です。
2. Cursorに、MaguyvaをMCPサーバーとして追加し、同じセッションからホスト型のワークスペースマップにも問い合わせられるようにしてください。CursorはMaguyvaの文書化されたクライアントです。片方のインデックスを選んでもう片方を消す、という話ではありません。
3. リポジトリに触れるClaude Code、Codex CLI、その他どのMCPクライアントにも、同じMaguyvaサーバーを追加してください。一つのAPIキーの形。一つのワークスペース。
4. CIエージェントがMCP互換であれば、同じサーバーを指させてください。ノートパソコンが読んだのと同じタイムスタンプ付きスナップショットを読むことになります。

エディタのインデックスは、「今このウィンドウのディスク上に何があるか」に対する最良のツールであり続けます。ホスト型マップは、「今日それに触れるすべてのエージェントにとって、このワークスペースがどう見えるか」に対する最良のツールです。この二つの文は競合しません。

ワークスペースのクォータは価格ページで公開されています。リポジトリ数、インデックス済み行数、ユーザー数を、ワークスペース単位で課金します。エージェントと人間は同じユーザー数を共有します。すでに評価できるリポジトリで無料で始めてください。引用がツリーとの接触を生き延びてから、ワークスペースを引き上げてください。

このページが主張しないこと

Cursorのインデクサーが弱い、不完全だ、あるいはエディタを乗り換える理由だ、とは主張しません。本稿の最初の一文はその逆です。

MaguyvaがInstant GrepやExploreサブエージェントを置き換える、とは主張しません。それらはCursorの機能です。Cursorの中に留まります。

どちらの製品についても、言語数、レイテンシの数値、トークン節約量を捏造しません。分からない数値は公開されないままにします。

プッシュされていないローカルの作業がホスト型マップに入っているふりはしません。タイムスタンプ付きスナップショットがその限界を可視化します。それを取り除くわけではありません。

テストはありふれています。すでに知っているリポジトリをインデックスしてください。確認できる質問を、まずCursorで、次に二つ目のMCPクライアントで尋ねてください。ついてくるコンテキストとは、両方の場所で同じ引用が得られることです。

// same map, wherever you opened it.