ローカルインデクサーなしで、大規模リポジトリのコンテキストをAIエージェントに与える

大規模なリポジトリはコンテキストウィンドウに収まりません。そして、本物のmonorepoにノートパソコンのインデクサーを向けたことがあるなら、そこにも心地よくは収まらないことを知っているはずです──メモリが跳ね上がり、最初のインデックス作成に一時間かかり、それでもあなたのエージェントは次のセッションの開始時に、どのファイルが重要かをまだ推測しています。

よくある答えは、エディタの隣でインデクサーを動かすことで、一台のマシンに心地よく収まるリポジトリであれば、それは良い答えです。あなたのmonorepoがすでにCursorで高速にインデックスされていて、マップが必要な場所がそこだけなら、この記事に付け加えることは何もありません──読み飛ばしてください。

この記事は別のケース、つまりエージェントが大規模リポジトリの問い合わせ可能なマップを必要としていて、それを手に入れるためにローカルインデクサーを動かしたくないときの話です。

ローカルインデクサーが間違ったツールになるとき

ローカルインデックスは、コードがそれを問い合わせるマシンの上に存在することを前提としており、本物のmonorepoの規模では、この前提は単一のエディタの中でさえ限界に近づきます。リポジトリは、ノートパソコンでずっと温めておきたい大きさを単純に超えています。あるパッケージで作業している間、影響範囲は三つ先のディレクトリにあり、200万行のツリーの最初のコールドインデックス作成は、二度経験したいことではありません──あなたのマシンでも、そのツリーを一度もクローンしたことのないCIランナーでも。あるいは、チームメイトが自分のマシンで同じインデックスを苦労して通過するのを待たずに、あなたと同じマップを問い合わせられるべきかもしれません。

これらのどれも、良いエディタのインデクサーを捨てる理由にはなりません。それは、どのエージェントもMCPで問い合わせられるホスト型マップも持つべき理由です。

そして規模の問題は、「貼り付けるにはファイルが多すぎる」よりも根深いものです。大きなツリーでは、興味深い質問はほとんど「このファイルを見せて」ではありません──どのファイルか、どのシンボルか、どの呼び出し元か、どのテストかです。src/を一覧表示して最初の三件の結果を読むことから始めるエージェントは、apps/apiにあるハンドラーとpackages/sdkにある生成されたクライアントを、平然と見逃すでしょう。必要なのは、ツリー全体から構築され、ランク付けされ、引用された検索です。

「大規模リポジトリのコンテキスト」が実際に意味すること

ファイルをプロンプトに流し込むことはコンテキストではありません──それはツリーのより小さく、より劣ったコピーにすぎません。あなたのエージェントが実際に必要としているのは、質問をして引用付きの答えを受け取ることです。このシンボルはどこで定義されていて誰が呼び出しているか、今変更しようとしているモジュールに何が依存しているか、どのテストファイルがこの振る舞いをカバーしているか、そしてツリーが前四半期ではなく今どう見えるか。

これらの答えは、他人のリポジトリについてのモデルの記憶ではなく、あなたのリポジトリから構築されたインデックスから来る必要があり、そのインデックスはエージェントのコンテキストウィンドウ以外のどこかに存在する必要があります。この問題については、あなたのノートパソコン以外のどこかにも存在すべきです。

指示ファイルがあなたのためにできないことがもう一つあります。CLAUDE.mdとAGENTS.mdは慣習と振る舞いのための正しい場所ですが、200万行のツリーの、生きていて、ランク付けされた、問い合わせ可能なマップではありません。振る舞いにはルールを、事実にはリポジトリインテリジェンスを使ってください。

クラウドでマップを構築し、どのクライアントからも問い合わせる

MaguyvaはリモートのMCPコードベース・コンテキストレイヤーです。GitHubを接続し、リポジトリを選べば、あとはクラウドパイプラインがツリーを解析し、シンボルとグラフのエッジを構築し、ランク付けされたマップを維持している間、その場を離れられます──ローカルインデクサーは決して不要です。

コードをプッシュすると、変更されたファイルは段階的に解析され、グラフとランキングのレイヤーはスケジュールに従って再構築されます。無料プランでは毎日、有料プランでは毎時です。すべてのスナップショットにはタイムスタンプが付いているため、あなたのエージェントはどのバージョンのツリーを読んでいるかを判別できます。ここでの正直な限界は、同期されていないローカルの作業です。あなたの作業ツリーにしか存在せず、一度もプッシュされていない編集は、まだホスト型マップに入っていません。

次に、すでに使っているクライアントのMCP設定にAPIキーを追加して接続します。24の文書化されたMCPクライアント向けのセットアップガイドがあり、標準設定をサポートする他のMCP互換クライアントも接続できます。Cursorが本拠地であれば、Cursorページがその経路をたどります。同じサーバーがClaude Code、VS Code、Windsurf、Codex CLIなどにも応答します。

エディタを乗り換える必要はありません。検索、シンボル、依存関係分析、ファイル取得、リポジトリコンテキストにまたがる11のMCPツールというツールサーフェスを、あなたのエージェントに与えます。279以上の言語とテキストベースの技術をカバーしており、何年も前から単一言語ではなくなったmonorepoでは、これは思う以上に重要です。

答えは行番号付きのファイルパスとして、根拠のある形で返ってきます。セマンティック、構造、グラフ、テキストの検索がランク付けされた結果に融合されるため、「parseConfigに何が依存しているか」のような質問に対して、grepのダンプでも単一のセマンティックな断片でもなく、実際に重要な数か所が返ってきます。

具体的なやり方

会社全体をインデックスすることから始めないでください。実際に機能する経路はこうです。

1. すでによく知っているリポジトリを一つ選んでください。手で評価できるパッケージのほうが、手元にある最大のツリーよりも価値があります。
2. 無料で始めてください。リポジトリ3件、インデックス済み5万行、11ツールすべて、月間クエリ上限なし。代表的なリポジトリがそれより大きい場合、価格ページに、席数ではなくインデックス済みフットプリントによるワークスペース階層($0、$19、$49、$149)が掲載されています。
3. GitHubを接続し、最初のインデックス作成が終わるのを待ってください。ローカルでは何もコンパイルしていません。
4. MCPクライアントを接続してください──設定は数行です。Maguyvaはリモートのmcpサーバーなので、プラグインも拡張機能も、採用すべき二つ目のエディタもありません。
5. 確認できる質問を一つしてください。「parseConfigに何が依存しているか?」あるいは「ログインセッションの有効期限はどこで処理されているか?」引用されたfile.ext:lineの結果を開き、目の前のツリーと照らし合わせてください。
6. 引用がその照合を生き延びてから、初めてエージェントに編集させてください。

最初のリポジトリがうまく合っていて、あなたのツリーが大きいなら、インデックス済み行数と再構築の頻度に合わせてワークスペースを引き上げてください。人間とエージェントは同じユーザー数を共有します──Maguyvaは席数ではなくワークスペース単位で課金するため──ループに三体目のエージェントを加えても、あなたに追加コストはかかりません。

有効化テストは、ドキュメントがどの初回実行にも推奨するものと同じです。すでに知っているリポジトリをインデックスし、確認できる質問を尋ねる。大規模なリポジトリだからといってテストが変わるわけではありません。最初に選び間違えたファイルの代償が大きくなるだけです。

接続した後に注意すべきこと

三つのことに注意してください。鮮度:有料プランは毎時、無料プランは毎日再構築され、プッシュされていないローカルの作業はマップに入りません──それがあなたが受け入れるトレードオフです。範囲:アーカイブされたフォークすべてではなく、代表的なリポジトリの集合をインデックスしてください。無料枠は、その答えが保持する価値があるかどうかを見極めるために、意図的にそのくらいの規模に設定されています。そして検証:パスと行番号を引用できない大規模リポジトリのマップは、より遅い推測エンジンにすぎません。だから、パッチを出す前にエージェントに場所を示させてください。

それから、小規模なリポジトリで行うのと同じテストを実行してください。すでに知っているリポジトリをインデックスしてください。確認できる質問を尋ねてください。マップが本物なら、あなたのエージェントは冷えたツリーから出発するのをやめます。

// no laptop got hot building this map.