https://www.knightli.com/ja/tags/compound-engineering/ Recent content in Compound Engineering on KnightLiブログ Hugo -- gohugo.io ja Fri, 01 May 2026 03:15:39 +0800 https://www.knightli.com/ja/2026/05/01/compound-engineering-plugin-ai-coding-workflow/ Fri, 01 May 2026 03:15:39 +0800 https://www.knightli.com/ja/2026/05/01/compound-engineering-plugin-ai-coding-workflow/ <p><code>Compound Engineering Plugin</code> は、Every Inc が公開している AI コーディングワークフロープラグインです。</p> <p>注目しているのは「AI により速くコードを書かせること」ではありません。AI コーディングを、よりエンジニアリングチームに近いループへ入れることです。まず計画し、次に実装し、その後レビューし、最後に経験を蓄積します。Claude Code、Codex、Cursor、Copilot のようなツールをよく使う人にとって、この種のプラグインはプロンプト問題ではなくワークフロー問題を解決します。</p> <p>AI コーディングツールは強力になっていますが、実プロジェクトで難しいのはコード生成そのものではありません。AI に継続してプロジェクトルールを守らせ、タスク境界を理解させ、同じ間違いを繰り返させず、複数回の反復でコンテキストを蓄積させることです。</p> <h2 id="解決する問題">解決する問題 </h2><p>多くの人は AI コーディングアシスタントを次のような流れで使います。</p> <ol> <li>要件を直接説明する</li> <li>AI にコードを変更させる</li> <li>結果が動くか確認する</li> <li>エラーが出たら追加説明する</li> <li>次のタスクでまた背景を最初から説明する</li> </ol> <p>小さなタスクならこれで十分なこともあります。しかし複雑なプロジェクトでは問題が起こりやすくなります。</p> <ul> <li>要件を整理しないまま AI が編集を始める</li> <li>コード変更後に体系的な review がない</li> <li>プロジェクト規約がユーザーの繰り返しの注意に依存する</li> <li>同じ種類のミスが次回も起こる</li> <li>複数の Agent ツール間で統一した作業方法がない</li> <li>経験が再利用可能なルールとして蓄積されない</li> </ul> <p><code>Compound Engineering Plugin</code> が解決したいのは、この種の問題です。AI コーディングを複数の段階に分け、Agent を単なるコマンド実行者ではなく、より完全なエンジニアリングプロセスの参加者にします。</p> <h2 id="compound-engineering-とは何か">Compound Engineering とは何か </h2><p>プロジェクト README の説明から見ると、Compound Engineering は AI 支援ソフトウェア開発の方法と理解できます。</p> <p>重視するのは次のループです。</p> <ul> <li>計画：目的を理解し、タスクを分解し、方針を確認する</li> <li>実行：計画に沿ってコードを変更し、コマンドを実行し、問題を処理する</li> <li>レビュー：実装品質、リスク、テストカバレッジを確認する</li> <li>学習：経験を後続で再利用できるルールとして蓄積する</li> </ul> <p>このループは実際のエンジニアリングチームの働き方に近いです。</p> <p>信頼できるエンジニアは、要件を受け取ってすぐに無秩序に変更することはありません。変更後に何も確認せず渡すこともありません。まず影響範囲を判断し、実装し、リスクとテスト結果を確認し、最後に踏んだ落とし穴を記録します。AI Agent にも同じような制約が必要です。</p> <h2 id="なぜプラグインが必要なのか">なぜプラグインが必要なのか </h2><p>プロンプトで AI に「先に計画してから実行してください」と伝えることはできます。しかしプロンプト自体は必ずしも安定しません。</p> <p>会話が長くなり、コンテキストが複雑になると、モデルは計画を飛ばしたり、ルールを無視したり、タスク完了を急いで過度に自信を持ったりします。プラグインの価値は、ワークフローを固定し、異なる Agent 環境でも似た方法を守れるようにすることです。</p> <p>この種のプラグインは通常、ワークフローをコマンド、ルール、テンプレート、サブフローに分解します。ユーザーは毎回完全なプロンプトを書く必要がなく、固定された入口から特定の段階を起動します。</p> <p>たとえば：</p> <ul> <li>まず Agent に計画を生成させる</li> <li>計画に沿って段階的に実装する</li> <li>変更後に review を起動する</li> <li>問題が見つかったら修正に戻る</li> <li>残す価値のある経験を記憶やルールに書く</li> </ul> <p>これにより AI コーディングは、一回限りのチャットではなく「制御された協作」に近づきます。</p> <h2 id="対応する-agent-環境">対応する Agent 環境 </h2><p>README では、複数の AI コーディング環境をサポートすると説明されています。</p> <ul> <li>Claude Code</li> <li>Codex</li> <li>Cursor</li> <li>GitHub Copilot</li> <li>Amp</li> <li>Factory</li> <li>Qwen Code</li> </ul> <p>これは注目すべき点です。</p> <p>多くのワークフローツールは 1 つのクライアントにだけ結びついており、ツールを替えるとルールを再利用できません。<code>Compound Engineering Plugin</code> は、クロス Agent のエンジニアリング方法に近く、計画、実行、レビューのような流れを異なるツールへ持ち込みます。</p> <p>複数の AI コーディングアシスタントを同時に使うなら、このような統一ワークフローには価値があります。ツールごとに能力は違っても、プロジェクト規約、レビュー習慣、タスク分解方法はできるだけ一貫している方がよいです。</p> <h2 id="計画段階の役割">計画段階の役割 </h2><p>計画段階の価値は、AI が早すぎる段階で手を動かすのを防ぐことです。</p> <p>複雑なタスクで本当に重要なのは、たいてい次のような問いです。</p> <ul> <li>どのファイルを変更するのか</li> <li>どのモジュールが影響を受ける可能性があるか</li> <li>既存のパターンは何か</li> <li>テストはあるか</li> <li>リスクはどこにあるか</li> <li>先に読むべきドキュメントはあるか</li> <li>より小さなステップに分解できるか</li> </ul> <p>Agent がこれらを考える前にコードを書き始めると、完成しているように見えてもプロジェクト構造から外れた実装になりやすくなります。</p> <p>計画は長い必要はありません。良い計画は短く、具体的で、実行可能です。目的はドキュメントを増やすことではなく、後続の実装に境界を与えることです。</p> <h2 id="実行段階で避けるべきこと">実行段階で避けるべきこと </h2><p>AI がコードタスクを実行するとき、よく起こる問題があります。</p> <ul> <li>関係ないコードをついでにリファクタリングする</li> <li>ユーザーの既存変更を上書きする</li> <li>happy path だけを処理する</li> <li>エラーハンドリングを無視する</li> <li>既存のプロジェクトスタイルに従わない</li> <li>必要な検証を実行しない</li> <li>エラー後に場当たり的に試す</li> </ul> <p>ワークフロープラグインはこれらの問題を完全には消せませんが、ルールと段階制約によって発生確率を下げられます。</p> <p>たとえば、実行段階では Agent に計画どおり段階的に進めさせます。計画範囲外の発見があった場合は、まずリスクを説明します。共有モジュールを変更する場合は、テストを追加するか、少なくとも関連検証を実行します。</p> <p>この制約は大規模コードベースで特に重要です。AI が速くコードを書くほど、その勢いを制限するプロセスが必要になります。</p> <h2 id="レビュー段階が重要な理由">レビュー段階が重要な理由 </h2><p>多くの AI コーディング失敗は、コードがまったく動かないからではありません。細部に問題があるからです。</p> <ul> <li>境界条件が処理されていない</li> <li>状態更新が一貫していない</li> <li>API 契約がこっそり変わっている</li> <li>テストが重要経路をカバーしていない</li> <li>エラーメッセージが分かりにくい</li> <li>性能やセキュリティリスクが触れられていない</li> </ul> <p>レビュー段階は Agent を「作者モード」から「レビューモード」へ切り替えます。</p> <p>作者モードでは自分の実装を正当化しがちです。レビューモードでは、穴、回帰リスク、テスト漏れを積極的に探すべきです。この 2 つの段階を分ける方が、同じ回答内で実装と自己レビューを同時に行わせるより信頼しやすくなります。</p> <p>ユーザーにとっても、レビュー出力は価値があります。その変更をマージしてよいか、まだ修正が必要かを素早く判断できます。</p> <h2 id="学習と記憶の意味">学習と記憶の意味 </h2><p>プロジェクト名の “Compound” は、重要な考え方を示しています。エンジニアリング経験は複利的に増えるべきだ、ということです。</p> <p>AI が毎回のミスをその場で直すだけで、次回また同じミスをするなら、生産性向上は限られます。より良い方法は、価値ある経験を蓄積することです。</p> <ul> <li>このプロジェクトのディレクトリ規約</li> <li>ある種類のエラーの調査方法</li> <li>テストコマンドと注意事項</li> <li>触ってはいけない生成ファイル</li> <li>コードスタイルの好み</li> <li>よく使う実装パターン</li> </ul> <p>これらの経験は、ルール、記憶、ドキュメント、テンプレートになります。後続タスクでは、Agent がまずそれらの蓄積を読み、その後作業を始めます。</p> <p>これが AI コーディングを「一回限りの問答」から「長期協作」へ進める鍵です。</p> <h2 id="向いている場面">向いている場面 </h2><p><code>Compound Engineering Plugin</code> は次のような場面に向いています。</p> <ul> <li>AI Agent を長期的に使ってコードを書く</li> <li>1 つのプロジェクトを何度も、複数回にわたって変更する</li> <li>AI に先に計画してから実装してほしい</li> <li>変更後に review 思考へ自動で入ってほしい</li> <li>チームで AI コーディングフローを統一したい</li> <li>Claude Code、Codex、Cursor など複数ツールを同時に使う</li> <li>プロジェクト経験を再利用可能なルールにしたい</li> </ul> <p>たまに小さなスクリプトを AI に書かせるだけなら、完全なフローは重く感じるかもしれません。</p> <p>しかし AI コーディングアシスタントを日常開発の相棒として使うなら、計画、実行、レビュー、学習のループは明らかに役立ちます。</p> <h2 id="通常のプロンプトテンプレートとの違い">通常のプロンプトテンプレートとの違い </h2><p>通常のプロンプトテンプレートは、「タスクをどう明確に伝えるか」を解決します。</p> <p>たとえば：</p> <ul> <li>一歩ずつ考えてください</li> <li>先にファイルを読んでください</li> <li>コードスタイルを揃えてください</li> <li>テストを実行してください</li> <li>変更内容を要約してください</li> </ul> <p>これらのプロンプトはもちろん有用です。しかし、毎回ユーザーが正しく使うことに依存しています。</p> <p><code>Compound Engineering Plugin</code> は、よりワークフロー層にあります。これらの要求を再現可能なプロセスとして整理し、異なる Agent ツールに適用します。毎回ゼロからプロンプトを書くのではなく、一つのフローの中でタスクを進めます。</p> <p>簡単に言えば、プロンプトテンプレートはリマインダーであり、ワークフロープラグインは制度に近いものです。</p> <h2 id="利用時の注意">利用時の注意 </h2><p>第一に、フローを負担にしないことです。</p> <p>小さなタスクに完全な計画と長いレビューが常に必要なわけではありません。良いワークフローはタスクの複雑さに応じて調整できます。単純な問題は素早く処理し、複雑な問題では完全なループを使います。</p> <p>第二に、レビューはテストの代わりにはなりません。</p> <p>Agent review は多くの問題を見つけられますが、実行時エラーを見逃すことがあります。最終判断には、テスト、型チェック、ビルド結果、人間のレビューが必要です。</p> <p>第三に、ルールは継続的に整理することです。</p> <p>経験の蓄積は重要ですが、ルールが増えすぎるとノイズになります。古いルール、重複ルール、一回のタスクにしか合わなかった一時的な経験は、定期的に整理すべきです。</p> <p>第四に、ツール間で一貫していることは完全に同じであることではありません。</p> <p>Claude Code、Codex、Cursor、Copilot などは能力や対話方式が異なります。統一すべきなのは作業方法であり、すべてのコマンドや設定詳細が同じである必要はありません。</p> <h2 id="向いているチーム">向いているチーム </h2><p>チームがすでに AI Agent に実コードの変更を許可しているなら、「どのモデルが強いか」だけを議論しても不十分です。</p> <p>より重要なのは次の点です。</p> <ul> <li>AI は変更前にタスクを理解しているか</li> <li>AI は変更中にプロジェクト境界を守っているか</li> <li>AI は変更後にリスクを自発的にレビューしているか</li> <li>AI は過去のミスから学べるか</li> <li>チームに統一された Agent 利用規約があるか</li> </ul> <p><code>Compound Engineering Plugin</code> のようなプロジェクトの意味はここにあります。AI コーディングを個人の小技から、チームで再利用できるプロセスへ一歩進めます。</p> <h2 id="参考">参考 </h2><ul> <li><a class="link" href="https://github.com/EveryInc/compound-engineering-plugin" target="_blank" rel="noopener" >EveryInc/compound-engineering-plugin</a></li> </ul> <h2 id="最後に">最後に </h2><p><code>Compound Engineering Plugin</code> が注目に値する理由は、AI コーディングコマンドを一つ増やすことではありません。AI コーディングを、継続的に改善できるエンジニアリングフローとして整理することです。</p> <p>AI Agent が実プロジェクトに参加し始めると、計画、実行、レビュー、経験の蓄積は、一回限りのコード生成より重要になります。</p>