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

この記事でわかること

  • ためたKnowledgeを、次の案件で「思い出させる」仕組み
  • 過去の知識に引っ張られすぎないための優先順位
  • 「分からない」をAIに埋めさせない大切さ

前回（第4回）は、案件の履歴からAIにKnowledgeを取り出してもらう仕組みをつくりました。でも、ためるだけでは意味がない。今回は、その知識を次の仕事に持ち込む話です。

Knowledgeはつくった。で、いつ読む？

knowledge-extractorによって、案件の経験からKnowledgeを取り出せるようになりました。でも、Knowledgeは保存しただけでは役に立ちません。次の仕事で使われて、初めて意味があります。

そこで次につくったのが、knowledge-context（ナレッジ・コンテキスト）というSkillです。

役割はシンプルです。新しい案件を見たときに、

「過去のKnowledgeの中で、今回関係するものはどれ？」

をAIに探してもらう。

18件全部をAIに読ませない

最初に考えたのは「Knowledgeを全部Claudeに渡せばいい」でした。でも、それも違うと思いました。

18件ならできます。でも100件、500件になったら？ 関係ない知識まで大量に入ると、かえって判断の邪魔になります。

そこで、本の探し方と同じ手順にしました。いきなり全ページを読むのではなく、まず目次を見る、という順番です。

  1. まず索引（各Knowledgeの見出しと概要）だけを見る
  2. 今回の案件の中身を理解する
  3. 各Knowledgeを3つに分ける
    • 強く関連するもの
    • 状況次第で関連するもの
    • 今回は対象外のもの
  4. 本文まで読むのは、関係するものだけ

実際の案件で試してみた

テストに使ったのは、オンライン学習塾「キミラボ」のWebサイトです。

  • 静的HTML（WordPressなどを使わず、ページを直接つくる方式）のサイトとLP
  • Cloudflare Workersというサービスで配信
  • 公開前の仕上げ段階
  • お問い合わせフォームは、まだ見た目だけのデモ
  • 写真やイベント情報に、仮の素材が残っている

この案件に対して、18件のKnowledgeを照らし合わせました。

分類件数内容
強く関連4件仮素材とダミーデータ／公開フォーム／キャッシュ対策／レスポンシブの確認
状況次第2件静的サイトかCMSかの判断／生成物の「正本（元データ）」を一つにする考え方

本文まで読んだのは、合わせて6件でした。

なお、このテストは読み取りだけです。実行の前後を比べて、案件のファイルやKnowledgeに一切変更がないことも確認しました。「確認すべきことが見つかった」ことと「サイトの修正が終わった」ことは別の話です。

例：仮素材のKnowledgeが見つけたこと

過去のKnowledgeに、こんなものがありました。

「仮素材とダミーデータは、仮であると機械的に判別できる状態で置く」

実際のサイトを見ると、写真には「※仮」「サンプル」という表示がある。一方で、「成績アップ事例」の数値にはサンプル表示がありませんでした。

そこで、

「この数値は実績なのか、ダミーなのか？」

という確認事項が出てきました。もしダミーのまま公開されていたら大問題です。

過去のKnowledgeが「問い」を運んでくる

フォームについても同じでした。

過去に「公開フォームを自分でつくるときのスパム対策」というKnowledgeがありました。今回のサイトを調べると、フォームは見た目だけで、実際にはどこにも送信されていない。

すると、こんな問いが出てきます。

  • 公開前に、送信先をどうする？
  • 送信されたデータを処理する仕組みはどこに置く？
  • スパム対策は？

Knowledgeが答えを出しているというより、

過去の経験が、今回確認すべきことを思い出させてくれる。

この感覚がかなりしっくりきました。ベテランの先輩が横から「そういえば、あれ確認した？」と声をかけてくれるような感じです。

ただし、危ないこともある

過去にうまくいった方法をAIに渡すと、「では今回もそうしましょう」となりやすい。これは危険です。案件は毎回違うからです。

そこでknowledge-contextでは、優先順位をはっきり決めました。

① 今回のユーザー指示
      ↓
② 今回の仕様・ルール
      ↓
③ 今の案件から確認できる事実
      ↓
④ 過去のKnowledge

Knowledgeは一番下です。

過去の自分が何と言っていようと、今回の条件が違えば使わない。過去の知識は「参考意見」であって「命令」ではありません。

「分からない」を消さない

もう一つ大事にしたのが、分からないことを勝手に埋めないことです。

たとえばキミラボでは、「今後、誰がサイトを更新するのか」が分かっていませんでした。

過去のKnowledgeには「更新する人によって、静的サイトかCMSかを判断する」という考えがあります。だからといって「このサイトはCMSにすべき」とはしません。

答えは、

「更新者がまだ確認できていないので、現時点では判断できない」

です。

AIは空欄を埋めるのがとても得意です。でも仕事では、

分からないことを、分からないまま残す

ことも重要です。空欄をもっともらしい推測で埋めてしまうと、あとで大きなズレになるからです。

「過去の知識」「今の事実」「提案」を混ぜない

実際にテストしてみて、もう一つ直すことにした点があります。

AIが出した文章を見ると、

  • 過去のKnowledgeに書いてあったこと
  • 今回のサイトから見つけたこと
  • その2つからAIが提案したこと

が少し混ざっていたんです。そこで、今後の出力ではこれらを分けるよう、Skillの修正方針を決めました。

区分中身
Knowledgeの要点過去の経験から得た判断
今回確認できたこと今の案件の事実
今回への適用上の2つを踏まえた、今回への提案

たとえば、LPの中に「どこにもリンクしていないリンク（href="#"）」が27か所あったのは、今回のコードから見つけた事実です。自動返信メールや管理者への通知を用意しよう、という話は今回への提案です。どちらも、過去のKnowledgeに最初から書いてあったこととして扱ってはいけません。

また、過去のメモに対策が書いてあっても、今回すでにその不具合が起きているとは限りません。キャッシュやスマホでの表示は、実際の環境や実機で確認してから判断します。

この区別が、Knowledgeを長く使い続けるうえで大事になると思いました。

ここで初めて「循環の入口」ができた

knowledge-extractorだけのときは、流れは一方通行でした。

案件
 ↓
Knowledge

knowledge-contextができたことで、こんな循環を回す入口ができました。

案件
 ↓
経験
 ↓
Knowledge
 ↓
次の案件
 ↓
もう一度判断
 ↓
新しい経験
 ↓
Knowledgeを更新

ただし、今回確かめられたのは「過去のKnowledgeから、別の案件で確認すべきことを取り出せた」ところまでです。長く使って判断がどれだけ良くなったかは、これから確かめていく必要があります。

つくりたかったのは「判断が育つ仕組み」だった

ここまでつくって、ようやく気づきました。

僕がつくろうとしていたのは、Obsidianの便利な使い方でも、Claude Codeの便利なSkillでも、最強のAI環境でもありませんでした。

仕事を重ねるほど、自分の判断が少しずつ育っていく仕組み

をつくりたかったんだと思います。

そこで、この2つのSkillをClaude Codeに読ませて、「この仕組みから、僕の仕事のやり方を分析して」と頼んでみました。そこで出てきた言葉の一つが、

「判断の複利」

でした。

なるほど。僕がやりたかったのは、たぶんこれです。お金に利息がついて、その利息にまた利息がつくように、

判断を、次の判断の資産にする。

まだ残っている課題

もちろん、課題も残っています。

  • 古くなったKnowledgeを、どう減らすのか
  • Gitに記録されない仕事（打ち合わせや企画など）の経験を、どう扱うのか
  • 知識を「使う」回数より「整理する」回数のほうが増えてしまわないか

だからこれは、完成した「最強の環境」の紹介ではありません。自分が仕事を重ねていくための仕組みを、ようやく試し始めた記録です。

まとめ

  • knowledge-contextで、新しい案件に関係するKnowledgeだけを取り出す
  • 全部読ませず、索引 → 関連判定 → 必要なものだけ本文の順で
  • 過去のKnowledgeは「答え」ではなく「確認すべき問い」を運んでくる
  • 優先順位は「今回の指示 ＞ 仕様 ＞ 今の事実 ＞ 過去のKnowledge」
  • 分からないことは、分からないまま残す
  • 目指すのは「判断の複利」——判断を次の判断の資産にすること

次回：第6回「AIに仕事を任せたいわけじゃない。仕事をするほど『判断』が育つ仕組みをつくりたい」