AIが常に自分のことを知っている状態を作る — ナレッジ基盤編
前回の記事でOrbitの全体像を説明した。
3レイヤーの土台はナレッジ層だという話をした。
この記事ではナレッジ基盤の設計思想と、Orbitでの実装の考え方を書く。
AIに渡す「知識」とは何か
AIが自分のことを知っている状態を作ろうとしたとき、最初に詰まった問いがある。
「自分のことを知っている」とは、具体的に何を知っているということか？
「自分の技術スタック」だけ知っていても足りない。
「自分の価値観」だけでも足りない。
「過去に参加した案件の記録」だけでも足りない。
AIが本当に役に立つのは、これらが組み合わさって「自分というエンジニアの文脈」として機能するときだ。
そこで気づいたのは、AIに渡す知識には2種類あるということだった。
「外の世界についての知識」と「自分についての知識」は、
性質がまったく違う。
「FastAPIの設計パターン」は外の世界の知識だ。
自分が知っていようが知っていまいが、その知識自体は変わらない。
一方「自分はFastAPIよりDjangoの方が設計しやすいと感じている」は自分についての知識だ。
自分の経験と主観から生まれるもので、他の誰かには当てはまらない。
この2つを同じ場所に混在させると、AIへの渡し方が曖昧になる。
「これは普遍的な知識として参照すべきか、それとも自分の判断パターンとして扱うべきか」がわからなくなる。
Orbitでは、この2つを明確に分けた。
外の世界の知識は「手札」として蓄積する
では「外の世界の知識」をどう蓄積するか。
最初に試みたのは、読んだ記事や学んだ概念をとにかくまとめておく、という方法だった。
これは失敗した。
蓄積はできた。でも使えなかった。
「GISのAPIを設計したい」と思ったとき、Wikiに何かあったはずなのに引き出せない。
「クリーンアーキテクチャの記事をまとめておいた」のに、実際の設計判断の場面で想起されない。
知識は増えているのに、仕事の質は変わらない。
根本的な問いを立て直した。
「知識を溜めることが目的か、それとも使うことが目的か」
答えは明らかだった。
使うことが目的だ。
だとすれば、知識の蓄積の仕方を「使うために置く」形に変えなければならない。
こうして「手札データベース」という設計思想に行き着いた。
手札とは、設計の壁打ちや技術選定のときに「これ使えるかも」と想起できる知識のことだ。
定義を書くのではなく、「いつ使うか」「何と組み合わせると機能するか」「どんな制約があるか」を書く。
この問いに答えられない知識は、手札として機能しない。
だからそもそも蓄積しない。
Orbitでは、この層を3_Wikiと呼んでいる。
ページごとに「いつ使うか」「組み合わせ」「制約・注意点」「実績」の4セクションを必須にした。
これを埋められないページは置かない、というルールにした。
自分についての知識は「スナップショット」として維持する
もう一方の「自分についての知識」は、外の世界の知識とは性質がまったく違う。
技術知識は基本的に変わらない。
でも「自分の現在地」は常に動いている。
今どのプロジェクトに関わっているか、今週何にフォーカスしているか、今どんな判断パターンが自分らしいか。
これらは週単位・月単位で変わる。
ここで陥りがちな罠がある。
「どんどん追記していく」という運用だ。
自分も最初はそうしていた。
気づいたことを追記し続けた結果、AIへのエントリポイントになるファイルが50を超えた。
「このエンジニアは今何をしているか」をAIが把握するために、50ファイルを読まなければならない。
しかもどれが「今」の情報かわからない。
これでは「常に知っている状態」ではなく「大量の観察記録を持っている状態」になってしまう。
根本的な問いを立て直した。
「自分の文脈をAIに渡すとき、必要なのは履歴か、現在地か」
現在地だ。
履歴ではない。
過去の状態がどうだったかより、今の状態がどうかが重要だ。
だからOrbitでは「スナップショット」という概念を導入した。
ログのように追記し続けるのではなく、定期的に現在地を上書きする。
観察した事実を蓄積したいときは専用のログファイルに入れて、「現在地ファイル」には最新の状態だけを残す。
この層を4_Contextと呼んでいる。
ファイルごとに更新プロトコルを決めた。
根本が変わったときだけ書き換えるファイル、週次で上書きするファイル、観察を追記するだけのファイル。
それぞれ役割が違う。「置くだけ」を禁止して、どの更新プロトコルに従って変更するかを意識させる設計にした。
自動で育てる仕組みを作る
知識基盤を「使うときだけ更新する」運用にすると、メンテナンスコストが問題になる。
更新を意識しないといけない状態では、忙しくなると途端に陳腐化する。
だから「何もしなくても蓄積される経路」を作った。
Claude Codeにはフックという仕組みがある。
ユーザーが発言するたびに、裏でスクリプトを走らせられる。
これを使って、AIと会話するたびに発言の内容・感情・状態を自動でデイリーノートに記録するエージェントを動かしている。
自分が意識しなくても、仕事中の思考の断片が積み重なっていく。
週次レビューのタイミングで、このデイリーノートを見返す。
「一時的な感情か、繰り返し現れるパターンか」を判断して、パターンとして安定したものだけ4_Contextに昇格させる。
日々の観察が直接自分のコンテキストファイルに流れ込まないようにするための、フィルタリングの設計だ。
自分で組むときに大事にしてほしいこと
このシステムをそのままコピーしても、たぶんうまくいかない。
ディレクトリ構成やスキルの定義は、自分の仕事の仕方・使うAIツール・蓄積したい知識の種類によって変わる。
Orbitの実装はあくまで「自分の環境で試行錯誤した結果」であって、普遍的な正解ではない。
大事なのは実装ではなく、設計のときに問うた問いだ。
知識を「使うために置く」設計になっているか
「外の世界の知識」と「自分の文脈」を区別して管理しているか
自分のコンテキストはスナップショットか、それともログになっていないか
何もしなくても蓄積される仕組みがあるか
この問いに自分なりに答えを出した結果が、自分のナレッジ基盤になる。Orbitはその一例として読んで活用してみてほしい。
