Claude Code×Obsidianのフォルダ構成を公開｜1ヶ月で「AIの職場」が育った話

こんにちは、みのり（@minori_aimama）です。本業・育児の合間にAI×ブログ副業に挑戦中です。

Claude Code × Obsidianを使い始めて、だいたい1ヶ月が経ちました。

最初は、スマホアプリやブラウザで使うClaude.aiのプロジェクト機能で記事を書いてもらっていました。でもリライトに手を付けると「どの記事のどの版が最新なのか」「前回どこまで直したのか」が追いにくくなり、Claude Codeを導入。

すると、記事を書く時間より仕組みを作る時間のほうがずっと長くなっていきました🫠

今日は、その1ヶ月でたどり着いたClaude Code×Obsidianのフォルダ構成、実際に増えたスキルの数、そして公式ベストプラクティスと比べて見えた課題を、まとめて棚卸ししてみます。完成形ではなく、あくまで「今の形」です。

導入から1ヶ月、現在のフォルダ構成

先に前提を1つ。私のObsidian全体がそのままClaude Code用というわけではありません。

Obsidianは、ふだんから常に開いているメモ・作業スペースです。Webクリップやプロンプト集、アーカイブなども入っていますが、Claude CodeやCodexに主に触らせているのは、その中の 10_プロジェクト 配下だけです。

AIに毎回ぜんぶ見せているわけではありません。なので以下では、その 10_プロジェクト の中身を紹介します。

10_プロジェクト/
├ 11_ブログ①/      ← サイトごとのルール・記事
├ 12_ブログ②/
├ 13_AI副業らぼ/    ← このブログ
├ 14_ブログ④/
├ 19_月次分析/      ← 全サイトの数字をまとめて見る
├ 20_ツールwiki/    ← AIツールの使い方メモ
├ 21_おたよりwiki/   ← 個人用の情報整理
├ _system/         ← 全プロジェクト共通ルールの正本
├ _handovers/      ← 引き継ぎノート（1日1ファイル）
├ _tasks/          ← 横断ToDoの正本
├ .claude/         ← スキル・コマンド・権限設定
├ .codex/          ← Codex専用（画像生成など）
├ AGENTS.md        ← 全体方針の正本
└ CLAUDE.md        ← AGENTS.mdを読み込むだけの薄いシム

見てもらうと分かるんですが、上のほうにあるサイトごとのフォルダより、下のアンダースコア付きフォルダ（_system・_handovers・_tasks）と、隠しフォルダ（.claude・.codex）のほうが「Claude Codeのため」の本体だったりします。

整理してみて分かったのは、記事を置く場所より、AIが読むための土台フォルダのほうが多くなっていたということでした。1ヶ月前の私に見せたら、たぶん「記事はどこにあるの？」と聞いてくると思います🫠

各フォルダは何を管理している？

ざっくり、フォルダは3つの役割に分かれています。

ひとつめはサイトごとのプロジェクト。ブログ1本につき1フォルダで、その中に記事・サイト独自のルール・下書き（inbox）が入っています。

ふたつめは横断の土台。_system に全サイト共通のルール（文章の書き方やフロントマターの決まり）の正本を1つだけ置いて、各サイトからは「それを参照」と書くようにしました。同じことを何ヶ所にも書かないための工夫です。_handovers は1日1ファイルの引き継ぎノートで、今は29本たまっています。_tasks はやることリストの正本で、Obsidianの「Tasks」というプラグインを入れています。

みっつめがスキル置き場。.claude がClaude Code用、.codex がCodex用です。ここがいちばん育ちました。

数で見るとこんな感じです。

Claude Codeのスキル16個の中身を、ジャンル別に分けるとこうなります。

Codex専用の4個は、ぜんぶ画像まわりです。アイキャッチ・挿入画像・SNS画像など。これは役割分担というより、そもそもClaude Codeは画像そのものを生成できないからなんです。なので画像づくりはCodexに任せて、文章とデータはClaude Code、と自然に線が引かれました。

スキルは最初から16個を設計したわけではありません。困るたびに1個ずつ増えていった結果です。棚卸してみると使っていないスキルもあることに気づいたので、あとで整理したいと思います。

ちなみに、これから始める人が最初から全部作る必要はないと思います。最低限なら、記事フォルダ・共通ルール・引き継ぎノートの3つだけでも十分。私も最初はそれくらいから始めて、困るたびに足していっただけです。

公式のベストプラクティスでセルフ監査してみた

ここまで「われながらよく整理した」と思っていましたが、たまたまAnthropic公式の設定ベストプラクティス記事（Claude Codeの steering まわり）を読んで、ちょっと冷静になりました。

ここから少し設定寄りの話になります。正直まだ私も全部は理解できていないので、「今後の宿題リスト」くらいの軽い気持ちで読んでもらえたらと思います🫠

書いてあった要点を、私なりにまとめるとこうです。

• CLAUDE.md は200行以下に保つ。オーナーを決めて、コードのようにレビューする
• Rules は paths で関連ファイルにだけ効かせる（特定のフォルダやファイルにだけ効く追加ルールのようなもの）
• 手順ものはSkillに逃がす。名前と説明だけ常時読み込まれ、本体は呼び出されたとき展開される
• 絶対にやらせないことは Hooks で確定的に止める。プロンプトのお願いは確率的なので、PreToolUseフックで該当操作をブロックするのが確実
• 重い調べものは Subagent に投げる。別のまっさらな文脈で動くので、メインの会話が散らからない
• Permissions（と Hooks）が、確実に守らせるための層

これを物差しにして、自分の設定をClaude Codeに採点してもらいました。なお、これは厳密な評価ではなく、「公式の考え方にどれくらい寄せられているか」を自分用にざっくり見ただけのものです。

並べてみて、はっきり傾向が出ました。私ができていたのは「AIを迷わせない設計」ばかりで、「AIに絶対やらせない設計（HooksやRules）」はまるごと手つかずだったんです。

ただ、正直に言うと、Cがついた4つのうちPermissions・Rules・Hooksは、まだ何ができるのか自体ちゃんと理解できていません。Subagentsだけ「重い調べものを別のところに投げられるやつ」と、なんとなくイメージがついた段階。なので、この監査は「できていない反省」というより「次に勉強することリストが見つかった」に近いです。

それでも、文章で「必ずUTF-8で読んでね」とお願いしても、それはあくまでお願いで、守られなくても止まらない。確実に止めたいことは別の仕組みで固めるものらしい、というのは採点してみてようやく分かりました。

ちなみにこのセルフ監査、Claude Codeに以下のようにお願いするとやってくれます。

https://claude.com/ja/blog/steering-claude-code-skills-hooks-rules-subagents-and-more
この記事のClaude Code設定ベストプラクティス（CLAUDE.md／Rules(paths)／Skills／Hooks／Subagents／Permissions）を抽出し、それを物差しに、今のプロジェクトの設定を実際に見てS/A/B/Cで採点して。
最後に「傾向の総括」と「次にできそうなこと」を2〜3個。

出てくるランクは厳密に定義されていないので、その環境ごとに違います。お遊び感覚でやってみると意外な発見があるかも🫠

1ヶ月使って分かったこと

いちばん意外だったのは、記事を書いてもらう時間が全体の5%くらいしかなかったことです。

残りの95%は、フォルダ設計・AGENTS.md・スキル・引き継ぎ・プロジェクト整理。つまり、書く前の準備にほぼ全部使っていました。

最初は「これ、記事を書くために導入したんだよな？」と我に返る瞬間もありました。でも今は、この土台さえできれば改善しながら長く使える資産になる、と感じています。スキルもルールも、一度作れば次から効くので。

変わるものと変わらないものを、自分なりに分けるとこうなりました。

特に「正本は1つ」「引き継ぎを残す」は、運用のいちばん最初に知れてよかったです。フォルダやスキルがどれだけ変わっても、この考え方だけは残り続けると思っています。

気づいたら、Obsidianはただのメモ帳ではなく、Claude Codeが仕事をするための職場になっていました🫠

そもそもなぜObsidianなのか、という話も少しだけ。私にとってObsidianは、メモアプリというより「AIに渡す作業場」になりました。PCでは常に開いていて、スマホでは空き時間にメモを足す。Webで見つけた情報はクリップしてMarkdownにする。そうやって日々たまる素材を、Claude Codeが読める場所に置いておく。

Obsidian全体を見ると、記事・タグ・AI用wikiページが同じ場所に集まり、作業のハブになってきた感じがあります。直接すべてがリンクでつながっているわけではありませんが、「必要な情報を置いておく場所」がひとつあるだけで、かなり扱いやすくなりました。

あとは、必要なファイルをClaude Codeが自分から読みに行ってくれる。

「AI用wiki」については、こちらの記事で詳しく書いています。

あわせて読みたい

保育園のおたよりから商品リサーチまで│AI用wikiで気づいた情報整理の共通点 情報が散らばるものは、実は同じ設計で管理できるかもしれません。商品リサーチ、AIツール管理、保育園のおたより整理を例に、LLM wikiの活用事例と設計思想を紹介します。

まとめ

これは完成形ではなく、あくまで1ヶ月時点の現在地です。

しかも今回セルフ監査してみたおかげで、次に何を勉強すればいいかが見えました。Hooksで「絶対やらせないこと」を固める、Rulesで必要なときだけルールを効かせる。名前は知っても、まだ使いこなせていない領域です。このあたりを理解するのが、たぶん来月の宿題です。

来月にはまたフォルダもスキルも変わっているかもしれません。でも、その変化していく過程そのものがAI運用のおもしろいところだと思っています。最初から完璧な構成を探すより、自分で育てていくほうが私の性格には合っていました。

半年後・1年後にまた同じ構成を公開して、どれだけ変わったか比べてみたいです。引き続き、この「AIの職場」を試行錯誤しながら育てていきます🫠

あわせて読みたい

Claude Codeにたどり着くまで｜AIブログのコピペ地獄を抜けた話 ハルシネーションとコピペの多さに詰まり、非エンジニアがClaude CodeとObsidianの連携環境に移行した実録。Claude.aiだけでは限界だったブログ記事制作フローが変わるまでの話です。