AIコーディングツールを自分のリポジトリで試す:試用期間の評価シートの作り方

試す前に決める3つのこと

1. 課題は「過去に自分がやった作業」から選ぶ

ベンチマーク向けの題材ではなく、直近1〜2か月のコミット履歴やチケットから選びます。種類をばらけさせると、ツールごとの得意・不得意が見えやすくなります。

• 小さな修正(バグ1件、型エラーの解消など)
• 既存コードを読んで把握する作業(「この関数の呼び出し元を洗い出して」など)
• 複数ファイルにまたがる変更(機能追加、リネーム、仕様変更)
• テストやドキュメントの追加

すでに自分で解決済みの課題なら、正解の差分(自分の実際のコミット)と比べられます。

2. 合格条件を先に書く

Claude Codeのベストプラクティスは、冒頭でリポジトリから見えない情報を伝えることと、AIに「実行して確かめる手段」を渡すことを挙げています。評価でも同じで、「テストが通る」「型チェックが通る」「この関数の戻り値がこうなる」といった合格条件を課題ごとに先に決めておけば、ツールごとに判定がぶれません。テストがない課題は、人が見る確認項目を3つ書いておきます。

3. 条件をそろえ、データの扱いを確認する

• コードの状態:課題ごとに同じコミットから作業ブランチを切り、ツールごとにやり直します。前のツールの変更を持ち越さないためです。
• プラン:無料枠と有料プランでは使える機能や上限が違うことがあります。たとえばGitHub Copilotのプラン比較では、Copilot Freeのインライン補完は月2,000回までで、選べるモデルもプランによって異なります(2026年10月29日に閲覧した時点の内容で、変わる可能性があります)。比較は、実際に契約するつもりのプランで行ってください。
• 利用場所:Claude Codeはターミナル、IDE、デスクトップアプリ、Webで使え、多くの利用形態でClaudeの契約かConsoleアカウントが必要です。使うエディタやOSが違うと条件がそろわないので、シートに環境を書きます。
• データ設定:たとえばCursorはデータ利用の説明ページ(最終更新日表示は2026年9月3日)で、Privacy Modeを有効にするとCursorは顧客データを学習に使わず、無効の場合はコードや入力内容を機能改善や学習に使うことがあると説明しています。ページには、プロンプト等が不正利用検知に反応した場合に調査のためデータが保持されることがあるとも記載されています。設定や提供元の扱いを確認し、社内ルールに従ってください。迷うなら説明用のダミーのリポジトリか、公開してよいコードで試してください。

評価シートの雛形

課題ごとに1枚、ツールごとに1列で記入します。コピーして使ってください(項目や基準は説明用の例です)。

【試用メタ情報】
ツール名/バージョン:
プラン:            モデル設定(自動/指定):
利用場所(CLI/IDE等):  データ設定(学習利用の可否など):
試した日:

【課題】 ID:T1  種類:(修正/読解/複数ファイル/テスト)
基準コミット:        合格条件:
 1.
 2.
 3.

【記録】
□ 受け入れ判定:A そのまま / B 軽微修正 / C 大幅修正 / D 破棄
□ 合格条件の達成:  初回 / 修正後 / 未達
□ 私の修正時間(分):
□ 指示のやり取り(回):
□ 範囲外のファイル変更(件):
□ 事実誤りや存在しないAPIの使用:  あり / なし
□ 承認操作の手間:  少 / 中 / 多
□ 待ち時間の体感:  短 / 中 / 長
□ 使用量の消費(画面に出る範囲で):
□ 良かった点/困った点(1行):

【最終メモ】 このツールに次も任せたいか:  はい / 条件付き / いいえ

必須にしたいのは「受け入れ判定」「私の修正時間」「指示のやり取り」「範囲外のファイル変更」の4つです。残りは気づいたときに書く程度で構いません。記録が重いと、試用の途中で続かなくなります。

全ツール共通の依頼文

ツールによって依頼文を変えると、差が腕前の差なのか書き方の差なのか分からなくなります。次のような共通の文面を使い、課題の部分だけ差し替えます(説明用の例です)。

目的:{課題の説明を2〜3文で}
対象範囲:{触ってよいファイル/ディレクトリ}
触らないもの:{設定ファイル、他モジュールなど}
合格条件:
- {例:`npm test` の対象テストが通る}
- {例:既存の公開関数のシグネチャは変えない}
進め方:まず変更方針を3行で示し、私の了承後に実装してください。
実装後は、実行したコマンドと結果、変更したファイル一覧を報告してください。
実行していない確認を「確認済み」と書かないでください。

最後の行は評価用の工夫です。実行していない確認を「できた」と書く癖がないかも、「事実誤り」欄で観察できます。「了承後に実装」の指示は、承認操作と計画の質を比べるためのものです。自動で進むツールとは条件が変わるため、使うなら全ツールで統一してください。

採点と判断表

項目の重要度は人によって違うので、自分で重みを決めて合計します。例として、保守性重視の人の配点です(説明用の例)。

• 受け入れやすさ、見る欄：受け入れ判定A〜D(A=3, B=2, C=1, D=0)、重みの例：×3
• 手戻りの少なさ、見る欄：修正時間、やり取りの回数、重みの例：×2
• 安全性、見る欄：範囲外の変更、事実誤り、重みの例：×3
• 作業の流れ、見る欄：承認操作、待ち時間、重みの例：×1

合計点は参考値にとどめ、次の表で最終判断をします。

• 安全性の欄で事実誤りや範囲外変更が複数課題で出た、判断の目安：点数が高くても、レビュー負担が増えるので保留
• 合計は僅差で、課題の種類ごとに得意が分かれた、判断の目安：用途で使い分けるか、日常的に多い種類の課題で決める
• 全課題でCかDが多い、判断の目安：課題の説明か合格条件が不足していないか、まず依頼文を見直してから再試行
• 点は高いが、使用量の上限や承認操作が日常利用に合わない、判断の目安：契約するプランの条件で再計測

1週間で回す進め方

1. 1日目:課題を3〜5件選び、基準コミット、合格条件、共通の依頼文を作ります。
2. 2〜4日目:ツールを順に変え、同じ課題を試します。1つのツールの記録を終えてから次に移ります。
3. 5日目:シートを見直し、記入が空の欄や、後から評価が変わったものを直します。気になる課題だけ再試行します。
4. 6〜7日目:重みを付けて集計し、判断表に当てはめます。最後に「普段の自分の作業でこのツールが当たる課題はどれか」を確認して、決定します。

同じ課題を同じ人が複数回やると、2回目以降は課題の理解が進んで有利になります。ツールの試す順番を課題ごとに入れ替えるか、「順番」欄を足してください。

また、ツールやモデルは頻繁に更新されます。結果にはバージョンと日付を必ず添え、半年ほど経ったら、同じ課題で再計測する前提にしておくと、古い比較結果で判断し続けずに済みます。