Busabase × CursorCursorのナレッジベース
指示はコードの近くに置き、意思決定、根拠、責任者はレビュー済み記録へ。知識をブランチ、エディタ、担当者の交代を越えて残します。
Rulesは指示
Cursor Rulesは行動を導くもの。事実を何でも詰め込むデータベースではない。
Cursorの公式文書はProject Rules、User Rules、Team Rules、AGENTS.mdを区別しています。これらはプロンプト時にAgentを導くためのものです。チームの意思決定には別の役割があり、根拠、責任者、日付、明確なレビュー履歴が必要です。
| 指示の種類 | 範囲 | 保存する内容 |
|---|---|---|
| Project Rules | リポジトリとファイル範囲 | アーキテクチャ規約と反復ワークフロー |
| User Rules | 個人のCursor環境 | 個人設定と対話スタイル |
| Team Rules | 管理されたCursorチーム | 組織共通のAgent動作 |
| AGENTS.md | リポジトリのディレクトリ | コードの近くに置く読みやすい運用指示 |
所有権の境界
RuleはCursorに何をすべきか伝える。記録はチームが何を承認したか示す。
両者を混ぜると、指示は履歴で膨らみ、意思決定はレビューに必要な構造を失います。チャットやブランチから情報を移す前に、簡単な昇格基準を使います。
ずれが始まる場所
同じリポジトリに、3通りの「決まったこと」が残る。
ローカルのAgentセッション、長期ブランチ、隣接リポジトリは別々の前提を持ちがちです。コードが動いていても、プロダクト、サポート、運用が古い判断で動くことがあります。
意思決定台帳
次のCursorセッションが信頼するために必要な最小項目を残す。
増え続けるプロジェクトノートより、小さなBaseの方が維持しやすくなります。判断と根拠を分け、古さも見えるようにします。
| フィールド | 答える問い |
|---|---|
| decision | チームは何を信頼してよいか？ |
| scope | どのリポジトリ、サービス、顧客に適用するか？ |
| evidence | どのテスト、リンク、記録が支えるか？ |
| owner | 誰が最新状態を保つか？ |
| effective_from | いつから有効か？ |
| revisit_when | 何が起きたら再検討するか？ |
レビューループ
Cursorには更新を提案させる。プロジェクトの事実を黙って書き換えさせない。
Cursorは作業に必要な承認済み記録を読みます。長期的な判断が変わったらChange Requestを送り、レビュー担当者がフィールド差分を確認して正式記録にするか決めます。
承認済み判断を読む
現在のリポジトリで作業
根拠付きでフィールド変更を提案
レビューして正式記録へマージ
接続方法は専用ページへ
このページは何を覚えるかを扱い、mcp.jsonの編集手順は繰り返さない。
グローバルまたはプロジェクト単位のMCP設定とOAuthには既存の接続ガイドを使います。Cursor公式のRules文書が指示の範囲を説明し、Busabaseはその指示が参照するレビュー済み記録を管理します。
導入前の質問
CursorナレッジベースのFAQ
Busabaseは.cursor/rulesやAGENTS.mdの代わりですか？
いいえ。Agentへの指示はCursor RulesかAGENTS.mdに残します。責任者と情報源が必要で、リポジトリを越えて使う事実や判断にBusabaseを使います。
Cursorの発見をすべて記録しますか？
いいえ。別の人やAgentが後で依存する情報だけを昇格させます。一時的な分析、推測、単発のデバッグ結果は一時情報のままで構いません。
Cursorは意思決定台帳を更新できますか？
付与された権限の範囲で可能です。共有知識にはChange Request権限を使い、Cursorは変更を提案し、レビュー担当者がマージを管理します。
Gitに残すべきものは？
コード、テスト、マイグレーション、リポジトリ指示、実装が所有する文書はGitに残します。同じ判断が他のリポジトリや業務システムにも影響するときにBusabaseが役立ちます。
1つのBaseを複数リポジトリで使えますか？
はい。明確なscopeフィールドと正確な根拠リンクを用意すれば、適用範囲を曖昧にせず再利用できます。