MNML AIエージェント組織設計書
Issue #139
作成: W層 architect
日付: 2026-03-24
ステータス: CEO判断待ち
この文書について
合同会社MNMLのAIエージェント組織の全体設計をまとめたものです。
Mac mini 1台 + Claude CLI (Max Plan) の上で動く「AI組織」が、どのような構造で、どのように仕事を進め、どのように情報を管理するかを定義します。
1. 組織のビジョン — 行動原則とサッカーフィールドの比喩
1-1. サッカーフィールドとしての組織
MNMLのAI組織は「サッカーフィールド」に例えられます。Z軸（高さ）がCEO→M層→W層の階層、XY平面（フィールド）がW層のスキルプールです。
図: サッカーフィールドの比喩 — Z軸が階層、XY平面がW層スキルプール
ポイント
CEOはスタンドから全体を俯瞰する。M層は監督・コーチとしてフィールドの選手を配置・指揮する。W層はフィールド上の選手で、必要なポジション（スキル）に必要な人数だけ配置される。試合（PJ）が終われば解散。
1-2. 行動原則 — MNMLの組織が大切にすること
全てのエージェントが共有する、組織の根本的な考え方です。迷ったときはここに立ち返ります。
🎯
自動化が最優先
人の手・時間・在庫を最小にする。やれることはAIがやる。CEOには判断だけ上げる。
🧩
1つの世界、1つの真実
同じものが2つ存在する状態を許さない。作る前に既存を探す。見つかれば再利用・拡張する。
✨
シンプルさは美
過度な抽象化・過剰設計を避ける。必要最小限の仕組みで最大の成果を。
🔄
冪等性
同じ操作を何度実行しても安全な設計にする。途中で止まっても、再実行すれば正しい状態になる。
🔍
構造的一貫性
場当たり的な対処より根本設計。判断はMECE（漏れなくダブりなく）で分解する。
🛡
捏造禁止
実行結果を推測で報告しない。動かして確認してから完了とする。不確実なら不確実と言う。
2. 組織構造と各役割 — CEO / IF層 / M層 / W層
2-1. 組織図
MNMLのAI組織は、CEO（人間）を頂点に、役割の異なるAIエージェントが階層的に配置されています。
図1: MNML AIエージェント組織図
常駐 ≠ 常にトークンを消費
「常駐」とは、プロセスが待機状態で存在し続けるという意味です。メッセージが来なければトークン消費はゼロ。呼ばれたときだけ動きます。メッセージ振り分け機構がメッセージを受け取り、必要なエージェントだけが起動します。（実装:
セクション8参照）
2-2. 各役割の詳細
CEO（内山）
人間
3つの責務に集中し、日常オペレーションには入らない（M層に委任）。
- MVV（ミッション・ビジョン・バリュー）の定義 — 組織の方向性と価値基準を決める
- 有限リソースに関する意思決定 — 何を優先し、何を止めるかを判断する
- 社外との折衝 — クライアント・パートナー・外部サービスとの交渉
AIに委ねるのは「作業」。「判断」は人間が行う。CEOはダッシュボードで全活動を監視し、必要な時だけ介入する。
IF層（インターフェース）
常駐 スレッド横断
- CEOとAI組織の唯一の窓口
- タスクの受付・内容理解・適切な責任者へのルーティング
- 完了報告・状況報告のCEOへの伝達
- 組織全体で1つ（複数スレッドを横断して管理）
VDU責任者（事業/プロダクト単位）
常駐 プロダクトごとに1人
- 担当プロダクト/事業のドメイン知識を蓄積
- 改善課題を発見・管理し、PJとして起票
- PJMを起動して作業を委任、完了を監督
- プロダクト増加に応じてスケール（責任者を追加）
現在: agents基盤 / the-botch / shift / ITコンサル / 香水ブランド の5つ
BO責任者（バックオフィス）
常駐 1エージェント
- 経理・法務・総務を1人で管理
- 観点（経理 vs 法務 vs 総務）は違うが、ナレッジで吸収
- ops/パイプライン（経費・請求書・メール等）の管理者
AU（監査）
常駐 複数エージェント
- 横断的な品質監視（成果物の品質チェック）
- 重複排除チェック（同じものが2つ作られていないか）
- トークン消費量の監視・チューニング提案
- ナレッジの整合性チェック・横展開
- 並行実施が多いため、ボトルネック防止で複数に分類
PJM（プロジェクトマネージャー）
一時的 PJ期間のみ
- M層の一時的なインスタンス
- 担当PJのスコープでW層を管理・監督
- PJ完了で消滅
- VDU責任者・BO責任者・AUが必要に応じて起動
スキルプール（W層）
都度起動 共有資源
組織全体で共有する実作業者群。誰でも呼べる。必要な数だけ並行起動し、完了したら消滅する。
| スキル | 役割 | 典型的な使い方 |
|---|
architect | 設計・IF定義 | 新機能の全体設計、データモデル定義 |
coder | コード実装 | 設計書に基づくコーディング |
reviewer | コード/設計レビュー | 品質ゲートチェック、セキュリティ確認 |
tester | テスト作成・実行 | テストコード作成、動作検証 |
researcher | 技術調査・コード分析 | 既存コードの横断検索、技術選定 |
analyst | データ分析・調査 | ログ分析、傾向調査 |
writer | 文書作成 | メール下書き、提案書 |
designer | UI/UXデザイン | 画面設計、モック作成 |
docs | ドキュメント整備 | README、手順書、API仕様 |
deployer | デプロイ作業 | Cloudflare Pages、本番反映 |
2-3. M層の自律稼働 — 工場のように毎日動く組織
M層の各Division（VDU / BO / AU）は、CEOの指示を待たずに自律的に活動します。CEOは日常オペレーションに入らず、M層に委任しています。組織全体が「工場のように毎日自律稼働する」イメージです。
図: M層の自律稼働 — 各Divisionが独立して日常業務を遂行
CEOの関わり方
CEOが関与するのは、承認が必要な判断（リソース配分変更、組織変更、対外交渉）と定期レポートの確認のみ。日常の改善・運用・品質管理はM層が自律的に回す。CEOがSlackを見なくても、組織は動き続ける。
3. プロジェクト構造 — 起票から完了まで
3-1. 通常フロー vs PJ化フロー
タスクの大きさによって2つのフローを使い分けます。
通常フロー（小さなタスク）
M層（VDU責任者/BO責任者）が直接W層を呼んで処理します。
↓
2
M層がW層を直接起動例: coder 1名を呼んで修正
↓
↓
PJ化フロー（大きなタスク）
M層がPJMを立てて委任します。複数W層の協調が必要な場合に使います。
↓
↓
3
PJMがW層を必要な数だけ並行起動例: architect + coder 2名 + tester
↓
↓
3-2. なぜPJMを別に立てるのか
図2: PJMを別に立てる理由 — 直列処理の排除
3-2b. VDU責任者のPMO生成フロー
VDU責任者がA個の改善課題を発見したとき、それをB個のPJに分割し、各PJにPMOを立てます。VDU責任者自身はPMOを兼任しない（兼任すると他の課題発見がスタックする）。VDU責任者・PMO・W層の全員が並行稼働し続けます。
図2b: VDU責任者のPMO生成フロー — VDU責任者はPMOを兼任せず、全員が並行稼働
なぜVDU責任者はPMOを兼任しないのか
VDU責任者がPMOを兼任すると、PJ管理に時間を取られ、次の改善課題の発見が止まる。VDU責任者の本質的な仕事は「何をやるか」を決めること。「どうやるか」はPMOに委任する。これにより、VDU責任者は常に新しい課題を探し続け、PMOは各PJを独立して管理し、W層は実作業に集中する。全員が並行稼働し、誰もスタックしない。
3-3. プロジェクト全体フロー
図3: プロジェクト全体フロー — 起票から完了まで
3-4. Slackスレッド = プロジェクト
MNMLでは「Slackの1スレッド = 1プロジェクト」という考え方を採用しています。
仕組み
| 概念 | 対応するもの | 説明 |
|---|
| プロジェクト | Slackスレッド | CEOが1スレッドで起こすもの = 1プロジェクト |
| プロジェクト開始 | CEOの投稿 | IF層がスレッドの要求を理解してPJを立ち上げ |
| 担当決定 | IF層のルーティング | IF層がM層と相談して必要なW層を特定 |
| 並行稼働 | 複数スレッド | 複数スレッド = 複数PJが同時に進行 |
常駐エージェント（スレッド横断）
- IF層 — 全スレッドのメッセージを受け取る
- VDU責任者 — 担当プロダクトのスレッドを監視
- BO責任者 — バックオフィス系スレッドを監視
- AU — 全活動を横断的に監視
都度起動エージェント（スレッド専属）
- PJM — 該当PJのスレッドでのみ活動
- W層 — PJMまたはM層の指示で起動
- スレッド（PJ）完了で消滅
図4: 並行稼働する3つのスレッド（プロジェクト）のイメージ
4. リソース管理 — 限られた資源をどう使うか
4-1. 物理制約
| リソース | 詳細 | 備考 |
|---|
| ハードウェア | 物理マシン 1台 | 全エージェントがここで動く |
| AIエンジン | LLM（月額固定プラン） | トークン予算は月単位の上限あり |
| 実行方式 | サブプロセス起動 | 従量課金なし（固定プラン内） |
全活動が同じリソース（トークン予算）を共有しているため、誰かが大量に使えば他が使えなくなります。
4-2. リソース逼迫時のフロー
図5: リソース逼迫時のフロー
重要: AIはリソース配分を判断しない
「何を優先して何を止めるか」はCEOが決める。AIは判断材料（現在の稼働状況・消費量）を整理して提示するだけ。AIが自動的に優先度を付けて停止することはしない。
4-3. ダッシュボード — CEOの判断支援画面
CEOが全活動を一覧し、リソース配分を判断するための画面です。
設計方針
- 稼働中の全活動を一覧（IF/VDU/BO/AU/PJM/W 全層）
- スレッド（案件）単位でグルーピング
- M層→W層を親子でネスト表示
- 経過時間の降順ソート（リソース消費の代替指標）
- AIが重要度・優先度を自動判断しない（CEOが判断できる材料を並べる）
- 停止ボタン付き（判断→行動が1画面で完結）
UIモック
MNML Agent Dashboard
トークン使用率: 78%
agents基盤改修
スレッド: #dev / 2026-03-24 14:30 開始 / セッション: a8f2c1
VDU
agents基盤 責任者
— 監督中
稼働 47分
PJM
PJM-改修
— W層管理中
稼働 35分
W
coder
— bot/router.py 実装中
稼働 30分
W
tester
— テストケース作成中
稼働 15分
図6: ダッシュボードUIモック — 親子ネスト表示・停止ボタン付き
5. 根本原則 — 重複排除・共通資産化
根本思想
MNMLの世界は1つの閉じた情報空間。同じものが2つ存在する状態を許さない。
何かを作る前に、既にあるものを探す。あれば再利用・拡張する。なければ新規に作るが、特定PJ専用ではなく共通資産になるかを検討する。
5-1. 対象
| 対象 | 重複の例 | 正しい姿 |
|---|
| コード | 同じHTTPクライアント処理が2箇所にある | 共通モジュールに統合 |
| 設計書 | 同じ領域の設計書が別PJで作られる | 既存を拡張 |
| Issue | 同じ課題が重複起票される | 既存Issueに追記 |
| ドキュメント | 同じ手順書が2箇所にある | 1箇所にまとめてリンク |
| パイプライン | 同じ処理が別のopsスクリプトにある | 共通化 |
| ナレッジ | 同じ判断理由が複数のCLAUDE.mdにある | Issueに1箇所で管理 |
5-2. 横断チェックの仕組み
図7: 重複排除チェックのタイミングと担当者
6. ナレッジ管理 — 情報をどこに、どう貯めるか
6-1. 3つの管理先と役割分担
図8: ナレッジ管理の3層構造
6-2. タグ体系
knowledge.mdで使うタグの設計。タグでフィルタして必要なIssueを素早く見つけます。
| カテゴリ | タグ例 | 用途 |
|---|
| ドメイン | #agents #the-botch #shift #consulting #fragrance #ops | どのプロダクト/事業に関するか |
| 種別 | #design-decision #postmortem #lesson #architecture | 情報の性質 |
| 技術 | #slack-bolt #claude-cli #ms-graph #playwright | 関連する技術スタック |
| 業務 | #accounting #invoice #mail-filing #legal | 関連する業務領域 |
knowledge.md のエントリ例
## #agents #architecture #design-decision
- [Issue #139](https://github.com/info-mnml/issues/issues/139) — 組織構造の再設計。VDU責任者/PJM分離の判断理由
- [Issue #102](https://github.com/info-mnml/issues/issues/102) — トークン消費削減。対策A〜Gの設計判断
## #agents #postmortem #lesson
- [Issue #102](https://github.com/info-mnml/issues/issues/102) — 表面的実装→revert。設計判断はCEO承認後に実装する教訓
## #ops #mail-filing #ms-graph
- [Issue #134](https://github.com/info-mnml/issues/issues/134) — メール添付自動取得。Hennge除外ルールの経緯
6-3. CLAUDE.md更新フロー
| 項目 | 内容 |
|---|
| 更新権限 | M層（VDU責任者/BO責任者）が提案 → CEOが承認 |
| レビュー | AUが整合性チェック（矛盾・重複がないか） |
| 浸透方法 | CLAUDE.mdは各エージェントの起動時に自動読み込みされる。更新 = 即浸透 |
| 頻度 | 役割定義や行動規範の変更時のみ（頻繁には変えない） |
7. 情報管理マップ — 全ての情報の所在
MNMLの情報は「単一真実源（Single Source of Truth）」の原則で管理されます。同じ情報が複数箇所にある状態を作らない。
図9: 情報管理マップ — 全ての情報には「唯一の置き場所」がある
付録: 組織構造サマリー
| 層 | 役割 | 常駐/一時 | 数 | 起動条件 |
|---|
| CEO |
最終意思決定・リソース配分 |
— |
1（人間） |
— |
| IF層 |
CEOとの窓口・ルーティング・報告 |
常駐 |
1 |
システム起動時 |
| VDU責任者 |
プロダクト/事業のドメイン管理 |
常駐 |
プロダクト数 |
システム起動時 |
| BO責任者 |
経理・法務・総務 |
常駐 |
1 |
システム起動時 |
| AU |
品質監視・トークン管理・横展開 |
常駐 |
複数（分類別） |
システム起動時 |
| PJM |
PJのスコープ管理・W層管理 |
一時 |
PJ数 |
M層がPJ化判断時 |
| W層 |
実作業（設計・実装・テスト等） |
一時 |
必要数 |
PJM/M層の指示時 |
8. 実装手段 — 技術的な実現方法
ここまでのセクションで「何が必要か」を定義しました。本セクションでは、それをどう実現しているかを対応付けます。
組織設計と実装は分離する
組織の役割定義やフローは、特定の技術に依存しない。技術は入れ替え可能。このセクションは「現時点の実装」であり、組織設計そのものではない。
8-1. 技術スタック
| 組織設計上の概念 | 現在の実装手段 | 備考 |
|---|
| ハードウェア基盤 | Mac mini（Apple Silicon） | 全エージェントの実行環境 |
| AIエンジン | Claude CLI（Max Plan） | 月額固定。API課金なし |
| エージェント起動方式 | claude CLI subprocess | 各エージェントを独立プロセスとして起動 |
| メッセージ振り分け機構 | bot.py（Slack Bolt + Socket Mode） | Slackメッセージを受け取り、適切なエージェントにルーティング |
| リソース監視機能 | bot.py 内蔵の利用率監視 | トークン利用率を定期チェック、閾値超過でIF層に通知 |
| ダッシュボード | Webアプリ（HTML + REST API） | エージェント一覧・停止機能を提供 |
| 常駐エージェント起動 | bot.py 起動時に自動起動 | IF層・VDU責任者・BO責任者・AUが同時に立ち上がる |
| PJM/W層の起動 | M層がCLI subprocessとして起動 | PJ完了で自動終了 |
8-2. opsパイプライン（バックオフィス自動化）
| 業務 | 実装 | 技術 |
|---|
| 経費処理 | ops/accounting/ | MFクラウド経費API + Playwright |
| 請求書 | ops/invoice/ | MFクラウド請求書API |
| メール添付取得 | ops/mail_filing/ | MS Graph API |
| 作業報告書 | ops/work_report/ | Outlookカレンダー + openpyxl |
| 予定調整 | ops/scheduler/ | Outlookカレンダー API |
8-3. 共通技術基盤
- 言語: Python 3.12
- Slack連携: slack-bolt（Socket Mode）
- HTTP: httpx
- 設定管理: pydantic-settings
- コード品質: ruff（フォーマット + リント）
- 型ヒント: 必須（
from __future__ import annotations）
- HTML成果物公開: Cloudflare Pages（mnml-docs.pages.dev）