Anthropic の Safeguards チームの研究者が書いたこの記事は、著者が「エージェントチーム」と呼ぶ、言語モデルを監督するためのアプローチを説明している。これは、複数の Claude インスタンスが、人間の積極的な介入なしに、共有のコードベース上で並列に作業するというものである。このアプローチを負荷試験するために、16 体のエージェントに、Linux カーネルをコンパイルできる Rust 製の C コンパイラをゼロから書くというタスクが与えられた。2,000 回近い Claude Code のセッションと約 20,000 ドルの API コストをかけて、チームは Claude’s C Compiler を生み出した。これは 10 万行のコンパイラで、x86、ARM、RISC-V 上で Linux 6.9 をビルドできる。
著者はコンパイラそのものを興味深い成果物と位置づけつつも、記事の重点は、この実験が長時間稼働する自律型エージェントチームのためのハーネス設計について教えてくれたことに置いている。すなわち、人間の監督なしにエージェントを軌道に乗せ続けるテストをどう書くか、複数のエージェントが並列に進捗できるよう作業をどう構造化するか、そしてこのアプローチがどこで限界に達するか、である。このプロジェクトは能力ベンチマークとしても設計されており、Claude 4 モデルシリーズを通じて、モデルが今日かろうじて達成できることを探るために使われてきた。
ハーネス自体は意図的に必要最小限のものになっている。各エージェントは自分専用の Docker コンテナ内の無限シェルループで Claude Code を実行し、共有のベア git リポジトリからクローンしてそこへプッシュし返す。前のセッションが終わるとすぐに、新しいセッションが新しいコンテナで始まる。著者は、Ralph Loop を見たことがある人にはこのループは見覚えがあるだろうと述べ、自分のマシン上ではなくコンテナ内で実行するよう勧めている。
要点
- Claude Code のような既存のエージェントスキャフォールドは、長い問題に取り組むとモデルがいずれ入力を待って止まってしまうため、オペレーターがオンラインでいる必要があると説明されている。ループで実行することは、持続的な自律的進捗を引き出すための著者の方法である。
- エージェントは単純なロックによって作業の重複を避ける。エージェントは
current_tasks/ディレクトリにテキストファイルを書き込むことでタスクを確保し、同じタスクを確保しようとした 2 体目のエージェントは git の同期によって別のタスクを選ぶことを強いられる。 - オーケストレーション用のエージェントも、それ以外のエージェント間通信も存在しない。各エージェントは何をするかを自分で決め、たいていは「次に最も明らかな」問題に取りかかる。
- 著者の労力の大半は、ループそのものではなく、Claude を取り巻く環境、つまりテスト、環境、フィードバックに費やされた。
- タスクの検証器はほぼ完璧でなければならない。そうでなければ、自律型エージェントは間違った問題を解いてしまうからである。新機能が既存の機能を壊し始めたときには、より厳格に強制する継続的インテグレーションのパイプラインが追加された。
- 各エージェントはコンテキストを持たない新しいコンテナで起動するため、エージェントには詳細な README と進捗ファイルを保守するよう指示された。
- テスト出力は、記事が挙げるモデルの 2 つの限界を踏まえて設計された。1 つはコンテキストウィンドウの汚染(数行だけを出力し、残りはファイルに記録し、grep できるよう
ERRORとその理由を 1 行にまとめる)、もう 1 つは時間の感覚の欠如(デフォルトの--fastオプションで、エージェントごとに決定論的なランダムな 1% または 10% のサンプルを実行する)である。 - 独立した失敗テストが多数ある間は並列化は容易だったが、Linux カーネルでは破綻した。これは 1 つの巨大なタスクであり、すべてのエージェントが同じバグに突き当たって同じバグを修正してしまった。
- 解決策は、GCC を既知の正しいコンパイラのオラクルとして使うことだった。カーネルの大部分を GCC でコンパイルし、ランダムに選んだ残りの部分だけを Claude のコンパイラでコンパイルすることで、エージェントごとに異なるファイルの異なるバグを追えるようにした。
- 並列化によって、専門化された役割も可能になった。1 体のエージェントは重複したコードの統合を担い、他のエージェントはコンパイラの性能、生成コードの効率、Rust 開発者の視点からの設計批評、ドキュメントに取り組んだ。
- この実行では 2 週間で約 20 億の入力トークンと 1 億 4,000 万の出力トークンが消費された。著者は、このコストは自分でコンパイラを作る場合、ましてやチームで作る場合にかかったであろうコストのごく一部だと評価している。
- 著者の報告によれば、それ以前の Opus 4 モデルは機能するコンパイラをかろうじて作れる程度であり、Opus 4.5 は大規模なテストスイートに初めて合格したモデルだったが、実際の大規模プロジェクトではまだ失敗していた。
- 完成したコンパイラは Opus の能力の限界にほぼ達したとされる。残された制約を修正しようとする試みは完全には成功せず、新機能やバグ修正が既存の機能を頻繁に壊した。
背景
この記事は、1 人の研究者による 1 つの実験についての直接の報告であり、Anthropic のエンジニアリングブログ向けに書かれたものである。著者はこのハーネスを非常に初期の研究プロトタイプと呼んでいる。記事は勝利ではなく警告の調子で締めくくられる。完全に自律的な開発には現実のリスクが伴うとされる。自律的なシステムにとって、テストが通るのを見て仕事が終わったと思い込むのはたやすいが、実際にそうであることはめったにないからである。そして、以前ペネトレーションテストの仕事をしていた著者は、プログラマーが自分で一度も検証していないソフトウェアをデプロイすることを現実の懸念として挙げている。著者は、この実験に興奮すると同時に不安も覚えると述べている。
進捗をファイルへ外部化することと、モデルのコンテキストに合わせて形作られたテスト出力を重視している点で、この記事は、長時間稼働エージェント の設計と ハーネスエンジニアリング に関するこのウィキの他の記述と並ぶものである。