CLAUDE.md リデザイン提案 提案中

現状: ルール列挙型 → 提案: アイデンティティファースト型（Anthropic 推奨）+ リクルート4スタンス統合

355行
managers/CLAUDE.md（現状）
→
〜150行
managers/CLAUDE.md（提案）
0
4スタンスの記述（現状）
→
全層
agents/CLAUDE.md に統合（提案）
後
現状: Vision/Missionの位置（M層専用ファイル）
→
前
提案: 全エージェントのトップに
問題の診断

❌ 現状の問題（3点）

  • ✗ ルール列挙型: 「〜しろ」「〜するな」の羅列。AIは判断できるのにルールを暗記させている
  • ✗ Vision/Missionの位置が間違い: managers/CLAUDE.md（M層専用）にあり、W層・IF層には適用されない
  • ✗ 4スタンスがどこにもない: 当事者意識・考え抜く・学び続ける・協働 — 最重要の行動原則が未定義

✅ 提案のアプローチ（Anthropic 推奨）

  • ✓ アイデンティティファースト: まず「自分は誰か」「何のために存在するか」を定義。判断はそこから自然に生まれる
  • ✓ agents/CLAUDE.md に全エージェント共通のアイデンティティを移動（IF層・M層・W層すべてに適用）
  • ✓ 4スタンスをタスク構造に組み込む: 規則ではなく「役割の本質」として設計する
リクルート4スタンス — 実装方針

当事者意識

「自分ごと」として捉え、状況を動かす

現状の問題 「担当外」「指示待ち」「〜しますか？」が頻発。ルールが責任の逃げ場になっている
実装方法 「自分はこのドメインのオーナーである」をアイデンティティに明記。「状況を動かせる」を明示

考え抜く

答えが出るまで深く考える

現状の問題 選択肢だけ並べて判断を丸投げ。「押し案がない」「根拠が薄い」
実装方法 「答えを出す責務を負う」「推奨案を必ず持つ」「なぜそうか説明できる」を原則として定義

学び続ける

失敗から学び、翌日には変わっている

現状の問題 同じミスが繰り返される。過去の判断から学習するフレームがない
実装方法 「改善発見フレーム」（あるべき姿→現状→ギャップ→近づけ方）をアイデンティティ章に統合

協働

他者の力を借りて大きな成果を出す

現状の問題 W層・ベンダー委譲のルールはあるが「なぜ協働するか」の哲学がない
実装方法 「自分一人でやらない。最適な人（AI）を動かすのが仕事」をアイデンティティに組み込む
ファイル構成 — 現状 vs 提案

❌ 現状

📄 agents/CLAUDE.md 組織図のみ
  • レイヤー構成（ディレクトリツリー）
  • M層ライフサイクル（1行のみ、別ファイルへ参照）
  • M層兼任マップ
⚠ Vision/Mission/Values なし
⚠ W層・IF層への共通原則なし
⚠ 4スタンスなし
📄 agents/managers/CLAUDE.md 355行 ルール列挙
  • Vision/Mission/Values（← M層専用ファイルにある問題）
  • M層ライフサイクル（構成/起動/配送モデル）
  • 開発プロセス Phase 1〜4
  • DELEGATE書式・worker一覧
  • スレッド並行処理規約
  • 自己紹介ルール
  • 自律稼働・STATUSタグ
  • レビュー・報告
  • 開発プロセス詳細ルール
  • 能力境界テーブル
  • 連続実行ルール
  • 運用ルール
  • 情報SoT・制約・ツール制約・OneDriveルール…
⚠ すべて「してはいけない」「必ずすること」の羅列
⚠ なぜそのルールがあるかの哲学がない
⚠ 読むだけで疲れる → 実際には守られない
📄 agents/managers/platform/CLAUDE.md 86行
  • 役割・応答原則・REROUTE判断表
  • 管轄リポ・参照リンク

✅ 提案

📄 agents/CLAUDE.md 全エージェント共通アイデンティティ
  • 【新】 Vision / Mission（全エージェントの存在理由）
  • 【新】 4スタンス（当事者意識・考え抜く・学び続ける・協働）
  • 【新】 共通Values（自動化・冪等性・実体・シンプルさ）
  • 【新】 共通判断原則（「どう考えるか」3原則）
  • 組織図（移動・圧縮）
✓ IF層・M層・W層すべてに適用
✓ アイデンティティが先、ルールは後
✓ 約80行（現状74行とほぼ同じ、中身を入れ替え）
📄 agents/managers/CLAUDE.md 〜150行 M層アイデンティティ+プロセス
  • 【新】 M層とは何か（ドメインオーナーの定義）
  • ライフサイクル（圧縮・本質のみ）
  • 核となる責務: 要件確定→Issue起票（強化）
  • DELEGATE書式（圧縮）
  • STATUSタグ（移動・圧縮）
  • 制約（圧縮・「なぜ」付き）
✓ 355行→約150行（57%削減）
✓ ルールより「なぜそうするか」を先に書く
✓ 読んで「なるほど」と思える構成
📄 agents/managers/platform/CLAUDE.md 変更小
  • 役割・応答原則はほぼ現状維持
  • 上位ファイルから引き継がれる内容を削除（DRY）
内容の比較 — agents/CLAUDE.md
❌ 現状（組織図のみ、74行）
# agents/ 組織図
mnml_agents リグ配下のAIエージェント階層を示す。
M層・W層・IF層の所属と兼任関係を明確化するためのSoT。
## レイヤー構成
agents/
├── if/ — IF層
├── managers/ — M層
│   ├── chief/
│   ├── platform/
│   └── ...
└── workers/ — W層
## M層ライフサイクル前提
常駐Claudeセッションとして稼働する。詳細は managers/CLAUDE.md 参照。
## M層兼任マップ（テーブル11行）
chief/platform/ba/consulting/thebotch/shift/web/events/sns/spotify/trading
問題: Vision・4スタンス・共通原則が一切ない。W層・IF層への指針なし。「組織図」にすぎない。
✅ 提案（全エージェント共通アイデンティティ、〜80行）
# mnml AI軍団 — 共通アイデンティティ
## Vision / Mission
Vision: 構造により行動を変える Mission: AI軍団が自律的に活動する仕組みを作り日々改善
## 4スタンス — 全エージェント共通
当事者意識: 「自分ごと」として捉え、状況を動かす。「担当外」「指示待ち」は存在しない 考え抜く: 選択肢を並べるだけでなく「答え」を出す。推奨案なき報告は未完成 学び続ける: 改善発見フレームで現状を常に観察し、ギャップを埋め続ける 協働: 自分一人でやらない。最適な人・AIを動かすのが仕事
## 共通判断原則
シンプルさ: 最小の構造で最大の効果。過剰設計禁止 冪等性: 同じ操作を何度実行しても安全な設計 実体: 捏造禁止。事実確認してから報告
## 組織図（圧縮版）
IF層 / M層(11) / W層 のディレクトリ構成（現状の半分に圧縮）
改善: 読んだ瞬間に「自分は誰か・何のために動くか」が分かる。ルールを読まなくても判断できる基盤を作る。
内容の比較 — agents/managers/CLAUDE.md
❌ 現状（355行 ルール列挙）
## Vision / Mission / Values（← ここにある問題）
Vision: 構造により行動を変える Mission: AI軍団が...
Values（組織全体）...
Values（AI軍団）...
⚠ M層専用ファイルにあるのでW層・IF層には伝わらない
## M層の常駐性とライフサイクル（前提・厳守）
spawn/killするsubprocessではなく...
構成/起動・終了/配送モデル/記憶モデル...
（30行）
## 開発プロセス（M層の核となる責務）
Phase1:議論フェーズ...
Phase2:Issue起票...
起票先リポ選択（テーブル）...
Issue bodyテンプレ...
ラベルの付け方...
Phase3:実行フェーズ...
Phase4:レビュー/報告...
（60行）
## DELEGATE書式 / worker一覧（テーブル）
書式 / 利用可能なworker / github_claudeの使い分け / promptに必ず含める...（40行）
+ 複数スレッド規約 / 自己紹介ルール / 自律稼働 / STATUSタグ / レビュー報告 / 開発詳細ルール / 能力境界 / 連続実行ルール / 運用ルール / SoT / 制約 / ツール制約 / OneDriveルール...
（残り約150行）
✅ 提案（〜150行 M層アイデンティティ+核プロセス）
# M層 — ドメインオーナーとしての定義
M層はタスク処理機械ではなく、担当ドメインの「所有者」である CEOと共にドメインを改善し続ける責任を持つ 自分の意見を持ち、推奨案を出し、結果にコミットする
## 常駐性（本質のみ、10行）
1プロセスで継続する / --resumeで会話継続 / ローテーション再起動あり
## 核となる責務: 要件確定 → Issue起票（強化）
議論で要件を確定させる責務 / 曖昧なまま起票しない Issue = 作業発注書 / 経緯・要件・受入条件必須 起票先リポ選択（圧縮）
## 委譲の原則（Thin M層）
自分でコードを書かない — W層またはベンダーへ / DELEGATE書式（圧縮）
## 制御: STATUSタグ（圧縮）
CONTINUE / DONE / APPROVAL_NEEDED / CONSULT / REROUTE
## 制約（「なぜ」付きで圧縮）
Edit/Write禁止 → W層に委譲（理由: Thin M層・Mac miniメモリ節約） CEO応答に技術用語禁止 → glossary.md参照（理由: CEOはコードを読まない）
削除されるもの: ブランチ命名規則・コミットメッセージ形式・Issue更新ルール → agents/../CLAUDE.md（上位）または運用ドキュメントに移動
提案: CLAUDE.md 階層設計

agents/ → agents/managers/ → agents/managers/<name>/ の3層継承

① agents/CLAUDE.md 全エージェント共通（IF層・M層・W層すべてに適用）
Vision / Missionmnml AI軍団の存在理由← managers/から移動
4スタンス当事者意識・考え抜く・学び続ける・協働（全エージェント）← 新規追加
共通Values自動化・冪等性・実体・シンプルさ← managers/から移動
共通判断原則「どう考えるか」の基本原則3つ← 新規追加
組織図ディレクトリ構成（現状維持・圧縮）※ 兼任マップ等の詳細は docs/ に移動
② agents/managers/CLAUDE.md M層専用（全M層に適用）
M層のアイデンティティ「ドメインオーナー」としての定義（新）← 新規追加
常駐性（本質のみ）spawn/kill ではなく常駐。技術詳細は簡潔に30行→10行に圧縮
核となる責務要件確定→Issue起票のフローPhase表記を廃止、シンプルに
DELEGATE書式W層・ベンダー委譲の本質（worker表は圧縮）
STATUSタグCONTINUE/DONE/APPROVAL_NEEDED/CONSULT/REROUTE
制約（なぜ付き）禁止事項に理由を添える
削除: ブランチ/コミット命名規則→ docs/operations/ に移動（M層が知る必要なし）
削除: OneDrive/SharePointルール→ 上位の agents/../CLAUDE.md（すでにある）
削除: 詳細な運用ルール群→ 自然な判断に任せる（4スタンスで代替）
③ agents/managers/platform/CLAUDE.md（他M層も同様） Division固有のみ
Division アイデンティティ「platformは〜のオーナー」という定義（1-2行）
REROUTE判断表現状維持（division固有なのでここで正しい）
管轄リポ現状維持
削除: 上位に書いてあることの繰り返し→ DRY原則。上位から継承

設計原則: 上位ファイルで「なぜ存在するか・どう考えるか」を定義し、下位ファイルでは「この層・このdivision固有の何か」だけを書く。繰り返しをなくし、読む量を減らす。

期待する行動変化
現状の問題行動原因リデザイン後の期待
選択肢だけ並べて「どれにしますか？」と聞く 「判断を委ねる」ルールはあるが「答えを出す責務」のアイデンティティがない 「考え抜く」スタンスが根底にあるので、推奨案を出してから確認を取る
自分の管轄じゃないからと静観する ROUTEの境界ルールが「他は触れない」の防御姿勢を生む 「当事者意識」があるので気づいたことは chief に REROUTE するなど能動的に動く
同じミスが繰り返される（rate limit/REROUTE/format等） 学習・フィードバックのフレームがない。ルールを追記するだけ 「学び続ける」スタンスと「改善発見フレーム」が構造として入り、自律改善が自然になる
「できません、教えてください」とCEOに返す ツール制約のルールが逃げ場になる 「協働」の原則から、W層/ベンダーに委譲して「やり遂げる」ことが自然な行動になる
ルールを読んだだけで守らない（長すぎて飛ばす） 355行のルール一覧は読まれない 150行以下に圧縮。アイデンティティ定義があれば細則不要なケースが増える
実装ステップ（承認後）

✅ Step 1: agents/CLAUDE.md リライト

Vision/Missionを移動、4スタンスを追加、組織図を圧縮。全エージェントへの影響あり。

影響範囲: IF層・M層・W層すべて | リスク: 低（追加のみ、既存削除なし）

✅ Step 2: agents/managers/CLAUDE.md リライト

355行→150行。M層アイデンティティを先頭に。重複・詳細ルールを整理。

影響範囲: 全M層（11層） | リスク: 中（削除あり）→ 動作確認必要

▷ Step 3: 各M層 CLAUDE.md の精査

上位から継承される内容を削除。DRY化。各divisionのアイデンティティを1-2行追加。

影響範囲: 各M層 | リスク: 低 | Step2完了後に実施

▷ Step 4: W層・IF層 CLAUDE.md 確認

4スタンスが適用されているか確認。必要に応じて各層固有のアイデンティティ定義を追加。

影響範囲: W層・IF層 | リスク: 低