個人事業主のモノレポ運営術｜1人会社のディレクトリ構成
個人事業主や1人会社の経営者がプロジェクトを増やしていくと、どこかで必ず「ディレクトリがカオスになっている」問題にぶつかります。クライアント案件、自社プロダクト、SNS発信、経理、自己学習。これらが机の上のフォルダのように散乱し、どこに何があるのか自分でも分からなくなる。私自身、株式会社Fyveを1人で経営しながら個人発信もしている中で、まさにこの状態に陥りました。
本記事では、個人事業主が複数の事業・案件を同時に管理するための「モノレポ運営術」を、私が実際に ~/Desktop/projects/ 配下を組織として再設計したリアルな経験を元に解説します。Claude Code を中心に据えた1人モノレポは、「全プロジェクトを1つの組織として扱う」という発想転換で初めて運営可能になります。
個人事業主が直面する「フラットなディレクトリ」問題
個人事業主が複数のプロジェクトを抱えると、最初は「フォルダを分ければOK」という素朴な発想で始めます。私もそうでした。~/Desktop/ の下に fyve/、tajima/、クライアント案件A/、クライアント案件B/、経理/ といった具合に、思いついた順に並べていくのです。
ところが、案件が10件、20件と増えるとこの構造は破綻します。ある日、自分のプロジェクト一覧を眺めて呆然としました。ルート直下に28個のディレクトリがフラットに並び、クライアント案件・自社事業ハブ・実験用プロトタイプ・参考リポジトリ・保留中プロジェクトが完全に混在していたのです。
具体的に何が起きていたか
当時の私の projects/ 配下には、以下のような問題が累積していました。
- クライアント案件と自社事業ハブが同じ階層に並び、優先度の判断ができない
- 「stash」系のフォルダ（
tools/、on-hold/、web-clones/、references/）が役割未分化のまま乱立 - クライアント案件の置き場ルールが2系統共存（プラットフォーム獲得経路ごと vs ルート直下の直案件）
- ディレクトリ名から「これは現役か、終わったのか、保留中か」が判別できない
- 新しい案件が来たとき、どこに作るべきかその都度迷う
これは個人事業主に特有の問題ではなく、フリーランスや1人会社で複数案件を並走する誰もが通る道だと思います。1人だと自分で意識的に「組織設計」をしないと、ディレクトリは必ずカオスになります。
発想転換：個人事業主のモノレポは「会社の組織図」と同じ
カオスを解消するきっかけになったのが、ある日ふと立ち止まって考えた次のメタモデルです。
「個人名義も法人名義も、対外ブランディングの違いでしかない。事業として見れば全部1つだ」
個人事業主や1人会社の経営者は税務的に「個人」と「法人」を分けますが、実際の仕事の中身は連続しています。法人名義で受託した案件で得た知見が個人発信のネタになり、個人ブログの記事が法人サイトの集客につながる。経理は両方を扱い、学習は両方の糧になります。
であれば、ディレクトリ構成も「個人と法人を別管轄にする」のではなく、1つの会社の中に複数の部署があるという発想で設計すればいい。これが私のモノレポ再設計の出発点です。
組織メタファーで設計する
具体的には、以下のように対応させて考えます。
- 大ハブ（
fyve/、tajima/など）= 部署 - 末端ディレクトリ（個別クライアント案件、個別プロダクト、個別記事プロジェクト）= 社員 or 案件チーム
- 機能フォルダ（
scripts/、assets/、secretariat/）= 全社共通の管理部門 - 保留中・参考資料（
on-hold/、references/）= 倉庫・図書室
このメタファーを採用すると、新しい案件が発生したときの置き場所判断が一瞬で決まります。「これはどの部署の仕事か？」と問えばいいからです。同時に、ルート直下に置くべきものは「部署」と「全社共通機能」だけ、というシンプルな基準が手に入ります。
大規模リファクタの実例：28ディレクトリを17に削減
組織メタファーを決めた後、私は実際にモノレポを作り変えました。ここからは具体的な手順とビフォー・アフターを公開します。個人事業主が同じ轍を踏まないための実例として読んでください。
Before：ルート直下に何が混在していたか
リファクタ前のルート直下は、おおよそ次のような構成でした。
- 事業ハブ：
fyve/、tajima/、billing-ops/、project-hub/ - クライアント案件（直接契約）：単独のディレクトリで点在し、優先度の見分けがつかない
- クライアント案件（プラットフォーム経由）：
fyve/coconala/projects/、fyve/lancers/projects/に分散 - 自己学習：他の事業と同列にぶら下がる
- stash系：
tools/、on-hold/、web-clones/、references/ - 関連プロジェクト：終わった案件のアーカイブもそのまま
合計28ディレクトリ。一覧を ls で出すだけで画面が埋まり、何が現役で何が終わったのか視覚的に判別不能でした。
After：3つの「集約フォルダ」を新設して17ディレクトリに削減
リファクタの中心は、新しい集約フォルダを3つ作って、散らばっていたものをそこに集めることでした。
clients/新設：clients/{coconala,lancers,crowdworks,direct}/という4つのサブフォルダを切り、全クライアント案件8件をここに集約learning/新設：自己学習・資格取得系プロジェクトを集約secretariat/新設：取締役室・秘書役の機能を集約（project-hub/から rename）
結果、ルート直下は28 → 17ディレクトリに削減。一覧が1画面に収まり、「どこに何があるか」が即座に把握できるようになりました。ディレクトリ数を3割減らすだけで、認知負荷は体感で半分以下になります。
クライアント案件の配置ルール統一
リファクタ前の最大の混乱は、クライアント案件の置き場が2系統共存していたことです。プラットフォーム経由（ココナラ、Lancers、Crowdworks）の案件は fyve/{platform}/projects/ に置く一方、直接契約・紹介経由の案件はルート直下に置く、というルールでした。これは source（獲得経路）を物理パスに反映するという発想ですが、横断検索のコストが跳ね上がるという致命的な弱点がありました。
たとえば「次に対応すべき案件は何か？」を確認したいとき、fyve/coconala/projects/、fyve/lancers/projects/、ルート直下の3箇所を見に行く必要があります。
これを clients/{coconala,lancers,crowdworks,direct}/ に統一することで、クライアント案件は必ず clients/ 配下にあるという単純な検索パスが手に入りました。獲得経路ごとのサブフォルダは残すので、「ココナラ経由の案件だけ」を抽出するのも引き続き可能です。
フロントマター駆動運用：物理移動しない設計の力
モノレポを組織として運営するうえで、もう1つ重要な設計判断があります。それが フロントマター駆動運用 です。
stage は frontmatter で管理し、物理移動しない
クライアント案件には必ず stage（lead, estimate, negotiating, active, delivered, lost, dormant）が存在します。素朴な発想だと「stageごとに親フォルダを作って、進行に応じて移動する」と考えがちです。leads/、active/、delivered/ といった具合に。
しかし、私はこれを明確に否定しました。理由は2つあります。
- stageが変わるたびに
git mvする「移動の儀式」が発生し、しかも忘れやすい - 同じクライアントのファイルパスが時間とともに変わるので、過去のメモやリンクが壊れる
代わりに採用したのが、stageは各案件のCLAUDE.mdのfrontmatterで管理する方式です。
---
client: クライアント名
source: coconala
stage: active
next_action: 提案書のドラフトを送る
next_action_by: 2026-05-10
amount_estimated: 300000
started_at: 2026-04-18
---これなら、stageが変わるときに書き換えるのは frontmatter の1行だけ。ディレクトリは動きません。grep -r "stage: active" で全アクティブ案件を一覧でき、過去案件の振り返りも同じ方法でできます。
アーカイブは active/archive の2状態のみ
多くのモノレポでは「進行中」「完了」「失注」「保留」などstageごとに物理フォルダを分けがちですが、私は active と archive の2状態だけに絞りました。clients/{platform}/_archive/ という1つのフォルダだけを置き、stageが delivered または lost になった案件を手動で移動します。
「自動化」ではなく「手動移動」にしたのも意図的です。アーカイブは 明示的な意思決定 なので、自動化すると「気づいたら案件が消えていた」状態になりかねません。手で動かす儀式があるほうが、むしろ管理しやすいのです。
1人モノレポを運営するための4つの原則
ここまでの試行錯誤で見えてきた、個人事業主のモノレポ運営における設計原則を4つにまとめます。これは私が実際にリファクタを通じて検証した、Claude Code モノレポにも応用できる普遍的なルールです。
原則1：1クライアント=1ディレクトリを絶対維持する
1つのクライアントに関するファイル（メッセージ履歴、提案書、契約書、納品物、設計メモ）はすべて同じディレクトリに置きます。フォルダを分散させると、横断検索のコストが跳ね上がるからです。
具体的には clients/{platform}/{client-name}/ 配下に messages/、proposal/、documents/、app/、output/ といった統一構造を持たせます。規模やプロジェクトタイプ（レッスン/開発/コンサル）で構造を変えないのがポイントです。使わないフォルダは .gitkeep で空のまま維持します。
原則2：プラットフォーム範囲を超えたら卒業させる
ココナラやLancers経由で始まった案件が、継続契約・大型案件・直接契約に発展することがあります。このとき、プラットフォーム配下から clients/direct/ に移動させます。
移動の判断基準は次の通りです。
- プラットフォーム単発を超えて継続契約に発展した
- プラットフォーム側のメッセージ機能を離れ、直接契約・直接連絡に切り替わった
- 独自ドメインや独立リポジトリを持つ規模に育った
移動時も source: coconala といった frontmatter は維持します。獲得経路の履歴は残しつつ、現在の管轄を物理パスで表現する設計です。
原則3：ルート直下には「部署」と「全社共通機能」だけ置く
個人事業主が陥りがちな罠が、「とりあえず思いついたフォルダをルートに作る」習慣です。これをやると数ヶ月でルートがカオスになります。
ルール化するなら、ルート直下に置けるのは「事業部署」「全社共通機能」「明確に分類された倉庫」だけです。それ以外は必ずどこかの部署配下に入れます。私の今のモノレポでは、ルート直下は次の17項目に絞られています。
- 事業ハブ：
fyve/、tajima/、billing-ops/、secretariat/ - 集約フォルダ：
clients/、learning/ - 全社共通：
scripts/、assets/ - 倉庫：
on-hold/、tools/、web-clones/、references/、_templates/ - その他：プロトタイプ系・実験系の独立した小プロジェクト
原則4：ハブの肥大化はクリーンアップの合図
リファクタの副次効果として、secretariat/（旧 project-hub/）の大規模クリーンアップを行いました。ファイル数 81,592 → 26、約2.5GB削減です。原因は過去のセッションログ・実験スクリプト・一時ファイルの堆積で、Claude Code でモノレポを運営していると必ず発生する現象です。組織再設計のついでに一掃するのが、最も心理的負荷が低いやり方でした。
Claude Code との相性：モノレポは「1つの会社」として扱える
このモノレポ運営術は、Claude Code との相性が極めて良好です。Claude Code はディレクトリのルートに CLAUDE.md を置くと、その配下のすべてのセッションでルールが自動適用される仕組みを持っています。
つまり、モノレポのルートに会社全体のルールを書き、各部署（fyve/、tajima/ 等）のルートに部署固有のルールを書くことで、自然な階層的ルール継承が実現します。クライアント案件のディレクトリにも個別のCLAUDE.mdを置けば、案件固有の文脈（クライアント名、stage、next_action）を Claude Code が常に把握した状態で作業できます。
これは「組織として設計する」という発想と完全に一致します。社員（=各案件のCLAUDE.md）は部署のルール（=部署のCLAUDE.md）に従い、部署は会社全体のルール（=ルートのCLAUDE.md）に従う。Claude Code モノレポは、組織図そのものをファイルシステムに落とし込む装置です。
関連して、モノレポ全体の運営戦略については以下の記事で詳しく書いています。
知見の蓄積ルール（CLAUDE.mdに何を書き、何を書かないか）については、こちらの記事も参考になります。
個人事業主だからこそモノレポを「組織」として設計する
個人事業主や1人会社の経営者は、自分1人で複数の役割を兼務します。営業、開発、経理、発信、学習。これを「個別のフォルダの集合」として扱うと、必ずカオスになります。
逆に、1つの会社の中に部署と社員が並んでいる組織図として扱えば、新しい案件が発生したときの置き場所判断、stageの管理、横断検索、Claude Code との連携、すべてがシンプルに整理できます。
私の場合、28ディレクトリを17に減らし、stage管理を物理移動からfrontmatter駆動に切り替え、クライアント案件を clients/ 配下に統一したことで、モノレポは「育つもの」から「設計するもの」に変わりました。Claude Code モノレポを軌道に乗せたい個人事業主の方は、まず一度ルートディレクトリの一覧を眺めて、「これは部署か、社員か、倉庫か」を問い直してみてください。それだけで、次にやるべきリファクタが見えてくるはずです。
御社の業務に合わせたClaude Code導入支援
「AIツールを導入したが、現場で使われない」を終わらせる。
業務課題のヒアリングから設計、ハンズオン実践、運用定着まで一貫して支援します。