AIで開発はどれくらい加速したのか？AIエージェントによるコード生成を、現場の評価と研究開発の評価の両面からdeep diveしてみる

Slide 1

Slide 1 text

1 AIで開発はどれくらい加速したのか？ AIエージェントによるコード⽣成を、現場の評価と研究開発の評価の両⾯からdeep diveしてみるどすこい (doskoi64) GMOペパボ株式会社 EC事業部事業開発チーム Burikaigi 2026 Day 1 (2026.01.09) マス #burikaigi_m

Slide 2

Slide 2 text

2 ⾃⼰紹介 EC事業部 ECグループ事業開発チームどすこい Daisuke Takeda ⾼校(⽚⼭学園)まで新湊⼤橋のらへんに住んでいました！地元で登壇嬉しい🙌🙌 東京ではECサイトの検索基盤/ログ基盤の改善を⾊々しています。純粋にAIが好きで、⼤学で研究してたり、⾊々調べたりしていました。 Webエンジニア X: @doskoi64

Slide 3

Slide 3 text

3 私たちは「⼈類のアウトプットを増やす」ことをミッションとし、インターネットやテクノロジーの⼒で情報発信のハードルを下げる⽀援をしています。

Slide 4

Slide 4 text

4 #burikaigi_m #burikaigi Xで感想/コメントのツイートお願いします！

Slide 5

Slide 5 text

5 AI使ったコーディングしてますか？ 5

Slide 6

Slide 6 text

6 AIのコード⽣成の精度どうですか？⼿を挙げてください！🖐 6 😎 🙂 🤔 😡

Slide 7

Slide 7 text

7 AIのコード⽣成の精度どうですか？ 7 😎 🙂 🤔 😡 中　　多　　中　少予想はこうです！

Slide 8

Slide 8 text

8 本⽇のテーマ 8

Slide 9

Slide 9 text

9 AIで開発はどれくらい加速したのか?

Slide 10

Slide 10 text

10 AIで開発はどれくらい加速したのか?

Slide 11

Slide 11 text

実感としてはかなり速くなった... 気がする！けど、ちゃんとは⾔えてないどれくらい加速したのか？ 11

Slide 12

Slide 12 text

けど、実際に速さはありそう...！？ 12 Jaana Dogan (@rakyll) 2026-01-03 Google プリンシパルエンジニア

Slide 13

Slide 13 text

定量的にはどうなんだろう ● 現場：使ってみて良くなった ● 研究：ベンチマークで〇〇％向上これって具体的に何がどうなっているんだろう？ AIエージェントの評価 13

Slide 14

Slide 14 text

AIエージェントのコード⽣成の定量評価について深掘り ● 現場ではどこのデータをみているのか ● ⼀⽅、研究ではどのように評価しているのか ● 研究での評価と現場での評価の違いがどうしてあるのか ● これを踏まえてどのように考えていくのか今⽇のお話では... 14

Slide 15

Slide 15 text

15 業務や趣味開発などで試してみることで得られる定性評価&試⾏錯誤も、とても重要です！お話ししませんが、重要なことジュニア/シニア問わず、皆さんが使ってみた⼿応え感や考え⽅をわいわい聞くことの⽅をむしろ僕は⼤事だと思っています！アウトプットしましょう！

Slide 16

Slide 16 text

Table of contents ● ⾃⼰紹介と導⼊ ● 近年のAIエージェントのあゆみ ● 現場でのAIエージェント開発の評価 ● ⽣成AIによる単純なコード⽣成のベンチマーク: HumanEval ● HumanEval-XLを実際触ってみる ● 現実世界のソフトウェア開発の動きに近いベンチマーク: SWE-bench ● 研究との現場の違い ● これを踏まえたAI時代の動き 16

Slide 17

Slide 17 text

Slide 18

Slide 18 text

18 近年のAIエージェントのあゆみ

Slide 19

Slide 19 text

19 2022 ~ 2023

Slide 20

Slide 20 text

20 2024 ~

Slide 21

Slide 21 text

21 完全に雰囲気に⾝を任せて、コードの詳細に気を払わず、⾃然⾔語だけで指⽰をしてコーディングする Andrej Karpathy (X:@karpathy) 2025-02 OpenAIの創設メンバー Vibe Codingとは

Slide 22

Slide 22 text

22 2025※イメージです

Slide 23

Slide 23 text

23 ⼈間とAIのドライバー席の交代

Slide 24

Slide 24 text

24 https://staﬀ.persol-xtech.co.jp/hatalabo/mono_engineer/568.html

Slide 25

Slide 25 text

25 『エンジニアに許された特別な時間の終わり』より (https://speakerdeck.com/watany/the-end-of-the-special-time-granted-to-engineers)

Slide 26

Slide 26 text

26 ⼈間が数⼗、数百⾏コードを1⽇で書くところ... AIを使えば1万⾏書くことができる圧倒的な量を誰でも書くことができる⼈間とAIのドライバー交代

Slide 27

Slide 27 text

つづきはこちら 27 https://speakerdeck.com/daisuketakeda/vibecodingshi-dai-noenziniaringu

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 現場での AIエージェント開発の評価

Slide 30

Slide 30 text

Four Keys 30 ● DORA（DevOps Research and Assessment）が提唱する開発組織のパフォーマンスを測る4つの指標 ● デプロイ頻度, リードタイム, 変更障害率, サービス復元時間 ● 4つの指標がどれも優れている組織をエリートとしている ● ペパボではこれをチームごとに記録する基盤があります 2020-10-01 https://cloud.google.com/blog/ja/products/gcp/using-the-four-keys-to-measure-your-devops-performance

Slide 31

Slide 31 text

デプロイの頻度の変化 31 ● Four Keys中でのデプロイの頻度の⼀例⽇付デプロイの頻度

Slide 32

Slide 32 text

デプロイの頻度の変化 32 AIエージェント導⼊で増えている⽇付デプロイの頻度

Slide 33

Slide 33 text

他のチームの例プロダクトやチームの状況でも変わってくる... 33 ● 他1: 同様にデプロイの頻度が増えている。さらに2倍, 3倍となるようにアクションを⾏っている。 ● 他2: 同じようなデプロイの頻度がみられなかった。そもそもPR作成の数が増えてなさそう。なので、PR作成数にフォーカスして再度測定。

Slide 34

Slide 34 text

34 10倍になる感覚があるけど活かしきれてないとのこと..

Slide 35

Slide 35 text

定性的には 35 ● 調査、検証⽤実装を速く、並列でできるようになった。 ● これまででは考えられない速度,リソースでリリースできたサービスもある。 ● キャッチアップや、知らないコードベースに対する調査でも強み。 tech.pepabo.com

Slide 36

Slide 36 text

⼀⽅で... 36 ● 冗⻑なコメントやドキュメントができたりする ● コミットの粒度が⼤きくなったりしまう時がある ● ライブラリなどを使わずに独⾃実装してします ● 設計⽅針や他のコードを参考にしていないような実装になってしまうことがある etc...

Slide 37

Slide 37 text

グッドハートの法則 Goodhart's Law 37 ● 数値だけを追い求めてハックみたいになってはいけない ● ⽬指すべきは⽣産性の増加で、知りたいのは現状の⽣産性がどうだったのかと過去の⽣産性はどうだったのか ● 例えば、デプロイの頻度に注⽬しすぎて、いままで⼀つの PRでマージしていたものを細かいPRマージにして数値を増やしても意味がない開発生産性測定のトレードオフ「グッドハートの法則」はもっと悲観的に捉えるべきだったFindy 開発⽣産性Conference2025 Kent Beck

Slide 38

Slide 38 text

これらをふまえて... 38 ● ⼀⽅で、何もしないことよりも、アクションをすることで試⾏錯誤し続けることの⽅が重要 ● 新しい技術やエージェントの機能、開発の⽅法や開発フローの整備を⾏って、数値がこれまでからどのように変わったのかを⾒てフィードバックループを回す ● ⽬的を⾒失わずに⼿を動かしていく

Slide 39

Slide 39 text

Slide 40

Slide 40 text

生成AIによる単純なコード生成のベンチマーク : HumanEval 40

Slide 41

Slide 41 text

41 ● Open AIが2021年に公開した、コード⽣成の定量評価のためのベンチマークのためのデータセット ○ LLMに⼊れるprompt, 実装するentry_point, 検証⽤test,... ● GitHub由来の解答を⽣成しないように、⼈間が⼿書きでコードを⽣成。⾔語理解、アルゴリズムなどコーディング⾯接っぽい問題。Pythonのコード。データセット: HumanEval Mark Chen, et.al. , Evaluating Large Language Models Trained on Code, 2021, https://arxiv.org/pdf/2107.03374, https://github.com/openai/human-eval

Slide 42

Slide 42 text

42 ● HumanEvalは英語,Pythonのみ。複数⾔語でコード⽣成のベンチマークを⽐較したいというモチベーション ● 23の⾃然⾔語(without Japanese😇)と12のプログラミング⾔語があります ○ 単純なコード⽣成能⼒というより多⾔語間でのコード⽣成能⼒の⽐較のためのもの HumanEval-XL Qiwei Peng, Yekun Chai, and Xuhong Li, 2024, LREC-COLING 2024 | HumanEval-XL: An Execution-based Multilingual Code Generation Benchmark Across 23 Natural Languages and 12 Programming Languages, https://github.com/ﬂoatai/HumanEval-XL, https://huggingface.co/datasets/ﬂoatai/HumanEval-XL

Slide 43

Slide 43 text

43 HumanEval-XL Qiwei Peng, Yekun Chai, and Xuhong Li, 2024, LREC-COLING 2024 | HumanEval-XL: An Execution-based Multilingual Code Generation Benchmark Across 23 Natural Languages and 12 Programming Languages, Fig 1, Illustration of data construction in four steps.

Slide 44

Slide 44 text

44 ● 問題に対してk個のサンプルを⽣成して、少なくとも⼀つのサンプルがtestをpassするコードがかける問題数の全問題数に対する割合 ○ 実際はk << nのn個を⽣成して不偏推定量を使います。評価⽅法: pass@k について Kulal, et.al, 2019 ,SPoC: Search‑Based Pseudocode to Code

Slide 45

Slide 45 text

45 pass@1: ⼀回の試⾏で正しい正解を出⼒する能⼒の指標。最初の提案にどれくらい信頼がおけるか、開発者がどれくらい⼿放しで開発できるかがわかる。 pass@100: 理論的な上限を探る指標。多数の不正解の中に埋もれていたとしても、モデルが正解を⽣成する絶対的な能⼒を持っているかを評価します。 pass@10, pass@5: 開発者が選択肢を確認したり、対話的にコードを⽣成していくシナリオのものです。多様なコード⽣成をしつつ、正しいコードが⽣成できるかの指標評価⽅法: pass@k について Qiwei Peng, Yekun Chai, and Xuhong Li, 2024, LREC-COLING 2024 | HumanEval-XL: An Execution-based Multilingual Code Generation Benchmark Across 23 Natural Languages and 12 Programming Languages, Fig 1, Illustration of data construction in four steps.

Slide 46

Slide 46 text

Slide 47

Slide 47 text

47 HumanEval-XLを実際触ってみる

Slide 48

Slide 48 text

HumanEval-XLを実際みて触ってみる 48 Hugging faceからデータを取得 https://huggingface.co/

Slide 49

Slide 49 text

HumanEval-XLを実際みて触ってみる 49 jsonでこのようなデータがもらえる

Slide 50

Slide 50 text

HumanEval-XLを実際みて触ってみる 50 promptはこんな感じ

Slide 51

Slide 51 text

HumanEval-XLを実際みて触ってみる 51 問題はこんな感じ ● ⼝座の残⾼を追跡し、途中でマイナスになるかを判定。 ● 整数リストの合計と積を返す。空なら (0,1)。 ● リストからユニークな要素を取り出し、昇順にソート。 ● 整数リスト内に、和がゼロになるペアがあるか判定。 ● ⽂字列をMD5ハッシュに変換。空なら None。 ● ⼆つの整数 a, b の間の偶数を昇順で返す。簡単な問題、⾼難易度の問題がある！

Slide 52

Slide 52 text

HumanEval-XLを実際みて触ってみる 52 ⾃分で試してみる: 銀⾏⼝座残⾼管理問題 Claude Code Sonnet 4.1(2025-0929)で試しました問題預⾦‧引き出し操作のリストが与えられ、ゼロ残⾼から開始して、任意の時点で残⾼がゼロを下回るかどうかを検出する関数を実装します。下回った時点で Trueを返し、そうでなければFalseを返します。例: - `below_zero([1, 2, 3])` → False（残⾼: 0→1→3→6） - `below_zero([1, 2, -4, 5])` → True（残⾼: 0→1→3→-1で負になる）

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

HumanEval-XLを実際みて触ってみる 55 ⾃分で試してみる: 銀⾏⼝座残⾼管理結果...！

Slide 56

Slide 56 text

HumanEval-XLを実際みて触ってみる 56 ⾃分で試してみる: 銀⾏⼝座残⾼管理結果...！ 😎

Slide 57

Slide 57 text

HumanEval-XLを実際みて触ってみる 57 ● 実際はいちいちClaude Codeに⼊⼒するのではなく、⾃動でコード⽣成、テスト検証、結果記録までのパイプラインをつくってやっています！ ● ですが、何がテストされていて、どういう検証がされているか調べるのはおもしろいので、ぜひみてみてください！ぜひ実際にみてみてください

Slide 58

Slide 58 text

Slide 59

Slide 59 text

59 現実世界のソフトウェア開発の動きに近いベンチマーク : SWE-bench

Slide 60

Slide 60 text

60 ● LLMが現実世界のソフトウェアエンジニアリングの問題をどれだけ解決できるかを評価するためのもの ● Githubの有名リポジトリからIssueと解決したPRを集めて、修正パッチを作成できるかをテスト ● 単なるコード補完で以上のバグ特定や修正ができるのかを評価するもの SWE-bench SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, Carlos E. Jimenez et al. 2024, https://arxiv.org/abs/2310.06770 https://github.com/SWE-bench/SWE-bench

Slide 61

Slide 61 text

61 HumanEvalとの違い SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, Carlos E. Jimenez et al. 2024, https://arxiv.org/abs/2310.06770 https://github.com/SWE-bench/SWE-bench HumanEval ● 関数やクラス単位でのコード⽣成 ● 数⾏で解け、⾃⼰完結する問題が中⼼ SWE-Benchは... ● リポジトリ横断の⽂脈把握とコード⽣成を要求 ● 現実のソフトウェア開発に則したベンチマーク

Slide 62

Slide 62 text

62 SWE-bench Multilingual https://www.swebench.com/multilingual.html ● 多プログラミング⾔語対応のSWE-bench ● Claude 3.7 Sonnetに絞ってますが、C、C++、Go、 Java、JavaScript、TypeScript、PHP、Ruby、Rustで実施 ● 中央値で10⾏、95%の課題が110⾏以内のコード変更で解決可能 ● 明確なユニットテストがあるものに限定 ※この⼤規模版としてMulti-SWE-benchもあります。⼀旦今⽇は上記の話をします。

Slide 63

Slide 63 text

63 https://github.com/gin-gonic/gin/pull/1805, https://github.com/gin-gonic/gin/issues/1804

Slide 64

Slide 64 text

64 https://github.com/gin-gonic/gin/pull/1805, https://github.com/gin-gonic/gin/issues/1804

Slide 65

Slide 65 text

65 どうなったらpassなのか ● Caddyは設定ファイルを読み込んでWebサーバーを起動するOSS。設定ファイルにはimportという機能があり、よく使う設定をテンプレート化して再利⽤可能 ● これが、⼊れ⼦構造にすると動かなくなるissue ● 正解は、設定ファイルの判定処理を修正し、3ファイルにまたがる55⾏の変更が必要このPRの⾃動テストがpassする実装が書けたらクリア！

Slide 66

Slide 66 text

66 結果: 正答率 https://www.swebench.com/multilingual.html

Slide 67

Slide 67 text

67 結果: ⾔語ごとのコード変更⾏数 https://www.swebench.com/multilingual.html

Slide 68

Slide 68 text

68 研究の限界 SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, Carlos E. Jimenez et al. 2024, https://arxiv.org/abs/2310.06770 https://github.com/SWE-bench/SWE-bench ● 相対的に易しい課題が多い ● コードを書く以前/以外の環境的な難しさは評価してない ● テストが通るかだけで判定するため、コードの品質を⾒落とすことがある。passしていても可読性が低かったり⾮効率であったり保守性が低い場合がある ● コードスタイルを無視した強引な修正を⾏なうことも

Slide 69

Slide 69 text

こちらのブログでさらに詳しく書いています！ 69 https://developers.gmo.jp/technology/78505/

Slide 70

Slide 70 text

Slide 71

Slide 71 text

71 研究との現場の違い

Slide 72

Slide 72 text

72 現場では... AIエージェントを⽤いた開発を⾏って... ● デプロイの頻度/リードタイムはガクッと増えているチームもあれば、そこまで増えていないチームもある。 ● AIエージェントをつかう+ AIエージェントの効果を⼤きくするための体勢を整える。 ● アクションに対するKPIとして引き続き定量数値を確認する。

Slide 73

Slide 73 text

73 研究では... AIモデルの進化によって... ● 単純なコーディング問題の正解数は増えている。 ● すでに解決されているOSSのissueを、複数ファイルの調査や編集をして解決できるようになっている。 ● 多くのファイルを読んで、原因を突き⽌めて、その原因を解決する実装を独⼒で書けるようになっている。

Slide 74

Slide 74 text

74 結局、開発は加速した...？そこまで変わらない？ PRマージ数は⼤きく変化してないリリース時間も速くなってない現実では変わってないんじゃ？

Slide 75

Slide 75 text

75 結局、開発は加速した...？速くなった？ベンチマークのスコアが上がってるエージェントは多くのことができるようになっている便利だし速くなっている！

Slide 76

Slide 76 text

76 結局、開発は加速した...？速くなった？ベンチマークのスコアが上がってるエージェントは多くのことができるようになっている便利だし速くなっている！そこまで変わらない？ PRマージ数は⼤きく変化してないリリース時間も速くなってない現実では変わってないんじゃ？

Slide 77

Slide 77 text

77 結局、開発は加速した...？速くなった？ベンチマークのスコアが上がってるエージェントは多くのことができるようになっている便利だし速くなっている！そこまで変わらない？ PRマージ数は⼤きく変化してないリリース時間も速くなってない現実では変わってないんじゃ？矛盾！

Slide 78

Slide 78 text

78 結局、開発は加速した...？速くなった？ベンチマークのスコアが上がってるエージェントは多くのことができるようになっている便利だし速くなっている！そこまで変わらない？ PRマージ数は⼤きく変化してないリリース時間も速くなってない現実では変わってないんじゃ？矛盾！に⾒えますが...

Slide 79

Slide 79 text

79 結局、開発は加速した...？速くなった？ベンチマークのスコアが上がってるエージェントは多くのことができるようになっている便利だし速くなっている！そこまで変わらない？ PRマージ数は⼤きく変化してないリリース時間も速くなってない現実では変わってないんじゃ？どちらも⼀つの側⾯では正しいです

Slide 80

Slide 80 text

80 AIモデル AIエージェント人

Slide 81

Slide 81 text

81 AIモデル AIエージェント人ジュニアエンジニアシニアエンジニアビジネス職

Slide 82

Slide 82 text

82 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題

Slide 83

Slide 83 text

83 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題最新のモデル！

Slide 84

Slide 84 text

84 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題アップデート！使いやすく！

Slide 85

Slide 85 text

85 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題プロンプト勉強しました！

Slide 86

Slide 86 text

86 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題そもそも課題をわかってない

Slide 87

Slide 87 text

87 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題大量でレビューできない

Slide 88

Slide 88 text

88 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題リリースフローが整ってない

Slide 89

Slide 89 text

89 速くなった！変わらない！

Slide 90

Slide 90 text

90 AIエージェントを⽤いた開発フローの特定箇所に着⽬して速さを測定している AIの⼊出⼒に近いところでは速くても開発⽣産性指標では速くなっていない

Slide 91

Slide 91 text

Slide 92

Slide 92 text

92 これを踏まえたAI時代の動き

Slide 93

Slide 93 text

93 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題全体を踏まえて一番良いようにして！

Slide 94

Slide 94 text

94 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題

Slide 95

Slide 95 text

95 多くの選択肢...どれがいいの？ AIモデル AIエージェント

Slide 96

Slide 96 text

96 人指示入力推論結果 AIモデル AIエージェント成果物レビューリリース課題

Slide 97

Slide 97 text

97 人⼈もやるべきことがたくさん...

Slide 98

Slide 98 text

98 結局どれが⼀番良いんだろう？

Slide 99

Slide 99 text

99 『AI時代のソフトウェア開発を考える（2025/07版）』より引用 (https://speakerdeck.com/ twada/agentic-software-e ngineering-findy-2025-07- edition)

Slide 100

Slide 100 text

100 AIは“最⾼”の変化が激しい ● 進化や発展が特に速いAI技術群、最⾼のものはすぐに塗り変わってしまう。 ● 関わるプロダクトや⼈によっても最⾼は変わる。

Slide 101

Slide 101 text

101 『LLM（大規模言語モデル）の変遷まとめ』より (https://zenn.dev/muit_techblog/articles/0bd35b9c4ea6b1)

Slide 102

Slide 102 text

102 AIは“最⾼”の変化が激しい ● 進化や発展が特に速いAI技術群、最⾼のものはすぐに塗り変わってしまう。 ● 関わるプロダクトや⼈によっても最⾼は変わる。

Slide 103

Slide 103 text

103 人 AIモデル AIエージェント成果物リリース課題 GUIが良いな... エンジニアじゃない... 会社で契約しているモデルにしたい ... 安く済ませたい ...

Slide 104

Slide 104 text

104 両睨み🐍 ● 進化や発展が特に速いAI技術群、最⾼のものはすぐに塗り変わってしまう。 ● 関わるプロダクトや⼈によっても最⾼は変わる。 ● 特定のAIモデルやツールだけを使うのではなく、いつでも乗り換えられるように両睨みすべき。 ● 最新の情報をキャッチして、実際に試してみて、より良い場合に乗り換える柔軟さが強みになりそう。

Slide 105

Slide 105 text

105 どれも試してみましょう！ (伏線回収) 105

Slide 106

Slide 106 text

106 106 どれも試してみましょう！ (多いけど少しずつ...)

Slide 107

Slide 107 text

107 107 両睨みしましょう🐍 ● AI技術群は進化や発展がとても速く、最⾼のものはすぐに塗り変わってしまう。 ● 関わるプロダクトや⼈によっても最⾼は変わる。 ● 特定のAIエージェントや技術だけを使うのではなく、いつでも乗り換えられるように両睨みすべき。 ● 最新の情報をキャッチアップして、実際に試して、より良い場合に乗り換える柔軟さが強みになりそう。

Slide 108

Slide 108 text

現場では ● Four keysを指標として⽣産性の向上を測定 ● チームごとで測定結果が異なる場合がある ● 指標を⽬標とするのではなく気づきのヒントとして、アクションを繰り返し、試⾏錯誤するまとめ1 108

Slide 109

Slide 109 text

研究では ● 単純なプログラミングテストによるベンチマークや、OSSのissueをcloseさせられるかで判定するベンチマークがある ● テストが通るかどうかで判定しており、保守性などの要件はテストされていない 109 まとめ2

Slide 110

Slide 110 text

● 研究で⾒ている部分と現場で⾒ている部分はAI エージェントを⽤いた開発フローの⼀つの側⾯ ● 開発フロー全体を⾒て議論をしていく必要がある ● AIによる開発の”最⾼”は変化が激しい ● 特定の物だけを使うのではなく、両睨みするためにたくさんキャッチアップしていくことが重要 110 むすび

Slide 111

Slide 111 text

111 Let’s AI Let’s Buri