Compound Engineeringとは｜AI開発を複利で回すOSSの仕組み

AI コーディングツールを日常的に使っていても、「エージェントへの指示が毎回その場しのぎになっている」「同じレビュー指摘や同じバグ対応を何度も繰り返している」と感じることはないでしょうか。ツールの選択肢は急速に増えましたが、「どう使えば開発が継続的に楽になるのか」という方法論はまだ確立されていません。

特に少人数チームや個人開発では、開発フローを仕組み化したいと思っても、参考にできるベストプラクティスが手探りになりがちです。プラグインやスキル、サブエージェントといった概念は理解していても、それらをどう組み合わせて運用すれば成果につながるのかは、ツールのドキュメントだけでは見えてきません。

こうした課題に対して、メディア／プロダクト企業の Every 社が公開したのが Compound Engineering という公式プラグインです。中核にあるのは「各作業が次の作業を楽にする（＝複利のように効いてくる）」という開発の考え方で、それをスキルとエージェントの集合体として実装している点が特徴です。

本記事では、Compound Engineering の思想・コアワークフロー・対応ツール、そして spec-kit や BMAD-METHOD といった類似 OSS との違いを、公開ドキュメントをもとに整理します。実際のインストールや動作検証は行わず、あくまで「自分のプロジェクトに採用を検討すべきか」「どのツール環境で使えるか」を判断するための材料を提供することを目的としています。

Compound Engineeringとは何か

Compound Engineering は、Every 社（every.to）が公開している AI コーディング向けの公式プラグインです。公式リポジトリでは「各エンジニアリング作業を、前回より楽にする AI スキル＆エージェント群（AI skills and agents that make each unit of engineering work easier than the last）」と説明されています（EveryInc/compound-engineering-plugin（GitHub））。

プラグインの提供形態

このプラグインは Claude Code をはじめとする複数の AI コーディングツール向けに配布されており、リポジトリの説明文（description）でも「Official Compound Engineering plugin for Claude Code, Codex, Cursor, and more」と明記されています。単発のスクリプトやテンプレート集ではなく、ブレインストーミングから計画・実装・レビュー・学びの蓄積までを一連のワークフローとして提供する点が、一般的なプロンプト集との違いです。

README によると、compound-engineering プラグインは現時点で 37 のスキルと 51 のエージェントを同梱しています。各コンポーネントの完全な一覧は、後述のコンポーネントリファレンスで確認できます。

リポジトリ基本データ（メンテナンス健全性）

採用を検討する際に気になるのが、プロジェクトが健全に維持されているかという点です。本記事執筆時点（2026年6月5日）の客観データは以下のとおりです。

スター数は 19,848 と多く、最終更新日も執筆時点と同日付であり、活発に開発が継続されているプロジェクトです。リポジトリはアーカイブ済みでもフォークでもなく、ライセンスは MIT で設定されています。MIT ライセンスは商用利用・改変・再配布に対して制約が緩やかなため、業務プロジェクトへの組み込みを検討する際の障壁は小さいといえます。

なお、本記事の数値はすべて公開リポジトリのメタデータに基づくものであり、スター数やフォーク数は日々変動します。最新の値は GitHub 上で確認してください。

「複利型エンジニアリング」という考え方

Compound Engineering を理解するうえで核になるのが、その名のとおり「複利（compound）」というメタファーです。

中核となる命題

README が掲げる中核命題は、「各エンジニアリング作業は次の作業を楽にすべきであり、難しくすべきではない（Each unit of engineering work should make subsequent units easier -- not harder.）」というものです（EveryInc/compound-engineering-plugin（GitHub））。

従来の開発では、機能を追加するたびに複雑性が増し、バグ修正のたびに「あとで誰かが再発見しなければならないローカルな知識」が積み残されていきます。コードベースは大きくなり、文脈を把握するのが難しくなり、次の変更はどんどん遅くなる――いわゆる技術的負債の蓄積です。Compound Engineering は、この流れを反転させることを狙っています。

Every 社は公式記事でも、この思想とエージェントを使った開発の進め方を詳しく解説しています（Compound engineering: how Every codes with agents（every.to））。

リソース配分は「80%が計画とレビュー」

Compound Engineering の特徴的な点は、作業時間の配分にあります。README では「80% を計画とレビューに、20% を実行に充てる」という方針が示されています。実装そのものよりも、その前後の設計・検証・知識の体系化に重きを置く構成です。具体的には次のような役割分担が想定されています。

• コードを書く前に /ce-brainstorm と /ce-plan で十分に計画する
• /ce-code-review と /ce-doc-review で問題を捉え、判断基準を調整する
• /ce-compound で知識を再利用可能な形に体系化する
• 品質を高く保ち、将来の変更を容易にする

目的は「儀式」ではなく「レバレッジ」

README は「ポイントは儀式（ceremony）ではなく、レバレッジ（leverage）である」と明言しています。手続きを増やすこと自体が目的ではありません。良いブレインストーミングが計画を鋭くし、良い計画が実行を小さくし、良いレビューは個別のバグではなくパターンを捉え、良い「compound ノート」によって次のエージェントが同じ学びをゼロから学び直さずに済む――この連鎖こそが「複利」の正体です。

同じミスを繰り返している、レビューでの気づきが個人の頭の中にしか残らない、といった課題を抱えるチームにとっては、この設計思想が自分たちの問題に効くかどうかが採用判断の分かれ目になります。

コアワークフローと主要スキル

思想を理解したら、次に確認すべきは「実際にどう運用するのか」です。Compound Engineering は、一連のスキルをループとして回すことを前提に設計されています。

コアループの流れ

README が示すコアループは「ブレインストーミング → 計画 → 実行 → レビュー → 学びの蓄積（compound）、そしてより良いコンテキストで繰り返す」というものです。具体的には、要件をブレインストーミングし、実装を計画し、計画に沿って作業し、結果をレビューし、学びを蓄積したうえで、改善された文脈のもとで次のサイクルを回します。

ループの手前には /ce-strategy が位置づけられています。これはプロダクトの対象課題・アプローチ・ペルソナ・主要指標・トラックを STRATEGY.md という短く永続的なアンカーとして記録するスキルで、ideate・brainstorm・plan がこれを下敷き（grounding）として参照する構造になっています。各サイクルが積み重なるごとに、ブレインストーミングが計画を鋭くし、計画が将来の計画に活き、レビューがより多くの問題を捉え、パターンがドキュメント化されていきます。

主要スキル一覧

README に記載されている主要スキルを整理すると、以下のようになります（EveryInc/compound-engineering-plugin（GitHub））。

このうち /ce-compound が、複利型エンジニアリングの中核を担うスキルです。レビューで得た学びをその場限りにせず、ドキュメントとして体系化し、次のサイクルで参照できる資産に変える役割を持ちます。

コマンド実行例

README には、典型的なサイクルのコマンド例が掲載されています。ラフなアイデアを要件ドキュメントに落とし込み、そのドキュメントをもとに計画してから /ce-work に実行を引き渡す流れです。以下は README からの抜粋です（出典: EveryInc/compound-engineering-plugin（GitHub））。

/ce-brainstorm "make background job retries safer"
/ce-plan docs/brainstorms/background-job-retry-safety-requirements.md
/ce-work
/ce-code-review
/ce-compound

バグ調査に絞ったサイクルとしては、次の例も示されています（出典: EveryInc/compound-engineering-plugin（GitHub））。

/ce-debug "the checkout webhook sometimes creates duplicate invoices"
/ce-code-review
/ce-compound

各コンポーネントの完全な一覧（全エージェント・全スキル）は、リポジトリ内のコンポーネントリファレンスにまとめられています（コンポーネント完全リファレンス（plugins/compound-engineering/README.md））。導入を検討する際は、ここで自分のワークフローに必要なスキルが揃っているかを確認すると判断しやすくなります。

対応ツールとインストールの前提

「自分の使っているツール環境で使えるか」は、採用前提として最初に確認すべきポイントです。Compound Engineering は複数の AI コーディングツールに対応していますが、ツールによって導入方法が異なります。

ネイティブ対応のツール

README の Install セクションによると、Claude Code・Cursor・GitHub Copilot（VS Code / CLI）・Factory Droid・Qwen Code は、ネイティブのプラグイン機構経由で導入できます。これらは追加のランタイムを必要とせず、各ツールのプラグインマーケットプレイス経由でインストールする形が基本です。

Claude Code の場合、README では以下のコマンドが案内されています（出典: EveryInc/compound-engineering-plugin（GitHub））。

/plugin marketplace add EveryInc/compound-engineering-plugin
/plugin install compound-engineering

Bun ステップが必要なケース

一方、Codex はネイティブの skills インストールに加えて、カスタムエージェントを追加するための Bun（bunx @every-env/compound-plugin）を使ったステップが必要です。README には、これは Codex の現行プラグイン仕様がまだカスタムエージェントの登録に対応していないためであり、将来 Codex 側が対応すれば Bun ステップは不要になる、と注記されています。

さらに、OpenCode・Pi・Gemini CLI・Kiro CLI といったツールは、TypeScript で書かれたコンバーター（converter）経由でのインストールに対応しています。これらを使う場合は Bun が前提になります。

導入を検討する際は、自分のメインツールが「ネイティブ対応」か「コンバーター経由（Bun 前提）」かを先に確認しておくと、セットアップの手間を見積もりやすくなります。なお、本記事ではこれらのインストール手順を実際に実行・検証したわけではなく、README の記載内容を整理したものである点にご留意ください。

spec-kit・BMAD-METHODとの違い

AI 開発ワークフローを構造化する OSS は、Compound Engineering 以外にも複数あります。「結局どれを選べばいいのか」という判断のために、代表的な 2 つの類似プロジェクトと比較してみます。

比較対象の概要

spec-kit（github/spec-kit） は、Spec-Driven Development（仕様駆動開発）のためのツールキットです。「spec が何を作るかを定め、plan がどの手順で作るかを定め、code が plan に従う」という 3 つのドキュメント構造を中心に据えています。成果物（spec / plan）が任意の AI コーディングエージェントで扱えるよう設計され、GitHub の PR 上でステークホルダーがレビューすることを前提に、成果物が Git に残る点が特徴です。

BMAD-METHOD（bmad-code-org/BMAD-METHOD） は、「Breakthrough Method for Agile AI-Driven Development」を掲げるプロジェクトです。PM・アーキテクト・スクラムマスター・開発者・QA といった多数の役割エージェントと、名前付きのワークフロー群を備え、仕様から実装までを複数フェーズに分けて、各フェーズを役割エージェントが担当します。spec-kit が「成果物」を整理するのに対し、BMAD は「人（役割）」を整理するアプローチといえます。

観点別の比較

Compound Engineering 固有の価値

3 者とも「計画 → 実装 → レビュー」を構造化する点は共通しています。そのうえで Compound Engineering 固有の価値は、レビュー後の学びを /ce-compound で資産化し、次のサイクルに複利的に効かせる点にあります。単発の「仕様 → 実装」で完結するのではなく、サイクルを跨いで知識が積み上がっていく設計になっているため、「同じミスを繰り返している」という課題に対して直接的に応えるツールだといえます。

逆に、仕様成果物をチームで厳密にレビュー・管理したいなら spec-kit、明確な役割分担のあるアジャイル体制を AI で再現したいなら BMAD-METHOD のほうが目的に合致する可能性があります。自チームの課題が「知識が蓄積されないこと」なのか「仕様管理」なのか「役割分担」なのかを起点に選ぶと、判断が明確になります。

どんなチームに向くか・採用判断のポイント

最後に、ここまでの整理をもとに採用判断の観点をまとめます。

向いているケース

• 同じミスやレビュー指摘を繰り返している: /ce-compound による学びの蓄積ループが、まさにこの課題に対応する設計になっています
• 少人数で開発のレバレッジを上げたい: 80% を計画とレビューに充てる思想は、人手をかけずに品質と速度を両立したい個人・小規模チームと親和性が高い構成です
• 既に Claude Code・Cursor 等を使っている: これらはネイティブ対応のため、追加ランタイムなしで導入を検討できます

慎重に検討すべきケース

• すでに確立した開発フローがある: 80%を計画・レビューに充てる配分が既存プロセスと衝突しないか、事前の検討が必要です
• メインツールがコンバーター経由のみの対応: OpenCode・Pi・Gemini CLI・Kiro CLI などを使う場合は Bun が前提になるため、セットアップの手間を見込む必要があります

メンテナンス健全性の観点

採用リスクを評価するうえで、プロジェクトの継続性は重要な材料です。前述のとおり、スター数 19,848・Fork 数 1,468 と利用・関心の規模が大きく、最終更新も執筆時点と同日付で開発が活発に続いています。アーカイブされておらず、MIT ライセンスで商用利用の制約も緩やかなため、OSS としての導入障壁は比較的小さいといえます。一方で、リリースバージョンは自動化で管理され、更新頻度が高いプロジェクトであるため、導入後は変更の追従コストも見込んでおくとよいでしょう。

まとめ

Compound Engineering は、「各作業が次の作業を楽にする」という複利型の開発思想を、スキルとエージェントの集合体として実装した Every 社製の OSS プラグインです。本記事では、その思想・コアワークフロー・対応ツール・類似 OSS との違いを公開ドキュメントベースで整理しました。

採用を判断する際の観点を改めて整理すると、次のようになります。

• 思想が自チームの課題に効くか: 「同じミスの繰り返し」「学びが個人に閉じる」といった課題があるなら、複利化の思想と /ce-compound の学び蓄積ループが直接的に効く可能性があります
• ツール環境が合うか: Claude Code・Cursor などネイティブ対応ツールなら導入障壁は小さく、コンバーター経由のツールなら Bun 前提のセットアップを見込む必要があります
• 類似 OSS との使い分け: 仕様管理重視なら spec-kit、役割分担重視なら BMAD-METHOD、学びの複利化重視なら Compound Engineering、という軸で選ぶと判断しやすくなります
• メンテナンスは健全か: スター数・更新頻度ともに活発で、MIT ライセンスのため採用リスクは比較的低い水準です

最終的な導入可否は、実際にコンポーネントリファレンスで必要なスキルを確認し、自プロジェクトのツール環境と開発フローに照らして検討することをおすすめします。本記事が、その判断のスタート地点になれば幸いです。