クイックノートで特定のフォルダに新しくメモを作成する。作ったはいいものの、tagsで要素を決めてMoverで移動させるにも考える必要があるから面倒になる。
これは1箇所ですべてを賄おうとしているから起きる話で、inboxから他へ移動させるためには、メモを整理する仕組みそのものが必要だと考えた。
あなたはどうだろう。inboxに溜まったメモ、定期的に空にできている派？ それとも見ないふりをしている派？
私は完全に後者だった。ただ数えてみたら、怠けているというより仕組みの設計が悪かっただけだとわかった。
発端：inboxが「置き場」ではなく「墓場」になっていた
Obsidianのクイックノートは 07_workspace/00_Memo/_inbox に一次受けしている。思いついたことをすぐ書けるのはいいのだが、書くコストが低い分だけ溜まるスピードが処理するスピードを上回る。
一応、仕組みはあった。frontmatterに #防音Lab のようなブログタグを付けると Auto Note Mover が対応フォルダへ運んでくれる。理屈の上では自動化されている。
理屈の上では。
実際に数えたらこうだった。
| tags | 件数 |
|---|---|
note のみ | 139 |
| その他（standfm / ClaudeCode / GA4 など） | 5 |
144件中139件がデフォルトの note のまま。 タグで動く仕組みなのに、タグが付いていない。自動化の前提そのものが成立していなかったわけだ。
なぜ付けないのか。付けるのが面倒だから、ではない。タグを1つ選ぶという行為が、実際には「このメモは何なのか」「どのブログに載るのか」「そもそも記事になるのか」を同時に判断させられるからだ。メモを開くたびにこの3つを考えるなら、そりゃ後回しになる。
診断：溜まる原因は「1件あたりの判断コスト」だった
144件を眺めてわかったのは、メモの熟度がきれいに4層へ分かれていることだった。
| 層 | 件数 |
|---|---|
| 種メモ（15行未満・問いだけ） | 40 |
| 育ちかけ（15〜39行） | 37 |
| 記事化圏内（40〜99行） | 40 |
| レポート級（100行超） | 28 |
「スイスはなぜ秘匿性の高い銀行があるのか」の10行と、「エリート・アスリートの食事法」の343行が、同じフォルダに同じ顔で並んでいる。この2つを同じ手順で処理しようとするから止まる。
つまり問題は「整理していないこと」ではなく、整理という作業が1件ごとに重すぎることだった。ここを分解すれば動くはずだ。
構想：判断と移動を分ける
出した結論はシンプルで、「分類する」と「移動する」を別のコマンドに割るというもの。
_inbox/ ← 未処理（クイックノートの着地点）
↓ /inbox-triage 判定を書き込むだけ。行き先へは動かさない
_triaged/ ← 判定済み・行き先待ち
↓ /inbox-flush 判定に従って機械的に移動。新たな判断はしない
各destination（ブログ / 09_Knowledge / 06_resource / 99_Planning …）分けるメリットは2つある。
1つ目は、判定フェーズでは「移動先が正しいか」を悩まなくていいこと。とりあえず判定を書き込むだけなので、間違っていても後から直せる。ファイルはまだ動いていない。
2つ目は、フォルダの残数がそのまま進捗になること。_inbox に何件あるかが未処理件数で、それ以外に指標を持つ必要がない。
実装：AIに読ませる範囲を2要素に絞る
ここが一番効いた設計判断だと思っている。
自分のメモは、Templaterの都合で全件が同じ構造をしている。ファイル名がそのままH1で、その下に > [!important] のcalloutが1つ。
そして気づいたのだが、メモのネタは必ずこの2つに入っている。タイトルは自分が付けた問いそのものだし、importantには書いた瞬間の意図が入っている。本文は後から膨らんだ枝葉でしかない。
実際に測ったら、144件中130件（90%）のimportantに実テキストが入っていた。
だからAIに読ませるのは「ファイル名 + frontmatter + importantブロック」だけでいい。本文全体は読ませない。
これは効率の話に見えて、精度の話でもある。343行のメモを全部読ませると、AIは本文の細部に引きずられて「このメモは何なのか」を見失う。タイトルとimportantだけ渡したほうが、書いた本人の意図に近い判断が返ってくる。
20件で試したところ、判定不能はゼロだった。10行のメモも343行のメモも、同じ2要素だけで判定できた。
実装：判定は「分類」ではなく「アドバイス」を本体にする
当初は type: content のような分類ラベルを付けるだけのつもりだった。でもそれだと、ラベルが付いただけでメモは1ミリも前に進まない。
そこで、書き戻す内容の主役を「このメモをどう発展させるべきか」に変えた。分類はその副産物という位置づけにする。
実際の出力がこれ。
> [!tip] 発展の指標
> 判定: コンテンツ作成 → namagomi-techo（stage: seed）
> 方向性: 生ごみ処理機ブログの購入動機そのものを扱えるテーマ。一般論ではなく浜松市の有料化状況を軸にすると、地元検索に刺さる。
> 次の一手: 浜松市の指定ごみ袋の価格と近隣市の価格を調べる
> 不足: 自治体の一次情報、有料化前後のごみ量データ元のメモは「ごみ有料化による問題と課題について」で、importantには「まとめるべきだなと思った」の一行しか書いていない。それでも切り口まで戻ってくる。
ルールとして効いたのが「次の一手は動詞で終わる1文にする」「検討する・考えるは禁止」の2つ。「〜を検討する」で終わると、結局また判断が必要になって元の木阿弥になる。「浜松市の指定ごみ袋の価格を調べる」まで落ちていれば、5分あれば手が動く。
実装：データはfrontmatterに、指標は本文に
判定結果は2箇所に書き分けている。
---
created: 2026-06-18 19:29
updated: 2026-08-07
tags:
- note # ← 触らない（後述）
type: content # content | idea | task | resource | knowledge
stage: ready # seed | ready
dest: namagomi-techo
triaged: 2026-08-07
---frontmatterは機械が読む用。Obsidian Basesやdataviewで「type=content かつ stage=ready」のように絞り込める。
[!tip] は人間が読む用。フォルダを開いてメモを見たとき、次に何をすればいいかが目に入る。
type（何であるか）と stage（今すぐ動かせるか）を別プロパティにしたのもポイントで、1軸だと「記事化圏内40件」と「種メモ40件」が同じ content に混ざって、結局また選別が発生する。2軸なら「contentかつready」だけを取り出せる。
落とし穴：自動化ツール同士がぶつかる
これは事前に気づけてよかった点。
Auto Note Mover の設定を見たら trigger_auto_manual: "Automatic" になっていた。つまり tags にタグを書いた瞬間にファイルが移動する。登録されているのは11ルール。
| tag | 移動先 |
|---|---|
#防音Lab #釣！浜名湖 #海上アングラー #シラバスハック #生ごみ手帖 #344net #ビジネス解剖 | 各ブログフォルダ |
#task | _task |
#archive | 22_Archives |
#自己啓発 #自分メモ | 06_resource / 03_assets |
もし判定を tags に書く設計にしていたら、triageした瞬間に全ファイルが飛び散って、「判定と移動を分ける」という設計思想そのものが壊れていた。
対処は単純で、判定は type / stage / dest という独立プロパティに書く。Auto Note Mover はタグしか見ないので反応しない。
そして逆手に取れる。flush（実際の移動）のときはタグを付けるだけでAuto Note Moverが運んでくれる。既存の自動化を壊さず、乗る。
自動化を足すときは、既に動いている自動化の発火条件を先に確認する。便利なプラグインが勝手に動くのは、意図しないタイミングでは事故になる。
落とし穴：思い込みで判定基準を作りかけた
もう1つ、実測に救われた話。
> [!important] の中身が > ノートの要約 というプレースホルダのまま放置されているメモが14件あった。最初は「中身が空なんだから全部アーカイブでいい」と決めかけた。
実際に行数を数えたら、こうなっていた。
| 区分 | 件数 | 例 |
|---|---|---|
| 本文もない | 7 | 次にやりたいことがないな（10行） |
| importantは空だが本文が育っている | 7 | エリート・アスリートの食事法（343行）、乳酸値測定デバイスに関する調査レポート（109行） |
半分は中身がしっかりあった。importantを埋め忘れただけで、343行のレポートをアーカイブに放り込むところだった。
さらに、残る7件も捨てるべきではないと考え直した。「スイスはなぜ秘匿性の高い銀行があるのか」は本文こそ空だが、タイトル自体が良質な問いになっている。むしろこういうメモこそAIに方向性を出してもらう価値がある。
結果、archive は自動で付けない仕様にした。捨てる判断は人間がやる。
一括処理のルールを作る前に、1回数える。144件を相手にするとき、思い込みの誤差は7件の取り返しのつかない削除になる。
実装：デイリーノートから見えるようにする
ここまでで仕組みは動くが、見に行かないと存在を忘れるという根本問題が残る。inboxが墓場になったのと同じ理由だ。
なので、triageしたメモにはチェックボックスを1行足すようにした。
- [ ] 【未整理】**ごみ有料化による問題と課題について**これをデイリーノートのdataviewで拾う。
## 未整理メモ（triage済み・行き先待ち）
```dataview
TASK
FROM "07_workspace/00_Memo/_triaged"
WHERE !completed AND contains(text, "【未整理】")
SORT file.ctime ASC
LIMIT 15
```「【未整理】」というマーカーを付けているのには理由がある。メモの中には「気になる本20260519」のように、本文に読書リストの - [ ] を20個以上持っているものがある。マーカーなしでTASKクエリを書くと、デイリーノートが本のタイトルで埋まる。
もう1つ引っかかったのが、既存の「Task：no-complete」クエリが FROM "01_diary" に限定されていたこと。メモ側にチェックボックスを置いただけでは拾われないので、専用セクションを別に作る必要があった。
dataviewのTASKクエリを増やすときは、既存クエリのFROM範囲と本文に元からある - [ ] の2つを確認する。片方を見落とすと「表示されない」か「表示されすぎる」のどちらかになる。
結果：20件流してみた
created の古い順に20件でテストした。
| type | 件数 | stage | 件数 | |
|---|---|---|---|---|
| content | 10 | ready | 11 | |
| knowledge | 7 | seed | 9 | |
| idea | 1 | |||
| resource | 1 |
判定不能ゼロ、タグの誤爆ゼロ、[!important] の改変ゼロ。処理そのものは想定通りに動いた。
面白かったのは、結果を見て設計のほうに疑いが出たことだ。
type: task が1件も出なかった。5分類のうち1つが空振りしている。自分のinboxは思索メモが主体で、実行タスクはそもそも流入していないのかもしれない。残り126件を流しても出なければ、4分類に縮めるのが正しいはずだ。
content の行き先が344netに8件集中した。専門5ブログのテーマに乗らないものの受け皿になっている。これは分類の問題ではなく、344net側にカテゴリ設計が要るという話だろう。
このあたりは20件流さないと絶対にわからなかった。設計書を完璧にしてから実装するより、20件で殴ってみたほうが早い。
未解決のまま残していること
冒頭に書いた通り、これは正解ではない。現時点で未解決の点を並べておく。
flush（実際の移動）はまだ実装していない。20件の判定精度を見てからにした。344netへの集中を見るに、残り126件を流して分布を確定させてからのほうが手戻りが少ないと考えている。
type の5分類は多い可能性が高い。task が空振りしているのが気になっている。
週次で回して新規流入と釣り合うかも未検証だ。計算上は週1回20件で足りるはずだが、実際に3ヶ月続くかは別問題。
そもそも「AIに方向性を出してもらう」こと自体が正しいのかという問いも残る。自分で考えるべきことを外注しているだけかもしれない。ただ、144件を前に手が止まっている状態よりはマシだと今は判断している。
作業中にも2件、新しいクイックノートが増えた。仕組みを作っている間にも流入は止まらない。そういうものだと思って付き合うしかないのだろう。
まとめ：数えてから仕組みを作る
inboxが溜まる原因は怠慢ではなく、1件あたりの判断コストが重すぎることにあった。
144件を数え、熟度で4層に分け、判定と移動を別コマンドに割ったことで、20件のテストでは判定不能ゼロ・誤爆ゼロという結果につながった。それでも task 分類の空振りや344netへの集中など、20件流したからこそ見えた誤算も残っている。
設計を完璧にしてから動かすより、少数で殴ってみて穴を探すほうが結局早いんじゃないかなと思っている。
