※この記事は、2026年8月時点の自分のAI・Obsidian運用について書いた実運用メモです。
AIと話していると、その場だけで終わらせるにはもったいない内容が出てきます。
次回も使いたいルール。 別のAIへ渡したい前提。 あとで試したい改善案。 ブログに使えそうな気づき。
以前は、こうした内容が別のチャットへ移るたびに抜けていました。
そこで、AIとの会話から必要そうな情報を抜き取り、Obsidianへ「反映候補」として残す仕組みを作りました。
会話の内容をいきなり確定情報にするのではなく、まず候補として保存する。 あとで人間が確認して、必要なものだけ正式なメモや運用ルールへ反映する。
この仕組み自体は動きました。
ただ、しばらく運用した結果、別の問題が出てきました。
未確認の候補が22件まで増えたのです。
そこで、20件を超えたら新しく集めるのを止める条件を入れました。
実際、候補はそれ以上増えなくなりました。
しかし、何度確認しても22件のままです。
止める仕組みは動いた。 でも、減らす仕組みにはなっていなかった。
今回は、自動収集を作った後で気づいた、その違いについて整理しておきます。
会話を直接記憶にせず、まず反映候補として残していた
AIとの会話には、いろいろな状態の情報が混ざっています。
- 今後も使いたい運用方針
- 今日だけ必要な作業
- まだ試していない改善案
- すでに別の場所へ反映済みの話
- 公開しない方がよい個人的な情報
- その場では重要に見えたが、あとで不要になる話
これを全部そのままAIの記憶として扱うと、古い作業や未確認情報まで現在の前提に見えてしまいます。
だから、自分の運用ではいったんraw側へ反映候補として残すようにしていました。
AIに任せるのは、忘れそうな情報を拾うところまでです。
確定情報として採用するか。 別のメモへ移すか。 重複として閉じるか。 今は使わないと判断するか。
そこは、あとで確認する前提でした。
安全側に寄せる意味では、この中間層は今でも必要だと思っています。
問題は、中間層を作れば確認まで自然に進むと思っていたことでした。
収集は動いたが、確認待ちが22件まで増えた
会話から候補を拾う仕組みを作ると、最初はかなり便利でした。
別チャットで話したことを忘れにくくなる。 繰り返し伝えたルールを拾える。 運用のずれや、入口から漏れている情報にも気づける。
ただし、候補を作る速度と、人間が確認する速度は同じではありません。
AIは会話のたびに候補を追加できます。
一方、人間側は候補を開いて、元の文脈を確認し、現在も有効か考えなければなりません。
すでに反映済みではないか。 別の候補と重複していないか。 今の運用とは矛盾していないか。 確定情報として扱ってよいか。
一件ずつ見ると小さな確認です。
それでも、後回しにしているうちに未確認候補は20件を超え、22件まで増えていました。
以前、Obsidian全体をAIに監査させた時にも、この状態を見て、
収集は回る。精査で止まる。
と感じました。
その時点で問題には気づいていましたが、気づくだけでは候補は減りませんでした。
20件を超えたら、新しい候補を作らないことにした
そこで追加したのが、収集の停止条件です。
未確認候補が20件以上ある時は、新しい候補を作らない。
代わりに、今ある候補の件数を確認する。 重複を探す。 すでに別の入口から読めるものを確認する。 次に人間が見るべき候補を提示する。
この条件を入れてから、監査のたびに候補が増える状態は止まりました。
AIが「重要そうな話を見つけた」と判断しても、似た内容がすでに残っているなら新しく作らない。
保存されているが見つけにくいだけなら、同じ内容を複製せず、入口の問題として扱う。
収集を止める条件としては、きちんと機能していたと思います。
少なくとも、22件が30件、40件と増え続ける状態は防げました。
増えなくなったが、22件は減らなかった
ここで、自分は少し勘違いしていました。
新しい候補を作らなければ、その間に既存の候補を整理できると思っていたのです。
しかし、7月中旬以降、何度か状態を確認しても未確認候補は22件のままでした。
増えてはいません。
ただ、減ってもいません。
考えてみれば当たり前です。
停止条件が決めているのは、これ以上入れないことだけです。
既存の候補を三件ずつ見せる。 似た候補をまとめる。 採用、保留、破棄を選びやすくする。 判断結果を正式な置き場所へ反映する。
こうしたレビューの手順までは作っていませんでした。
入口を閉じても、すでに並んでいる確認待ちが勝手に処理されるわけではありません。
停止条件は、問題を解決する仕組みではなく、悪化を止めるブレーキだったようです。
22件の中身を見ると、全部が新しい判断ではなかった
今回、改めて22件の内訳も確認しました。
すると、22件すべてが独立した新しいルールというわけではありませんでした。
古いブログの公開確認を追いかけている候補が三件。 投資判断向けで、公開ブログとは分けたい候補が三件。 AIの数字確認、根拠表示、権限分離などの運用候補。 自動化やツール設計に関する候補。 アーカイブや進路、ローカルLLMに関する候補。
さらに、近い内容をすでにブログ記事や別のメモへ反映していたものもありました。
つまり、未確認候補が22件あることと、未解決の重要判断が22件あることは同じではありません。
候補を作った時点では未確認でも、その後の別作業で同じ考え方を記事や運用へ反映することがあります。
しかし、元の候補の状態を閉じる工程がなければ、一覧上は未確認のまま残ります。
重複をまとめる。 反映済みなら閉じる。 privateな領域へ送る。 今も判断が必要なものだけ残す。
レビュー工程には、内容を読むだけでなく、こうした状態整理も必要でした。
自動収集、停止、レビュー、反映は別の工程だった
今回の運用を振り返ると、ひとまとめに「会話を自動で整理する仕組み」と考えていたこと自体が分かりにくかった気がします。
実際には、少なくとも四つの工程があります。
- 会話から残す価値がありそうな情報を拾う
- 未確認候補が増えすぎたら収集を止める
- 候補を確認し、採用、保留、破棄を決める
- 採用した内容を入口ファイルや運用ルールへ反映する
今の仕組みで比較的うまく動いていたのは、一番目と二番目です。
三番目のレビュー工程が弱いため、四番目の正式反映まで進みませんでした。
自動化を考える時は、入口の作業ばかり見てしまいます。
どう集めるか。 どう分類するか。 どう保存するか。
もちろん、そこも必要です。
ただ、集めた後に人間が何を見て、どの判断をすれば終わるのかまで決めないと、確認待ちという別のInboxが増えるだけでした。
レビューまでAIに任せればよいのか
ここまで来ると、候補の確認もAIへ任せればよいように見えます。
実際、重複候補をまとめる。 元の会話と現在のメモを比較する。 すでに反映済みの可能性を示す。 次に見る候補を数件だけ選ぶ。
このあたりは、AIに手伝ってもらえそうです。
ただし、最終的な採用まで自動化するのは、まだ少し怖いです。
当時は正しかったが、今は使っていない方針かもしれません。 個人的な判断を、全体のルールへ広げてはいけない場合もあります。 投資や仕事の話のように、保存場所や公開範囲を慎重に分けたい情報もあります。
AIには、判断材料を小さくして提示してもらう。
最後に採用するかどうかは、人間が決める。
自分の場合は、今のところこの境界が合っていそうです。
次に必要なのは、収集スキルより確認の入口かもしれない
今後は、収集する仕組みをさらに賢くするより、22件を確認できる大きさへ切る方を先に考えたいです。
たとえば、一度に全部を見せるのではなく、次に確認する候補を三件だけ出す。
各候補について、
- 元の文脈
- 現在も有効そうか
- 似たメモがあるか
- 反映先の候補
- 公開してよい内容か
を短く並べる。
その上で、人間が採用、保留、破棄を選ぶ。
まだ、このレビュー工程は完成していません。
ただ、未確認候補が増えた原因を収集精度だけの問題にしなくなったことで、次に直す場所は見えやすくなりました。
まとめ
AIとの会話から必要そうな情報を自動で拾う仕組みは、実際に動きました。
その一方で、確認する工程が追いつかず、未確認候補は22件まで増えました。
20件を超えたら新しく収集しない条件を入れた結果、それ以上の増加は抑えられました。
ただし、何度確認しても22件のままです。
今回分かったのは、停止条件とレビュー工程は別だということでした。
止める仕組みは、悪化を防ぐブレーキになる。
減らすには、候補を人間が判断できる大きさへ切り、採用、保留、破棄を決める入口が必要になる。
AIへ情報収集を任せるなら、何を集めるかだけでなく、集めた後に誰が、どの単位で、どう確認すれば終わるのかまで決めた方がよさそうです。
コメント