ウィンドウを複数開いて、各ウィンドウでひとつずつレポジトリを開き、切り替えながら開発している——そんな状況はありませんか？
複数レポ開発の辛さとして、次のようなことが挙げられます。
- Backend / BFF / Frontend など、レポジトリごとにエディタを切り替える手間
- 横断的な検索や理解がしづらい
- 設計書やAPI仕様など、ドキュメントとコードが別々で「見比べる」のが大変
さらに AIにコンテキストが渡せない問題 もあります。
- ウィンドウが分かれていると、BFFのスキーマやAPI仕様をFrontendの実装時にAIに渡しづらい
- 設計ドキュメントを都度コピペするのは非効率で、トークンも無駄になりがち
- 結果として「設計と実装の一貫性」をAIに任せづらく、手作業の確認が増える
このような状況にある同僚からも「これってどうにかできないですかね？」という声がありました。
この声に応える形で、本記事ではその解決策をまとめます。
解決策の全体像
ここで一旦、構成の全体像を図にしておきます。Cursor Workspace で複数レポ＋ドキュメントを1ウィンドウにまとめ、Obsidian でMarkdownの設計・仕様を書き、Git で共有する構成です。
- 開発環境: Cursor の 1 ウィンドウ（Workspace）に、複数レポ＋ドキュメントを同居させる。
- 作成・編集: 設計・仕様は Obsidian で書き、コードは Cursor で触る。同じドキュメントを Workspace に含めてコンテキストとして渡せる。
- 共有: ドキュメントもコードも Git で管理し、チームで共有・自動Pull しやすい。
この構成では、ドキュメントを Markdown + Git で扱うことを前提にしています。
その結果、複数人での情報共有がしやすいことと、AIにコンテキストを渡しやすいことの両方が実現しやすくなります。
実践: Workspace 設定
VSCode時代からのWorkspaceの活用
VSCodeの公式ドキュメントにもあるように、Workspaceは単なる「フォルダを開く」以上の機能を持っています。
- Workspaceの設定: プロジェクト単位でエディタの挙動をカスタマイズできる
- タスクとデバッガー: ワークスペースに対してのみ有効なタスクやデバッガー起動構成を保持できる
- 拡張機能の制御: ワークスペースごとに拡張機能を選択的に有効にできる
「このプロジェクトではこの拡張だけ」「このプロジェクトではこのタスクだけ」といった切り分けができ、ノイズを減らしつつ必要なものだけを有効にできます。
複数レポジトリがあるプロジェクトに有効
この機能で特に重要になるのは、マルチルートワークスペースという機能です。
マルチルートワークスペースを使うと、複数の異なるフォルダを同じワークスペースの一部として開けます。
- Backend・BFF・Frontend を 1つのウィンドウ でまとめて管理できる
- コンテキストも一括で扱えるため、横断的な理解や検索がしやすい
つまり、モノレポでない構成でも、関連するリポジトリをひとまとめにできるのがWorkspaceの強みです。
具体的なWorkspaceの作り方
ここでは具体的なワークスペースの作り方を説明しています。
この記事ではCursorで行っていますがVSCodeも同様にワークスペースの作成ができると思います。
1. メニューから「ファイル → ワークスペースにフォルダを追加」
- 複数のディレクトリを選択することが可能
- ここでバックエンド、フロントエンドなど様々なレポジトリを含めることで1エディタで管理可能
2.「名前を付けてワークスペースを保存」
- 特定の位置にworkspaceの構成ファイルをおくことが可能
3. workspaceの構成ファイルから再度開く
- 2までで作成したworkspaceを再度開ける
- エディタを再起動しても、設定を保ったまま同じ構成を維持できる
ドキュメントを読み込ませて、コンテキストとして利用する
これはWorkspaceを使用するときのTipsになります。
上記で作成したWorkspaceのように、同一Workspace内に複数のアプリケーションがあれば、アプリケーションをまたいでコンテキストを共有できます。
例：BFFのスキーマやAPI仕様をコンテキストとして渡し、それに合わせたFrontendの接続処理（hooks や composables）をCursorに生成させる、といった使い方ができます。このため、設計と実装の一貫性を保ちやすくなります。
Cursorでドキュメントを渡すためには、 ChatやComposerで @ からファイル名・フォルダ名を指定するか、該当ファイルを開いた状態で会話に含めることで、その内容をコンテキストとして参照できます。
必要なドキュメントだけを都度選ぶと、トークン消費を抑えつつ精度を保てます。
特におすすめの使い方は、下記です。
- ドキュメント用のディレクトリをWorkspaceに追加する
- プロンプト実行時に、そのドキュメントを読み込ませてコードを生成する
Workspaceにドキュメントディレクトリを含めると、単一のエディタ内でドキュメントをコンテキストに読み込ませながら、実際のプロンプトでの開発がしやすくなります。
実践: Obsidian + Git 設定
ここからは上記のCursor Workspaceと合わせて使用している、Obsidianの説明です。
Obsidianとは
Obsidian は、ローカル保存（Vault／ボルト）型のノートアプリです。ボルト（Vault） とは、ノートが保存されるルートフォルダ（保管庫）のことで、このフォルダごとに「1つの知識ベース」として管理します。このボルトをCursorのWorkspaceに追加すれば、同じディレクトリをObsidianとCursorの両方で扱えます。
- 特徴: Markdown形式でノートを作成し、ノート同士のリンクで「知識の地図（グラフ）」として視覚化できる
- メリット: 高速動作、プライバシー保護、プラグインによる自由度の高い拡張
- 用途: 知識管理、アイデアの整理、デイリーノート、タスク管理
ファイルはすべてローカルのMarkdownなので、Gitで管理しやすく、CursorのWorkspaceにそのまま追加できます。
自動PullとNotionライクなMarkdown表示
ObsidianはMarkdownをそのまま編集しつつ、見た目を整えて表示してくれます。
- Mermaid による図の表示
- テーブル の見やすい表示
「生のMarkdownを読む」よりも読みやすく、設計書や仕様書をObsidianで書いておくと、後からCursorに渡すコンテキストとしても扱いやすくなります。
下記はMermaidとテーブルのObsidianでのサンプルです。
ObsidianでのMermaidで作成した図
Obsidianでのテーブル表示
Gitコミュニティプラグインの利用
Obsidianのコミュニティプラグインには、Git連携のプラグインがあります（例: Obsidian Git）。
- Pull / Push など基本的なGit操作がObsidian内で可能
- 任意の分数で自動Pull する設定（定時同期）ができる
- チームでドキュメントを共有・同期するのが容易になる
「Obsidianで書く → Gitで共有 → 各自が自動Pullで最新を取得」という流れを組み立てやすいです。ObsidianもCursorも無料で始められ、Gitさえあればすぐに試せます。
具体的なObsidian Gitの設定方法
1. コミュニティプラグインの有効化
Obsidianの設定画面を開き、コミュニティプラグインを選択し、コミュニティプラグインを有効化します。
（こちらは、コアプラグインとは異なり、Obsidian公式というものではないので、個人の責任で有効化していただくようにお願いします。また、業務利用される方は、所属組織のルールに従ってください。）
2. コミュニティプラグインからGitを追加する
コミュニティプラグインを有効化すると、プラグインを探すことができます。
検索欄に「Git」と入力すると、Gitが出てくるのでこれをインストールし、有効化します。
3. （任意）便利な設定を追加する
Gitのコミュニティプラグインが追加されると、インストールされたプラグインが表示され、設定をすることができます。
歯車マークをクリックし、好みに応じて設定を追加してください。
ドキュメントをGitで管理している際には、自動コミットや自動Pullの設定を入れられるので、追加しておくと便利です（特にPull）。
-
Auto Commit and Push
上の赤線部分(図中の1つ目の赤線で囲んだ部分が該当の設定)に、数字（分）を設定すると、ドキュメントのレポジトリに自動で定期的にcommitするようになります。 -
Auto Pull
下の赤線(図中の2つ目の赤線で囲んだ部分が該当の設定)は、同じようにGitのレポジトリから定期的にPullできます。個人的には60分で自動的にPullするようにしています。
実例: 実際にやってみた
メインの使い方はここです。
- CursorのWorkspaceに、ドキュメント用のディレクトリ（Obsidianのボルトなど）を追加する
- 基本設計・詳細設計などのドキュメントを Obsidian（＋必要ならCursor）で作成する
- 作成したドキュメントを Cursorのコンテキストとして参照する
- コンテキストを元にコード生成やリファクタの指示を出し、プロンプトの精度を上げる
「仕様や設計が文章化されている → それをそのままAIに渡せる」状態にしておくことで、効率的に開発ができます。
個人の環境では、実際のWorkspaceとして「ドキュメントレポジトリ + 開発レポジトリ」として運用をしてます。
こうすることで「詳細設計のドキュメントを更新しつつ、アプリケーションを作成する」ということも１エディタで気軽にできるので、効率が上がったことも体感しています。
冒頭で図解した全体像もこの構成で作られています。
ドキュメントをAIと一緒に作る
ドキュメントそのものの質を上げる使い方もあります。
- 土台はObsidianでMarkdownとして書く
- ある程度形になったら、Cursorに読み込ませてブラッシュアップのポイントを指摘してもらう
- AIと一緒にドキュメントの完成度を上げる
- GitHubにレポジトリがある場合はPushして共有する
「書く人」と「添削するAI」の役割分担にすると、設計書や議事録のクオリティを上げやすくなります。
実際の開発でも、ドキュメントの精度が上がり、設計の時間の短縮になっています。
特にMermaidなどのアーキテクチャ図をCursorに書いてもらうことにより、開発者がMermaidなどの図式作成に時間を取られることが減りました。
また、自分で気づけなかったポイントも、AIにレビューしてもらうことができるので、観点漏れなども減ったように思います。
設計→実装の具体的フロー
設計から実装までを、この構成でどうつなげるかを整理します。
-
設計をObsidianで書く
基本設計・詳細設計・API仕様・Mermaid図などを、ObsidianのMarkdownで作成。必要ならCursorに「この構成で図を描いて」と依頼して整える。 -
Workspaceでドキュメント＋コードを同じコンテキストに
ドキュメント用ディレクトリ（Obsidian Vault）をWorkspaceに追加し、Backend/BFF/Frontendの各レポと並べて開く。 -
実装時にドキュメントをコンテキストとして渡す
Chat/Composerで@から該当の設計書・API仕様を指定し、「この仕様に合わせてFrontendの接続処理を書いて」のように指示する。 -
一貫性を保ちながらコード生成
BFFのスキーマやAPI仕様に合わせたhooks・composablesを生成させ、設計と実装のずれを減らす。 -
ドキュメントの更新と実装を同じウィンドウで
仕様変更があれば、同じWorkspace内でドキュメントを更新し、続けて該当コードの修正指示を出す。
この流れにしておくと、「設計 → 実装」のつながりが明確になり、AIのコンテキストも活かしやすくなります。
Tips
ドキュメントのレポジトリには .gitignore に **/tmp/ を追加する
一時的なメモや下書き、AIが生成した案などを tmp に置き、レポジトリを汚さないようにするのがおすすめです。.gitignore に **/tmp/ を入れておけば、作業用ファイルだけをローカルに残せます。
PRの説明作成
- GitHub MCP（Model Context Protocol）でCursorとGitHubを接続し、PRの内容を読み込ませる
- 「このPRの説明文を書いて」と依頼し、PRの説明を生成させる
- 生成結果は tmp（.gitignore済み） に保存し、本番のドキュメントやコミットは必要に応じて手で整える
PR説明のテンプレ化や下書きの自動生成として使えます。MCPはCursorの設定から「MCP」で検索し、GitHub用のサーバーを追加することで利用できます。
日報や個人ログの作成
- 個人のメモには、Obsidianのデイリーノートやその他プラグインを組み合わせると便利
- デイリーノートに「今日やったこと」「気づき」を書き、必要なら要約や振り返りをCursorに任せる
チーム用ドキュメントと個人用メモを、同じWorkspace・同じツール群で扱えるのが利点です。
ドキュメントレポジトリの中から、特定のプロジェクトのディレクトリのみ追加する
- ドキュメントのレポジトリからWorkspaceに追加するドキュメントは、プロジェクト単位で選ぶ
- こうすることで、必要ないコンテキストを読み込むことなく、特定のドキュメントのみ参照できます
さらに、ObsidianでGitを繋いでいるため、自動でドキュメントの更新＆任意のタイミングのみPushして共有ができます。
個人的には、エディタ + Obsidianの画面を参照しながら開発しています。
注意点・制約
- コンテキストのトークン上限: Cursorには入力できるコンテキスト量に上限があります。ドキュメントが大きい場合は、必要な章だけを指定する・要約してから渡すなど、選んで読み込むとよいです。
- 競合の回避: 同じドキュメントをObsidianとCursorで同時に開いて編集すると競合することがあります。編集はどちらか一方にまとめるか、編集前にPullして最新にしておく習慣があると安心です。
まとめ
AI時代だからこそ使えるCursor WorkspaceとObsidianの使い方を紹介しました。
- Cursor Workspace で、コードとドキュメントを同じコンテキストにまとめ、AIの精度を上げられる
- Obsidian でMarkdownの設計・仕様ドキュメントを書き、Gitで共有・自動Pullできる
- Cursor + Obsidian で「ドキュメントをコンテキストにした開発」と「AIと一緒にドキュメントを磨く」の両方ができる
-
.gitignoreのtmpやGitHub MCPを活用すると、PR説明や日報まわりも楽になる
コンテキストを意識してWorkspaceとObsidianを組み合わせると、設計と実装のつながりが明確になり、開発効率とドキュメントの質を両立しやすくなります。
この記事の内容があなたのためになれば幸いです。
Schooでは一緒に働く仲間を募集しています！