Obsidianへメモをためていると、以前の計画、変更前の仕様、すでに解決した問題も検索結果に出てきます。人間なら日付や前後関係から「これは古い」と気付けますが、AIへ複数のメモをまとめて渡すと、古い内容を現在の事実として使うことがあります。
特に困るのは、古いメモの文章が詳しく、新しいメモが短い場合です。AIは詳しく書かれた方を重要な情報として扱い、すでに変更された方針を回答へ混ぜることがあります。
そこで私は、AIに読ませるObsidianメモの先頭へ、次の3項目を置くようにしました。
状態：現在有効
確認日：2026-10-11
出典：PUBLISH_SCHEDULE.json と公開ページ
たった3項目ですが、AIに「本文を読んで新旧を推測してもらう」状態から、「人間が確認した状態を読んでもらう」状態へ変えられます。
この記事では、状態、確認日、出典をどう使い、古いメモを消さずに現在地を分かりやすくするかを紹介します。
更新日だけでは現在有効か分からない
ファイルの更新日時が新しければ、内容も新しいとは限りません。
たとえば、過去の計画メモへ誤字修正を加えると、ファイルの更新日時は今日になります。しかし、計画そのものは採用されていないかもしれません。
反対に、数か月前に決めたルールが今も有効なこともあります。
2026-07-26に決定
外部公開の直前はHuman Approvalを必要とする
現在も有効
このルールは古い日付だから無効なのではありません。新しい決定で変更されていなければ、現在も使うルールです。
そのため、私はファイルの更新日時だけで新旧を判断しません。メモの中に「現在有効か」「いつ確認したか」「何を根拠にしたか」を書きます。
1. 状態を書く
最初の項目は状態です。細かく増やしすぎると迷うので、私は次の4つを使います。
| 状態 | 意味 |
|---|---|
| 現在有効 | 今の作業で事実やルールとして使う |
| 履歴 | 当時は有効だったが、現在の判断には直接使わない |
| 確認待ち | 内容はあるが、現在も正しいか未確認 |
| 下書き | AIまたは人間が作成中で、正式な情報ではない |
たとえば、公開済みの記事記録なら次のようにします。
状態：現在有効
内容：Vol.69は公開済み
公開前の原稿なら、状態は下書きです。
状態：下書き
内容：Vol.70の記事案
AIが原稿を書き終えただけで「公開済み」にはしません。Qiitaへ投稿し、公開ページを確認したあと、人間が状態を更新します。
状態が書かれていない古いメモは、AIに推測させず「確認待ち」として扱います。
2. 確認日を書く
2つ目は確認日です。これは「ファイルを編集した日」ではなく、「人間が内容を確かめた日」です。
確認日：2026-10-11
確認したこと：公開URL、記事ID、投稿者、投稿日、タグ
確認日があると、AIは情報の鮮度を比較できます。ただし、確認日が新しいだけで正しいとは限りません。何を確認したのかも一緒に残します。
たとえば、タイトルだけ確認した記録から、本文やタグまで確認済みだとは言えません。
確認日：2026-10-11
確認範囲：タイトルのみ
本文：未確認
タグ：未確認
このように書けば、AIが確認範囲を広げて解釈しにくくなります。
定期的に変わる情報には、次回確認の条件も付けます。
次回確認：新しい記事を公開したとき
毎日すべてのメモを見直す必要はありません。内容が変わる出来事を、再確認のきっかけにします。
3. 出典を書く
3つ目は出典です。「どこに書いてあるか」だけでなく、「何を確認するための出典か」も残します。
出典：docs/qiita/PUBLISH_SCHEDULE.json
確認できること：記事の予定日、状態、記事ID、公開URL
出典：Qiitaの公開ページ
確認できること：公開中のタイトル、投稿者、投稿日、タグ、本文
出典がなければ、AIが書いた要約を別のAIが事実として再利用し、いつの間にか根拠が分からなくなることがあります。
一次情報を確認できる場合は、そのファイル名、URL、記事IDなどを残します。ただし、URLに認証情報や秘密のパラメータが含まれる場合は、メモへ貼りません。顧客情報や個人情報も、AIへ渡す共有範囲から除外します。
出典へアクセスできないAIを使う場合は、「出典あり」と「そのAIが確認済み」を混同しません。
出典：公開ページURLあり
AIによる確認：未実施
人間による確認：2026-10-11に実施
3項目をメモの先頭へ置く
状態、確認日、出典は、本文の最後ではなく先頭へ置きます。
---
状態: 現在有効
確認日: 2026-10-11
出典: docs/qiita/PUBLISH_SCHEDULE.json
次回確認: 新しい記事を公開したとき
---
# Qiita公開の現在地
最新公開：Vol.69
公開URL：...
Obsidianのプロパティとして書いても、普通の本文として書いても構いません。大切なのは、AIが本文を要約する前に状態を読める位置へ置くことです。
Markdownなので、ローカルファイルを参照できるChatGPT、Claude、Cursorなど、異なるAIへ同じメモを指定しやすくなります。特定のAIだけが覚えている状態を減らし、原本に書かれた現在地から始められます。
ただし、ObsidianのファイルをAIが自動的に読めるわけではありません。利用するAIにローカルファイルへのアクセス機能と適切な権限が必要です。Vault全体ではなく、作業に必要なフォルダやファイルだけを指定します。
古いメモは削除せず「履歴」にする
古い情報を見つけても、すぐ削除しません。当時の判断理由が、あとで役立つことがあるからです。
たとえば、以前の方針を次のように更新します。
状態：履歴
当時の確認日：2026-09-01
現在の情報：DECISIONS/2026-10-10-article-source.md を参照
変更理由：複数AIで使う原本の場所を明確にしたため
古いメモから現在のメモへの参照を付ければ、AIも人間も次に読むべき場所が分かります。
一方、同じファイルの本文だけを新しい内容で上書きすると、なぜ判断が変わったのか分からなくなります。削除や大量の書き換えは、人間が差分を確認してから行います。
AIには判定ではなく「要確認一覧」を作ってもらう
すべてのメモへ手作業で3項目を付けるのは大変です。そこで、AIには対象フォルダを限定して、情報が不足しているメモを探してもらいます。
指定したObsidianフォルダ内のMarkdownを確認してください。
各ファイルについて、次を一覧にしてください。
- ファイル名
- 記載されている状態
- 確認日
- 出典
- 現在の情報への参照
- 人間の確認が必要な点
ルール：
- 状態がなければ「確認待ち」とする
- 更新日時だけで「現在有効」と判断しない
- 出典が読めない場合は確認済みにしない
- 古いメモを削除、移動、上書きしない
- 日付や出典を推測で補わない
- 個人情報、顧客情報、認証情報を出力しない
最後に、状態、確認日、出典が不足しているファイルだけを
要確認一覧としてまとめてください。
AIの役割は、古いメモを勝手に整理し終えることではありません。人間が見るべき候補を減らすことです。
一覧を確認したあと、人間が「現在有効」「履歴」「確認待ち」を決めます。AIには、承認された結果だけをメモへ反映してもらいます。
日次メモは無理に全部更新しない
日次メモは、その日の記録です。過去の日次メモまで現在の状態へ書き換えると、当時何が起きたか分からなくなります。
そのため、日次メモは履歴として残し、現在地をまとめるファイルを別にします。
daily/2026-10-10.md 当日の記録
CURRENT_CONTEXT.md 現在有効な情報
DECISIONS/... 判断と変更理由
PUBLISH_SCHEDULE.json 公開状態の記録
AIには最初にCURRENT_CONTEXT.mdを読ませ、必要なときだけ日次メモや意思決定記録へ戻ってもらいます。
すべてを最新に書き換えるより、現在地と履歴の役割を分けた方が、AIへ渡す情報を少なくできます。
まとめ
Obsidianのメモは増えるほど便利になりますが、古い内容と現在の内容が混ざると、AIが過去の計画を今の事実として使うことがあります。
そこで私は、AIに読ませるメモの先頭へ次の3項目を置きます。
- 状態：現在有効、履歴、確認待ち、下書き
- 確認日：人間が何を確認した日か
- 出典：どのファイルや公開ページを根拠にしたか
さらに、古いメモは消さずに履歴とし、現在の情報への参照を付けます。AIには状態を決めさせず、不足している項目と要確認候補を整理してもらいます。
AIに大量のメモを読ませる前に、人間が確認した現在地を短く示す。これだけで、AIが違っても同じ原本から作業を始めやすくなります。
この記事は、Obsidianを複数AIで参照できるMarkdownの原本として使い、現在地、履歴、出典、Human Approvalを分けてきた本プロジェクトの運用をもとに構成しました。