keyaki 組織発展計画

keyaki を「AI が実際に業務を担う組織」として構築する。この組織自体が Scaffold プランの実証例であり、検証済みのアーキテクチャをそのまま顧客に提供する。

更新（2026-06-08）: 初期の「川上＋経理の2エージェント・オーケストレーター検討中」段階を脱し、 reatex 型のプロジェクト縦割り（専任PM制） へ再構成した。本ドキュメントを現状に合わせて改訂。

組織コンセプト

山下（社長）: 意思決定・方針策定・最終承認
AI エージェント群: 各業務を担う「社員」として機能。窓口（orchestrator）→ PM → 実装/専門プールの階層
That's Source 方針: 外部 SaaS に頼らず、サーバー（GCE VM）上で完結させる

Scaffold プランの差別化ポイントである「組織として動く AI」を、自社で先行実装・検証している。

現在の組織構成（プロジェクト縦割り・PM制）

山下（社長 / 最終承認）
  └─ orchestrator（千葉）          唯一の窓口・PM振分・報告集約。詳細は持たない
       ├─ pm-kodouflow            kodou flow 専任PM・進捗を所有
       ├─ pm-edanet               edanet 専任PM・進捗を所有
       │     ↓ inbox 投函
       ├─ engineer（川上）/ frontend（中村）/ backend（田中）   実装プール（横断・指示待ち）
       ├─ designer（山口）/ marketing（石川）                  専門プール
       └─ reviewer                 PR レビュー専任（コメントのみ・マージは山下）

  on-demand（常駐しない）: legal（大久保・法務）/ accounting（佐藤・経理）

各エージェントはディレクトリ単位で分離し、CLAUDE.md（ローダ）+ AGENTS.md（役割）+ DOCS.md（外部記憶）の3点セットで構成する。役割定義の SSoT は ~/agent/org.md、運用は ~/agent/MANUAL.md。

なぜ PM 制にしたか

初期のフラット構成では orchestrator が全プロジェクトの詳細を抱え込み、DOCS が肥大化して単一障害点になった。プロダクトごとに専任 PM を置き、PM が自分の DOCS.md を常に最新化することで、orchestrator は窓口に専念でき、「いつ報告を求められても即答できる」状態を保てる。新プロダクトは pm-<name>/ を足すだけで拡張できる。

モデル使い分け方針

エージェント	モデル	用途
orchestrator / PM / engineer / frontend / backend / designer / marketing / reviewer	Claude Code	判断・コーディング・設計・レビュー
accounting（佐藤）	ローカルLLM（Gemma 4 12B / Ollama + opencode）	経理の定型処理。脱クラウド課金の検証台

将来的に組織全体をローカル LLM へ寄せ、「使うほど一回あたりが安くなる」固定費型を目指す。その第一歩として低リスクな佐藤（経理）を Gemma 4 にローカル化済み（2026-06-06）。

稼働形態

インフラ: GCE g2-standard-4（NVIDIA L4 GPU・佐藤のローカル推論用）。tmux 常駐セッション。
稼働: 当面 オンデマンド（使う時だけ make start → 終わったら make stop でコスト最適化）。起動中は dormant 時間帯を設けず 24h 稼働（2026-06-07 確定）。
連携: ファイルキュー _shared/tasks/（inbox→doing→done→archive、mv でアトミック遷移）。
記憶/同期: 各 DOCS.md は git（keyaki-org-workdir）で管理。分岐はコンフリクトとして検知し人が解決する。

現在の到達点

領域	状態
組織構造	✅ reatex 型 PM 制へ再構成済み（2026-06-08）。org.md / MANUAL.md 整備
エージェントディレクトリ	✅ 構築済み（orchestrator / pm-* / 実装・専門プール / reviewer / オンデマンド）
ローカルLLM（佐藤）	✅ Gemma 4 12B + Ollama + opencode で稼働・検証成功（2026-06-06）
プロダクト	kodou flow（PWA β公開中）/ edanet（開発中）/ konoha（Tauri・開発中）
自律稼働	tick による自走。当面オンデマンド運用（フル24h常駐はコストが見合う段階で再開）

今後の検討事項

フルローカル化フェーズ: 佐藤の検証を踏まえ、実装ロールの一部を Gemma 等ローカル LLM へ段階移行
PM 粒度の最適化: プロダクト増に応じた pm-* の増設、reviewer 運用の定着
フル 24h 常時稼働への復帰判断（モデル品質・配管が固まり、コストが見合う段階で）
Scaffold テンプレートとしての汎用化（どこまで共通化・再現パッケージ化できるか）
将来的な法人化に伴う組織・経理構成の変更対応

Scaffold との関係

この組織の構築・運用プロセスそのものが Scaffold の開発ロードマップである。実運用で検証したアーキテクチャ・ドキュメント・ノウハウを、顧客向けターンキーパッケージとして提供する。汎用的な再現手順は AI組織のつくりかた（再現ガイド）に整理済み。

→ 詳細は Scaffold 提案書を参照