秒～分のフィードバック：フィードバックチャネルとしてのCI/CD

Linterは構文や型の問題をミリ秒で検出するが、より深い問いには答えられない：コードはビルドに成功するか？モジュール間の依存関係は壊れていないか？統合テストは通るか？これらの問いには実際にビルドとテストプロセスを実行する必要があり、フィードバック遅延はミリ秒から秒・分へと押し上げられる。

従来の開発では、CI/CDパイプラインの役割はデプロイメントだった：コードを書き、パイプラインに通し、デプロイする。Agent駆動開発では、その主な役割がシフトする：パイプラインはまず何よりもフィードバックチャネルであり、デプロイツールは二次的な役割となる。各コミット後、パイプラインがAgentに伝える：ビルドは成功したか失敗したか？どのテストが壊れたか？統合ポイントは無事か？これらのシグナルがAgentの次のアクションを決定する。

これはパイプライン設計の優先順位を変える必要があることを意味する。従来のパイプラインは完全性と安全性を最適化する：全テストを実行し、全チェックを通過させ、承認を得てからデプロイする。Agent駆動パイプラインはまず速度を最適化しなければならない：Agentは自分のコードに問題があるかどうかをできるだけ早く知る必要がある。フルCIの実行に40分かかるなら、Agentは40分間アイドルで待つか、未検証の前提に基づいてコードを書き続けるかのどちらかになる。どちらも理想的ではない。

解決策はCIのカバレッジを減らすことではなく、層を分けることだ。第1層は高速フィードバック層：現在の変更に直接関連するビルドとテストのみを実行し、数十秒以内に結果を返す。第2層は完全検証層：全テストと統合チェックを実行し、非同期で処理する。Agentは第1層の高速フィードバックで作業し、第2層で問題が見つかれば、中断して修正する。

Multi-Agent並列シナリオでは、CI設計にもう一つの重要な要件がある：トレーサビリティだ。3つのAgentが3つのブランチで同時に作業しているとき、CI結果は特定のAgentと特定のタスクに明確に関連付けられなければならない。「ビルド失敗」では不十分だ。「Agent Bがタスク#42でpayments/handler.goを修正し、統合テストTestPaymentFlowが失敗した」というレベルが必要だ。このレベルのトレーサビリティがなければ、帰属不明な赤マークの山を前にすることになる。

統合頻度も上げる必要がある。従来のチームは1日1回統合するかもしれない。複数のAgentが並列で作業している場合、各Agentはアトミックなタスクを完了するたびに統合をトリガーすべきだ。逸脱の修正コストはその逸脱が存在した時間に比例する：2つのAgentがそれぞれ1日作業してから統合すると、発見されたコンフリクトは1日分のロールバックを必要とするかもしれない。1時間ごとに統合すれば、最悪でも1時間分で済む。

パイプラインの安定性も同様に重要だ。CIにflaky test（ランダムに失敗するテスト）がある場合、Agentは「自分のコードに問題がある」と「CI自体が不安定」を区別できない。人間にとってflaky testは小さな煩わしさだ --- 再実行すればいい。Agentにとってflaky testは偽のシグナルだ：存在しない問題の「修正」に大量のトークンを費やすか、逆に「前回もこうだったけど再実行したら直った」からとテスト失敗を無視するようになるかもしれない。Flaky testの排除はあれば良いものではなく、プラットフォーム信頼性のベースラインだ。