Skip to Content
Docs08. コーディングエージェントコーディングエージェントの評価
上級coding-agentsevaluation更新: 2026-07-05この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

コーディングエージェントの評価

この記事の目的

公開ベンチマークのスコアを正しく読み解き、その限界を踏まえて自社のコードベース・タスクでの評価を設計できるようになります。ツールの選定・更改・乗り換えを、デモの印象ではなく再現可能なデータで判断できることが目標です。

対象読者

前提知識

本文

概要

コーディングエージェントの評価には 2 つの異なる問いがあります。

  1. ツール比較: どのツール・モデルが自分たちのタスクに向くか(選定・乗り換えの判断)
  2. 効果測定: 導入によってチームの成果は改善したか(継続・拡大の判断)

公開ベンチマークは 1 の参考情報にはなりますが、どちらの問いにも単独では答えられません。本記事は「ベンチマークの読み方」→「自社評価の設計」→「効果測定」の順で扱います。

公開ベンチマークの読み方と限界

コーディングエージェントの能力指標として最も広く引用されるのは SWE-bench 系(実在の GitHub Issue に対する修正パッチをテストで検証するベンチマーク)です。読み解く際は次の限界を踏まえます。

要するに、ベンチマークは「候補の足切り・話題のツールの相場観」には使えますが、「自社でどれが働くか」は測ってくれません。

社内評価タスクの設計

選定の中心に置くべきは、自社コードベース由来の評価セットです。Agent 評価の基礎 の原則(タスクセット・成功基準・自動化)をコーディングエージェントに適用します。

  1. タスクの採取 — 直近の実タスクから 10〜30 件を選びます。バグ修正・小機能追加・リファクタリング・テスト追加など、実際の作業分布を反映させます。正解(実際にマージされた変更)が既にあるものを選ぶと基準を作りやすいです
  2. 成功基準の定義 — 「既存 + 追加テストが通る」「リント・型検査が通る」を機械判定の下限とし、その上に人手レビュー(要件充足・過剰変更の有無)を重ねます。機械判定だけだと「テストは通るが望ましくない変更」を見逃します
  3. 測定項目 — 成功率だけでなく、人の介入回数(何度依頼し直したか)、所要時間(依頼から完了まで)、コスト(トークン・クレジット消費)を記録します。成功率が同じでも介入 1 回と 5 回では実務価値がまったく違います
  4. 条件の固定 — ツール間比較では、同じルールファイルコーディングエージェントがセッション開始時に読み込む、プロジェクト固有の指示書(AGENTS.md・CLAUDE.md など)。恒常的な規約を毎回の依頼文から分離する。相当の情報・同じ依頼文・同じ回数制限で走らせます。依頼文の質の差がツールの差に見えるのが最頻の測定ミスです

導入効果の測定

パイロット・本格導入の効果測定では、次に注意します。

  • 個人差がツール差より大きい — 使い手の依頼設計の巧拙で数倍の差が出ます。比較は同一人物内(before/after)またはランダム割付で行います
  • 先行指標と遅行指標を分ける — 先行指標(提案受け入れ率、PR 作成までのリードタイム、依頼あたり介入回数)は数週間で観測できますが、品質への影響(欠陥率、変更失敗率、レビュー負荷)は遅れて現れます。先行指標だけで「成功」と結論しないでください
  • 生成量を KPI にしない — 「AI が書いたコード行数」「生成 PR 数」は、増えるほど良い指標ではありません。レビュー・保守のコストを外部化しているだけの可能性があります
  • 自己申告バイアス — 満足度アンケートは参考情報に留め、リポジトリ・CI から取れる客観データと突き合わせます

継続的な再評価

実務での注意点

アンチパターン

  • ベンチマーク上位のツールを無検証で採用する — ハーネス・タスク分布・時点の違いにより、自社タスクでの序列は入れ替わります。→ ベンチマークは足切りに使い、選定は社内評価セットで行います
  • デモ・チュートリアルの印象で契約する — デモは成功しやすいタスクで構成されています。→ 自社の「面倒な実タスク」でパイロットします
  • 生成コード行数・PR 数を KPI にする — 量に最適化され、レビュー負荷と品質リスクが増えます。→ 成功率・介入回数・欠陥率など成果ベースの指標にします
  • 一度の評価で固定する — 半年前の評価結果は現行バージョンの実力を反映しません。→ 評価セットを保持し、定期・更新時に再実行します

チェックリスト

  • 自社コードベース由来の評価タスクセット(10 件以上)があるか
  • 成功基準が機械判定(テスト・リント)+ 人手レビューの二段で定義されているか
  • 成功率に加えて介入回数・所要時間・コストを記録しているか
  • ツール間比較で依頼文・提供情報・回数の条件を揃えたか
  • 効果測定で個人差(依頼スキル)を統制したか
  • 再評価のトリガー(定期・メジャー更新)と乗り換え基準が決まっているか

関連トピック

参考資料

TODO・未確認事項

チーム導入とレビュー体制主要コーディングエージェント比較