以前の記事で、エージェントが書いたコードをバリデーションするための基本的なアプローチについて説明しました。フィードフォワードとフィードバックという2つの手法です。フィードフォワードは、より良いプロンプトや計画戦略を立てるなど、エラーを事前に防ぐ手法です。フィードバックは、タスクが実際に達成されたことをエージェントに知らせるシグナルです。フィードバックは、RalphループやCodexやClaude Codeの/goalコマンドのような一般的なエージェントパターンの重要な要素です。既知の条件を満たすまで作業を続けるという仕組みです。
この記事では、エージェントのフィードバックループを構築する際に発生する問題と、CircleCIで効果的だと分かった代替手段について説明します。
インフラがバリデーションのボトルネックになる
バリデーションチェック、つまりリンター、テスト、あるいは他のエージェントであっても、どこかで実行する必要があります。開発環境では通常、エンジニアのノートPC、リモートVMやCodespace、あるいはリモートのビルドシステムで実行されます。エージェントにコードを書かせる場合も同様です。しかし、エージェントは従来のローカルおよびリモートのテストアプローチに新たな問題をもたらします。同時に、より効率的かつエージェントファーストな方法でコードをテスト・バリデーションする機会も生まれます。
ローカルバリデーションを第一段階として
初期段階では、ほとんどのチームがコーディングエージェントと同じマシンでバリデーションを実行します。このアプローチには多くの利点があります。開発者はおそらく既に作業環境を持っており、その環境からエージェントを操作し、エージェントから作業を引き継ぐ必要があればIDEに切り替えることもできます。コーディングエージェントはテスト、リンター、ビルドコマンドの実行方法やエラーの修正方法を理解しています。これはAI導入前にエンジニアが行っていた作業の実用的な延長線上にあります。
しかし、複数のエージェントを長時間実行し始めると、いくつかの問題が浮上してきます。
- 1台のマシンで複数のサービスインスタンスを実行するのは困難です。十分なCPUとRAMがあっても、すべてを
localhostで動作するフルスタック環境を構築するのは骨が折れます。 - 大規模なバリデーションスイート（Playwrightテストなど）は大量のリソースを消費し、最終的にはノートPCの動作が遅くなります。
- ローカル環境はエンジニア固有の設定や環境の癖で「汚れて」いきます。クリーンなCI環境でテストを実行する理由の1つは、「自分のマシンでは動く」が既知の正常な環境では動かないというケースを排除することです。
- ほとんどのチームでは、ローカルバリデーションは承認プロセスとしては「有効」とみなされません。エージェントが必要なチェックをすべて実行しても、結局はCIパイプラインがマージ承認チェックを通過するのを待つことになります。
これらの問題はすべて解決可能です。再現性を確保するためにエージェントをマシン上のコンテナで実行させることができます。Vercelのportlessのようなツールはlocalhostの問題を解決するのに役立ちます。ただし、通常はアプリケーションに変更を加える必要があり、開発者間でセットアップの一貫性を維持しなければなりません。
エージェントとバリデーション環境を同居させる、より大きな問題は、それが生み出す密結合です。開発者がエージェントのいるマシンにフルアクセスでき、自分で複数のエージェントを実行している場合、エージェントが行き詰まったときにいつでもトラブルシューティングできます。しかし、Devinのような自動化やバックグラウンドエージェントシステムを通じた、クラウドベースのエージェントによるコーディングが増えています。ここでは環境管理がより複雑になります。initスクリプトやカスタムコンテナで環境をカスタマイズできますが、最終的にはエージェントインフラプロバイダーがサポートする内容に依存します。エージェントがタスクに長時間取り組むほど、障害の可能性も高くなります。ローカルディスクがいっぱいになったり、メモリが枯渇したり、エージェントが誤ってマシンを壊してしまうと、すべてがクラッシュします。
すべてを統べる1つの環境を設定しようとするのではなく、バリデーション環境をエージェントがアクセスでき、完全にカスタマイズ可能なツールとして提供する方がはるかに柔軟です。エージェントとバリデーション環境を独立して入れ替えることができます。環境を受け渡すことで、エージェント間で作業を引き継ぐことさえ可能です。ClaudeのManaged Agentのデザインや、Deepagentsのプラグイン可能なサンドボックスがこのアプローチの例です。
CIをフィードバックソースとして使う
この時点で、多くのチームは自分たちが既にリモートでスケーラブル、かつ再現可能な環境を持っていることに気づきます。CIパイプラインです。どうせCIを通す必要があるなら、エージェントにCIへプッシュさせ、CIからのフィードバックをループすればいいのではないでしょうか。CodexとClaude Codeには、CIが通りレビュアーが満足するまでPRを見守るスキルがあります。CIの活用には多くの利点があります。アプリのインスタンス数の制約がなくなり、どのチェックが実行されるか正確に把握でき、エージェントがシークレットに直接アクセスできないセキュリティバリアが組み込まれています。
このアプローチは機能します。しかし、ローカルバリデーションと同様に多くの欠点があります。まず、CIパイプラインにはスタートアップのオーバーヘッドがあります。「クリーンな」環境の欠点は、毎回ゼロから始めなければならないことです。次に、多くのCIパイプラインはエージェントが必要とする以上のバリデーションを実行します。CIはゲートとして機能するため、組織が行うあらゆる種類のチェックが集約されます。CVEチェック、ドキュメント生成、パフォーマンステストなどです。そしてこれらのチェックは、実際に変更したコードに関係なく毎回実行されます。クリーンな環境と同様、これが自動化の意義です。mainを壊さないための一貫性が必要ですが、開発中のコードにはおそらく過剰です。
さらに、ほとんどのCIパイプラインは比較的まれなエラーをキャッチするように構築されています。CIのセットアップでは、ビルドステップをファンアウトして並列実行するのが一般的なアプローチです。CircleCIを含むほとんどのCIシステムは、1つのジョブが失敗してもファンアウトされた他のジョブの実行を停止しません。開発者がビルドを修正できるよう、すべてのフィードバックを収集したいからです。そうしないと、リントエラーがテストの失敗を隠してしまう可能性があります。エンジニアがプッシュ前に必ずローカルでテストを実行していると仮定すれば、ほとんどの場合は通過するため、ビルドの実時間を短縮できます。しかし、開発中はテストが壊れたり、リンターに通らないコードを書いたり、CIでビルドが壊れるようなことをしがちです。CIパイプラインをフィードバックソースとして使う場合、多くの失敗を経験することになりますが、パイプラインがまだ実行中のためフィードバックを得るまでに時間がかかることがあります。
さらに、エージェントにフィードバックを届ける問題があります。CIシステムはエージェントにビルド出力を提供できますが、直接的なコマンド出力ほどダイレクトではありません。通常、APIを経由し、ログを再構成し、問題を診断する必要があります。これらすべてが、必要な情報を収集するためにトークンを消費することになります。
最後に、コストの問題があります。反復的に作業するエージェントはCI使用量を大幅に押し上げ、コストを増加させます。
ローカル開発と同様に、CIプロセスに変更を加えてより良い開発ループにすることは可能です。キャッシュにより依存関係のインストール時間を短縮できます。ビルドシステムがサポートしていれば、インクリメンタルビルドも可能です。高いファンアウトの問題を防ぐために、より「悲観的な」特別なパイプラインを作成し、チェックのサブセットを順次実行したり、単一ジョブとして実行することもできます。これらの「開発用」パイプラインは、エージェントに結果を単一ファイルで提供し、ツールの使用とトークン消費を抑えることができます。欠点は、CIパイプラインが本来想定していない機能を後付けしようとしていることです。例えば、フルパイプラインの実行を避けるためにトリガーの設定に注意する必要があります。
Chunkサイドカー + マイクロビルドの登場
本当に必要なのは、両方の良いところを合わせたものです。リモートのテスト環境と、エージェントに優しいフィードバック、そして特定のチェックが既に実行済みであることを証明する方法。すべてをCIコストの爆発なしに実現することです。
Chunkサイドカーは、Firecracker microVMランタイムをベースにした高速なリモート環境です。microVMアプローチにより、速度、スケーラビリティ、コスト効率の面で大きなメリットが得られます。microVMはリモートで実行されるため、単一マシンのリソースに制約されません。環境は数十ミリ秒で起動し、一般的なCIジョブよりも高速です。また、使用していないときにmicroVMをサスペンドし、エージェントがテストする必要があるときに再起動することもできます。イテレーションのたびに新しいVMやコンテナでフルCIパイプラインを実行する代わりに、セッション全体で同じインスタンスを再利用できます。これは開発者のフローにはるかに近い形です。また、既知のスナップショットをベースにmicroVMを作成できるため、初期化と依存関係のインストールを定期的に行い、環境を最新の状態に保つことができます。スナップショットアプローチにより、インスタンスが不安定になった場合、それを破棄して既知の正常なポイントから新しいインスタンスを起動できます。完全な密閉的再現性ではありませんが、エージェント開発にとっては許容できるトレードオフです。
Chunkサイドカーが環境を提供し、マイクロビルドがフィードバックを提供します。マイクロビルドの考え方はシンプルです。CIで実行する内容を凝縮したバージョンを実行するということです。これは開発中の作業用に特別なパイプラインを持つのに似ていますが、CIシステムをいじる必要がありません。エージェントがchunk validateを実行すると、コマンドはChunkサイドカー上で直接実行され、出力はエージェントに直接送られます。CIパイプラインをポーリングする代わりに、結果がエージェントに直接返され、テストが通るまでイテレーションを続けることができます。エージェントはアクセス権も持っています。これはChunkサイドカーへの常時オンの「SSHデバッグ」オプションのようなものです。そのため、エージェントはコード内の正当な障害と環境の問題を区別し、修正を提案することができます。
デフォルトでは、gitリポジトリに変更がある場合、エージェントのストップイベントごとにマイクロビルドの実行をトリガーするフックを使用しています。ストップイベントは、エージェントがエラーを表面化する前に過度なコードを書くことを防ぎつつ、作業中にエージェントが自律的にチェックを実行する余地を残す、適度な頻度です。ただし、ChunkサイドカーはCLIでプログラマティックに作成できるため、エージェントが（例えば）テストをシャーディングするために複数のサイドカーを作成することも可能です。
マイクロビルドはインクリメンタルに設計されています。CIパイプラインの煩わしい点の1つは、コミットを作成し、プッシュして、結果を待たなければならないことです。マイクロビルドでは、ローカルのチェックアウトからリモートのChunkサイドカーへ、gitのパッチメカニズムを使用してインクリメンタルに同期します。これにより、エージェントのレイテンシーをさらに短縮できます。
結果
CircleCIでは、Chunkサイドカーとマイクロビルドのパターンを使用してChunkサイドカー自体を開発しています。
これまでの結果は有望です。
- トークン効率：マイクロビルドの出力は、CIログを直接使用するよりもエージェントがエラーを特定する際のトークン効率が3倍です。「有用な」トークンの割合を調べて測定しました。CIログの取得には追加のツール呼び出しが必要で、ログにはインストール出力のように障害の修正に役立たない結果が含まれていることが多いためです。
- コスト効率：Chunkサイドカー環境は、CIパイプラインと比較してコアあたりのコスト効率が10〜20倍です。この改善の大部分は、サイドカーがプリウォームされた環境を持つことでセットアップ時間を削減し、ファンアウトジョブの完了を待つ代わりに素早く失敗できることに由来しています。
今後の展望
現在のChunkサイドカーとマイクロビルドの実装は、目の前の問題に対処しています。コードをバリデーションするために使用する従来のインフラが圧迫されているという問題です。コードを書くプロセスは劇的に高速化しましたが、数千のPlaywrightテストがある場合、それを実行するのに十分なコンピュートが必要で、さらにエージェントの数を掛け合わせると、インフラコストは急速に増大します。
しかし、目の前の問題を超えて見ると、Chunkサイドカーはエージェントファーストインフラというより広いトレンドの一部です。ここ数年、私たちはAI開発を人間向けに構築されたツールに適合させてきました。エージェントをノートPCで実行し、エージェントにPRやCIパイプラインを監視させるといった具合です。しかし、ツールが改善され、エージェントが人間の監視なしに数時間や数日間実行できるようになった今、エージェント専用に構築されたアーキテクチャが増えています。既にエージェントにブラウザを提供しています。Chunkサイドカーにより、エージェントに追加のコンピュータを与えて作業をスケールアウトさせることができます。小規模なエージェント向けクラウド環境も想像できるでしょう。
Chunk CLIをインストールしてプロジェクトでchunk initを実行し、Chunkサイドカーをお試しください。CircleCIアカウントがあれば始められます。デモはこちら。
