ObsidianメモをCLAUDE.mdに変えるClaude Code運用: 文脈を毎回説明しない仕組み

Obsidianに作業メモはあるのに、Claude Codeを開くたびに同じ説明をしているなら、知識管理と実装の間に隙間があります。この記事では、Obsidianの自由なメモを、Claude Codeが毎回読めるCLAUDE.mdの運用ノートに変える流れを作ります。

Obsidian記事への流入が多い読者は、単なる連携方法ではなく、メモを実装品質に変える方法を探しています。重要なのは大量のノートを渡すことではなく、現在の判断、禁止事項、検証コマンドだけを短く渡すことです。

関連して読む記事: claude-code-obsidian-integration, claude-code-claude-md-starter-template, claude-md-best-practices.

なぜ最初にこの型を作るのか

Claude Codeは、作業の境界が明確なときに一番強くなります。よい境界は、読んでよいファイル、編集してよいファイル、実行してはいけない操作、作業を終える証拠を名前で示します。この境界がないと、初心者向けの小さな依頼でも大きな書き換えになり、コンテンツ変更が無料PDF、Gumroad、導入相談の導線を静かに壊すことがあります。

この型は収益作業にも効きます。技術的な証拠と読者側の証拠を同じチェックに入れるからです。ローカルでbuildできても、違う読者を違う商品へ送っているページは未完成です。scope、command、public URL、CTAを残す運用なら、明日も記憶ではなく記録から改善できます。

実務で使うワークフロー

1. Obsidianでは事実、判断、未解決、次の一手を分けて書く
2. 週に一度、Claude Codeに渡すべき内容だけを抽出する
3. CLAUDE.mdには安定ルール、handoffには一時状態を置く
4. 商品や記事運用ならCTA判断も運用ノートに入れる
5. 古い判断は削除し、毎回読ませる文脈を軽く保つ

場面	安全な進め方	確認方法
コンテンツ運用	記事の検索意図、対象商品、CTA判断をObsidianで考え、CLAUDE.mdには毎回守る収益導線ルールだけ残します。	build, diff, URL
チーム開発	設計判断はObsidianに詳しく残し、Claude Codeには現在採用中のルールと禁止事項だけ渡します。	screenshot, test
デバッグ	原因仮説の履歴はメモに残し、次回セッションには検証済み事実と次のコマンドだけ渡します。	log, command, handoff

最初の確認は短くします。監査が作るべきものは巨大なレポートではなく判断です。20分後も判断が曖昧なら、編集を始めるのではなく、追加で読むべき1ファイルを決めます。

そのまま使えるプロンプトとコード

このObsidianメモを読んで、CLAUDE.mdに残すべき運用ルール、一時的なhandoff、削除してよい古い情報に分けてください。

const note = {
  title: "Checkout copy bug",
  facts: ["mobile CTA wraps", "Gumroad link still works"],
  decisions: ["keep paid CTA after free PDF"],
  commands: ["npm.cmd run build"],
};

export function toClaudeMdBlock(item) {
  return [
    "## Current operating note",
    `- Topic: ${item.title}`,
    `- Facts: ${item.facts.join("; ")}`,
    `- Decisions: ${item.decisions.join("; ")}`,
    `- Proof command: ${item.commands[0]}`,
  ].join("\n");
}

console.log(toClaudeMdBlock(note));

このコードはわざと小さくしています。運用上の考えを、scopeがあるか、保護領域があるか、少なくとも1つの検証コマンドがあるかという確認可能な形に変えるためです。記事公開、アプリ開発、デバッグ、チーム引き継ぎに合わせて形を変えられます。

3つの実例

コンテンツ運用

記事の検索意図、対象商品、CTA判断をObsidianで考え、CLAUDE.mdには毎回守る収益導線ルールだけ残します。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

チーム開発

設計判断はObsidianに詳しく残し、Claude Codeには現在採用中のルールと禁止事項だけ渡します。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

デバッグ

原因仮説の履歴はメモに残し、次回セッションには検証済み事実と次のコマンドだけ渡します。

大事なのは証拠です。1つのコマンド、1つの表示ページ、または読者に届いたことを示す1つのメモを残します。

よくある失敗例

• Obsidian全体を読ませると、古い判断と今の判断が混ざります。
• CLAUDE.mdを日記にすると、毎回読むべきルールが埋もれます。
• CTA判断をメモに閉じ込めると、記事本文と商品導線がずれます。

もう1つの見落としは多言語のずれです。英語版では正しい商品導線を説明していても、別言語では古いCTAが残ることがあります。だから公開確認では frontmatter の lang だけでなく、h1、本文冒頭、CTAの言語まで見ます。

無料PDF、Gumroad、導入相談へのつなぎ方

基本操作を手元に置きたい場合は 無料チートシート から始めてください。設定、権限、CLAUDE.md、CI/CD まで整えたい読者には Setup Guide が合います。レビュー、デバッグ、リファクタリングの入力を毎回考えている読者には 50 Prompt Templates を勧めます。チーム展開や収益導線まで含む設計が必要なら 導入相談 に進むのが自然です。商品一覧を比較したい場合は products も確認できます。

すべての読者をいきなり有料商品へ送る必要はありません。初心者には摩擦の低いPDFが合います。同じプロンプトを繰り返す中級者はテンプレートに近く、権限、CLAUDE.md、hooks、MCP、CI/CDで止まる読者はSetup Guideに近い。チームや運用設計の相談は導入相談に近いです。

公開前後に見る検証ポイント

この記事では、h1、本文冒頭、heroImage、内部リンク、Gumroadリンク、相談導線が同じ意図でつながるかを確認対象にします。HTTP 200 だけでは完了にせず、読者が次の行動を選べる状態かを見ます。

多言語公開では、日本語、英語、中国語、韓国語、スペイン語、フランス語、ドイツ語、ポルトガル語、ヒンディー語、インドネシア語を別々に確認します。slugが一致しても本文が古い場合があります。モバイル幅のスクリーンショットなら、冒頭本文とCTAを同時に見られるため発見が早くなります。

次に見るべき数字

次に見る数字は、このslugのPDF開始、Gumroadクリック、products訪問、training訪問、検索流入、国別比率、記事からCTAへのクリック率です。PVが増えてもGumroadクリックが増えないなら商品対応を強めます。技術記事から相談訪問が増えるなら、読者は一般チュートリアルではなくワークフロー設計を求めています。公開後の改善では、記事単体の順位だけを見ず、どの段落のあとに読者が商品導線へ進んだかを見ます。無料PDFで止まるなら初心者向けの説明を厚くし、Gumroadで止まるなら商品名ではなく解決できる作業を具体化します。相談ページまで進んで離脱するなら、誰向けの相談か、何を持ち帰れるか、英語商品との関係をさらに明確にします。特に多言語記事では、英語版のGumroad商品が主軸であることを隠さず、読者が英語教材へ進む理由を本文中で説明します。日本語読者には、無料PDFで操作を試し、Setup Guideで設定を固め、必要なら相談で自分の運用に落とすという順番を明示します。この順番があると、広告的な押し売りではなく、次の作業を選ぶ案内になります。最後に、公開後のスクリーンショットで冒頭とCTA付近を見直し、本文の約束とボタンの行き先がずれていないことを確認します。これで記事はPVだけでなく次の行動まで評価できます。