- メモの分類 - メモの検索 - メモの探索（ふと目に入ってメモを漁るなど） - 耐用数（その方法で限界が来そうな境界） - Publish（Obsidian Publishの適正） - AI（Claude Codeなどが扱い安いか） - メモの長短適正（メモの長短で検索戦略が変わる） | 方法 | 分類 | 検索 | 探索 | 耐用数 | Publish | AI | メモの長短適正 | | ------------------------- | --- | --- | --- | ------------ | ---------------- | -------------------- | -------------------------- | | フォルダ | ◎ | △ | - | 〜ファイル1000 | ◎（構造がそのままURLに反映） | 低（パス文字列は意味が薄い） | 長文向き（枚数が少なくて済む） | | タグ | ◎ | ○ | △ | 〜タグ100 | △（表示に癖あり） | 中（表記ゆれに弱い） | 短文でも可、ただし総数管理が要る | | 自由リンク<br>バックリンク（2Hop） | - | - | ◎ | 数千〜 | ◎（主力の探索導線） | 高（グラフを辿らせやすい） | 短文向き（1メモ1トピックと相性◎） | | MOC | ◎ | △ | ◎ | 1MOCあたり20〜50 | ◎（ポータル・目次として最適） | 非常に高（1枚で目次+ポインタ） | 短文向き（ただしMOC自体は長くなりがち） | | フロントマターDB（Bases/Dataview） | ◎ | ◎ | - | 無制限 | ×（未実装） | 低〜中（クエリ結果をAIが直読できない） | 長さ無関係（メタデータ設計次第） | | 全文検索 | - | ◎ | - | 数千枚〜（ノイズ増加） | △（全文検索のみ・ノイズ大） | 低（直接呼べない、経由なら中） | 長文向き（短いとヒット過多でノイズ増） | | ベクトル検索 | - | △ | ◎ | 数万〜十万メモ | ×（基本未対応） | 非常に高（AI由来技術） | 長文向き（300字は薄すぎ、500〜1000字推奨） | 補足として2点だけ： - **Publishの◎/×は運用インターフェースとしての話**で、「機能として動くか」（フロントマターDB・ベクトル検索は動かない）と「表示形式として向いているか」（フォルダ・リンク・MOCは向く、全文検索は動くけどノイズが多い）が混ざってる点は注意してください。 - **AI列の「フロントマターDB＝低〜中」は今回の対話で一番意外だった発見**だと思ってます。人間向けの利便性（GUIでフィルタ）とAI向けの利便性（機械可読な出力）が逆相関する珍しいケースなので、AI運用を主軸に置くなら他の手法（特にMOC・ベクトル）で代替できないか検討する価値がありそうです。 ## リンク - [[Obsidianのファイル分類・検索方法のメリット・デメリット]]