どすこい
doskoi64
テーマ
AIエージェントの導入によって、開発の現場は実際にどのくらい生産性が向上したかをテーマに、導入した現場での定量的な実測値とAIエージェントのベンチマークを深掘って考察した結果を発表します。
いくつかのAIエージェントの導入(2023年のCopilot、2024年のCursor、2025年のClaude Code)による社内でのマージ頻度やリードタイムの変化と考察、AIエージェントの研究開発の分野で参照されるHumanEval / SWE-Bench等のベンチマークの深掘り、そのベンチマークによる定量評価がどれくらい現場での定性的な評価と合っているのかを考察した内容を発表します。
想定する参加者層(前提知識)
機械学習やLLMに関する研究の知識などを必要とせず、コード生成をするAIエージェントを見聞きしただけの人にもわかりやすいような基礎からの発表にします。特に、ベンチマークについては、具体的にどのような課題があってどのように判定されているのかを噛み砕いて説明します。
トーク概要
本セッションでは、AI コードエージェント導入による開発加速の実態を、現場データとベンチマークの両面から整理してご報告します。
当社では 2023 年以降、その時点で有効と判断したコード生成 AI エージェントを導入してきました。マージ頻度やリードタイムの集計の結果、ある事業部では Cursor 導入後にマージ頻度がおよそ 3 倍、Claude Code 併用後にリードタイムがおよそ 1/2 となる変化を観測しました。この事実をもとに、「AI でどれくらい加速したのか」「どう評価すべきか」を定義し直します。
AI 導入初期はコード生成の品質が安定せず、人手による修正が前提となる場面が多いと感じていました。その後、モデル世代の変化に伴いコード生成の「精度」が向上し、コードエージェントの導入により開発体験が実際に変化した手応えがありました。ただし、この「精度」が具体的に何を指すのかに疑問を持ちました。変化量を外部基準でも確認するため、研究開発分野で一般的なベンチマークが何を測り、どのスコアを KPI としているかを整理する必要があると判断しました。
そこで、HumanEval と SWE-Bench を取り上げ、研究・開発分野で何を指標としてスコアを伸ばそうとしているかを解説します。これらのベンチマークでは、HumanEval は明確な入出力をもつ小粒度タスクに対する関数レベルの正確性を測定し、SWE-Bench は既存リポジトリ上での Issue 修正達成(文脈統合・依存解決・テスト通過)を測定します。現場では前者をユーティリティ/純粋関数の自動実装の置換可能性、後者を既知バグ修正や小〜中規模改修の到達率として読み替えます。本発表では、実際のテストデータを参照しながら両者の評価対象と前提条件を具体的に説明します。
あわせて評価指標にも短く触れます。pass@k は同一課題に対して k 本のコード生成を行い、少なくとも 1 本がテストを通過する確率を示します(例:pass@1 は単発生成の正答率、pass@5 は多様サンプルからの到達率)。SOTA(state of the art) は特定ベンチマーク・評価手順・バージョンにおける当時点の最高到達成績を指します。いずれも評価プロトコルと前提条件への依存性が高いため、比較は同一条件で行う必要があります。
そのうえで、ベンチマークの数値は次の三点で位置づけて読み解きます。第一に、何を前提に何を測っているか(課題の明確さ、必要コンテキスト、依存・ビルド環境、採点方法)を明示します。第二に、どの作業単位に対応するか(例:小粒度の実装、既知 Issue の修正、結合起点の不具合対応)を対応付けます。第三に、影響しやすい成分/しにくい成分を仮説化します。なお、研究分野の「コード精度」は pass@k やテスト合否が中心であり、仕様の曖昧さの解消、非機能要件、ステークホルダー調整、セキュリティやロールバック設計、コードデザイン(責務分割・凝集/結合・API 境界)といった現場要素は評価外になりやすい点を前提にします。本セッションでは、この読み替えを対応表と最小手順として提示し、新しいモデル・ツール・論文に出会った際に、作業単位や手元の指標へトレースする実務的なガイドとして持ち帰っていただきます。
聴講者が得られること
• AI 導入による効果が定量的にどのくらいあるかと、その評価方法
• 研究開発分野での AI エージェントの扱われ方と、どのスコアを KPI として伸ばしているかの整理
• 研究ベンチマークが開発現場でどの程度・どの領域に起用できるかを考え、議論するための視点