※この記事は、2026年4月にAIと作ったObsidian用の小さなPythonツールを、2026年9月に振り返って整理した実運用メモです。現在の整理方法とは一部異なります。
以前、AIに手伝ってもらいながら、Obsidianのdailyとinboxから使えそうなメモを拾う小さなツールを作りました。
元のノートは変更せず、条件に合った行だけを別のMarkdownへ一覧化する練習用のツールです。
当時の記事では、主に「元ノートを壊さず、安全に一覧化するところから始めた」という話を書きました。
ただ、久しぶりに当時のログを読み直してみると、その途中でもう一つ大事な失敗をしていました。
候補を拾う条件と、拾った候補を分類する条件を一緒にしてしまったことです。
結果だけ並べると、抽出件数はこう変わっていました。
0件 → 2,218件 → 55件 → 479件 → 55件 → 50件 → 28件
かなり落ち着きのない数字です。
でも、この数字の揺れを追ったことで、AIに整理ツールを作らせる時は、単にキーワードを増減するより、「拾う」と「分類する」を別の仕事として設計した方がいいと分かりました。
最初は0件だった
最初に作ったツールは、dailyとinboxを読み、ブログやアイデアの候補になりそうな行を探して、_generatedへ一覧を出すだけのものでした。
元のノートを書き換えないので、失敗しても生成物を消せば戻せます。
ところが、最初に動かした結果は0件でした。
AIにコードを書いてもらったものの、想定していたフォルダ構成と実際のVault構成が違っていました。さらに、検索条件も自分のメモに使っている言葉と合っていませんでした。
コードそのものは動いているように見える。
でも、見に行く場所と探す言葉がずれていたので、何も見つからない。
まずはパスを実際の構成に合わせ、dailyとinboxを読めているか確認するところからやり直しました。
見落としを減らそうとしたら2,218件になった
参照先を直した後は、候補を拾うためのキーワードを増やしました。
0件だったので、条件が狭すぎると思ったからです。
すると今度は、2,218件まで増えました。
確かに見落としは減ったのかもしれません。
ただ、ここまで増えると一覧としてはほとんど読めません。候補を探すために作ったはずなのに、その一覧の中からもう一度候補を探す作業が必要になります。
これでは、Obsidian内を直接検索するのとあまり変わりません。
AIに「もっと拾って」と頼めば、拾えるものは増えます。
しかし、拾える量が増えることと、使える一覧になることは別でした。
55件まで絞ったのに、分類を足すと479件へ戻った
そこで、抽出に使う言葉を見直し、候補らしいものだけを拾うように調整しました。
結果は55件です。
まだ多いかもしれませんが、2,218件に比べれば中身を確認できる量になりました。
次に、拾った候補をブログ、AI活用、情報整理といった種類へ分けたくなりました。
ここで失敗しました。
分類に使う言葉まで、候補を拾う条件へ入れてしまったのです。
すると、55件だった一覧が479件へ再び増えました。
分類用の言葉には、広い意味で使える一般的な語が多く含まれます。
そうした言葉を入口の条件にすると、「すでに拾った候補へ意味を付ける」のではなく、「その言葉を含む行を新しい候補として拾う」動きになります。
分類を細かくしたつもりが、入口を広げていたわけです。
「拾う」と「分類する」を別工程にした
そこで、条件を二つに分けました。
- 抽出条件: 候補として拾うかどうかを決める
- 分類条件: 拾った候補をどの種類へ置くか決める
流れにすると、こうなります。
daily / inboxを読む
↓
狭い条件で候補を拾う
↓
archiveや元データを除外する
↓
拾った候補だけを分類する
↓
_generatedへ一覧を出すこれで、分類条件を増やしても抽出件数まで勝手に増えにくくなりました。
当時の件数変化を整理すると、次のようになります。
| 段階 | 件数 | 状態 |
|---|---|---|
| 初回 | 0件 | パスと検索条件が実データに合っていなかった |
| 条件を広げた後 | 2,218件 | 拾えたがノイズが多すぎた |
| 抽出条件を絞った後 | 55件 | 中身を確認できる量になった |
| 分類語を抽出にも使った後 | 479件 | 一般語まで入口になり再膨張した |
| 抽出と分類を分離 | 55件 | 分類を足しても入口が広がらなくなった |
| archiveを除外 | 50件 | 古い整理ログが減った |
| 元データを除外 | 28件 | 当時の用途では見やすくなった |
最初から28件を目標にしていたわけではありません。
どの工程で数字が変わったかを見ながら、原因を一つずつ切り分けた結果でした。
28件が正解だったわけではない
ここは誤解しないようにしておきたいところです。
28件になったから、このツールが完成したわけではありません。
対象にしたノート、当時使ったキーワード、除外したフォルダが違えば、当然ちょうどいい件数も変わります。
しかも、最終的な一覧を見ても、「では今日どれを使うのか」までは分かりやすくなっていませんでした。
そのため、このツールは長く使い続ける完成品ではなく、ObsidianをPythonで安全に読んで整理するための練習台として一区切りにしました。
ただし、失敗だったとは思っていません。
価値があったのは28件という結果ではなく、
- 読み込み
- 抽出
- 除外
- 分類
- 出力
を別々に見られるようになったことです。
どこかがおかしくなっても、全部を作り直すのではなく、「今回は抽出条件が広がった」「除外が効いていない」と考えられるようになりました。
コードを全部読めなくても、件数の変化は見られた
当時の自分は、出てきたPythonコードを見ても正直かなり「わけわかめ」でした。
変数、ループ、パスの扱い、検索条件。
最初から全部を理解しようとすると、それだけで止まりそうになります。
でも、この段階で必要だったのは、自力で同じコードを最初から書けることではありませんでした。
少なくとも、
- どの部分が読み込みを担当しているか
- どこを変えると拾う条件が変わるか
- 分類条件を足した後に件数がどう動いたか
- 元ノートではなく生成先だけが更新されているか
は確認できました。
AIにコードを書いてもらっても、出力の変化までAI任せにすると、479件へ増えた理由に気づけなかったかもしれません。
コードを全部理解していなくても、入力、担当する工程、出力の変化を見ることで、修正の相談はできます。
少なくとも自分にとっては、それがAIと小さなツールを作る入口になりました。
今の「INBOXを整理して」にも同じ考え方が残っている
現在は、当時のPythonツールをそのまま使ってINBOXを整理しているわけではありません。
今は、整理の手順をスキルとして用意し、自分は「INBOXを整理して」とまとめて頼むことが多くなっています。
表面上は一つの依頼です。
ただ、内部では一つの巨大な判定にしていません。
長い原文はrawへ残す。
その中から再利用できそうな芯を拾う。
拾ったものを、今触る候補、育てる途中の素材、継続して参照する知識へ分ける。
ブログ候補なら、さらに既存記事との重複や公開してよい内容かを確認する。
やっていることは以前より増えましたが、「まず拾い、その後で分類する」という考え方は残っています。
使う側が毎回すべての工程を言わなくても、スキルの中では役割を分けておく。
この形なら、分類方法を変えたい時に、原文の保存や候補抽出まで巻き込まずに調整しやすくなります。
以前の記事とは、扱っている段階が違う
以前書いた「Obsidian自動化の最初は、dailyとinboxを安全に一覧化するところから始めた」は、元ノートを壊さず、別の場所へ一覧を出す最初の一歩が主題でした。
また、「ObsidianをAIに整理してもらうなら、『整理して』で動くルールを作るのが一番効いた」は、現在のINBOX、raw、workbenchなどを含む整理運用の全体像を書いたものです。
今回の話は、その間にあった実装上の失敗です。
安全に読めるようになった後、何を拾い、どう分類するか。
そこを一つの条件で済ませようとして、55件から479件へ逆戻りしました。
全体の運用ルールを説明する記事というより、整理の中にある二つの仕事を分ける必要があった、という実験記録です。
まとめ
AIにObsidianの整理ツールを作らせた時、最初は必要そうなキーワードを足せば良くなると思っていました。
しかし、条件を広げると0件から2,218件になり、いったん55件へ絞っても、分類用の言葉を入口へ混ぜると479件まで増えました。
そこで、候補を拾う条件と、拾った候補を分類する条件を分けました。
最終的に28件になったことより、工程ごとに結果を見て調整できるようになったことの方が大きかったと思います。
AIに一言で「整理して」と頼むとしても、AI側の仕事まで一つにまとめる必要はありません。
拾う。除外する。分類する。出力する。
使う側の依頼は短くしても、中の仕事は分けておく。
その方が、結果がおかしくなった時に、どこを直せばいいのか分かりやすくなりました。
コメント