Obsidianのメモを、Claude Codeが今日実装できる依頼文に変える手順

金曜の夜、Obsidianに「サインアップへの誘導が弱い気がする。スクロールしないと無料PDFのリンクに気づかない人が多そう」とだけメモを残しました。月曜の朝、そのメモをまるごとClaude Codeに貼って「これ直して」と頼んだら、返ってきたのは2画面分の「現状の整理」でした。コードは1行も書かれていません。

メモは悪くなかった。問題は、メモをそのまま渡したことです。僕はその日、背景説明を聞かされただけで30分を溶かしました。

Obsidianに知識は溜まっているのに、毎回Claude Codeに同じ前置きを書いている。心当たりがあるなら、足りないのは賢いAIではなく、メモを「依頼文」に削る型です。

この記事の要点

• Obsidianのメモをそのまま貼ると、Claude Codeは要約係になって実装が遅れる。渡すのは全文ではなく、今日終わる1タスクだけ。
• メモから抜き出すのは6つだけ。目的・触らない範囲・最初の一手・確認方法・導線・戻し方。
• 「読む範囲」と「触らない範囲」を先に書くと、支払いや認証に勝手に広がる事故が消える。
• 依頼文はテンプレ化してObsidianに保存すれば、次回から書き起こす手間がなくなる。
• 完了報告を信じる代わりに、画面のキャプチャやビルド結果という確認材料で判断する。

なぜメモを全部渡してはいけないのか

Obsidianのメモは、未来の自分への手紙です。文脈も迷いも全部書いてある。だからこそ、AIに渡すと「全部読んで理解しよう」としてしまいます。

人間の同僚なら、長いメモを読んで「要するに誘導リンクの位置だね」と勝手に削ってくれます。Claude Codeはそこまで気を利かせません。渡された文章量に比例して、丁寧な要約を返してきます。親切なのに、欲しいのは要約じゃない。

だから渡す前に、人間側で削ります。1000字のメモから、実装に必要な30字だけ残す。この削る作業こそが、毎回の前置きをなくす近道です。

メモの整理そのものをClaude Codeに任せたい人は、先にObsidianとの連携の基本を読んでおくと、この記事の手順がつながりやすくなります。

メモから抜き出す6項目

僕が毎回メモから取り出すのは、次の6つだけです。メモにこの6つが揃っていなくても構いません。足りない欄は、削るときに自分で決めます。

項目	中身	例
目的	利用者が得る結果を1文で	訪問者がスクロール前に無料PDFのリンクに気づく
触らない範囲	壊したくない場所	決済処理、ログイン、スマホ表示の崩れ
最初の一手	どこから手をつけるか	トップの最初の画面に1セクション追加
確認方法	終わったと判断する材料	ビルドが通る、変更の差分、公開URLの見た目
導線	読者を次にどこへ送るか	無料PDFの登録ページ
戻し方	失敗したときの退路	このコミットだけ取り消せばよい

ポイントは「触らない範囲」です。ここを空欄のままにすると、誘導リンクを直すついでに決済まわりのコードを「ついでに整えました」と言われかねません。先に禁止区域を引いておくのが、いちばん効きます。

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

ここを混ぜると事故ります。線引きをはっきりさせます。

• 人が決める: 目的・触らない範囲・戻し方。これは事業の判断なので、AIに丸投げしない。
• AIに任せる: 最初の一手の具体化、コードの実装、確認コマンドの実行。
• 人が最後に見る: 公開URLの見た目と、差分が想定どおりか。ここだけは目で確かめます。

判断を任せていいのは「どう作るか」であって、「何を守るか」ではありません。守るものを決めるのは、いつも人間の側です。

メモを依頼文に変えるプロンプト雛形

抜き出した6項目を、そのままClaude Codeに渡せる形にします。下の雛形をコピーして、最後にメモを貼るだけです。

次のObsidianメモを、あなたが今日実装できる1つの依頼文に変換してください。
出力は以下の6見出しに分けてください。まだコードは書かないでください。

- 目的（利用者が得る結果を1文で）
- 触らない範囲（変更してはいけない場所）
- 最初の一手（最小の変更1つ）
- 確認方法（ビルド・差分・公開URLなど）
- 導線（読者を次に送る先）
- 戻し方（失敗時に元へ戻す手順）

【メモ】
（ここにObsidianのメモを貼る）

大事なのは最後の一文、「まだコードは書かないでください」です。これがないと、Claude Codeは変換と実装を一気にやろうとして、触らない範囲の確認をすっ飛ばします。一度依頼文を出させて、人間が禁止区域を確認してから、改めて「ではこの依頼文どおり実装して」と返す。この二段構えで事故が減ります。

雛形の精度をもっと上げたい人は、Claude Code向けプロンプト設計の応用に細かい言い回しのコツをまとめてあります。

コピペで動く変換スクリプト

毎回プロンプトを手で組むのが面倒なら、メモをオブジェクトで書いて依頼文を自動生成してしまいます。Node.jsがあればそのまま動きます。

// メモを「今日実装できる依頼文」に変換する最小スクリプト
// 使い方: node note-to-issue.mjs

const note = {
  目的: "訪問者がスクロール前に無料PDFのリンクに気づく",
  触らない範囲: ["決済処理", "ログイン", "スマホ表示の崩れ"],
  最初の一手: "トップの最初の画面に告知セクションを1つ追加",
  確認方法: ["ビルドが通る", "変更の差分", "公開URLの見た目"],
  導線: "無料PDFの登録ページ",
  戻し方: "このコミットだけ取り消せば元に戻る",
};

function toIssuePrompt(n) {
  // 必須項目が抜けていたら、依頼文を出す前に気づけるようにする
  const required = ["目的", "触らない範囲", "最初の一手", "確認方法"];
  const missing = required.filter((key) => {
    const v = n[key];
    return v === undefined || (Array.isArray(v) && v.length === 0);
  });
  if (missing.length > 0) {
    throw new Error(`依頼文に必要な項目が足りません: ${missing.join(", ")}`);
  }

  const line = (label, value) =>
    `${label}: ${Array.isArray(value) ? value.join(" / ") : value}`;

  return [
    line("目的", n.目的),
    line("触らない範囲", n.触らない範囲),
    line("最初の一手", n.最初の一手),
    line("確認方法", n.確認方法),
    line("導線", n.導線),
    line("戻し方", n.戻し方),
    "まだコードは書かず、この範囲で最小の実装計画だけ返してください。",
  ].join("\n");
}

console.log(toIssuePrompt(note));

実行すると、6行＋最後の一文の依頼文が出力されます。触らない範囲 を空配列にしてもう一度走らせると、依頼文を出す前に「項目が足りません」と止まります。空欄のまま渡してしまう事故を、コードの側で先に弾く仕組みです。

実際に効く場面を3つ

1. 誘導リンクの改善メモ 「無料PDFのリンクが弱い」というメモを、そのまま貼ると改善案の説明が延々と続きます。依頼文に削れば、最初の一手 が「最初の画面に1セクション追加」の1点に絞られ、決済まわりには触らせません。改善前後の見た目を公開URLで見比べれば、効果を雰囲気でなく目で判断できます。

2. バグ調査のメモ 「たまにログイン後に画面が真っ白になる」というメモは情報が多すぎます。依頼文では 最初の一手 を「再現条件とエラーログだけ先に共有」に絞る。原因究明と修正を一気にやらせず、まず再現に集中させると、見当違いの修正を回避できます。

3. 記事企画のメモ 「次の記事、内部リンクをちゃんと張りたい」という曖昧なメモも、目的 を「関連記事への内部リンクを2本固定する」に削れば実装可能になります。確認方法を「ビルドが通る」にしておけば、リンク切れを公開前に止められます。記事まわりの作業を任せる前提は、非エンジニア向けのClaude Code入門で一度ならしておくと安心です。

依頼文をテンプレとして残す

一度作った依頼文は、使い捨てにせずObsidianに戻します。次に似たメモが来たとき、6つの見出しごと再利用できるからです。

僕は templates/issue-prompt.md というノートを1つ作って、6見出しの空テンプレを置いています。新しいメモが来たら、そのテンプレをコピーして埋めるだけ。前置きを毎回書く時間が消えました。

さらに、Claude Codeが読むべきルール自体をプロジェクトに固定しておくと、依頼文がもっと短くなります。プロジェクト共通の約束ごとはCLAUDE.mdの書き方に寄せておくと、依頼文側で毎回繰り返さずに済みます。

つまずきやすい落とし穴と直し方

最初の頃に僕がやらかした失敗を、直し方つきで挙げます。

• メモを全文貼る: Claude Codeが要約係になる。直し方は、貼る前に6項目へ削る。削れないメモは、まだ依頼として固まっていない証拠なので、先に自分で結論を1文書く。
• 触らない範囲を書かない: 支払いや認証に勝手に広がる。直し方は、空欄を許さず「特になし」とも書かない。最低1つは禁止区域を挙げる癖をつける。
• 確認方法が「動けばOK」: 完了報告を信じるしかなくなる。直し方は、ビルド結果・差分・公開URLのうち最低1つを必ず指定する。
• 一気に実装させる: 変換と実装が混ざって、禁止区域の確認が飛ぶ。直し方は「まだコードは書かないで」を必ず入れ、依頼文を確認してから実装を頼む。

落とし穴はどれも「先に1行決めておけば防げた」ものばかりでした。

よくある質問

Q. メモが断片的で、6項目を埋められません。 全部埋まらなくて大丈夫です。最低限「目的」と「触らない範囲」だけ決めれば依頼文になります。残りは依頼文を出したあと、Claude Codeの提案を見て埋めても間に合います。

Q. Obsidianのメモを直接Claude Codeに読ませる連携は必要ですか。 最初は不要です。メモを手でコピーして雛形に貼るだけで十分機能します。同じ作業を何度も繰り返すようになってから、自動連携を検討すれば遅くありません。

Q. 「まだコードは書かないで」と書いても実装を始めてしまいます。 プロジェクトのCLAUDE.mdに「依頼文の変換時はコードを書かない」と明記しておくと安定します。プロンプト1回の指示より、プロジェクト共通のルールのほうが守られやすいです。

Q. 依頼文はどのくらいの長さが適切ですか。 6見出しで合計10行前後を目安にしています。それより長くなったら、1つのタスクに複数の目的が混ざっているサインです。タスクを分けてください。

Q. 確認方法に何を入れればいいか分かりません。 迷ったら「ビルドが通る」と「公開URLの見た目」の2つで始めてください。この2つだけで、完了報告を鵜呑みにする状態からは抜け出せます。

実際に試した結果

冒頭の誘導リンクのメモを、この6項目の雛形で削ってからもう一度Claude Codeに渡してみました。今度は要約は返ってこず、「最初の画面に告知セクションを1つ追加」という実装計画が最初に出ました。触らない範囲に挙げた決済処理には一切手が入っていません。

検証スクリプトのほうも、触らない範囲 をわざと空にして走らせたところ、依頼文を出す前に「項目が足りません」で止まりました。空欄のまま渡してしまう一番よくある事故が、実行前に防げることを確認できました。

賢い指示を毎回ひねり出すより、メモを削る型を1つ持つほうが速い。これが今の実感です。同じやり方をチームの記事作成や問い合わせ対応にも広げたい人は、業務向けの研修・相談で実際の運用に合わせて型を組み立てられます。公式の基準はAnthropicの公式ドキュメントで確認できます。