Claude向け知識構造化の置き場所を分ける

長いプロンプトより、薄いレイヤーに分ける

Claude向けの知識構造化は、知識を1つの巨大な説明文へ統合する作業ではない。毎回必要な前提は CLAUDE.md、特定領域だけの規約は rules、繰り返す作業手順は skills、過去の学習や好みは memory、文書横断の関係探索は knowledge graph として分けるほうが運用しやすい。

この分け方にすると、Claudeへ渡すcontextを小さく保ちやすい。更新すべき場所も明確になり、古い情報を常時読み込ませる事故も減る。特にrepoやvaultでは、まずsource、config、log、sample artifactを読む運用を残し、memoryだけで現在の事実を決めないことが重要になる。

知識の種類で置き場所を選ぶ

置き場	向いている知識	避けたい使い方
`CLAUDE.md`	毎回必要なrepo構造、build/test command、守るべき規約。	細かい手順や長い背景説明を全部置く。
rules	特定path、技術領域、ファイル種別だけに効く規約。	全体規約と矛盾する広すぎるルール。
skills	調査、レビュー、公開、デプロイなど再利用する作業手順。	ただの事実メモや、毎回変わる実行結果。
memory	過去の判断、好み、失敗から得た再利用可能な知見。	現在状態の代替。driftしやすい情報は再確認が必要。
knowledge graph	entity、relation、multi-hop queryが主役の探索。	小規模な規約整理を最初から重くすること。

小さく始めるなら、この順番

CLAUDE.mdを短く保ち、毎回必要な事実と制約だけに絞る。
2回以上同じ手順を説明している作業を skill に切り出す。
frontend、migration、docs など領域限定の規約は rules に分ける。
繰り返し効く好みや過去の失敗は memory に残す。ただし live state は毎回読む。
複数文書をまたぐ関係探索が必要になってから knowledge graph を検討する。

最初の設計目標は「賢いontology」ではなく、Claudeが必要な知識だけを取り出せること。

迷ったときの判断基準

常に必要か

yesなら CLAUDE.md。noなら常時contextに入れない。

手順か

複数ステップのworkflowなら skill。scriptsやtemplatesも一緒に置ける。

範囲が狭いか

特定directoryや技術だけなら rules。全体に広げない。

現在性が必要か

必要なら memory で決めない。source、config、log、docsを読み直す。

参考資料

資料	位置づけ
How Claude remembers your project	`CLAUDE.md` と project memory の公式説明。
Extend Claude with skills	skillsを再利用可能な作業能力として扱う公式説明。
Create custom subagents	特定用途のagent分割に関する公式説明。
Memory tool	agentがセッションをまたいで情報を保存・取得するtoolの公式説明。
Knowledge graph construction with Claude	Claudeでentityとrelationを抽出し、knowledge graphを構成するcookbook。
Equipping agents for the real world with Agent Skills	Agent Skillsの設計思想を説明するAnthropic Engineering記事。