エージェント組織再編 設計書

PMO・横断機能・リソース管理の組織設計

Issue #139 作成: architect 2026-03-24 バージョン: 2.1（未定義事項3件の仮方針追記）
目次
  1. 概要
  2. 組織構造図
  3. 確定済み責務分担表
  4. PMO / PJM の関係定義
  5. CEO判断結果（確定済み）
    1. リソース管理M層の設計 → AR独立M層
    2. プロセス停止権限の所在 → 段階的権限
    3. 教育の担当 → AU
    4. Asset Managerの稼働形態 → 定期+オンデマンド
  6. 全ロール一覧
  7. 実装ロードマップ
  8. 補足ルール（仮方針）
    1. R5→R6昇格プロトコル
    2. 複数M層またがりPJ管理
    3. C8のM層振り分け基準

1. 概要

本設計書は、Issue #139 で議論中のエージェント組織再編について、CEOとの議論を経て確定した全事項を整理したものである。

設計書の目的

現状の課題

2. 組織構造図

再編後の組織全体像。紫色がM層（事業部門）、青色が横断機能、緑色が統制機関、赤色がAR（リソース管理）を示す。

CEO（内山） 最終判断権 Slack（UI） IF層 ルーティング・CEO窓口 M層（事業部門） VDU責任者（m-dev） 開発・技術全般 BO責任者（m-bo） バックオフィス・経理 法務責任者（m-legal） 契約・コンプライアンス PMO PJ横断状況管理 正式定義 AR（リソース管理） 死活監視・停止/再起動 確定 横断機能（W層相当） Asset Manager 共有資産・ナレッジ管理 正式定義 W層（プロジェクトチーム） researcher / architect / coder / reviewer / tester / docs 統制機関 AI Ops エラー監視・レジストリ 既存 AU（監査） CLAUDE.md管理・組織改善 正式定義 M層（事業部門） 横断機能 統制機関 AR（リソース管理）
図1: 再編後のエージェント組織構造

3. 確定済み責務分担表

CEOとの議論を経て確定した責務の割り当て。

責務担当補足
共有資産管理（knowledge/、共通ライブラリ） Asset Manager 横断的な共有リソースの整理・更新
ナレッジベースindex更新 Asset Manager 知識の整理・検索性向上
横断的な重複排除・整合性チェック Asset Manager 複数PJ間で重複する知識・コードの統合
CLAUDE.md（役割定義）管理 AU（監査） 各エージェントの役割定義の改善・統制
組織の役割・能力改善 AU（監査） 組織全体の改善提案
教育（ベストプラクティス浸透） AU（監査） CLAUDE.md管理と一体。監査→改善のサイクル
死活監視・リソース監視 AR（リソース管理） 独立M層。トークン/rate limit/CPU監視
プロセス停止/再起動 AR（リソース管理） 段階制: rate limit停止は自律、PJ停止はCEO承認
PJ横断の状況可視化 PMO ダッシュボード・進捗報告
設計書・ソースコード管理 architect Asset Managerへの委譲も検討余地あり
Issue更新・内容充実 PJM PJ進行中のIssue管理はPJMの責務
PJ品質改善 PJM PJの品質改善はPM（PJM）担当
設計の考え方 「Issue更新」「品質改善」のように、全員が当事者として取り組むべき責務は特定のロールに閉じ込めない。責任の所在が曖昧になるのではなく、「自分のタスクは自分が管理する」という原則を組織に埋め込む。

4. PMO / PJM の関係定義

概念整理

PMO = 箱（組織）

Project Management Office。M層に属する組織単位。

PJM = 帽子（役割）

Project Manager。PMO組織メンバーがPJに参加した時の役割名。

PMOとPJMの使い分け

観点PMO（組織として）PJM（役割として）
視点 全PJ横断・俯瞰 特定PJの中
主な活動 ダッシュボード管理、進捗の横並び比較、リソース配分助言 PJ内の進捗管理、Issue管理、M層への報告
対話相手 CEO、各M層責任者 W層メンバー、M層責任者
いつ活動 定期（日次/週次の状況把握） PJ進行中（タスク発生時）
PMO（組織） PJ横断の管理オフィス PJに参加すると… PJM Issue #139 を担当 PJM Issue #XXX を担当 PJM Issue #YYY を担当 W層（researcher / architect / coder / reviewer / tester / docs）
図2: PMO（箱）とPJM（帽子）の関係

5. CEO判断結果（旧: 未決事項）

以下4件はCEO判断により全て確定済み。判断経緯と選択肢の比較を記録として残す。

5-1. リソース管理M層の設計

背景 CEOは「リソース管理をM層としてちゃんと定義したい」と明言。トークン消費・プロセス数・rate limitの監視と、リソースが逼迫した時の停止判断・CEO報告が必要。
観点案A: AR（独立M層として新設）案B: PMOにリソース管理を統合
概要 AR（AI Resources Management）を独立したM層として新設。トークン・プロセス・rate limitの監視と停止判断を専任で担う PMOがPJ横断管理の一環としてリソース配分も管理。PJの優先度とリソースを一元判断
メリット
  • 責務が明確で、リソース問題に即座に対応できる
  • M層として正式に位置づけられ、停止権限を持てる
  • PMOの負荷が上がらない
  • M層の追加が不要（組織がシンプル）
  • PJ優先度とリソース配分を一元的に判断できる
  • PMOが全体像を把握しているため、配分の判断に文脈がある
デメリット
  • 常駐プロセスが1つ増える
  • 現時点の仕事量で専任が正当化されるか疑問
  • PMOとの連携が必要（「このPJを止めてよいか」の判断）
  • PMOの責務が重くなる（PJ管理 + リソース管理）
  • リソース監視は常時必要だが、PMOはオンデマンドの可能性
  • 責務が混ざると、どちらも中途半端になるリスク
CEO判断: 案A採用 — ARを独立M層として新設

理由: CEOが「M層として定義したい」と明言。リソース管理は事業判断を伴う重要な責務。プロセス停止のような即座の判断が求められる場面では、専任のほうが対応が速い。PMOとの責務分離も明確になる。

5-2. プロセス停止権限の所在

背景 ARがリソース逼迫時にプロセスを停止する権限をどこまで持つか。特に深夜のCEO不在時の対応が論点。
観点案A: 段階的権限案B: 全面自律案C: 全面CEO承認
概要 緊急度に応じて権限を分ける。低優先PJの停止は自律、高優先PJはCEO承認 ARが全ての停止判断を自律的に行い、事後報告 全ての停止にCEO承認が必要
メリット
  • 緊急時に即座に対応できる
  • 重要な判断はCEOが関与
  • 深夜でも最低限の防御が機能
  • CEOの負担が最小
  • 24時間対応可能
  • CEOが全て把握できる
  • 誤停止のリスクゼロ
デメリット
  • 権限の線引きルールの設計が必要
  • 重要PJを誤って停止するリスク
  • CEOが把握できない判断が行われる
  • 深夜にCEO不在だと対応できない
  • rate limit暴走時に被害が拡大
CEO判断: 案A採用 — 段階的権限

確定ルール:

5-3. 教育の担当

背景 エージェントの「教育」（能力改善、ベストプラクティスの浸透）を誰が担うか。CEOは「相談したい」と発言。
観点案1: AU（監査）が担当案2: AR（リソース管理）が担当
概要 AUがCLAUDE.md管理の延長で教育も担う。「どう改善すべきか」を分析・提案 ARが「リソース＝エージェントの能力も含む」と解釈し、能力向上を担う
メリット
  • CLAUDE.md管理と教育は本質的に同じ活動（役割定義の改善 = 教育）
  • 監査で発見した問題をそのまま改善につなげられる
  • 「問題を見つける人」と「直す人」が同じで効率的
  • リソース管理の一環として、エージェントのスキル向上を統合的に見られる
  • 能力不足で余計なリトライが発生→リソース浪費、という流れを一元管理
デメリット
  • 「監査」と「教育」は性質が異なる（チェックする側と育てる側）
  • ARの責務が広がりすぎる（プロセス管理 + 能力管理）
  • 教育の内容を判断するにはCLAUDE.mdの深い理解が必要で、ARにはない
CEO判断: 案1採用 — AUが教育を担当

理由: AIエージェントにおいて「教育」とは「CLAUDE.mdの改善」とほぼ同義。CLAUDE.md管理と教育は一体。監査で見つけた問題を改善提案として反映する流れが自然。ARに能力管理まで持たせると責務が分散する。

5-4. Asset Managerの稼働形態

背景 共有資産管理は常時監視が必要か、必要な時だけ起動すればよいか。
観点案A: オンデマンド案B: 定期実行（バッチ）案C: 常駐
概要 M層やW層が依頼した時だけ起動 1日1回など定期的にknowledge/の整合性チェックを実行 常駐プロセスとして常時稼働
メリット
  • リソース消費が最小
  • シンプルな実装
  • 定期的な整合性チェックが保証される
  • リソース消費は中程度
  • 即座に対応可能
  • 変更を常時監視できる
デメリット
  • 依頼を忘れると資産が放置される
  • 整合性チェックが漏れる可能性
  • リアルタイムの対応はできない
  • 常駐プロセスが増える
  • 仕事量に対して過剰な可能性
CEO判断: 定期実行＋オンデマンド併用

理由: 共有資産の整合性チェックは日次バッチで十分。加えて、M層やW層が必要に応じて呼び出せるようにしておけば、緊急時も対応できる。常駐させるほどの仕事量は現時点ではない。

6. 全ロール一覧

確定分は緑枠、既存は紫枠で表示。

M層（事業部門）

VDU責任者（m-dev）

既存 常駐

開発・技術全般を統括。W層に作業を委譲し、成果物をレビューする。

実装: agents/managers/dev/

BO責任者（m-bo）

既存 常駐

バックオフィス・経理業務を統括。opsパイプラインを管理する。

実装: agents/managers/bo/

法務責任者（m-legal）

既存 常駐

契約・コンプライアンスを統括。契約書レビュー等を担当。

実装: agents/managers/legal/

PMO

正式定義

PJ横断の状況可視化。メンバーがPJに参加するとPJMとして活動。

実装予定: agents/managers/pmo/

AR（リソース管理）

確定 独立M層

死活監視・リソース監視（トークン/rate limit/CPU）・異常時の停止/再起動。停止権限は段階制: rate limit停止は自律、PJ停止はCEO承認。

実装予定: agents/managers/ar/

横断機能

Asset Manager

正式定義

knowledge/・共通ライブラリの管理。ナレッジindex更新。重複排除・整合性チェック。

実装予定: agents/workers/asset-manager/ または agents/shared/asset-manager/

W層（プロジェクトチーム）

researcher

既存

技術調査・コード分析。Phase 1で活動。

architect

既存

設計・IF定義。Phase 1で活動。

coder

既存

コード実装。Phase 2で活動。

reviewer

既存

コード/設計レビュー。Phase 3で活動。

tester

既存

テスト作成・実行。Phase 3で活動。

docs

既存

ドキュメント作成。任意フェーズで活動。

統制機関

AI Ops

既存 常駐

エラー監視・レジストリ管理・CLAUDE.md整合性チェック。

実装: agents/ai-ops/

AU（監査）

正式定義

CLAUDE.md（役割定義）管理・組織の役割改善・教育（確定）。

実装予定: agents/au/

7. 実装ロードマップ

優先度順に4フェーズで段階的に実装する。各フェーズは独立してデプロイ可能。

Phase 1 確定済みロールの実装

基盤整備として先行着手するもの。

タスク内容前提
PMOのCLAUDE.md作成 PJ横断状況可視化の役割定義、PJMとの使い分けルール なし（確定済み）
Asset ManagerのCLAUDE.md作成 共有資産管理の役割定義、対象ディレクトリ、更新ルール なし（確定済み）
AU（監査）のCLAUDE.md作成 CLAUDE.md管理・組織改善の役割定義、チェック観点 なし（確定済み）

Phase 2 CEO判断確定分の実装

CEO判断が全て確定済み。即着手可能。

タスク内容前提
AR（リソース管理）の実装 CLAUDE.md作成、AI Ops monitorとの連携設計、段階制停止権限ルール Phase 1完了
AUに教育責務を追加 AU（監査）のCLAUDE.mdに教育（CLAUDE.md改善）責務を追加 Phase 1完了
Asset Managerの稼働形態設定 定期実行（日次バッチ）＋オンデマンド呼び出し併用。スケジューラー設定 Phase 1完了

Phase 3 IF層・ルーティングの更新

新ロールへのルーティングを有効化する。

タスク内容前提
IF層のルーティング更新 PMO・AR・AU・Asset Managerへのルーティングルール追加 Phase 1・2完了
ダッシュボードの更新 新ロールの組織図表示、PMOの横断ビュー Phase 1完了

Phase 4 運用検証と調整

実際に動かして問題を洗い出し、ルールを調整する。

タスク内容前提
1週間の試験運用 新ロールを有効化し、問題を収集。特にARの停止判断ルールを検証 Phase 3完了
CLAUDE.md調整 試験運用で見つかった問題をAU主導で改善 試験運用完了
全Phase即着手可能 CEO判断が全て確定済みのため、Phase 1〜4を順次進められる。

8. 補足ルール（仮方針） 仮

ユースケース網羅検証（47件）で発見された未定義事項3件について、仮の方針を記載する。CEO確認後に正式化する。

8.1 R5→R6昇格プロトコル 仮

課題 PMOが軽微（R5: PMO直接処理）と判断してPJMなしで着手後、途中で中規模と判明した場合の昇格手続きが未定義。

仮方針

  1. 昇格判断: PMOが作業中に「影響範囲が2ファイル以上」「設計判断が必要」「複数W層の協調が必要」のいずれかに該当すると判断した時点で、R6（PMO→PJM経由）に昇格する
  2. PJM起票: PMOがPJMを起票し、タスクの背景・現状・作業済み成果物を引き継ぎ情報として渡す
  3. 成果物の引き継ぎ: PJMが引き継ぎ時に作業済み成果物をレビューし、継続利用可否を判断する。問題なければそのまま継続、問題があればやり直し指示を出す
  4. W層の扱い: 進行中のW層タスクはPJMが引き継ぐ。W層の再起動は不要（PJMからの新しい指示で継続）
ステップ実行者アクション
1. 昇格判断PMO作業中に中規模以上と判断。R5→R6に昇格を決定
2. PJM起票PMOPJMを起票し、背景・成果物・残作業を引き継ぎ
3. 成果物レビューPJM引き継いだ成果物を確認し、継続利用可否を判断
4. 作業再開PJM → W層PJMがW層に新しい指示を出し、作業を再開

8.2 複数M層またがりPJ管理 仮

課題 PJMの報告先・フェーズ主管の決定方法が未定義。例: dev+bo両方にまたがるPJの場合、どちらのM層がPJMを管理するか。

仮方針

  1. 主管M層の決定: タスクの主目的に応じて主管M層を一つ指定する
    • コード変更・システム設計が主目的 → m-dev が主管
    • 経費・請求・業務フローが主目的 → m-bo が主管
    • 契約・法務が主目的 → m-legal が主管
    • 判断が難しい場合 → IF層がCEOにconsult
  2. 副M層との連携: 副M層は主管M層経由で連携する。PJMが直接副M層に指示を出すことはない
  3. 報告ライン: PJM → 主管M層 → CEO。副M層への進捗共有は主管M層が行う
  4. フェーズ主管: 各フェーズで実作業を担うM層が異なる場合でも、PJM全体の管理責任は主管M層に帰属する
主目的主管M層例
コード変更・システム設計m-dev新機能実装で経費連携が必要なPJ
経費・請求・業務フローm-bo経費自動化でAPI開発が必要なPJ
契約・法務m-legal契約変更でシステム改修が必要なPJ
判断困難CEO判断IF層がCEOにconsultして決定

8.3 C8のM層振り分け基準 仮

課題 外部イベント（Webhook等）をIF層がm-bo/m-devのどちらに振るかの基準が未定義。

仮方針

IF層がイベントのペイロード内容（トリガー種別）で判断する。

  1. m-dev に振るイベント: コード変更・デプロイ・CI/CD・GitHub Webhook・システムアラート・インフラ関連
  2. m-bo に振るイベント: 経費・請求・メール受信・スケジュール・業務フロートリガー・外部SaaS通知（MFクラウド等）
  3. 判断困難な場合: IF層がCEOにconsult
イベント種別振り先具体例
GitHub Webhookm-devPR作成、Issue更新、CI失敗通知
デプロイ通知m-devCloudflare Pages、Vercelデプロイ完了/失敗
システムアラートm-devプロセスダウン、メモリ逼迫、ディスク容量
メール受信m-bo添付ファイル取得・振り分け（mail_filing）
SaaS通知m-boMFクラウド経費/請求書の更新通知
スケジュールm-boOutlook予定変更、リマインダー
不明・複合CEO判断IF層がconsultで確認
補足: 振り分けルールの拡張 新しい外部イベントソースが追加された場合、IF層のCLAUDE.mdにルーティングルールを追記する。AU（CLAUDE.md管理担当）が定期的にルール網羅性を確認する。

Issue #139 | architect | 2026-03-24