TL;DR
前回・前々回の記事で構築した24ロール・10フェーズのAI開発チームに、4つの構造的な進化を加えました。
- CLAUDE.md 分割・軽量化: 1,897行 → 696行（63%削減）。外部ファイル5本に分割し、PMが必要な時だけReadで読み込む設計へ
- Hub → Mesh 通信アーキテクチャ: PM経由の一極集中から、SendMessage + TaskList による自律分散型へ移行
- 視覚フォーマット導入: チーム起動バナー、進捗ダッシュボード、スピナーアニメーションで通常CLIと差別化
- 記事化判定の完全自動化: Phase 10で閾値チェック → 該当すれば確認なしで記事生成
結果として、コンテキスト枯渇問題の解消とエージェント間の通信効率の大幅向上を実現しました。
なぜ必要だったのか
問題1: CLAUDE.md の肥大化 ― コンテキストが数ターンで枯渇する
前回・前々回の記事で24ロール・10フェーズ・5ゲートの開発フローを構築しましたが、すべてのルールを1つの CLAUDE.md に書いていた結果、ファイルが 1,897行・102KB にまで膨れ上がりました。
CLAUDE.md の肥大化の推移
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
v1.0（第1弾）: ~600行 ~35KB ← まだ問題なし
v2.0（第2弾）: ~1,200行 ~68KB ← やや重い
v3.0（今回前）: 1,897行 102KB ← 数回の会話でコンテキスト上限到達
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Claude Code は会話開始時に CLAUDE.md を全文読み込みます。102KBのファイルがコンテキストウィンドウの大部分を占有するため、実際の開発作業に使えるコンテキストが極端に少なくなり、数ターンの会話でコンテキスト上限に到達してしまいます。
特にL/XL規模のタスクでは、10フェーズすべてを実行する前にコンテキストが尽きるという致命的な問題でした。
問題2: PM経由の一極集中通信 ― PMのコンテキストがボトルネック
全エージェント間の通信がPM経由（Hub方式）で行われていたため、PMのコンテキストに全メンバーのやり取りが蓄積していきます。
Hub方式の問題（Before）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
frontend ──→ PM ──→ backend 「APIの仕様を教えて」
backend ──→ PM ──→ frontend 「/api/users は JSON形式」
qa ──→ PM ──→ backend 「バグ見つけた。修正して」
backend ──→ PM ──→ qa 「修正完了。再確認お願い」
security ──→ PM ──→ frontend 「XSS対策が不足」
↑
PMのコンテキストに
全通信が蓄積される
→ PMが先にコンテキスト枯渇
→ プロジェクト全体が停止
PMのコンテキストが先に枯渇すると、進捗管理もフェーズ移行もできなくなり、プロジェクト全体が停止します。PMの本来の仕事は「管理」であって「メッセージの中継」ではありません。
アーキテクチャ変更の全体像
今回の変更は、以下の4つの柱で構成されています。
╔═══════════════════════════════════════════════════════════════════════════╗
║ ║
║ C L A U D E A G E N T T E A M v 4 . 0 ║
║ ~ Mesh Architecture + Context Optimization ~ ║
║ ║
║ ┌─────────────────────────────────────────────────────────────────┐ ║
║ │ │ ║
║ │ [1] CLAUDE.md 分割・軽量化 │ ║
║ │ 1,897行 → 696行（63%削減） 102KB → 46KB（55%削減） │ ║
║ │ 外部ファイル5本: role / phase / pipeline / quality / mock │ ║
║ │ │ ║
║ │ [2] Hub → Mesh 通信アーキテクチャ │ ║
║ │ TeamCreate + SendMessage + TaskList │ ║
║ │ PM中継不要 → エージェント間DM │ ║
║ │ │ ║
║ │ [3] 視覚フォーマット導入 │ ║
║ │ 起動バナー / フェーズヘッダー / ゲート表示 │ ║
║ │ 進捗ダッシュボード / スピナー / 通信ログ │ ║
║ │ │ ║
║ │ [4] 記事化判定の完全自動化 │ ║
║ │ Phase 10 閾値チェック → 自動生成（published: false） │ ║
║ │ │ ║
║ └─────────────────────────────────────────────────────────────────┘ ║
║ ║
╚═══════════════════════════════════════════════════════════════════════════╝
実装の詳細
1. CLAUDE.md 分割戦略
設計判断: 何を残し、何を外部化するか
分割で最も重要なのは**「何をCLAUDE.mdに残すか」の判断基準**です。以下の原則で設計しました。
分割の設計原則
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
CLAUDE.md に残すもの（常に必要な情報）:
✅ チーム構成の全体像（24ロール・9部門の表）
✅ フェーズ定義（10フェーズの一覧と概要）
✅ 品質ゲートのフローチャート
✅ 規模判定基準（S/M/L/XL）
✅ 起動フロー（TeamCreate → Agent → TaskCreate）
✅ 通信ルール（SendMessage / broadcast / TaskList）
✅ 視覚フォーマット定義
外部ファイルに分割するもの（必要な時だけ読み込む情報）:
📄 各ロールの詳細実施項目 → role-instructions.md
📄 InfraSim・テンプレート・資料生成の手順 → phase-details.md
📄 自動導入パイプラインの仕様 → auto-integration-pipeline.md
📄 品質原則・過去の教訓 → quality-principles.md
📄 模擬案件のガイドライン → mock-project-guidelines.md
この判断基準は 「PMが毎回参照する情報か、特定フェーズでのみ必要か」 という軸です。PMは毎回チーム構成やフェーズ定義を参照しますが、個別ロールの詳細指示は該当メンバーをスポーンする時だけ必要です。
ファイル構成
/home/user/.claude/agent-team/
├── role-instructions.md # 515行 — 21ロールの詳細指示
├── phase-details.md # 314行 — InfraSim・テンプレート・資料生成
├── auto-integration-pipeline.md # 114行 — 自動導入パイプライン仕様
├── quality-principles.md # 93行 — 品質原則・過去の教訓
└── mock-project-guidelines.md # 191行 — 模擬案件ガイドライン
PMの読み込み戦略
PMはサブエージェント起動時に、必要なファイルだけを Read ツールで読み込みます。
読み込みタイミングの設計
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 0（チーム編成）:
→ Read: role-instructions.md
→ 該当ロールの指示だけを抽出して Agent の prompt に含める
Phase 3（STRIDE）/ Phase 5（レビュー）/ Phase 7（Red Team）:
→ Read: phase-details.md
→ AI Code Review / Security Review のテンプレートを取得
Phase 8（InfraSim）:
→ Read: phase-details.md
→ InfraSim 障害耐性評価フローを取得
QAフェーズ / デプロイ前:
→ Read: quality-principles.md
→ 品質チェックリストを取得
Phase 10（完了報告）:
→ 閾値チェック → 該当時に auto-article スキルを起動
日次リサーチ（cron 自動実行）:
→ Read: auto-integration-pipeline.md
→ 7軸評価・撤退基準を参照
この設計により、PMのコンテキストにはその時点で必要な情報だけが読み込まれ、不要な情報でコンテキストを浪費しません。
定量的な効果
| 指標 | Before | After | 削減率 |
|---|---|---|---|
| CLAUDE.md 行数 | 1,897行 | 696行 | 63%削減 |
| CLAUDE.md サイズ | 102KB | 46KB | 55%削減 |
| 初回コンテキスト消費 | 大（全情報読込） | 小（コア情報のみ） | 約55%削減 |
| コンテキスト枯渇までのターン数 | 数ターン | 大幅に延長 | - |
2. Hub → Mesh 通信方式
Before: Hub方式（PM一極集中）
┌──────────┐
│ PM │
│ (Hub) │
└────┬─────┘
│
┌────────────┼────────────┐
│ │ │
┌────▼───┐ ┌───▼────┐ ┌───▼────┐
│frontend│ │backend │ │ qa │
└────────┘ └────────┘ └────────┘
全通信がPM経由 → PMのコンテキストが急速に消費
frontend → PM → backend （API仕様の確認だけでPMを経由）
After: Mesh方式（直接通信 + 共有タスク）
┌────────────────────────────────────────────┐
│ Team: "ec-site" │
│ │
│ frontend ◄──DM──► backend │
│ │ │ │
│ │ ┌──────┐ │ │
│ └─DM─►│ qa │◄─DM─┘ │
│ └──────┘ │
│ │ │
│ ┌───▼────┐ │
│ │security│ │
│ └────────┘ │
│ │
│ PM: フェーズ管理・全体監視のみ │
│ TaskList: 共有タスクで自律的に進行 │
│ │
└────────────────────────────────────────────┘
メンバー間DM → PMのコンテキストを消費しない
frontend → backend （直接通信。PMは関与しない）
使用するAPIの構成
Mesh方式は、Claude Code の以下の4つのAPIを組み合わせて実現します。
Mesh通信を支える4つのAPI
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. TeamCreate(team_name)
→ チームを作成し、共有TaskListを自動生成
→ 全メンバーが同一チームに所属する基盤
2. Agent(name, team_name, prompt)
→ メンバーをチームにスポーン
→ team_name を指定することで自動的にチームに参加
3. SendMessage(type, recipient, message)
→ メンバー間の直接通信（DM）
→ type: "message" — 個別DM
→ type: "broadcast" — 全体通知（Criticalのみ）
4. TaskList / TaskCreate / TaskUpdate
→ 共有タスクリストで自律的にタスクを管理
→ 依存関係（blocks/blockedBy）で実行順序を制御
→ メンバーが自分のタスク完了後に次を自律取得
チーム起動のコード例
以下は、M規模（機能追加）のチーム起動コードです。
# Step 1: チーム作成
TeamCreate(team_name="login-feature")
# Step 2: タスクを分解して登録
task1 = TaskCreate(
subject="OAuth2 ライブラリ調査",
description="passport.js vs auth0 vs firebase auth の比較",
activeForm="🔄 OAuth2ライブラリを調査中...",
owner="research-engineer"
)
task2 = TaskCreate(
subject="認証API実装",
description="POST /api/auth/login, /api/auth/logout を実装",
activeForm="🔄 認証APIエンドポイントを実装中...",
owner="backend-engineer",
blockedBy=[task1] # リサーチ完了後に着手
)
task3 = TaskCreate(
subject="コードレビュー",
description="LGTM + AI Code Review を実行",
activeForm="🔄 コードレビューを実施中...",
owner="review-engineer",
blockedBy=[task2] # 実装完了後に着手
)
# Step 3: メンバーをスポーン（team_name を指定）
Agent(
name="research-engineer",
team_name="login-feature",
prompt="""OAuth2 ライブラリの比較調査を実施してください。
完了後は SendMessage で tech-lead に結果を報告してください。
【チーム通信ルール】
- 他メンバーとの連携は SendMessage を使用
- タスク完了時は TaskUpdate で completed に更新
- TaskList で次のタスクを確認して自律取得"""
)
Agent(
name="backend-engineer",
team_name="login-feature",
prompt="""認証APIを実装してください。
research-engineer から調査結果を受け取ったら実装開始。
実装完了後は review-engineer に SendMessage でレビュー依頼。"""
)
# ... 他メンバーも同様にスポーン
通信パターンの具体例
Mesh方式での実際の通信フローを示します。
通信ログ（M規模: ログイン機能追加）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
💬 research → tech-lead:
「OAuth2 ライブラリ比較完了。passport.js を推奨。
理由: Express との親和性、ストラテジーの豊富さ」
💬 tech-lead → backend:
「passport.js を採用。JWT + refresh token 方式で実装して」
💬 backend → frontend:
「API仕様確定。POST /api/auth/login
Request: { email, password }
Response: { accessToken, refreshToken, expiresIn }」
💬 frontend → backend:
「了解。トークンの保存先は httpOnly cookie でOK?」
💬 backend → frontend:
「OK。Set-Cookie ヘッダーで返却する実装にした」
💬 backend → review:
「実装完了。レビューお願い」
💬 review → backend:
「LGTM。1点修正: refresh token の有効期限を設定して」
💬 backend → qa:
「修正完了。検証お願い」
💬 qa → backend:
「認証フロー検証OK。トークン期限切れ後の再認証もOK」
# PMのコンテキストにはこれらの通信は蓄積されない
# PMはフェーズ移行とゲート通過の管理だけに集中できる
Hub方式 vs Mesh方式の比較
| 項目 | Hub方式（Before） | Mesh方式（After） |
|---|---|---|
| 通信経路 | 全てPM経由 | メンバー間DM |
| PMの負荷 | 全通信を中継 | フェーズ管理のみ |
| PMのコンテキスト消費 | 急速（全通信蓄積） | 緩やか（管理情報のみ） |
| 通信遅延 | 2ホップ（送→PM→受） | 1ホップ（送→受） |
| スケーラビリティ | PMがボトルネック | メンバー数に依存しない |
| 障害耐性 | PM停止で全停止 | PM停止でもDM継続 |
| タスク管理 | PM手動 | TaskList自律管理 |
| 全体通知 | PM経由 | broadcast（Critical時のみ） |
3. 視覚フォーマット
Agent Team モードを通常の Claude Code と明確に区別するため、6種類の視覚フォーマットを導入しました。
チーム起動バナー
チーム起動時に、編成情報を一覧表示します。
╔══════════════════════════════════════════════════════════╗
║ 🏢 AGENT TEAM ACTIVATED ║
║ Project: ec-site ║
║ Scale: L | Members: 16名 | Phases: 10 ║
╠══════════════════════════════════════════════════════════╣
║ TEAM ROSTER ║
║ ┌─────────────────┬────────────────────────────────┐ ║
║ │ Role │ Mission │ ║
║ ├─────────────────┼────────────────────────────────┤ ║
║ │ project-manager │ フェーズ管理・全体監視 │ ║
║ │ tech-lead │ 技術方針・設計レビュー │ ║
║ │ frontend-eng │ React UI実装 │ ║
║ │ backend-eng │ REST API実装 │ ║
║ │ qa-engineer │ 品質検証 (70/20/10) │ ║
║ │ review-eng │ LGTM + AI Code Review │ ║
║ │ security-eng │ STRIDE + Red Team │ ║
║ │ ... │ ... │ ║
║ └─────────────────┴────────────────────────────────┘ ║
╚══════════════════════════════════════════════════════════╝
フェーズ移行ヘッダー
フェーズが移行するたびに、現在のフェーズを視覚的に表示します。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
▶ Phase 4: 実装（Feature Flag駆動） [frontend + backend + data]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ゲート通過/失敗表示
品質ゲートの結果を即座に表示します。
✅ Gate 1: LGTM Review — PASSED
✅ Gate 2: Bar Raiser Review — PASSED
❌ Gate 3: Testing Pyramid — FAILED → 修正ループ開始
原因: Integration Test で認証フローのエラー検出
担当DRI: backend-engineer
進捗ダッシュボード
PMがフェーズ移行時や主要タスク完了時に表示します。
┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃ 📊 PROGRESS DASHBOARD 12:34:56 ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ ┃
┃ Phase 0 ████████████████████ 100% ✅ 完了 ┃
┃ Phase 1 ████████████████████ 100% ✅ 完了 ┃
┃ Phase 2 ████████████████████ 100% ✅ 完了 ┃
┃ Phase 4 ██████████████░░░░░░ 70% 🔄 実装中 ┃
┃ Phase 5 ░░░░░░░░░░░░░░░░░░░░ 0% ⏳ 待機 ┃
┃ Phase 6 ░░░░░░░░░░░░░░░░░░░░ 0% ⏳ 待機 ┃
┃ ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ TASKS [6/12 completed] ┃
┃ ┃
┃ ✅ #1 DB設計 data-engineer ┃
┃ ✅ #2 APIスキーマ定義 backend-engineer ┃
┃ ✅ #3 認証基盤構築 security-engineer ┃
┃ 🔄 #4 REST API実装 backend-engineer ┃
┃ 🔄 #5 React UI実装 frontend-engineer ┃
┃ 🔄 #6 決済API連携 backend-engineer ┃
┃ ⏳ #7 コードレビュー review-engineer ┃
┃ ⏳ #8 テスト qa-engineer ┃
┃ ┃
┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫
┃ ACTIVE AGENTS ┃
┃ 🟢 backend-engineer #4 REST API実装中 ┃
┃ 🟢 frontend-engineer #5 React UI実装中 ┃
┃ 🟢 backend-engineer #6 決済API連携中 ┃
┃ 💤 review-engineer 待機中 (Phase 5 待ち) ┃
┃ 💤 qa-engineer 待機中 (Phase 6 待ち) ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
TaskCreate の activeForm（スピナーアニメーション）
TaskCreate 実行時に activeForm パラメータを設定すると、ユーザーのCLIにスピナーとして表示されます。
TaskCreate(
subject="REST API エンドポイント実装",
description="CRUD エンドポイントを実装する",
activeForm="🔄 REST APIエンドポイントを実装中..." # ← CLI に表示される
)
命名規則:
- 先頭に
🔄を付ける - 「〜中...」の形式で現在進行形にする
- 何をしているか一目でわかる具体性を持たせる
activeForm の命名例
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
🔄 データベーススキーマを設計中...
🔄 REST APIエンドポイントを実装中...
🔄 コードレビューを実施中...
🔄 テストスイートを実行中...
🔄 OWASP Top 10 脆弱性スキャン中...
🔄 150+シナリオで障害耐性を評価中...
🔄 本番環境にデプロイ中...
チーム内通信ログ
重要な通信のみをユーザーに表示します。
💬 backend → frontend: 「API仕様確定。/api/users は GET/POST 対応」
💬 qa → backend: 「認証フローでエラー検出。修正依頼」
🔴 security → [broadcast]: 「CRITICAL: XSS脆弱性検出。全員確認」
通常のClaude Code応答ではこれらのフォーマットは一切使用しません。Agent Teamモードが起動している場合のみ表示されるため、ユーザーは今どのモードで動作しているかを直感的に把握できます。
4. 記事化の自動判定
Phase 10（完了報告）で、PMが自動的に以下の閾値をチェックします。
記事化の自動判定フロー
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Phase 10 完了
│
▼
PMが閾値を自動チェック（1つ以上該当で記事生成）:
□ 3ファイル以上の新規作成/大幅修正
□ 新ツール/スクリプトの追加
□ 新フェーズ/ロール/ゲートの追加
□ Enterprise機能の再現
□ 重要なアーキテクチャ決定
□ 新プラクティスの導入
│
├── 1つ以上該当 → /auto-article スキルを自動実行
│ → 記事生成（published: false で下書き保存）
│ → git push
│ → 完了報告に「下書き記事を生成しました」を含める
│
└── 該当なし → スキップ（ログに「記事化対象外」と記録）
ポイントは ユーザーへの「記事にしますか？」という確認を一切行わない こと。閾値に該当すれば自動生成し、published: false（下書き）で保存します。公開するかどうかはユーザーが後から判断できます。
完全自律運転の原則 ― 「ユーザーは最初の指示を出したら、完了報告まで一切操作しない」 ― に沿った設計です。
Before/After 比較
定量的な改善
| 指標 | v3.0（Before） | v4.0（After） | 改善 |
|---|---|---|---|
| CLAUDE.md 行数 | 1,897行 | 696行 | 63%削減 |
| CLAUDE.md サイズ | 102KB | 46KB | 55%削減 |
| PM経由の通信量 | 全通信（100%） | フェーズ管理のみ（推定20%以下） | 80%以上削減 |
| コンテキスト枯渇リスク | 高（数ターン） | 低（大幅延長） | - |
| メンバー間通信ホップ数 | 2（送→PM→受） | 1（送→受） | 50%削減 |
| タスク管理方式 | PM手動 | TaskList自律管理 | 自動化 |
| 記事化 | 手動判断 | 自動判定+自動生成 | 自動化 |
アーキテクチャの変化
v3.0（Hub方式） v4.0（Mesh方式）
━━━━━━━━━━━━━━━━━━━ ━━━━━━━━━━━━━━━━━━━
┌───┐ ┌────────────────────┐
│PM │←─全通信─→全員 │ Team │
└─┬─┘ │ │
│ │ A ←DM→ B │
┌───┼───┐ │ │ │ │
A B C │ └─DM─→ C │
│ │
CLAUDE.md: 1,897行 │ PM: 管理のみ │
全情報一括読込 │ TaskList: 自律管理 │
└────────────────────┘
CLAUDE.md: 696行
+ 外部5ファイル(必要時Read)
既存アプローチとの比較
| 項目 | Hub方式（中央集権） | Mesh方式（分散自律） | Mesh + Context最適化（本システム） |
|---|---|---|---|
| 通信構造 | Star型（PM中心） | Full Mesh | Mesh + 共有TaskList |
| コンテキスト効率 | 低（PM集中） | 中（各自独立） | 高（分割Read + DM） |
| スケーラビリティ | PMがボトルネック | 通信量 O(n^2) | TaskListで O(n) に抑制 |
| タスク管理 | PM手動 | 各自判断 | TaskListで自律+整合性 |
| 障害耐性 | PM単一障害点 | 高い | 高い + ゲート自動修正 |
| 導入コスト | 低い | 中（通信設計必要） | 中（テンプレート化で軽減） |
| 視覚的識別 | なし | なし | バナー+ダッシュボード |
本システムの特徴は、Mesh方式の通信効率と、TaskListによるタスク管理の整合性を両立している点です。純粋なMesh方式では通信量がメンバー数の2乗に比例して増加しますが、TaskListを共有することで通信量を線形に抑えつつ、必要な時だけDMで直接連携します。
関連記事
本記事はシリーズ第3弾です。
-
Claude Codeで24ロール・10フェーズのAI開発チームを自動編成する ― GAFAM+Anthropicの開発フローを完全再現
24ロール・9部門・10フェーズ体制の構築。Google Design Doc、Amazon Bar Raiser、Anthropic Red Teaming等のプラクティス統合。 -
Claude Agent Team 進化録 ― Enterprise機能を無料で再現し、新機能を自動で取り込む仕組みを作った
Enterprise機能（Code Review $15-25/PR、Security Enterprise限定）の自前再現。7軸スコアリングによる自動導入パイプライン。 -
本記事（第3弾） ― CLAUDE.md 63%削減、Hub→Mesh通信、視覚ダッシュボード。
まとめ
AI エージェントチームの開発を続ける中で、**「ルールを書けば書くほどコンテキストが圧迫される」**という根本的な矛盾に直面しました。
この矛盾を解決するために、4つの構造変更を行いました。
- CLAUDE.md 分割: 全情報を常に読み込むのではなく、必要な時だけ外部ファイルをReadする「遅延読み込み」設計。1,897行 → 696行（63%削減）
- Mesh通信: PMをメッセージの中継役から解放し、本来の「管理」業務に集中させる。SendMessage + TaskListで自律分散型に移行
- 視覚フォーマット: Agent Teamモードを通常のCLI操作と視覚的に区別し、プロジェクトの進行状況を直感的に把握可能に
- 記事化自動判定: 完全自律運転の原則を最後まで貫き、ナレッジの発信まで自動化
特に重要なのは「分割」と「Mesh」の組み合わせです。CLAUDE.md の軽量化だけでは、PMのコンテキストが通信で埋まる問題は解決できません。逆に、Mesh通信だけでは、初回のCLAUDE.md読み込みでコンテキストが圧迫される問題は残ります。両方を同時に解決することで、コンテキスト効率が根本的に改善しました。
AI エージェントシステムの進化は、「機能を追加すること」ではなく、**「制約（コンテキストウィンドウ）の中でいかに効率的に情報と通信を設計するか」**という最適化問題だと感じています。
この記事は Zenn にも投稿しています。