Show original
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
Share
🌱Claude Code: From "Using" to "Growing"
AI translation
― Environment Setup Series Complete Summary
About 14 min read64
AI translation
― Environment Setup Series Complete Summary
Enjoyed this article?
Use "Request tipping" to ask the author to set up tip receiving.
This is the final installment of the Claude Code environment series, which has run for 14 episodes so far.
Up until now, we've built individual "components" one by one: "memory," "skills," "costs," and "self-repair." In this final installment, we're doing two things. First, we're rearranging those components on a single map and putting into words the "connections between components" that weren't written in individual articles, and the design principles that ran through everything. Second, we're directly answering the question that people who've read this far most want to know ―― "So, what actually happened with this environment?"
The first half is a technical summary (no new code appears). In the second half, I'll honestly write about what this environment actually produced ―― including the money side of things.
Arranging the articles I've written by role, it looks like this:
This is the part that couldn't be written in individual articles. The 14 pieces above look like separate themes, but they're actually running a single loop.
┌─────────────────────────────────────────────┐
│ │
▼ │
[記憶] ──→ [スキル] ──→ [自走/自動化] ──→ [可視化/監視]
4層memory 手順を蓄積 launchdで無人実行 死活監視・コスト
▲ │ │
│ ▼ ▼
│ [ガード] [自己修復]
└────────────────── 秘密/owner検証 壊れたら戻す
会話ログが記憶に戻る │
▲ │
└────────────────────────────────────────────┘
修復ログ・実測値が次の記憶になるPutting components in individually doesn't work. There's a chain of dependencies where "because there's memory, skills grow; because skills grow, autonomous operation works; because it runs autonomously, monitoring and guardrails are needed," and only when the loop closes does it become an "environment that keeps running without intervention." Reading the series in order teaches you how to build the components, but this way of connecting them was the real thing.
When arranged this way, what looked like separate themes kept showing the same thinking over and over.
This is what I repeated most in this series. Claude says "I did it," "I published 3 pieces," but those words and reality diverge. So conversation logs are ground truth with actual files as the source of truth, autopilot cross-checks self-reported counts against actual measurements, and hook measurement concluded "mean is broken by outliers, so look at p95." The more you delegate to AI, the more humans (and scripts) must hold verification.
The core of health monitoring was the design of "silent when normal, RED FLAG only when abnormal." A system that sends "everything's OK" every morning stops being read after 3 days. Make silence the default, and make deviations stand out. Self-repair works the same way: quiet when it fixes things, call humans only when it can't. The number of notifications is inversely proportional to trust.
The more something runs unattended, the more quietly accidents spread. Secret guard stops PII before push, and the launchd article touched on the pitfall that "launchd direct execution doesn't have hooks, so you need to re-implement secret scanning inside the script." The more human hands are removed from a path, the more doubly you guard it. Once you push an API key, there's no taking it back.
Self-replicating skills and project classification both worked on the principle of "don't create a perfect system upfront; add while using, and prune regularly." Skills go stale after 30 days unused, archive after 90. Have both a mechanism to add and a mechanism to subtract, so it grows without bloating. Like bonsai: you decide both which branches to grow and which to cut, and that's how it takes shape.
There was no design blueprint at the start. We just kept adding components one by one, and now it's like this:
I'm not bragging about the numbers; I'm leaving them as an example that "continuing to add one by one gets you here". If we'd tried to design 30 launchd automations from the start, probably none would have finished. Start small, fix when it breaks, add more. That's all.
If I were building from zero today, I'd add them in this order, following the chain of dependencies:
Doing it in reverse (lots of automation first, guardrails later) leads to painful silent accidents. Putting guardrails and monitoring "before scaling up" was the one and only biggest trick.
The technical summary ends here. But honestly, my motivation for building this environment wasn't just "to use Claude Code conveniently." It was to survive.
It started at ¥100k a month. Income while attending university, like a part-time job.
From there, I juggled multiple companies as an intern, and before I knew it, ¥600k a month. I thought that was pretty good for a student.
——Then it all disappeared in a single day. Company-initiated layoff. Income: zero.
Everything I thought I'd built collapsed in an instant, and I genuinely believed "I have nothing left."
But one thing remained. "The ability to build systems that keep running by my own hands."
Over the next six months, with Claude Code as my partner, I built from scratch the autonomous environment I've written about in this series. Memory, skills, automation, guardrails ―― adding components one by one, I built a "factory" that keeps producing content and apps almost unattended. Before I knew it: 30 launchd, 85 skills. And income had returned to ¥1.2M a month.
The reason I could recover wasn't grit. It was because I had "systems that keep running while I sleep." If I could say one thing to myself on that day when I hit zero, it would be this ―― "Keep going. The 'systems' you build, no one can lay off."
This environment didn't end as mere work efficiency. The 30 launchd and 85 skills are now continuously producing content (affiliate articles, YouTube scripts, article distribution) and apps (iOS microapp mass production → submission for review) as an almost unattended "factory." The cost is nearly zero ―― because the API charges run on just Claude Max's allowance and the free tier.
If the free series was "how to make organs," what remains is the story of connecting them all and running them as a "revenue-generating system." Specifically:
I've put it all together in a paid article on note.
📕 **Claude Code自律環境で、実際どう稼ぐか ― 仕組み・実例・始め方・サポート**
For the launch, I'm starting at a low price. As it gets read and sales come in, the price goes up, so the earlier you read, the cheaper it is. If you're interested, right after publication is recommended.
In parallel, I'm also starting a series on what we actually built with this environment. The "mass production of personal projects" series ―― the mass production flow from conceiving an iOS app in a day to submitting for review, automating daily affiliate article publication, and more, opening up the factory's insides one by one.
Thank you for staying with me this far. From "using" an environment to "growing" it ―― and the environment you grow actually feeds you. I'd be happy if this series becomes someone's first component.
Lily (@bokuwalily) ― Individual developer. Building automation infrastructure with Claude Code while mass-producing iOS apps and web services. ◼︎ Apps I've made are summarized at **ポートフォリオ** 📱 ◼︎ New releases and development behind-the-scenes on X **@bokuwalily** 🐦 ◼︎ OSS: **github.com/bokuwalily** 🐙 Your ❤️ and shares are encouraging!
これまで全14回連載してきたClaude Code環境シリーズの、最終回です。
ここまで一本ずつ「記憶」「スキル」「コスト」「自己修復」といった部品を作ってきました。この最終回でやることは2つ。ひとつは、その部品を一枚の地図に並べ直し、個々の記事には書かなかった「部品どうしの繋がり」と、全部に通底していた設計原則を言葉にすること。もうひとつは、最後まで読んでくれた人が一番知りたいであろう問い ―― 「で、この環境、結局どうなったの？」 に、正面から答えることです。
前半は技術のまとめ（新しいコードは出てきません）。後半で、この環境が実際に何を生んだのか ―― お金の話も含めて ―― 正直に書きます。
書いた記事を、役割ごとに並べるとこうなります。
ここが、個々の記事では書けなかった部分です。上の14本は別々のテーマに見えて、実は一本のループを回しています。
┌─────────────────────────────────────────────┐
│ │
▼ │
[記憶] ──→ [スキル] ──→ [自走/自動化] ──→ [可視化/監視]
4層memory 手順を蓄積 launchdで無人実行 死活監視・コスト
▲ │ │
│ ▼ ▼
│ [ガード] [自己修復]
└────────────────── 秘密/owner検証 壊れたら戻す
会話ログが記憶に戻る │
▲ │
└────────────────────────────────────────────┘
修復ログ・実測値が次の記憶になる部品を単体で入れても効きません。「記憶があるからスキルが育ち、スキルが育つから自走でき、自走するから監視とガードが要る」という依存の連鎖になっていて、ループが閉じて初めて「放っておいても回る環境」になります。連載を順番に読むと部品の作り方は分かりますが、この繋ぎ方こそが本体でした。
並べ直すと、別々のテーマに見えて同じ考え方が何度も出てきていました。
このシリーズで一番繰り返したのがこれです。Claudeは「やりました」「3本公開しました」と言いますが、その言葉と実体はズレます。だから会話ログは ground truth として実ファイルを正とし、autopilotは自己申告の回数を実測と突き合わせ、hook計測では「meanは外れ値で壊れるからp95を見る」と結論しました。AIに任せるほど、検証は人間（とスクリプト）が握る。
死活監視の核は「正常時は無言、異常時だけRED FLAGが出る」設計でした。毎朝「全部OKです」と通知が来る仕組みは、3日で誰も読まなくなります。沈黙をデフォルトにして、逸脱だけを目立たせる。自己修復も同じで、直せた時は静かに、直せなかった時だけ人間を呼びます。通知の数は、信頼と反比例します。
無人で動くほど事故は静かに広がります。秘密ガードはpush前にPIIを止め、launchdの記事では「launchd直実行にはhookが乗らないのでスクリプト内に自前で秘密スキャンを再実装する」という落とし穴に触れました。人手が抜けた経路ほど、ガードを二重に張る。一度でもAPIキーをpushすれば、取り返しはつきません。
スキルの自己増殖もプロジェクト分類も、「最初に完璧な体系を作る」のではなく「使いながら足して、定期的に間引く」運用でした。スキルは30日未使用でstale、90日でアーカイブ。増やす仕組みと減らす仕組みをセットで持つから、肥大せずに育ちます。盆栽と同じで、伸ばす枝と切る枝の両方を決めるから形になる。
設計図が最初にあったわけではありません。一本ずつ部品を足していったら、いまこうなっていました。
数字を自慢したいわけではなく、「一本ずつ足す」を続けるとここまで来るという実例として置いておきます。最初から30本のlaunchdを設計しようとしたら、たぶん一本も完成しませんでした。小さく始めて、壊れたら直して、また足す。それだけです。
もし今ゼロから組むなら、依存の連鎖に沿ってこの順で入れます。
逆順（先に大量の自動化、後からガード）でやると、静かな事故で痛い目を見ます。ガードと監視を「増やす前」に置くのが、唯一かつ最大のコツでした。
技術のまとめはここまでです。でも、正直に言うと、僕がこの環境を組んだ動機は「Claude Codeを便利に使いたい」だけではありませんでした。生きるためでした。
最初は月10万でした。大学に通いながらの、バイト感覚の収入。
そこから複数の会社をインターンとして掛け持ちして、気づけば月60万。学生にしては上出来だと思っていました。
——その全部が、ある日いっぺんに消えました。会社都合の解雇。収入はゼロ。
積み上げたつもりのものが一瞬で崩れて、「自分には何も残っていない」と本気で思いました。
でも、ひとつだけ残っていた。"自分の手で何かを回し続ける仕組みを作る力" でした。
そこから半年、Claude Code を相棒に、この連載で書いてきた自律環境をゼロから組みました。記憶・スキル・自動化・ガード ―― 部品を一本ずつ足して、ほぼ無人でコンテンツとアプリを生み続ける"工場"を建てた。気づけば launchd 30本・スキル85個。そして収入は、月120万まで戻っていました。
戻せた理由は、根性ではありません。"寝ている間も回る仕組み"を持ったからです。ゼロに落ちたあの日の自分に一言だけ言えるなら、こう言います ―― 「続けろ。お前が作る"仕組み"だけは、誰にも解雇できない」。
この環境は、単なる作業効率化では終わりませんでした。30本のlaunchdと85個のスキルが、いまコンテンツ（アフィリ記事・YouTube台本・記事配信）やアプリ（iOSマイクロアプリの量産→審査提出）を、ほぼ無人で生産し続ける「工場」として動いています。原価はほぼゼロ ―― API課金はClaude Maxの枠と無料Tierだけで回しているからです。
無料連載が「臓器の作り方」だったとすれば、残っているのはそれを全部繋いで"収益を生むシステム"として動かす話です。具体的には、
これを、note の有料記事に全部まとめました。
📕 **Claude Code自律環境で、実際どう稼ぐか ― 仕組み・実例・始め方・サポート**
発売記念で低価格スタートにしています。読まれて部数が出るごとに値上げしていくので、早く読むほど安いです。気になる人は公開直後がおすすめです。
並行して、この環境で実際に何を作ったかの連載も始めます。「個人開発の量産」シリーズ ―― 1日でiOSアプリを着想して審査提出するまでの量産フローや、アフィリ記事を毎朝自動公開する仕組みなど、工場の中身を一本ずつ開けていきます。
ここまでお付き合いいただき、ありがとうございました。環境を「使う」から「育てる」へ ―― そして、育てた環境は、ちゃんと自分を食わせてくれます。この連載が、誰かの一本目の部品になれば嬉しいです。
Lily（@bokuwalily）― 個人開発者。Claude Code で自動化基盤を組みながら、iOSアプリやWebサービスを量産しています
◼︎作ったアプリは **ポートフォリオ** にまとめています📱
◼︎新着・開発の裏側は X **@bokuwalily** で発信しています🐦
◼︎OSS: **github.com/bokuwalily**🐙
皆さんの ❤️ やシェアが励みになります！