Issue #143 — Three Lines 6ディビジョン構成 / 日次経営会議 / トークン管理会計
| 項目 | 内容 |
|---|---|
| 階層構成 | CEO → IF層 → M層 → W層 の4層 |
| M層（ディビジョン） | Three Linesモデルに基づく6ディビジョン ■ 1線（VDU） Value Delivery Unit — 事業・プロダクト責任。複数人可 ■ 2線（BA） Business Admin — 経理・法務・調達 ■ 2線（H&A） Human & AI Resources — 人材・AI資源管理・育成・評価 ■ 2線（PMO） Project Management Office — PJ推進・ナレッジ管理・PJM生成 ■ 3線（OA） Operation Audit — 業務監査・品質・CLAUDE.md整合性 ■ 3線（SA） System Audit — 死活監視・セキュリティ・トークン管理 |
| W層（スキルプール） | 8種: researcher / architect / coder / tester / reviewer / docs / legal-reviewer / tax 拡張候補: writer > analyst > designer > support |
| PJM（有期） | PMOが生成する有期プロジェクトマネージャー。PJ完了で消滅 |
| 三線防御 | 1線（価値提供）/ 2線（管理・統制）/ 3線（独立監査）の分離原則を遵守 |
| 項目 | 内容 |
|---|---|
| CEO ↔ IF層 | Slack経由。bot.pyはSlack↔IF層の薄い中継のみ（ビジネスロジックなし） |
| IF層 ↔ M層 | IF層がM層の窓口。 IF層がM層に指示を出し、結果を受け取る。bot.pyがM層を直接呼ばない |
| M層 → W層 | M層がW層をCLI subprocess起動（都度起動・完了消滅） |
| M層 ↔ M層 | ディビジョン間の連携（例: VDU完了→OA監査、SA検知→VDU修正） |
| CEO直通禁止 | M層・W層はCEOに直接投稿しない。全てIF層を経由する |
| 項目 | 内容 |
|---|---|
| CEOからの指示 | Slackメッセージ → IF層が判断してM層にルーティング（現行と同様） |
| 日次経営会議 | 毎日定時にIF層が全M層を招集。全M層が参加する定期トリガー 定常アジェンダ: 1. 前日振り返り（各ディビジョンの実績報告） 2. 組織進捗（ディビジョン健全性） 3. PJ進捗（各PJの状況・ブロッカー） 4. リソース計画（トークン消費実績・配分計画） 持ち込みアジェンダ: - 課題棚卸（技術的負債・原則違反・未実装設計） - ルール設計（新規ルール提案・既存見直し） - 新規PJ起案 - CEOからの相談事項 |
| 時間トリガー | BA: 月末経費締め、月初請求書確認、契約更新日等 |
| イベントトリガー | GitHub Issue作成→PMO、PRマージ→OA、エラー検知→SA等 |
| ディビジョン間連携 | あるディビジョンの完了がトリガーとなり別ディビジョンが起動（例: VDU実装完了→OA品質監査） |
| 能動ループ | VDU等が自律的にコードベース観察→課題発見→実行するループ ※ 常駐が必要か、トリガー設計で代替可能かは設計フェーズで決定 |
| 項目 | 内容 |
|---|---|
| 要件 | 各M層は「常にいる」状態が望ましい（CEOの意向） |
| 常駐のメリット | 能動ループ可能 / 即時応答 / 文脈がメモリ上にある |
| 非常駐（--resume） | 文脈維持可能 / idle時プロセスなし / 能動ループ不可 / 毎回起動コスト |
| 判断基準 | トリガー設計に依存する。日次経営会議等のトリガーで全M層を呼び出せるなら非常駐でも可。 常駐が必須かどうかは設計フェーズで検証する |
| 技術選択肢 |
Claude Code SDK (TS) / Claude CLI `-p --resume` / tmux + interactive / subprocess stdin pipe ※ Claude Code CLIが推奨する枠組みを優先採用する方針。設計フェーズで確定 |
| コンテキスト管理 | 長時間セッションはCLIのcompact機能で圧縮。問題があれば特定期間で引き継ぐ設計も可 |
| 項目 | 内容 |
|---|---|
| 背景 | 一般企業の管理会計に相当。トークンをリソースとして計画的に管理する必要がある |
| 消費計測 | ディビジョン別・PJ別のトークン消費実績を計測・記録 |
| 配分計画 | 日次経営会議でリソース配分を決定。どのPJ・ディビジョンに優先配分するか |
| 制約 | Claude Max Planのトークン上限内で運用。レート制限時は優先度制御で対応 |
| 項目 | 内容 |
|---|---|
| 日次経営会議 | 各ディビジョンからの報告を受け、優先順位・リソース配分を決定 |
| APPROVAL_NEEDED | コスト発生・外部送信・破壊的操作はCEO承認待ち |
| 随時指示 | Slackから任意タイミングでIF層に指示可能 |
| 緊急停止 | 全M層を即座に停止するコマンド |
| 非同期確認 | CEO不在時もM層は自律実行。CEOは後から結果を確認し承認キューを処理 |
| 項目 | 内容 |
|---|---|
| 目的 | 全M層と現状の課題棚卸・優先順位付けを行う |
| アジェンダ |
1. 各ディビジョンの管轄範囲の確認 2. 現在のIssue・技術的負債の棚卸 3. 設計済み・未実装の機能の洗い出し 4. 実装済みだが原則に従っていないものの特定 5. ルール設計の初期議論 6. 優先順位決定・リソース配分 |
| 期待成果 | 全ディビジョンが自分の管轄で何を改善すべきか提案し、CEOと合意した優先順位で動き出す |
| 項目 | 内容 |
|---|---|
| パターンA: M層直接 |
軽微〜中程度のタスク。M層（VDU/BA等）がW層を直接起動し、自分でレビューして完了 例: バグ修正、ドキュメント更新、定型経費処理 |
| パターンB: PJ型 |
大規模・複数工程のタスク。PMOがPJMを生成し、工程管理する 例: 新機能開発、アーキテクチャ変更、大規模リファクタリング |
| 判断基準 | IF層がタスク規模を判断し、パターンAならVDU/BA等に直接ルーティング、パターンBならPMOにルーティング |
| 項目 | 内容 |
|---|---|
| PJライフサイクル |
1. CEO/VDUがPJ起案 → IF層がPMOにルーティング 2. PMOがPJMを生成、工程計画を策定 3. H&Aが必要なW層リソースを確保・割当 4. PJMがW層を起動し各工程を実行管理 5. VDU（発注者）が成果物をレビュー（Rv）し承認/差し戻し 6. OAが工程完了ごとに品質監査（OK/NG） 7. 全工程完了 → PJM → PMO → IF層 → CEO報告 8. PJ完了 → PJM消滅 |
| PJ中のループ |
工程内ループ: PJM → W層起動 → 成果物 → VDU Rv → NG差し戻し → W層再実行 工程間ループ: PJM → W層起動 → VDU Rv → OA監査 → PJM → 次工程 監査NG: OA → PJMに差し戻し → W層修正 → VDU再Rv → OA再監査 CEO承認ゲート: 重要マイルストーンでIF層経由でCEO承認を取る |
| ディビジョン | PJでの役割 | 関与タイミング |
|---|---|---|
| VDU | 発注者。PJMに委託し、成果物をRvして承認/差し戻し。事業価値・品質の最終責任 | 各工程の成果物レビュー時。PJMが工程を管理しW層を起動。VDUは成果物のRvで承認/差し戻しを行う |
| PMO | PJM生成・進捗管理・工程管理 | PJ全体。起案→計画→工程間遷移→完了/中止判断。PJMのライフサイクル管理 |
| H&A | W層リソースの確保・割当 | PJ開始時に必要なW層スキルを確認し割当。リソース不足時に追加調達。PJ間のリソース競合を調停 |
| BA | トークン消費の記録・管理会計 | PJ全体。工程ごとのトークン消費を計測・記録し、リソース計画との乖離を報告 |
| OA | 品質監査（独立した第三者視点） | 工程完了ごと。VDUのレビューとは別に、OAが独立監査。NG→VDUに差し戻し。三線防御の原則 |
| SA | 死活監視・セキュリティ | PJ実行中常時。W層プロセスの死活監視、セキュリティチェック。異常時はVDU/PJMに通知 |
| REQ-1 組織構造 | 確定 |
| REQ-2 通信構造 | 確定 |
| REQ-3 駆動モデル | 一部未確定（能動ループの実現方法） |
| REQ-4 プロセスモデル | 未確定（設計フェーズで決定） |
| REQ-5 リソース管理 | 方針確定・詳細未確定 |
| REQ-6 CEO関与 | 確定 |
| REQ-7 初回経営会議 | 確定 |
| REQ-8 タスク実行パターン | 確定 |
| REQ-9 PJ型フロー | 確定 |
| REQ-10 各DivのPJ関与 | 確定 |
MVV定義・リソース意思決定・社外折衝
Slack経由でIF層とのみ対話
唯一のCEO↔AIインターフェース
全スレッドがタスクの記録単位
Slack ←→ tmux のプロトコル変換器
ビジネスロジックなし
• Slack WebSocket維持（Bolt/Socket Mode）
• メッセージ → tmux send-keys
• tmux capture-pane → Slack投稿
• tmuxセッション死活監視・再起動
CEO専属インターフェース
ルーティング判断・結果整形・Issue起票
M層への指示はtmux send-keys
Value Delivery Unit
事業・プロダクト責任
開発・品質・リリースの成果責任
Business Admin
経理・法務・調達
Human & AI Resources
人材・AI資源管理
エージェント育成・評価
Project Management Office
PJ推進・ナレッジ管理
PJM生成・消滅
Operation Audit
業務監査・品質
成果物レビュー・CLAUDE.md整合性
System Audit
死活監視・セキュリティ
トークン管理・インシデント対応
技術調査・分析
設計・IF定義
コード実装
テスト作成・実行
コード/設計レビュー
ドキュメント
法務レビュー
税務判定
| ディビジョン | 駆動 | プロセス | 理由 |
|---|---|---|---|
| IFO | 常時待機 | Claude CLI 常駐（tmux） | CEOからのメッセージを即時受信 |
| VDU | 能動ループ | Claude CLI 常駐（tmux） | 磨き込みに終わりがない |
| BA | 時間トリガー | Claude CLI 常駐（tmux） | 締日・期限駆動 |
| H&A | 能動ループ | Claude CLI 常駐（tmux） | エージェント状態の観察・改善は常時 |
| PMO | イベント＋ループ | Claude CLI 常駐（tmux） | PJ発生時はイベント、進捗管理はループ |
| OA | イベント駆動 | Claude CLI 常駐（tmux） | 成果物が出たら監査 |
| SA | 能動ループ | Claude CLI 常駐（tmux） | 死活監視は常時 |
| W層（全8種） | 受動（委譲） | 都度起動・完了消滅 | M層からの委譲でのみ起動 |
CEO → Slack → bot.py（IF層ロジック内蔵）
↓ subprocess起動（毎回新規）
M層（dev / bo / legal）+ ai-ops
↓ subprocess起動（毎回新規）
W層（8種）
• bot.py = IF層 + ルーティング + 結果整形
• M層は1タスク1プロセス（起動→応答→終了）
• 文脈はセッションごとにリセット
• 能動的な起動手段なし（CEO発話のみ）
CEO → Slack → bot.py（薄い中継層）
↓ tmux send-keys
IF層（Claude CLI 常駐）
↓ tmux send-keys
M層（6ディビジョン、全て常駐）
↓ subprocess起動（都度）
W層（8種）
• bot.py = プロトコル変換器のみ
• IF層・M層はtmuxで常駐（文脈維持）
• 各ディビジョンが自律駆動モデルを持つ
• idle時はトークン/CPU消費ゼロ
Generated for Issue #143 — 2026-03-24
雑談・質問・スケジュール確認など、IF層が単独で判断・回答しM層に委譲しないケース
※ M層・W層は関与しない。IF層のみで完結する最短ルート
コード実装・設計・デプロイなど。VDU（1線）がフェーズ分解しW層に委譲、レビュー後にIF層へ返却
※ レビューNGの場合、修正指示とともにW層に差し戻し。OKになるまでループ
経費登録・請求書・契約レビュー・法的リスク評価など。BA（2線）がops/パイプライン実行またはW層に委譲し、レビュー後に返却
※ BAは経理・法務・調達を統合管理。経理→ops/パイプライン、法務→legal-reviewer、調達→docs等のW層を使い分ける
VDUが常駐セッション内で自律的にコードベース・Issueを観察し、課題を発見→W層に委譲→結果をIF層経由でCEOに報告
※ VDUは常駐セッション内で「観察→判断→実行→報告」を自律ループ。CEOは結果を非同期で確認。
※ APPROVAL_NEEDEDな操作（外部送信・破壊的変更）はCEO承認待ちで一時停止
月末・月初などの時間トリガーでBAが自動起動し、経費チェック・請求書確認・月次レポートを実行
※ BAは締日・期限に基づいて自動起動。経費登録など外部書き込みはCEO承認待ち（APPROVAL_NEEDED）
※ 確認のみの読み取り操作は自動完結し、結果のみ報告
SAが常時監視ループでエラー・異常を検知し、影響範囲を判断。自動復旧またはVDUに修正を依頼
※ SA→VDUのディビジョン間連携が発生するケース。SAは検知・判断・通知に責任、修正実行はVDUの責務
※ 軽微な異常（プロセス再起動等）はSAが自動復旧。CEOには事後報告のみ
VDUが実装完了後、OA（業務監査）が品質チェックを実施。三線防御の分離原則に基づく独立監査
※ OAはVDUから独立した視点で監査する（三線防御の原則）。VDU自身のレビューとは別のチェック
※ NG時はVDUに差し戻し→修正後にOAが再監査。OKになるまでCEOには上がらない
※ 同様のパターン: PMOがPJ計画策定→VDUに実行指示、H&Aが新W層追加→SAにレジストリ更新通知
規模の大きいタスクはPJ化する。PMOがPJMを生成し、PJMがW層を管理。各ディビジョンがPJライフサイクルに関与する
| 直接委譲型 | PJ型 | |
|---|---|---|
| 規模 | 小〜中（1ディビジョンで完結） | 中〜大（複数ディビジョン・複数フェーズ） |
| 管理者 | M層（VDU/BA等）が直接W層を起動 | PMOがPJMを生成。PJMがW層を管理 |
| PJ化の判断 | — | IF層またはM層が判断。複数Div横断・長期・CEO承認要の場合 |
| ライフサイクル | タスク完了で終了 | PJ開始→工程管理→完了→PJM消滅 |
| Div | PJにおける役割 | 関与タイミング |
|---|---|---|
| VDU | 技術判断・プロダクト方針。PJMが判断できない事項を支援 | 実行中（技術判断時） |
| BA | 予算・契約・法務チェック | 起案時（予算）、実行中（外部契約） |
| H&A | W層リソース確認・割当。完了後の振り返り・ナレッジ蓄積 | 起案時＋完了時 |
| PMO | PJ全体管理。PJM生成/消滅・進捗監視 | 全期間 |
| OA | 成果物の品質監査。独立視点でチェック。NG→差し戻し | 各フェーズ完了時 |
| SA | システム監視継続。異常検知時にPJM/PMOに通知 | 実行中（常時） |
外側ループ（PMO管理）:
PMOがPJ計画策定 → PJM生成
↓
内側ループ（PJM実行）:
PJMがフェーズ分解 → W層起動 → 成果物受領
↓
OAに品質監査依頼
↓ NG → PJMに差し戻し → W層に再委譲（内側ループ）
↓ OK → 次フェーズへ
↓
全フェーズ完了 → PMOに報告
↓
PMOがPJ完了確認 → PJM消滅 → H&Aが振り返り記録
↓
IF層がCEOに最終報告
割り込み:
SA異常検知 → PJM/PMOに通知 → 対応判断
CEO指示変更 → IF層 → PMO → PJM計画修正
VDU技術判断要請 → PJMがVDUに相談 → 判断を反映
BA予算超過 → PMOに警告 → CEO承認待ち
• PJMは有期: PMOが生成し、PJ完了で消滅
• OAの独立性: PJM/VDUとは独立に品質監査（三線防御）
• SAは常時: PJ実行中もシステム監視を継続。PJに従属しない
• H&Aは始点と終点: リソース確認（始点）と振り返り・ナレッジ蓄積（終点）
• 内側ループ: PJM→W層→OA監査がフェーズごとに回る
• 外側ループ: PMOが全体進捗を監視し、PJM間の依存関係を管理
Generated for Issue #143 — 2026-03-24