以前、エージェントが書いたコードを検証するための主要なアプローチについて説明しました：フィードフォワードとフィードバックの手法です。フィードフォワード手法は、例えばより良いプロンプトや計画戦略を考えることで、事前にエラーを回避することです。フィードバックは、エージェントが実際にタスクを達成したという信号を与えます。フィードバックは、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 チェック、ドキュメント生成、パフォーマンステスト）の磁石になります。そして、これらのチェックは、実際に変更したコードに関係なく、毎回実行されます。新鮮な環境と同様に、これは自動化の目的です：メインを破壊しないための整合性を望むからです。しかし、開発中の作業にはおそらく過剰です。

次に、ほとんどの CI パイプラインは、比較的稀なエラーをキャッチするように構築されています。CI を設定する一般的なアプローチは、ビルドステップをファンアウトして並行して実行することです。CircleCI を含むほとんどの CI システムは、開発者がビルドを修正できるようにすべてのフィードバックを収集したいため、1つが失敗してもファンアウトされたジョブの実行を停止しません。そうでなければ、リンティングエラーがテストの失敗もマスクする可能性があります。エンジニアが確実にプッシュする前にローカルでテストを実行しているため、ほとんどの場合パスすると仮定すると、これはビルドのウォールクロック時間を短縮します。しかし、開発を進めていると、テストを破壊したり、リンターで失敗するコードを書いたり、CI でビルドを破壊するようなことをしたりする可能性があります。CI パイプラインをフィードバックソースとして使用すると、多くの失敗を経験することになりますが、パイプラインがまだ実行中であるため、フィードバックを得るまでに時間がかかる可能性があります。

次に、エージェントにフィードバックを提供する問題があります。CI システムはビルド出力を提供できますが、直接的なコマンド出力ほど直接的ではありません。通常、API を介してホップし、ログを再構成し、問題を診断する必要があります。これらはすべて、必要な情報を収集するためにトークンを消費することになります。

最後に、コストの問題があります。反復的に作業するエージェントは、CI の使用量を大幅に増加させ、コストを増大させる可能性があります。

ローカル開発と同様に、CI プロセスを変更して、より良いローカル開発ループにすることができます。キャッシングは依存関係のインストール時間を短縮するのに役立ちます。ビルドシステムがサポートしている場合、インクリメンタルビルドを実行できます。高いファンアウトの問題を防ぐために、チェックのサブセットを順次または単一のジョブとして実行する、より「悲観的」な特別なパイプラインを作成できます。これらの「開発」パイプラインは、エージェントに単一ファイルで結果を提供し、ツールの使用と出力によるトークンの消費を削減できます。欠点は、CI パイプラインが本来意図していなかった機能をボルトオンしようとしていることです。例えば、完全なパイプラインが実行されないようにトリガーの設定方法に注意する必要があります。

Chunk sidecar + microbuild の登場

本当に必要なのは、両方の長所：リモートテスト環境、エージェントフレンドリーなフィードバック、そして特定のチェックがすでに実行されたことを証明する方法です。すべて CI コストを爆発させることなく。

Chunk sidecar は、Firecracker microVM ランタイムに基づく高速リモート環境です。microVM アプローチは、速度、スケーラビリティ、コスト効率の点で多くの利点をもたらします。私たちの microVM はリモートで実行されるため、単一マシンのリソースに制限されません。環境は非常に速く起動し、数十ミリ秒で、典型的な CI ジョブよりも高速です。使用されていないときに microVM をサスペンドし、エージェントが何かをテストする必要があるときに再起動することもできます。毎回の反復で新しい VM とコンテナで完全な CI パイプラインを実行する代わりに、同じインスタンスをセッション全体で再利用できます。これは、開発者のフローにずっと近い近似です。また、既知のスナップショットに基づいて microVM をベースにできるため、定期的に初期化と依存関係のインストールを行い、環境を最新の状態に保つことができます。スナップショットアプローチでは、特定のインスタンスが不安定になった場合、それを破棄して既知の良好なポイントから新しいインスタンスを開始できます。これは完全な hermetic 再現性ではありませんが、エージェント開発のための許容できるトレードオフです。

Chunk sidecar は環境を提供し、microbuild がフィードバックを提供します。microbuild の背後にあるアイデアは非常にシンプルです：CI で実行するものの蒸留版を実行することです。これは、進行中の作業のための特別なパイプラインを持つことに似ていますが、CI システムをいじる必要はありません。エージェントが chunk validate を実行すると、コマンドは Chunk sidecar 上で直接実行され、出力はエージェントに直接送信されます。CI パイプラインをポーリングする必要はなく、結果はエージェントに直接返され、エージェントはテストがパスするまで反復できます。エージェントにもアクセス権があり、これは Chunk sidecar への常時接続の「ssh でデバッグ」オプションを持つようなものです。そのため、エージェントは、コードの正当な失敗と環境の問題を区別したり、もちろん修正を提案したりできます。

デフォルトでは、git リポジトリに変更がある場合、エージェントの停止イベントごとに microbuild の実行をトリガーするために フックを使用します。停止イベントは、エージェントがエラーを表面化する前にあまりに多くのコードを書くのを防ぐのに十分な頻度でありながら、エージェントが作業中に自律的にいくつかのチェックを実行する余地を残します。ただし、Chunk sidecar は CLI でプログラム的に作成できるため、エージェントは（例えば）テストをシャーディングするために多くの sidecar を作成できます。

Microbuild はまた、インクリメンタルになるように作られています。CI パイプラインの煩わしい点の1つは、コミットを作成し、プッシュし、結果を待つ必要があることです。microbuild では、ローカルのチェックアウトからリモートの Chunk sidecar へのインクリメンタル同期（git のパッチメカニズムを使用）を行います。これにより、エージェントのレイテンシがさらに削減されます。

結果

CircleCI で Chunk sidecar を構築するために、Chunk sidecar と microbuild パターンを使用しています。

これまでのところ、結果は有望です：

  • トークン効率 - microbuild の出力は、エラーを特定するためにエージェントが使用するトークン効率が、CI ログを直接使用する場合の3倍です。これは「有用な」トークンの割合を見て測定しました：CI ログの取得には追加のツールコールが必要で、ログにはインストール出力のような失敗の修正に役立たない結果が含まれていることが多いです。
  • コスト効率 - Chunk sidecar 環境は、CI パイプラインよりも10〜20倍コアコスト効率が良いです。この改善のほとんどは、sidecar が事前ウォームされた環境を持ち、セットアップ時間を削減し、ファンアウトジョブが完了するのを待つのではなく高速に失敗できることに由来します。

今後の展望

Chunk sidecar と microbuild の現在の実装は、今日の即時の問題に対処しています：コードを検証するために使用する従来のインフラが圧力を受けています。コードを書くプロセスは劇的に高速化しましたが、数千の Playwright テストがある場合、それらを実行するのに十分なコンピュートが必要で、エージェントの数でこれを掛け算すると、インフラコストは急速に上昇します。

しかし、即時の懸念を超えて見ると、Chunk sidecar はエージェントファーストのインフラというより広いトレンドの一部です。ここ数年、私たちは人間のために構築されたツールに AI 開発を適合させてきました：エージェントをノートPCで実行させ、エージェントに PR と CI パイプラインを監視させ、などです。しかし、ツールが改善され、エージェントが人間の監督なしで数時間または数日間実行できるようになると、エージェント向けに特別に構築されたアーキテクチャが増えています。今ではエージェントにブラウザを与えています。Chunk sidecar を使えば、エージェントに作業をスケールアウトするための追加のコンピュータを与えることができます。小規模なエージェント向けクラウド環境も想像できます。

Chunk CLI をインストールして chunk init をプロジェクトで実行することで、Chunk sidecar をチェックしてみてください。開始するには CircleCI アカウントが必要です。デモはこちら。