テーゼ
ホワイトカラーは Claude Code / Codex のようなコーディング LLM を使い、仕事をしながら自分用の skill を書いて溜めるべきだ。それが複利になって他人と決定的に差がつく。
ほとんどの人は一歩手前で止まる。コーディング LLM でソフトウェアそのものを速く作ることに満足して、目の前の object-level のタスクをこなすところまで。だが一歩深い動きがある——目の前の開発タスクだけに集中するのではなく、自分の日々の仕事を自動化する skill を、たとえ毎日数%の時間でも書いて溜めること。
普通の仕事は「1日＝1日分の成果」で線形だ。skill を書く人は「1日＝仕事＋skill 作成、翌日以降＝skill が働く」。毎日わずか数%の改善でも、積み重なれば、タスクをこなすだけの人を遥かに引き離す。 これは比喩ではなく、金融の複利そのものだ。元本に利息がつき、その利息がまた利息を生む——skill が空けた時間が次の skill を生み、それがまた時間を空ける。
これは Jeremy Howard が自分のプロジェクト群でやってきたことの正体でもある——nbdev → fastcore → fastai → fasthtml → solveit と、仕事をしながら道具を作り、前の道具が次の土台になる。
昔、生産性で頭一つ抜けたのは Excelマクロ／シェルスクリプト／Emacs・Vim をカスタムできる人だった。今はそれが Claude Code Skills / Codex Tasks / MCP連携 / Agent Workflows / Personal Knowledge Base に置き換わっている。skill を書くとは労働所得を資本所得に変換する行為そのものだ。さらに Skill A・B・C が A+B、A+C、A+B+C と組み合わさると新しい能力が生まれる——通常の複利（足し算的な再利用）を超えた、ネットワーク効果に近い超線形の伸び。
まずここを腑に落とすことが核心だ。ほとんどの人はここに来ていない。 以下はこの複利を正しく回すための精緻化であって、核心の否定ではない。
だが複利するのは skill の山ではない
ここに罠がある。書いた skill そのものは減価する資産だ。 今日書く skill の多くは、ベースモデルがまだ安定してこなせないことへの回避策にすぎない。能力曲線が前に進むたびに一部は静かに無用になる。数を誇るのは虚栄の指標で、ジャンクな40個は手放せない3個に負ける。
本当に複利するのはメタスキル——何を符号化する価値があるか見抜く判断力だ。雑然としたワークフローを再利用・合成可能な最小単位に分解する力。「これは18ヶ月後にモデルが吸収する」と「これは持続する」の境界を見抜く目。持続する符号化とは、自分の文脈・美意識・組織固有の繋ぎ込み・汎用モデルが持ち得ないドメイン知識を運ぶもの。汎用能力こそ skill 化の投資先として最悪だ。そこはモデル本体がいずれ無料で肩代わりする。
このエッセイのネタ元の動画（“How AI agents & Claude skills work”）でも同じ趣旨が語られている——自分が持っていてモデルが持たない唯一のものは、自分の workflow・taste・strategy だ。モデルの強みに頼り、渡すべきは自分に固有のもので、一般知識ではない。React を使えと指示するな、モデルは知っている、と。いわゆる context engineering（「モデルはもう良い。差は harness と context だ」）は、このテーゼを一段低い高度で言ったものだ——モデルはコモディティで、その周りに巻くものがエッジになる。
差は情報ではなく規律にある
「そんなことは皆知っている」と言われる。だが知識はタダ同然なのにエッジは消えない。理由は秘密だからではなく、地味な事前構造化を誰もやらないからだ。大半の人は AI セッションを使い捨てにし、答えを得て立ち去り、翌日また同じ文脈を説明し直す——自動販売機のように使う。一握りは二度説明しないために文脈を外に出して固定する——工場のように使う。複利の優位は情報の格差ではなく規律の格差だ。
「毎日 skill を書け」は間違い
誤解されやすい。良い skill はカレンダーからではなく摩擦から生まれる。同じ作業を二度やった、同じ所で詰まった——その時に初めて符号化する価値が立つ。要らない skill を「日課だから」と想像で書くのは過剰設計で、自分でジャンクを量産することになる（YAGNI）。ただし摩擦は安全な既定値であって唯一の源泉ではない。既に知っているパターンなら、痛む前に構造化してよい——harness の設計はまさにそれだ（摩擦の前に組む）。それを見分けるのもまた判断であって、投機的な「将来要るかも」とは違う。
だから routine 化すべきは生産ではなく気づきだ。daily writing ではなく daily noticing / weekly codifying。毎日問うべきは「今日いくつ書いたか」ではなく「今日の仕事のどの部分を、もう二度と手でやらなくて済むようにしたか」。
ネタ元の動画の skill 作成法がまさにこれだ。workflow を見つけてもいきなり skill を書かない（彼はそれを最悪のやり方だと言う）。まずエージェントと手作業で一歩ずつやり、失敗させ、訂正し、成功する run を一度作ってから skill 化する。理由は、モデルは新入社員であって black box ではないから——新人にいきなり『財務レポート作って』と振っても、context が無ければ動けない。だから skill には成功 run の contextが要る。“scale for productivity, not for what looks cool” も同じだ——workflow も無いのに 15 個の sub-agent と 30 個の skill を並べるな。一つのエージェントから始め、skill を積み、本当に必要になってから sub-agent を足す。
複利には「沈む2週間」がある
正直に書いておく。複利には先に沈む期間（J-curve）がある。ネタ元の動画では、あるプロジェクトの立ち上げに「これはゴミか」と思う約2週間の投資期間があったと語られる。そして鋭いのは——この初期投資の辛さを誰も言わない、特に agent-harness の会社は（言えば資金調達に響くから）、という指摘だ。複利の話は伸びる部分ばかり語られ、沈む部分は売り手の都合で隠される。だが沈みを越えないと配当は始まらない。vending machine 的に使う多数派は、この2週間を越えられず、毎回ゼロから説明し直す側に留まる。規律の格差は、ここで脱落するかどうかでもある。
数百個は腐るか——小さくプリミティブに保てば負債を bounded にできる
数百の skill を抱えれば技術的負債が複利で膨らむ、という懸念はもっともだ。負債は消えない——だが設計で bounded に抑え込める。鍵は二つ。skill を小さくプリミティブに保つこと。実タスクとの紐付けを失わないこと。
- 小さく単機能なら故障が局在する。タスクが失敗しても、どの部品が原因か合成構造をたどれば切り分けられる（Unix哲学の do one thing well）。
- 疎結合なら全体の複雑さは部品の和に近づき、積にも指数にもならない。保守対象は原子の数百個であって、組み合わせの天文学的な数ではない。
- そして最強の点——自分が起点だ。 これらは外から降ってきた資産ではなく、自分のタスクが必要としたから自分が書いた。だから仕様は skill の外、実タスクに明示的に存在する。3年後に「なぜこれが存在するか」を推測する必要がない。
ただし無料ではない。発火条件（description）の調整、重複、古い skill の棚卸し、依存関係、discovery の負荷——これらの負債は消えず残り続ける。さらに「いつも一緒に使うから統合するか」「このタスク用に特殊化すると便利だ」という最適化の誘惑が、小さな原子を大きく文脈依存の塊へ育てる。腐る数百個は設計の失敗形であって、デフォルトではない。残った未解決問題は合成の正しさ——部品個々が正しくても、つなぐ順序や受け渡しに故障が宿りうる。これは机上で解く問題ではなく、実際に積んで詰まった時に像を結ぶ。壊れた箇所は失敗ではなく「ここは人間が握り続けるべき継ぎ目だ」という情報になる。地図は壊れた箇所の蓄積としてしか描けない。
Jeremy Howard という生き証人——ただし修正版の
このテーゼの最強の実例は Jeremy Howard だ。nbdev → fastcore → fastai → fasthtml → solveit。全部「自分の生産性を上げたい」から、object-level の仕事をしながら、その摩擦から抽出された。need-first であって build-first ではない。順番が逆——スペシャリストになろうとしたのではなく、自分の不満を解消したら結果的にそうなっていた。道具が道具を生む。
ただし彼が証明しているのは素朴版ではなく修正版だ。彼は使い捨ての skill を数百個書いたのではなく、少数のよく factored された持続的抽象（3個であって40個ではない）を抽出し、設計・リファクタ・テスト・ドキュメント化した。減価のダイナミクスすら彼に当てはまる——fastai v1 がpioneerした多くを PyTorch 本体が吸収した。成果物は減価し、appreciate したのは「何を抽象化すべきか見抜く目」だった。
private skill はいつ「資産」になるか——private → 組織 → public
もう一つ、過去に自分で書いていた重要な制約：純粋な private tool は、transferable asset としては compound しにくい。 Howard の道具が複利したのは公開して他人の土台になったからだ。だから「自分の思考を再現する skill が500個 = 会社の資産」と言うとき——500個の private skill は個人の生産性では複利するが、資産価値として複利させるには「公開＋解説」の層が要る。
ただしここでネタ元の動画が重要な区別を足してくれる。「他人の skill をダウンロードするな」——理由は (1) 攻撃ベクトル（セキュリティ）、(2) ダウンロードした skill には君の成功 run の context が無い。つまり——公開して複利するのは「移植可能な抽象」（nbdev のような context を持たない道具）であって、context を焼き込んだ個人 skill ではない。後者は本質的に持ち運べない（あなたのタスクと taste が埋め込まれている）。だから500個の個人 skill をそのまま他人が使える「資産」になるわけではない。資産価値として複利させたいなら、個人 skill から context を剥がして移植可能な抽象（フレームワーク／テンプレート）として再パッケージする一段が要る。これが skill → 公開ツール → インフラの階段の、実は一番難しい段だ。
そして public と private の間に組織という中間層がある。チームで共有される skill は、公開ほどではないが個人よりはるかに複利する。5人のチームなら、500個の private skill より、各人のトップ10を共有した40個の方が資産価値として複利する。これは「他人の skill をダウンロードするな」とも整合する——チーム内共有は「成功 run の context」を（暗黙にでも）共有できる最小単位だからだ。だから正確には private → 組織 → public の3層で、複利率は右ほど高く、context の移植コストも右ほど高い。
複利という比喩を、正確に
これは財務の有名な助言と同じ深層構造を持つ。線形の即時消費を我慢し、リターンを生む資産に変え、再投資して指数で伸ばす。労働所得を資本所得に。
特に効くのは Die with Zero の memory dividend——早期の経験が、その後の人生で何度も再賞味され繰り返し配当を払う。これは「元本成長型」ではなく「再賞味型」の複利だ。経験は一回きりで固定だが、思い出すたびに配当を払い、配当は再賞味した時にしか実現しない。
skill はこれに構造的に近い（経験は再賞味、skill は再実行・再利用——配当の出方は違うが構造は同じ）。skill の価値は （将来の再利用回数）×（1回あたりの価値）。早く書くほど再賞味の総和が増える。そして再利用されない skill は、思い出されない経験と同じで配当ゼロ——資産ですらない。利回りは「持っている数」ではなく「再賞味される頻度」だから、count は無意味だ。ただし memory dividend には写真・日記・匂いといったトリガーが内蔵されているのに対し、skill のトリガーは「同じタスクが再発すること」だ。つまり再賞味頻度を決めるのは skill の質だけではなく、カレンダー上のタスク発生確率——利回りの半分は外部要因にある。ここから自然に導ける：commit message や PR review のような高頻度タスクほど skill 化の優先度が高く、一回限りは書くな。これが設計の利回り的な正当化だ。
3層と、最も減価しにくい元本
| 層 | 複利の性質 | 減価するか |
|---|---|---|
| 個々の skill | memory dividend（再賞味型の配当） | する（モデルが吸収する） |
| skill フレームワーク自体 | 配当を入れておく「口座」 | する（今日は Claude skill、明日は別物） |
| 判断（judgment） | 最も減価しにくい元本 | しにくい（再較正で強くなる） |
skill は memory dividend で、いずれ褪せ、吸収される。フレームワークは口座で、いずれ乗り換える。判断も無敵ではない——モデル能力・市場・自分の目的が変われば古びる。だが skill や framework と違い、判断は再較正でき、その再較正のたびに強くなる。だから三層で最も減価しにくく、「利息on利息」で育つのは判断だ。何を符号化するか、何を捨てるか、このフレームワークはまだ最良かを問い続ける——その判断こそ最も重要な資産。
そして判断そのものが最高次の memory dividend でもある。判断を下した一回一回が、後で「より鋭い判断」として再賞味される。過去の符号化判断の蓄積が taste として何度も配当を払う。だから:
- skill = 経験の memory dividend（褪せる、吸収される）
- 判断 = それらの判断経験が複利した、最高次の memory dividend（最も褪せにくく、再較正で強くなる）
（この台帳に習慣——毎日「今日の仕事を外に出したか」と問う externalization の反射神経——を載せていないのは意図的だ。習慣はモデルにも framework にも依存せず判断に先行する土壌だが、配当を払う資産ではなく資産を生む行為だから、資産台帳ではなく前段「『毎日 skill を書け』は間違い」の節で扱った。3層はこの習慣という土壌の上に乗っている。）
脚注：素朴版の実装が現実に走っている——AnswerThis
YC Root Access の Ayush Garg（AnswerThis） が、このテーゼの素朴版を実装した実例を見せている（これは前節までの「ネタ元の動画」とは別のソースだ）。フルタイム2名＋契約者数名で ARR $2M超。中核は「self-extending agent——まだできない反復タスクに遭遇すると coding sub-agent にツールを作らせ、そのツールは永続化し将来のセッションでも使える」。これは本記事の「摩擦→符号化→永続化→複利」と、トリガー（カレンダーでなく反復＝摩擦）まで含めて一致する。彼が言う3種類の記憶——factual（コード/DBの読取コピー）／behavioral（毎ターン読む instructions.md）／procedural（自作ツール）——も、本記事の「judgment という元本／skill という配当」の運用形だ。
ただし動画は素朴版に留まる。本記事の精緻化の層が欠けている。(1) 動画は「45個も自作CLIがある」を成果として誇るが、本記事の基準ではそれは vanity——「ジャンクな40個は手放せない3個に負ける」。(2) 動画の agent は反復に気づくと即ツール化し、「いきなり書くな、まず手作業で成功 run を一度作ってから符号化せよ」という規律（成功 run の context 焼き込み）をスキップしている。つまり動画はこの記事を裏付ける証拠であって、更新する新情報ではない。
新しいのは1点だけ——「これは符号化する価値があるか」という判断の一部を agent に委譲している点だ。本記事は「routine 化すべきは生産ではなく気づき（daily noticing）」と書き、人間を判断の起点に置いた。AnswerThis はその気づき自体を半自動化する実験をしている。これは本記事の未解決部分——「手動から半自動へ」と「合成の正しさは机上で解けず、積んで詰まった時に像を結ぶ」——がちょうど当たる場所であり、上の2つの警告（数の罠／成功 run 規律）がそのまま効く。だから論点は「self-extending できるか」ではなく「判断の委譲をどこまで許すか」に移る。最も減価しにくい元本が判断である以上、それを最も委譲しにくい——委譲した瞬間、複利するはずの元本を手放しかねない。ここが、素朴版と修正版を分ける継ぎ目だ。
結論
skill は道具として「今の」最良の器にすぎない。減価せず残り続けているのは、ずっと判断の方だ。2ヶ月前に「目的地なき複利」と書き、今日それを再賞味してさらに鋭くした——この行為自体が、判断という元本が複利している現場だ。そしてもし2ヶ月前に外部化していなければ、今日また一から考え直していた。頭の中だけにある仕事は、存在しないのと同じ。