4つのAI開発ツールを同じ課題で試す手順。見るのは直した時間と費用

11テスト中10件でも、重複した指定を見逃す

2026年10月26日、配布ZIPの開始コードと11個のテストを使い、手で用意した変更案を一時フォルダーで実行しました。Codex、Claude Code、Cursor、Copilotを実行した成績ではありません。選定前に、合格条件が見逃してはいけない変更を捉えるかを確かめた教材です。

実行したコード	通過／不適合	残った問題
配布した開始コード	4／7	statusの検証と絞り込みが未実装
条件を加えた手書き例	11／0	この11条件に適合。性能・実認証などは対象外
所属会社の条件を取り除いた例	7／4	他社の見積りが混ざり、件数や内容が変わる
statusの重複を許した例	10／1	同じstatusを二度渡した要求を拒否できない

練習素材のZIPには、元の四ファイルを保ったまま、この確認用のPythonファイルを追加しています。展開後に python3 verify-exercise.py を実行します。Node.js 22以降も必要です。元のファイルを書き換えず、外部通信は行いません。

ツールの比較では、各候補へ元の同じ開始コードを渡します。候補がテスト自体を書き換えていれば、実装の合格とは分けて差分を確認します。11件通過した後も、他社データの扱い、未承認の外部送信、余分な機能追加を人が読み、採用までの修正時間と費用へ含めます。

試用から選定までの4ステップ

1. 同じ課題を用意する。 下の練習素材には、開始コード、架空データ、合格条件のテストが入っています。開発担当者が各候補へ独立したコピーを渡します。
2. 試す条件をそろえる。 作業する画面、使うモデル、渡す資料、許可する操作を決めます。会社のコードや本番データを使う前に、契約と送信範囲も調べます。
3. 完成した変更を人が確かめる。 テスト結果と変更内容を読み、追加で直した箇所、見直しから完成までの時間、費用を記録します。
4. 合格した候補を比べる。 必要な変更が完成し、次の担当者が保守できることを前提に、人の手間と費用で選びます。

練習素材（ZIP）と試用条件表・採点票（Excel）を使えます。以下は試用を組み立てる手順です。製品ごとの成績は、実施した結果を採点票へ記入します。公式仕様の確認日は2026年9月15日です。

支援と作業代行の違い

コード補完は、入力中の続きを提案する支援です。会話による編集は、相談した修正をコードに反映します。さらに、関連ファイルを探し、編集し、コマンドで検証する一連の作業を進める機能があります。本稿では後者を「エージェント」と呼びます。まず、欲しいものが補完なのか、変更を確認まで進める作業なのかを決めます。

OpenAIはCodex、AnthropicはClaude Codeの利用画面を案内しています。Cursorには編集支援、VS Codeにはエージェント用ツールがあります。試用する画面を、既存のローカルリポジトリを調査・編集・テストする次の4通りにそろえます。

表1｜今回そろえる利用画面と対象範囲

比較候補	今回使う画面・作業	今回混ぜないもの
Codex	Codex CLI。ターミナルからローカルのコードを調査・編集・実行する。	Codexのクラウド実行、IDE拡張機能
Claude Code	Claude Code CLI。ターミナルからローカルのコードを調査・編集・実行する。	Web・デスクトップ等の別の利用画面
Cursor	Cursorエディタ内の標準Agent。ワークスペースの編集とコマンドを扱う。	Cursor上のCodex拡張機能、Cloud Agent
GitHub Copilot	VS Code内のAgent。ローカルの編集・コマンド用ツールを使う。	Copilot cloud agent、コードレビュー単独

製品名、AIモデル名、作業画面を分けて記録します。例えばCodexの拡張機能はCursorでも利用できます。「Cursorを使う」とだけ記録すると、Cursor標準のAgentなのかCodexなのかが曖昧です。併用はできますが、試用では実際に作業したエージェントまで記録します。

同じ変更で試用する

試用環境を用意する開発担当者は、後半の「ローカルとクラウドを比べる」「操作できる範囲を確認する」を読み、許可する操作と扱う情報をそろえてから始めてください。

「見積り一覧を絞り込む」課題で試す

説明用の架空課題は、見積り一覧API「GET /quotes」にstatusによる絞り込みを追加する変更です。既存の認証とページ送りを維持し、認証済みの所属T1に対する結果だけを返します。状態はdraft、sent、accepted。ID昇順、1ページ2件とし、totalは絞り込み後・ページ送り前の件数です。

架空データは、T1のQ001・Q003がdraft、Q002・Q004がsent、T2のQ005がaccepted、Q006がsentです。これを共通の開始データにして、実装・テスト・動かし方の説明を依頼します。依存関係の追加やデータ構造の変更は認めません。課題仕様と共通指示文は、配布Excelの試用条件表・採点票に収録しています。

開始コード・架空データ・テストをまとめた練習素材（ZIP）を用意しました。Node.js 20以上で動き、外部パッケージ・通信・実データは使いません。APIの処理を関数として再現した教材です。

開始時は既存の認証・ページ送りなど4テストが通り、追加機能の7テストが失敗します。各製品へ独立したコピーを渡し、実装後に計11テストと次の受入条件を照らし合わせます。

表2｜合成課題の受入条件（想定例）

確認項目	T1として送る条件	期待する結果
指定なし	statusなし、page=1	200。Q001・Q002、total=4
下書き	status=draft、page=1	200。Q001・Q003、total=2
送付済み	status=sent、page=1	200。Q002・Q004、total=2
ページ送り	status=sent、page=2	200。itemsは空、total=2
他社との分離	status=accepted、page=1	200。itemsは空、total=0。T2のQ005を返さない。
不正な指定	空文字、未知の値、statusの重複を別々に確認	それぞれ400。既存の認証・ページ検証も維持する。

AIが追加したテストの成功後も、担当者が受入条件と既存テストを照合し、権限や表示件数の検査が抜けていないかを見ます。GitHubも、Copilotのコードレビューはすべての問題を見つける保証がなく、結果の検証が必要だと説明しています。

時間・採点・費用を分けて読む

人の時間は、準備、要件理解、操作・実行確認、修正、レビュー・受入に分けて記録します。別に、開始から終了までの経過時間を残します。AIの待ち時間中に別の仕事をしていた場合は、その時間を人の作業時間から分けます。再試行や失敗も同じ記録に残し、成功した最短の1回だけを抜き出さないようにします。

まず表2の合否、人が直した箇所と時間、費用を比べます。利用許可、権限順守、全受入・既存テスト、人の最終確認に一つでも不適合があれば対象外、未確認があれば保留です。速さや点数で相殺しません。

合格した候補をさらに比べる、任意の採点例

点数を付ける場合の配点例は、要件理解30点、確認の再現性25点、差分の適切さ20点、レビューへの対応15点、引き継ぎ10点です。各項目を0・1・2で記録し、「評価÷2×重み」を合計します。

次の例で0・1・2点の意味をそろえます。実行していない項目は0点にせず「未確認」とします。

項目	0点	1点	2点
要件理解	状態による絞り込みや他社との分離を取り違え、説明後も直らない	条件の指摘を受けて実装を直した	最初の実装で絞り込み・所属・件数の条件を満たした
確認の再現性	実行したと言うだけで結果を再確認できない	手順の補足後に同じ結果を確認できた	同じ開始コードと手順で11テストの結果を再確認できた
差分の適切さ	不要な変更が残り、既存処理を壊す	不要な変更を指摘後に戻した	必要なファイルだけを変え、既存処理を維持した
レビューへの対応	具体的な指摘を反映できない	再説明を受けて修正できた	最初の具体的な指摘で修正し、影響を確かめた
引き継ぎ	動かし方や変更理由が分からない	説明を補ってもらえば次の担当が動かせる	変更理由・実行手順・残課題がそろい、次の担当が動かせる

表3｜採点票の読み方（想定例・特定製品とは無関係）

項目	架空の試用A	架空の試用B
開始前・完了後の必須確認	すべて適合	権限順守が不適合
5項目の評価（上記の順）	2・2・1・1・2	すべて2と記入していても対象外
集計対象の点数	82.5／100点	集計しない
人の作業時間／経過時間	70分／95分	速く終わっても採用理由にしない
費用の記入例	人件費換算7,000円＋契約配賦100円＋追加利用200円＋実行環境0円＝7,300円	違反した試用の費用も別途記録する

試用Aの金額はすべて税抜きの仮定で、人の時間単価は6,000円／時です。契約の月額を予定試行数で割り当てると、この架空例では100円、追加利用は実際の増分請求に相当する仮定値200円としています。契約内の消費量を金額換算した表示を、追加請求として二重に足しません。実際の支払額は各社の請求明細で確かめます。

この小さな課題が成立しても、大規模なデータ移行、高負荷への対応、顧客データを使う本番運用の適性までは分かりません。クラウドで並行作業を任せたい場合も、今回のローカル比較の結論をそのまま使えません。追加で必要な受入条件は発注側の業務責任者から、データ・通信の許可は情報管理者から、再現できる環境は開発担当者から集め、別の試用条件を作ります。

ローカルとクラウドを比べる

ローカル型では、自分の開発環境にあるファイルや実行コマンドが比較対象になります。クラウド型では、リポジトリを置く環境、依存関係の準備、認証情報、外部通信の条件を別に調べます。GitHubも、クラウドエージェントとIDE内のAgentを区別して説明しています。製品全体を「ローカル専用」「クラウド専用」と決めつけないことが出発点です。

ローカルで動くツールも、コードや指示を社外へ送る場合があります。Claude Codeの資料でも、ローカル動作とモデルへのネットワーク通信が併記されています。また、モデルの学習に使われない条件と、データの保持期間がゼロである条件は同じではありません。利用する契約、認証先、送信内容、保持、削除の条件を、自社の管理者が提供元の文書と照合してください。

試用でそろえる「リポジトリ情報」は、同じ開始時点のコード、依存関係、要件、既存テスト、参照を許可した資料です。開始コミットの識別子と作業ディレクトリを記録し、各製品には独立したコピーと新しい会話を渡します。前の製品の修正や会話履歴を、次の製品の開始条件に混ぜません。

同じモデル名を選ぶ場合も、参照資料やツールの設定をそろえます。CursorはAgentの構成要素を指示・ツール・モデルに分けています。本稿ではこの構成を踏まえ、参照資料やツールの設定も記録する方法を提案します。別モデルを使う場合は「その製品と設定の組合せの試用」とし、モデル単体の優劣とは分けて読みます。

操作できる範囲を確認する

「外へ送信しないで」という指示に加え、設定で実行権限を制限します。Claude Codeの許可設定はプロンプトの指示とは別で、コマンドの文字列照合にも限界があります。Codexも、実行可能な範囲を限定するサンドボックスと、利用者に確認する承認設定を分けています。指示は作業方針、設定や隔離は操作の境界として扱います。

承認の単位は、操作ごとに違います。Cursorではワークスペースへの編集が先に反映される一方、ターミナル実行の承認は別に扱われます。VS Codeでもツールの有効化と承認は別で、ターミナル用の制約が適用される範囲を確かめます。「承認あり」という一欄だけで判断せず、ファイル、コマンド、通信、公開操作に分けて確認します。

試用環境を用意する人向け：4候補の共通条件と制限

表4｜4候補に共通の試用条件（提案・未実施）

確認項目	今回の設定方針と残す記録
作業する画面	表1のローカル形態を使う。実施時に製品版・OS・モデル・認証方法を記録する。
リポジトリ情報	同じ開始コミットの独立コピー。架空データのみ。共通の要件文と既存テストを渡す。
コマンドと外部アクセス	編集は試用コピー内。内容を読んだテスト・型検査のみ許可。エージェントの外部通信・検索・外部連携は停止する。承認済みAIサービスへの推論・認証通信とは区別する。
禁止する操作	秘密情報・本番データを置かない。リモートへの送信、公開、ブランチ変更、課金操作を許可しない。自動再読込・監視プロセスを停止する。
差分と確認	開始時との差分、実行ログ、受入結果、修正履歴を保存。停止時はセッションだけでなく子プロセスの終了も見る。
組織設定と費用	利用許可、設定の適用範囲、使用量と追加請求の区別を調べる。不明な条件は「不明」と記録し、適合扱いにしない。

表4は試用前に決める設定方針です。製品版とOSで必要な制限を実現できるか、開始前に試します。実現できない候補は、同条件比較から外すか、同等に隔離した環境を用意して再設計します。また、許可するコマンド名が同じでも、AIがテスト用スクリプトを書き換えれば実行内容は変わります。差分を見ずに「npm testだから安全」と判断しないでください。

採用後に残すもの

選定後は、担当者が通常の開発環境で保守できるようにします。ソースコード、変更理由、セットアップ方法、実行するコマンド、受入結果、残る問題を、リポジトリのREADMEや変更記録にまとめます。担当者が通常の開発環境から内容を読み、検証を再実行できるかを確認します。

チームで使うときは、利用者の追加・削除、設定の強制、認証経路、ログの閲覧、利用上限と超過時の扱いを管理者と決めます。これらがどの契約で使えるかは別問題です。「個人で使えた」ことを、会社としての利用許可や管理機能の代わりにしないでください。

費用は月額と、利用量に応じた追加費用を合わせて比べます。CodexはChatGPT契約の利用枠・追加クレジットとAPIキーの課金を区別します。Claude Codeも契約とConsole等の認証経路を確認します。Cursorは契約内の利用枠と追加利用、GitHub Copilotは席数とGitHub AI Creditsの条件を確認します。採用前に、使うモデル・作業形態での利用量と、人の確認・修正に必要な費用を合わせて確認します。

迷ったら、現在の画面と権限条件に合う候補から、同じ課題で「人がどこを見て、何を直し、何を引き継げたか」を比べてください。自分たちの作業と見直し方に合う組合せを選びます。

関連する確認と相談

発注者が見る品質確認や引き継ぎについては、AIネイティブ開発｜人の確認と品質・引き継ぎで説明しています。ツール選択と、開発全体の品質を確かめる仕組みは分けて考えます。

自社の業務、AIに渡してよい情報、利用条件を整理したい場合は、AI業務改善診断で試用前の課題を確認できます。

ツールを導入した後も自社に残る仕事を見て、内製・外注・併用の体制を比較できます（システム開発の内製・外注・併用｜体制と総費用）。

AI業務改善診断を見る

参考出典

• OpenAI「ChatGPT Learn」
• OpenAI「Codex CLI」
• OpenAI「Codex IDE extension」
• OpenAI「Agent approvals and security」
• OpenAI「Pricing」
• Anthropic「Claude Code overview」
• Anthropic「Configure permissions」
• Anthropic「Data usage」
• Anthropic「Manage costs effectively」
• Cursor「Cursor Documentation」
• Cursor「Agent overview」
• Cursor「Agent security」
• Cursor「Models & Pricing」
• GitHub「About GitHub Copilot code review」
• VS Code「Use tools with agents」
• GitHub「About GitHub Copilot cloud agent」
• GitHub「Plans for GitHub Copilot」
• VS Code「Manage approvals and permissions」