深掘り · 小互解説
どのチームも飛ばす第四ステップこそ、AI エンジニアリングの鍵
Every は一人チームで 5 つのプロダクトを運営する。核心は、機能を仕上げるたびに加えるもう一手——解法をシステムに保存し、次は AI が自動で落とし穴を避けられるようにすることだ。
概要
Every は「複利エンジニアリング」（Compound Engineering）という方法論で、ほぼ一人のエンジニアチームながら傘下の 5 つのプロダクトを維持している。核心は Plan → Work → Review → Compound の四ステップ循環だ。
従来のエンジニアリングは Review で止まる。第四ステップの Compound は、毎回解決した問題をシステムの知識へ変え、次は AI が同種のミスを自動で避けられるようにする。効率の差はここから生まれる。
この方法論では、エンジニアの時間の 80% を Plan と Review に充て、実際にコードを書くのはわずか 20% だと説く。
付属のプラグインはオープンソース化済みで、Claude Code / OpenCode / Codex に対応。26 個の専用 agent、23 本のワークフローコマンド、13 個のスキルを備え、設定ゼロですぐ使える。
/workflows:review は一度の呼び出しで 14 個の専用 agent を並行させてコードを審査し、/workflows:plan は ultrathink モードで 40 個超の調査 agent を並行できる。
⚑ 立場の注記：本稿は Every チームが自ら語る「複利エンジニアリング」方法論と、自社オープンソースプラグインの実践だ。並行規模・時間配分・プロダクト数はいずれも公式発表に基づく。以下では、その仕組みと各数字の意味だけを解説する。
1 背景
一人で 5 つのプロダクトを支える、その方法とは
Every チームは先ごろ「複利エンジニアリング」（Compound Engineering）という方法論と、それに付属するオープンソースプラグインを公開した。ほぼ一人体制のエンジニアチームで、傘下の 5 つのプロダクトをどう同時に維持しているかを語っている。
5 つのプロダクト Cora、Monologue、Sparkle、Spiral、それに公式サイト Every.to——どのプロダクトもエンジニアチームは基本的に一人だけ。この規模を支えているのは、長い労働時間ではなく、四ステップ循環のうち大多数のチームが省いてしまう最後の一手だ。
◆
なぜ読む価値があるか：Every は普段は社内だけで回していたものをオープンソース化した。14 個の AI が一つのコードを同時に審査 、計画段階では 40 個超 の調査 agent を並行、さらに 26 個 の専用 agent も含む。これは現在公開されているマルチ agent 並行エンジニアリングの実践のなかでも、数字が最も具体的なオープンソース参考例の一つだ。
2 問題
コードは書くほど触りにくくなる、その根源は
ほとんどのコードベースは時とともに保守が難しくなる。理由は単純だ。機能を一つ足すたびに、新たな複雑さがシステムへ注ぎ込まれ、新機能はすべての旧機能と「交渉」しなければならない。十年も経つと、チームが過去のコードと格闘する時間は、新しいものを作る時間より多くなり、コードはどんどん読みにくく、変えにくく、信頼しにくくなる。
複利エンジニアリングはこの曲線を逆転させる。機能はもはやシステムへ負担を足すものではなく、システムに新しい技を一つ覚えさせるもの。bug を一つ直せば、ついでに将来の同種 bug を丸ごと一掃する。解法が一つ固定されれば、次回そのまま再利用できるツールになる。反復が増えるほど、システムは使いやすくなる。
従来：直すほど大変に
複利：使うほど快適に
機能／反復が増えるほど →
一か所を直す手間 →
同じ横軸（機能／反復が増えるほど）で、行き先は二つ。従来のコードベースは一か所直すのがどんどん大変になり、複利エンジニアリングは反復のたびにシステムをより快適な土台へ整えていく。
3 メインループ
四ステップ循環：時間の 80% は実はコードを書いていない
この規模を支えているのは、一つの四ステップ循環だ。Plan（計画）、Work（実行）、Review（審査）、Compound（定着）、そして繰り返す。5 分で bug を直すときも、数日かけて機能を作るときも、通る道はこの四ステップで、各ステップにかける時間が違うだけだ。
最初の三ステップはどの開発者にもなじみがある。第四ステップの Compound こそが、複利エンジニアリングと普通のエンジニアリングを分ける境界線だ。これを飛ばせば、やっていることは「AI アシスタント付きの従来型エンジニアリング」にすぎない。
Plan
計画
Work
実行
Review
審査
Compound
定着
従来はここで終了 ✕
複利は一歩先へ
繰り返し：次の周は前周で定着した知識を自動で引き継ぐ ↻
四ステップが深緑のレール上を順に流れる。従来のエンジニアリングは Review で手を引くが、複利エンジニアリングは Compound の一歩を加え、この周で学んだものを次の周へ残す。
直感に反する点：コードを書くのは時間の 2 割だけ
Plan と Review を合わせるとエンジニアの時間の 80% を占め、実際に手を動かして書く（Work）と定着（Compound）はわずか 20% にすぎない。思考の大半は、コードが書かれる前と後に起きている。
四ステップで各々何をするか／Every が捨てるよう勧める旧来の通念いくつか
Plan 計画： アイデアを設計図に変える。要件と制約を明確にし、コードベース内で同種の機能がどう実装されているかを調べ、フレームワークのドキュメントとベストプラクティスを確認し、設計案を立て、その案が妥当かを検証する。
Work 実行： まず git worktree（リポジトリの隔離されたサンドボックス複製。複数のタスクがそれぞれ一つずつ並行で動かせて互いに干渉しない）で隔離環境を作り、agent が計画に沿って一歩ずつ実装し、一か所直すたびにテスト、linting（コードの自動チェック）、型チェックを走らせる。
Review 審査： 複数の専用 agent が並行で審査し、問題を P1（必ず直す）／ P2（直すべき）／ P3（直してもよい）に分類。直したあと再検証し、今回どんな問題が出たかを記録する。
Compound 定着： 解法を再利用できる知識へ抽出してシステムに書き戻す。次の節で詳しく扱う。
Every はさらに、捨てるべき旧来の通念をいくつか挙げている。「コードは手で書かねばならない」（あなたの仕事は、保守でき、正しい問題を解く良いコードを生むこと。誰がキーを叩くかは重要ではない）。「初版から良く書くべき」（彼らの経験では初版は 95% がゴミ、第二版でもまだ 50%。これは過程であり、目標は、第三版を仕上げるほうが初版より速くなるくらい反復を速くすること）。「自分で叩かないと身につかない」（今は理解が筋肉記憶より大事。AI の実装を 10 個審査するほうが、手で 2 個叩くより多くのパターンを学べる）。「コードは自己表現だ」（コードは決してあなた個人のものではない。チーム、プロダクト、ユーザーのものだ）。
4 第四ステップ · 核心
第四ステップの具体的なやり方：解法をシステムの記憶に変える
最初の三ステップ（計画、実行、審査）が生み出すのは「一つの機能」だ。第四ステップ Compound が生み出すのは「機能を毎回より良く作れるようになるシステム」だ。それは具体的には四つの動作に落ちる。
① 解法を記録 何が効いて何が効かなかったか、再利用できる点はどれか
→
② メタデータを付与 YAML frontmatter でタグ付けし、後の検索を楽にする
→
③ CLAUDE.md を更新 agent が起動のたびに読むファイルに新パターンを書き込む
→
④ 学習を検証 次は同種の問題を自動で受け止められるか
第二ステップの YAML frontmatter とは、ドキュメント冒頭に置くメタデータのタグ（タイトル、分類、キーワード）のこと。この解法を後から条件で検索でき、正確に取り出せるようにする——書いたきり大量のドキュメントに埋もれて見つからない、という事態を防ぐ。
複利の源泉
従来の開発は第三ステップの審査で止まる。複利エンジニアリングはこの一歩を加える——たった今解決した問題をシステムへ書き込むのだ。このステップはコードを生まない。生むのは「システムが次回、同種の問題を自動で避ける」能力だ。効率の差はここから生まれる。
たとえるなら
CLAUDE.md はプロジェクトのルートに置く「AI の操作マニュアル」で、agent は起動のたびにまずこれを読む。新入社員が入社時に必読の SOP マニュアルのようなもの——誰かがこれまで出会わなかった問題を解決するたびにルールを一条加えれば、次に来た人は自動で分かり、同じ落とし穴をもう一度踏まずに済む。
次の切り替えを見れば、このルールが積み上がったあとの違いが直感的に分かる。
Compound を一度終えるたびに CLAUDE.md は知識が一条増え、システムは使うほど賢くなる。
docs/solutions/ がどうやって組織の知識ベースへ育つか
解決したすべての問題が、YAML frontmatter 付きの markdown として保存され、自動で分類・タグ付けされる。Every はこのステップを /workflows:compound コマンドで走らせる。並行で六つの子 agent を派遣する——問題を理解するもの、解法を抽出するもの、関連する旧ドキュメントを見つけて相互リンクするもの、「再発をどう防ぐか」を書くもの、分類タグを付けるもの、最後に整形してドキュメントにするもの。以降はどのセッションでも、この一群のドキュメントから過去の解法を自動で引き出せる——ベテランエンジニアの頭の中の記憶に頼らずに。
5 並行審査
14 個の AI が同時にコードを審査
PR（コード変更の提出）が一件入ると、/workflows:review というコマンドが一度に 14 個の専用 agent を派遣し、同時に走らせる。各 agent は一つの観点だけを見る——セキュリティ、性能、アーキテクチャ、データ、コード品質、フレームワーク規約など。それぞれが別々に調べ、最後に結果を P1（必ず直す）／ P2（直すべき）／ P3（直してもよい）の優先度順に並べた一覧へまとめる。
1 件の
PR
14 個の専用 agent が同時に稼働
1
2
3
4
5
6
7
8
9
10
11
12
13
14
一件の PR が同時に 14 個の agent へ放射状に広がる。色は下の観点グループに対応する。順番待ちではなく、並行で走る。
01 security-sentinel · セキュリティ
OWASP Top 10（最も悪用されやすいとされる 10 種のセキュリティ脆弱性）、インジェクション攻撃、認証と権限昇格をスキャン。
02 performance-oracle · 性能
N+1 クエリ、欠けたインデックス、キャッシュ可能な箇所、アルゴリズムのボトルネックを洗い出す。
03 architecture-strategist · アーキテクチャ
システム設計、コンポーネントの境界、依存の方向を評価。
04 pattern-recognition-specialist · アーキテクチャ
デザインパターン、アンチパターン、コードの臭いを識別。
05 data-integrity-guardian · データ
DB マイグレーション、トランザクション境界、参照整合性を検証。
06 data-migration-expert · データ
ID マッピング、ロールバックの安全性、本番データの検証をチェック。
07 code-simplicity-reviewer · 品質
YAGNI（使うかもしれない機能を先回りで書くな）を徹底し、余計な複雑さを洗い出す。
08 kieran-rails-reviewer · 品質
Rails 規約、Turbo Streams、モデルとコントローラの責務分担。
09 kieran-python-reviewer · 品質
PEP 8 規約、型アノテーション、Pythonic な書き方。
10 kieran-typescript-reviewer · 品質
型安全、モダンな ES の書き方、クリーンアーキテクチャ。
11 dhh-rails-reviewer · 品質
37signals 流：抽象より単純さを優先。
12 deployment-verification-agent · デプロイ
リリース前チェックリスト、リリース後の検証手順、ロールバック計画を生成。
13 julik-frontend-races-reviewer · フロントエンド
JavaScript と Stimulus コントローラ内の競合状態を洗い出す。
14 agent-native-reviewer · Agent-native
機能が人だけでなく agent でも使えることを保証。
N+1 クエリとは
02 番の agent が専門に見張る N+1 クエリは、データベース性能でよくある罠だ。100 件のリストを取得するとき、書き方を誤ると一件ごとにもう一度個別に問い合わせることになり、合計 101 回のリクエストになる。スーパーへ 10 品を買いに行ったのに 11 往復するようなもの——まず何があるか見に行き（1 往復）、それから一品ずつ個別に取りに行く（10 往復）。
14 系統の並行結果は統合・重複排除され、優先度付きの一覧にまとまる。だいたいこんな形だ。
P1 · 必ず直す
☐ 検索クエリに SQL インジェクションの脆弱性 security-sentinel
☐ ユーザー作成にトランザクションの包みが欠如 data-integrity-guardian
P2 · 直すべき
☐ コメント読み込みに N+1 クエリ performance-oracle
☐ コントローラに業務ロジックが詰め込まれている kieran-rails-reviewer
P3 · 直してもよい
☐ 未使用の変数が一つある code-simplicity-reviewer
一覧が出たあとどう処理するか
/resolve_pr_parallel はすべての問題を自動で処理する。先に P1、次に P2 を直し、各修正はそれぞれ隔離して走るので互いに踏み合わない。最後に、生成された変更をあなたが手で一通り確認する。先に選別してから直したいなら /triage を使う——一条ずつ、承認（待機リストへ）、スキップ（削除）、優先度変更を人が決め、承認したものを status: ready とマークして /resolve_todo_parallel に任せる。
6 プラグイン
プラグインの中身と、入れたあとの使い方
一連のフローはひとつのプラグインにまとめられ、入れればすぐ使える、設定ゼロ。Claude Code に対応し、OpenCode と Codex にも試験的に対応する。
26
専用 agent
どれも一つのことだけに長ける——14 個の review 専門家に加え、調査型、設計型、自動化、ドキュメント型。
23
ワークフローコマンド
メインループのコマンド（plan / work / review / compound）に、実用ツール系コマンド一式を加えたもの。
13
スキル
すぐ使える領域知識。たとえば agent-native アーキテクチャのスキル、スタイルガイドのスキルなど。
どのファイルが何を担うか
CLAUDE.md agent が起動のたびに必読の操作マニュアル：好み、取り決め、踏んだ落とし穴。
docs/solutions/ 解決した問題ごとに検索可能なドキュメントとして保存し、次のセッションで自動的に見つかる。
docs/plans/ · brainstorms/ /plan と /brainstorm の成果物。
todos/ review が見つけた問題。優先度と状態付き。
二行のコマンドで導入完了（Claude Code）
claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering
OpenCode / Codex のインストールコマンド、そして一つのコマンドでパイプライン全体を走らせる方法
bunx @every-env/compound-plugin install compound-engineering --to opencode
/lfg ：機能を説明するだけで、パイプライン全体をつなげて自動で走らせる。計画 → 計画の深掘り → 実行 → 審査 → 問題の修正 → ブラウザテスト → 機能デモの録画 → 定着。全工程で 50 個超の agent を派遣し、最後にそのままマージできる PR を渡してくれる。途中で止まるのは計画の承認のところだけだ。
7 数字
重要な数字：並行 agent の規模はどれほどか
このシステムの規模を、いくつかの具体的な数字に落とし込む。
5 つ
Every がこの方法で維持するプロダクト数。エンジニアチームは基本的に一人体制。
80% / 20%
計画＋審査がエンジニアの時間の 80% を占め、実行＋定着はわずか 20%。
14 個
/workflows:review の一度の呼び出しで同時に走る専用審査 agent の数。
40+ 個
/workflows:plan を ultrathink モードにしたとき派遣される調査 agent の数。
26 / 23 / 13
プラグインが含む専用 agent 数／ワークフローコマンド数／スキル数。
どんなエンジニアリングの仕事も、後続の仕事をより難しくではなく、より易しくするべきだ。Every『Compound Engineering』
本稿は Every チームが自ら語る「複利エンジニアリング」方法論とオープンソースプラグインの実践であり、文中の並行規模・時間配分・プロダクト数はいずれも同社の公式発表に基づく。原文：Every『Compound Engineering』、every.to/guides/compound-engineering。プラグインのオープンソース URL：github.com/EveryInc/compound-engineering-plugin。