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

最近、Claude CodeとObsidianを使って、2つの仕組みをつくりました。

ひとつは knowledge-extractor。

もうひとつは knowledge-context。

名前だけ見ると、いかにもAIツールっぽい。

でも、この2つをつくりながら考えていたのは「AIをどう便利に使うか」ではありませんでした。

むしろ、自分がこれまでどう仕事をしてきたのか。そしてこれから、どう仕事をしていきたいのか。

それが少しずつ言葉になってきました。

僕はこれを、ひとまず

「西田井式・仕事のOS」

と呼んでみようと思います。

仕事が終わると、何が残るんだろう

Webサイトをひとつつくる。

完成して、公開して、納品する。

当然、Webサイトという成果物は残ります。

GitHubにはコードが残るし、コミット履歴も残る。仕様書やREADME、打ち合わせの記録なんかも残っている。

でも、次の案件が始まったときに、本当に欲しいのはそれだけなんだろうか。

たとえば前の案件で、

最初はAという方法で実装した。

ところが実機で不具合が出た。

原因を調べてBに変えた。

結果的に、ある条件ではBの方が安全だと分かった。

次の案件で欲しいのは、完成したコードを丸ごとコピーすることではありません。

欲しいのは、

「なぜAではなくBを選んだのか」

という判断です。

案件ごとにデザインも違う。クライアントも違う。予算も違うし、更新する人も違う。

成果物そのものは、そのまま次に使えないことが多い。

でも、

何を見て、どう考えて、なぜその判断をしたのか。

これは次の仕事でも使える。

だったら、仕事が終わったときに残すべきなのは、成果物だけじゃないんじゃないか。

そんなところから、この仕組みを考え始めました。

「記録」と「知識」は違う

そこでまず分けたのが、

記録と知識です。

GitHubには案件の記録を残します。

何を実装したのか。

何を変更したのか。

どこで失敗したのか。

なぜやり直したのか。

これは事実の記録です。

一方、ObsidianのKnowledgeに残すのは、その案件を通して得た「判断」です。

たとえば、

この案件ではこういうコードを書いた。

これは記録。

でも、

非エンジニアに引き渡すサイトでは、実装のしやすさだけでなく、引き渡した後に誰が更新するのかまで含めて設計する。

ここまで抽象化すると、別の案件でも使える知識になります。

つまり、

記録は事実。知識は判断。

この2つを混ぜないことにしました。

仕事中に、無理に「学び」をまとめない

もうひとつ決めたことがあります。

Knowledgeをつくるのは、基本的に案件の区切りです。

仕事をしながら、

「これは重要な学びだ！」

「これは次にも使えそう！」

と、いちいちKnowledgeにしません。

仕事中は、目の前の仕事に近すぎるからです。

その瞬間にはものすごく重要に見えたことが、後から考えると、その案件だけの特殊事情だったりする。

逆に、何度もやり直した小さな修正が、後から見るとものすごく重要な判断だったりする。

だから作業中にやるのは、

後から振り返れる記録を残すこと。

コミットに理由を残す。

仕様が変わったら古い情報を放置しない。

なぜ変更したのか分かるようにしておく。

そして一区切りついたところで、AIに履歴を読ませます。

knowledge-extractor ―― 経験から「判断」を取り出す

そこでつくったのが knowledge-extractor です。

ざっくり言えば、

案件の経験から、次の仕事でも使える知識を取り出す仕組み。

Claude CodeにGitHubのリポジトリを読ませます。

READMEだけではありません。

コミット履歴や変更の流れも見ます。

特に注目するのは、

「やり直したところ」

「不具合を直したところ」

「方針を変えたところ」

「同じような修正を何度もしたところ」

です。

僕は、うまくいったところより、ズレたところの方に学びがあると思っています。

最初からうまくいったことは、たまたまかもしれない。

でも、

「最初はこう考えた。でもダメだった。だからこう変えた」

という履歴には、判断の変化があります。

そこから、

「この経験は他の案件でも使えるか？」

を考えます。

Knowledgeは、増やせばいいわけじゃない

ここでかなり意識していることがあります。

Knowledgeを増やすことを目的にしない。

新しい学びっぽいものが出てきても、すぐに新しいノートにはしません。

すでにあるKnowledgeで説明できないか。

既存Knowledgeに追記すれば十分ではないか。

本当に別の判断として独立させる価値があるのか。

それを確認します。

だから knowledge-extractor の結果は、

新規・追記・却下

に分かれます。

実際、ある案件を分析したときは、

新規3件。

既存Knowledgeへの追記3件。

却下9件。

却下が一番多かった。

でも、それでいいと思っています。

むしろ理想は、仕事を重ねるほど、

新しいKnowledgeがどんどん増えるのではなく、すでにあるKnowledgeが強くなっていくこと。

例外が加わる。

反例が加わる。

条件が細かくなる。

知識は「多い」より「効く」方がいい。

僕の中では、

少なく、強く、育てる。

という感覚です。

次の仕事では、過去のKnowledgeを「正解」にしない

そして、もうひとつつくったのが knowledge-context です。

こちらは逆方向です。

knowledge-extractor が、

経験 → Knowledge

なら、

knowledge-context は、

Knowledge → 今の仕事

です。

新しい案件を始めたとき、AIがまず現在のプロジェクトを理解する。

そのうえで、自分のKnowledgeの中から、今回の判断に関係しそうなものだけを探してくる。

ただし、ここで大事にしたのが、

Knowledgeをルールにしないこと。

過去にうまくいったからといって、今回もうまくいくとは限りません。

だから優先順位を決めました。

今回の指示。

今回の仕様。

現在のプロジェクトから確認できる事実。

そして最後に、過去のKnowledge。

Knowledgeは一番下です。

過去の自分より、目の前の現実を優先する。

「前はこうした」ではなく、「今回はどうする？」

たとえば過去の案件から、

「更新者が自分で情報を更新するなら、CMSを検討する」

というKnowledgeがあったとします。

だからといって、新しい案件を見て、

「CMSにしましょう」

とはしません。

今回、誰が更新するのか。

更新頻度はどのくらいなのか。

そもそも更新する必要があるのか。

分からなければ、

「未確認」

とする。

過去のKnowledgeと今回の条件を照らし合わせて、もう一度判断する。

つまりKnowledgeは、

答えではなく、問いを思い出させるもの

なのかもしれません。

「この条件、確認した？」

「前にここで失敗しなかった？」

「今回は本当に同じ判断でいい？」

そんなふうに、過去の自分が現在の自分に問いかけてくる。

僕がつくりたいKnowledgeは、そういうものです。

AIには「考えること」ではなく「考え続ける仕組み」を手伝ってもらう

ここまでつくってみて、AIとの付き合い方も少し見えてきました。

AIにはかなりのことを任せています。

大量のコミットを読む。

変更履歴から候補を探す。

既存Knowledgeと比較する。

似たものを見つける。

文章にまとめる。

次の案件で関係するKnowledgeを探す。

正直、これを毎回自分ひとりでやるのは無理です。

最初の数回はできても、そのうち面倒になってやらなくなる。

だからAIに任せる。

でも、

何を自分のKnowledgeとして残すのか。

そこは人間が決めます。

AIが候補を出しても、自動ではKnowledgeに入りません。

僕が確認して、採用する。

AIに任せたいのは、

読む、探す、比べる、整理する。

人間が持っておきたいのは、

選ぶ、決める、責任を持つ。

そんな分担なのかなと思っています。

AIは「未来の同僚」でもある

もうひとつ、最近面白いなと思っていることがあります。

今書いているドキュメントを読むのは、人間だけではないということです。

数か月後、別の案件でClaude Codeが読むかもしれない。

ChatGPTが読むかもしれない。

未来のAIが、過去の自分の記録を読んで仕事を手伝う。

そう考えると、記録の書き方も変わります。

古い方針をそのまま残さない。

決まっていないことを、それらしく埋めない。

分からないなら「不明」と書く。

なぜそうしたのかを残す。

AIを単なる道具ではなく、

未来の自分と一緒に記録を読む同僚

として考える。

これは、AI時代のドキュメントの作り方として結構重要なんじゃないかと思っています。

ただし、この仕組みも正解ではない

もちろん、今の仕組みには問題もあります。

Knowledgeは増えたり追記されたりするけれど、

「これはもう古い」

「この考え方は間違っていた」

と、知識を減らす仕組みはまだ弱い。

GitHubに残らない仕事もあります。

学校での探究。

地域での活動。

研修。

デザイン。

イベント。

EC。

僕の仕事のかなりの部分は、コードではありません。

そういう経験をどうKnowledgeにするのかも、まだできていません。

さらに怖いのは、

Knowledgeを整えること自体が仕事になってしまうこと。

Knowledgeが100件になった。

きれいに整理できた。

リンクが全部つながった。

でも、実際の仕事では何も変わっていない。

それでは意味がない。

Knowledgeの価値は、何件あるかではなく、

次の仕事で、実際に判断を変えたか。

そこにあるはずです。

だから、この「仕事のOS」自体も完成させるつもりはありません。

使いながら疑って、変えていく。

Knowledgeと同じです。

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

ここまで考えて、自分の仕事のやり方を一言で表すなら、

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

なのかなと思っています。

仕事をする。

迷う。

決める。

失敗する。

やり直す。

うまくいく。

そこから、判断を取り出す。

次の仕事では、その判断を持ってスタートする。

でも、過去の判断を正解にはしない。

今の状況を見て、もう一度考える。

そして、そこで得た経験をまた残す。

仕事
 ↓
経験
 ↓
判断を取り出す
 ↓
Knowledge
 ↓
次の仕事で参照する
 ↓
もう一度判断する
 ↓
新しい経験
 ↓
Knowledgeを育てる
 ↓
……

この循環を回していく。

僕がAIに期待しているのは、仕事そのものを代わりにやってもらうことではないのかもしれません。

仕事をするほど、自分たちの判断が育っていく状態をつくること。

AIが登場したことで、これまでなら面倒で続けられなかった「振り返る」「探す」「比較する」「再利用する」が、現実的にできるようになった。

だからAIを使う。

速く仕事をするためだけではなく、

次の仕事を、今より少し良い判断から始めるために。

今のところ、それが僕なりの「AIと仕事をする」ということです。