※この記事は2026年6月時点の実運用メモです。
※AIとの会話を完全自動で記憶させる方法ではなく、必要そうな情報を一度候補として抜き取り、あとで確認する運用の話です。
AIと作業していると、たまに不安になることがあります。
「これ、前にフィードバックしたっけ？」
ブログのネタ出しで気になったこと。
Obsidianの整理で直してほしかったこと。
次のチャットでも覚えておいてほしい注意点。
公開前に確認する必要があること。
その場では話していても、別のチャットへ移ると文脈が切れます。
だからといって、会話ログを全部そのままObsidianへ保存すればよいかというと、それも少し違いました。
会話の中には、確定した方針だけではなく、思いつき、未確認情報、一時的な感情、あとで不要になるタスクも混ざっています。
全部をそのまま「重要な記憶」として残すと、今度はAIが古い情報を信じてしまいます。
最近は、AIとの会話から必要そうな情報を直接保存するのではなく、一度「反映候補」としてrawへ抜き取るようにしています。
今回は、その運用を始めてみて分かったことを書いておきます。
会話の中で出た大事な話は、意外と次のチャットへ残らない
AIとの会話は、その場ではかなり自然につながります。
前の返答を踏まえて話せる。
少し曖昧な言い方でも補ってくれる。
何度かやり取りすると、自分が何を気にしているのかも伝わってくる。
ただ、その感覚のまま別のチャットへ移ると、急に前提が消えます。
自分の場合、ブログ運用でこれが何度か起きました。
「AIに直接関係しない記事は弱い」
「ネタ出しは新しいログだけでなく、過去ログも見てほしい」
「投資や競馬の具体判断は、そのまま公開ブログ候補にしない」
「関連記事はリンク付きにしたい」
「タグは半角カンマ付きで出してほしい」
その場で伝えれば、次の返答は直ります。
でも、次のチャットでも同じ前提が使われるとは限りません。
毎回同じ説明をするのは面倒ですし、自分自身も何を伝えたか忘れます。
この問題を減らすために、入口ファイルやスキルを作るようになりました。
ただ、入口ファイルへ何を追加するかを決める前にも、ひとつ段階が必要でした。
会話ログを全部保存すると、古い情報まで残ってしまう
最初に思いつくのは、会話ログを全部保存することです。
元の文脈が残る。
あとから検索できる。
別のAIにも読ませられる。
rawとして残すこと自体は、今でも大事だと思っています。
ただ、長い会話ログをそのまま次のチャットの前提にするのは危ないです。
会話の中には、いろいろな状態の情報が混ざっています。
- 今後も使いたい運用方針
- 今日だけ必要なタスク
- まだ確認できていない情報
- 公開しない方がよい個人的な話
- その場では気になったが、あとで不要になった話
- すでに別の場所へ反映済みの話
これを全部同じ重さでAIに読ませると、古いタスクや未確認情報まで「現在の前提」に見えてしまいます。
実際、自分のObsidianでも、ブログ記事の公開待ち情報が古いまま残っていることがありました。
別のファイルでは新しい記事へ進んでいるのに、チャット間の共有メモでは数日前の記事確認が残っている。
AIがそこだけを読むと、古い作業を今の最優先だと思いかねません。
保存することと、現在の前提として採用することは分けた方がよさそうでした。
そこで、まずrawへ「反映候補」として抜き取ることにした
最近は、会話や定時チェックから重要そうな情報が見つかった時、いきなり入口ファイルやinboxへ反映しないようにしています。
まず、raw/chat_handoff_extracts/ という仮置き場へ候補メモを作る。
ここに置くのは、確定情報ではありません。
「次のチャットへ渡した方がよさそう」
「この運用ルールは見直した方がよさそう」
「公開前に確認が必要そう」
「あとで記事にできるかもしれない」
そのくらいの段階です。
候補メモには、単に要約だけを書くのではなく、次のような情報を付けています。
- なぜ拾ったか
- 元の文脈は何か
- どこへ反映しそうか
- 信頼度はどのくらいか
- 何を確認する必要があるか
- 反映しない場合は、どんな理由があるか
さらに、handoff_check や workbench のような分類候補も付けます。
ただし、分類を付けても自動で反映はしません。
AIに任せるのは、「忘れそうなものを拾うところまで」です。
実際に、入口から漏れていた確認手順を拾えた
この運用を始めて、最初に拾えたのは、未精査の候補を見る導線が入口ファイルにないという問題でした。
自分のObsidianには、AIが最初に読む入口ファイルがあります。
そこには、inboxを見る、チャット間の共有メモを見る、必要ならworkbenchやtopicsを見る、といった読み順を書いています。
ただ、反映候補を置く場所を作っただけでは、次の整理時に誰も見ない可能性があります。
候補を保存したのに、候補の存在を確認する手順がない。
これは地味ですが、かなり大きな穴です。
そこで、Inbox整理時には未精査の反映候補も確認する、というルールを入口側へ追加しました。
この例は、会話ログの内容そのものを保存したというより、運用の不足を候補として拾い、確認後にルールへ反映した形です。
古い公開待ち情報も拾えたが、勝手には消さなかった
別の候補では、チャット間の共有メモに残っている公開待ち情報と、現在のブログ管理ファイルの状態がずれている可能性を拾いました。
共有メモでは、数日前の記事をWordPressへ貼る作業が残っている。
一方で、別のファイルでは、その後の記事の公開待ちキューまで進んでいる。
この状態なら、古い共有メモはもう不要かもしれません。
ただし、AIだけではWordPress側で本当に公開済みか確認できない場合があります。
ここで自動的に古いメモを消すと、まだ終わっていない作業を消す可能性があります。
だから、候補メモでは、
「古い可能性がある」
「WordPress側の実公開状態を確認する」
「確認できたら共有メモを整理する」
というところまでに留めました。
この距離感は大事だと思っています。
AIは、ファイル同士のずれを見つけるのは得意です。
でも、そのずれが本当に間違いなのか、外部サービス側の状態まで含めて確定するのは別の仕事です。
仕組みのルール自体がずれていることも見つかった
もうひとつ拾えたのが、反映候補メモのstatus語彙のずれでした。
運用ルールでは、
unreviewedreviewedpromotedignored
という状態を使うことにしていました。
ところが、実際の候補メモには reviewed_pending という別の状態が混ざっていました。
人間が見れば、なんとなく意味は分かります。
ただ、AIに判別させるなら、使う語彙が増えるほど判断がぶれます。
未精査として数えるのか。
確認待ちとして扱うのか。
精査済みとして除外するのか。
こういう小さなずれは、ファイルが少ないうちは気になりません。
でも、候補が増えると効いてきます。
会話内容だけでなく、仕組みそのもののずれも反映候補として拾えるのは、この運用の良いところでした。
自動収集で大事なのは、賢く確定することではなかった
AIに会話ログを整理させると聞くと、全部自動で覚えてくれる仕組みを想像しやすいです。
重要な話を自動で選ぶ。
適切なファイルへ自動で保存する。
次のチャットで自動的に思い出す。
うまく動けば便利です。
ただ、自分はそこまで自動化しない方が合っている気がします。
会話の中で重要に見えた話が、翌日には不要になることがあります。
未確認情報を、そのまま確定した前提にしたくないこともあります。
ブログ候補に見えても、既存記事と近すぎて出さない方がよいこともあります。
だから、自動収集の役割は、賢く整理することではなく、忘れそうなものを仮で拾うこと。
自動判別の役割も、正しい保存先を確定することではなく、確認する人の負担を少し減らすこと。
このくらいにしておく方が、AIに権限を渡しすぎずに済みます。
反映候補は、AIとの会話を記憶に変える前の中間層だった
今の自分の中では、AIとの会話をそのまま記憶として扱わないようにしています。
流れとしては、だいたいこうです。
- 会話やチェックから、重要そうな情報を見つける
- rawへ反映候補として抜き取る
- 分類候補と信頼度を付ける
- Inbox整理やハンドオフ整理の時に確認する
- 必要なものだけ入口ファイル、workbench、topics、decisionsへ反映する
この中間層があると、元の文脈を残しつつ、確定情報を汚しにくくなります。
全部を覚えさせるのではなく、覚える価値があるかを後で判断できる形にする。
AIに自分の文脈を渡す運用では、この段階が意外と大事でした。
まとめ
AIとの会話では、次のチャットにも渡したい話がよく出ます。
ただ、会話ログを全部そのまま保存すると、古いタスク、未確認情報、一時的な話まで現在の前提に見えてしまいます。
そこで最近は、必要そうな情報を直接保存せず、一度rawへ「反映候補」として抜き取るようにしています。
実際にこの方法で、
- 未精査候補を見る導線の不足
- 古い公開待ち情報の可能性
- status語彙のずれ
を拾うことができました。
ただし、AIには勝手に確定させません。
拾うところまで。
分類候補を付けるところまで。
反映するかどうかは、あとで確認する。
AIに全部覚えさせるより、忘れそうなものを仮で残す。
今のところ、そのくらいの距離感が自分には合っています。
コメント