⟐ Claude Code/2026-05-24上級

Claude Code × Obsidian で「自律する司書」を据える ― 4 サイト運営から見た 3 層ストレージと Skill 実装の運用ノート

Andrej Karpathy 氏の LLM Wiki 構想を入り口に、Claude Code と Obsidian を組み合わせた自律型ナレッジ OS を、4 サイト並行運用の実際の運用構造に当てはめながら設計します。3 層ストレージ・ingest/compile Skill・Dataview 監視・週次ジョブの実装まで、本番運用に耐える形で整理します。

Claude Code¹⁹⁸ Obsidian Skills⁵ ナレッジマネジメント個人開発¹¹⁰

✦ プレミアム記事

毎晩寝る前に、その日の Claude Code セッションのログを読み返す習慣があります。1 日 16 本の記事生成が走り終わったあと、サブエージェントが書き残した「考察」や「実装メモ」が、ローカルに数十ファイルずつ積み上がっています。これを最初のうちは Notion に貼って整理していましたが、半年もすると検索しても出てこない、出てきても要約済みで元の文脈が失われている、という状態になりました。

私は 2014 年から個人で iOS / Android アプリを開発し、累計 5,000 万ダウンロードを超えたいま、4 つの AI 技術ブログサイトを Claude Code で並行運用しています。アプリの方も AdMob と App Store Connect から毎朝データを取り込み、サイトの方も articles.json を毎ビルドで再生成しているので、ナレッジを「動く資産」として保つ必要があるドメインが複数あります。Karpathy 氏が話していた LLM Wiki の概念や、それを実務に落とし込んだ Qiita 記事「【実装編】Claude Code × Obsidian で作る自律型ナレッジ OS「2do BRAIN」のアーキテクチャと運用コード」の構造に強く共感したのは、まさにこの「腐らないナレッジ」をどう作るかという問いに、ディレクトリと Skill だけで答えを出していたからです。

今日は、その 3 層ストレージと Skill 群を、私の 4 サイト + 6 アプリの運用構造に重ね、実装と運用の両側で耐えるように整理し直した結果を残します。同じように個人で複数プロジェクトを横断している方の参考になればと思います。

なぜ Vector DB ベースの RAG だけでは足りないと感じたか

最初に思っていたのは、Obsidian の vault を丸ごと Vector DB に投げ込んで、Claude Code から RAG で検索すれば足りる、というものでした。これは半分正解で、半分は問題を先送りにします。

実際にやってみると、生データ（PDF・公式ドキュメント・チャットログ）を都度ベクトル化して引き戻すことはできます。しかしそれは「知識の断片を都度検索する」だけで、「知識を構造化して育てる」「過去に書いたことと矛盾する記述を検知する」ことができません。私のように 4 サイトに同じ概念（例えば Claude Code の Skill）が異なる粒度で書かれている場合、Vector DB は最近書いた記事を返すだけで、過去の自分の判断と矛盾していても気づきません。

ここで効くのが、AI に「書く前に必ず一次情報を再読込させる」「書いたものは履歴に必ず残させる」という、データ構造側からの強制力です。Skill のプロンプトでお願いするだけでは、忙しくなるほど守られなくなります。ディレクトリと YAML フロントマターでルールを表現すれば、Claude Code 側も Obsidian Dataview 側もそのルールを機械的に検証できます。

3 層ストレージ：01_raw / 02_wiki / Schema の役割を厳密に分ける

実装の核は、vault のルートに置く 3 つのディレクトリです。

2do-brain/
├── 01_raw/              # 生データ層：不変の一次情報（Source of Truth / Read-Only）
├── 02_wiki/             # 編集済み知識層：AI が編纂する構造化知識（Write-Allowed）
│   ├── index.md         # カタログ：全ページのインデックス
│   └── log.md           # 履歴：## [YYYY-MM-DD] 操作名 | 対象
└── Schema/              # 規律層：司書としてのルール定義
    ├── CLAUDE.md        # ナレッジ OS の憲法（基本原則）
    └── .claude/
        ├── rules/       # 分野別ルール
        └── skills/      # 実行 Playbook（後述）

3 つを厳密に分ける目的は、再帰的要約劣化 を止めることです。AI に過去の Wiki（要約）だけを見て要約を繰り返させると、一次情報の重要な細部がだんだん削ぎ落とされていきます。これを防ぐため、01_raw/ は Claude Code の Skill 側でも Read 系のツールしか向けず、編集系のツールは触れさせない設計にしています。

私の 4 サイト運用に当てはめると、01_raw/ に入るのは Anthropic / Google / Microsoft の公式ドキュメント PDF、Cloudflare Workers の changelog、Stripe の API リファレンスのスナップショット、そして 4 サイトの GSC エクスポート CSV です。02_wiki/ 側には、それらを Claude Code に読ませて編纂した「Cloudflare Workers と Next.js 16 を 4 サイトに展開するときの落とし穴」のような統合ノートが置かれます。

Schema/CLAUDE.md には次のような最小限のルールだけを書いています。

すべての主張に [[01_raw/filename]] のインライン出典を付与すること
既存ページを更新する場合、必ず 01_raw/ の該当箇所を再読込してから書き換えること
書き換えたら必ず 02_wiki/log.md に ## [YYYY-MM-DD] 操作名 | 対象 を追記すること

この 3 つだけで、6 ヶ月運用しても矛盾が積み上がらない vault になりました。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦01_raw / 02_wiki / Schema の 3 層ストレージを Obsidian の vault と Claude Code Skill の両側から成立させる、ディレクトリ・YAML・Skill 引数の具体的な型

✦再帰的要約劣化を止めるため、ingest と compile を別 Skill に分離し、allowed-tools と disable-model-invocation で書き込みを意図的に止める運用パターン

✦Dataview クエリと週次セルフチェック Skill を組み合わせて、4 サイト運用で 90 日溜まったナレッジに耐性を持たせた実数値ベースの判断ルール

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

ingest Skill：一次情報を読み込み、ドラフトだけ書き出す

Skill 群の 1 つ目は、01_raw/ に入った新規ドキュメントを読み込む ingest です。実行はターミナルから /ingest 01_raw/admob-reporting-v1beta.pdf のように、引数として対象ファイルを渡します。

.claude/skills/ingest/SKILL.md の核は次の通りです。

name: ingest
description: 01_raw/ ディレクトリ以下の新規ドキュメントを読み込み、エンティティ抽出と要約を行う。
argument-hint: 対象ファイルのパス (例: 01_raw/sample.pdf)
arguments:
  - name: target_path
    description: 抽出対象となる一次情報のファイルパス
    required: true
allowed-tools:
  - Read
  - Grep
paths:
  - 01_raw/*

設計上のポイントは allowed-tools を Read と Grep だけに絞っている点です。Skill の本文では「抽出した結果を 02_wiki/_drafts/YYYY-MM-DD_[ファイル名].md に保存する」と書いていますが、書き込みに該当するツールは事前承認されていないため、ドラフト保存の段階で必ずユーザーへの承認確認が入ります。

このひと手間が、抽出結果の品質を 1 段引き上げる安全弁になります。私の経験では、ingest から 02_wiki/_drafts/ に出た時点でひと呼吸置けるかどうかが、その後の compile の精度に直結しました。

compile Skill：既存 Wiki に統合する側を、あえて手動起動だけにする

2 つ目の compile Skill が、この設計のなかで一番大事な部分です。ingest が出したドラフトを、既存の 02_wiki/ ページに統合します。

name: compile
disable-model-invocation: true
description: 抽出されたドラフト情報を既存の 02_wiki/ ページ群に統合し、出典とメタデータを更新する。
argument-hint: 統合元のドラフトファイルパス (例: 02_wiki/_drafts/draft.md)
arguments:
  - name: draft_path
    description: Ingest で作成されたドラフトファイルのパス
    required: true
allowed-tools:
  - Read
  - Grep
  - Edit
  - Bash(git add 02_wiki/*)

最重要は disable-model-invocation: true の 1 行です。これを入れると、この Skill は Claude のコンテキストやサブエージェントにプリロードされなくなります。つまり AI 側からはそもそも見えない状態で、人間が /compile と明示的に手動で起動しない限り発火しません。

ここまで厳しくする理由は、compile が 02_wiki/ 本体に直接書き込むからです。私の 4 サイト運用では、02_wiki/ の側に「Claude Code Skills を選定する 5 つの軸」のようなノートが積み上がっており、これが暗黙的に上書きされると、後続の記事生成がそのまま劣化したノートをコンテキストとして読み込んでしまいます。Auto-invoke で勝手に走らせるのではなく、人間がドラフトを確認してから手動で起動する設計は、本番運用するなら譲れない一線でした。

もう 1 つ細かい工夫が Bash(git add 02_wiki/*) の書き方です。無制限の Bash を渡すのではなく、コマンド単位でスコープを絞ってあります。Anthropic 公式の Skill ドキュメントが推奨するプラクティスでもあり、私の運用では git push 相当の操作は完全に人間側に残しています。

Skill 本文側では、次の 3 ステップを必ず守らせます。

# Wiki Compile ワークフロー
対象ドラフト: $draft_path

1. 既存ページを更新する場合、再帰的要約劣化を防ぐため、必ず対応する 01_raw/ の該当箇所を再読込して事実確認を行うこと
2. すべての主張に [[01_raw/filename]] の形式でインライン出典を付与すること
3. 処理の最後に必ず 02_wiki/index.md と 02_wiki/log.md を更新すること

examples/output_template.md を同じディレクトリに同梱して、フロントマターと本文の完成形を Few-shot として与えるのも有効でした。私のサイトでも YAML が updated_at / sources / status の 3 キーで安定するまで、テンプレを渡さないとフォーマットがブレ続けたので、ここはケチらずに 1 ファイル追加する価値があります。

Dataview で「未レビューのページ」を恒常的に監視する

ここまでで vault の中に YAML フロントマター付きのページが積み上がるようになります。これを Obsidian の Dataview プラグインから動的にクエリすると、「AI が生成したまま、人間がまだレビューしていないページ」が即座に出てきます。

```dataview
TABLE updated_at, status
FROM "02_wiki"
WHERE status != "reviewed"
SORT updated_at ASC
```

私はこのクエリを vault のホームノートに固定し、毎朝開いて未レビュー件数をチェックしています。10 件を超えてくる週は compile の精度が落ちている兆候なので、Skill のプロンプトと examples/output_template.md を一度見直す合図にしています。8 週間運用してきた感覚では、ここを 5 〜 10 件のレンジでキープできているとき、4 サイト側の記事生成も安定していました。

4 サイト運用に当てはめたとき、どこを変えたか

ここまでは Qiita 記事の構造をほぼそのまま採用していますが、私の運用に合わせて変えた箇所がいくつかあります。

1 つ目は、01_raw/ に サイト別サブディレクトリ を切ったことです。Claude Lab / Gemini Lab / Antigravity Lab / Rork Lab で必要な一次情報がほとんど重ならないため、01_raw/claudelab/、01_raw/gemilab/ のように分けています。ingest Skill の paths も 01_raw/{site}/* で受け取れるようにしました。

2 つ目は、02_wiki/ 側に クロスサイト統合ノート を別フォルダで持たせたことです。「Stripe メンバーシップを 4 サイトに展開するときの共通設計」のように、サイトをまたぐ判断は 02_wiki/_cross/ に集約しています。これがないと、同じ判断を 4 サイトのノートにそれぞれ書き込むことになり、矛盾の温床になります。

3 つ目は、週次で走る weekly-audit という Skill を追加したことです。Cron 経由で日曜の朝に /weekly-audit を発火させ、02_wiki/log.md から過去 7 日の compile 件数と、Dataview のクエリ結果（未レビュー件数）をサマリして 1 つの Markdown に書き出します。月次でこのサマリを並べてみると、サイトごとの更新頻度の偏りが可視化されました。

8 週間運用して見えた、運用判断 6 つ

実装の話だけだとイメージが湧きづらいので、私が 8 週間運用して固まった判断ルールを残します。

01_raw/ に置く一次情報は、可能なら必ず元の URL とハッシュ値もメタとして添える。Cloudflare の changelog のように動的に更新されるページは、月 1 回のスナップショットで上書きする
02_wiki/ の 1 ノートあたりの長さは 1,500 〜 2,500 文字を目安にします。これより長くなったら compile Skill 側で分割を促す
compile の allowed-tools には絶対に Bash 単独を渡さありません。必要なコマンドだけスコープで絞る
Dataview の未レビュー件数が連続 3 週で 20 件を超えたら、Skill のプロンプトを根本から見直す
クロスサイト統合ノートは、書いた日から 30 日経ったら、4 サイトの実状と再照合する
Schema/CLAUDE.md は四半期に 1 回だけ更新します。頻繁に変えると vault 全体の一貫性が崩れる

特に 4 番目は、私の運用で複数回助けてくれた指標です。「最近 Skill の出力が薄い気がする」という感覚的な違和感を、Dataview の数値で先に検知できるようになりました。

検索できるゴミ箱ではなく、働く脳を据えるという発想

実装の話を長く書いてきましたが、根っこの動機はとても単純です。AI に毎回前提を説明し直すのが面倒で、しかも説明し直すたびに細部がずれる、という現象に飽きたのです。

Markdown とディレクトリ構造の自由さは、特定の SaaS に縛られないという意味で大きな価値があります。そこに、Claude Code の SKILL.md 仕様を正しく使った規律を重ねると、ナレッジは複利で増えていく資産になります。私の 4 サイトはまだ 8 週目ですが、すでに「今日何を考えていたか」を翌週の自分が即座に引き継げる状態が定着し始めています。

明日からでも始められるはずです。手元のターミナルで claude を立ち上げて /ingest 01_raw/あなたのドキュメント.md と叩いてみてください。動き始めた瞬間に、これが何をしてくれる仕組みなのか、自分の手元で実感できるはずです。

同じ課題に取り組んでいる方の参考になれば嬉しいです。