MNML組織再設計 — 横断機能・ナレッジ管理詳細設計書

Issue #139 | 作成: architect | 2026-03-24 | バージョン: 1.0

A. 横断機能の設計
B. ナレッジ管理の設計
C. 全エージェントCLAUDE.md反映計画
1. C1. 共通原則の配置先
2. C2. 現行CLAUDE.mdから移動すべき内容
D. 前提条件・制約・移行スケジュール

A. 横断機能の設計

A1. 組織に必要な横断機能（MECE列挙）

組織の横断機能を「統制系」「支援系」「基盤系」の3軸で分解する。

分類	機能	目的	現状	対応方針
統制系（やってはいけないことの防止）	重複排除・資産管理	同じもの・似たものが2つ存在する状態を防ぐ	未実装	監査役の責務として新設
	品質監査	成果物が品質基準を満たしているか検証	一部あり reviewer/testerのCLAUDE.mdに品質ゲート埋め込み	監査役の定期チェックに統合
	セキュリティ監査	OWASP、認証情報漏洩、権限逸脱の検知	一部あり policies/global.md + reviewer品質ゲート	監査役の責務に含める
支援系（やるべきことの促進）	ナレッジ管理	判断理由・経緯・教訓の蓄積と検索	分散 CLAUDE.md / knowledge/ / MEMORY.md に混在	Issue + knowledge.mdインデックスに統合
支援系（やるべきことの促進）	標準化	CLAUDE.mdの構造・命名・記述ルール統一	部分的 M層共通ルールのみ	CLAUDE.md階層継承モデルで解決
基盤系（動き続けるための仕組み）	エラー監視・復旧	障害検知と自動復旧	実装済み AI Ops monitor	現状維持（AI Opsの責務のまま）
基盤系（動き続けるための仕組み）	レジストリ管理	エージェント台帳・権限の整合性維持	実装済み AI Ops registry	現状維持（AI Opsの責務のまま）

整理のポイント: AI Opsは「基盤系」（エラー監視・レジストリ）に専念し、「統制系」（重複排除・品質・セキュリティ監査）を監査役に分離する。支援系はルール化で対応し、専任機能は不要。

A2. 監査役の責務定義

位置づけ

CEO直轄の独立機能。事業ライン（VDU/BO/Legal）にもAI Opsにも属さない。M層・W層の成果物に対して独立した視点でチェックを行う。

CEO（内山） ├── IF層 ├── VDU部門 ─ m-dev ├── BO部門 ─ m-bo ├── 監査役 ◄── CEO直轄・独立。事業ラインから独立した監査 ├── AI Ops ─── エラー監視・レジストリ管理（基盤系） └── スキルプール（共有W層）

責務一覧

責務	トリガー	チェック内容	アウトプット
重複排除チェック	M層がW層に新規作成を指示する前	既存コード・設計書・Issue・ドキュメントに同じもの・似たものがないか横断検索	「既存あり→再利用指示」or「既存なし→新規作成OK + 共通資産化の要否判定」
品質監査	M層がDONE報告する前（定期）	品質ゲート（セキュリティ・金額計算・エラーハンドリング・UI）の遵守	監査報告（OK / 指摘事項リスト）
CLAUDE.md整合性	定期（日次 or コミット時）	全CLAUDE.mdの構造・必須セクション・参照先の存在確認	不整合レポート → AI Opsに修正依頼
ナレッジ整合性	定期（週次）	knowledge.mdインデックスとIssueの整合性。リンク切れ・タグ未付与の検出	不整合レポート → 該当M層に修正依頼

注意: 監査役 ≠ AI Ops
AI Opsは「基盤の安定稼働」（プロセス監視・再起動・レジストリ）が責務。監査役は「成果物の品質・一貫性」が責務。役割が異なるため分離する。
ただし、現行AI Opsの「CLAUDE.md整合性チェック」は監査役に移管する（重複を排除）。

監査役の実装形態 — 比較検討

案	内容	メリット	デメリット
A. 独立エージェント	agents/auditor/ に専用CLAUDE.mdを持つCLIエージェント	独立性が高い。M層と利害相反しない	CLIプロセス1回分のトークン消費
B. AI Opsの責務拡張	既存AI Opsに監査機能を追加	新規エージェント不要	基盤運用と品質監査が混在。責務肥大化
C. M層の自己チェック強化	M層CLAUDE.mdに監査チェックリストを追加	追加コスト0	自分で自分を監査する構造。独立性なし

案A: 独立エージェントを推奨。
監査の本質は「独立性」にある。M層もAI Opsも当事者であり、第三者視点での検証は独立した存在が必要。
トークン消費は「呼ばれた時だけ起動」で最小化可能（常駐不要）。
配置先: agents/auditor/CLAUDE.md

監査役の起動タイミング

事前チェック: M層がW層に「新規ファイル作成」「新規モジュール設計」を指示する前に、bot.pyが自動で監査役を起動。researcherによる横断検索を指示
事後チェック: M層がDONE報告を出した後、bot.pyが監査役を起動。品質ゲート遵守を確認
定期チェック: 日次でCLAUDE.md整合性チェック、週次でナレッジ整合性チェック

A3. 横断品質管理の仕組み

現行の品質管理は各Worker（reviewer, tester）のCLAUDE.mdに品質ゲートが埋め込まれている。これを横断的に管理する方法を検討する。

比較検討: 品質ゲートの管理方式

案	内容	メリット	デメリット
A. 現状維持（各CLAUDE.md埋め込み）	reviewer, tester, coder, architectの各CLAUDE.mdに品質ルールを記載	各Workerが自身のルールを即座に参照可能	同じルールが4箇所に分散。更新時に漏れるリスク
B. 品質基準ファイルに一元化	`agents/shared/quality_gates.md` に全品質ルールを集約。各CLAUDE.mdから参照	Single Source of Truth。更新が1箇所で済む	各Workerの文脈に合わせた記述ができない
C. 共通定義 + 各層カスタマイズ	共通品質基準を `agents/shared/quality_gates.md` に定義。各CLAUDE.mdには「共通基準を参照 + 自層固有の補足」のみ記載	一元管理と文脈適応の両立	参照構造が1段増える

案C: 共通定義 + 各層カスタマイズを推奨。
品質ゲートの「ルール本体」は1箇所（agents/shared/quality_gates.md）で管理。各Workerは「この品質基準に従え」と参照するだけにし、Worker固有の適用方法（例: reviewerは「チェックリストとして使う」、testerは「テストケース生成の基準として使う」）のみCLAUDE.mdに書く。

品質ゲートの分類（共通定義ファイルの構成）

カテゴリ	チェック項目例	適用Worker
セキュリティ	SQLi防止、リソース所属検証、認証情報非出力、入力バリデーション	coder, reviewer, architect
金額計算	整数演算、ゼロ除算、合計一致	coder, reviewer, tester
エラーハンドリング	fetchのres.okチェック、ローディング状態、APIエラー表示	coder, reviewer
UI/UX	二重送信防止、フォーム必須要素、レスポンシブ390px、コード共通化	coder, reviewer, architect
パフォーマンス	ページネーション、N+1防止、インデックス、キャッシュ	architect, coder, reviewer

A4. 重複排除プロセスの具体的フロー

フロー概要

┌──────────┐ ┌───────────────┐ ┌──────────────────┐ │ CEO/IF層 │────▶│ M層がタスク │────▶│ 新規作成が必要？ │ │ タスク投入 │ │ を分解 │ │ （判断ノード） │ └──────────┘ └───────────────┘ └────────┬─────────┘ │Yes │No ┌───────▼───────┐ │ │ 監査役を起動 │ │ 既存修正のみ │ 横断検索を指示 │ │ → そのまま進行 └───────┬───────┘ │ │ │ ┌───────▼───────┐ │ │ researcher が │ │ │ 横断検索実行 │ │ └───────┬───────┘ │ │ │ ┌───────▼───────────┐ │ 類似物が存在？ │ └───┬──────────┬────┘ Yes │ │ No ┌────────▼──┐ ┌───▼──────────┐ │ 既存を再利用 │ │ 新規作成OK │ │ or 拡張 │ │ 共通資産化を │ │ │ │ 検討して作成 │ └───────────┘ └──────────────┘

横断検索の対象と方法

対象	検索方法	類似判定基準
ソースコード	リポジトリ内のGlob/Grep検索	同名ファイル、同機能の関数・クラス、同パターンの処理
設計書	`agents/workers/architect/output/` 内のHTML検索	同一機能の設計、同一問題への対処
Issue	GitHub Issues (info-mnml/issues) のラベル・タイトル検索	同一課題、類似要件、関連する過去の判断
ナレッジ	`knowledge.md` のタグ検索	同一トピックの既存知見
CLAUDE.md	全CLAUDE.mdのGrep検索	同一ルールの重複記載

共通資産化の判定基準

新規作成するものが以下のいずれかに該当する場合、共通資産として設計する:

2つ以上のM層/W層で使われる可能性がある（例: Slack通知、ファイルアップロード）
横断的なルール・基準である（例: 品質ゲート、コーディング規約）
外部API連携の共通処理である（例: MS Graph認証、OneDrive操作）

共通資産の配置先:

コード → ops/shared/ or bot/
ルール・基準 → agents/shared/（新設）
ナレッジ → Issue + knowledge.mdインデックス

B. ナレッジ管理の設計

B1. CLAUDE.mdの役割再定義

現状の問題

CLAUDE.mdに3種類の情報が混在している:

役割定義（本来あるべき）: 「アーキテクトは設計を行う」「coderは実装する」
組織文化・行動原則（本来あるべき）: 「確認せず進める」「平易な言葉で説明する」
判断経緯・教訓（ここにあるべきでない）: 「danketsu-appで浮動小数点問題があった」「トークン消費削減でA〜Gの設計判断をした」

再定義: CLAUDE.mdに書くもの・書かないもの

書くもの（CLAUDE.mdの責務）	書かないもの（Issue/knowledge.mdに移動）
役割・責務の定義（「何をする存在か」）行動原則・制約（「こう振る舞え」「これは禁止」）組織文化・コミュニケーションルール入出力フォーマット定義他エージェントとの連携プロトコル共通ファイルへの参照リンク	過去の判断経緯（「なぜこの設計にしたか」）→ Issue 教訓・失敗事例（「danketsu-appで発見された問題」）→ Issue 特定プロジェクトの設計判断 → Issue 時系列の経緯（「2026-03-06に実装」等）→ Issue 手順書・HowTo → knowledge.md経由でIssue参照

判定基準（迷った時）: 「日付がつくならIssue」「"なぜ"が主語ならIssue」「"何をする"が主語ならCLAUDE.md」

B2. knowledge/ディレクトリの移行計画

現行ファイルの棚卸と移行先

現在の場所	ファイル	内容	移行先	理由
`agents/managers/dev/knowledge/`	action_tags.md	ACTIONタグの定義（file_upload, send_email, cf_deploy）	移動 `agents/shared/action_tags.md`	全M層が参照する共通定義。shared/に一元化
	delegation_protocol.md	W層委譲プロトコル（文脈ブロック・フェーズ分割）	移動 `agents/shared/delegation_protocol.md`	m-bo/m-legalもW層委譲する新設計では共通ルール
	review_process.md	レビュープロセス	移動 `agents/shared/review_process.md`	M層共通ルール。bo/legalにも同名ファイルが存在
	git_workflow.md	Gitワークフロー	移動 `agents/shared/git_workflow.md`	M層共通ルール。bo/legalにも同名ファイルが存在
	auto_commit.md	自動コミットルール	移動 `agents/shared/git_workflow.md` に統合	Gitワークフローの一部
`agents/managers/bo/knowledge/`	ops_commands.md	opsパイプラインの実行コマンド一覧	維持 m-bo固有のまま	m-bo専用の運用知識。他M層は不要
`agents/managers/bo/knowledge/`	action_tags.md（シンボリックリンク）	→ dev/knowledge/action_tags.md	削除 shared/への参照に切替	移動先のshared/を直接参照
`agents/managers/legal/knowledge/`	action_tags.md（シンボリックリンク）	→ dev/knowledge/action_tags.md	削除 shared/への参照に切替	同上
各W層	_MANIFEST.md（テンプレート）	空のプレースホルダー	削除	空テンプレートは価値なし。knowledge.mdに移行

移行後のディレクトリ構成

agents/ ├── shared/ ← 新設: 全エージェント共通資産 │ ├── action_tags.md ← dev/knowledge/ から移動 │ ├── delegation_protocol.md ← dev/knowledge/ から移動 │ ├── review_process.md ← dev/knowledge/ から移動・統合 │ ├── git_workflow.md ← dev/knowledge/ から移動・統合（auto_commit含む） │ └── quality_gates.md ← 新規: 品質ゲート定義を一元化 │ ├── managers/ │ ├── CLAUDE.md ← 維持（M層共通ルール） │ ├── dev/ │ │ ├── CLAUDE.md ← 維持（shared/への参照に書き換え） │ │ └── knowledge/ ← 削除（shared/に移動完了後） │ ├── bo/ │ │ ├── CLAUDE.md ← 維持 │ │ └── knowledge/ │ │ └── ops_commands.md ← 維持（m-bo固有） │ └── legal/ │ ├── CLAUDE.md ← 維持 │ └── knowledge/ ← 削除（shared/に移動完了後） │ ├── workers/ │ ├── （各Worker）/ │ │ ├── CLAUDE.md ← 維持（品質ゲートはshared/参照に変更） │ │ └── knowledge/ ← _MANIFEST.md削除。knowledge.md参照に変更 │ └── ... │ └── auditor/ ← 新設: 監査役 └── CLAUDE.md

B3. knowledge.mdのタグ体系設計

CEO指示: knowledge.mdは「タグ管理付きインデックス」として使う。膨大な情報をエージェントが効率的に検索できる手段とする。

配置場所の検討

案	内容	メリット	デメリット
A. リポジトリルートに1つ	`knowledge.md` をルートに配置	全エージェントが同じインデックスを参照。重複なし	ファイルが大きくなりすぎる可能性
B. agents/に1つ	`agents/knowledge.md` に配置	エージェント関連ナレッジに限定。ops/とは分離	ops/のナレッジが別管理になる
C. 層別に分割	各M層/W層にknowledge.md	各層に関連する知識のみ掲載	分散して横断検索が困難。現状の問題を再発

案A: リポジトリルートに1つを推奨。
「同じものが2つ存在する状態を許さない」原則に最も合致。ファイルサイズはタグで構造化すれば問題ない。全エージェントのCLAUDE.mdからknowledge.mdを参照するルールを記載する。

タグ体系

タグは2軸で構成: 「ドメイン」×「種別」。

軸	タグ	説明
ドメイン（何についてか）	`#architecture`	システム設計・構造に関する判断
	`#security`	セキュリティに関する判断・教訓
	`#ops`	月次業務パイプラインに関する知見
	`#legal`	法務・契約に関する知見
	`#tax`	税務に関する知見
	`#workflow`	Git・デプロイ・CI/CDに関する知見
	`#org`	組織設計・エージェント構成に関する判断
種別（どういう種類か）	`#decision`	設計判断とその理由
	`#lesson`	失敗からの教訓
	`#howto`	手順・やり方
	`#reference`	外部情報・仕様への参照

knowledge.md のフォーマット

# ナレッジインデックス

## 使い方
- タグで検索: `#architecture #decision` のように絞り込む
- Issue番号で原典を参照: 各エントリにIssue番号が付与されている

## エントリ

### トークン消費削減の設計判断
- **Issue**: #102, #103
- **タグ**: #architecture #decision
- **概要**: 対策A〜Gの全設計判断。session最適化、IF層内蔵化、M層Planner化等
- **日付**: 2026-03-06〜03-16

### danketsu-appの品質問題と教訓
- **Issue**: #XX（要起票）
- **タグ**: #security #lesson
- **概要**: 浮動小数点除算、クロスリソースアクセス、二重送信等12件のCRITICAL/HIGH
- **日付**: 2026-03-09

### AI Ops責務再定義
- **Issue**: #XX（要起票）
- **タグ**: #org #decision
- **概要**: ニュース巡回・Issue優先度付けをAI Opsから分離。統制機能に専念
- **日付**: 2026-03-07

（以下、同フォーマットで追記）

B4. Issueへのナレッジ蓄積ルール

GitHub Issueのラベル体系

ナレッジをIssueに蓄積するため、以下のラベルをGitHub (info-mnml/issues) に追加する。

ラベル	色	用途
`knowledge:decision`	#0075ca (青)	設計判断・方針決定の記録
`knowledge:lesson`	#e4e669 (黄)	失敗からの教訓
`knowledge:howto`	#0e8a16 (緑)	手順・やり方の記録
`knowledge:reference`	#d876e3 (紫)	外部仕様・参考情報

ナレッジIssueのテンプレート

## 概要
（何についての知見か。1-2文で要約）

## 背景・文脈
（いつ、なぜこの知見が得られたか）

## 判断内容 / 教訓 / 手順
（本体。詳細を記載）

## 関連
- 元Issue: #XXX
- 関連ファイル: path/to/file
- ドメインタグ: #architecture, #security 等

ナレッジIssue運用ルール

起票タイミング: M層がDONE報告時、その作業で得られた判断・教訓があれば、DONE報告と同時にナレッジIssueを起票する
ラベル付与: knowledge:* ラベル + ドメインラベル（dev, ops, legal等）を必ず付与
knowledge.mdへの登録: Issue起票後、knowledge.mdインデックスにエントリを追加する
クローズしない: ナレッジIssueは参照用のため、基本的にOpenのまま維持する

B5. 検索・参照の仕組み

エージェントがナレッジを見つける方法は3段階。

段階	方法	対象	利用場面
1. CLAUDE.md参照	起動時に自動読み込み	自身の役割定義、行動原則、共通ルールへのリンク	常に（起動のたび）
2. knowledge.md検索	タスク開始時にタグでフィルタリング	過去の判断・教訓のインデックス → Issue番号を取得	新規作成・設計判断が必要な時
3. Issue原典参照	`gh issue view` でIssue本文を取得	判断の詳細・背景・経緯	knowledge.mdで見つけたエントリの詳細が必要な時

検索フロー

M層/W層がタスク開始 │ ├── CLAUDE.md を読む（自動） │ └── 「関連ナレッジがあれば knowledge.md を参照せよ」の指示を確認 │ ├── knowledge.md を開く │ └── ドメインタグで該当エントリを検索 │ 例: #architecture #decision で設計判断の一覧を取得 │ └── 該当Issueを読む（必要に応じて） └── gh issue view 123 --repo info-mnml/issues └── 判断の詳細・背景・代替案を確認

CLAUDE.mdへの追記ルール: 各エージェントのCLAUDE.mdに以下の1行を追加する。
タスク開始時、関連する過去の判断・教訓がないか knowledge.md を参照すること。

C. 全エージェントCLAUDE.md反映計画

C1. 共通原則の配置先

CLAUDE.md階層構造

CLAUDE.mdは4階層で継承関係を持つ。下位は上位のルールを引き継ぐ。

[L0] CLAUDE.md（リポジトリルート） │ 技術スタック、Gitルール、環境情報、全体方針 │ ├── [L1] agents/managers/CLAUDE.md（M層共通） │ │ STATUSタグ、レビュー原則、Issue連携、連続実行 │ │ │ ├── [L2] agents/managers/dev/CLAUDE.md（m-dev固有） │ ├── [L2] agents/managers/bo/CLAUDE.md（m-bo固有） │ └── [L2] agents/managers/legal/CLAUDE.md（m-legal固有） │ ├── [L1] agents/shared/（共通資産ファイル群） │ ├── action_tags.md │ ├── delegation_protocol.md │ ├── quality_gates.md │ ├── review_process.md │ └── git_workflow.md │ └── [L2] agents/workers/*/CLAUDE.md（各Worker固有） └── shared/ への参照 + Worker固有の適用方法

新たに追記する共通原則

原則	配置先	内容
重複排除の原則	CLAUDE.md（ルート）	「新規作成前に既存の類似物を横断検索する。あれば再利用・拡張。なければ共通資産化を検討」
ナレッジ管理原則	CLAUDE.md（ルート）	「判断経緯・教訓はIssueに蓄積。CLAUDE.mdには役割定義・行動原則のみ。knowledge.mdで検索」
knowledge.md参照指示	agents/managers/CLAUDE.md	「タスク開始時、関連ナレッジがないか knowledge.md を参照すること」
共通資産への参照	各M層 CLAUDE.md	「`agents/shared/` の共通ファイルを参照すること」+ ファイルリスト
品質ゲート参照	各W層 CLAUDE.md（coder, reviewer, tester, architect）	「品質基準は `agents/shared/quality_gates.md` を参照」+ Worker固有の適用方法

C2. 現行CLAUDE.mdから移動すべき内容

ルートCLAUDE.md

セクション/内容	現在の行数	対応
アーキテクチャ概要	~20行	維持組織構造の定義は CLAUDE.md の責務
ディレクトリ構造	~15行	維持
技術スタック	~5行	維持
実行方法	~10行	維持
Gitワークフロー	~30行	簡略化詳細はshared/git_workflow.mdへ。ルートには要約のみ
報告ルール	~10行	維持全エージェント共通の行動原則
運用ルール	~10行	維持
HTMLデプロイルール	~20行	移動 shared/action_tags.mdに統合
フロー図作成ルール	~20行	移動 architect/docs固有。shared/に移動 or Worker CLAUDE.mdに限定

M層 CLAUDE.md

ファイル	移動対象	対応
agents/managers/dev/CLAUDE.md	品質ゲート7カテゴリ（~50行）	移動 shared/quality_gates.mdに統合。CLAUDE.mdは参照のみ

W層 CLAUDE.md

ファイル	移動対象	対応
coder/CLAUDE.md	実装品質ルール（整数演算、リソース検証等 ~30行）	移動 shared/quality_gates.md + CLAUDE.mdに「参照 + coder固有の適用方法」
reviewer/CLAUDE.md	必須チェックリスト（セキュリティ5+金額3+エラー3+UI5+性能5 ~40行）	移動 shared/quality_gates.md + CLAUDE.mdに「チェックリストとして適用」
tester/CLAUDE.md	テスト必須カバレッジ5カテゴリ ~20行）	移動 shared/quality_gates.md + CLAUDE.mdに「テストケース生成基準として適用」
architect/CLAUDE.md	セキュリティ・バイ・デザイン + パフォーマンス・バイ・デザイン（~50行）	移動 shared/quality_gates.md + CLAUDE.mdに「設計書の必須項目として適用」

MEMORY.md（自動メモリ）

ファイル	現状	対応
architect/MEMORY.md	the-botch パフォーマンス改善の設計判断記録	移動ナレッジIssueに起票 → knowledge.mdにエントリ追加 → MEMORY.mdから削除
researcher/MEMORY.md	空テンプレート	削除空テンプレートは不要
reviewer/MEMORY.md	空テンプレート	削除
tester/MEMORY.md	空テンプレート	削除

W層MEMORY.mdの方針: W層はタスクごとにCLIが起動・終了する一時プロセスのため、MEMORY.mdに知見を蓄積しても次回のタスクで参照される保証がない。ナレッジはIssueに蓄積し、knowledge.md経由で検索する方が確実。W層のMEMORY.mdは全削除を推奨。

D. 前提条件・制約・移行スケジュール

前提条件

GitHub (info-mnml/issues) にラベル作成権限がある
agents/shared/ ディレクトリは新規作成
既存のシンボリックリンク（action_tags.md）は移動後に更新が必要
全CLAUDE.mdの更新は1コミットにまとめず、段階的に行う

制約

移行中も既存のエージェント動作を止めてはならない（参照先ファイルが存在し続けること）
knowledge.mdが巨大になった場合の分割戦略は将来課題（当面は1ファイルで運用）
W層のCLAUDE.mdから品質ゲートを移動する際、品質が落ちないよう「shared/を参照せよ」の記載を同時に行う

移行ステップ

Step	作業内容	影響範囲	備考
1	`agents/shared/` ディレクトリ作成 + 共通ファイル配置	新規追加のみ。既存に影響なし	action_tags.md, delegation_protocol.md, review_process.md, git_workflow.md, quality_gates.md
2	各M層CLAUDE.mdに `agents/shared/` への参照を追記	M層CLAUDE.md（追記のみ）	まだ旧knowledge/も残っている状態（両方参照可）
3	各W層CLAUDE.mdの品質ゲートを「shared/参照 + 固有適用方法」に書き換え	W層CLAUDE.md	品質ルールの本体はshared/、適用方法はCLAUDE.mdに残す
4	ルートCLAUDE.mdに重複排除・ナレッジ管理の原則を追記	ルートCLAUDE.md
5	`knowledge.md` をルートに作成。既存の判断経緯をエントリ化	新規追加	MEMORY.mdやCLAUDE.mdに混入している判断経緯をIssue化 → knowledge.mdに登録
6	GitHubにナレッジラベル作成（`knowledge:decision` 等）	GitHub Issues
7	旧knowledge/ディレクトリの共通ファイルを削除、シンボリックリンク更新	M層knowledge/	Step 2完了後に実施。参照先がshared/に切り替わっていることを確認してから
8	W層の空MEMORY.md・空_MANIFEST.md削除	W層
9	`agents/auditor/CLAUDE.md` 作成	新規追加	監査役のCLAUDE.md + agents.ymlへの登録
10	AI Opsから「CLAUDE.md整合性チェック」を削除、監査役に移管	AI Ops CLAUDE.md, 監査役CLAUDE.md

安全な移行: Step 1〜6は全て「追加のみ」で既存に影響しない。Step 7以降の削除は、新しい参照先が確実に機能していることを確認してから実施する。

トレードオフ・代替案の記録

判断ポイント	採用案	却下案と理由
監査役の実装形態	独立エージェント（agents/auditor/）	AI Ops拡張: 責務混在。M層自己チェック: 独立性なし
品質ゲートの管理	shared/一元化 + 各層カスタマイズ	現状維持: 更新漏れ。完全一元化: 文脈適応できない
knowledge.mdの配置	リポジトリルートに1ファイル	層別分割: 横断検索困難。agents/配下: ops/が漏れる
W層MEMORY.md	全削除	維持: 一時プロセスのため蓄積されても参照されない可能性大

MNML組織再設計 — 横断機能・ナレッジ管理 詳細設計書

A. 横断機能の設計

A1. 組織に必要な横断機能（MECE列挙）

A2. 監査役の責務定義

位置づけ

責務一覧

監査役の実装形態 — 比較検討

監査役の起動タイミング

A3. 横断品質管理の仕組み

比較検討: 品質ゲートの管理方式

品質ゲートの分類（共通定義ファイルの構成）

A4. 重複排除プロセスの具体的フロー

フロー概要

横断検索の対象と方法

共通資産化の判定基準

B. ナレッジ管理の設計

B1. CLAUDE.mdの役割再定義

現状の問題

再定義: CLAUDE.mdに書くもの・書かないもの

B2. knowledge/ディレクトリの移行計画

現行ファイルの棚卸と移行先

移行後のディレクトリ構成

B3. knowledge.mdのタグ体系設計

配置場所の検討

タグ体系

knowledge.md のフォーマット

B4. Issueへのナレッジ蓄積ルール

GitHub Issueのラベル体系

ナレッジIssueのテンプレート

ナレッジIssue運用ルール

B5. 検索・参照の仕組み

検索フロー

C. 全エージェントCLAUDE.md反映計画

C1. 共通原則の配置先

CLAUDE.md階層構造

新たに追記する共通原則

C2. 現行CLAUDE.mdから移動すべき内容

ルートCLAUDE.md

M層 CLAUDE.md

W層 CLAUDE.md

MEMORY.md（自動メモリ）

D. 前提条件・制約・移行スケジュール

前提条件

制約

移行ステップ

トレードオフ・代替案の記録

MNML組織再設計 — 横断機能・ナレッジ管理詳細設計書