はじめに
こんにちは。
トライベック株式会社の岡山です。
以前、Serena MCPを導入した記事を書きました。
Serena MCPはプロジェクト全体の構造を解析し、AIに「プロジェクト専用のコンテキスト」を持たせることで、ハルシネーションの低減に効果がありました。
しかし、一つ解決すると、次の課題が見えてきます。
ある日、こんな状況に気づきました。
「今日もAIに実装してもらったけど、仕様の整理だけで1時間かかった。先月も似たような調査をした気がする……」
振り返ると、こんなことが繰り返されていました。
- 「何を作るか」の整理に時間がかかる ——仕様が曖昧なままAIに投げると、修正ループが増える
- 同じ調査を何度もしている ——先週解決した問題を、チームの別メンバーがまた1から調べている
- レビューの質がバラバラ ——AIが生成したコードのチェック観点が人によって違い、品質が安定しない
- 知見が個人の中で死んでいる ——Slackのどこかに答えはあるはずなのに、誰も探せない
つまり、Serena MCPで「AIがプロジェクトを理解する」問題は解決できた。
でも、その先——「チームとして何を作るか考え、知識を蓄積していく」プロセスは、まだ人間の手に頼ったままでした。
この課題に対して、Every社が公開している Compound Engineering プラグイン が有効なアプローチになると考え、実際に導入・検証してみました。本記事では、その導入方法と使い方、そして実際に感じた効果をまとめます。
Compound Engineeringとは
Compound Engineeringは、「各エンジニアリング作業の単位が、次の作業をより簡単にするべきである」という思想に基づいたClaude Code向けのプラグインです。
従来の開発では、機能を追加するたびに複雑さが増大し、コードベースの保守が次第に困難になっていきます。Compound Engineeringはこの流れを逆転させ、開発を重ねるほどに効率が上がる仕組みを提供します。
その核となる考え方は、「80%を計画とレビューに、20%を実行と知識の蓄積に」 というものです。
なぜ「複利」なのか
金融の「複利」と同じ原理です。
最初にバグを解決して、その過程をドキュメントとして記録する。次に似た問題に遭遇したとき、過去の記録があるので解決時間が短縮される。その短縮された時間で、さらに別の知見を記録する——この繰り返しにより、知識が雪だるま式に蓄積されていきます。
ワークフローの全体像
Compound Engineeringのコアワークフローは、以下の 4ステップのループ で構成されています。
Plan → Work → Review → Compound → 繰り返し
| ステップ | コマンド | 役割 |
|---|---|---|
| 1. 計画 | /ce:plan |
アイデアを詳細な技術的実装計画に変換する |
| 2. 実行 | /ce:work |
Git worktreeとタスクトラッキングで計画を実行する |
| 3. レビュー | /ce:review |
マルチエージェントによる段階的コードレビュー |
| 4. 蓄積 | /ce:compound |
解決した問題や学びをドキュメント化する |
最初の3ステップ（Plan, Work, Review）は従来の開発でも馴染みのある工程ですが、4番目の Compound（蓄積） こそがこのプラグインの真髄です。このステップを省略すると、単にAIを使った従来型の開発に留まってしまいます。
また、要件が曖昧な段階では /ce:brainstorm で対話的に要件を探索してから /ce:plan に渡すこともできます。タスクがシンプルな場合は自動的にセレモニーが省略されるので、小さな修正で過剰な計画が生まれる心配はなさそうです。
CLAUDE.md — エージェントの記憶の中核
Compound Engineeringにおいて最も重要なファイルが CLAUDE.md です。これはエージェントがセッション開始時に毎回読み込むファイルで、プロジェクトの好み、パターン、コンテキストを記載しておく場所です。
何か問題が発生した際にメモを追記しておけば、エージェントが同じ間違いを繰り返さなくなります。チームの「暗黙知」をここに言語化していくことで、複利効果が加速します。
プロジェクト内のディレクトリ構成
プラグイン導入後、以下のようなディレクトリ構成でドキュメントが管理されます。
your-project/
├── CLAUDE.md # エージェントへの指示・パターン・好み
├── docs/
│ ├── brainstorms/ # /ce:brainstorm の出力
│ ├── plans/ # /ce:plan の出力
│ └── solutions/ # /ce:compound の出力（カテゴリ別）
└── todos/ # /triage やレビューで検出された課題
├── 001-ready-p1-fix-auth.md
└── 002-pending-p2-add-tests.md
docs/solutions/ に蓄積されるドキュメントは、過去に解決した問題の検索可能なナレッジベースとなり、将来のセッションで自動的に参照されます。
導入方法
Claude Codeの場合
Claude Codeを使用している場合は、2つのコマンドを実行するだけです。
claude /plugin marketplace add EveryInc/compound-engineering-plugin
claude /plugin install compound-engineering
これだけで導入完了です。既存のコードやCI/CD、設定ファイルには一切影響しません。追加されるのはスラッシュコマンドとエージェントのみです。
その他のツール（Codex, Copilot, Gemini, Windsurf等）
Compound Engineeringは、Claude Code以外のAIコーディングツールにも対応しています。CLIツールで各ツール向けのフォーマットに変換してインストールできます。
# Codex向け
bunx @every-env/compound-plugin install compound-engineering --to codex
# GitHub Copilot向け
bunx @every-env/compound-plugin install compound-engineering --to copilot
# Gemini CLI向け
bunx @every-env/compound-plugin install compound-engineering --to gemini
# Windsurf向け
bunx @every-env/compound-plugin install compound-engineering --to windsurf
# インストール済みの全ツールに自動で導入
bunx @every-env/compound-plugin install compound-engineering --to all
対応ツールの一覧は以下の通りです。
| ターゲット | 出力先 | 備考 |
|---|---|---|
codex |
~/.codex/prompts + ~/.codex/skills
|
コマンドがprompt + skillペアに変換 |
copilot |
.github/ |
.agent.md形式で出力 |
gemini |
.gemini/ |
.toml形式のコマンドファイル |
windsurf |
~/.codeium/windsurf/ |
グローバルスコープがデフォルト |
opencode |
~/.config/opencode/ |
.md形式のコマンドファイル |
その他にも Droid, Pi, Kiro, OpenClaw, Qwen に対応しています。
各コマンドの使い方
ここからは、各コマンドの具体的な使い方を紹介します。
/ce:brainstorm — 要件の探索
要件が曖昧な段階で使うコマンドです。アイデアや課題を伝えると、対話的なQ&Aを通じて要件とアプローチが整理されます。
/ce:brainstorm 認証フローのリファクタリング
内部ではリポジトリの軽量な調査を行った上で、目的・ユーザー・制約・エッジケースなどを一つずつ質問してきます。出力は docs/brainstorms/ に保存され、次の /ce:plan にそのまま渡せる形になります。
/ce:plan — 実装計画の作成
ブレスト結果（またはアイデアの直接入力）を、リポジトリの既存パターンに基づいた技術的な実装計画に変換します。
/ce:plan ユーザーがコメントを受け取ったときにメール通知を送る機能を追加
内部では3つの並列リサーチエージェント（コードベース分析・フレームワークドキュメント調査・ベストプラクティス調査）が同時に動き、その結果をマージして構造化された計画を生成します。既存のアーキテクチャとの整合性を自動でチェックした上で、エージェント（または人間）が実行可能なレベルの計画を出力してくれます。
/ce:work — 計画の実行
Git worktreeを使った並列開発とタスクトラッキングで、計画を体系的に実行します。
/ce:work
クイックスタート（worktree作成・ブランチ設定）→ 実行（タスクごとに進捗追跡）→ 品質チェック（レビューエージェント起動）→ シップ（lint実行・PR作成）の4フェーズで進みます。
/ce:review — マルチエージェントコードレビュー
個人的に最も注目しているコマンドです。複数のAIペルソナが、それぞれ異なる観点からコードレビューを並列実行します。
/ce:review
搭載されているレビューエージェントの一部を紹介します。
| ペルソナ | チェック観点 |
|---|---|
| security-sentinel | OWASP Top 10の脆弱性、インジェクション攻撃、認証・認可の不備 |
| performance-oracle | N+1クエリ、インデックス不足、キャッシュ最適化、アルゴリズムのボトルネック |
| data-integrity-guardian | マイグレーション、トランザクション境界、参照整合性 |
| architecture-strategist | システム設計、コンポーネント境界、依存関係の方向 |
| pattern-recognition-specialist | デザインパターン、アンチパターン、コードスメルの検出 |
| code-simplicity-reviewer | YAGNI原則、不要な複雑性、可読性 |
| deployment-verification-agent | デプロイ前チェックリスト、ロールバック計画 |
| agent-native-reviewer | 機能がAIエージェントからもアクセス可能かの確認 |
これ以外にも、Rails哲学（シンプルさ重視のOmakaseスタック）に基づいてレビューする dhh-rails-reviewer や、TypeScript特化の kieran-typescript-reviewer、Python特化の kieran-python-reviewer など、言語・フレームワークに特化したエージェントも用意されています。プラグイン全体では26の専門エージェントが搭載されています。
レビュー結果はP1（必須修正）・P2（推奨修正）・P3（軽微）に優先度分類された上で、重複が排除されたフィードバックとして提供されます。人間のレビューの前段として非常に心強そうです。
/ce:compound — 解決知識の蓄積
問題を解決した後に実行するコマンドです。解決過程を構造化ドキュメントとして docs/solutions/ に保存します。
/ce:compound # 直近の修正をドキュメント化
/ce:compound Redis接続タイムアウト # コンテキストを添えて記録
内部では6つの並列サブエージェント（コンテキスト分析・解決策抽出・関連ドキュメント検索・再発防止策立案・カテゴリ分類・ドキュメント作成）が動き、YAMLフロントマター付きの検索可能なMarkdownを生成します。蓄積されるほど、同種の問題への対応速度が向上する——これが「複利」の仕組みです。
/lfg — ワンコマンドで全自動実行
「Let's Go」の略で、アイデアを伝えるだけでPlan → Work → Review → Compoundの全パイプラインを自動実行してくれるコマンドです。
/lfg 設定ページにダークモード切替を追加
計画の承認で一度だけ人間の確認が入りますが、それ以降は自律的に実行され、全ステージを通じて50以上のエージェントが起動します。最終成果物はマージ可能なPRとして出力されます。
/ce:ideate — 改善点の発見
コードベースを分析して、高インパクトな改善アイデアを自動で発見・評価してくれるコマンドです。
/ce:ideate # オープンエンドで改善点を探索
/ce:ideate DX improvements # 開発者体験にフォーカス
/ce:ideate low-complexity wins # すぐ着手できる改善に絞る
内部では、大量のアイデアを発散的に生成した後、敵対的フィルタリング（Adversarial Filtering） で明確な理由付きで棄却し、生き残ったアイデアのみを詳細化するというプロセスが実行されます。結果は docs/ideation/ に保存されます。
/ce:compound-refresh — 知識の鮮度維持
蓄積したドキュメントが古くなっていないかをチェックし、各ドキュメントに対して「維持・更新・置換・アーカイブ」の判断を行ってくれます。
/ce:compound-refresh
その他の便利コマンド
コアワークフロー以外にも、日常的に使えるコマンドが揃っています。
Git系コマンド
| コマンド | 機能 |
|---|---|
git-commit |
変更内容から価値を伝えるコミットメッセージを自動生成 |
git-commit-push-pr |
コミット→プッシュ→PR作成まで一括実行 |
git-worktree |
並列開発のためのworktree管理 |
git-clean-gone-branches |
リモートが削除済みのローカルブランチを掃除 |
特に git-commit-push-pr は、コミットメッセージの作成からPR本文の生成まで一気通貫で行ってくれるので、手作業のオーバーヘッドがかなり減りそうです。
ユーティリティ系コマンド
| コマンド | 機能 |
|---|---|
/onboarding |
リポジトリをスキャンして ONBOARDING.md を自動生成 |
/changelog |
最近のマージからチェンジログを生成 |
/reproduce-bug |
ログやコンソールを使ってバグを再現 |
/resolve-pr-feedback |
PRレビューのフィードバックを並列で解決 |
/triage |
レビュー結果を一件ずつ確認し、承認・スキップ・カスタマイズを判断 |
/onboarding は、リポジトリをスキャンしてプロジェクトのアーキテクチャやエントリーポイント、依存関係などをASCIIダイアグラム付きで ONBOARDING.md に自動生成してくれるコマンドです。新メンバーのオンボーディングにそのまま活用できます。
設定の同期機能
Claude Codeの個人設定（スキル、コマンド、MCPサーバー）を他のAIコーディングツールに同期する機能もあります。
# 全ツールに自動同期
bunx @every-env/compound-plugin sync
# 特定のツールに同期
bunx @every-env/compound-plugin sync --target copilot
bunx @every-env/compound-plugin sync --target gemini
同期される内容は以下の通りです。
-
✅ パーソナルスキル（
~/.claude/skills/— シンボリックリンクで同期されるため、変更が即反映） -
✅ スラッシュコマンド（
~/.claude/commands/） -
✅ MCPサーバー設定（
~/.claude/settings.json）
複数のAIコーディングツールを併用している場合に便利な機能です。
今後の展望：既存プロジェクトへの導入を検討中
今回はCompound Engineeringプラグインの導入方法や使い方を一通り調べてみましたが、ゆくゆくは実際に既存プロジェクトへの導入を検討しています。
特に以下の点に期待しています。
-
✅
/ce:reviewによるレビュー品質の底上げ：複数のAIペルソナによるマルチ観点レビューは、人間のレビューの補助として大きな効果がありそう -
✅
/ce:compoundによる知見の蓄積：バグ修正のたびに解決過程を記録していけば、チーム全体のナレッジベースが自然に構築されていく -
✅
/onboardingによる新メンバーの立ち上がり支援：コードベースの全体像をドキュメント化しておくことで、オンボーディングコストの削減につながりそう
プラグイン自体がソースコードや設定ファイルに変更を加えない非侵襲的な設計なので、段階的に導入しやすそうなのも好印象です。まずは /ce:review だけPRに組み込んでみるなど、小さく始めてみようと考えています。
実際に導入してみたら、その効果や使用感について改めて記事にまとめたいと思います。
まとめ
Compound Engineeringプラグインは、AIエージェント時代における 「計画」と「知識の蓄積」 という見落とされがちな部分を強化するツールです。
改めてポイントを整理すると：
- ✅ 4ステップのコアループ（Plan → Work → Review → Compound）で開発サイクルを構造化
- ✅ マルチエージェントレビューで26の専門エージェントが多角的にコードをチェック
- ✅ 知識の複利効果で、問題解決のたびにチームの対応速度が向上
- ✅ マルチツール対応でClaude Code以外にもCopilot, Gemini, Windsurf等に導入可能
- ✅ 非侵襲的設計で既存プロジェクトにも段階的に導入しやすい
AIが「コードを書く速度」を上げてくれる一方で、「何をどう作るか」の判断と「過去の学びの活用」は依然として課題として残っています。Compound Engineeringは、まさにこの部分にアプローチしてくれるツールだと感じました。