「Claude Code環境」シリーズです。前回はClaude Codeを無人で自律改善させる autopilotを書きましたが、そちらで登場した「自動化スクリプト群」の整理が済んでいないと autopilot に何を渡すかも迷います。今回はプロジェクトの分類と場所を管理する仕組みの話です。
いまの台帳 ~/PROJECTS.md を数えると、Webアプリ・Chrome拡張・iOSアプリ・デジタル商品・受託・AI基盤・PC自動化・OSS評価合わせて40本超が並んでいます。ここまで増える前に「8カテゴリ + 台帳 + symlinkツリー」という体制を作りました。この記事はその設計の話です。
困りごと：プロジェクトは「ある」のに「どこにある」か分からない
~/dev/・~/Projects/・~/digital-products/・~/oss-trial/ に散らばったディレクトリを、Claude Codeが毎回 find ~ で探していました。探す時間だけでなく、状態（live/stalled/retired）・本番URL・収益化の有無も散逸していて、「あのアプリどうなってたっけ」を聞くたびに文脈から再構成していました。
台帳を1ファイルに集約して「聞いたらすぐ答えが出る」状態を作ることが目標です。
8カテゴリの切り方
~/PROJECTS.md の定義表をそのまま引きます。
| コード | 定義 |
|---|---|
01-webapp |
デプロイして使うWebアプリ/Webゲーム |
02-chrome-ext |
Chrome拡張(MV3)＋専用バックエンドAPI |
03-ios-app |
iOSネイティブ/配信ラッパー |
04-digital-product |
noteマネタイズ・デジタル商品・コンテンツ販売物 |
05-client-work |
業務委託・受注・会社repo（第三者owner remote = push注意） |
06-claude-tooling |
Claude/AIエージェント自体に作用する基盤・スキル・連携 |
07-pc-automation |
PC自動化・スクレイパー・CLIスクリプト |
08-oss-eval |
外部OSSの評価・実験・サンドボックス |
カテゴリが増えると意味が薄れるので、新設は「8つのどれにも本質的に収まらない時だけ」としています。
判定は名前でなく提供形態で決めます。たとえば autolike-license-server はAPI名称ですが、Chrome拡張のライセンス検証専用バックエンドなので 02-chrome-ext に入れています。名前で判断すると「API → サーバー → 01-webapp」と誤分類します。
核心：なぜ実体dirを動かさないか
「整理 = フォルダ移動」と思いがちですが、個人開発では絶対パスへの依存が3箇所に潜んでいます。
-
.vercel/project.json— Vercelとのリンクに絶対パスが入る。移動するとvercel deployが別プロジェクトに向く。 -
launchd plist —
ProgramArgumentsに書いたスクリプトパスが実パスで登録される。移動するとcronが死ぬ。 -
git worktree —
git worktree addで作ったworktreeのメタデータが.git/worktrees/<name>/gitdirに実パスを持つ。
実体ディレクトリの物理移動は厳禁。.vercel・launchd plist・git worktreeが絶対パス依存で壊れます。「分類」はsymlink＋台帳で表現します。
運用：台帳＋symlinkで分類を表現する
実体は触らず、~/Desktop/All-Projects/<カテゴリ>/ にsymlinkを張るだけです。
# 新規プロジェクトを分類する（実体は動かさない）
ln -sfn ~/dev/takugumi ~/Desktop/All-Projects/01-webapp/
# 確認
ls ~/Desktop/All-Projects/01-webapp/
# takugumi -> ~/dev/takugumi のように出る
ln -sfn の -f は既存symlinkの上書き、-n はリンク先がディレクトリでも末尾に潜り込まない指定です。この2フラグがないと二重ネストになります。
台帳 ~/PROJECTS.md は1行1プロジェクトで、パス・状態・収益化・本番URL・注意を持ちます（現在は現在は8カテゴリ × 合計40本超）。Claude Codeはこのファイルを読めば即座に「就活トラッカーのiOSアプリはどこ？」「live状態のものは？」を答えられます。
Claudeに分類させる手順
~/.claude/skills/auto/project-categorization/SKILL.md に手順を書いてあり、新規プロジェクトを作るたびに自動発火します。手順の核はこれだけです。
新規プロジェクト着手時、コードを書き始める前に:
1. 何を作るか確定 → 上の8カテゴリのどれかを選ぶ
（提供形態で決める。名前や第一印象でなく）
2. 既存8つに収まらない時のみ 09-<kebab> を新設
3. 実体を適切な親dir に作る
Webアプリ/拡張 → ~/dev か ~/Projects
商品 → ~/digital-products
OSS評価 → ~/oss-trial
4. ln -sfn <実体パス> ~/Desktop/All-Projects/<カテゴリ>/
5. ~/PROJECTS.md の該当カテゴリ表に行を追加
CLAUDE.md にも「新規プロジェクトを作る時は着手前に必ず8カテゴリへ分類する」と書いてあるため、Claudeは指示しなくても分類から始めます。
検証コマンド
# symlinkが正しく張れているか
ls ~/Desktop/All-Projects/01-webapp/
# 台帳に追記されているか
grep "takugumi" ~/PROJECTS.md
# client-workの場合：機密がignoreされているか
git -C ~/dev/<project> check-ignore credentials.json
踏んだ落とし穴
auto-skill の Pitfalls 節にまとめてあるものから引きます。
-
名前で分類して誤カテゴリ —
autolike-license-server（Chrome拡張バックエンド）を「サーバー =01-webapp」と入れかけた。package.json や README を読んで提供形態で判断する。 -
05-client-workの秘密鍵漏洩リスク —toc-seo/credentials.json（GCP鍵）が会社repo直下に裸で置かれていた。client-work を作るたびに.gitignoreに秘密鍵パターンが入っているか確認する。 -
第三者ownerのremoteにpush —
ababa-pr/*・fujibee/*は05-client-work扱いでpush厳禁。git remote -vでownerを確認してからpushする。 - カテゴリを増やしすぎる — 迷ったら無理やり8つに収める。新設カテゴリは「8つのどれにも本質的に入らない」時だけ。
まとめ
- プロジェクトが増えると「ある」のに「どこにある」「状態は何か」が分からなくなる
- 実体dirは絶対に動かさない（.vercel・launchd・git worktreeが壊れる）。分類はsymlink＋台帳で
- 8カテゴリは提供形態で決める。名前で判断すると誤分類する
- 台帳
~/PROJECTS.md+~/Desktop/All-Projects/<カテゴリ>/symlinkツリーが正典 - CLAUDE.mdに「着手前に分類」と書けば、Claudeが毎回自動でやってくれる
次回は、こうして整理したプロジェクト群を毎朝Mermaid図に自動生成してDesktopに置く仕組みを書きます。
Lily（@bokuwalily）― 個人開発者。Claude Code で自動化基盤を組みながら、iOSアプリやWebサービスを量産しています
- 作ったアプリは ポートフォリオ にまとめています📱
- 新着・開発の裏側は X @bokuwalily で発信しています🌍
- OSS: github.com/bokuwalily 🐙
- この仕組みで「作業」じゃなく「環境」を回して月120万に戻した話は noteに無料で 書いています
皆さんの ❤️ やシェアが励みになります！