Context Engineering
Private — 個人の運用知見腐らない知識を、
AIに渡す。
AIと協働するために設計した外部の知識基盤について、模索している現状を紹介するノート。
人は忘れます。忘れるほど記憶は曖昧になり、曖昧な記憶では正しい判断ができなくなります。
AIとの協働も、根っこは同じ原理の上に立っています——判断の質は、扱える情報の質で決まるという原理です。ただし劣化の起き方は人とは違います。人は時間とともに記憶そのものが曖昧になっていきますが、AIは渡された情報の量と質に、判断の質がそのまま規定されます。少なければ判断は浅くなり、多すぎればノイズに溺れます。だから大切なのは「正しい知識を、正確に、過不足なく」渡す設計そのものだと考えています。
この感覚は以前からぼんやり持っていて、2025年9月ごろに vault として実践に落とし込み始めました。試行錯誤を重ねた結果、今では思いついたことを迷わず全部投げ込めるようになっています。以下では、その設計を支える5つの原則、ルールのない置き場との違い、そして実際の仕組みを、今の到達点として書き残しています。
Foundations
5つの原則
この設計は、5つの原則の上に成り立っています。
01
外部化
AIのメモリには限界があると考えています。だから知見を閉ざされたメモリに留めず、全部外部の置き場に投げ込みます。取捨選択は後回しにし、まずはできるだけ多く投げ込むことを優先します。
02
分離
知識には二種類あると考えています。上書きされる「事実の台帳」と、追記されるだけの「ある時点の記録」です。混ぜると、古い所感がいつまでも事実の顔をして残り続けます。
03
自己修復
ルールは作った瞬間から守られなくなるリスクがあります。だから週次でvault自体をスキャンし、違反や矛盾を機械的チェックとAIの判断の両方で検知し続けます。
04
選別
何を書き残すかは、置き場所ではなく入り口で決めます。低摩擦な明示的なコマンドで拾い、AIの自発的な判断には委ねません。判断を安定させると、あいまいな「どこに置くか」の悩みも減ります。
05
忘却
拾った記録のすべてが使われ続けるわけではありません。参照されず古びたものは、消さずに検索の優先度だけを下げます。人の記憶が忘れることで壊れずにいられるのと同じ発想です。
Comparison
ルールで何が変わるか
ルールのないメモ置き場や、AIのメモリ機能そのままとは何が違うのでしょうか。
ルールのない置き場
- 容量に制約があり、増やせる知見の量に上限があります
- 情報が古くなっても、誰も気づきません
- AIの検索は玉石混交の中からの手探りになります
知識基盤 + ルール
- 外部化しているので、投げ込める知見の量に事実上の上限がありません
- 週次チェックが陳腐化・矛盾を検知します
- ルールに沿って整理されているので、AIは必要な情報だけに正確にアクセスできます
情報量が増え、かつアクセス精度が落ちません。結果として知見は、使うたびに古びる負債ではなく使うほど効いてくる資産になります。
Reality Check
直したいところ
もちろん、まだ設計として甘い部分もあります。
- ルールを作っても、ちゃんと守られているかのチェック自体に穴があり、気づくのが遅れることがあります
- 気づいたことを「ルールの改善」に変換する工程は、まだ自分の手作業に頼っている部分が多いです
- 「これは事実の台帳か、ある時点の記録か」の切り分けは、今のところ経験則任せなところがあります
For Engineers
仕組みの詳細
vaultのディレクトリ構造
永続ドキュメント（career / mental / personal / work / finance）と、運用ルールを定義する policies を分けて置いています。各ディレクトリの snapshots/ は追記専用のスナップショット置き場です。
knowledge-vault/ ├── career/ │ ├── career-history.md 永続：確定した事実の台帳 │ ├── periods/ 1期間 = 1ファイル │ └── snapshots/ ある時点の断面（追記専用） ├── mental/snapshots/ ├── personal/snapshots/ ├── work/ ├── finance/ └── policies/ ├── vault-writing-rules.md この設計のルールブック └── security-audit-log/
永続ドキュメントとスナップショットの分離ルール
永続ドキュメントには「時間爆弾ワード」を書かない、というルールがあります。書いた瞬間から陳腐化が始まる表現を禁止し、確定した日付に置き換えます。
| 禁止パターン | 代替 |
|---|---|
| 現在の担当は〇〇 | 2026年4月時点の担当は〇〇（→ 状態が変わったら追記ではなく書き換えます） |
| 〜になりつつある | 確定した状態と、それが確定した日付を書きます |
| 入社3ヶ月の所感（本編内に直書き） | snapshots/ に切り出して別ファイル化します |
スナップショット側は逆に「追記のみ・上書き禁止」です。過去の断面を書き換えると、時点ごとの変化が追えなくなるためです。
週次整合性チェックの中身
機械的チェックと、LLMによる意味判断チェックの二段構えです。前者は網羅性、後者は文脈理解を担当します。
機械的チェック（正規表現・ファイル走査ベース）
LLM判断チェック
各セクションが単独で取り出されても意味が通るか（自己完結性）を、文脈を理解した上で判定します。正規表現では拾えない「意味的な陳腐化」や「文脈依存の矛盾」はここで拾います。
唯一の例外として、スナップショットのdecay_score（検索優先度の指標、下記参照）だけはこのチェックが自動で書き換えます。それ以外のフィールド・本文は一切自動更新しません。
選別と忘却の実装
「選別」は、明示コマンドでのみ起動するスキルとして実装しています。会話が自然に収束したとAIが判断して自発的に書き込む方式も試しましたが、実運用ではほとんど機能しなかったため、コマンド駆動一本に絞りました。
「忘却」は、スナップショットのfrontmatterに持たせた次のフィールドで表現しています。
| フィールド | 役割 |
|---|---|
| status | unprocessed → reviewed → folded。永続ドキュメントへの反映が済んだ記録は folded にする |
| last_reviewed | 直近でstatusが動いた日付。decay_scoreの経過日数計算の起点 |
| decay_score | 0〜100の検索優先度。経過日数で減衰し、他ファイルからの被参照数で回復する。folded になった分もわずかに下げる |
記録を削除することはありません。decay_scoreが下がっても、ファイルはsnapshots/に残り続けます。まだ運用を始めたばかりで、この計算式自体が妥当かは検証できていません。
スキルの3層アーキテクチャ
日常の運用は、役割ごとに4層に分けたAIエージェント（スキル）群で回しています。
Known Limitations
正規表現ベースの年齢・時間表現の検出パターンが甘く、同じ検出漏れが約2ヶ月直りませんでした。ただし並走するLLM判断チェックが代替検出していたため、レポート上の実害は限定的でした。「ルールを作る」と「ルールの実装を保守し続ける」は別の仕事だと気づかされた例です。
走査対象ディレクトリの想定が狭く、実在するファイルを「リンク切れ」と3週連続で誤検知していました。走査範囲をvault全体に広げて解消しましたが、気づいてから直すまでに数週間のラグがありました。
週次チェックが問題を検知しても、それをスクリプトやルールの改修に落とし込む工程は属人的なままです。記録だけが数週間積み上がることがあります。
走査・比較の範囲設計が甘いと、整合性チェック自体が誤判定を出します。ルールはメンテし続けないと腐る、という入れ子の教訓です。
スキルの挙動を2回続けて修正したのに、1回目のパッケージ化で「完了」と扱ってしまい、2回目の修正が未反映のまま残っていました。明示的に確認コマンドを叩いてもらって初めて気づきました。「ルールを直した」と「直した結果を実際に反映した」は別工程だと、ここでも同じ教訓を得ました。
今後は「気づき→ルール改修」のサイクルをどう機械的な習慣に落とし込むかが、次のテーマだと考えています。
References