10月30日、startuphub.aiが「AI writes 2,450% more code, ships 30% more」と題した記事を公開した。AIエージェントがコード生成量を爆増させる一方でリリース数の増加は限定的にとどまるという実態と、その根本原因について詳しく紹介されている。

コードは2,450%増、リリースは30%増——この乖離が本質

AI EngineerカンファレンスでSonar CEOのTariq Shaukatが提示した研究データが、エンジニアコミュニティに問いを投げかけている。

AIエージェントの導入によって、コード行数は2,450%増、コミット数は240%増を記録した。しかしリリース数の増加は**わずか30%**にとどまった。

この数字の意味は明確だ。AIは膨大なコードを生成しているが、それがそのまま出荷物の増加につながっていない。Shaukatはその理由を3つの構造的問題に集約している。

なお、この乖離はエージェント時代になって初めて顕在化した問題でもある。従来のAIコード補完（GitHub Copilotなど）は人間の作業を補助する範囲にとどまっており、コード生成量とリリース量の比はさほど乖離しなかった。しかし自律的にタスクを完遂するAIエージェントが普及すると、人間の関与なしに大量のコードが生成・コミットされるようになる。これにより「生成量」と「出荷できる品質」の断絶が一気に拡大した——それが2,450%対30%という数字の背景にある。

問題1：人間によるレビューはスケールしない

Shaukatが最初に指摘するのは「Human in the loop（人間がループに入る）」モデルの限界だ。AIが大量のコードを生成する速度に、人間のレビューが追いつかない。

さらに深刻なのが「認知的服従（cognitive surrender）」の問題だ。AIが正しい場合に人間が同意する割合は93%——ここまではまだ理解できる。問題はAIが間違っている場合でも、5回中4回は人間がそれに同意してしまうという数字だ（Shaukatが登壇中に引用した研究データによる）。人間がAIを監視しているつもりで、実質的にはゴム印を押しているだけになっている。

エージェントが生成するコードの量が増えれば増えるほど、一件あたりのレビューにかけられる時間は短くなる。認知的服従のリスクはレビュー負荷に比例して高まる構造であり、「人間が最終確認すれば安全」という前提そのものが崩れつつある。

問題2：コードベースが大きくなるとエージェントが崩壊する

AIエージェントはコードベースの規模に対して非常に脆弱だ。Shaukatが引用したコード翻訳に関する研究では：

• 10,000行のコードベースで精度91%
• 50,000行になると精度が急落

さらに別の研究では、同一タスクに必要なトークン数がエージェントによって最大30倍も変動した——エージェントがコードの構造を把握しようとしてトークンバジェットを無駄に消費するためだ。

MeterのデータもAnthropicのClaude（Mythosプレビュー版）※を用いた実験として紹介されており、16時間相当の人間作業を精度50%で完了し、精度曲線は80%付近で急激にフラット化した。エラーは積み重なり、精度の頭打ちが早い段階で来る。

※「Mythosプレビュー版」はShaukatが登壇中に言及したモデル名であり、元記事時点での表記に基づく。Anthropicの一般公開モデル名とは異なる可能性があるため、詳細は元記事および公式情報を確認されたい。

問題3：LLMをジャッジにしても信頼できない

「LLMに別のLLMを評価させる」手法（LLM-as-a-judge）はコードレビューの自動化として注目を集めているが、Shaukatはその信頼性に疑問を呈した。

• PayPal AI Researchの調査：同一の入力に対する評価が、モデルや状況によって7〜17%の確率で変化した
• Metaの研究：単純に「本当にそれで合ってる？（are you sure?）」と再質問するだけで、7〜34%の確率で回答が覆った

LLMジャッジが持つこの不安定性は、大規模なエージェントシステムの品質保証において無視できないリスクとなる。エージェントが生成したコードをエージェントが検証し、その結果を人間が信頼する——という連鎖が成立するかどうかは、現状では保証できないとShaukatは述べる。

Shaukatが提唱する「コード信頼性の公式」

Shaukatのアプローチは、エラーを事後に捕捉する「ガードレール（guard rails）」ではなく、エージェントを正しい方向に誘導し続ける「ガイドレール（guide rails）」を重視する。両者の違いは「道を外れてから気づく」か「外れないよう誘導する」かの差だ。

具体的な構成要素は以下の4点：

• Intent（意図の明確化）
• Guide rails（事前誘導）
• Independent verification（独立した検証）
• Auditable evidence（監査可能な根拠）

Shaukatが経営するSonarはこの考えに沿った製品を販売している。SonarQubeはコード品質の検証基盤として位置づけられ、Sonar Vortexはエージェントが生成するコードをより保守性・信頼性・セキュリティ面で優れたものにすることを目的とする（ただし、VortexとRemediation AgentはSonarQube CloudのTeamプランまたはEnterpriseプランに加え、別途サブスクリプションが必要）。

Shaukatによれば、大規模コードベースの長時間タスクでVortexを使用した顧客ではトークンコストが36%削減、コミット時の問題件数が92%減少したという。また1,000人以上の顧客調査では、SonarQube利用者は非利用者と比較してAIコーディングによるコードセキュリティへの影響を「非常にポジティブ」と評価する割合が81%高く、リリース速度では34%、障害頻度では76%の改善を報告した。

「コードを書く速度」と「価値を届ける速度」の乖離——これはエージェント時代のソフトウェア開発が直面している構造問題だ。2,450%対30%という数字は、その現実を端的に示している。

詳細はAI writes 2,450% more code, ships 30% moreを参照していただきたい。