溜めた知識をAIに使わせる3層構造

9月の半ば、2日かけて、YouTubeで高く評価してきた動画を100本以上、視聴ノート（文字起こしと要約をAIに作らせたノート）にしました。そのあと気づいたのは、ノートが増えても作業のしかたは1ミリも変わっていないということです。

読んだつもりになっていただけでした。

そこで、溜めた知識体系を、AI（Claude Code）がその場で使える形まで落とし込みました。私は普段、Claude Codeに個人開発を手伝わせています。作っているのは、シミュレーションゲームやこのブログです。開発の進め方は、AIが読む「開発ルール」のファイルに書いています。

この記事は、そのときに決めた3層構造と、蒸留する（たくさんのノートから、使える部分だけを抜き出してまとめる）ときの基準の話です。最後に、3週間使ってみて分かったことも書きます。Obsidianに溜めたメモを、AIにも使わせたい方に向けて書きます。

なぜ溜めるだけでは使われないのか

私のObsidian（Markdownでノートを溜めるアプリ）には、記事のクリップとYouTubeの視聴ノートが、合わせて約930本あります。文字起こしやリンクも含めると、全部で約1,000万字です。文庫本を1冊12万字とすると、80冊分を超えます。

この量には2つの問題があります。

1つ目は、AIに毎回読ませられないことです。作業のたびに80冊分を読ませるわけにはいきません。コストの問題もありますが、それ以前に、大量の文脈を与えると、判断がぼやけやすくなると考えています。

2つ目は、自分も読み返さないことです。「あの話、どのノートに書いたっけ」で終わります。検索して見つけたとしても、そこに書いてあるのは動画の要約であって、いま手を動かすための手順ではありません。

つまり、溜めるための形のままでは、AIと私のどちらにも使えません。

1. 溜める場所と使う場所を分ける

そこで3層に分けました。いちばん上のSkillは、Claude Codeに作業の手順を持たせる仕組みです。手順書を ~/.claude/skills/ に置いておくと、その作業のときにAIが読み込みます。

層	置き場所	中身	読むのは
生ノート	Obsidian（YouTube・Clippings）	動画や記事ごとのノート。出典・文字起こし付き	人（たまに）
Tips	Obsidian（Memo）	複数のノートを横断して蒸留したもの	人・AI（参照時）
Skill	Claude Code（skills）	その場で手が動く手順だけ	AI（その作業のとき）

いちばん下の生ノートは捨てません。出典が辿れなくなると、あとで「本当にそう言っていたか」が確認できなくなるからです。

いちばん上のSkillは短く保ちます。私が作った2つ（プロジェクト管理の手順と、シミュレーションゲームを設計する手順）は、今160〜200行ほどです。ここに読み物を書くと、呼ばれるたびに全部読み込まれて邪魔になります。

真ん中のTipsが橋渡しです。生ノートから「使える形」だけを抜き出して、250行から400行ほどにまとめます。Skillには、ここへのパスを1行だけ書いておきます。迷ったらTipsを読みに行ける、という状態です。

2. 一致点を捨てて、差分だけ残す

蒸留するときの基準がこれです。

今回、プロジェクト管理を扱った動画のノートが、動画51本分ありました。語り手は4人います。全員がPMBOK（プロジェクト管理の知識を体系にまとめたもの）を説明しているので、当然かなりの部分が重なります。

では4人全員が一致していたのは何かというと、たった3点でした。

プロジェクトとは「独自の目標」と「期限」を持つ活動である
スコープ（作業範囲）の定義が要になる（4人中3人は「最も重要」と明言）
統合マネジメントは全体のバランスを取るものである

この3点は、正直どの教科書にも書いてあります。これだけを抜き出しても、本を1冊読むのと変わりません。

価値があったのは、残りの差分のほうでした。たとえば、ある語り手だけが「定量化とは分母と分子を明確にすること」と言っていました。次の2つの引用は、その動画を要約したノートから引いています。

「順調です、現在70%です」→ 翌週「80%です」→ そこからなかなか100%にならず、83%、85%、86%と、なぜか急に1%刻みになる。

この推移に心当たりがある人は多いと思います。私もあります。語り手は、正しい言い方を次のように示していました。

玉ねぎ8個、人参2本、じゃがいも6個で合計16個。あとじゃがいも4個だけ残っている。よって「16個中12個完了で現在75%です」。

判定基準も明快でした。「その50%の根拠は？」と聞かれて、分母と分子を説明できるか。 説明できずに、これまでやった作業の説明を始めたら、それは定量化できていません。

こういう「その人しか言っていないこと」だけをTipsに残しました。一致点は追認にしかならないからです。

ちなみにこれは、私が以前から持っている「外部の実践から学ぶときは一致点ではなく差分を成果物にする」というルールを、動画に適用しただけです。同じ話を4人から聞くのは無駄に見えますが、差分を取るためには複数の語り手が要ります。

3. Skillには「手が動く形」だけ書く

3つ目は、TipsからSkillへ落とすときの基準です。

判断の分かれ目は単純で、読んだあと手が動くかどうかです。

背景の説明、なぜそうなのかの理屈、出典のエピソードは、全部Tips側に置きます。Skillに入れるのは、チェックリストと、判断の分かれ目と、やってはいけないことだけです。

実際に書いたSkillから、強調の記号を外して抜き出すとこうなります。

### ④ 粗いままの項目を「分かっていない項目」として扱う

細かく分解できるのは分かっているから。
粗くしか分解できないのは分かっていないから。

粗い項目を見つけたら、そこを調べる／試すことを最初のタスクにする。
「あとで分解する」ではなく「いま分からないと分かった」として扱う。

元になった動画では、作業をどこまで細かく分けるかを、ステーキをどの大きさに切るかにたとえて説明していました。その比喩はTips側に残してあります。Skillには結論と、次にとるべき行動だけを書きました。

もう1つ、Skillには、「やらないこと」を必ず書きます。私が書いたものにはこうあります。

1行修正・typo修正のような極小の作業で、この手順を持ち出さない
PMBOKの用語をそのまま使わない。個人開発の規模に合わないものは、Tipsにも入れていない
追加のエージェント（別に動かすAIの担当）・API呼び出しを発生させない

これを書いておかないと、AIは手順を全部の場面に当てはめようとしがちです。手順書は、使わない場面を書いて初めて使える手順書になります。

配線して何が変わったか

3層に分けたあと、AI側にも配線しました。開発ルールに「計画を点検するときは、このSkillを使う」と書き、計画を点検する専用のエージェントを1つ足しています。エージェントは、決まった観点で計画を読み、抜けを指摘するだけの担当です。Skillの「やらないこと」のとおり、Skillそのものはエージェントを呼びません。大きな計画を立てたときだけ、こちらから別に呼びます。

小さな変化から挙げると、AIの進捗の報告が変わりました。

Skillには、「ほぼできました」「あと少しです」を悪い例として、「16件中12件完了」を良い例として書きました。今は、AIが計画を立てるときに数える単位を先に決め、「手順（分母＝6）」のように書いてきます。数えられない作業は、工程で割ります。

地味ですが、読む側としてはかなり助かります。「ほぼ」と言われても、どこまで終わったかは分かりません。分母が決まっていると、終わっていない部分が具体的に見えます。

3週間使ってみて

3層に分けてから3週間、この仕組みを使いました。作業の記録から呼び出した回数を数えると、次のとおりです。

使ったもの	回数（9月19日〜10月12日）
プロジェクト管理のSkill	6回
計画を点検するエージェント	2回
ゲーム設計のSkill	1回

回数は多くありません。エージェントは、開発ルールで「大きな計画を立てたときだけ呼ぶ」と決めています。Skillも、まとまった作業に入るときや数を報告するときに読む手順なので、毎日の小さな作業では呼ばれません。

いちばん効いたのは、計画の点検でした。エージェントにゲームの開発計画を2回点検させたところ、どちらも8件の指摘が返ってきました。そのうちの1件は、要件と設計に書いた70項目を計画と突き合わせた結果です。17項目が、どの作業にも「やらないこと」にも入っていませんでした。

もう1件は、作業の順番の指摘でした。まだ測っていない部品の結果しだいで後の作業が変わるのに、計画はその部品を使う作業から始まっていました。エージェントは、先に調べる作業を置くよう勧めていました。3つ目の節で抜き出した「粗い項目は、先に調べる」が、そのまま点検の観点として働いたことになります。

Skillも少し育ちました。プロジェクト管理のSkillは、9月19日の156行から、今は195行になりました。増えた分の多くは、9月23日に足した「数を報告する前の5つの点検」です。元は、Claude Codeに足せる拡張（プラグイン）にあった点検の一覧でした。ここでも全部は取り込まず、自分の作業で起こりうる項目だけを残しています。

生ノートの側も整理を続けました。9月20日から、テーマごとにまとめたノート（YouTubeは72テーマ）と、全体の見取り図を足しています。探すときは見取り図とテーマのノートから入り、要るときだけ生ノートまで降ります。

まだできていないこともあります。今回数えられたのは、呼んだ回数と指摘の件数までです。Skillを使った計画と使わなかった計画で、手戻りがどれだけ違うかは、まだ比べていません。

まとめ

溜める場所と使う場所を分ける。 生ノートは捨てず、Skillは短く保ち、Tipsで橋渡しする
蒸留するときは一致点を捨てて差分を残す。 一致点は追認にしかならない
Skillには手が動く形だけ書く。 背景はTipsへ。そして「やらないこと」を必ず添える
3週間でいちばん効いたのは、計画の点検。 2回の点検で、それぞれ8件の指摘があった

知識は溜めた時点では資産になりません。使う場所まで運んで、初めて資産になります。

これは私の環境に合わせたやり方なので、1つの参考として見ていただければと思います。