#77 コードを動かさずに採点するAIの新常識

GitHubの不具合を自動で直す「コーディングAI（コーディングエージェント）」を賢く育てるには、AIが提出した修正が本当に正しいかを判定する「採点役（検証器）」が欠かせません。これまでの採点方法は、修正したコードを実際に動かしてテストを通すのが定番でした。しかしこの方法には大きな弱点があります。プロジェクトごとに専用の実行環境（Docker）を組み立て、依存関係を解決し、テストを書く…という膨大な準備が必要なのです。しかも、社内の秘密のコードや古いシステムなど、そもそも動かせる環境やテストが存在しないケースも多い。この「準備地獄」が、AI訓練を大規模化する上での最大のボトルネックになっていました。

Dockerless の発想はシンプルかつ大胆です。「コードを動かさずに、代わりに調べて判断する」。

従来の「動かさない採点」もありましたが、それらは修正の見た目（テキスト）を表面的に比べるだけで、精度がいまいちでした。Dockerless はここが違います。まるで熟練のコードレビュアーのように、リポジトリの中を実際に探索して証拠を集めるのです。

具体的には二段階。まず、不具合の説明とお手本の修正から「この修正はどこに効くべきか」「他の部分を壊さないか」といった検証すべき質問を数個つくります。次に、質問ごとに担当の小さなAI（サブエージェント）を並行して派遣し、grep などの読み取り専用コマンドでコードを調べさせ、証拠つきの答えを持ち帰らせます。最後に集めた証拠を総合して「正しい/正しくない」を判定します。図書館で複数の調査員に手分けして調べさせ、報告を突き合わせて結論を出すイメージです。

採点役としての精度を測るテストで、Dockerless は既存の最強オープンソース検証器を 14.3ポイント​（AUCという指標で）上回りました。GPT-5.4 のような最先端の大規模AIを審査員に使った場合よりも高精度です。

さらに、この採点役を使ってAIを訓練したところ、SWE-bench という不具合修正の腕試しで、修正成功率が **62.0%​（Verified）、​50.0%​（多言語版）、​35.2%**​（Pro版）に到達。ベースモデル（Qwen3.5-9B）より各 2.4・8.7・2.9ポイント向上しました。注目すべきは、これが「実際にコードを動かして採点する従来方式」とほぼ互角だった点です。準備コストゼロで同等の成果を出せたわけです。

この研究の意義は「AI開発の民主化とスケール化」にあります。これまでコーディングAIを鍛えるには、動かせる環境が整った特定のプロジェクトしか使えませんでした。しかし現実の世界には、環境を再現できない社内システムや古いコード（いわゆる「ロングテール」）が圧倒的に多い。Dockerless はこの膨大な「眠っていた資産」を訓練データとして活用する道を開きます。

ビジネス視点で見ると、自社の独自コードベースを使ってAIを鍛えたい企業にとって、「テスト環境を全部整える」という高いハードルが下がる意味は大きい。準備の人件費とインフラコストを削りつつ、自社に最適化されたコーディングAIを育てられる可能性があります。

コスト面でも実用的で、AI訓練にかかる時間のうち採点処理はわずか 7.2%。大半はコード生成そのものに費やされるため、「調べて採点する」方式の追加コストは実質わずかだと示されました。