Obsidianのメモをnote記事に変える5ステップ。最初に「メモを選ばない」理由

私のObsidianには、日記、仕事の気づき、過去の記事、AIとの作業ログが別々の場所に残っています。

材料はあります。

でも、記事を書こうとしてObsidianを開いても、すぐに文章が出てくるわけではありませんでした。メモを1つ選んでClaude Codeに「この記事を書いて」と頼むと、読みやすいけれど、どこかで見た文章になる。逆に、関係しそうなメモを全部読ませると、今度は話が広がりすぎます。

必要だったのは、強いプロンプトではありません。

メモを記事へ変える順番でした。

私は元スーパーのレジ打ちで、PCも未経験でした。今はAI企業で働きながら、ObsidianとClaude Codeを使って記事を作っています。その中で残った工程は、次の5つです。

1. 読者の困りごとを1つ決める
2. Obsidianから根拠を集める
3. 事実と推測を分ける
4. 記事の設計図を作る
5. 下書きを作り、元メモと照合する

この順番なら、メモの整理そのものに時間を使い続けず、手元の記録をnote記事の下書きまで運べます。

ステップ1：メモより先に、読者の困りごとを1つ決める

最初にObsidianを眺めると、目についたメモから記事を作りたくなります。

私はこれで何度も話を広げました。

「AI」「メモ」「仕事」「自動化」。関連するメモを集めれば集めるほど、書けそうなことは増えます。ただ、記事の中心は薄くなる。材料から題材を決めると、読者が探しているものではなく、今日たまたま見つけたものが主役になるからです。

今は、先に検索語を1つ置いています。

今回なら、これです。

Obsidian メモ note記事 変換 手順

この検索語から、読者の困りごとを1文にします。

Obsidianにメモは溜まっているが、どれをどう組み合わせれば
1本の記事になるのか分からない。

ここまで決めてから、メモを探します。

主役はメモではなく、読者が止まっている場所です。メモは、その問題に答えるための材料として使います。

ステップ2：Claude Codeに「答え」ではなく「根拠」を探させる

困りごとが決まったら、Claude CodeをObsidianのVaultで開きます。

ここで、いきなり記事を書かせません。

先に頼むのは、根拠探しです。

「Obsidianにメモは溜まっているが、記事にできない」
という問題について書きます。

Vault内から、次の材料を探してください。
- 私が実際に困った記録
- 試して失敗した方法
- 今も残っている手順
- 数字や作業ログなど、確認できる証拠

候補ごとに、ファイル名と該当部分を示してください。
まだ記事本文は書かないでください。

大事なのは、ファイル名と該当部分まで出させることです。

「関連するメモがありました」だけでは、確認できません。AIが内容を要約する途中で、事実と解釈を混ぜることもあります。元の文章へ戻れる形なら、自分の目で確かめられます。

たとえば、Vault内のファイル数を調べるときは注意が必要です。開発用フォルダには、ツールが自動生成したREADMEなども含まれています。表示された合計をそのまま「自分のメモ数」として扱うことはできません。

コマンドが正しく動いていても、数える対象が違えば、欲しい答えにはならない。

だから数字が出たときは、「いくつか」より先に「何を数えたか」を確認します。

ステップ3：集めた材料を3種類に分ける

Claude Codeが材料を集めたら、すぐに構成へ進まず、次の3つに分けます。

この分類を挟む理由は単純です。

Claude Codeは、足りない部分を自然な文章で埋められます。それ自体は便利ですが、記事では「自然に読めること」と「実際に起きたこと」は別です。

私は、集めた材料を「実体験・再構成・仮想例」の3列に分けています。証拠が確認できないものは実体験に入れません。数字も、値だけではなく「何を・いつ・どの条件で数えたか」まで確認します。

ここは記事の信用を決める工程です。分類をClaude Codeに手伝わせることはできますが、最後の判定まで任せません。

ここで材料が少なければ、無理に記事を作りません。

書けないのではなく、まだ根拠が足りない状態です。別のメモを探すか、実際に試して記録を増やします。

ステップ4：本文ではなく、先に設計図を作る

材料が揃ったら、ようやく構成です。

私は、本文より先に次の5項目だけを作ります。

1. 読者が今困っていること
2. 記事で約束する変化
3. その約束を支える一次情報
4. 読者が実行する手順
5. 読み終えた直後の小さな行動

今回の記事なら、こうなります。

困りごと：メモはあるが、記事への変え方が分からない
約束：5つの順番で、下書きまで作れる
一次情報：実際の検索語、指示文、数字を誤った失敗記録
手順：問題設定→根拠収集→分類→設計→照合
行動：自分のメモから根拠を3件だけ探す

設計図の役割は、文章をきれいにすることではありません。

話を増やしすぎないことです。

AIにいきなり2,000字を書かせると、足りない説明を補う方向に動きます。設計図なら、まだ数行です。約束が大きすぎる、根拠が弱い、過去記事と重なる。そうしたズレを、本文を書く前に直せます。

ステップ5：下書きを作ったら、元メモへ戻る

設計図が固まったら、Claude Codeに本文を作らせます。

ただし、ここで使っている執筆指示は一文のプロンプトではありません。読者、文体、事実確認、記事構成、公開前検査を分けた手順書として保存しています。以前は毎回長い指示を貼っていましたが、修正が増えるたびに内容が混ざり、どこを直したのか分からなくなったからです。

まず試すなら、設計図と確認済みの一次情報を渡し、「元メモにない感情・回数・成果を追加しない」と指定するだけでも構いません。

下書きが出たら、読みやすさより先に照合します。

見る場所は4つです。

• タイトルで約束した内容が、本文にあるか

• 数字が元メモと一致しているか

• 実体験に、元の記録があるか

• 読者が途中で手を止める工程がないか

たとえば、元メモには「一度試した」としか書いていないのに、下書きでは「何度も試した」に変わっていたとします。文章としては自然です。ただ、事実ではありません。

こうした小さなズレは、下書きだけを読んでいると見落とします。

だから最後は、文章のうまさではなく、元メモと一文ずつ照らし合わせます。数字、回数、感情、結果。元の記録にないものが加わっていないかを確認します。

ここまで確認して、ようやく完成です。

メモを増やすより、変換する入口を固定する

以前の私は、記事が書けないとメモが足りないと思っていました。

実際には逆でした。

メモはすでにある。足りなかったのは、どの問題に使うかを決め、根拠を選び、事実を守ったまま文章へ運ぶ工程です。

Obsidianは、保存するだけならメモ帳です。Claude Codeも、丸投げするだけなら文章生成ツールです。

この2つがつながるのは、間に順番を置いたときでした。

問題を決める
→ 根拠を探す
→ 事実を分ける
→ 設計図を作る
→ 下書きと元メモを照合する

最初からVault全体を整理する必要はありません。

まず、今書きたい問題を1つ決めてください。そしてClaude Codeに、答えではなく根拠を3件だけ探させてみてください。そこが、メモが記事へ変わり始める入口です。

最後まで読んでいただき、ありがとうございます。