要件定義書 — MNML自律組織アーキテクチャ（Issue #143）

Issue #143 — Three Lines 6ディビジョン構成 / 日次経営会議 / トークン管理会計

前提

組織構造・Division定義（4層構成・6ディビジョン・W層スキルプール・Three Lines モデル）は Issue #139 組織アーキテクチャ定義 を参照。本書は業務要件・機能要件・非機能要件等の「要件」を定義する。

REQ-1: 組織構造参照

項目	内容
4層構成	CEO / IF層 / M層 / W層
M層（Three Lines モデル）	1線: VDU（事業開発）/ 2線: BA（経理・法務）・H&A（人事・AI管理）・PMO（プロジェクト管理）/ 3線: OA（品質監査）・SA（システムリソース管理・監視）
W層	8種のスキルプール（researcher, architect, coder, docs, reviewer, tester, analyst, operator）
参照先	詳細は Issue #139 組織アーキテクチャ定義を参照

REQ-2: 通信構造

項目	内容
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層を経由する

REQ-3: 駆動モデル・トリガー設計

項目	内容
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等が自律的にコードベース観察→課題発見→実行するループ ※ 常駐が必要か、トリガー設計で代替可能かは設計フェーズで決定

REQ-4: M層プロセスモデル（未確定）

項目	内容
要件	各M層は「常にいる」状態が望ましい（CEOの意向）
常駐のメリット	能動ループ可能 / 即時応答 / 文脈がメモリ上にある
非常駐（--resume）	文脈維持可能 / idle時プロセスなし / 能動ループ不可 / 毎回起動コスト
判断基準	トリガー設計に依存する。日次経営会議等のトリガーで全M層を呼び出せるなら非常駐でも可。常駐が必須かどうかは設計フェーズで検証する
技術選択肢	Claude Code SDK (TS) / Claude CLI `-p --resume` / tmux + interactive / subprocess stdin pipe ※ Claude Code CLIが推奨する枠組みを優先採用する方針。設計フェーズで確定
コンテキスト管理	長時間セッションはCLIのcompact機能で圧縮。問題があれば特定期間で引き継ぐ設計も可

REQ-5: リソース管理（トークン管理会計）

項目	内容
背景	一般企業の管理会計に相当。トークンをリソースとして計画的に管理する必要がある
担当	SA（3線）が計測・記録・配分制御・最適化・停止提案を一貫して担当
消費計測	ディビジョン別・PJ別のトークン消費実績を計測・記録
配分制御	日次経営会議でリソース配分を報告。レート制限時は優先度に基づき配分制御
最適化	消費効率の分析、無駄なリトライの検知、リソース停止提案（最終判断はCEO）
制約	Claude Max Planのトークン上限内で運用

REQ-6: CEO関与ポイント

項目	内容
日次経営会議	各ディビジョンからの報告を受け、優先順位・リソース配分を決定
APPROVAL_NEEDED	コスト発生・外部送信・破壊的操作はCEO承認待ち
随時指示	Slackから任意タイミングでIF層に指示可能
緊急停止	全M層を即座に停止するコマンド
非同期確認	CEO不在時もM層は自律実行。CEOは後から結果を確認し承認キューを処理

REQ-7: 初回経営会議（移行の起点）

項目	内容
目的	全M層と現状の課題棚卸・優先順位付けを行う
アジェンダ	1. 各ディビジョンの管轄範囲の確認 2. 現在のIssue・技術的負債の棚卸 3. 設計済み・未実装の機能の洗い出し 4. 実装済みだが原則に従っていないものの特定 5. ルール設計の初期議論 6. 優先順位決定・リソース配分
期待成果	全ディビジョンが自分の管轄で何を改善すべきか提案し、CEOと合意した優先順位で動き出す

REQ-8: タスク実行パターン（M層直接 vs PJ型）

項目	内容
パターンA: M層直接	軽微〜中程度のタスク。M層（VDU/BA等）がW層を直接起動し、自分でレビューして完了例: バグ修正、ドキュメント更新、定型経費処理
パターンB: PJ型	大規模・複数工程のタスク。PMOがPJMを生成し、工程管理する例: 新機能開発、アーキテクチャ変更、大規模リファクタリング
判断基準	IF層がタスク規模を判断し、パターンAならVDU/BA等に直接ルーティング、パターンBならPMOにルーティング

REQ-9: PJ型フロー

項目	内容
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ライフサイクル

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承認を取る

REQ-10: 各ディビジョンのPJ関与

ディビジョン	PJでの役割	関与タイミング
VDU	発注者。PJMに委託し、成果物をRvして承認/差し戻し。事業価値・品質の最終責任	各工程の成果物レビュー時。PJMが工程を管理しW層を起動。VDUは成果物のRvで承認/差し戻しを行う
PMO	PJM生成・進捗管理・工程管理	PJ全体。起案→計画→工程間遷移→完了/中止判断。PJMのライフサイクル管理
H&A	W層リソースの確保・割当	PJ開始時に必要なW層スキルを確認し割当。リソース不足時に追加調達。PJ間のリソース競合を調停
OA	品質監査（独立した第三者視点）	工程完了ごと。VDUのレビューとは別に、OAが独立監査。NG→VDUに差し戻し。三線防御の原則
SA	システムリソース管理・死活監視・セキュリティ	PJ全体。トークン消費の計測・記録・配分制御。W層プロセスの死活監視。レート制限時の優先度制御。異常時はVDU/PMOに通知。リソース停止提案（最終判断はCEO）

要件ステータス

REQ-1 組織構造参照	確定（#139参照）
REQ-2 通信構造	確定
REQ-3 駆動モデル	一部未確定（能動ループの実現方法）
REQ-4 プロセスモデル	未確定（設計フェーズで決定）
REQ-5 リソース管理	方針確定・詳細未確定
REQ-6 CEO関与	確定
REQ-7 初回経営会議	確定
REQ-8 タスク実行パターン	確定
REQ-9 PJ型フロー	確定
REQ-10 各DivのPJ関与	確定
REQ-11 成果物管理ルール	確定
REQ-12 情報管理ルール	確定
REQ-13 設計原則	確定

REQ-11: 成果物管理ルール

項目	内容
配置規約	W層の成果物は各ワーカーの `output/` ディレクトリに配置例: agents/workers/architect/output/DESIGN_*.html, agents/workers/coder/output/ 等
HTMLデプロイ	HTML成果物は Cloudflare Pages（mnml-docs.pages.dev）にデプロイし、公開URLを共有 URL形式: `https://mnml-docs.pages.dev/issue-{番号}/{ファイル名}.html` デプロイは `<<ACTION>>{"type":"cf_deploy",...}<</ACTION>>` タグで実行
コミットルール	• コミットメッセージは英語 • 意味のある単位で1機能1コミット • `.env`、`.tokens*.json`、credentials等の機密ファイルを含めない • コミット前に `ruff` / `py_compile` でチェック
プッシュルール	• push前に `git pull --rebase` で最新取得 • force push は原則禁止（CEO承認必須） • main ブランチへの直接push はCEO承認必須
承認フロー	W層（コミット作成） → M層（内容確認・push判断） → push W層は単独でpushしない。M層が判断・指示する force push / main直接push → CEO承認が必要

REQ-12: 情報管理ルール

項目	内容
情報の棲み分け	GitHub Issues (info-mnml/issues): タスク管理・課題追跡 SharePoint (シェアドドキュメント): ビジネス文書全般（契約書・請求書・納品物・報告書） .md / CLAUDE.md (リポジトリ内): エージェント動作指示・技術仕様 Slack: コミュニケーション・リアルタイム指示
管理責任	GitHub Issues: PMO（PJ系）・各Division（自管轄） SharePoint: BA（契約・請求）・各VDU（納品物） .md: H&A（エージェント定義）・PMO（共通ルール） Slack: 全メンバー
原則	1. Single Source of Truth: 同一情報を複数箇所に置かない 2. ソースコードはGitHub: コード・技術ドキュメントはリポジトリ内 3. ビジネス文書はSharePoint: 契約書・請求書・納品物等 4. Slackは揮発性: 永続化すべき情報はGitHub/SharePoint/.mdに転記 5. CEO向けファイルはSharePoint: ローカル保存ではなくSharePoint配置+URL共有

REQ-13: 設計原則

#	原則	説明
1	スケーラブルに設計	1人法人を前提にしない。拡大しても破綻しない設計
2	現行実装名称の排除	組織設計は実装に依存しない
3	実装手段は後に決める	組織構造が確定してから実装手段を決定
4	同じものを2つ作らない	共通資産化を徹底。PMOが番人
5	リソース停止判断はCEO	SAが検知・報告し、最終判断はCEO

業務要件（Division別・UCナンバリング付き）

UCナンバリング規則: UC-{Div}-{連番3桁}
Div略称: VDU / BA / HA / PMO / OA / SA / CROSS（Div横断）/ IF（IF層単独）
例: UC-VDU-001, UC-BA-001, UC-CROSS-001

IF層（直接回答）

UC番号	ユースケース名	概要	アクター	トリガー
UC-IF-001	雑談・一般質問への即時回答	CEOからの質問・雑談にIF層が単独で回答。M層に委譲しない最短ルート	CEO	Slackメッセージ
UC-IF-002	スケジュール確認	CEOのカレンダー確認・空き状況の回答。外部APIアクセスを伴う場合あり	CEO	Slackメッセージ
UC-IF-003	タスクルーティング判断	CEOの指示を分析し、適切なDivisionにルーティング。PJ型 vs 直接委譲の判断を含む	CEO	Slackメッセージ

VDU — Value Delivery Unit（1線事業）

UC番号	ユースケース名	概要	アクター	トリガー
UC-VDU-001	CEO指示による開発タスク	CEOからの開発指示をIF層経由で受領。VDUがフェーズ分解しW層に委譲、レビュー後にIF層へ返却	CEO → IF → VDU	CEOのSlackメッセージ
UC-VDU-002	能動ループ: コードベース改善	VDUが自律的にコードベースを観察し、技術的負債・改善点を発見→実行。CEOの指示なしで起動	VDU（自律）	能動ループ（常時）
UC-VDU-003	バグ修正（軽微）	Issue起票済みまたはSA検知のバグ。VDUがW層（coder）に直接委譲し、レビュー後修正完了	VDU / SA → VDU	Issue / SA通知
UC-VDU-004	技術調査・PoC	新技術・ライブラリの調査。VDUがW層（researcher）に委譲し、調査レポートを受領	CEO / VDU（自律）	CEO指示 / 能動ループ
UC-VDU-005	設計レビュー承認	PJM経由でarchitectが作成した設計書をVDUがレビュー。承認/差し戻しの判断	PJM → VDU	W層成果物完了
UC-VDU-006	成果物最終受入	PJ完了時にVDUが事業価値・品質の観点で最終受入判断。全工程成果物を総合評価	PJM → VDU	PJ完了報告

BA — Business Admin（2線管理）

UC番号	ユースケース名	概要	アクター	トリガー
UC-BA-001	月末経費締め処理	月末にMFクラウド経費の仕訳・登録を自動実行。CEOに承認依頼	BA（自律）	時間トリガー（月末）
UC-BA-002	月初請求書確認・発行	月初にMFクラウド請求書の確定・PDF取得。未処理請求の確認とCEOへの報告	BA（自律）	時間トリガー（月初）
UC-BA-003	契約更新日リマインド	契約更新日の前にCEOにリマインド。更新/解約の判断を求める	BA（自律）	時間トリガー（更新日N日前）
UC-BA-004	CEO指示による経理・法務タスク	CEOからの経理・法務関連指示。BAがW層（tax, legal-reviewer）に委譲して処理	CEO → IF → BA	CEOのSlackメッセージ
UC-BA-005	月次作業報告書生成	Outlookカレンダーから月次作業報告書（Excel）を自動生成。CEOに確認依頼	BA（自律）	時間トリガー（月末）

H&A — Human & AI Resources（2線管理）

UC番号	ユースケース名	概要	アクター	トリガー
UC-HA-001	新エージェント定義（採用）	新しいW層が必要な場合、CLAUDE.md・knowledge/を定義して生成。H&Aが能力要件を策定	H&A / PMO依頼	PJ開始時 / 能動ループ
UC-HA-002	エージェント能力改善（育成）	W層のCLAUDE.mdを分析し、パフォーマンス改善のための更新を実施	H&A（自律）	能動ループ
UC-HA-003	パフォーマンス評価	W層の成果物品質・処理速度・エラー率を測定。日次経営会議で報告	H&A（自律）	日次経営会議
UC-HA-004	PJリソース確認・割当	PJ開始時にPMOから依頼を受け、必要なW層リソースの空き状況を確認し割当	PMO → H&A	PJ起案時
UC-HA-005	振り返り・ナレッジ蓄積	PJ完了後に成果・課題を記録し、次回PJに活かせるナレッジとして蓄積	H&A	PJ完了時

PMO — Project Management Office（2線管理）

UC番号	ユースケース名	概要	アクター	トリガー
UC-PMO-001	PJ起案・PJM生成	IF層からPJ化指示を受け、PJ計画を策定しPJMを生成。工程定義・リソース計画を作成	IF → PMO	IF層のPJ化判断
UC-PMO-002	PJ重複チェック	新規PJ起案時に既存PJとの重複・競合を検出。重複時はマージまたは却下を判断	PMO（自律）	PJ起案時
UC-PMO-003	PJ進捗監視	全アクティブPJの進捗を監視。ブロッカー検出時はPJM/VDUに通知、必要ならCEOにエスカレーション	PMO（自律）	能動ループ
UC-PMO-004	共通資産管理	複数PJで使用される共通コンポーネント・ライブラリの管理。重複実装の防止	PMO（自律）	能動ループ / PJ完了時
UC-PMO-005	軽微変更の直接実行	PJM生成が不要な軽微コード変更。PMOが直接W層を起動して処理	PMO	M層 / IF層からの依頼

OA — Operational Audit（3線監査）

UC番号	ユースケース名	概要	アクター	トリガー
UC-OA-001	PJ工程完了時の品質監査	PJMから成果物を受領し、品質基準に照らして監査。VDUのレビューとは独立した第三者視点。NG→差し戻し	PJM → OA	PJ工程完了（イベント）
UC-OA-002	VDU完了後の独立監査	VDUが直接委譲型で完了したタスクを、OAが独立に監査。三線防御の実現	VDU完了 → OA	VDUタスク完了（イベント）
UC-OA-003	品質基準の策定・更新	監査で発見したパターンを品質基準に反映。reviewer/testerのCLAUDE.mdチェックリスト更新を提案	OA（自律）	監査結果の蓄積
UC-OA-004	横展開（水平展開）	あるPJで発見された問題・改善点を他PJ・他Divisionに展開。再発防止策の全社適用	OA（自律）	監査NG発見時

SA — System Audit（3線監査）

UC番号	ユースケース名	概要	アクター	トリガー
UC-SA-001	プロセス死活監視	全M層・bot.pyプロセスの死活を常時監視。異常検知時に自動復旧を試行、失敗時はCEOに報告	SA（自律）	能動ループ（常時）
UC-SA-002	リソース消費監視	トークン消費量・CPU/メモリ使用率を監視。閾値超過時にIF層経由でCEOに報告	SA（自律）	能動ループ（常時）
UC-SA-003	エラー検知・自動復旧	W層のエラー・タイムアウトを検知。rate limit時はexponential backoff、通常エラーは再起動試行	SA（自律）	エラーイベント
UC-SA-004	セキュリティ監視	機密ファイルの漏洩チェック、不正なgit操作の検知。.env/.tokens*.jsonの変更監視	SA（自律）	能動ループ / gitフック
UC-SA-005	トークン管理会計	Division別・PJ別のトークン消費実績を計測・記録。配分制御・最適化。日次経営会議で配分計画を報告。リソース停止提案（最終判断はCEO）	SA（自律）	能動ループ（常時）/ 日次経営会議

Div横断

UC番号	ユースケース名	概要	関与Div	トリガー
UC-CROSS-001	日次経営会議	IF層が全M層を招集。定常アジェンダ（振り返り・進捗・リソース）+ 持ち込みアジェンダを処理	全Division	時間トリガー（毎日定時）
UC-CROSS-002	VDU完了→OA品質監査連携	VDUの開発完了をトリガーにOAが独立監査を開始。三線防御の連携	VDU → OA	VDU完了イベント
UC-CROSS-003	SA異常検知→VDU修正連携	SAが検知した異常をVDUに通知し、VDUがW層に修正を委譲	SA → VDU	SA異常検知イベント
UC-CROSS-004	リソース逼迫エスカレーション	SAがリソース逼迫を検知→IF層経由でCEOに報告→CEOが優先度判断→PMOがPJ調整	SA → IF → CEO → PMO	SA閾値超過
UC-CROSS-005	PJ型タスク（全体フロー）	大規模タスクのPJ化。PMO→PJM生成→W層実行→VDU受入→OA監査→完了の全体ライフサイクル	PMO, VDU, OA, H&A, SA, BA	IF層のPJ化判断

UC統計: 合計 33 UC（IF: 3, VDU: 6, BA: 6, H&A: 5, PMO: 5, OA: 4, SA: 4, CROSS: 5）
駆動モデル内訳: CEO指示: 6, 時間トリガー: 4, イベント駆動: 8, 能動ループ: 10, 日次経営会議: 2, 複合: 3

PJ工程定義（12工程正常系＋異常系）

工程構造: M層フェーズ（工程1〜5）→ PMO/PJM/W層フェーズ（工程6〜11）→ 完了フェーズ（工程12）
M層は入口（要求・要件Rv）と出口（最終受入）のみ関与。PJMは工程12（解散）まで存続。

M層フェーズ（工程1〜5）— VDUが主管

発見

課題・機会の発見。CEO指示 / VDU能動ループ / SA異常検知 / 日次経営会議の議題

異常系: 既存PJと重複 → PMOが重複チェック → マージ or 却下

調査

VDUがW層（researcher）に技術調査を委譲。現状分析・実現可能性評価

異常系: 技術的に実現不可能 → VDUがCEOに報告 → 代替案検討 or 中止

要求整理

VDUが調査結果を基に要求を整理。MECE分解・優先順位付け

異常系: 要求が曖昧・矛盾 → CEOに確認（CONSULT）→ 要求を明確化

CEO承認ゲート: 要求範囲の合意

要件定義

VDUがW層（architect）に要件定義を委譲。機能要件・非機能要件・制約条件を定義

異常系: 要件間の矛盾発見 → VDUに差し戻し → 要求整理からやり直し

CEO承認ゲート: 要件の最終承認（コスト・スコープの合意）

委託

VDUがPMOにPJ化を依頼。PMOがPJMを生成し、工程計画を策定。H&AがW層リソースを確認・割当

異常系: リソース不足 → H&AがCEOに報告 → 優先度調整 or 新エージェント生成

PMO/PJM/W層フェーズ（工程6〜11）— PJMが主管

設計

PJMがW層（architect）に設計を委譲。アーキテクチャ設計・IF定義・ファイル構成を策定

異常系: 設計方針の対立 → VDUに技術判断を依頼 → VDUが裁定

異常系: OA監査NG → PJMに差し戻し → architectが修正

実装

PJMがW層（coder）に実装を委譲。設計書に従いコードを実装

異常系: 実装困難（設計との乖離）→ PJMがarchitectに設計修正を依頼 → 工程6に戻る

異常系: 構文エラー → coderが自己修正ループ（最大3回）→ 解消しなければPJMに報告

テスト

PJMがW層（tester）にテスト作成・実行を委譲。正常系・異常系・境界値・認可テスト

異常系: テスト失敗 → PJMがcoderに修正を依頼 → 工程7に戻る

異常系: テストカバレッジ不足 → testerが追加テスト作成

受入（VDU Rv）

PJMがVDUに成果物を提出。VDUが事業価値・品質の観点でレビュー。承認/差し戻し

異常系: VDU差し戻し → PJMに具体的修正指示 → 該当工程（6/7/8）に戻る

CEO承認ゲート: 重要マイルストーンの場合、VDUがIF層経由でCEO承認を取得

リリース

PJMがW層（coder）にデプロイを委譲。コミット・プッシュ・デプロイ実行

異常系: デプロイ失敗 → SA検知 → PJMに通知 → ロールバック判断

CEO承認ゲート: main直接push / 破壊的変更の場合

記録

PJMがW層（docs）にPJ記録を委譲。H&Aが振り返り・ナレッジ蓄積を実施

異常系: 記録不備 → OAが横展開チェック時に発見 → 追記依頼

完了フェーズ（工程12）

解散

PMOがPJ完了を確認。PJMを消滅させる。IF層がCEOに最終報告

異常系: 完了後に問題発見 → 新PJとして再起案（PJM再生成）

異常系パターン一覧

パターン	検知者	対応フロー	戻り先工程
PJ重複	PMO	PMOが既存PJとマージ、または新規PJを却下	工程1（発見）
技術的実現不可	researcher / VDU	VDUがCEOに報告 → 代替案検討 or 中止	工程2（調査）
要求不明確	VDU	CEOにCONSULT → 要求明確化	工程3（要求整理）
リソース不足	H&A	CEOに報告 → 優先度調整 or 新エージェント生成	工程5（委託）
設計方針対立	PJM	VDUに技術裁定を依頼	工程6（設計）
OA監査NG	OA	PJMに差し戻し → W層が修正 → OA再監査	該当工程
VDU受入NG	VDU	PJMに具体的修正指示 → 該当工程に差し戻し	工程6/7/8
テスト失敗	tester	PJMがcoderに修正委譲	工程7（実装）
デプロイ失敗	SA	PJMに通知 → ロールバック判断	工程10（リリース）
rate limit	SA	exponential backoff → グローバルクールダウン → 自動リトライ（最大3回）	中断箇所から再開
完了後の問題発見	OA / SA / CEO	新PJとして再起案	工程1（発見）

CEO承認ゲート一覧

工程	ゲート名	条件（いつ必要か）	判断内容
3	要求範囲合意	常時（全PJ）	スコープ・優先度の確認
4	要件最終承認	コスト大 / スコープ変更時	コスト・スコープのトレードオフ判断
9	重要マイルストーン承認	外部影響あり / 不可逆な変更	事業影響の最終確認
10	リリース承認	main直接push / 破壊的変更 / 外部サービス影響	リリース実行のGo/No-Go

業務フロー（13列スイムレーン）

13列定義: CEO / IF層 / VDU / BA / PMO / W-Researcher / W-Architect / W-Coder / W-Reviewer / W-Tester / W-Docs / SA / External
注: H&AとOAはM層だが、主要フローでの登場頻度が低いため備考欄で補足する。PJMはPMO列内で表現する。

実装方針: 13列はCSS Gridベースの <table> で実装。横スクロール対応。 SVGオーバーレイは列数が多く保守困難なため不採用。代わりにセル内ノード + 行間の矢印記号（→ ← ↓）で方向を表現する。

UC-VDU-001: CEO指示による開発タスク（直接委譲型）

CEO	IF層	VDU	W-Researcher	W-Architect	W-Coder	W-Reviewer	W-Tester
指示送信	→ 受信
	判断: VDU委譲	← 受領
		フェーズ分解	← 調査委譲
		調査結果Rv	報告 →
		設計委譲 →		← 設計開始
		設計Rv		設計書 →
		実装委譲 →			← 実装開始
					コード完了	← Rv委譲
						Rv結果 →	← テスト委譲
		最終Rv					結果 →
	← 結果受領	報告 →
← 確認	CEO報告

備考: OAはVDU完了後にイベントトリガーで独立監査を開始（UC-CROSS-002）。SAは全工程中プロセス監視を継続。

UC-CROSS-005: PJ型タスク（全体フロー）

CEO	IF層	VDU	BA	PMO/PJM	W-Researcher	W-Architect	W-Coder	W-Reviewer	W-Tester	W-Docs	SA
PJ指示	→ PJ判断
		← 調査指示			← 調査委譲
承認G	承認依頼	要求整理			報告 →
		要件委譲 →				← 要件定義
		PMOに委託→		← PJM生成
				PJM: 設計→		← 設計実行
				PJM: 実装→			← 実装実行				監視中
				PJM: テスト→				← Rv	← テスト
		VDU受入Rv		成果物提出→
				OAに提出							OA監査
承認G	承認依頼			PJM: リリース			← デプロイ
			消費記録	PMO:完了確認 PJM消滅						← 記録
← 最終確認	CEO報告

備考: H&AはPJ開始時にリソース確認（PMO/PJM列の裏で動作）、PJ完了時に振り返り記録。OAはSA列を借用して表示（3線監査としての独立性を視覚的に表現）。

UC-BA-001: 月末経費締め処理（時間トリガー型）

CEO	IF層	BA	External
		月末トリガー起動
		経費データ取得→	MFクラウド API
		仕訳分類・登録	← MFクラウド
承認G	← 承認依頼	IF経由で承認依頼→
承認 →	承認伝達 →	← 確定処理

UC-SA-003: エラー検知・自動復旧

CEO	IF層	VDU	W-Coder	SA
				異常検知
				自動復旧試行
		← 修正依頼		復旧失敗→ VDUに通知
		W層に修正委譲	← 修正実行
← 報告確認	← CEO報告	結果報告→

追加すべき業務フロー一覧

以下のUCは上記と同じ13列フォーマットで追加する。優先度順に記載。

UC番号	ユースケース名	優先度	理由
UC-CROSS-001	日次経営会議	高	全Div参加の中核プロセス。列の大半がアクティブになる代表的フロー
UC-VDU-002	能動ループ: コードベース改善	中	CEO指示なしの自律起動パターン。従来にないフロー
UC-BA-004	CEO指示による経理・法務タスク	中	BAの代表的フロー。tax/legal-reviewerの活用パターン
UC-HA-001	新エージェント定義（採用）	低	H&A特有のフロー。Div間連携の一例
UC-CROSS-004	リソース逼迫エスカレーション	低	SA→IF→CEO→PMOの多段連携パターン

機能要件

W層ツール・成果物・権限

機能要件（ツール群・成果物配置・コミット/プッシュルール）

W層ツール定義

Worker	使用ツール・スキル	出力形式	自己修正
researcher	WebSearch / WebFetch / Grep / Read / Bash（読取系）。APIドキュメント・ライブラリ比較・コードベース分析	調査レポート（テキスト）	なし
architect	Read / Grep / Glob。アーキテクチャ設計・IF定義・Mermaid図。セキュリティ/パフォーマンス・バイ・デザイン必須	HTML設計書 `output/DESIGN_*.html`	なし
coder	Read / Edit / Write / Bash（実行系）。Python / TypeScript / HTML/CSS。ruff / py_compile / pytest	実装コード + テスト	最大3回ループ
reviewer	Read / Grep / Glob（読取系のみ）。25項目チェックリスト（セキュリティ・金額・エラー・UI・パフォーマンス）	レビューレポート MUST/SHOULD/NIT	最大2周
tester	Read / Write / Bash。pytest / カバレッジ測定。正常系・異常系・境界値・認可・E2Eテスト	テストコード + 実行結果	最大3回ループ
docs	Read / Write / Grep。Markdown / HTML / Mermaid図	ドキュメント Markdown or HTML	最大3回ループ
legal-reviewer	Read（knowledge/のみ）。法務リサーチ・リスク分析。knowledge外の情報で断言禁止	リスク分析レポート高/中/低分類	最大3回ループ
tax	Read（knowledge/のみ）。税務計算・税法調査。条文番号紐づけ必須	税務調査レポート	最大3回ループ

成果物配置ルール

成果物種別	配置先	命名規則	デプロイ先
設計書（HTML）	`agents/workers/architect/output/`	`DESIGN_{テーマ}.html`	Cloudflare Pages `issue-{N}/`
実装コード	対象パッケージ内（既存構造に従う）	既存命名規則に従う	Git push
テストコード	`tests/`（対象パッケージのテストディレクトリ）	`test_{対象モジュール}.py`	Git push
ドキュメント	`agents/workers/docs/output/` or パッケージ内	内容に応じて	Cloudflare Pages（HTML時）
調査レポート	Slackスレッド内（テキスト）	—	—（揮発性）
レビューレポート	Slackスレッド内（テキスト）	—	—（揮発性）
法務・税務レポート	SharePoint（CEOへの報告時）	案件に応じて	SharePoint URL共有
CEO向けビジネス文書	SharePoint シェアドドキュメント	案件に応じて	SharePoint URL共有

コミット・プッシュ権限マトリクス

アクター	ファイル作成/編集	git commit	git push	force push	main直接push	備考
architect	○ 設計書のみ	△ M層指示時	×	×	×	設計書HTMLファイルのコミットのみ可
coder	○	△ M層指示時	×	×	×	実装コード・テスト。ruff/py_compile通過後
tester	○ テストのみ	△ M層指示時	×	×	×	テストコードのコミットのみ可。プロダクションコード変更禁止
docs	○ ドキュメントのみ	△ M層指示時	×	×	×	ドキュメントファイルのコミットのみ可
researcher	× 読取のみ	×	×	×	×	ファイル変更一切不可
reviewer	× 読取のみ	×	×	×	×	コード修正禁止（指摘のみ）
legal-reviewer	× 読取のみ	×	×	×	×	knowledge/のみ参照可
tax	× 読取のみ	×	×	×	×	knowledge/のみ参照可
M層（VDU等）	× 判断のみ	×（W層に指示）	○ 判断・指示	× CEO承認必須	× CEO承認必須	M層は手を動かさない。push判断のみ
CEO	○（任意）	○	○	○（最終承認者）	○（最終承認者）	全権限。force push/main pushの最終承認者

コミット・プッシュフロー

通常フロー

W層がファイル作成/編集
W層が ruff / py_compile でチェック
W層が pytest でテスト実行
M層がコミットを指示
W層が git add + git commit
M層が差分を確認し git push を判断
M層が git pull --rebase → git push を指示

禁止事項

W層が単独で git push を実行
M層が直接コードを書く（W層に委譲）
--force push（CEO承認なし）
main ブランチへの直接 push（CEO承認なし）
.env / .tokens*.json のコミット
--no-verify でフックスキップ

テスト通過時の自動フロー

テストが全て通過した場合、M層は確認なしでコミット・プッシュまで一気に実行してよい（CEO指示による運用ルール）。

条件:
・ruff / py_compile エラーなし
・pytest 全テストPASS
・機密ファイルが含まれていないこと

HTMLデプロイルール

項目	内容
デプロイ先	Cloudflare Pages — `mnml-docs.pages.dev`
デプロイ方法	`<<ACTION>>{"type":"cf_deploy","path":"相対パス","issue":番号}<</ACTION>>`
URL設計	`https://mnml-docs.pages.dev/issue-{番号}/{ファイル名}.html`
上書きルール	同一Issue・同名ファイルは上書き。版を残す場合はファイル名を変更（例: `_v2.html`）
対象	architect設計書、docs出力（HTML時）、coder生成HTML

M層の機能・権限

Division	主要機能	W層起動権限	特記事項
VDU	事業・プロダクト判断。フェーズ分解・W層委譲・成果物レビュー・最終受入	全W層（調査・分析は直接、コード変更はPMO経由）	能動ループ可
BA	経理・法務・調達判断。opsパイプライン管理	tax, legal-reviewer, researcher + opsパイプライン	時間トリガー駆動
H&A	エージェント生成・育成・評価。CLAUDE.md管理。リソース割当	architect, coder, researcher, docs	能動ループ可
PMO	PJ推進管理。PJM生成・統括。重複チェック。共通資産管理。ナレッジ記録	全W層（PJM経由 or PMO直接）	コード変更は全てPMO経由
OA	品質監査。品質基準策定。横展開。VDU/PJMとは独立した第三者視点	reviewer, docs, researcher	イベント駆動
SA	システムリソース管理（トークン管理会計・配分制御・最適化）。死活監視。セキュリティ。プロセス管理（起動/停止）。リソース停止提案	researcher, coder（PMO経由）, reviewer + opsパイプライン	能動ループ（常時）

通信・駆動モデル

組織構成図・各Division役割の詳細は Issue #139 組織アーキテクチャ定義 を参照。本セクションでは通信構造・駆動モデル・アーキテクチャ比較のみ記載する。

通信方式

CEO ↔ IF : Slack（bot.py中継）

IF ↔ M層 : tmux send-keys / capture-pane / ファイル

M層 → W層 : claude CLI subprocess（都度起動・完了で消滅）

駆動モデル

ディビジョン	駆動	プロセス	理由
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消費ゼロ

ユースケースフロー

Direct Route — IF層が直接回答

雑談・質問・スケジュール確認など、IF層が単独で判断・回答しM層に委譲しないケース

CEO

Slack + bot.py

IF層

メッセージ送信

Slack受信 → bot.py
→ tmux send-keys

判断:「自分で回答可能」

回答を生成・出力

tmux capture-pane
→ Slack投稿

回答を確認

凡例

指示（下流へ）

結果返却（上流へ）

※ M層・W層は関与しない。IF層のみで完結する最短ルート

VDU Route — 事業・プロダクト開発

コード実装・設計・デプロイなど。VDU（1線）がフェーズ分解しW層に委譲、レビュー後にIF層へ返却

CEO

Slack + bot.py

IF層

M層（VDU）

W層

タスクを送信

Slack受信 → bot.py
→ tmux send-keys

判断:「開発タスク」
→ VDUへ委譲

VDU: 受領
フェーズ分解

W層実行
coder / architect / researcher等

VDU: 成果物受領

成果物返却

レビュー

NG → 修正指示で
W層に差し戻し

↓ OK

結果受領・整形

VDU: 結果報告

tmux capture-pane
→ Slack投稿

結果を確認

凡例

指示・委譲（下流へ）

結果返却（上流へ）

NG差し戻しループ

判断ノード（OK/NG分岐）

※ レビューNGの場合、修正指示とともにW層に差し戻し。OKになるまでループ

BA Route — 経理・法務・調達

経費登録・請求書・契約レビュー・法的リスク評価など。BA（2線）がops/パイプライン実行またはW層に委譲し、レビュー後に返却

CEO

Slack + bot.py

IF層

M層（BA）

W層 / ops

経理・法務指示を送信

Slack受信 → bot.py
→ tmux send-keys

判断:「経理・法務」
→ BAへ委譲

BA: 受領・タスク判断
経理/法務/調達を分類

ops/パイプライン実行
or W層起動（tax等）

BA: 結果受領

結果返却

レビュー

NG → 修正指示で
差し戻し

↓ OK

結果受領・整形

BA: 結果報告

tmux capture-pane
→ Slack投稿

結果を確認

凡例

指示・委譲（下流へ）

結果返却（上流へ）

NG差し戻しループ

判断ノード（OK/NG分岐）

※ BAは経理・法務・調達を統合管理。経理→ops/パイプライン、法務→legal-reviewer、調達→docs等のW層を使い分ける

VDU能動ループ — CEOの指示なしで自律稼働

VDUが常駐セッション内で自律的にコードベース・Issueを観察し、課題を発見→W層に委譲→結果をIF層経由でCEOに報告

CEO

Slack + bot.py

IF層

M層（VDU）

W層

（不在 / 就寝中）

自律コードベース観察
Issue一覧を確認

課題発見
「技術的負債あり」

優先度
判断

低優先 → 記録のみ
（Issue起票して待機）

↓ 高優先: W層に委譲

W層実行
researcher / coder / architect

VDU: 成果物レビュー

成果物返却

結果受領
CEO向け報告整形

IF層へ報告
tmux send-keys

tmux capture-pane
→ Slack投稿

（起床後）
報告を確認・承認

次の観察サイクルへ
ループ継続

ポイント

自律 CEOの指示なしでVDUが自発的に開始

※ VDUは常駐セッション内で「観察→判断→実行→報告」を自律ループ。CEOは結果を非同期で確認。
※ APPROVAL_NEEDEDな操作（外部送信・破壊的変更）はCEO承認待ちで一時停止

BA時間トリガー — 定時業務の自動実行

月末・月初などの時間トリガーでBAが自動起動し、経費チェック・請求書確認・月次レポートを実行

CEO

Slack + bot.py

IF層

M層（BA）

ops / W層

（不在）

cron月末トリガー発火
「経費チェックの時間」

実行計画策定
1. 経費確認 2. 請求書 3. 報告書

ops/パイプライン or W層
経理→ops / 法務→legal-reviewer / 調達→docs

BA: 結果確認

実行結果返却

承認
要否

自動完結可能 → 次タスクへ
CEO承認要 → 承認待ち

結果受領
日次サマリーに集約

IF層へ報告

tmux capture-pane
→ Slack投稿

（出社後）
サマリー確認
承認キュー処理

ポイント

cron 時間トリガー（月末・月初・毎朝等）

※ BAは締日・期限に基づいて自動起動。経費登録など外部書き込みはCEO承認待ち（APPROVAL_NEEDED）
※ 確認のみの読み取り操作は自動完結し、結果のみ報告

SA異常検知 — エラー検知から自動対応

SAが常時監視ループでエラー・異常を検知し、影響範囲を判断。自動復旧またはVDUに修正を依頼

CEO

Slack + bot.py

IF層

M層（SA）

M層（VDU）

（不在）

自律死活監視ループ
プロセス・ログ監視

異常検知
CLIプロセス異常終了

重要度
判断

軽微 → 自動復旧
重大 → VDUに連携

重大: VDUに修正依頼
tmux send-keys → m-vdu

VDU: 受領
W層に修正委譲

インシデント報告受領
CEO向けアラート整形

IF層へインシデント報告

tmux capture-pane
→ Slack投稿
緊急通知

アラート確認
対応状況を把握

ポイント

自律 SAが常時監視ループで異常を検知

※ SA→VDUのディビジョン間連携が発生するケース。SAは検知・判断・通知に責任、修正実行はVDUの責務
※ 軽微な異常（プロセス再起動等）はSAが自動復旧。CEOには事後報告のみ

ディビジョン間連携 — VDU完了→OA品質監査

VDUが実装完了後、OA（業務監査）が品質チェックを実施。三線防御の分離原則に基づく独立監査

CEO

Slack + bot.py

IF層

M層（VDU）

M層（OA）

VDU: 実装完了
W層（coder）の成果物OK

OAへ監査依頼
tmux send-keys → m-oa

event監査依頼受領

品質監査実行
W層（reviewer/tester）起動

監査
結果

VDU: 指摘受領
修正してOAに再提出

NG: VDUに指摘事項
修正依頼

監査完了報告受領
CEO向け整形

OK: IF層へ監査完了報告

tmux capture-pane
→ Slack投稿

監査結果を確認
実装+品質の両方がOK

ポイント

event VDUの完了がOAのトリガーになる（ディビジョン間連携）

※ OAはVDUから独立した視点で監査する（三線防御の原則）。VDU自身のレビューとは別のチェック
※ NG時はVDUに差し戻し→修正後にOAが再監査。OKになるまでCEOには上がらない
※ 同様のパターン: PMOがPJ計画策定→VDUに実行指示、H&Aが新W層追加→SAにレジストリ更新通知

PJ型タスク — PMOがPJMを生成して管理

規模の大きいタスクはPJ化する。PMOがPJMを生成し、PJMがW層を管理。各ディビジョンがPJライフサイクルに関与する

2つのパターン

	直接委譲型	PJ型
規模	小〜中（1ディビジョンで完結）	中〜大（複数ディビジョン・複数フェーズ）
管理者	M層（VDU/BA等）が直接W層を起動	PMOがPJMを生成。PJMがW層を管理
PJ化の判断	—	IF層またはM層が判断。複数Div横断・長期・CEO承認要の場合
ライフサイクル	タスク完了で終了	PJ開始→工程管理→完了→PJM消滅

PJライフサイクルと各ディビジョンの関与

IF層

PMO

PJM（有期）

VDU / BA

OA / SA

H&A

PJ化を判断
PMOに起案指示

PJ計画策定
PJMを生成

リソース確認
W層の空き状況

進捗監視

W層を起動
工程管理
フェーズ分解・委譲

VDU: 技術判断
BA: 予算・契約

SA: 監視継続
異常時にPJMに通知

成果物をOAに提出

OA: 品質監査
NG→PJMに差し戻し
OK→次へ

CEO向け報告整形
承認依頼

PMO: 完了確認
PJM消滅

振り返り記録
ナレッジ蓄積

各ディビジョンのPJへの関与

Div	PJにおける役割	関与タイミング
VDU	技術判断・プロダクト方針。PJMが判断できない事項を支援	実行中（技術判断時）
BA	予算・契約・法務チェック	起案時（予算）、実行中（外部契約）
H&A	W層リソース確認・割当。完了後の振り返り・ナレッジ蓄積	起案時＋完了時
PMO	PJ全体管理。PJM生成/消滅・進捗監視	全期間
OA	成果物の品質監査。独立視点でチェック。NG→差し戻し	各フェーズ完了時
SA	システム監視継続。異常検知時にPJM/PMOに通知	実行中（常時）

PJのループ構造

外側ループ（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間の依存関係を管理

データモデル

永続化はすべてJSONファイルベース（logs/ ディレクトリ配下）。RDBは使用しない。アトミック書き込み（temp file → rename）でデータ破損を防止。

Task

システムの中核エンティティ。CEOからのメッセージ1件が1 Taskとなり、状態遷移しながら処理される。

フィールド	型	説明
id	str	8文字の一意識別子
thread_ts	str	Slackスレッドタイムスタンプ（セッションのグループ化キー）
status	str	received → classifying → routing → executing → completed / error
route	str	ルーティング先（m-dev, m-bo, direct 等）
prompt	str	ユーザーメッセージ（最大200文字）
retry_count	int	自動リトライ回数（上限3、再起動をまたいで永続）
result	str	AI応答テキスト（先頭500文字）
created_at / updated_at	float	Unixタイムスタンプ

永続化先: logs/tasks.json — TaskTrackerがインメモリ辞書 + JSONで管理。スレッドセーフ

ProcessInfo（プロセスレジストリ）

実行中のClaude CLIプロセスを追跡するレジストリ。ダッシュボードの組織図・ワーカー状態表示に使用。

フィールド	型	説明
pid	int	OSプロセスID
task_id	str	紐づくTask.id
route	str	ルート名
layer	str	manager / worker / if（cwdから自動判定）
thread_ts	str	Slackスレッドタイムスタンプ
cpu_percent / memory_mb	float	リソース使用量（psutilでサンプリング）

永続化先: logs/agents.json — ProcessRegistryグローバルシングルトン。スナップショット保存

Session（セッションマッピング）

SlackスレッドとClaude CLIセッションIDの対応。--resume による文脈継続に使用。

フィールド	型	説明
key	str	`thread_ts`（IF層）または `thread_ts:manager`（M層）
sid	str	Claude CLIセッションID（UUID）
ts	float	作成タイムスタンプ（TTL: 24時間、最大1000エントリ）

永続化先: logs/sessions.json — claude_runner.pyが管理

WorkerStatus（W層実行状態）

W層の起動・完了を追跡。ダッシュボードのリアルタイム表示に使用。

フィールド	型	説明
id	str	UUID
manager	str	委譲元マネージャー（m-dev等）
worker	str	ワーカー種別（coder, architect等）
started_at / completed_at	float	開始/完了タイムスタンプ。自動クリーンアップ: 24h超stale削除、1h超completed削除

永続化先: logs/worker_status.json — 配列形式

PendingApproval（承認キュー）

CEO承認が必要な操作（コスト発生・外部送信・破壊的操作）の待ちキュー。

フィールド	型	説明
id	str	8文字の一意識別子
route / task_id	str	ルーティング先・紐づくTask
impact_reason	str	承認が必要な理由
thread_context	str	スレッド会話履歴（判断材料）

永続化先: logs/approvals.json — ApprovalManagerが管理

エンティティ関連

関連	多重度	結合キー・備考
Task → ProcessInfo	1:N	`task_id` で結合。1タスクにM層+複数W層プロセスが紐づく
Task → Session	N:1	`thread_ts` で結合。同一スレッド内の複数タスクが1セッションを共有
Task → PendingApproval	1:0..1	`task_id` で結合。承認待ち状態のタスクのみ
ProcessInfo → WorkerStatus	1:1	W層プロセスのみ。`manager` + `worker` で論理結合
Task → PendingEmail	1:0..N	`thread_ts` で結合。メール送信承認待ち

永続化ファイル一覧

ファイル	エンティティ	ライフサイクル	書き込み保護
tasks.json	Task	無期限（全履歴保持）	threading.Lock + atomic write
agents.json	ProcessInfo	現在のスナップショット	atomic write
sessions.json	Session	TTL 24h / 最大1000件	atomic write
worker_status.json	WorkerStatus	自動クリーンアップ	atomic write
approvals.json	PendingApproval	承認/却下まで保持	atomic write
pending_emails.json	PendingEmail	送信/却下まで保持	atomic write
rate_limit_status.json	RateLimitStatus	履歴100件 / TTL 24h	atomic write

項目	要件
稼働形態	Mac mini 24時間常時稼働。bot.pyはlaunchdサービスとして自動起動
接続方式	Slack Socket Mode（WebSocket常時接続）。Webhook不要、ファイアウォール開放不要
プロセス監視	SA（3線）が死活監視。プロセス異常時はSlack通知 + 自動復旧試行
障害復旧	bot.py再起動でタスク状態はtasks.jsonから復元。実行中タスクはstale検出→通知
単一障害点	Mac mini自体が単一障害点。冗長化は現時点で不要（一人法人規模）

項目	要件
応答時間	IF層の初回応答: 数秒〜十数秒（Claude CLI起動 + LLM推論）。リアルタイム性は求めない
同時実行	Claude Max Planのレート制限に依存。並行5セッション程度が実用上限
トークン制約	Max Planの月間トークン上限内で運用。レート制限時はexponential backoff（30s→60s→120s）
永続化性能	JSONファイルI/O。タスク数は月100件程度の想定で性能問題なし

項目	要件
認証	Slack User ID + ロール（admin/developer/member）で制御。admin = CEO のみ
認可	破壊的操作・コスト発生・外部送信はCEO承認必須（APPROVAL_NEEDEDゲート）
機密管理	`.env`に集約。トークンファイル（`.tokens*.json`）はgitignore対象。コミット禁止
三線防御	1線（VDU: 実行・レビュー）→ 2線（BA: 経理統制）→ 3線（OA/SA: 独立監査・監視）
force push禁止	Git操作はW層→M層→pushの承認フロー。force pushはCEO承認必須

項目	要件
起動・停止	`scripts/start.sh` / `scripts/stop.sh` で一括制御。launchdサービス登録済み
ログ	`logs/` ディレクトリに集約。Pythonのloggingモジュール使用
ダッシュボード	Webダッシュボード（組織図・セッション一覧・W層状態）をSSE配信でリアルタイム表示
設定管理	pydantic-settingsで`.env`から読み込み。環境変数でオーバーライド可
デプロイ	Git pull + プロセス再起動。CI/CDなし（Mac miniローカル実行）

項目	要件
W層追加	新ワーカーは`agents/workers/{name}/`にCLAUDE.md + knowledge/を配置するだけで追加可能
M層追加	新ディビジョンは`agents/managers/{name}/`配置 + IF層のルーティング定義追加
opsパイプライン追加	`ops/{name}/`にパッケージを追加。pyproject.tomlのパッケージ検索パスに含まれる
外部サービス連携	ACTIONタグ拡張で新しいサービス連携を追加可能（cf_deploy, file_upload, send_email等）
DB移行	現在はJSONファイル。将来的にSQLiteやPostgresへの移行パスを確保（TaskTrackerの抽象化）

種別	対象	方針
ユニット	個別モジュール（parser, tracker, registry等）	純粋関数・データ変換ロジックを重点テスト。外部依存はモック可
統合	コンポーネント間連携（bot→IF→M→W）	JSONファイルI/O、プロセス起動・停止、tmux通信を実環境で検証
E2E	Slackメッセージ送信→AI応答→Slack返信	テスト用Slackチャンネルで実メッセージフロー検証

レイヤー	テスト対象	テスト方法
bot.py	Slackイベントハンドリング、タグパーサー、タスク状態遷移、承認フロー	ユニット: パーサー関数。統合: Boltテストアダプタでイベント発火
IF層	ルーティング判断、直接回答の品質	定型メッセージセットで期待ルート・応答パターンを検証
M層	STATUSタグ出力、DELEGATEタグ出力、W層結果の統合	統合: 実際のClaude CLI起動で入出力検証
W層	成果物品質（コード・設計書・テスト）	M層のレビュー + OA監査で品質保証。自動テストはruff/py_compile

ゲート	基準	タイミング
ruff	フォーマット・リントエラーゼロ	コミット前
py_compile	全.pyファイルの構文チェック通過	コミット前
型ヒント	`from __future__ import annotations`必須。型ヒント漏れなし	レビュー時
セキュリティ	OWASP Top 10チェック。機密ファイル混入なし	レビュー時
M層レビュー	W層成果物はM層が必ずレビュー。無条件信頼禁止	W層完了後
OA監査	PJ型タスクは工程完了ごとにOAが独立監査	工程完了後

要件定義書 — MNML自律組織アーキテクチャ

前提

REQ-1: 組織構造参照

REQ-2: 通信構造

REQ-3: 駆動モデル・トリガー設計

REQ-4: M層プロセスモデル（未確定）

REQ-5: リソース管理（トークン管理会計）

REQ-6: CEO関与ポイント

REQ-7: 初回経営会議（移行の起点）

REQ-8: タスク実行パターン（M層直接 vs PJ型）

REQ-9: PJ型フロー

REQ-10: 各ディビジョンのPJ関与

要件ステータス

REQ-11: 成果物管理ルール

REQ-12: 情報管理ルール

REQ-13: 設計原則

業務要件（Division別・UCナンバリング付き）

IF層（直接回答）

VDU — Value Delivery Unit（1線 事業）

BA — Business Admin（2線 管理）

H&A — Human & AI Resources（2線 管理）

PMO — Project Management Office（2線 管理）

OA — Operational Audit（3線 監査）

SA — System Audit（3線 監査）

Div横断

PJ工程定義（12工程 正常系＋異常系）

M層フェーズ（工程1〜5）— VDUが主管

PMO/PJM/W層フェーズ（工程6〜11）— PJMが主管

完了フェーズ（工程12）

異常系パターン一覧

CEO承認ゲート一覧

業務フロー（13列スイムレーン）

UC-VDU-001: CEO指示による開発タスク（直接委譲型）

UC-CROSS-005: PJ型タスク（全体フロー）

UC-BA-001: 月末経費締め処理（時間トリガー型）

UC-SA-003: エラー検知・自動復旧

追加すべき業務フロー一覧

機能要件

W層ツール・成果物・権限

機能要件（ツール群・成果物配置・コミット/プッシュルール）

W層ツール定義

成果物配置ルール

コミット・プッシュ権限マトリクス

コミット・プッシュフロー

HTMLデプロイルール

M層の機能・権限

通信・駆動モデル

通信方式

駆動モデル

現行アーキテクチャ

提案アーキテクチャ

ユースケースフロー

Direct Route — IF層が直接回答

凡例

VDU Route — 事業・プロダクト開発

凡例

BA Route — 経理・法務・調達

凡例

VDU能動ループ — CEOの指示なしで自律稼働

ポイント

BA時間トリガー — 定時業務の自動実行

ポイント

SA異常検知 — エラー検知から自動対応

ポイント

ディビジョン間連携 — VDU完了→OA品質監査

ポイント

PJ型タスク — PMOがPJMを生成して管理

2つのパターン

PJライフサイクルと各ディビジョンの関与

各ディビジョンのPJへの関与

PJのループ構造

ポイント

データモデル

Task

ProcessInfo（プロセスレジストリ）

Session（セッションマッピング）

WorkerStatus（W層実行状態）

PendingApproval（承認キュー）

エンティティ関連

永続化ファイル一覧

VDU — Value Delivery Unit（1線事業）

BA — Business Admin（2線管理）

H&A — Human & AI Resources（2線管理）

PMO — Project Management Office（2線管理）

OA — Operational Audit（3線監査）

SA — System Audit（3線監査）

PJ工程定義（12工程正常系＋異常系）