連載「AIと『判断が育つ』仕事環境づくり」第4回

この記事でわかること

  • GitHubの履歴からAIに「学び」を取り出してもらう仕組み
  • Knowledgeを増やしすぎないための「新規・追記・却下」の3分類
  • AIに任せること／人間が決めることの線引き

前回（第3回）は、Notion・GitHub・Obsidian・Eagleの役割分担を整理しました。最後に残った問題は「ObsidianのKnowledgeは誰が書くのか」。今回はその答えです。

GitHubには「失敗」まで残っている

案件が終わったあと、GitHubを眺めていて気づきました。完成したコードより、そこに至るまでの履歴のほうが面白いんです。

  • 最初はこうつくった
  • 不具合が出た
  • 直した
  • 別の問題が出た
  • 方針を変えた
  • 一度つくったものを元に戻した

そこには、そのときどきの判断が残っています。

だったらClaude Codeに、完成品だけでなく案件の履歴そのものを読んでもらえばいい。そうして生まれたのが、knowledge-extractor（ナレッジ・エクストラクター＝知識の抽出係）というSkillです。

用語メモ：Claude CodeのSkill
Claude Codeに「この作業はこういう手順・ルールでやってね」と教えておく指示書のようなもの。一度つくっておけば、毎回同じ基準で作業してもらえます。

「学びをまとめて」だけではダメだった

最初は簡単に考えていました。リポジトリ（案件の保存場所）を読ませて、「この案件から得られる学びをまとめて」と頼めばいい、と。

でも、その頼み方だけではKnowledgeがどんどん増えてしまう心配がありました。「何かを取り出すこと」自体が目的になると、採用する基準がゆるくなるからです。

  • どこにでも書いてある一般論までKnowledgeになる
  • その案件だけの特殊な事情までKnowledgeになる
  • すでに持っている知識とほぼ同じものが、新しいメモとして出てくる

これでは、数十案件こなしたころにはKnowledgeが使い物にならなくなります。

そこで発想を変えました。

取り出す仕組みより、捨てる仕組みのほうを厳しくする。

「新規・追記・却下」の3つに分ける

Knowledgeの候補が出てきたら、次の3つに分けます。

分類意味
新規まだ持っていない、独立した判断
追記すでにあるKnowledgeに、新しい例外や条件を足せるもの
却下案件固有、根拠が弱い、既存Knowledgeと重複しているもの

実際に玉野高校のWeb案件を分析したときの結果は、こうでした。

  • 新規：3件
  • 追記：3件
  • 却下：9件

一番多かったのは却下です。

却下にはちゃんと理由がついていました。「制約として書かれているだけで、実際に失敗した経験が確認できない」「履歴から判断の理由が読み取れない」など。役に立ちそうな一般論でも、今回の記録が根拠にならないなら、無理に「自分の経験」として残さない。新規がゼロ件でも、それは正常な結果として扱います。

これを見たとき、「これでいいんだ」と思いました。

Knowledgeを増やすことが目的ではないからです。

AIが見つけても、自動ではKnowledgeにしない

もう一つ大事にしたのが、人間の承認です。

Claude Codeが「これは再利用できるKnowledgeです」と言っても、そのままObsidianには入りません。

  1. AIが候補として出す
  2. 僕が見る
  3. 「採用」「追記」「却下」を決める
  4. 決めたものだけを反映する

AIには、大量の履歴を読むことも、比べることも任せたい。でも、

「これは本当に自分の知識なのか？」

を決めるところまでは任せない。ここが線引きです。

AIは優秀な「編集アシスタント」ですが、何を載せるか決める「編集長」は自分、というイメージです。

だからKnowledgeは「読むだけ」から始める

この考え方は、Skillの設計そのものにも組み込みました。

作業中、既存のKnowledgeは基本的にread-only（読むだけ）です。

  • 勝手に書き換えない
  • 勝手に削除しない
  • 勝手に統合しない

まず提案し、承認されてから反映する。さらに、リンク切れや重複、案件固有の情報が混ざっていないかもチェックするようにしました。

ここまで来ると、単なる「AIへのお願い文」ではなくなりました。

自分がKnowledgeをどう扱いたいかを、Claude CodeのSkillとしてルール化した

というほうが近いと思います。

取り出す前に「振り返れる記録」を残しておく

履歴を読めるからといって、AIが当時の考えを何でも再現できるわけではありません。変更の理由が残っていなければ、分からないことは分からないままです。

そこで作業中は、学びのメモを毎回つくるより、後から振り返れる記録を残すことに集中することにしました。

  • コミット（変更の記録）には「現象・原因・対処」を書く
  • 仕様が変わったら、ドキュメントの古い情報を書き換える

そのうえで、案件の区切りで抽出する。次回は「前回以降の履歴」だけを対象にできるようにしておく。

タイミングやること
作業中振り返れる記録を残す（コミットに現象・原因・対処）
案件の区切りAIに記録を読ませて判断を取り出す

記録を残す時間と、そこから判断を取り出す時間を分ける。この二段構えなら、目の前の仕事を止めすぎずに続けられそうだと思いました。

最初にできたKnowledgeは18件

KairosのWeb案件と玉野高校の案件を通して、最初のKnowledgeができました。

全部で18件。内訳は次のとおりです。

分野件数
Web11件
Workflow（仕事の進め方）4件
AI2件
Design1件

（別に、抽出の履歴を残す管理用メモが1件あるので、フォルダ内のファイル数は19。知識の数と管理用ファイルは分けて数えています。）

中身はたとえばこんなものです。

  • キャッシュ（古いデータが残って変更が反映されない問題）への対策
  • スマホ・PCでの表示崩れ（レスポンシブ）
  • CMS（WordPressのような更新システム）の設計
  • エンジニアではない人への引き渡し
  • 仮の写真や文章（仮素材）の扱い
  • AIと長期の案件を進めるときのロードマップ
  • AIが生成したものを手で直さないこと

面白かったのは、「Web制作のテクニック集」にはならなかったことです。技術の話もあれば、運用の話もある。AIとの仕事の進め方もある。

つまり残ったのは、

コードではなく、判断の基準

でした。

でも、Knowledgeは貯めるだけでは意味がない

ここで次の問題に気づきます。

18件のKnowledgeができた。これが100件、500件になったとして——

次の案件で、本当に見るのか？

毎回Obsidianを開いて、「今回使えそうなKnowledgeは……」と探すのか。それでは、また続かなくなります。

Knowledgeは貯めるだけでは意味がありません。必要なときに、向こうから戻ってこないといけない。

そこで、逆方向のSkillをつくることにしました。

まとめ

  • GitHubの履歴には「判断」が残っている → AIに読ませて学びを取り出す
  • 大事なのは抽出より捨てる基準（新規・追記・却下）
  • AIは候補を出すまで。採用を決めるのは人間
  • 作業中は「振り返れる記録」、区切りで「判断の抽出」という二段構え
  • 最初の18件に残ったのは、コードではなく判断の基準だった

次回：第5回「過去の自分の知識を、次の案件に持ち込む」