すべてのチームが飛ばしている「第4ステップ」こそが、AIエンジニアリングの核心だ
- Everyは「Compound Engineering（複利エンジニアリング）」という方法論を使い、ほぼ一人のエンジニアリングチームで自社の5つのプロダクトを維持している。核心はPlan → Work → Review → Compoundの4ステップサイクルだ。
- 従来のエンジニアリングはReviewで止まる。第4ステップのCompoundは、毎回解決した問題をシステムの知識に変換し、AIが次回から同種のエラーを自動的に避けられるようにする——効率の差はここから生まれる。
- この方法論では、エンジニアの作業時間の80%をPlanとReviewに使い、実際にコードを書くのはわずか20%だとしている。
- 付属プラグインはオープンソース化済みで、Claude Code / OpenCode / Codexに対応。26体の専門agent、23個のワークフローコマンド、13個のスキルを含み、設定不要ですぐ使える。
- /workflows:reviewを1回呼び出すと、14体の専門agentが同時並行でコードを審査する。/workflows:planでultrathinkモードを開けば、40以上のリサーチagentを同時並行させられる。
一人で5つのプロダクトを支える、その仕組み
Everyチームは最近、「Compound Engineering（複利エンジニアリング）」という方法論を公開した。あわせて付属のオープンソースプラグインも公開し、ほぼ一人構成のエンジニアリングチームで、自社の5つのプロダクトを同時に維持する方法を語っている。
5つのプロダクトCora、Monologue、Sparkle、Spiral、そして公式サイトEvery.to。各プロダクトのエンジニアリングチームは基本的に1人しかいない。この規模を支えているのは長時間労働ではなく、4ステップのサイクルのうち、ほとんどのチームが省いてしまう最後の1ステップだ。
コードが触れなくなっていく根本原因はどこにあるか
ほとんどのコードベースは時間とともに保守が難しくなっていく。理由は単純だ——機能を1つ追加するたびに、システムに新しい複雑さを注入することになり、新機能は既存のすべての機能と「交渉」しなければならなくなる。10年経つと、チームは新しいものを作るより過去のコードと格闘する時間の方が長くなり、コードはどんどん理解しづらく、変更しづらく、信頼しづらくなっていく。
Compound Engineeringはこの曲線を逆転させる。機能はもうシステムへの負担ではなく、システムに新しい能力を教え込むものになる。バグを1つ直せば、ついでに将来起こりうる同種のバグの一群を消し去る。1つの解決策が固化されれば、次回そのまま再利用できるツールになる。反復するほど、システムは使いやすくなっていく。
4ステップのサイクル：時間の80%はコードを書いていない
この規模を支えているのは、Plan（計画）、Work（実行）、Review（審査）、Compound（固化）という4ステップのサイクルで、これを繰り返す。5分でバグを1つ直す場合でも、数日かけて機能を1つ作る場合でも、通るのはこの4ステップで、違うのは各ステップにかける時間だけだ。
最初の3ステップはどの開発者にもおなじみだが、第4ステップのCompoundこそがCompound Engineeringと普通のエンジニアリングを分ける境界線だ。これを飛ばせば、やっていることは単なる「AIアシスタント付きの従来型エンジニアリング」でしかない。