案件の打ち合わせメモ、Figmaの決定事項、WordPressの修正メモ——全部を1つのフォルダに放り込むと、Obsidian Cursor 連携を試したときにAIが古い仕様を拾ってしまうことがあります。私はWebディレクションと実装を兼ねているので、「人が読むメモ」と「エディタに渡すルール」を混ぜない運用に寄せています。本記事はObsidianの新機能紹介ではなく、すでにMarkdownで案件を回している人が、VaultとCursorのRulesを役割分けする手順に絞ります。Cursor RulesでWordPress修正範囲を固定する手順やFigmaブランチでの確認フローと並べて使う想定です。
この記事でわかること
- Vault内で「案件ログ」「ルール」「下書き」を分けるフォルダ設計
- デイリーノートから案件ノートへリンクする最小テンプレ
- Cursor側で参照させるファイルと、Obsidianに残すファイルの切り分け
先に結論
- 向いている人: 複数案件を並行するフリーランス。Markdownで仕様を残している人。AIにコード修正を頼む前に、触ってよい範囲を文章で固定したい人。
- 向いていない人: 案件資料がすべてNotionやGoogleドキュメントで、ローカルMarkdownを使わない人。ObsidianをインストールしただけでVaultを作っていない人（先にVault作成から）。
- 私のおすすめ: Obsidianは「事実と履歴」、Cursor Rulesは「編集の縄張り」 に固定する。同じ文章を両方にコピペしない。
私はルールを長く書きすぎると守られなくなるので、案件ごとに3行だけ増やす運用にしています。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
ObsidianとCursorの料金・機能は執筆時点（2026年9月22日・日本時間）の情報です。Syncや有料プランの有無は変わることがあるので、導入前に各公式を確認してください。
フォルダ設計（Vaultの3層）
混ぜないための最小構成は次の3つです。
| フォルダ | 置くもの | Cursorが触るか |
|---|---|---|
00_daily/ |
デイリーノート、短いTODO | 基本触らない |
10_projects/案件名/ |
打合せ、決定事項、URL一覧 | 参照のみ（Rulesで指定） |
90_rules/ |
.cursor/rules へコピーする正本 |
編集対象の定義元 |
10_projects には「クライアントが言ったこと」「自分が決めたこと」を日付見出しで追記します。ここは体験と事実のログです。推測は > 引用で「要確認」と書き、確定したら通常の箇条書きに昇格させます。
90_rules には、WordPressテーマ名、触ってよいディレクトリ、触らないプラグインなどを短く書きます。正本はObsidianに置き、Gitリポジトリの .cursor/rules/ へ同期するイメージです。詳細なWordPress向けの書き方はCursor RulesのWordPress固定手順に任せ、ここでは「Obsidian側に何を書くか」だけ押さえます。
デイリーノートのテンプレ（5分で回す）
デイリーノートは索引に徹します。長文を書かないのがコツです。
- ファイル名は
YYYY-MM-DD.md（日本時間） - 先頭に「今日触る案件」を最大3つ、Wikiリンク
[ [案件slug] ]で列挙 - 各案件へのリンクの下に、1行メモだけ（例: 「18時クライアント確認」）
テンプレ例（そのままコピー可）:
## 今日の案件
- [[clientA-redesign]] — トップのヒーロー差し替え確認
- [[clientB-wp-fix]] — functions.php 触らない
## 終わったら
- [ ] 決定事項を案件ノートへ移す
- [ ] Cursorに渡す前に 90_rules を見直す
デイリーノートに仕様を書き始めると、あとから案件ノートへ移す手間が増えるので、私はリンクだけ残すようにしています。
案件ノート側には、Figma URL、ステージングURL、担当者名（イニシャル可）を固定セクションに置きます。個人情報ルールがある案件は、VaultをクラウドSyncする前に共有範囲を必ず確認してください。私はSyncを使う案件と使わない案件でVaultを分けています（一般論として、機密はローカルのみが無難です）。
Cursor Rules に渡す内容（Obsidianから抜き出す）
CursorのRulesに載せるのは、次の4項目までに絞ると効きます。
- 編集可能パス（例:
wp-content/themes/xxx/のみ） - 禁止（例: プラグイン本体、本番DB、
.env） - 参照してよい仕様書（Obsidianの
10_projects/案件名/spec.mdへの相対パス） - 文体・コミット（日本語、1コミット1目的 など）
Obsidianの案件ノート全文をRulesに貼らない理由は、トークンが古い打合せメモで埋まるからです。Rulesは「縄張り」、Obsidianは「百科事典」と割り切ります。
実務の流れは次のとおりです。
- 打合せ後、Obsidianの案件ノートに決定事項だけ追記
- その日のうちに、変更がコードに効くなら
90_rules/案件名.mdcを3行更新 - Gitへ
.cursor/rules/をコミット（Obsidian正本と内容を揃える） - Cursorで「
spec.mdと rules を読んでから修正」と依頼
Figma側の決定事項は、Obsidianに「画面名＋承認日」までで十分なことが多いです。ピクセル値の羅列はFigmaに任せ、Figma Dev Modeの参照フローと役割が被らないようにします。
Obsidianと同じリポジトリでCursorを開く
私のおすすめは、案件リポジトリのルートに docs/ または notes/ を置き、Obsidian Vaultのルートをそこにする方法です。WordPressテーマ修正とメモが同じGit履歴に乗るので、「いつ仕様が変わったか」がコミットログで追えます。
注意点:
.obsidian/はGitに含めても含めなくてもよいが、プラグイン設定を共有するとチームで挙動が変わるので、個人設定は各自で- 大容量の画像バイナリはVaultに入れない（リンクだけ。実体は
assets/など別管理） - CursorのAgentが
notes/全体を読むと古いメモを拾うので、Rulesで 読むファイルを列挙 する
リポジトリをクライアントに渡す案件では、Vaultごと渡さず、Rulesと spec だけを抜粋 する運用もあります。その場合もObsidian側の正本を自分で保持し、抜粋はコピーと割り切ってください。
よくある失敗（私がやったこと）
- デイリーノートに仕様を書き続ける → 案件ノートが空のまま。後から検索不能。
- Rulesにクライアントの怒りメールを貼る → AIのトーンがおかしくなる。感情ログはObsidianのプライベート節へ。
- ObsidianとRulesの二重管理をやめる → どちらも更新されず、AIだけが古い
.mdcを信じる。 - Syncなしで複数PC → ルール正本がどのマシンにあるか分からなくなる。Gitを正本にするか、Syncの衝突解決ルールを決める。
失敗したときの復旧は、90_rules を1ページに縮約 し、案件ノートの未確定項目に 要確認 タグを付けるだけで十分なことが多いです。
よくある質問
Q. Obsidianは無料のままで足りますか？
A. 個人の案件メモとデイリーノートだけなら、無料版で足りることが多いです。複数端末でVaultをリアルタイム同期したい、公開ノートをWebに出したい場合は有料SyncやPublishを検討します。Cursor連携の本質はローカルMarkdownが読めることなので、エディタ連携だけが目的ならGit同期でも問題ありません。
Q. Cursor Rules と AGENTS.md はどちらを優先すべきですか？
A. リポジトリに両方ある場合、より具体的なパス指定がある方を正とします。私はObsidianの 90_rules に「AGENTS.md は概要、詳細は .cursor/rules/案件.mdc」と1行書いて、二重定義を減らしています。WordPress案件では修正範囲固定の記事のテンプレを 90_rules からコピーするのが早いです。
Q. クライアント向けの進捗報告もObsidianに書きますか？
A. 書きますが、送付用の文面は別ファイルにします。例: 10_projects/案件/ report-20260922.md を作り、デイリーノートからリンク。Slackに貼った最終文はObsidianに残すと、後から「何を約束したか」が追えます。進捗報告の型はフリーランス進捗報告のテンプレも参考になります。
Q. Notionから移行する場合、何から移しますか？
A. 触る頻度が高い案件1件だけからで十分です。Notionの全ページを一気に移すとリンク切れが地獄になります。まず「決定事項」「URL」「禁止事項」の3セクションだけMarkdown化し、Cursor Rulesに禁止事項を写します。残りは必要になったページから順次です。
まとめ
Obsidian Cursor 連携で大事なのは、同じ文章を everywhere に置かないことです。デイリーノートは索引、案件ノートは事実、Rulesは縄張り——この3役割をフォルダで固定すると、AIにコード修正を頼むときの取り違えが減ります。
今日やること（チェックリスト）
- Vaultに
00_daily/10_projects/90_rulesの3フォルダを作る - 進行中案件が1件なら、その案件ノートに「決定事項」「URL」「禁止」の見出しだけ作る
90_rulesから.cursor/rules/へ、編集可能パス3行＋禁止2行 をコピーする- Cursorを開き、「rules と spec を読んでから」と依頼文の先頭に1行足す
完璧なVaultより、明日も同じ手順で開ける場所を決める方が、私には効きました。
関連記事: Cursor RulesでWordPress修正範囲を固定 / Figmaブランチでクライアント確認 / Figma制作フローの入口
AI支援付きエディタの契約・プランは変わることがあります。チームでCursorを使う場合は、リポジトリへ載せるメモにクライアント機密を入れないルールを、Obsidianの 90_rules 冒頭にも同じ文言で書いておくと安全です。
制作全体のチェックリストは Web制作納品チェックリスト もあわせて確認してください。エディタを整えたあとは、Figma側の承認フローとセットで見直すと、手戻りがさらに減ります。
