「SWE-bench」って何？ LLMのコーディング能力をどうやって評価するか
AIがコードを書く能力を身につけたことで、次に問われるのは「いかに具体的な開発タスクで実力を発揮できるか」だ。風戸氏は、LLMのコーディング能力を測るための様々な評価指標（ベンチマーク）と、実際の開発現場における生産性の変化について詳細なデータを提示した。
初期のAIモデルの評価には、関数の仕様を与えて正しいPythonコードが書けるかを問う「HumanEval」や「MBPP」というデータセットが用いられ、テストケースを通過するかどうかで機械的に性能が測定されてきた。しかし、推論モデルやエージェントが登場し、AIがシステム全体を横断して自律的にバグ修正などを行うようになると、より複雑な評価手法が必要となった。
そこで現在活用されているのが、GitHub上の過去のバグ修正や機能追加の履歴をAIに解かせる「SWE-bench」である。 これは、実際のリポジトリを当時の状態に巻き戻し、開発者が直面した課題（Issue）をAIに提示して解決策のコードを生成させ、既存のテストスイートを通過できるかを評価する実践的なベンチマークである。
しかし、ここでも新たな課題が浮き彫りになった。風戸氏によれば、抽出された問題のうち約6割は、Issueの記述自体が不明瞭であったり、他のIssueを参照しなければ解けない情報不足の案件であったりしたため、AIには物理的に解決不可能な不適切な問題であることが判明したのだ。
そこで、専門の開発者たちが一つひとつの問題を精査し、純粋にAIの能力を測れるように改善した「SWE-bench Verified」が構築された。この精査されたベンチマークにおいて、最新のトップクラスのAIモデルは過去のIssueの約7割以上を自律的に解決できる水準に達しているという。これは、単なる関数レベルのコーディング支援を超え、システム全体の改修という実務に直結する成果である。
一方で、現場への導入効果については興味深い逆転現象が報告されている。ある実験で、オープンソースの開発者にAIツールを使用して実務タスクを行わせたところ、本人の体感では「仕事が2割ほど早くなった」という回答が得られた。
しかし、実際の作業ログを解析すると、タスク完了までの合計時間はかえって2割増加していたのである。風戸氏はこの原因について、「コーディングしている時間やコードを読んでいる時間、テストやデバッグをしている時間は確実に減少していました。一方で、時間が増加していたのは『AIの出力結果を確認している時間』『プロンプトを入力している時間』、そして『AIの出力をぼーっと待っている時間』でした」と分析する。
AIのコード生成自体は高速でも、プロンプトの調整や生成されたコードの妥当性を人間がレビューする工程（オーバーヘッド）が新たなボトルネックを生み出しているのだ。
この事実は、AIツールを単に導入するだけでは生産性は自動的に向上せず、AIの応答を待つ間に別の作業を進めたり、的確な指示出しのスキルを磨いたりするなど、AIとの協働を前提とした新しい働き方への適応が必要であることを示唆している。
