クイックサマリー: マルチリポジトリ開発で、Cursor や Claude Code などのAIコーディングエージェントに「別リポジトリにある仕様書」を渡す方法は、大きく「全部インデックスする」「都度読ませる」「検索だけ外部に出す」の3つに整理できます。本記事ではZennで公開された解説記事をもとに各アプローチのトレードオフを比較し、MCP対応CLI（Claude Code / Cursor 等）ですぐ試せる GitHub MCP Server（リモート版）の設定手順まで紹介します。
「仕様書はちゃんと書いてあるのに、いま開いているワークスペースの外にあるせいでAIに届かない」——マイクロサービス的にリポジトリを分けて開発していると、この壁に何度もぶつかりませんか？サービスAのリポジトリをCursorで開いているのに、参照したい仕様書はサービスBのリポジトリにある。AIコーディングが日常になった今、この「あと一歩届かない」状態は多くの開発者が抱える課題です。
本記事では、Zennの記事「全部インデックスするか、全部読ませるか」（shida_dev氏）で整理されたジレンマを出発点に、実務で選べる選択肢を解説します。
- 「全部インデックス」vs「全部読ませる」のトレードオフの正体
- 第3の選択肢となる GitHub MCP Server（リモート版）の設定手順
- GitHubコード検索の制約（レートリミット・対象範囲）という落とし穴
- .cursor/rules / CLAUDE.md を使った実開発フローへの組み込み方
なお、本記事で扱う GitHub MCP Server はMITライセンスのOSSです。一方、記事著者が開発中の「Repospec」は未公開のクローズドなサービス（2026年7月時点でLPのみ）である点をあらかじめ明記しておきます。
「全部インデックスするか、全部読ませるか」——ジレンマの正体
選択肢A: ワークスペースに追加して全部インデックスする
Cursor のマルチルートワークスペース機能で、仕様書のあるリポジトリごとワークスペースに追加する方法です。元記事の著者は実際にこの方法を試したうえで、「今の作業に関係ない別リポジトリのファイルが検索に引っかかり、修正対象の取り違えやトークン量の増加が起きた」と振り返っています。仕様書を数ファイル読みたいだけの用途には過剰、というのが実体験ベースの評価です。
公平のために補足すると、Cursor は2026年4月のリリースで、1つのエージェントセッションが複数フォルダのワークスペースを対象にクロスリポジトリの変更を行えるようになっています（公式changelogより）。「フロントとバックエンドをまたいで修正する」用途には確実に改善されていますが、「開いたフォルダがインデックス対象になる」という構造自体は変わりません。
選択肢B: ワークスペースに追加せず、都度読ませる
rules ファイルに仕様書のパスを書いておき、必要なときにAIにファイルを取りに行かせる方法です。ファイルパスが分かっているなら十分機能します。課題は「あれ、どこかに書いた気がする」というケースです。パスが不明な以上、AIは候補ファイル群を読んでから探すことになり、検索のために全文がコンテキストに載ってトークン消費が重くなります。
つまりこのジレンマは「ノイズを許容してインデックスするか、トークンを払って全読みさせるか」の二択に集約されます。
第3の選択肢: GitHub MCP Server（リモート版）を設定する
ここで有力になるのが GitHub MCP Server です。GitHub Changelog によると、GitHubがホストするリモート版は2025年9月にGA（一般提供開始）しています。OAuthで一度認証するだけで使え、Dockerコンテナのローカル起動もPAT（Personal Access Token）の管理も不要です。プライベートリポジトリのファイルも、ローカルcloneなしで取得できます。
元記事の著者は「ローカルで起動する必要がある」という古いAI調査結果を信じてこの選択肢を候補から外し、自作を始めてしまったと率直に書いています。AIのリサーチは前提が古いことがある——一次情報に当たる重要性を示す実例と言えます。
Claude Code での設定
Claude Code では、リモート版のエンドポイントをHTTPトランスポートで登録します。
claude mcp add --transport http github https://api.githubcopilot.com/mcp/初回接続時に /mcp コマンドからOAuth認証を完了させれば準備完了です。正確なエンドポイントや最新の手順は、公式リポジトリのREADMEで確認してください。
Cursor での設定
Cursor では MCP 設定ファイル（mcp.json）にリモートサーバーを追記します。
{
"mcpServers": {
"github": {
"url": "https://api.githubcopilot.com/mcp/"
}
}
}動作確認とカスタマイズ
設定後、エージェントに「org/service-b リポジトリの docs/spec/auth.md を取得して要約して」のように依頼し、ワークスペース外のファイルが読めれば成功です。公式READMEでは、利用するツールセットを必要な範囲（リポジトリ読み取りのみ等）に絞る方法も案内されているため、書き込み系ツールを使わない場合は絞り込みを推奨します。
それでも残る「検索」の使いづらさと Repospec という試み
GitHub MCP Server にはコード検索ツールがあり、自分がアクセスできるプライベートリポジトリも横断検索できます。ただし公式ドキュメントに明記された仕様として、日常使いには次の制約があります。
- 検索対象はデフォルトブランチのみ・384KB未満のファイルのみ: ブランチで仕様を書き分けている場合は対象外になります
- コード検索APIのレートリミットは認証済みでも毎分10リクエスト: 通常のAPI（毎時5,000リクエスト）とは別枠で、試行錯誤で検索クエリを何度も投げがちなAIエージェントにはかなり狭い枠です
- 検索→本文取得で最低2往復: 検索結果はメタデータ中心のため、本文を読むには追加リクエストが必要です
どれも「できない」ではなく「日常使いには勝手が悪い」という類の話ですが、「どこかに書いた気がする」は1日に何度も起きます。そこで元記事の著者が開発しているのが Repospec です。仕様書の本文をPostgreSQLに置いて検索をDBクエリ1発で行い、AIにはマッチ箇所の前後数行のスニペットだけを返す設計で、「読み取り専用の小さな窓」に徹するため編集機能やバージョン管理は意図的に持ちません。ただし2026年7月時点ではLPのみの未公開サービスで、著者自身も「効果を大きく語る段階ではない」と述べています。
実際の開発フローに組み込む方法
.cursor/rules / CLAUDE.md に仕様書の所在を列挙する
元記事でも「.cursor/rules に仕様書リポジトリのパスを書いて GitHub MCP Server で読ませる。それで事足りるなら追加ツールは要らない」と結論づけられています。Claude Code なら CLAUDE.md に同じ内容を書けば、セッション開始時から仕様書の所在をAIが把握できます。
# CLAUDE.md（抜粋）
## 参照仕様書（GitHub MCP経由で取得すること）
- 認証仕様: org/service-b リポジトリ docs/spec/auth.md
- API規約: org/api-guidelines リポジトリ README.md
- DBスキーマ: org/service-b リポジトリ docs/spec/schema.mdこれにより「実装前に認証仕様を確認して」と指示するだけで、AIがワークスペース外の仕様書を取得してから作業に入るフローが成立します。パスを覚えていられる規模なら、この構成が最小コストです。
職種・状況別のユースケース
- 個人開発者（マイクロサービス志向）: 元記事の著者と同じケースです。「完成させられるサイズに切る」ためにリポジトリを分割した結果、仕様書が分散した状況で最も効果を発揮します
- 受託開発エンジニア: 顧客案件ごとにリポジトリが分かれ、共通のコーディング規約リポジトリを参照する構成なら、規約をインデックスせずMCP経由で都度取得することでノイズを避けられます
- SaaS開発チーム: フロントエンド・バックエンド・インフラでリポジトリが分かれている場合、API仕様書だけをrulesに列挙しておけば、各リポジトリの作業中に他リポジトリの仕様を参照できます
3つのアプローチ比較表
| 手法 | 対応ツール | ライセンス・提供形態 | 状況（2026年7月時点） | 特徴 |
|---|---|---|---|---|
| マルチルートワークスペース（全部インデックス） | Cursor 等 | プロプライエタリ | 2026年4月にクロスリポジトリ編集が強化 | 設定不要で横断修正に強い。ただしノイズ混入とトークン増が起きやすい |
| rules + GitHub MCP Server（都度読み込み） | Claude Code / Cursor 等MCP対応クライアント | MIT（OSS） | リモート版が2025年9月GA | OAuthのみでプライベートリポジトリも取得可。パスが分かる用途はこれで十分 |
| Repospec（検索の外部化） | MCP対応クライアント | クローズド・未公開（LPのみ） | 開発中 | 仕様書限定の横断検索とスニペット返却に特化。実績は未知数 |
注意点・制約・セキュリティ
- データの流れを理解する: リモート版 GitHub MCP Server はOAuthで認可した範囲のリポジトリ内容を取得し、その内容はAIモデルへのプロンプトに含まれます。機密性の高いプライベートリポジトリを扱う場合は、組織のポリシーと利用するAIサービスのデータ取り扱い規約を先に確認してください
- 権限は最小限に絞る: 仕様書の参照が目的なら、読み取り系ツールセットのみを有効化する構成が安全です
- 検索の制約は仕様: デフォルトブランチのみ・384KB未満・毎分10リクエストという制約はGitHub公式ドキュメントに明記された仕様であり、回避はできません
- AIの調査結果を鵜呑みにしない: 元記事の著者は、AIの古い調査結果（「ローカル起動が必要」）を信じて自作を始めた経緯を告白しています。導入判断の前に公式の一次情報を確認する習慣が、遠回りを防ぐと考えられます
- Repospecは未公開: 仕様書本文を外部DBに置く設計のため、公開された際はデータの保存先・暗号化方針を確認したうえでの利用をおすすめします
まとめ
- マルチリポジトリ開発でAIに仕様書を渡す方法は「全部インデックス」「都度読ませる」「検索だけ外部化」の3択に整理でき、それぞれノイズ・トークン・仕組みの手間というコストを払うトレードオフになっています
- ファイルパスを把握できる規模なら、.cursor/rules や CLAUDE.md にパスを列挙し、リモート版 GitHub MCP Server（2025年9月GA・OAuthのみで利用可）で読ませる構成が最小コストです
- 「リポジトリが複数」×「どこに書いたか覚えていない」が日常化したら、GitHubコード検索の制約（毎分10リクエスト等)を踏まえ、検索を外部に出す選択肢も視野に入ってきます
まずは自分のリポジトリ構成で「パスを覚えていられる規模かどうか」を見極めるところから始めてみてください。GitHub MCP Server の詳しい設定は公式リポジトリのREADMEを、Claude Code / Cursor 側のMCP設定は各公式ドキュメントを参照すると、数分で試せる構成が確認できます。
コメント