AIコーディングツールを同じゲーム仕様で比べる：比較方法を先に決める
遊びをつくる執筆にClaudeを使用しています。
「GitHub CopilotとCursorのどちらが良いか」という問いに、正直に答えるのは難しい。同じゲームを同じ条件で作って比べなければ、感想の交換にしかならないからだ。この記事では、AIコーディングツールを自分の目的で比較するための方法論の設計を扱う。ツールの順位ではなく、順位を出せる手順を先に作ることが目的だ。本文はClaudeが執筆し、人間による取材・実測・校閲は行っていない。
「使ってみた感想」が比較にならない理由
AIツールの「使い心地」を語る記事は多い。しかし多くの場合、ツールAで作ったゲームとツールBで作ったゲームは仕様が違い、作者のその日の集中度も違い、使ったモデルや設定も違う。条件がそろっていなければ、違いがツールのせいなのか仕様のせいなのかを分けられない。
比較を意味あるものにするには、先に何を測るかを決めることが欠かせない。費用か、完成までの修正回数か、生成コードの再現性か。自分が一番気にしている軸を一つ決めてから実験を設計すると、結果が実際の選択に使えるものになる。
比較用ゲームの仕様を固める
比較実験の核心は「同じ問題を各ツールに解かせる」ことだ。そのためにまず、テスト用のゲーム仕様を1枚の文書にまとめる。仕様が曖昧だと、ツールが返すコードの形も変わり、修正回数の比較ができなくなる。
仕様書テンプレート（比較用）
- ゲームタイプ：単一HTMLファイルで完結するもの（例：クリックで点数が増えるカウンターゲーム）
- 完了条件：ブラウザで動き、スコアが表示され、リセットできる状態
- 使用言語：HTML／CSS／Vanilla JavaScript のみ（外部ライブラリなし）
- 禁止事項：フレームワーク指定・既存コードの流用なし
- プロンプト文言：全ツールに対して一字一句同じものを使う
ゲームは小さければ小さいほど良い。複雑な仕様はツール以外の変数（設計の難しさ）が増え、比較を汚す。まず「動くカウンター」や「1画面のクイズ」程度から始めるのが現実的だ。
そろえるべき条件と記録項目
ツールを変えるとき、同時に変わってしまいやすい条件がある。それらをあらかじめ記録欄に設けておくと、後から「あの違いはツールのせいではなくモデルの違いだった」と気づける。
記録シートの項目例
- ツール名とプラン名：例「Cursor Premium」「GitHub Copilot Pro」。プランによって使えるモデルが変わるため必須
- 使用モデル：ツール側が選択させている場合はその名称。自動選択なら「自動」と記録
- 費用：月額のうち今回の作業に使ったクレジット量の概算（ツールのダッシュボードで確認できる場合）
- プロンプト送信回数：初回生成から完了条件を満たすまでに送ったチャット・指示の回数
- 手動修正の行数：AIが生成したコードを自分で書き換えた行数の概算
- 作業時間：開始から完了条件達成まで。集中が途切れた場合は除外ルールも決める
GitHub CopilotはProプランでAIクレジット制（1クレジット＝0.01ドル相当）、Cursorはプランごとに使用量の上限が異なる。それぞれの消費量の見え方が異なるため、「費用」は月額プラン料金と消費量の両方を書いておくと後で比較しやすい。
再現性をどう確かめるか
AIの出力は確率的であり、同じプロンプトを送っても毎回同じコードが返るとは限らない。1回の試行だけで「このツールはこうだ」と決めることには限界がある。再現性を確かめたい場合は、同じプロンプトを3回送って結果を比較する最低限の手順を組み込むと良い。
確認するポイントは三つある。①完了条件を満たすコードが毎回生成されるか、②修正回数に大きなばらつきがあるか、③エラーが出る場合にエラーメッセージが一定しているか。この三つを記録するだけで、「安定して使える」かどうかの判断材料になる。
自分の制作スタイルで判断軸を選ぶ
比較結果が出たとき、何を最優先にするかで「自分に合うツール」は変わる。以下に目的別の判断軸を示す。これは評価の型であり、特定のツールを推薦するものではない。
- コストを抑えたい：無料プランでどこまで完成条件に到達できるかを先に試す。GitHub Copilot FreeはコードからAIクレジットを消費しない補完を月2,000回含む（2026年10月時点の公式ページ）
- 修正回数を減らしたい：初回生成コードが完了条件をどれだけ満たしているかの割合を記録する
- すでに使っているエディタに組み込みたい：VSCode・JetBrains・Neovimなど、自分の環境がサポートされているか公式ドキュメントで先に確認する
- フロントエンドのゲーム開発に特化したい：HTMLゲームの生成を具体的なテスト仕様でためし、完了条件の達成率を記録する
「料金が安い順に並べる」だけでは選べない。自分が月に何本のゲームを作るか、1本あたり何回プロンプトを送るかによって、同じプランでも実質的なコストパフォーマンスは大きく変わる。
比較結果を公開するときの誠実な書き方
実際に比較した結果をブログや記事として公開したい場合、読者に伝えるべき情報がある。それは「順位」だけではなく、その順位が成立した条件だ。
- 使ったプランとモデル名（バージョンも含めると再現しやすい）
- テスト仕様のゲームの内容とプロンプト文言
- 試行回数（1回なのか3回平均なのか）
- 実施した日付（モデルや料金は改訂されるため）
- 完了条件の定義（「動いた」の意味を明記する）
これらを示さない比較記事は、「その人のその日のその条件での感想」にとどまる。条件を公開することで、読者は自分の環境と照らし合わせて判断できるようになる。それが、比較方法を先に決める最大の理由だ。
この記事ではツールの実測は行っていない。上記の方法論を使って自分の制作条件で試し、その結果をもとにツールを選ぶ——そのための設計図として使ってほしい。
