AIエージェント の記事一覧

この記事は GMOインターネットグループ Advent Calendar 2025 17日目の記事です。 本ブログの概要 こんにちは！GMOペパボのどすこいです！EC事業部でカラーミーショップというプロダクトの開発をしています！去年に引き続きGMOインターネットグループ Advent CalendarにAIの話を持ってきました！！ 昨今、ソフトウェア開発のためのコード生成を行うAIエージェント(以下、コーディングAIエージェント)は著しく進歩しています。日常業務で使う方も増えていることでしょう。しかし、AIに渡す入力や出力は状況によって異なっているはずです。どうやって進歩していると判断することができるのでしょうか？コーディングAIエージェント同士の精度は、何によって優劣が付けられているのでしょうか？ コーディングAIエージェントの評価には、利用者が触って感じる定性評価の他に、ベンチマークテスト等で測られる定量的な評価手法が、提案され、利用されています。 そこで、本記事では、コーディングAIエージェントの進歩を測る定量的な評価手法や評価について紹介します。その後、このベンチマークの検証を手元で試し、エンジニアが実環境で利用する使い方との違いについて考えます。本記事でお伝えする以下の事柄をもとに、AIをよりうまく使いこなすためのヒントやきっかけとなれば幸いです。 コーディングAIエージェントの定量的な評価手法の紹介コーディングAIエージェントの定量的な評価手法と、エンジニアが実際に利用する際の違い定量的な評価手法と定性的な評価手法の違いをもとにした、筆者の考える、コーディングAIエージェントを使いこなすヒント なお、本記事の内容は、私のいくつかの登壇資料と重なる点があります。参考として、もしよければ合わせてご覧ください。 https://speakerdeck.com/daisuketakeda/ruo-miwodeep-divesuru https://speakerdeck.com/daisuketakeda/goniokeru-sheng-cheng-ainiyorukodosheng-cheng-no-bentimakuping-jia-ru-men コーディングAIエージェントを用いた生成AIの評価 コーディングAIエージェントを用いた生成AIの評価をするためのベンチマークに、よく知られているものが2種類あります。1つは基礎的なコード生成能力を測るもの、もう1つは現実のソフトウェア開発に近い能力を測るものです。順番に紹介します。 AIのコード生成能力はどう測る？ ― HumanEvalベンチマーク 2021年7月、OpenAIはCodexというLLMを発表しました。Codexは、後にGitHub Copilotの基盤となったモデルです(GitHub Blog: "Introducing GitHub Copilot: your AI pair programmer")。このCodexの能力を正しく評価するために、OpenAIはLLMのコード生成能力の評価のためのベンチマークを新たに作成しました。 HumanEval ― コード生成能力評価の出発点 HumanEval(Evaluating Large Language Models Trained on Code)というベンチマークは、OpenAIの研究者たちが手作業で164個の新しいプログラミング問題を作成したものです。既存のプログラミング問題集（LeetCodeなど）はインターネット上に公開されており、モデルの訓練データに含まれている可能性があります。訓練データに含まれている問題で評価しても、モデルの真の能力は測れません。そのため、手作業によってベンチマークの問題が作られました。難易度としては、シンプルなソフトウェア面接問題レベルとなっています。 HumanEvalでは、関数のドキュメント文字列を与えて、その仕様を満たす実装を生成できるかを評価します。生成されたコードは、用意されたユニットテストで自動的に検証されます。 HumanEval-XL ― 多言語への拡張 HumanEvalによってコード生成能力の評価が可能になりましたが、いくつかの課題がありました Pythonに限定されている ― Go、Java、Rustなど他の言語での能力が測れない問題文が英語のみ ― 多言語の自然言語理解能力が測れない これらの課題を解決するために、2024年にHumanEval-XL(HumanEval-XL: A Multilingual Code Generation Benchmark)が発表されました。 HumanEval-XLは、23の自然言語 × 12のプログラミング言語という大規模な組み合わせに対応しています。例えば日本語の問題文からGoのコードを生成するといった、より実践的なシナリオでの評価が可能になりました。 コード生成能力の評価指標：pass@k ところで、AIが生成したコードの正しさをどう測るのかは、実は自明ではないトピックです。例えば、「リストの要素を合計する関数を書いて」というPythonの問題に対して、以下の2つの回答はどちらも正しいです。 # 回答A def sum_list(lst): return sum(lst) # 回答B def sum_list(lst): total = 0 for item in lst: total += item return total 機械翻訳の分野ではBLEUスコア1[^1]のようなテキストの一致度で評価されますが、コード生成においてはどうでしょうか。テキスト一致度において、上記の例では異なる回答になってしまいます。しかし、機能としては同じです2[^2]。そこで使われるのが機能的正しさによる評価です。生成されたコードを実際に実行し、ユニットテストを通過するかどうかで判定します。つまり、見た目ではなく正しい機能かどうかで評価します。 HumanEvalやHumanEval-XLでは、pass@kという指標で評価します。これは、k回コードを生成して、少なくとも1回はテストを通過する確率を表しています。具体的には以下のようなものが使われています。 pass@1: 1回の生成で正解できる確率。one-shotで正解ができるかという指標になる。pass@10: 10回生成して、正解が含まれる確率。対話の中正解ができるかという指標になる。pass@100: 100回生成して、正解が含まれる確率。AIモデルの潜在能力の上限を表す指標になる。 LLMによるコード生成には、ある程度のランダム性があります。同じ問題でも、生成するたびに異なるコードが出力されます。そのため、「1回で正解できるか」だけでなく、「何回か試せば正解できるか」という観点も重要になります。 2021年時点でのCodexは1回で正解できる確率は約29%でしたが、100回試せば70%の問題を解けました。繰り返し生成するというシンプルな戦略でも、成功率を大きく改善されることが当時からわかっていました。 連続する文字の並びと、事前に用意した正解文章に含まれる連続する文字の並びが比較され、一致数がカウントされ、重み付けして算出するスコアのことOpenAIのCodex論文では「同じ機能を実現するコードには無数の書き方があるため、テキスト一致度ベースの評価には限界がある」と指摘されています。詳細は Evaluating Large Language Models Trained on Code を参照 実際のソフトウェア開発に近い評価とは？ ― SWE-bench HumanEvalのような問題は、数行で完結する関数生成が中心です。しかし、現実のソフトウェア開発では、既存の大規模なコードベースを理解し、適切な箇所を修正する能力が求められます。関数を1つ書くのと既存のプロジェクトのバグを直すのでは、求められる能力が大きく異なります。後者は、巨大なコード行数があるコードベースを理解し、その中で問題の原因となっている箇所を特定し、他の部分に影響を与えないように修正するといったような、高度な能力が求められます。 このような現実のソフトウェアエンジニアリングに近い能力を測るために作られたのがSWE-benchです。 SWE-bench ― GitHubの実際のIssueを解決できるか？ 2023年10月、Princeton大学とシカゴ大学の研究者たちがSWE-bench(SWE-bench: Can Language Models Resolve Real-World GitHub Issues?)を発表しました。このベンチマークは、GitHubの実際のIssueを解決し、修正パッチを作成できるかをテストします。これはpass@1による評価をしており、one-shotでの評価となっています。 SWE-benchの特徴は、実際のオープンソースプロジェクトから収集したIssue-Pull Requestペアを使用している点です。対象はDjango、Flask、scikit-learnなど12の人気Pythonリポジトリで、モデルには"Issueの説明文"と"コードベース全体"が与えられ、問題を解決するパッチを生成することが求められます。 発表当時の最先端モデルでも、SWE-benchの成績は低いものでした。Claude 2で4.8%、GPT-4で1.7%という解決率です。HumanEvalで高いスコアを出していたモデルでも、実際のGitHub Issueを解決するタスクでは成績が下がりました。これは前述したように、"関数を1つ書く能力と"実際のバグを直す能力"が異なることを示しています。 SWE-bench Multilingual ― Python以外の言語での評価 SWE-benchによって現実の開発に近い評価が可能になりましたが、Pythonのみという制約がありました。Go、Java、Rustなど他の言語でのAIエージェントの能力を測ることができません。この課題を解決するために、2つの多言語対応ベンチマークが登場しました。 1つ目はSWE-bench Multilingual（公式拡張）です。C、C++、Go、Java、JavaScript、TypeScript、PHP、Ruby、Rustの9言語に対応し、42のリポジトリから問題が収集されています。 2つ目はMulti-SWE-bench（NeurIPS 2025採択）です。68名の専門アノテーターによる検証を経て、Java、TypeScript、JavaScript、Go、Rust、C、C++の7言語に対応しています。 SWE-bench Multilingualでは、言語によって解決率に大きな差があることが報告されています。SWE-agent + Claude 3.7 Sonnetの組み合わせでの結果では、Rustが最も高い解決率を示し、Goは中程度、C/C++は最も低い解決率となりました。全体では約43%のタスクを解決できたと報告されています。 実際にSWE-Bench Multilingualのタスクを手元で試してみる ここまで、ベンチマークをいくつか紹介しましたが、エンジニアが実環境でAIエージェントを使う時と、ベンチマークテストには違いがあります。エンジニアの実環境では、人間が判断とフィードバックをします。しかし、この違いによってベンチマークの結果は変わりうるのでしょうか。人間によって、解けなかったissueが本当に解けるようになるのでしょうか。 このことを検証するため、ここからは実際に一つベンチマークテストを動かして、AIが問題を解けるか試してみることとしましょう！ベンチマークに近い方法で実行する場合と、業務で使っているエンジニアの私の普段の方法で実行する場合を比較します。ここではSWE-Bench Multilingualにおける、Goのタスクを扱います。 なぜGoを選んだのか SWE-bench Multilingualでは言語によって解決率に大きな差があります。SWE-bench Multilingual公式ページによると、SWE-agent + Claude 3.7 Sonnetの組み合わせで、Goの解決率は30.95%と、Rust (58.14%) や Java (53.49%) に比べて低い結果となっています。 シンプルさを重要視している言語であるGoは、個人的にも特に扱いやすいプログラミング言語だと思っており、AIの生成精度も高いはずと予想していました。しかし、実際にはそうではありませんでした。この違いを体験するためにも、あえてGoのタスクを選んでみます。 その中でも、Goにおけるリポジトリごとの解決率がcaddyserver/caddyが最も難しく、14タスク中12タスクが未解決でした。この中の一つで、特に変更行数も多かったcaddyserver/caddy #5626で試してみます。 注意 元のベンチーマークではClaude 3.7 Sonnetを使っていましたが、手元の検証ではClaude Code v2.0.69 + claude-haiku-4-5-20251001での実験になります。また、性能について、Claude Haiku 4.5は、Claude Sonnet 4よりもSWE-bench Verifiedにおいて高いスコアでした(Introdcing Claude Haiku 4.5)。正確な比較とはなっていませんが、どのようにして手元で検証するのか方法を明らかにすることを優先しました。 また、このベンチマークは、同じ条件でAIモデルの性能比較のために使われるものです。つまり、実務での使いやすさを測るものではなく、人間の介入やフィードバックがある時のベンチマークではないということに注意しましょう。 SWE-Bench Multilingualのタスクの再現方法 準備 SWE-bench Multilingualの評価環境を再現するため、いくつかの工夫をします。 まず、リポジトリをshallow cloneし、ベースコミット（バグがある状態）をチェックアウトします。これにより、正解の修正コミットがAIから見えない状態を作れます。 git clone --depth 1 https://github.com/caddyserver/caddy.git cd caddy git fetch --depth 1 origin 0e2c7e1d35b287fc0e56d6db2951f791e09b5a37 git checkout 0e2c7e1d35b287fc0e56d6db2951f791e09b5a37 次に、テストを追加してバグを確認します。SWE-bench MultilingualではテストコードはAIに与えられないため、バグの再現を確認したらgit reset --hardでテストを消します。これでテストの中身を見てヒントを得ることができなくなります。また、ここでの検証は、手元のバージョンとは異なるGoを使うことになると思うので、Dockerを用いて行いました。 AIエージェントへの指示 SWE-bench Multilingualでは以下のようにGitHub Issueの本文のみがAIエージェントに与えられます。修正が必要なファイルやヒントは与えられません。 fix this issue: --- Caddy 2.7.0-beta.2: nested imports in handler broken (again) I think the same problem problem existed before (#4914) but was supposed to be fixed. It actually worked in beta.1 but is now broken again. The following example fails: (responderWithStatus) { respond {args[0]} {args[1]} } (responder) { import responderWithStatus {args[0]} 202 } http://127.0.0.1:8080 { handle { import responder "foobar" } } 2023/07/10 12:25:30.379 INFO using adjacent Caddyfile Error: adapting config using caddyfile: parsing caddyfile tokens for 'handle': Caddyfile:12 - Error during parsing: unrecognized directive: import - are you sure your Caddyfile structure (nesting and braces) is correct?, import chain: [''] --- AIはこの情報だけで修正箇所を特定し、コードを修正する必要があります。 ベンチマークの方法に近いone-shotの検証では、前述したバージョンのClaude Codeを起動して、/modelでモデルをClaude Haikuにセットし、dangerously skipモードで実行しました。手元で実際に試す場合はお気をつけください。 検証方法 AIが修正を完了したら、テストを追加してパスするか確認します。さらに、既存のテストが壊れていないかも確認します。 今回検証するissueの概要 今回検証するissueとその修正PRについて簡単に説明します。 Caddyは設定ファイル（Caddyfile）を読み込んでWebサーバーを起動します。Caddyfileにはimportという機能があり、よく使う設定をテンプレート化して再利用できます。プログラミング言語のimportやincludeに似た機能です。 問題は、importを入れ子にすると動かなくなったことでした。テンプレートAがテンプレートBを呼び出し、テンプレートBがさらにテンプレートCを呼び出す...という使い方ができなくなっていました。 正解の修正は、Caddyfileを読み込む処理（パーサー）の中にありました。パーサーは設定ファイルを1行ずつ読み込みますが、「次の行に移ったかどうか」を判定する処理がありました。この判定が、「どのimportから来た設定か」を考慮していなかったため、入れ子のimportで混乱していたのです。正解は、この判定処理を修正し、3ファイルにまたがる55行の変更が必要でした。 ベンチマークの方法に近いone-shotでの検証結果 dangerously skipモードで、one-shotで実行した結果は次のようになりました。 AIはまずコードベースを探索し、設定ファイルを読み込む処理（パーサー）を調査しました。行番号の判定ロジックに問題がありそうだと推測し、その部分を修正しました。 結果はテスト失敗。ただし、検証用自動テストのエラー内容が、修正前後で異なっていました。 修正前：unrecognized directive: import 修正後：Wrong argument count or unexpected line ending after '}' importが認識されないという元の問題は解消されましたが、別のエラーが発生しました。 AIの修正は惜しいところまで行っていました。問題の場所は正しく特定できていましたが、「どのimportから来た設定か」を追跡する内部構造の存在に気づけませんでした。AIは症状から行番号がおかしいと推測しましたが、根本原因はimport元の追跡にあったため、表面的な修正では解決できませんでした。 実環境のエンジニアの使い方での検証結果 実環境においてエンジニアである私は、コーディングAIエージェントと伴走して開発をすることがしばしばあります。その際に指示の最後に私が伴走します。Explore, Plan, Coding, Commitの順でやりましょうというようなプロンプトを加えます。これはAnthropicのClaude Code: Best practices for agentic codingという記事に書かれているプラクティスになっています。今回もこれを最初のissueの指示に加えました。 結果はテスト成功。検証に用いるユニットテストがパスしました。この中でAIエージェントは次のように動きました。 AIはコードベースを深掘り調査し、one-shotでは見つけられなかった根本原因にたどり着きました。one-shotでは行番号の判定がおかしいと推測していましたが、実際は「テンプレートを保存するタイミングでimportが展開されていない」という構造的な問題でした。まずは調査をすることで、構造的な問題に気づくことができていました。 原因が判明したのち、AIは3つのアプローチを提案し、最も適切なアプローチを選び、実装をしました。その結果、テストはパスした他、既存のテストの故障もありませんでした。 このことから、ベンチマークテストでの方法と異なる、人間が伴走するコーディングAIエージェントの使い方だと、解けなかった問題が解けるようになることがわかりました。 むすび 本記事では、AIエージェントのコーディング領域における評価方法と、私たちエンジニアの普段の使い方との違いについて紹介しました！ AIエージェントの能力の進歩は著しく、圧倒されてしまうものです。しかし、その進歩を具体的に知ることが、変化の激しいAI時代を生き抜くきっかけかもしれません。また、AIの評価に対する理解を通して、日々進化していくAIエージェントを使いこなすためのヒントが得られると幸いです！