すべてのチームが飛ばしている「第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アシスタント付きの従来型エンジニアリング」でしかない。
直感に反する点：コードを書くのはわずか2割
PlanとReviewを合わせるとエンジニアの時間の80%を占め、実際に手を動かして書くこと（Work）と固化すること（Compound）は合わせて20%しかない。大半の思考は、コードが書かれる前と後に起きている。
4ステップそれぞれが何をしているか / Everyが捨てるべきだとする旧来の思い込み
第4ステップの具体的な中身：解決策をシステムの記憶に変える
最初の3ステップ（計画・実行・審査）が生み出すのは「1つの機能」だ。第4ステップのCompoundが生み出すのは「毎回機能をより良く作れるようになるシステム」だ。これは4つの動作に落とし込まれる。
2番目のステップにあるYAML frontmatterとは、ドキュメント冒頭に付けるメタデータタグ（タイトル、分類、キーワード）のことで、この解決策が後から条件で検索・正確に取り出せるようにするためのものだ。書いた後に大量のドキュメントに埋もれて見つからなくなるのを防ぐ。
従来の開発は第3ステップの審査で止まるが、Compound Engineeringはもう1歩進み、解決したばかりの問題をシステムに書き込む。このステップはコードを生み出さない。生み出すのは「システムが次回から同種の問題を自動的に避けられる」能力だ。効率の差はここから生まれる。
CLAUDE.mdはプロジェクトのルートディレクトリに置かれた「AI操作マニュアル」で、agentは起動するたびにまずこれを読む。新入社員が入社時に必読するSOPマニュアルのようなもので、誰かがそれまで遭遇したことのない問題を解決するたびに、ルールを1条書き足す。次に来た人は自動的にそれを理解でき、同じ落とし穴をもう一度踏まずに済む。
次の切り替えで、このルールが積み上がった後の違いを直感的に見ることができる。
agentはこの落とし穴を知らない。あなたはagentと一緒にデバッグし、原因を特定し、修正する。修正後、Compoundステップが「なぜ起きたか、どう避けるか」をCLAUDE.mdに書き込み、YAMLタグ付きのドキュメントを1本docs/solutions/に保存する。今回は記録に少し余分な時間がかかった。
agentは起動した瞬間にそのルールを読み込んでおり、docs/solutions/でも前回の解決策を検索できる。だからPlan（計画）段階で、agentは同種の問題を先回りして避け、そもそもバグが出るところまで到達しない。前回記録にかかった時間は、ここで元利合わせて回収される。
Compoundを1回終えるたびに、CLAUDE.mdに知識が1条増え、システムは使うほど賢くなる。
docs/solutions/がどう組織の知識ベースへと積み上がっていくか
14体のAIが同時にコードを審査してくれる
1件のPR（コード変更の提出）が来ると、/workflows:reviewコマンドが14体の専門agentを一斉に派遣し、同時に走らせる。それぞれが1つの観点だけを見る——セキュリティ、パフォーマンス、アーキテクチャ、データ、コード品質、フレームワーク規約など。各自が個別にチェックし、最後に結果を統合してP1（必須修正）/ P2（修正すべき）/ P3（修正してもよい）で優先順位付けされた一覧にまとめる。
02番のagentが専門に見張っているN+1クエリとは、データベースのパフォーマンスにおけるよくある落とし穴だ。100件のリストを1回クエリするつもりが、書き方を誤ると各行ごとに個別クエリが発生し、合計101回のリクエストになる。スーパーで10品買うのに11回足を運ぶようなものだ——まず何があるか見に行き（1回目）、その後1品ずつ取りに戻る（残り10回）。
14系統の並行結果はマージ・重複排除され、優先順位付きの一覧にまとめられる。だいたいこんな見た目になる。
一覧ができた後どう処理するか
プラグインの中身と使い方
一連の流れは1つのプラグインにパッケージ化されており、インストールすればすぐ使える、設定不要。Claude Codeに対応し、OpenCodeとCodexも実験的にサポートしている。
各ファイルの役割
2行のコマンドでインストール完了（Claude Code）
OpenCode / Codexのインストールコマンド、および1コマンドで全パイプラインを実行する方法
bunx @every-env/compound-plugin install compound-engineering --to codex
キーとなる数字：並行agentの規模はどれくらいか
このシステムの規模をいくつかの具体的な数字に落とし込んでみる。
すべてのエンジニアリングの仕事は、その後に続く仕事をより簡単にするべきであって、より難しくするものであってはならない。Every『Compound Engineering』
コードベースが「触るほど大変」から「使うほど楽」に変わる差は、飛ばされがちな第4ステップにある
Everyは「Compound Engineering」でほぼ一人のチームが5つのプロダクトを支えている。秘訣は機能を作り終えるたびにもう一手間かけること——解決策をシステムに保存し、AIが次回から自動で同じ落とし穴を避けられるようにする。図付きで1枚にまとめた。
↓ 1枚で読み切れる · 動く図が1つあります
EveryはAIプロダクトを作る会社で、Cora、Monologue、Sparkle、Spiralと公式サイトを合わせて5つのプロダクトを持ち、各プロダクトのエンジニアリングチームは基本的に1人しかいない。この規模を支えているのが「Compound Engineering（複利エンジニアリング、毎回やった作業が次回の労力を減らしていく方法）」だ。
これが治そうとしているのは、従来のコーディングの古い悪癖だ——機能を1つ追加するたびにシステムに複雑さを積み増していき、10年経つとチームは新しいものを作るより過去のコードと格闘する時間の方が長くなる。さらに割に合わないのは、苦労して解決した問題が使い捨てられ、同種の落とし穴に次もまたゼロから踏み直すことになる点だ。
✘ しかし解決済みの問題は蓄積されず、同種の落とし穴に次もまたゼロから当たる
従来のフローは「審査」で完了とし、AIが今回学んだことは使い終われば捨てられる。複雑さは増える一方で減らず、コードはどんどん触りにくくなる。
Compound Engineeringを突き詰めると、計画・実行・審査・固化の4ステップサイクルだ。最初の3ステップはどのプログラマにもおなじみ。カギは、従来のエンジニアリングが「審査」で止まるところを、もう1歩「固化」まで進め、今回の解決策をシステムに書き戻す点にある。
違いは最後の1ステップだけだ。従来型は「審査」で完了とし、今回の解決策は使い終われば捨てられる。Compound Engineeringはさらに「固化」を1歩進め、解決策をシステムに書き戻す。次はAIが起動すると、それを最初から持っている。では具体的に「システムに書き戻す」とはどういうことで、AIはどうやって自動的に落とし穴を避けるのか——1枚の図で見てみよう。
第4ステップの「固化」を具体的に落とし込むと——問題を1つ解決するたびに、その解決策をCLAUDE.md（AIが起動のたびに最初に読む操作マニュアル）に書き込む、というだけのことだ。ここでは小互（本サイトの運営者）が同じバグに繰り返しぶつかる例で、従来型とCompound Engineeringの違いを見てみよう。
「何倍速くなった」と言われても普通の人にはピンと来ない。時間に換算するとはっきりする。Compound Engineeringの最も分かりやすい省き方は、「審査」のような繰り返し作業をまるごとシステムに任せてしまうことだ。
もう1つの節約は「並行化」だ。コードを1回審査するのに、14体の専門AI（それぞれ1つのことだけを担当するAIアシスタント）が同時に動く。計画を立てるときにultrathink（より深い思考モード）を開けば、一度に40体以上のリサーチAIを派遣できる。規模を数字に落とすと以下の通り。
以上の数字はすべてEveryチームの自社発表によるもので、公式発表の数字であり、第三者による独立した再現は行われていません。
直したはずじゃ？
- × 直したら終わり、
解決策は使い捨て - × 同じ落とし穴に、
次もまた当たる - × 複雑さは増える一方、
どんどん触れなくなる
覚えさせられない？
直すの!?
もう記録済み。
時間の8割、
コードを書くのは2割だけ。