🌳 BUILD YOUR OWN AI ORGANIZATION
🏢🤖
AIだけで回る「開発組織」を
自分のサーバーに作る
社長は自分ひとり、社員は全員AI。
VM上に役割分担したAIチームを常駐させ、寝てる間も開発が進む。
この資料はそれを"自分で再現する"ための設計図。
→ / Space で次へ
⚡ 何が起きるか
「AIに手伝ってもらう」から
「AIが組織として働く」へ
- 課題普通のAIチャットは 都度起動でコンテキストが消える/PCを閉じたら止まる。
- 発想サーバー(VM)にAI社員を常駐させ、役割で分け、ファイルで連携させる=組織化。
- 結果社長は窓口役に投げるだけ。組織が 自分で配って・作って・報告する。
24h 自走
窓口は Slack / chat
ローカルLLM も載せられる
cp -r で増員
🧩 仕組みの全体像
核となる6つの仕掛け
01VM + tmux
PCの電源に依存せず24時間稼働。GPUを積めばローカルLLMも。
02ディレクトリ分離
1人=1フォルダ。CLAUDE.mdを上位に置かず人格を分離。
03タスクキュー
inbox→doing→doneをmvで受け渡し。アトミック。
04オーケストレーター
窓口役が集約し各員をkickで起動。社長は窓口だけ見ればOK。
05tickループ
スケジュール機能で約10分ごと自走。一日中リアルタイム。
06DOCS.md 外部記憶
進捗をファイルに残す=いつ落ちても再開できる。
この6つを満たすディレクトリを置くだけで、誰でも再現できる ↓
📁 再現の土台
まずこのディレクトリ構成を作る
- ◆
_shared/ = 全員共通(会社情報・タスクキュー・起動スクリプト)。
- ◆1ロール = 1フォルダ。中身は必ず同じ3点セット。
- ◆これが組織の"オフィス"。増員はフォルダを足すだけ。
役割の数だけフォルダを並べる=そのまま組織図になる
org-agents/
├─ _shared/
│ ├─ COMPANY.md # 会社方針・ID・報告先
│ ├─ WORKFLOWS.md # git運用などの共通ルール
│ ├─ kick.sh # 各員を起動するスクリプト
│ └─ tasks/
│ ├─ inbox/ doing/
│ └─ done/ archive/
├─ orchestrator/ # 窓口・司令塔
│ ├─ CLAUDE.md AGENTS.md DOCS.md
├─ pm-xxx/ # プロジェクトPM
│ ├─ CLAUDE.md AGENTS.md DOCS.md
└─ engineer/ # 実装担当
├─ CLAUDE.md AGENTS.md DOCS.md
📄 各フォルダの中身
1人ぶんは「3ファイル」でできている
🪶CLAUDE.md
薄いローダ。下の3つをimportするだけ。起動時にこれが読まれる入口。
@../_shared/COMPANY.md
@AGENTS.md
@DOCS.md
🎭AGENTS.md
そのロール固有の役割・やること/やらないこと・tickフロー。人格の本体。
🧠DOCS.md
セッション間の外部記憶。進捗・決定・確認待ちを書き残す。状態の唯一の正。
- !ペルソナ分離の鉄則:人格定義を上位(
~/やグローバルCLAUDE.md)に置かない。cwdから上に遡って読まれるため、混ざると全セッションに漏れる。
🔁 連携のしくみ
受け渡しは「フォルダ間の mv」だけ
- ◆タスクは1枚のMarkdown。
inbox/に投函される。
- ◆担当が
doing/へmv=着手の合図。mvはアトミックなのでロック代わり。
- ◆終わったら結果を書いて
done/へ。窓口役が集約してarchive/。
DBもキューサーバーも不要。ただのフォルダで成立する
inbox/ 投函・未着手
↓ mv
doing/ 担当が掴んで作業中
↓ mv
done/ 完了・報告待ち
↓ mv
archive/ 集約済み保管
🧭 セッション管理をAIに委譲
窓口役が各員のセッションを kick する
- ◆窓口役(orchestrator)が指示を受け、担当の
inbox/に投函。
- ◆そして
kick.sh で担当を tmuxの裏で起動(非対話 claude -p)。
- ◆社長が気にするのは窓口役のコンテキストだけ。あとは組織が回す。
「誰をいつ動かすか」までAI側が判断・実行する
# orchestrator が実行
bash _shared/kick.sh engineer
# 中身(要点)
tmux new-session -d -s kick-engineer \
"claude -p '$PROMPT' \
--dangerously-skip-permissions \
| tee logs/engineer.log"
# → 裏でセッションが立ち上がり
# inbox を掴んで自走 → done へ
⏱️ 自走と記憶
10分tick → 進捗をDOCS.mdに残して眠る
- ◆各セッションは tick の最後に
ScheduleWakeup(600)=10分後に自分を再起床。
- ◆起床より先に必ず
DOCS.mdを更新するのがルール。
- ◆だから途中で落ちても、次回
DOCS.mdを読むだけでそのまま再開。
## tick 14:20 完了
- PR #42 レビュー待ち
- 経理ロール: 月次突合 done
- next: CI通ったらmerge
# ↑ ここから誰でも再開できる
🖥️ 土台のインフラ
なぜ"VM"なのか — 3つの効き目
🔌電源非依存
tmux常駐だからSSHを切ってもPCを閉じてもサーバー側で生き続ける。24h稼働の前提。
🧮ローカルLLM
GPUを積めばOllamaで自前モデルをサーバー内推論。API従量課金→固定費へ。
💬MCPで窓口
Slack / LINE WORKS のMCPを挿せばいつものチャットが窓口に。専用UI不要。
- →将来ローカルLLMの精度が上がれば、組織まるごとローカル化=「AI使い放題」が射程に入る(使うほど一回あたりが安くなる)。
🟢 構成例A(小さく始める)
4ロールのフラット編成
まずは少人数で。1ロールだけローカルLLMに載せて「脱クラウド課金」を検証する、といった始め方ができる。
窓口=チャットのMCP連携。少人数でも「窓口役+実働」の形は同じ
🔵 構成例B(スケールした編成)
3階層・プロジェクト別PM編成
同じ仕組みを役割を増やして拡張。窓口役の下にプロジェクト別PMを並べ、実装/レビューを横断で共有する。実運用で数日間の自走ログが積み上がっている成熟構成。
社長 指示・連絡(チャットMCP)
↓
🧭 orchestrator 唯一の窓口・振り分け・報告集約
↓ inbox投函 + kick
pm-A プロジェクト①
pm-B プロジェクト②
pm-C プロジェクト③
↓ inbox投函 + kick
engineer 横断実装
engineer-spot スポット
reviewer PRレビュー
📈 増員のしかた
新メンバー追加 = フォルダをコピーするだけ
1
既存ロールを丸ごとコピー:cp -r pm-loan pm-new
2
AGENTS.md を新しい役割・担当プロジェクトに書き換え(CLAUDE.mdはローダなので無修正でOK)
3
DOCS.md にそのロールの初期コンテキストを記入
4
窓口役(orchestrator)の担当一覧と kick.sh に新ロールを追記
構成が"フォルダの集合"だから、組織の拡大=コピペで完結する
✅ まとめ
あなたのサーバーにも、同じ組織が作れる
01VM+tmux
24h稼働+GPUでローカルLLM。
021人1フォルダ
CLAUDE/AGENTS/DOCSの3点セット。
03mvキュー
inbox→doing→done で連携。
04窓口役+kick
セッション管理ごとAIに委譲。
はじめの一歩:VMを1台立て、orchestrator/ と engineer/ の2フォルダから始める。あとは増やすだけ。🌳