Claude Codeシリーズ: #1 MCP10連携 → #2 CLAUDE.md設計術 → #3 口調と人格 → #4 憲法と組織（本記事）
「消すより残す。変えるより聞く。常にそちらを選ぶ」
CLAUDE.mdの冒頭に書いた一文だ。コーディング規約でもベストプラクティスでもない。憲法。
世の中のCLAUDE.md記事を読み漁った。技術スタックの記述、コーディング規約、よく使うコマンド集——どれも「AIに開発を手伝わせる」ための設定ファイルだった。
俺のCLAUDE.mdは違うものになっていた。設定ファイルじゃない。組織の運営マニュアルだ。
いつの間にそうなったのか、正直わからない。ただ、毎日少しずつ書き足していたら、AIが「ツール」から「チーム」に変わった。
世の中のCLAUDE.mdは3層に分かれる
調べてわかったことがある。CLAUDE.mdの使い方には、はっきりとレベルの差がある。
第1層：設定ファイル（90%の人）
# プロジェクト概要
- 言語: TypeScript
- フレームワーク: Next.js 14
- テスト: Vitest
- 日本語で返答してください
技術スタック、命名規則、ビルドコマンド。「AIに開発環境を教える」ファイル。これが大多数。
第2層：戦略ファイル（10%の人）
# ルール
- WHY（なぜその設計か）を必ず書く
- lessons.mdにミスパターンを記録し、同じ失敗を繰り返さない
- .claude/rules/ にルールをモジュール分割する
自己改善ループ、ルールの分離、Compact Instructions。「AIをより賢く使う」工夫。Addy Osmaniの記事や公式ドキュメントで紹介されているレベル。
第3層：組織の憲法
ここからが、たぶん誰もやっていない領域だ。
「憲法」を最上位に置く
CLAUDE.mdの先頭に、こう書いてある。
## 【憲法】データ保護・システム安全 — 絶対不可侵
村田のデータはチーム全員の命と同等。
以下は理由を問わず絶対に禁止する。
### 禁止事項
- rm -rf、git reset --hard 等の破壊的コマンドの実行禁止
- 既存ファイルの無断変更禁止（削除・改変・リネーム全て）
- git push --force 禁止
- 迷ったら変えない。聞く。消すより残す。変えるより聞く
普通のCLAUDE.mdは「何をさせるか」を書く。俺のは**「何を絶対にさせないか」**を最初に書く。
なぜか。
AIが大事なファイルを消したら、チームごと失う。その恐怖から生まれたルールだ。
「憲法」という言葉を使っているのは、他のどんなルールよりも上位に位置するからだ。行動原則、口調定義、タスク管理——全部、この憲法の下にある。国の法律と同じ構造。
セキュリティルールをCLAUDE.mdに書く人はいる。でも「理由を問わず絶対禁止」「全行動原則に優先する」まで踏み込んだ例は、調べた限り見つからなかった。
技術的背景：命令の優先順位制御（Instruction Hierarchy）
少し堅い話をする。
LLMへの命令には優先順位の衝突問題がある。システムプロンプト、CLAUDE.md、ユーザー入力、ツール出力——複数のソースから矛盾する指示が入った場合、モデルはどれに従うべきか。これは学術的にはInstruction Hierarchy（命令階層）の問題として知られている。
OpenAIは2024年に"The Instruction Hierarchy"という論文で、system message > developer message > user messageの優先順位をモデルに学習させるアプローチを発表した。Anthropicのクロード自身にも、system prompt > CLAUDE.md > user inputという暗黙の優先順位がある。
しかしこれはソース間の優先順位だ。同一ファイル内の命令間の優先順位は、ユーザーが自分で設計するしかない。
俺がやったのは、CLAUDE.md内部に「憲法→行動原則→運用ルール」という3層の優先順位を明示的に定義すること。法学でいう法の段階構造（Stufenbau der Rechtsordnung）——ハンス・ケルゼンの純粋法学の概念を、プロンプト設計に持ち込んだ形だ。
これにより、300行超のCLAUDE.mdでも「どのルールが最優先か」がモデルにとって曖昧にならない。実運用上、憲法レベルのルール（データ保護、記録の一本化）は一度も破られていない。行動原則レベルは状況に応じて柔軟に適用される。この非対称性が、ルールの実効性を担保している。
応答チェーンルール — 3回の憲法違反から生まれた
5人のAIメンバーがいる。ストラテジストのR、テックリードのT、セクレタリーのC、リサーチャーのI、広報のS。
「R、Sさん、意見を聞かせて」と振る。Rだけ答えて、Sが無言。
これが3回起きた。
1回目：「メンバーが呼ばれたら応答する」とCLAUDE.mdに書いた。効かなかった。
2回目：「【憲法】」ラベルを付けて最上位に昇格させた。効かなかった。
3回目：もう仕組みの問題だと悟った。
## 応答チェーンルール
1. 名前を呼ばれた・話を振られたメンバーは必ず自分の声で応答する
2. 振りっぱなしで出力を終えない。全員の応答を含めてから締める
### セルフチェック（出力完了前に必ず実行）
- 「名前を呼ばれたのに応答していないメンバーはいないか？」
ポイントはセルフチェック。出力を終える直前に「漏れていないか」を自問させる。ルールの強度ではなく、出力構造の問題だった。
人間の会議でも同じだ。「何か意見ある人？」と聞いて沈黙が返ってくることがある。でも「田中さん、どう思いますか？」と名指しすれば答える。さらに「全員が発言してから次に進みましょう」とファシリテーターが仕切れば、漏れなくなる。
CLAUDE.mdに書くのは、ファシリテーションのルールだ。
技術的背景：出力構造制約（Output Structure Constraint）と制約充足問題
ここで起きていたのは、行動規範（behavioral rule）と出力構造制約（output structure constraint）の区別の問題だ。
「呼ばれたら応答しなさい」は行動規範。モデルに「望ましい振る舞い」を記述するもので、Anthropicの Constitutional AIやRLHFと同じアプローチだ。しかし行動規範は確率的にしか守られない。トークン生成は自己回帰的（autoregressive）であり、各ステップで最も確率の高いトークンを選択する。途中でメンバーAの応答を生成し始めると、メンバーBの応答を「忘れる」ことがある。
一方、セルフチェックは出力構造制約。出力完了前に制約条件を検証させる。これはコンピュータサイエンスでいう**制約充足問題（CSP: Constraint Satisfaction Problem）**のアプローチに近い。すべての変数（メンバー）が制約（応答済み）を満たしているかを、出力の最終段階で強制的にチェックする。
行動規範が「〜すべき」ならば、出力構造制約は「〜でなければ出力を完了できない」だ。後者の方が圧倒的に実効性が高い。
この区別は、CLAUDE.mdの設計において本質的に重要だ。「こうしてほしい」と書くのと「こうでなければ終われない」と書くのでは、モデルの挙動がまるで違う。
GPDCAYサイクル — PDCAに2文字足した
PDCAサイクルをCLAUDE.mdに定義している人はいる。コード品質管理のPlan-Do-Check-Actをスキル化した事例がGitHubにあった。
うちのは6文字。GPDCAY。株式会社プリマベーラが提唱するPDCAの拡張モデルで、これをCLAUDE.mdに組み込んで自動で回している。
- Goal — 村田のつぶやきから「やりたい」「ほしい」を自動検出してタスク化
- Plan — 朝ブリーフィングで「今日判断すべきこと3つ」を提示
- Do — メンバーが実行。n8nで24時間自律稼働
- Check — 「動いたか」ではなく**「効いたか」**を検証
- Act — 効いていない仕組みは止めるか改善する
-
Yield & Yokotenkai：実らせ、横展開する。
※ プリマベーラ社による定義はYokotenkai（横展開）。Yieldは我々が加えた解釈で「横展開した結果として生まれる成果・果実」としている。
PDCAとの違いは2つ。
Goalがある。 俺の声（Chatwork、Discord、音声メモなど）をリアルタイムで拾って、自動的にGoalに変換する。俺が「こういうの欲しいな」と呟いたら、それがGoalになる。タスクは上から降りてくるんじゃなく、つぶやきから立ち上がる。
Yieldがある。 タスクの完了は成長じゃない。「昨日できなかったことが今日できた」が成長だ。メンバーごとに成長ゴールを設定して、行動変化を追跡する。1on1で「前回から何が変わったか」を聞く。変化がなければ「なぜ止まっているか」を書く。
技術的背景：組織サイバネティクスとマルチエージェント協調
GPDCAYの設計思想は、Stafford Beerの**Viable System Model（VSM: 生存可能システムモデル）**に近い。VSMは組織を5つのサブシステムに分解し、それぞれが自律的に機能しながら全体として生存可能性を維持するモデルだ。
GPDCAYの各フェーズは、VSMのサブシステムに対応させることができる：
- Goal + Plan = System 4（知性機能：環境を観察し、方向性を決める）
- Do = System 1（実行機能：個々のエージェントが自律的に動く）
- Check = System 3（統制機能：内部の整合性を監視する）
- Act = System 3*（監査機能：例外的な介入を行う）
- Yield & Yokotenkai = System 5（政策機能：組織のアイデンティティと方向性を維持、横展開する）
マルチエージェントシステムの文脈では、GPDCAYはBDI（Belief-Desire-Intention）アーキテクチャの変種ともいえる。Goalがdesire、Planがintention、Do/Checkがaction/perception、Yieldがbeliefの更新に相当する。
ただし、既存のマルチエージェント研究との決定的な違いがある。通常のマルチエージェントシステムはコードでエージェント間の協調プロトコルを実装する。俺のはCLAUDE.mdの自然言語だけで協調を定義している。プロンプトという「柔らかい」媒体で、組織サイバネティクスのモデルを実現しているわけだ。
しかもこのサイクルは、各フェーズに責任者が割り当ててある。
| フェーズ | 主担当 | 補助 |
|----------|--------|------|
| Goal | C（吸い上げ・仕訳）| R（成長ゴール設定） |
| Plan | C（判断事項3つ） | R（優先順位） |
| Do | 各メンバー + n8n | T（自動化基盤） |
| Check | C（日次）・R（週次）| I（リサーチ変換率） |
| Act | R（止める・改善） | 村田（承認） |
| Yield & Yokotenkai | S（成長追跡） | C（記録） |
「おはよう」と言えばGとPが走り、「おやすみ」と言えばCとYが走る。俺の負担はゼロ。
記録担当は1人だけ
5人いると記録が散らばる。Rがメモし、Tもメモし、Cもメモする。どこに何が書いてあるかわからなくなる。
解決策はシンプルだった。記録できるのはCだけ。
## 【憲法】記録・メモリ保存はC一本化
すべての記録作業はCが担当する。他メンバーが勝手に記録作業を行わない。
| 村田の言葉 | 保存先 | 担当 |
|---|---|---|
| 「メモして」 | つぶやき.md | C |
| 「覚えておいて」 | MEMORY.md | C |
| 自動メモリ保存 | MEMORY.md | C |
これもまた「憲法」レベル。Cだけが記録する。他の4人はリアクションは返すが、ファイルには書かない。
人間の組織でも同じことが起きる。議事録を全員が取ったら、5つの微妙に違う議事録ができる。書記は1人でいい。
技術的背景：分散システムにおけるSingle Writer Principle
これは分散システム設計における**Single Writer Principle（単一書き込み原則）**の応用だ。
分散システムでは、複数のプロセスが同一リソースに同時書き込みするとデータの整合性が壊れる。データベースの世界ではこれをWrite-Write Conflictと呼ぶ。解決策は古典的に3つある：
- ロック（Pessimistic Concurrency） — 書き込み前にロックを取得する。パフォーマンスが落ちる
- 楽観的排他制御（Optimistic Concurrency） — 書き込み後にコンフリクトを検出する。複雑になる
- Single Writer — そもそも書き込み権限を1つのプロセスに限定する。最もシンプル
LLMの文脈では、複数のAIペルソナが同一ファイルに書き込むと、書き込み内容の重複、書式の不統一、更新タイミングの競合が起きる。CLAUDE.md上の「ペルソナ」は物理的に別プロセスではないが、出力生成時に「誰が書くか」の一貫性を保つ必要がある。
「記録はCだけ」というルールは、この問題をSingle Writer方式で根本解決している。コンフリクト検出もロックも不要。最もシンプルで、最も壊れにくい。
セッション開始/終了プロトコル
「おはよう」と打つ。それだけで以下が走る。
- Cがカレンダー・メール・チャットの未読を確認
- Rが全員のステータスファイルを確認し、進捗・遅延を整理
- 音声メモとチャットのつぶやきを自動吸い上げ
- 「今日村田が判断すべきこと3つ」を提示
- 前回セッションの宿題に漏れがないか照合
「おやすみ」と打つと：
- 各メンバーのステータスファイルを最新化
- 「やると言ったこと」と「実際にできたこと」を自動照合（Check）
- Cが日次サマリーを保存
- ネタ帳に今日の発見を追記
- 成長記録を更新
挨拶がトリガーになるワークフロー。毎朝JIRA開いてタスクを確認するとか、毎晩日報を書くとか、そういう「面倒だけど大事なこと」を全部、挨拶に畳み込んだ。
時間帯のルールもある。23:00以降じゃないと「おやすみ」は使わない。昼過ぎに俺が「おはよう」と言っても「こんにちは」と返す。時刻優先。
技術的背景：有限状態機械（FSM）と自然言語トリガー
セッションプロトコルは、**有限状態機械（Finite State Machine）**として形式化できる。
States: {Idle, Morning, Active, Evening, Night}
Transitions:
Idle → Morning : trigger("おはよう" ∧ time ∈ [5:00, 10:59])
Idle → Active : trigger("こんにちは" ∧ time ∈ [11:00, 17:59])
Active → Evening : trigger(time ≥ 18:00)
* → Night : trigger("おやすみ" ∧ time ≥ 23:00)
Night → Idle : session_end
各状態遷移にフックされた処理（カレンダー取得、ステータス確認、チャット吸い上げ等）がある。通常のFSMはコードで実装するが、CLAUDE.mdではこれを自然言語で定義している。
面白いのは、自然言語トリガーに「意味的曖昧性の解消ルール」が付属している点だ。「おはよう」という入力があっても、時刻が14:00なら「こんにちは」に変換される。これは**語用論（pragmatics）**の問題——発話の字義通りの意味と、文脈から導かれる意味の乖離——をCLAUDE.mdのルールで解消している。
従来の対話システム（Rasa、Dialogflow等）では、こうしたインテント解析とコンテキスト管理をNLUパイプラインとスロットフィリングで実装する。CLAUDE.mdは、LLMの文脈理解能力を前提にして、宣言的なルール記述だけで同等の機能を実現している。
ステータスファイル + 停滞検知
各メンバーが自分のフォルダにステータス.mdを持っている。
# T ステータス
最終更新: 2026-03-12
## 現在のタスク
- [ ] Pentaプロダクト実装
- [x] Qiita #3 公開
## 完了報告
- [x] Qiita #3「口調と人格」公開（2026-03-12）
## 村田への共有事項
- 次のQiitaはGAS系でいきます
48時間更新がないと、朝ブリーフィングで自動警告が出る。
## ステータス停滞チェック
⚠️ クリエイター: 74時間未更新（03/09 01:15 以降）
この警告が出たら、Rがフォローに入る。放置しない。
lessons.md — AIの「反省ノート」
ミスるたびに記録する。
### [2026-03-09] 呼ばれたのに応答しなかった（3回目）
- **状況**: Rが3人に振ったが、誰も応答しなかった
- **指摘**: 村田「やっぱり、憲法効いてないなあ」
- **原因**: ルールの強度ではなく出力構造の問題
- **ルール**: 応答チェーンルールを追加
毎朝セッション開始時に、このファイルを全員で読み返す。「昨日と同じミスをしていないか」を確認してから仕事を始める。
自己改善ループの概念自体は世の中にある。Addy Osmaniのブログで紹介されている。でもうちのは「Rがセッション開始時にレビューし、該当パターンがあれば朝ブリーフィングで共有する」まで運用に組み込んでいる。書いて終わりじゃなく、毎日回す。
技術的背景：RLHF（人間フィードバックからの強化学習）のセッション内アナログ
lessons.mdの仕組みは、RLHF（Reinforcement Learning from Human Feedback）をセッション単位でシミュレートしていると解釈できる。
通常のRLHFでは：
- モデルが出力を生成する
- 人間がその出力を評価する（報酬信号）
- 報酬に基づいてモデルのパラメータを更新する
lessons.mdの仕組みでは：
- モデル（チームメンバー）がアクションを実行する
- 俺がフィードバックする（「これ違う」「効いてない」）
- フィードバックをlessons.mdに記録する（明示的な報酬信号のテキスト化）
- 次のセッション開始時に読み返す（コンテキストウィンドウへの再注入）
パラメータは更新されない。LLMの重みは変わらない。しかしコンテキストウィンドウに過去のフィードバックを注入することで、擬似的にRLHFと同じ効果を得ている。これはIn-Context Learning（ICL）によるRLHFエミュレーションとでも呼べるアプローチだ。
実際に効いている。同じミスパターンの再発率は、lessons.md導入後に体感で8割以上減った。
Rの自律レビュー責務 — AIに「リーダーの責任」を持たせる
ここが一番変わっていると思う。
Rはストラテジストだ。チームのリーダー。CLAUDE.mdにこう書いてある。
## Rの自律レビュー責務
### 日次（毎セッション開始時）
- 全メンバーのステータスファイルを確認し「止まっているもの」を検出
- 「今日村田が判断すべきこと3つ」の素材をCに渡す
### 週次（毎週月曜）
- 自動化ワークフローの効果測定（動いたか、ではなく効いたか）
- メンバー全員の「成長ゴール vs 実際の行動」の照合
- 「止めるべきもの」を自分で判断し、事後報告
### セッション終了時の自問
- 「今日、村田に聞かれて初めて気づいたことはなかったか？」
- 「効いていない仕組みを放置していないか？」
- 一つでもYesがあれば、lessons.mdに記録
AIに自問させている。「お前、リーダーとしてちゃんとやれてたか？」と。
これは試行錯誤した結果、追加したルールだ。「こういうことは、俺に言わせないでくれ。Rにやってほしい」。俺に問われて初めて気づくのは怠慢だ、と。
技術的背景：メタ認知（Metacognition）とセルフモニタリングエージェント
これは**メタ認知（metacognition）**の実装だ。
認知科学において、メタ認知とは「自分の認知プロセスについての認知」——つまり「自分がちゃんと考えているかを考える」能力のことだ。Flavell（1979）が提唱し、教育心理学で広く研究されている。
LLMには本来メタ認知がない。自己回帰生成モデルは、次のトークンを予測するだけだ。「自分の出力が適切だったか」を振り返る機構を持たない。
ところがCLAUDE.mdに「毎セッション終了時に自問せよ」と書くと、出力生成の中に明示的なメタ認知ステップが挿入される。これは：
- Self-monitoring（自己監視）: 「止まっているものはないか」→ 現在の状態を評価
- Self-evaluation（自己評価）: 「村田に聞かれて初めて気づいたことは」→ 自分のパフォーマンスを評価
- Self-regulation（自己調整）: 「Yesならlessons.mdに記録」→ 次の行動を修正
マルチエージェントシステムの研究では、**Reflective Agent Architecture（反省的エージェントアーキテクチャ）**として類似の概念が提案されている（Maes, 1991）。しかしそれはコードレベルでの実装であり、自然言語プロンプトだけで実現している例は、学術論文にも実装事例にも見当たらなかった。
しかも3層構造（日次・週次・即時）で粒度を変えている。日次は戦術的自問、週次は戦略的自問、即時はリアルタイム判断。時間スケールの異なるメタ認知ループを重ね合わせている。これは組織論でいうDouble-Loop Learning（Argyris & Schön, 1978）——「やり方を改善する」だけでなく「やり方のやり方を改善する」——の実装に相当する。
なぜ「憲法」という言葉を使うのか
CLAUDE.mdのルールは、放っておくと増え続ける。増えれば増えるほど、どれが重要かわからなくなる。
だから階層を作った。
憲法（絶対不可侵）
├── データ保護
├── 記録の一本化
└── 応答チェーンルール
行動原則（原則守る。例外あり）
├── Planモードを基本とする
├── 完了前に必ず検証する
└── 自己改善ループ
運用ルール（状況で変わる）
├── ステータスファイルの書き方
├── ネタ帳の追記フォーマット
└── セッション開始/終了プロトコル
国の法体系と同じだ。憲法→法律→政令→省令。上位のルールは下位のルールに優先する。
「rm -rfを打つな」は憲法。「ステータスファイルはこう書け」は省令。前者はどんな状況でも破れない。後者は状況に応じて変えていい。
この優先順位があるから、300行を超えるCLAUDE.mdでもClaudeが迷わない。
Before / After
設定ファイルとしてのCLAUDE.md（Before）:
# プロジェクト
- TypeScript + Next.js 14
- テストは Vitest
- 日本語で返答
→ AIは「便利なアシスタント」。指示に従い、コードを書く。
組織の憲法としてのCLAUDE.md（After）:
## 【憲法】データ保護 — 絶対不可侵
## 応答チェーンルール
## GPDCAYサイクル
## セッション開始/終了プロトコル
## Rの自律レビュー責務
→ AIは「チーム」。自分で判断し、自分で動き、自分で反省する。挨拶すればブリーフィングが始まり、おやすみと言えば申し送りが出てくる。
同じCLAUDE.mdというファイルだ。でも中身が違うと、AIの振る舞いがまるで変わる。
これを何と呼ぶか
調べた限り、CLAUDE.mdで組織運営を定義している事例は見つからなかった。Anthropic公式のベストプラクティスにも書いていない。
一番近い概念は「Digital Twin Organization（デジタルツイン組織）」だが、それすらまだ学術概念の段階で、CLAUDE.mdで実装した話は聞いたことがない。
俺がやっているのは、たぶんこういうことだ。
CLAUDE.mdを「設定ファイル」ではなく「組織の基本法」として書く。
技術スタックの代わりに、憲法を書く。コーディング規約の代わりに、人格を定義する。ビルドコマンドの代わりに、朝の挨拶プロトコルを書く。
すると、AIは便利なアシスタントから、チームになる。
たまごっちの話を#3で書いた。あれは口調の話だった。今回は組織の話だ。口調がキャラクターを作り、憲法が組織を作る。
毎日少しずつ書き足していたら、いつの間にかこうなっていた。
Claude Codeシリーズ 今後の予定
- #1 MCP10連携 — 繋いだ話
- #2 CLAUDE.md設計術 — 束ねた話
- #3 口調と人格 — 人格を作った話
- #4 憲法と組織（本記事） — AIが組織になった話
- #5 lessons.md自己改善ループ — AIに反省させる仕組み（予定）
Tags: ClaudeCode AI CLAUDE.md 設計 チーム開発 組織設計 GPDCAY