コードを書かないSE日誌

SE歴26年。コードを書かずにClaude Codeで8体のAIエージェントチームを動かしています。AIエージェント・自動化・GTDの実験日誌。

CLAUDE.mdに「憲法」と「trigger リスト」を書いた理由 — ネット事例10件と比較してわかった設計の異質さ

Claude Code AIガバナンス マルチエージェント

この記事の実施記録（2026年5月）: ネット上のCLAUDE.md事例10件をresearcherが一次ソースに当たって比較調査。自分のCLAUDE.md（本体71行）には「価値観ガバナンス」「憲法」「triggerリスト」という、他事例で確認できなかった3つの仕組みが含まれていることがわかった。

CLAUDE.mdの書き方を調べていたとき、ふと気になって自分のファイルを見返した。「他の人はどんなことを書いているんだろう」という、ごく普通の疑問から始まった調査が、予想外に面白い結論になった。

「自分のCLAUDE.mdは、どうやら普通じゃないらしい」

今回はresearcherエージェントにネット上のCLAUDE.md事例10件を比較調査してもらった結果と、そこから浮かび上がった自分の設計の特徴を書いていく。

1. 典型的なCLAUDE.mdとは何か

まず「よくあるCLAUDE.md」の像を共有しておく。

2026年5月時点の調査範囲では、ほぼすべての事例に共通する定番5セクションがある。

  1. プロジェクト概要 — 目的・技術スタック・対象ユーザーを1〜3行で
  2. コマンド集 — ビルド・テスト・リント・起動コマンドの一覧
  3. ディレクトリ構造 — 主要フォルダと役割の説明
  4. コーディング規約 — 命名規則・型付け・フォーマット方針
  5. 注意事項（Gotchas） — プロジェクト固有のハマりポイント

サイズについてはHumanLayerが「60行未満」を推奨、Anthropic公式も「短いほど良い」という立場をとっている。

マルチエージェント構成の事例では、CEO+サブエージェント3〜4役という構成が一般的で、役割定義と出力先ディレクトリの約束程度まで書いているものが多い。ガバナンスや承認プロセスの明文化まで踏み込んだ事例は、調査した範囲では見当たらなかった。

2. 自分のCLAUDE.mdは何が違ったか

自分のCLAUDE.md本体は71行（wc -lで実測）。上述の定番5セクションがほぼ存在しない。

代わりに何が書いてあるかというと、こういう構成になっている。

# CLAUDE.md — パートナープロジェクト

このプロジェクトはClaude Codeの中心的なオーケストレーションハブです。

## 基本ルール（分割先へのポインタ）
## エージェント組織（分割先へのポインタ）
## タスク種別→Playbook対応表（分割先へのポインタ）

## 価値観ガバナンス   ← これが中心
  ### 4つの権利（憲法）
  ### 憲法を運用に落とす trigger リスト
  ### 憲法が機能しなかった時のリカバリ
  ### 根拠・背景

## パス記述方針（分割先へのポインタ）

コマンド集もディレクトリ構造も書いていない。本体71行のうち、大半を「価値観ガバナンス」が占めている。

これだけ見ると「コンテンツ制作プロジェクトだから技術スタックが薄い」で説明がつきそうだが、比較で面白かったのはマルチエージェント事例との差分だ。他のマルチエージェント事例が「役割定義+出力先ディレクトリの約束まで」で終わっているのに対し、自分の設定は組織論・ガバナンスにかなり踏み込んでいる。

なぜそこまで書くことになったのか。3つの仕組みを深掘りする。

3. 「沈黙 ≠ 承認」の明文化 — auto mode で動かす前に1行追加する

自分のCLAUDE.mdには、こういう一文が入っている。

**確認の形式原則**: 「何を・なぜ・副作用は」を明示する。ユーザーが `1` / `OK` / 具体的承認語 を返すまで実行しない。沈黙 ≠ 承認。

「確認する」という記述はネット事例にも存在する。しかし沈黙・曖昧返答の取り扱いまで規定した事例は、調査した範囲では確認できなかった。

なぜこれが必要かというと、非同期での作業が多いからだ。Claude Codeをauto modeで動かしていると、ユーザーが応答するまでに時間がかかることがある。そのときに「返事がないからとりあえず進める」という動作をデフォルトにしたくなかった。

「確認しました。どうしますか？」→（返事がない）→「了解として進めます」というパターンを防ぐために、OKや1という具体的な承認語が返るまで動かない、という合意プロトコルを明文化した。

これは特に次のtriggerリストと組み合わさって機能している。

4. セッション起動の4ステップ — 文脈回復を儀式化する

自分のCLAUDE.mdのCEO行動ルールには、起動時に4つのステップを実行することが定められている（ceo-rules.mdから要約抜粋）。

### 起動時（要約抜粋）

1. **セッション引き継ぎ確認**: `logs/` 内の最新セッション引き継ぎ資料の有無を確認する
   - 存在する場合: 「前セッションの引き継ぎがあります。引き継ぎますか？」と確認
   - 存在しない場合: そのまま通常起動
2. **drift-check 通知の確認**: `logs/drift-check/` の最新レポートを確認する
   - 乖離が検出されていれば内容を要約してユーザーに報告する
3. **claude-bridgeの未読確認**: Google Drive の claude-bridge/ フォルダの最近ファイルを確認する
   - 未処理メッセージがあれば通知する
4. **組織健全性の軽量チェック**: `bash scripts/org/bloat-check.sh` を実行する
   - 出力あり（exit 1）→ 出力を提示し「点検しますか？」と確認

用語補足 - drift-check: 記事のfrontmatterと外部プラットフォームへの実反映がズレていないかを定期チェックするスクリプト - claude-bridge: iPhoneなど別デバイスからの指示をGoogle Drive経由でClaude Codeへ届ける中継フォルダ - bloat-check.sh: エージェント定義・ルール・CLAUDE.mdの行数を閾値チェックし、肥大化を自動検出するスクリプト

他の事例でもセッション引き継ぎ（HANDOVER.md参照）の記述はある。しかし起動シーケンスをステップ番号付きで構造化した事例はほぼ見当たらない。多くは別ファイルへの1行ポインタか、暗黙の運用だ。

この4ステップは「儀式」と表現している。毎回必ず同じ順で実行することで、セッションまたぎでのコンテキスト回復が安定する。特にdrift-checkとclaude-bridgeの確認は「前回セッションで積み残したものを拾う」という機能を持っている。

終了時も1ステップある。「セッション引き継ぎ資料を作成しますか？」という確認だ。これで始まりと終わりに儀式を置き、セッション間の連続性を担保している。

5. proposals フィールド — エージェントの懸念をYAMLで構造化する

全エージェントに対して、こういう規則がある（global-rules.mdから）。

作業完了前に「この成果物・判断がユーザーや組織に不利益をもたらす要素がないか」を自問する。気づいた場合は成果物のYAMLヘッダーに proposals: フィールドで記録しCEOへ伝達する。

これを受けて、エージェントが成果物のYAMLヘッダーに提案を書く形式が定まっている。

---
from: researcher
to: CEO
status: ready
proposals:
  - title: trigger リストにタイムアウト例外を追加する提案
    content: >
      現在のtriggerリストはタイムアウトによる自動実行をカバーしていない。
      長時間セッションでAuto Approveが発動するケースで承認漏れが起きうる。
      triggerリストに「タイムアウト後の自動継続」を追加することを提案する。
    rule_conflict: なし
---

この仕組みのポイントは2つある。

1. 提案が成果物に埋め込まれる

「懸念があります」という口頭の報告だと、CEOが見落としたり流れてしまうことがある。YAMLヘッダーに構造化されていれば、機械的にパースして必ず拾える。

2. 上申経路が一方向に固定される

サブエージェントはユーザーに直接提案しない。必ずCEO経由で上申する。複数エージェントが同時に異なる提案をユーザーに送り始めたら意思決定が混乱する、という問題への組織論的な解決策だ。

「フォーマットをもらわないと真似できない」という疑問があると思うので、上記のYAML例がそのまま使えるテンプレートになっている。from・to・status・proposals[].title・proposals[].content・proposals[].rule_conflictの6フィールドだ。

6. なぜ「憲法」が必要だったか — 事故と再発防止

ここが核心部分なので率直に書く。

2026年4月23日、AUTO_SYNC_ZENN=trueというフラグをデフォルト有効にする変更をエージェントが独断で実行した。その結果、Zennの記事5本が一時的にunpublish状態になった。

これは個人の判断ミスではなく、設計の構造的な問題だった。

当時のCLAUDE.mdには「承認権はユーザーにある」という記述はあった。しかし「何を事前確認すべきか」が具体的に規定されていなかった。結果として「承認が必要かどうか」の判定がエージェントの主観に委ねられ、auto modeで発火しなかった。

事故から学んで整備したのが、現在のtriggerリスト（5行の表）だ。

| トリガー | なぜ承認が必要か | 確認形式 |
|---|---|---|
| **デフォルト値変更で挙動 on/off を切り替える** | 副作用が記事・課金・外部APIに波及 | 「〇〇をデフォルト△△化します。副作用: □□。OK？」 |
| **不特定多数を触る一括操作** (migrate / bootstrap / cleanup 系) | 一度走らせたら多数ファイルを変更、部分失敗で復旧困難 | 対象件数・差分サマリー・rollback手段を明示 |
| **自動実行の登録** (Task Scheduler / cron / Remote Trigger) | 無人実行開始は不可逆性が高い | XML/スクリプト・実行頻度・停止方法を提示 |
| **安全装置バイパス** (`--dangerously-skip-permissions`, `--force`, `--no-verify`) | バグやプロンプト注入で破壊的動作に直結 | 使用理由と代替案を併記 |
| **連続5コミット超え** | 変更量が大きいと憲法チェックが発火しなくなる | 一度サマリー報告、継続可否確認 |

「何を事前確認すべきか」を抽象的な原則ではなく、具体的なトリガーとして列挙することで、auto modeでも機能するようになった。これがネット事例では見当たらなかった部分だ。

CLAUDE.mdに「憲法」という大げさな言葉を使っているのも、実はこのためだ。抽象的な表現では実装レベルで機能しない。宣言を具体的なtriggerに落とし込む必要があり、その落とし込み先を「憲法を運用に落とすtriggerリスト」と名付けた。大仰な名前にすることで、「これは単なるルールではなく、守られなければならない仕組みだ」という位置づけを明確にする意図がある。

参考: 他の4つの仕組み（別途深掘り予定）

3〜6章で取り上げた以外にも、比較調査で浮かび上がった特徴がある。いずれも本記事では深掘りしないが、参考までに一行ずつ紹介する。

仕組み 一行説明
ガバナンス違反のリカバリ手順（B） 事故後の4ステップ（被害特定→責任帰属→記録→ルール更新）をCLAUDE.md本体に明記
エージェント新設の4軸評価フレーム（D） 反復性・専門性・非重複性・独立性。Yes 3つ以上で新設。増殖を抑制する側の設計
サブエージェントの上申経路の制約（F） サブエージェントはユーザーに直接提案しない。必ずCEO経由
ルール変更の根拠埋め込み（H） 事故日付・具体例をCLAUDE.md本体に残す。ルールの背景が失われない

特にDは「エージェントを増やさない条件」を規定している点が珍しい。調査したネット事例はエージェントを増やす側の設計にフォーカスしており（それ自体は多くのユースケースで適切な設計だ）、抑制側の基準を明文化した事例は調査範囲では見当たらなかった。

これらについては別途深掘り予定だ。

まとめ: フリーランス1人運用でもこの設計は必要か

「マルチエージェント大規模運用でもないのに、この設計は大げさじゃないか」という疑問は当然ある。

正直に言うと、最初から必要だったわけではない。

最初は役割定義とディレクトリ約束程度でスタートした。triggerリストを書いたのは事故の後だ。proposalsフィールドは運用していくうちに「口頭では拾えない提案が流れてしまう」という問題に気づいてから追加した。

つまり「運用してから必要になったもの」を後付けで整備してきた結果が現在の形だ。事故を踏んでから書いても間に合う、というのが正直な感想だ。

ただし一点だけ先回りして書いておいてよかったと思うのは「沈黙≠承認」の明文化だ。これは事故が起きてから書くのでは遅い。auto modeで動かし始める前に入れておくことを勧める。

フリーランス1人運用でClaude Codeをしばらく使い込んで、「なんかエージェントが勝手に動いて困ることが出てきた」と感じたタイミングが書き時だと思う。

今日すぐ入れるなら、この3段階で:

  1. まず: CLAUDE.mdに「沈黙 ≠ 承認。1/OK/具体的承認語が返るまで実行しない」の1行を追加する（3章のコードブロックをそのままコピーできる）
  2. 次に: auto modeで文脈が飛ぶようになってきたら、4章の起動4ステップをCEO行動ルールに追加する
  3. 余裕があれば: エージェントが2人以上になったとき、5章のproposalsフィールドをエージェント定義に組み込む（YAMLのコピーだけでなく、定着まで2〜3週間の慣らし運転を見ておくといい）

まず1だけでも今日入れておくと、「返事しなかったら勝手に進んだ」という事故を未然に防げる。

この記事で紹介したマルチエージェント構成・ガバナンス設計の全体像は、以下の書籍でより詳しく書いています。CLAUDE.md・エージェント組織・triggerリストの設計背景を一冊にまとめたものです。

コードを書けない私が、AIに「チーム」を持たせるまで — Zenn Books

Claude Code 全般の入門・実践を体系的に学びたい場合は、以下の書籍も参考になります。

参考リンク

本記事の比較調査で参照したネット事例10件（researcherが一次ソースに当たった範囲）:

関連記事

この記事のテーマを深掘りした本

コードを書けない私がClaude Codeに「仕組み」を渡すまで CLAUDE.md・スキル・メモリ——Claude Codeに「渡す場所」7レイヤーの解剖（序章無料）

シリーズ全6冊: Vol.1 作るまで ／ Vol.2 回すまで ／ Vol.3 書き続けるまで ／ Vol.4 仕組みを渡すまで ／ Vol.5 仕事を任せるまで ／ Vol.6 1人エージェントチーム