今日、自分が書いた memory ファイルから、自分でも忘れてた記事の卵が 4 本蘇った。
「個人開発者の累積資産が複利で積み上がる」という抽象概念が、初めて自分の手で実装された瞬間だった。
1. 個人開発者だけが持ってる優位、のはずだった
組織で仕事してると、知識は人を介して散逸する。オフボーディング、関心領域シフト、ナレッジ共有コストの高さ。1 年前に誰かが解決した問題が、半年後には別の人が同じ詰まり方をする、というのを何度も見た。
個人開発者は、理論上ここが強い。全部の知見が同じ頭の中にあるから共有コストがゼロで、累積が累積として効くはず。
実際の自分はそうじゃなかった。
memory ファイルを 70 個近く書いてきて、各 1-3KB の濃縮した知見。MEMORY.md に hook をつけて検索しやすくしてある。それでも気付くと「あれ、これってどこかに書いた気がする」と過去の自分の発見を半分忘れた状態で再発見してる。Git log に同じ問題の解決 commit があるのに、思い出せない。
差を埋めてたのは結局「思い出して言語化する手間」だった。これが自分の認知容量で律速されてる時点で、個人開発者の理論上の優位は実現してない。
2. Claude Code が動く理由を、自分の記事 pipeline に移植する
Claude Code のメモリ仕組みは、相似形のヒントを持っていた。
セッション開始時に MEMORY.md の hook 全件が自動でコンテキストに焼き付けられる。各 hook は「次のセッションの自分が、何を尋ねたとき思い出すべきか」の視点で書かれてる。賢いモデルが index を持って、必要なときに full body を取りに行く。これが動く理由は 3 つに分解できる：
- エントリが小さい — 1 ファイル ~1-3KB、1 トピック。サブトピックが本文に埋もれにくい
- hook が retrieval-tuned — 検索用語が hook に再出してる
- 賢いモデルが半自動で hook を書く — 過去の自分が、未来の自分のために濃縮してる
この 3 つの構造が揃ってると、累積資産が複利で効き始める。
自分のサービス Kotonia の技術ブログには 58 本の記事が貯まってる。これに対しても同じ index 仕組みを持ち込めば、過去の記事から未踏 concept を機械的に発見できるはずだ。
問題は記事側の構造が真逆ということ。1 記事 5-15KB、サブセクション本文に埋もれた重要トピックが多い、description は SEO 用で retrieval-tuned じゃない、agent が読むには重すぎる。
ここを「Dreaming layer」と名付けた中間層で繋ぐ設計にした。生記事 (episodic) → semantic index (consolidated) → agent が逆引き、という階層。生物学的な睡眠中の記憶 consolidation の比喩そのまま。
技術詳細は別記事に書いたので、興味あればそちらを：Zenn: Dreaming layer の TF-IDF concept dedup を 26B 駆動で実装した話
3. 今日 4 本の draft が蘇った
pipeline を走らせた結果：
- 58 記事を semantic index 化（importance score 1-9、distribution が bell shape）
- 70 memory ファイルから未踏 concept を mining、ideas pool に投入
- 4 idea を Codex + ローカル 26B uncensored 経由で draft 化、
articles/_drafts/に着地
中身は全部、自分で書いた memory が元ネタなのに、自分でも「あ、これ書いてみたかったやつだ」って思ったやつだった。
具体的に：
- ASR/TTS 短文 A/B 罠 — Qwen3-ASR 1.7B → 0.6B 置換で本番劣化、revert の話
- CodeFormer による顔クリーンアップ — 0.54GiB/1.2s の grain 除去、Rust 配線
- voice chat の onomatopoeia 暴走 — frequency_penalty による感情爆発制御
- Stripe Product ID vs Price ID — 決済できない落とし穴の防御策
どれも、自分の memory に対応するエントリがあって、自分で過去にそこに重要な発見だと書き残してた。けど、その記憶が現在の自分の頭から自然に出てこなくなってた。pipeline がそれを「思い出して言語化する」を肩代わりしてくれた瞬間、初めて累積資産が複利として立った。
4. 構造的に失敗した箇所も、構造的に解決した
途中、自分でも見逃した重複が 3 件すり抜けた。「これ、既存記事 §3.3 と被ってない？」とふと気付いて pipeline 全体を見直す羽目になった。
agent の self-discipline (= prompt に「flagship 記事と被ったら REJECT せよ」と書く) を信じて enforcement レイヤを置かなかったのが原因だった。TF-IDF を tool 層に焼き込んで、agent が rule 違反不可能な構造に書き直した。
この話は別記事にした: agent の self-discipline は信用するな — tool 層 blocking で構造的に治した話
5. これが本当に複利で立つ条件
今日の loop が回ってみて、個人開発者の累積資産が複利で効き始める条件は 3 つに整理できる気がする：
- 生資産がそもそも溜まってる（memory file、commit message の「why」、開発ログ、決定理由）
- 生資産を semantic に圧縮する consolidation 層がある（人間が書く必要はない、agent に任せる）
- mining/draft/dedup が semantic index 経由で動く（生資産を直接舐めるのは context が破綻する）
逆に言うと、これらが揃ってない開発者は何年やっても「いつも目の前の問題だけ」になりがちで、累積が累積として効かない。memory + git の整備は「振り返り」じゃなく 未来の自分の自走能力への複利投資だった、というのが今日の発見。
組織だと #1 で詰む（個人の頭にしか残らない記憶が散逸する）。個人開発者は #2/#3 で詰みやすい（書いてるけど取り出せない）。前者は構造的に解けないが、後者は agent loop で解ける。
これが「個人開発者にしかできない知識複利」が現実的に立つ条件、だと思う。
余談: 今日この記事を書いた経緯
実はこの記事自体、自分が pipeline を走らせて生成された 4 draft とは別ルートで書いてる。理由は「フレッシュな体感は直接書く方が voice が乗るし速い」から。
pipeline が活きるのは「過去の自分が忘れた知見」の発掘で、現在進行形の出来事は人間が書いた方が早くて正確。両方使い分けるが今日の loop の使い分け原則になった気がする。
Kotonia の他の技術記事もどうぞ。