Issue #139 Governance-as-Platform 2026-04-06

MNML 組織アーキテクチャ定義

AIエージェント組織のガバナンスをプラットフォーム機能として実現する

凡例: People External Services Platform基盤 VDU (Manager層) BA (Manager層) Worker層 Governance AI AIエージェント

全体アーキテクチャ図

CEO(内山)
CFO / パートナー(大野)
プロダクトユーザー
ブラウザ / デスクトップアプリ
Slack
GitHub
Outlook / Exchange
MFクラウド
OneDrive / SharePoint
Socket Mode
REST API
MS Graph API
HTTP / Playwright
MS Graph API
Gateway(常駐プロセス)
Gateway (bot.py)
Resource Governor
Audit Engine
Self-Monitor
Scheduler
subprocess (Claude CLI)
Interface層(都度起動 → 消滅)
Orchestrator AI
Policy Engine (CLAUDE.md + hooks)
subprocess (Claude CLI)
Manager層 — Domain Experts(常駐セッション)
VDU — Value Delivery Unit(事業)
VDU-shift AI
VDU-the-botch AI
VDU-web AI
VDU-events AI
VDU-spotify AI
BA — Business Admin(管理)
BA AI
経費
請求書
報告書
メール
予定
ニュース
subprocess (Claude CLI)
Worker層 — Skill Pool(都度起動 → 消滅)
researcher AI
architect AI
coder AI
reviewer AI
tester AI
docs AI
legal-reviewer AI
tax AI
PJM AI

組織体制 — 全メンバー一覧

CEO

項目内容
役割最終意思決定者。事業判断の委譲、基盤改善の判断、agentsリポジトリ変更の承認
固有の仕事基盤(Platform)をどう変えるかの判断。これは委譲できない
承認権限agentsリポジトリへの全変更。例外なし

基盤メンバー — Platform

メンバー役割種別外部接続方式常駐
Gateway外部世界(Slack・GitHub・メール・カレンダー)との通信ハブ。全ての入出力がここを通る。Resource Governorを内蔵プログラムSlack: Socket Mode / GitHub: REST API / MS系: MS Graph API / MFクラウド: HTTP+Playwright常駐
Orchestrator(Interface層) AICEOからのメッセージを解析し、適切なManager層にルーティングする執事SonnetGateway ← subprocess (Claude CLI)都度起動→消滅
Scheduler定期タスクの発火。経費処理、ニュース巡回、メールダイジェスト等をcron的に実行プログラムGateway内部呼び出し常駐
Policy Engine品質ルールの定義と自動適用。CLAUDE.mdへのルール記述、pre-commit hooks、品質ゲート(lint・test自動実行)で構成設定 + hooks + 品質ゲートファイルシステム参照イベント駆動
Audit Engine全エージェントの全行動を自動記録。ルール逸脱の自動検知。CEOダッシュボードで可視化プログラムGateway内部 / ダッシュボード: HTTP常駐
Resource Governorトークンクォータ管理。タスク優先度に基づく自動スケジューリング。Worker層同時実行数制御。競合リクエストの公平配分プログラム(Gateway内蔵)Gateway内部呼び出し常駐
Self-Monitor全プロセスの死活監視。障害検知→自動復旧→CEO通知プログラムGateway内部 / 通知: Slack API常駐

Manager層 — Domain Experts

Manager層の原則
判断のみ行う。実行機能を持たない。Worker層の利用はGateway経由。常駐セッション(死亡時は自動復帰)。自律的に担当領域を監視・改善する。

VDU — Value Delivery Unit(事業)

メンバーリポジトリプロダクトモデル接続方式常駐
VDU-shift AIshiftシフト管理(React + Express)OpusGateway ← subprocess (Claude CLI)CEO確認後に起動→常駐化
VDU-the-botch AIthe-botchイベント精算(Next.js)OpusGateway ← subprocess (Claude CLI)CEO確認後に起動→常駐化
VDU-web AIwebコーポレートサイト(HTML/PHP)OpusGateway ← subprocess (Claude CLI)CEO確認後に起動→常駐化
VDU-events AIeventsイベント告知(静的HTML)OpusGateway ← subprocess (Claude CLI)CEO確認後に起動→常駐化
VDU-spotify AIspotifySpotify整理(Python)OpusGateway ← subprocess (Claude CLI)CEO確認後に起動→常駐化

BA — Business Admin(管理)

メンバー責務ツール群モデル接続方式常駐
BA AI経理・法務・調達・HR・総務経費処理、請求書管理、月次報告書、メール振り分け、予定調整、ニュース巡回OpusGateway ← subprocess (Claude CLI)常駐

Worker層 — スキルプール

ロール注入モデル
固定エージェントではなく、ロール(CLAUDE.md + knowledge/)をコンテキストとして注入されたインスタンス。特定Manager層に所属しない共有プール。都度起動→完了→消滅。
メンバーロールモデルパターン接続方式常駐
researcher AI技術調査・既存コード分析SonnetGeneratorGateway ← subprocess (Claude CLI)都度起動→消滅
architect AI設計方針・インターフェース定義・ファイル構成OpusGeneratorGateway ← subprocess (Claude CLI)都度起動→消滅
coder AIコード実装OpusGeneratorGateway ← subprocess (Claude CLI)都度起動→消滅
reviewer AIコード/設計レビューOpusCriticGateway ← subprocess (Claude CLI)都度起動→消滅
tester AIテスト作成・実行SonnetCriticGateway ← subprocess (Claude CLI)都度起動→消滅
docs AIドキュメント作成SonnetGeneratorGateway ← subprocess (Claude CLI)都度起動→消滅
legal-reviewer AI契約書レビュー・法務調査OpusCriticGateway ← subprocess (Claude CLI)都度起動→消滅
tax AI税務調査・計算OpusGeneratorGateway ← subprocess (Claude CLI)都度起動→消滅
PJM AIPJ管理・Worker層レビュー(有期。PJ完了で消滅)OpusCoordinatorGateway ← subprocess (Claude CLI --resume)PJ期間中は常駐

Platform — 基盤の概念

Platformとは
全メンバー(CEO以外)が動く土台。CEO直轄。agentsリポジトリそのもの。
Gateway・Interface層・Scheduler・Manager層・Worker層・ツール群・Governance機能群の全てがPlatformの中に存在する。

Platformの改善

基盤の改善はCEOの仕事
PlatformがWorker層を管理し、Worker層がPlatformを改善する循環構造。Platformの改善(agentsリポジトリへの変更)は全てCEO承認必須。

Interface層のルーティングテーブル

ルート条件
direct質問・雑談・スケジュール確認「おはよう」「明日空いてる?」
vdu-shiftシフト管理アプリ「シフト表にログイン機能追加」
vdu-the-botchイベント精算アプリ「精算画面のバグ直して」
vdu-webコーポレートサイト「会社HPのお知らせ更新」
vdu-eventsイベント告知サイト「次回イベントのページ作って」
vdu-spotifySpotify整理「プレイリスト整理スクリプト修正」
ba経理・法務・調達・HR・総務「請求書作って」「契約書チェック」
platform基盤そのものの改修・改善(CEO承認必須)「botのルーティング直して」「新しいWorker層作って」

通信フロー

CEOからのメッセージ処理フロー

ステップFromTo接続方式内容
1CEOSlackブラウザ / デスクトップアプリCEOがSlackにメッセージ投稿
2SlackGatewaySocket Mode (WebSocket)Slackがイベントをリアルタイム配信
3GatewayOrchestrator(Interface層)subprocess (Claude CLI)Gatewayがルーティング判断のためOrchestratorを起動
4OrchestratorManager層subprocess (Claude CLI)判断結果に基づきManager層セッションにタスク転送
5Manager層Gatewaystdout → Gateway解析Manager層がWorker層起動をGatewayに依頼
6GatewayWorker層subprocess (Claude CLI)Resource Governorがクォータチェック後、Worker層を起動
7Worker層Manager層stdout → Gateway → Manager stdin実行結果をManager層に返却
8Manager層Gateway → Slackstdout → Slack API (HTTP)Manager層がCEOに報告

定期タスク処理フロー

ステップFromTo接続方式内容
1Schedulerツール群(ops/)Python直接呼び出しcron設定に基づきツール群を起動(経費・請求書・メール等)
2ツール群外部サービスMS Graph API / HTTP / Playwright外部サービスからデータ取得・処理実行
3ツール群BA(Manager層)Slack API (HTTP)実行結果をBAに通知

通信ルール

通信経路接続方式
CEO → Manager層Slack → Gateway → Orchestrator(Interface層)→ Manager層Socket Mode → subprocess → subprocess
Manager層 → Worker層Manager層 → Gateway(Worker層起動依頼)→ Worker層stdout解析 → subprocess (Claude CLI)
Worker層 → Manager層Worker層 → Gateway → Manager層stdout → Gateway転送 → stdin
Manager層 → CEOManager層 → Gateway → Slackstdout → Slack API (HTTP)
Manager層 → Manager層直接通信不可。CEOを経由する
Worker層 → Worker層直接通信不可。PJMまたはManager層を経由する
全通信Audit Engineに自動記録Gateway内部ログ

PJ工程定義とレビュープロセス

PJ工程定義

フェーズ担当工程
PJ前Manager層発見 → 調査 → 要求整理 → 要件定義 → 委託
PJ中PMO + PJM + Worker層設計 → 実装 → テスト → 受入 → リリース → 記録 → 解散
Manager層の関与ポイント
Manager層はPJ中の全工程に張り付かない。入口(要求・要件レビュー)出口(最終受入)のみ関与する。
PJMはPJ解散まで生存し、PJ中工程の全体を管理する。

レビュープロセス(2026-04-06 CEO確定)

論点ルール
計画(Plan)のレビューCEO確認する
設計書のレビュー毎回必須ではなく必要に応じて
PJ中工程(Layer2)のレビューManager層ではなくPJMが担当
受入テスト要件を出した人が実施(Manager層が出した要件→Manager層、CEO→CEO)
要件定義のCEO確認全てではなく論点をシャープにして必要なものだけ上げる

デプロイとリリースの区別

概念定義
デプロイ特定環境への反映
リリースユーザーへの公開
要ルール化
以下の項目を定義する必要がある:
  • どの環境か(dev / staging / production)
  • どのブランチへのマージか(feature → develop、develop → main 等)
  • 環境ごとの承認フロー

PJ化ルール

共通資産に触るなら全てPJ化
共通資産(agentsリポジトリ等)に手を加えるなら、規模に関わらず全てPJ化する。フェーズスキップはしない。同じPJフローで回す。
ルール内容
PJ化の判断基準共通資産への影響有無。影響があれば規模を問わずPJ化
フェーズスキップ廃止小さくても同じPJフロー(設計→実装→テスト→受入→リリース→記録→解散)で回す
小さい要求の扱い単体でスキップではなく、他の要求とまとめて1つのPJにする

作業管理(Agile部分採用)

採用する概念

Agile用語MNMLでの対応
Epic= PJ(複数Issueのまとまり)
Story= Issue(1つの変更目的)
Task= サブタスク(Issue内の作業単位)

不採用の概念

概念不採用の理由
Sprint / Velocity / セレモニーAI 24h稼働にタイムボックス不要
Backlog管理GitHub Issueで十分。別概念不要
管理の基本単位
GitHub Issueが管理の基本単位。Epic = PJ でグルーピングする。

用語集

用語定義
Platform全エージェントが動く基盤。ガバナンス機能を内蔵。CEO直轄。agentsリポジトリそのもの
Gateway外部世界との通信ハブ。全通信がここを通る。Resource Governor を内蔵。接続方式: Slack Socket Mode / GitHub REST API / MS Graph API
Interface層Orchestrator。タスクを適切なManager層にルーティングする執事。接続方式: subprocess (Claude CLI)
Scheduler定期タスクの発火機能
Policy Engine品質ルールの定義と自動適用。CLAUDE.md + pre-commit hooks + 品質ゲートで構成
Audit Engine全行動の自動記録・異常検知・ダッシュボード
Resource Governorトークンクォータ・同時実行数・公平スケジューリングの自動制御
Self-Monitor基盤自身の死活監視・自動復旧
Manager層Domain Experts。判断のみ行い、実行はWorker層に委譲する。接続方式: subprocess (Claude CLI)
Worker層Skill Pool。ロール注入モデルで都度起動→消滅。接続方式: subprocess (Claude CLI)
VDUValue Delivery Unit。リポジトリ単位の事業責任者(Manager層)
BABusiness Admin。経理・法務・調達・HR・総務(Manager層)
Generator成果物を生成するWorker層ロール
Critic成果物を検証するWorker層ロール
PJMProject Manager。Worker層に注入される有期ロール
Governance-as-Platformガバナンスをエージェントではなく基盤機能として実現する設計思想
Epic= PJ。複数Issueをまとめた活動単位
Story= Issue。1つの変更目的
Taskサブタスク。Issue内の作業単位
PMOProject Management Office。PJ推進管理 + ナレッジ・資産管理
H&AHuman & AI Resources。採用・育成・評価・文化醸成
OAOperational Audit。業務監査・品質・横展開
SASystem Audit。死活監視・リソース管理・セキュリティ
デプロイ特定環境への反映
リリースユーザーへの公開
MNML 組織アーキテクチャ定義 — Governance-as-Platform
Issue #139 · 2026-04-06