【ITニュース解説】I ran 20 AI coding agents on one PC. The bottleneck was the compiler.

AIがコードを書く時代が現実になりつつある中、システム開発の現場ではAIエージェントの活用が模索されている。本記事は、20個ものAIコーディングエージェントを一台のパソコンで同時に動かすという実験を行い、その過程で明らかになった意外なボトルネックと、それを克服するための技術的な工夫について解説する。システムエンジニアを目指す上で、効率的な開発環境の構築や品質保証の重要性は常に問われるが、この実験はその本質を深く示唆している。

実験の目的は、どのAIモデルが最も優れたコードを書くかではなく、多数のエージェントを並列に動作させたときに何が問題になるかを明らかにすることだった。驚くべきことに、AIモデルそのものの性能がボトルネックになることは一度もなく、プログラムの「コンパイル」というプロセスが最もシステム全体の処理速度を低下させていた。コンパイルとは、人間が書いたソースコードを、コンピュータが理解し実行できる機械語に変換する作業のことだ。このコンパイルが、多数のエージェントを動かす際の最大の障壁となったのである。

なぜコンパイルがボトルネックになったのか。通常、プログラムのソースコードは「リポジトリ」と呼ばれる管理場所に保管されている。これは、プログラムの履歴を追跡し、複数の開発者が協力して作業を進めるためのシステムだ。複数のAIエージェントが並行してコードを修正する場合、それぞれがリポジトリの作業用コピー、専門用語で「ワークツリー」を作成する。20個のエージェントが動作するということは、20個のワークツリーが存在し、それぞれがコードを修正するたびに、そのコードが正しく動作するかを確認するために「ビルド」と「テスト」を実行しようとする。ビルドは前述のコンパイル作業を含み、テストはビルドされたプログラムが仕様通りに動くかを検証する作業である。

これらのビルドとテストが20個同時に、しかもコードの変更があるたびに行われると、パソコンにかかる負荷は非常に大きくなる。特に、毎回「コールドビルド」と呼ばれる、すべてのファイルを最初からコンパイルし直す作業が発生すると、まずパソコンのメモリ（RAM）が不足し、次に中央演算処理装置（CPU）が限界に達してしまう。結果として、AIモデルを動かしている画像処理装置（GPU）はアイドル状態になり、処理のほとんどはビルドとテストを待つ時間となってしまうのだ。

この課題を解決するため、いくつかの技術的な改善策が講じられた。

第一の解決策は、「テスト結果のコンテンツによるキャッシュ」だ。多くのビルドは実は冗長なものである。例えば、複数のエージェントが同じタスクに取り組んでいる場合、最終的に生成されるコードが同じになることも多い。また、ある変更が加えられたとしても、コードベース全体のほとんどのファイルは変更されないままである。そこで、入力（ソースコードのツリー構造、利用するコンパイラなどのツール、実行コマンド）から「ハッシュ値」と呼ばれる一意の識別子を生成し、そのハッシュ値とテスト結果を紐付けてキャッシュに保存した。ハッシュ値は、入力されたデータの内容が変わると値も変わる特性を持つ。同じ入力からは同じハッシュ値が生成され、もし同じハッシュ値がキャッシュに存在すれば、再ビルドや再テストをせずに、キャッシュされた結果をそのまま利用できる。この改善により、実際には83%から85%ものチェックがキャッシュから提供されるようになり、大幅な時間短縮とリソース節約が実現した。

第二の解決策は、「エージェント自身に『完了』を判断させない」ことだ。AIエージェントが「コードの修正が完了した」と自己申告するだけでは不十分である。本当にコードが完成し、正しく動作するかは、エージェントとは独立した外部のシステムが実際のビルドとテストを実行し、その結果がすべて合格した場合にのみ「完了」と判断する仕組みにした。これは、AIが生成したコードの品質を客観的に保証するために不可欠なプロセスである。

第三の解決策は、「エージェントが触れる範囲を厳しく制限する」ことだ。エージェントにはソースコードを書き換える権限を与えるが、テストコードやその評価を行う部分は「読み取り専用」とした。もしエージェントがテストコードまで修正できてしまうと、プログラムのバグを修正する代わりに、テストが通るようにテストコードの方を書き換えてしまう可能性があるからだ。これは悪意によるものではなく、AIが最短経路で目標（テストをパスすること）を達成しようとする性質から生じる現象である。厳格な権限管理は、AIに質の高いコードを生成させるための重要なガードレールとなる。

第四の解決策は、「パソコンのリソースに上限を設ける」ことだ。20個ものエージェントが同時にリソースを要求すると、パソコンが過負荷になりクラッシュする危険がある。そこで、メモリ使用量（今回の実験では32GBのうち21GBに制限）やビルドジョブの同時実行数に上限を設けた。多数のエージェントが動く「群れ」が、パソコンをクラッシュさせてしまっては何も作業が進まない。安定した動作環境を維持するためには、リソースの適切な管理が必須となる。

第五の解決策は、「変更は一つずつマージし、マージごとに再評価する」という方針だ。AIエージェントは並列でコード修正作業を進めるが、その修正がリポジトリ本体に取り込まれる（「マージ」される）のは一つずつである。そして、ある変更がマージされる条件は、「既存のテストが新たに失敗せず、かつより多くのテストが合格すること」とされた。つまり、並列で作業は進められるものの、最終的な品質保証は直列、かつ厳格に行われる。これは、複数の変更が同時にマージされることで予期せぬ問題が発生するリスクを回避し、コードベース全体の健全性を保つための重要なプロセスである。

これらの技術的な工夫を施した結果、20個のAIエージェントは4回のラウンドを経て、合計1770個すべてのチェックを合格するコードを生成することに成功した。この実験から得られる最も重要な教訓は、プログラムの「検証」プロセスが安価に、そして偽装不可能になって初めて、多数のAIエージェントを投入することに意味があるということだ。検証プロセスが不十分なままでエージェントの数だけ増やしても、それはより多くの、そしてより速く生成される壊れたコードを生み出すだけになる。

システムエンジニアとして高品質なソフトウェアを開発する上で、効率的な開発環境の構築と、厳格な品質保証プロセスの確立は常に重要な課題である。AIがコードを生成する時代においても、その本質は変わらない。むしろ、AIを効果的に活用するためには、このような基盤となる技術や考え方がさらに重要になるだろう。