この記事では、Windows環境のClaude Codeで実際に試した結果をもとにまとめています。

Obsidianでノートを書き始めたころは良かった。「あとで探すときのためにタグを付けとこう」——そう思って付けたタグ、今どうなってますか？ #アイデア、#idea、#アイディア。同じものが3つ並んでいることに気づいたとき、タグ設計は見直しどころだと分かります。Claude Codeに「タグとノートの命名ルールを整えて」と頼んでみたら、運用できるレベルのルールセットが固まりました。どこまでAIに任せられて、どこから自分で判断するのか——その境界線をこの記事で確かめます。

確かめること

Obsidianのタグとノートのファイル名——この2つをClaude Codeに任せて、運用しやすいルールがどこまで固まるかを試します。

ここでいう「運用しやすい」とは、ノートを書いたときに迷わずタグを付けられる、ファイル名を見るだけで中身が分かる、という状態のことです。範囲はタグの体系設計とノートの命名規則に絞り、既存ノートへの適用テストまで含めます。

Obsidianのフォルダ構成については別記事（CC-018）で扱っているので、この記事ではタグと命名に集中します。

やりたいこと——タグと名前がバラバラだとどう困るか

現状を整理します。

タグがバラバラになるパターンは大体決まっています。表記の揺れ（#アイデア、#idea、#アイディア）、粒度の不一致（#仕事 と #仕事/会議/議事録 が混在）。自分では「同じタグを付けているつもり」でも、Obsidianの検索はこれらを別物として扱います。

ファイル名も同じ問題を抱えがちです。「メモ」「考えたこと」「20240301」——3か月後に自分で開いて中身が分からなければ、名前の意味がありません。ノートが50本を超えたあたりから、検索窓にキーワードを入れても目的のノートが見つからないストレスが大きくなります。

タグも名前も「付けるのは簡単、あとから揃えるのは苦痛」という性質があります。だからこそ、最初にルールを決めておきたい——でも、自分でゼロからルールを設計するのは案外難しいものです。

依頼1回目: タグと命名ルールを提案して

Claude Codeに次のような依頼文を渡しました。

Obsidianのタグ体系とノートの命名ルールを設計してください。

【現在の状態】
- ノート数: 約80本
- 主な用途: 読書メモ、仕事のアイデア、日記、学習メモ
- タグの現状: #メモ、#idea、#アイデア、#仕事、#読書 など表記揺れあり
- ファイル名の現状: 日本語ベタ書き（「〇〇についてのメモ」「考え」など）
- 特にやりたいこと: タグで分類できるようにしたい、ファイル名から内容が分かるようにしたい

依頼のポイントは「現在の状態」をできるだけ具体的に書いたことです。ノートの数や用途、タグの実際の表記揺れをそのまま伝えました。抽象的に「タグを整理して」と頼むより、現状を共有した方がClaude Codeが出す提案の精度が上がります。

期待していたのは、自分の用途に合ったタグ階層と、日付プレフィックス付きの命名ルールのセットです。

結果1回目: 提案されたルール

Claude Codeから返ってきた提案は、想像以上に体系立っていました。

タグ体系の提案（階層構造）

ノート命名規則の提案

• 形式: YYYY-MM-DD_スラッグ.md
• スラッグは日本語可（例: 2025-01-15_読書メモ-原子の習慣.md）
• 接頭辞によるタイプ分けは不要（タグで代替）

悪くない提案です。階層タグで大分類→小分類の流れができるし、命名規則も日付が先頭に来るので時系列で並びます。

ただし気になる点もありました。タグの数が少し多く感じます。「#仕事/タスク」はタグよりフォルダやYAMLフロントマターのstatus欄で管理する方が自然ではないか。あと「#学習/プログラミング」と「#学習/英語」は、学習ジャンルが増えるたびにタグが増える設計で、運用し続けられるか少し不安です。

修正指示: 自分の使い方に合わせる

最初の提案をベースに、Claude Codeへ修正の依頼を出しました。

提案ありがとうございます。以下の点を修正したいです。

1. タグの階層をもう少しシンプルにしてください。
   大分類だけで十分なものは細分化しない（例: #学習 だけで #学習/プログラミング は不要）
2. 日本語タグを基本にしてください。英語タグは混在しないように統一したいです。
3. #仕事/タスク はタグではなく、ノート内のYAMLフロントマターで管理する方向にしたいです。
4. 命名規則は日付プレフィックスを維持しつつ、スラッグ部分をもう少し短くできないか検討してください。

修正の狙いは、タグを「迷わず付けられる数」まで減らすこと。階層が深すぎると「これ #仕事/アイデア にするか #仕事/メモ にするか」で迷ってしまい、結局タグ付けが面倒になります。

結果2回目: 修正後のルール

2回目の提案は、自分の感覚にかなり近づきました。

修正後のタグ体系

修正後の命名規則

• 形式: YYMM-DD_キーワード.md
• 例: 2501-15_原子の習慣.md
• キーワードは3〜5文字程度で内容を示す

試しにこのルールを既存の架空ノートに適用してみます。「メモ」というファイル名だったノートは 2503-20_案件Aの要件.md に変わり、#仕事 タグを付けるだけで分類が完了します。「考え」というノートは 2502-08_週次振り返り.md になり、#日記 タグと組み合わせて一目で内容が分かります。

運用のしやすさでいうと、タグの数が7個に収まったのが大きいです。ノートを書くたびに「どのタグを付けるか」で迷わなくなりました。

どこまで頼むだけでできたか

ここまでのやり取りは全部で3回（最初の依頼1回＋修正指示1回＋確認1回）でした。頼むだけでできたことと、人が判断したことを整理します。

頼むだけでできたこと
– タグの階層構造の設計と、その後の簡略化
– 日本語タグへの統一方針
– ファイル命名規則の提案と改善
– YAMLフロントマターとの使い分けの提案

人が判断したこと
– 「タグの階層を深くしすぎない」という方針の決定
– 「タグは日本語に統一する」という選択
– 「#仕事/タスクはタグではなくYAMLで管理する」という判断
– 実際のノートに適用してみての使い勝手の評価

言い換えると、Claude Codeは「提案を出す」ところまでは確実に進みますが、「自分の用途に合わせて取舍選択する」ところは人がやる必要があります。これはタグ設計に「正解」がなく、使う人の思考のクセやノートの取り方によって最適なルールが変わるからです。

ただし、ゼロから自分で考え始めるより、提案を出してもらってから修正する方が圧倒的に速かったです。

最終結果

完成したルールセットをまとめます。

タグ一覧（全7個）

命名ルール

• 形式: YYMM-DD_キーワード.md
• キーワードは3〜5文字程度、内容が分かる言葉
• 例: 2504-10_タグ設計.md, 2503-28_Claude検証.md

YAMLフロントマターとの併用

タグだけでは表現しきれない属性（ステータス、優先度、関連プロジェクトなど）は、ノート先頭のYAMLに書きます。

---
date: 2025-04-10
category: ツール検証
status: done
---

このルールセットは、Obsidianのフォルダ構成を整理するCC-018の検証とも整合するように設計しました。フォルダで大まかな分類をして、タグで横断的に拾う——この二段構えでノートの検索性が大きく上がります。

この検証の振り返り

全体の流れを振り返ると、依頼→提案→修正→完成という王道パターンでした。

タグ設計で一番難しいのは「粒度」です。少なすぎると分類できない、多すぎると迷う。Claude Codeに「もう少し減らして」と伝えれば調整してくれますが、「どの粒度が自分に合うか」の最終的な感覚は人にしか分かりません。少なめに始めて、運用しながら足していく方が失敗しにくいです。

初心者が試すときのコツを3つ挙げます。

• 最初の依頼で「現在のタグの状態」をそのまま伝える。表記揺れも含めて正直に書くほど、提案の精度が上がる
• 1回目の提案で「多すぎる」「深すぎる」と感じたら、遠慮なく減らす方向で修正指示を出す
• 実際に5〜10本のノートに適用してみて、違和感がないか確かめる。手で数本試すだけで、ルールの抜け漏れに気づける

タグ体系と命名ルールの基礎はClaude Codeに頼むだけで固まります。「自分の用途に合うタグ粒度」の微調整だけは、自分でノートを書きながら確かめるのが確実です。

まとめ

3回のやり取りで、タグ7個＋命名規則1本のルールセットが完成しました。ノートを書くたびに迷わずタグを付けられる状態になっています。

頼むだけでできたのは「提案を出す」「修正に応じる」「具体例を示す」ところまで。タグの粒度をどうするか、日本語と英語のどちらに揃えるか——この判断は自分がノートをどう使っているかに依存するため、人にしか決められません。

ゼロから自分で考えるのと、提案をもとに修正するのでは作業感が全然違います。Obsidianのタグや名前に悩んでいるなら、現在の状態をそのまま伝えてClaude Codeに提案してもらうところから始めるのが手っ取り早いです。

次はCC-020で、このタグ体系と命名ルールを使って内部リンクをどう整理するかを扱います。

今回の結果は、利用モデル、接続先、時期、環境によって変わる可能性があります。再現する時は検証条件もあわせて確認してください。