Obsidianのメモを Claude Code への指示書に変える手順

先週、僕はObsidianに2000字くらいのメモを残したまま、翌日のClaude Codeに「あのチェックアウトのボタン、直しといて」と頼みました。

返ってきたのは、ボタンの修正に加えて、ヘッダーの余白調整、フッターのリンク並び替え、ついでにCSSの命名規則を整える3ファイル分の差分。どれも頼んでいません。なぜこうなったかというと、僕がメモを丸ごと貼ったからです。3日前の「ここも気になる」というつぶやきまで、今日の指示と同じ重さで読まれてしまった。

メモは悪くないんです。悪いのは、メモを「そのまま渡せるもの」だと思っていた僕のほうでした。長いノートは記録には向くけど、作業の指示には向きません。今日はこの落差を埋める型、つまりObsidianのメモを短い指示書に変える手順を書きます。

この記事の要点

• 長いメモを丸ごと貼ると、AIは古いつぶやきと今日の指示を区別できず、頼んでいない作業まで広げる。
• 渡すのは4つだけ。「分かっている事実」「決めたこと」「まだ分からないこと」「次の一手」。これに「触らない場所」と「終わったと判断する証拠」を足す。
• 完了条件は小さくする。1つのファイル、1つの画面、1つのコマンドに絞り、ビルドとスクショまで見てから次へ進む。
• 雛形のプロンプトと、メモを指示書に変換する短いコードをそのままコピーして使える。
• AIに任せるのは「書く・探す・直す」。人が決めるのは「範囲・優先順位・公開可否」。ここを混ぜると事故る。

丸ごと貼るとなぜ広がるのか

Claude Codeは動くのが速いです。だからこそ、最初に渡す情報が広いと、広いまま全力で走ります。

メモには時間差があります。「ボタンが折り返す」という今日の事実と、「そういえば配色も古いかも」という1週間前の感想が、同じ箇条書きとして並んでいる。人間なら日付や文脈で読み分けますが、貼り付けられたAIにはどれが生きている指示か分かりません。結果、親切心で全部に手をつけます。

もう一つ。メモには「決めたこと」と「まだ迷っていること」が混ざっています。迷いの部分まで指示として読まれると、AIが勝手にどちらかに決めて進めてしまう。これが一番こわい。だから渡す前に、人間の側で一度だけ仕分けする必要があります。

渡すのは4つだけ

仕分けの軸はシンプルで、次の4つに振り分けるだけです。

1. 事実: 実際に確認できたこと。「375pxの画面でボタンが2行に折り返す」「公開URLは正しい」など、見れば誰でも同意できるもの。
2. 決定: もう決めたこと。「無料配布のPDFは有料教材より前に置く」のように、議論済みで動かさない方針。
3. 未確認: まだ分からないこと。「どの部品がボタンの余白を持っているか不明」など、AIに勝手に埋めさせたくない穴。
4. 次の一手: 今回やる1つのこと。「部品を特定し、最小のCSS変更を当て、スマホ幅で確認する」まで具体的に。

ここに2つ足します。触らない場所(例: 認証まわりのファイルは今回いじらない)と、終わったと判断する証拠(例: ビルドが通る、スマホ幅のスクショ)。この6項目が指示書の中身です。

仕分けで意識するのは、「未確認」を消さないこと。分からないことを正直に残すと、AIはそこを質問してくれます。逆に未確認を消して事実のように書くと、間違った前提のまま突き進みます。

AIに任せる範囲と、人が決める範囲

任せていいことと、人が握るべきことを最初に線引きします。ここが曖昧だと、指示書を作っても結局ぶれます。

工程	AIに任せる	人が決める
範囲	-	どのファイル・画面に絞るか
調査	部品やコードを探す	探す対象の優先順位
実装	最小の変更を書く	変更してよい上限
確認	ビルド・テストを走らせる	公開してよいかの最終判断

表のとおり、「探す・書く・走らせる」はAIが得意です。一方で「どこまでやるか」「公開していいか」は人が握る。この線を指示書に書いておくと、AIが範囲を広げようとしても自分で止まります。

コピペで使うプロンプト雛形

まずメモをそのまま選択して、この依頼文の下に貼ります。仕分け作業そのものをAIにやらせる使い方です。

次のObsidianメモを、Claude Code用の短い指示書に整理してください。
出力は以下の見出しだけにし、それ以外は捨ててください。

- 事実: 確認済みのことだけ
- 決定: もう動かさない方針
- 未確認: 勝手に埋めず、不明のまま残す
- 次の一手: 今回やる1つのことを具体的に
- 触らない場所: 今回いじらないファイルや機能
- 証拠: 終わったと判断する確認手段(ビルド、スクショ等)

古い感想や雑談は「参考メモ」として別枠にまとめ、指示には混ぜないでください。

出てきた指示書を読み直し、未確認が事実に化けていないか、次の一手が1つに絞れているかだけ確認します。問題なければ、これをそのままCLAUDE.mdや課題のコメントに貼って実装を頼みます。CLAUDE.mdの書き方はclaude-md-best-practicesに詳しくまとめています。

メモを指示書に変える検証コード

手作業の前に、構造を体に入れるための小さなコードを置きます。Node.jsで動きます。メモを上の6項目に分けて持ち、Claude Codeに渡す1枚の指示書に組み立てるだけのものです。

// メモを「事実・決定・未確認・次の一手」に分けて持つ
const note = {
  title: "チェックアウトのボタンがスマホで折り返す",
  facts: ["375pxの画面でボタンが2行に折り返す", "公開URLは正しい"],
  decision: "無料配布PDFは有料教材より前に出す",
  unknowns: ["どの部品がボタンの余白を持っているか不明"],
  nextAction: "部品を特定し、最小のCSS変更を当て、スマホ幅で確認する",
  doNotTouch: ["認証まわりのファイル"],
  proof: ["ビルドが通る", "375px幅のスクショ"],
};

// 6項目を1枚の指示書テキストに組み立てる
function toBrief(item) {
  return [
    `目的: ${item.nextAction}`,
    `事実: ${item.facts.join(" / ")}`,
    `決定: ${item.decision}`,
    `未確認(勝手に埋めない): ${item.unknowns.join(" / ")}`,
    `触らない場所: ${item.doNotTouch.join(" / ")}`,
    `証拠: ${item.proof.join(" / ")}`,
  ].join("\n");
}

// 仕分け漏れを機械でチェックする門番
function checkBrief(item) {
  const missing = [];
  if (item.facts.length === 0) missing.push("事実");
  if (item.unknowns.length === 0) missing.push("未確認");
  if (!item.nextAction) missing.push("次の一手");
  if (missing.length) {
    throw new Error(`仕分けが足りません: ${missing.join(", ")}`);
  }
  return true;
}

checkBrief(note);
console.log(toBrief(note));

checkBriefが地味な要ですが大事です。事実が空、未確認が空、次の一手が空のまま指示書を出そうとすると、ここで止まります。「とりあえず貼る」をコードの段階で禁止しておくと、雑なメモがそのままAIに流れる事故が減ります。出力結果をそのまま課題コメントや引き継ぎノートに貼れば、次の作業でも同じ判断を使い回せます。引き継ぎノートの作り方はclaude-code-session-handoff-templateが参考になります。

こんな場面で効く

1. 記事の改善を頼むとき 「この記事よくして」と丸投げすると、AIは本文を全部書き直しがちです。そこで指示書に「検索意図とCTA方針だけ渡す」「本文全体の書き換えは禁止」と書く。事実は今の見出し、決定は導線の方針、未確認は弱い段落、次の一手は1つの見出しだけ直す、と振り分けます。すると差分が小さくなり、戻すのも一瞬です。Obsidian連携そのものの設定はclaude-code-obsidian-integrationにまとめています。

2. バグを直すとき 再現できた事実と、まだ分からない原因を分けて渡すのがコツです。「375pxでボタンが折り返す」は事実、「どの部品が余白を持つか」は未確認。ここを混ぜて「原因はCSSのはず」と書いてしまうと、AIは間違った見当のまま直し始めます。未確認を未確認のまま渡すと、AIは先にそこを調べてくれます。

3. 導入の相談を受けるとき お客さんの業務メモを、そのまま見せず「今回触る範囲」「絶対に触らない範囲」「次回確認すること」に分けて渡します。本番のデータや課金まわりを未確認のまま自動で触らせない。この線引きを指示書に書くだけで、相談の場で安心して画面を共有できます。

やりがちな失敗と、その直し方

僕が最初にやらかした失敗は、だいたいこの3つに収まります。

ひとつ目は、vault全体を貼ったこと。古い決定と今の制約が混ざって、AIがどっちを信じればいいか分からなくなりました。直し方は単純で、貼る前に上の6項目へ仕分けるだけ。3日前の感想は「参考メモ」に隔離します。

ふたつ目は、決定だけを渡したこと。「PDFを前に出す」とだけ書いたら、AIはなぜそうするか分からず、別の場面で逆のことをしました。事実と理由をセットで残すと、応用が効きます。

みっつ目は、完了条件を大きくしたこと。「全体的に整えて」と頼むと、AIは親切に範囲を広げます。1つのファイル、1つの画面、1つのコマンドに絞り、ビルドとスクショを見てから次へ。これだけで、速度を落とさず戻し時間を減らせます。プロンプトの絞り方はclaude-code-prompt-engineering-advancedも合わせてどうぞ。

よくある質問

Q. メモを全部貼るより、指示書を作るほうが手間では? 最初の数回はそう感じます。でも丸投げで広がった差分を読み直して戻す時間のほうが、長い目で見ると重いです。仕分けは慣れると1分で終わります。

Q. 仕分けもAIにやらせていいですか? いいです。上のプロンプト雛形が、まさにその使い方です。ただし出てきた指示書は人が一度読み、未確認が事実に化けていないかだけ確認してください。

Q. CLAUDE.mdと指示書はどう違いますか? CLAUDE.mdはプロジェクト全体で変わらないルール置き場、指示書は今回の作業1回分の依頼です。指示書の「決定」が何度も出てくるなら、それはCLAUDE.mdに昇格させる合図です。

Q. Obsidianでなくても使えますか? 使えます。NotionでもただのテキストメモでもOKです。大事なのはツールではなく、事実・決定・未確認・次の一手に分ける考え方のほうです。

Q. どこまでAIに任せて、どこから人が決めるべき? 「探す・書く・走らせる」は任せて大丈夫です。「範囲をどこまで広げるか」「公開していいか」は人が握ります。この線を指示書に書いておくのがコツです。AIへの任せ方の基礎はclaude-code-for-non-engineersで解説しています。

実際に試した結果

冒頭の「頼んでいない3ファイル事故」のあと、僕はメモを貼る前に必ず6項目へ仕分けるようにしました。

実際に同じチェックアウトのボタン修正を、今度は指示書にして渡してみました。差分は1ファイル、CSSの数行だけ。ヘッダーもフッターも、頼んでいないものには一切触られませんでした。checkBriefで未確認を空のまま出そうとして1回止められて、「どの部品が余白を持つか」を書き足してから渡したのも効いた気がします。AIが先にその部品を探してくれたからです。

確かめたのは2つ。「未確認を残すと、AIが勝手に埋めずに調べてくれる」こと。そして「次の一手を1つに絞ると、差分が小さく戻しやすい」こと。賢いプロンプトを探すより、渡す前の1分の仕分けのほうが、結局いちばん速いというのが今の実感です。

メモの仕分けに慣れて、次はチーム全体で同じ型を回したくなったら、進め方を一緒に設計する研修・相談も用意しています。

公式の前提条件はAnthropic Claude Code getting startedで確認できます。