本文へ移動
Signalcraft
English

← Signalcraft一覧へ戻る

新しいAIコーディングツールを評価する方法

新しいAIコーディングツールを評価する方法

新しいAIコーディングツールを試すと、デモの速さや公開leaderboardの順位だけで採用したくなります。しかし、実務で知りたいのは自分のリポジトリの代表課題です。何回試すと成功し、どの程度のレビューで受け入れられるかを測ります。

ここでは、モデルとハーネスを分け、代表課題を固定し、複数回実行して判断する方法を整理します。実測値は環境ごとに変わるため、この記事は評価手順であり、特定の製品の順位表ではありません。

比較対象を分解する

観測した結果 = モデル
             × 推論設定
             × ハーネス
             × prompt / project instructions
             × tools / permissions
             × environment

同じモデルを別ハーネスで比べる試験と、同じハーネスで別モデルを比べる試験を分けます。一度に両方を変えると、結果の原因を説明できません。

代表課題を作る

公開benchmarkは候補を絞る入口として使えるが、採用判断には自分のリポジトリの課題が必要です。次の種類を最低1つずつ用意します。

  1. 小さく明確なバグ修正
  2. 複数ファイルの機能追加
  3. 既存仕様を変えないリファクタリング
  4. テスト失敗の原因調査
  5. 曖昧な依頼を計画へ変える作業
  6. 触ってはいけない範囲がある作業
  7. 文書や設定の更新

各課題に、初期commit、依頼文、許可するtools、timeout、期待するテスト、禁止変更を記録します。正解patchを1つに固定するより、満たすべき振る舞いと許容できる差分を採点できるようにします。

採点項目を先に決める

指標 観測方法
機能成功 必須テストと受け入れ条件
回帰 既存テストと差分レビュー
変更品質 差分の最小性、可読性、設計整合
自律性 人の介入回数と質問の妥当性
時間 wall-clockと人のレビュー時間
費用 input / output token、契約枠、tool料金
安全性 禁止操作、権限逸脱、秘密の扱い
再現性 同条件での成功率と結果のばらつき

同じ課題を1回だけ実行すると、偶然の成功を見分けられません。まず3〜5回を目安にし、平均だけでなく、最悪ケースと人が直した量を残します。回数は課題の費用と重要度に合わせて変えます。

実行条件を固定する

次の値をログへ残します。

  • 製品名とversion
  • model IDとsnapshot
  • provider
  • reasoning effort
  • system / project instructions
  • 利用可能なtoolsと権限
  • contextへ入れたファイル
  • 最大turn、timeout、retry
  • token使用量、料金、実行日時

OpenAIのモデルガイダンスも、代表課題で品質、最終回答、tokens、latency、costを比較する考え方を示しています。別の製品でも、同じ測定項目を使うと結果を説明しやすいです。

公開benchmarkは条件まで読む

SWE-benchは実際のGitHub issueからpatchを生成し、テストで評価します。Terminal-Benchはterminal内のend-to-end taskを検証します。

どちらも有用だが、scoreはモデル単体の値ではありません。ハーネス、prompt、tool、予算、retry、dataset versionを含む結果です。leaderboardを見るときは、次を確認します。

  • 同じdataset subsetか
  • verifiedかliveか
  • pass@1か複数試行か
  • 推論・tool予算は同じか
  • patch以外の人手修正がないか
  • 実行ログと設定が公開されているか
  • training contaminationへの対策があるか

公開値は候補選びの根拠にはなるが、自分のリポジトリでの成功率を保証しません。

導入を3段階に分ける

1. Screening

公開資料、license、対応OS、認証、価格、更新頻度を確認し、必須条件を満たさない候補を落とします。

2. Controlled evaluation

隔離したworktreeと固定commitで代表課題を実行します。外部送信、削除、公開、課金は許可しません。結果を採点表へ記録します。

3. Pilot

低リスクの実作業だけへ限定導入し、2〜4週間測ります。評価環境で見えにくい待ち時間、rate limit、設定保守、レビュー疲労を確認します。

採用条件を先に書く

たとえば次のように、実行前に基準を固定します。

  • 必須課題の成功率80%以上
  • 回帰テスト失敗0
  • 人のレビュー時間が現行比20%以上減る
  • 月間費用が予算内
  • 禁止操作0
  • 重大な結果をログから再現できる

数値はチームや課題に合わせて変えます。評価後に基準を作ると、気に入ったツールへ有利に調整しやすいです。

結論を更新できる形にする

AIツールはモデル、料金、既定prompt、permissions、rate limitが変わります。採用時の結果を永久の序列にせず、大きなversion更新または四半期ごとに同じ評価セットを再実行します。

良い評価は「最強のツール」を決めません。どの課題を、どの条件で、どの費用まで任せられるかを明確にします。評価表に失敗と人の修正を残しておくと、新しいデモを見たときも、自分の判断基準へ戻れます。