※この記事は、2026年8月時点の自分のObsidianとAIブログ運用について書いたものです。仕組みは今も調整中であり、今回の修正で取りこぼしが完全になくなったわけではありません。
最近、ブログの下書きをAIと確認している時に、少し引っかかることがありました。
「昨日残したメモは参照した？」
そう聞いて確認すると、整理済みの資料は読んでいましたが、元のメモまでは戻れていませんでした。
別の日には、別チャットで「これはブログ素材として残しておいて」と渡した内容が、次のネタ出しで候補に入っていませんでした。
素材が消えたわけではありません。
Obsidianの中には、ちゃんと残っていました。
それでも、AIが読みに行く経路に乗っていなかった。
自分はこれまで、情報をObsidianへ保存し、AIが必要な時に読めるようにすることを重視してきました。
ただ、今回の件で、保存できていることと、次のAIが見つけられることは別問題だと改めて分かりました。
普段の依頼は、かなり大ざっぱだった
自分が毎日ブログ担当のAIへ頼んでいる内容は、だいたい同じです。
「INBOXの整理と、今日のネタ出しをお願いします」
自分としては、この一言の中にかなり多くの意味を含めています。
- INBOXの新しいメモを見る
- 別チャットから引き継いだ内容を見る
- 過去ログも確認する
- 公開済みの記事と重複していないか調べる
- 今のブログに合う候補を選ぶ
ただ、AI側がこの範囲を勝手に理解してくれるわけではありません。
そこで、これまでに入口ファイルやブログ用のスキルを作り、「整理して」「ネタ出しして」の一言から同じ手順へ入れるようにしていました。
毎回、自分がフォルダ名や確認手順を細かく指定する必要はありません。
普段の使い勝手としては、それでかなり楽になっています。
それでも今回、保存済みの素材が候補から落ちました。
「最近のメモを見る」では、範囲が決まっていなかった
原因を確認すると、スキルには「最近のWorkBenchを見る」という趣旨の指示がありました。
一見すると、それで十分に見えます。
ただ、改めて考えると「最近」が何日分なのか決まっていません。
WorkBench以外のdailyやチャット引継ぎは含むのか。
中央の入口からリンクされていないメモは、どうやって見つけるのか。
長い会話ログは、どこまで戻るのか。
公開済みの記事やprivateな素材まで、候補として混ぜるのか。
こうした部分が、AIのその場の判断に残っていました。
人間同士なら「最近の資料も見ておいて」で、なんとなく通じるかもしれません。
しかしAIにとっては、探索範囲が決まっていない指示です。
その時に目についたファイルは読めても、自分が重要だと思っている素材まで必ず届くとは限りません。
入口ファイルを作るだけでは足りなかった
以前、AIに毎回同じ説明をするなら、入口ファイルを作る方が安定するという記事を書きました。
この考え自体は、今も変わっていません。
入口ファイルがあれば、AIは最初にどこを見て、どの情報を優先すればよいか分かります。
ただし、入口ファイルはあくまでスタート地点です。
そこに全ての素材へのリンクが常に追加されているとは限りません。
今回のように、別チャットで生まれたブログ素材がWorkBenchへ保存されても、入口側へ引き継がれていなければ、そのまま埋もれる可能性があります。
入口を作ることと、入口から外れた素材を定期的に探すこと。
この二つは別に必要でした。
素材を作る側と、使う側の両方を直した
今回の修正は、大きく二つに分けました。
一つ目は、素材を作った側の引継ぎです。
別チャットで「ブログ素材」「記事ネタ」と明示した内容は、そのチャットの中だけで終わらせず、ブログ候補を確認する棚へ渡すようにしました。
ここでは、いきなり記事候補として確定しません。
投資、仕事、家族、講座などの内容が混ざることもあるため、まずは「確認待ち」として置きます。
二つ目は、素材を使う側の探索です。
ブログ担当へ「最近のメモも見て」と書くだけでなく、直近14日分の範囲を一覧化する小さな処理を追加しました。
対象は、WorkBench、topics、daily、チャット引継ぎ、チャットアーカイブなどです。
さらに、入口ファイルやブログ候補一覧から参照されていない素材を、先に表示するようにしました。
これなら、入口へのリンクを追加し忘れた素材も、人間が確認する候補には出しやすくなります。
59ファイルを見つけても、59個の記事ネタではない
2026年8月19日に試した時は、直近14日分から59ファイルが一覧に出ました。
そのうち、既存の入口から参照されていないものは9件ありました。
数字だけ見ると、かなりの素材を発見したように見えます。
ただし、9件全てがブログ記事に使えるわけではありません。
中には、すでに公開済みの記事の元メモもありました。
仕事のノウハウに近く、そのまま公開しない方がよいものもありました。
個人開発や投資に関するprivateな内容もあります。
AI講座の資料のように、参照には使えても本文を公開できないものもあります。
そのため、今回追加した仕組みは、記事を自動で決めるものではありません。
あくまで、見落としていた可能性のある素材を、人間が確認できる場所まで戻す仕組みです。
発見と採用を分けておかないと、今度は見つけた素材を全部記事にしようとして別の問題が起きます。
入口、スキル、一覧化処理は役割が違った
自分は普段、「整理して」「ネタ出しして」と一括りでAIへ頼んでいます。
そのため、使う側としては入口ファイル、スキル、一覧化処理を細かく意識していません。
ただ、今回の失敗を整理すると、裏側では役割が違っていました。
- 入口ファイルは、今の状況と最初に読む場所を伝える
- スキルは、どんな順番と基準で作業するかを決める
- 一覧化処理は、実際にどこまで探したかを固定する
入口ファイルだけでは、探索漏れを検出できません。
スキルに「全体を見る」と書くだけでも、対象範囲は曖昧なままです。
逆に、一覧化するだけでは、どれを採用するか判断できません。
三つを組み合わせて、ようやく普段の短い依頼から同じ流れを再現しやすくなりました。
AIに全部読ませることが目的ではない
今回、探索範囲を明確にしましたが、Obsidianの全ファイルを毎回AIへ読ませたいわけではありません。
保存量が増えるほど、全件確認は重くなります。
古い情報、確定前の仮説、privateな内容まで一度に混ぜれば、かえって判断しにくくなります。
だから、まず直近14日の範囲を機械的に一覧化する。
そこで候補を絞り、必要なファイルだけ追加で読む。
過去ログを深掘りする場合も、一度に全部ではなく、その日の対象を限定する。
自分には、このくらいの方が合っています。
「全体を見る」を、全ての本文を読むという意味ではなく、確認対象の地図を一度作るという意味へ変えた形です。
まとめ
今回、別チャットで保存したブログ素材が、次のネタ出しで候補から落ちました。
素材は消えていませんでした。
保存場所にはあったのに、次のAIが読みに行く経路と探索範囲が決まっていなかったのが原因です。
そこで、次の二つを追加しました。
- 素材を作った側が、決まった確認棚へ引き継ぐ
- 素材を使う側が、決まった期間と場所を一覧化し、未参照を報告する
自分が毎回入力する言葉は、これまでと同じです。
「INBOXの整理と、今日のネタ出しをお願いします」
変えたのは、その一言を受け取った後にAIが確認する範囲です。
AIへ情報を渡す時は、保存先を作るだけでは足りない。
次に誰が、どの範囲を、どうやって探すのかまで決める。
今回の取りこぼしで、その部分がようやく具体的になりました。
コメント