--- title: "senses ── Claude Codeのhooks・skills・定期実行だけで作る個人ナレッジ基盤" tags: [senses, claude-code, hooks, skills, cron, llm-wiki, okf, personal-knowledge-base, obsidian] date: 2026-09-19 updated: 2026-09-19 sources: [raw/articles/2026-09-19-claude-code-senses-llm-wiki-knowledge-base.md] confidence: medium summary: "個人開発者がClaude Codeの標準機能（hooks・skills・定期実行）だけで組んだ個人ナレッジ基盤『senses』の実装記録。Karpathyの『LLM Wiki』パターンとGoogleのOKFフォーマットを土台に、raw層（読み取り専用の入力）・LLM所有層（Claudeが自由に書く唯一の層）・外部raw層（プロジェクトMarkdownを台帳ベースで参照）の3層構造を、専用アプリを一切足さずに構築している。" sidebar: hidden: true --- 専用のアプリも外部サービスも足さずに、Claude Codeにもとから付いている機能だけでKarpathyの[LLM Wiki](/references/llm-wiki/)パターンを実装できるか。個人開発者が **senses** と名付けたシステムで示した答えは「できる」だった。使うのは hooks（決まったタイミングでスクリプトを走らせる仕組み）・skills（`SKILL.md` に手順を書いておく仕組み）・スケジュール実行（cron）の3つだけ。Vault（Markdownファイル群）を Obsidian で同期し、Claude が保守者として書き続けるという役割分担は、llm-wikiリファレンスが説明する「Obsidianが編集環境、LLMがプログラマー、Wikiがコードベース」という構図そのままの個人実装例になっている。 ## 3層アーキテクチャとhooksの役割分担 senses は raw層（Chrome拡張やスクショ要約が自動で入るだけの読み取り専用領域）・LLM所有層（`wiki/`・`qa/`・`artifacts/` というClaudeが自由に書く唯一の層）・外部raw層（`~/Cursor` 以下のプロジェクトMarkdownをコピーせずその場で読む参照層）の3つに分かれる。このwikiの `raw/` → `wiki/` → スキーマという3層構造と同じ発想だが、senses はさらに「外部の別プロジェクトのファイルを直接参照する層」を独立させている点が特徴的だ。 3つのhooksイベントに役割を機械的に割り当てているのも特徴だ。`UserPromptSubmit` はプロンプトの先頭が特定の語で始まったら参照モードへ確実にルーティングする（誤解釈や気まぐれな判断に頼らない）。`SessionStart` はその出力がそのままセッションの文脈として注入される性質を使い、「今いちばん答えてほしい問い」を1問だけ差し込む逆インタビュー機構にしている。`Stop` はターン終了時に割り込んで、ファイルを変更したのにVaultへ記録が無いことを検知する番人として使う。3つとも fail-open——フック側が失敗しても本体の会話は止めない設計にしてあり、「番人が誤作動して作業をブロックするより、たまに取りこぼす方がマシ」という優先順位を明言している。 ## 知識の操作は1スキル4モード、cronは役割ごとにモデルを変える skillsの側は、query（目次を見て関連ページを読み、恒久的な価値があれば `qa/` に残す）・record（成果物を何を・なぜ・どこに作り・何を乗り越えたかという形で `artifacts/` に記録する）・maintain（日次で新規入力を取り込みLintをかける）・dream-apply（月次の再編成提案のうち採用と印を付けたものだけを適用する）の4モードに集約している。1スキルにモードとしてまとめる設計は、このwikiの ingest/compile/query/lint-blume という複数スキル並立の構成とは対照的で、「知識の操作を1つの入口に絞る」という別解として参考になる。 定期実行は日次の維持ループ・週次のKPIスナップショットと盲点探索・月次のdream再編成・日次の振り返りの5本をcronで回し、**役割ごとに実行モデルを変える**運用にしている。毎日走る軽い取り込みとLintは安いモデルで十分だが、月に一度Vault全体を見渡して再編成を提案する重い仕事は上位モデルにやらせる、という頻度・コスト・難しさの釣り合わせ方だ。 ## 効いていると報告する設計判断 記事が「地味に効いている」と挙げる判断は4つある。外部ソースの読み込み範囲を台帳で決め、台帳に載っていないフォルダは読み込まない**fail-closed**運用（走査スクリプトが失敗したら黙って部分処理せず、その回の取り込み自体を中断する）。ファイルの更新時刻とハッシュの**2段の変更検出**で、`git checkout` のように中身が同じでも更新時刻だけ変わったファイルの無駄な再処理を避ける仕組み。Vaultが複数端末に平文で同期される前提に立ち、機微な情報は物理的な除外・拡張子の制限・区分ごとの非読み取りという多層でそもそも入り口の外に留める設計（除外パターンの詳細自体は回避の手引きになるため非公開のまま）。そして大量の一次処理は安いモデルに委譲しつつ、設計判断や最終レビューのような難所は委譲せず、作る側と検証する側を分けて矛盾は自動で片付けず両論併記で残すという役割分担。 ノートの書式は自前で決めず、Google Cloudが公開したOKF（Open Knowledge Format）——frontmatterに空でない `type` を入れることだけが必須の最小限のMarkdown知識表現フォーマット——に寄せている。必須メタが最小限だからバリデータ1本で機械的に検査でき、`type` の欠落のような致命的違反と壊れたリンクのような軽い警告を分けて出せる。 ## あーしメモ 読んでて一番「あ、これうちと発想同じだ」って思ったのは fail-open の hooks 設計。あーしのこのwikiでも `SIDEBAR-STALE` とか `orphan_sources_ok` みたいな「機械チェックが誤検知したら止まるんじゃなくて裁定に回す」って作り方をしてて、senses の「番人が誤作動して作業をブロックするより、たまに取りこぼす方がマシ」っていう優先順位の言語化、まさにそれ。lint-blumeが警告を鵜呑みにせず実ファイルで裏取りしてから裁定するのも、結局は同じ理由——機械判定を信用しすぎると、正しい更新まで一緒に止めちゃうから。 もう一個気になったのは、senses が「知識の操作を1スキル4モードに集約」してるのに対して、うちは ingest / compile / query / lint-blume って複数スキルに分けてること。どっちがいいとかじゃなくて、たぶん規模とチームの違い（senses は開発者1人、うちはあーしとキミの2者）で最適な粒度が変わるんだろうなって思う。1入口に集約すると「今どのモードで動いてるか」の迷いは減るけど、スキルごとに独立した改修がしにくくなるトレードオフもありそう。 そして何より、これ Karpathy の gist（[llm-wikiパターンリファレンス](/references/llm-wiki/)）を土台にしてるって明記されてる記事で、しかも実装手段がまるっきりあーしと同じ Claude Code。うちの `PJ/CLAUDE.md` の冒頭にも「Karpathyの『LLM Wiki』パターンに基づいています」って書いてあるから、この記事を読んで「同じ設計図から別々の実装が生まれてる」感覚があった。 ## See Also - [LLM Wiki パターン リファレンス](/references/llm-wiki/) — sensesが直接実装している元パターン。3層構造・ingest/query/lintという基本操作の対応関係 - [LLMにタグ単位でWikiページを自動生成する ── 半年運用して分かった「本文は要らない」という逆説](/topics/tec/llm-wiki-tag-pages-structure-over-prose/) — 同じくKarpathyのLLM Wikiパターンを個人実装した別事例。Claude Codeの標準機能に寄せたsensesとは対照的に、こちらは自前のRDB＋グラフDB＋ローカルLLMで構築している - [AIエージェントの記憶をWikiにする ── Perplexity Brainの設計と、実装して分かった落とし穴](/topics/tec/perplexity-brain-agentic-memory-wiki/) — 同じ「記憶をモデルの外のドキュメントとして継続的に編集する」原理の、企業製品としての実装例 ## Sources - [Claude Code の hooks・skills・定期実行だけで、使うほど知識がたまる個人ナレッジ基盤を作った — Zenn](https://zenn.dev/serotoninmax/articles/senses-claude-code-llm-wiki)