AI コーディングに向いたAIの選び方

AIコーディングを選ぶときは、モデルの評判より「どこでコードを読み、どの範囲を変更し、どの権限で実行するか」を先に決めます。IDE内で小さく補助してほしいのか、terminalでtestまで回したいのか、GitHub上でissueからpull requestまで進めたいのか、独立したcloud agentへtaskを渡したいのかで候補が分かれます。同じrepositoryとtaskを使って比較し、速度や品質を宣伝文句から推測しないでください。

まずworkflowを選ぶ

表は横にスクロールできます

作業場所	候補の例	主な利点	比較時に見ること
IDE内	Cursor、GitHub Copilot	開いているcodeと編集画面の近くで質問・変更	context範囲、diff review、IDE対応、plan機能
terminal	Claude Code、Codex CLI等	command、test、Git操作を一連で進める	command許可、sandbox、filesystem/network、log
GitHub上	Copilot coding agent	issueやrepositoryのtaskからbranch / PRへつなぐ	repository permissions、Actions、review、費用
独立cloud environment	Cursor Cloud Agents、Codex cloud等	長めのtaskを隔離環境で進め、複数taskを管理	VM境界、secret、network、結果の持ち帰り方

これはexecution modelの違いであり、同一課題の品質順位ではありません。各製品の機能、利用plan、実行場所は更新されるため、導入時に公式Docsとadmin設定を確認します。たとえば「agentがPRを作れる」という説明は、PRの中身が正しいことやreview不要を意味しません。

向く条件を具体化する

IDE内で書いているコードを少しずつ直したいなら、IDE integrationから試します。既存fileの参照範囲、選択したdiff、inline edit、plan modeなどを見て、変更範囲を小さく保てるか確認します。CursorはIDE内のcoding workflowに加え、cloud agentを別VMで実行する選択肢を案内しています。IDE上の機能とcloud実行の権限条件は分けて確認します。

GitHub issueを起点に変更し、PRでreviewしたいならGitHub Copilot coding agentが候補です。GitHubのrepository permissions、branch protection、Actionsの実行条件を維持したまま作業できるか見ます。Agentが作ったcommit、test log、workflow runを確認し、必要なreviewerとrequired checksを省略しない運用にします。

terminalの既存作業を変えずに使いたいならClaude CodeやCodex CLIなどを比較します。repositoryの検索、file変更、command実行をどこまで許可するか確認し、read-only調査から始めます。MCP等の外部連携を入れる場合は、接続したDriveやissue trackerから見える情報もagentの権限境界に含めます。

複数の独立taskを同時に進めたいならcloud agentやworktree型を検討します。別VMやworktreeで作業しても、shared credential、環境変数、network access、branchへの書戻しが安全とは限りません。taskの依存関係と競合するfileを先に特定し、並列化する範囲を分けます。

10分の比較taskを設計する

ツールを変えるたびに課題の難しさが変わると比較になりません。同じrepositoryのclean branchまたは使い捨てfixtureで、変更が局所的で合否を確認できるtaskを用意します。

例：「検索フォームの空入力を拒否し、既存のvalidation styleに従う。関連testを更新し、変更理由と未確認点を説明する」。実行条件は同じにし、次を記録します。

• agentが最初に読んだfileと、誤解した仕様

• 変更したfile数とdiffの大きさ

• test / lintを自ら実行したか、結果を正確に報告したか

• 既存behaviorを壊す変更や不要なdependencyを加えたか

• secret、network、外部commandを要求したか

• reviewerが理解して修正できる説明があったか

• 1 taskあたりの人間review時間と発生費用

結果表は「pass/fail」だけで終わらせず、変更の見落としと人間の修正量を残します。同じモデルでもcontext、指示、repository状態で結果が変わります。短い比較で全種類のcoding taskに対する優劣を結論づけないでください。

Securityと権限の境界

cloud agentやterminal agentは、単に文章を提案するchatより広い操作を行う場合があります。導入前に以下を確認します。

1. filesystem：repository外、home、credential storeを読めるか。

2. command：test以外のshell commandを自動承認するか、確認を求めるか。

3. network：任意URLへの接続、package install、外部uploadが可能か。

4. secret：環境変数やCI secretをagent taskへ渡すか。必要最小限か。

5. isolation：cloud taskが別VM、container、worktreeのどこで動くか。

6. data use：codeとpromptのtraining / retention条件、plan別設定は何か。

7. prompt injection：repository issue、README、web contentの指示を無条件に実行しないか。

8. review：diff、test結果、generated artifactを人が確認してからmergeできるか。

9. cost：premium model、agent credit、Actions minutes、parallel executionの課金を追えるか。

10. audit：誰がtaskを開始し、どのfile / commandを変更したか追跡できるか。

製品のsecurity説明は、組織のpermissionが正しく構成されていることを保証しません。たとえばcloud agentが隔離VMで動く場合でも、taskに渡したrepositoryの機密コードやtokenの範囲は別途評価します。Cursorのprivacyやcloud agent security、GitHubのplan / usage条件など、実際に使う経路に対応した公式ページを確認してください。

出力を受け入れるQA

agentが「test pass」と報告しても、testが重要条件を覆っているとは限りません。merge前の最低限の受け入れ条件をtaskの種類に応じて定義します。

• diffに要件外のfileやlockfile変更がない

• acceptance criteriaごとにtestまたは手動確認がある

• authorization、validation、error pathを確認した

• test commandと結果をreviewer自身が再現できる

• build / lint / type checkの失敗を隠していない

• user-facing behaviorとbackward compatibilityを確認した

• dependency更新に理由があり、licenseとmaintenanceを確認した

• secretや個人情報がsource、test fixture、logへ入っていない

• rollback方法とmigration条件が明確

• PRを作る場合も、ownerがdiffとCIを確認する

本番database migrationや権限仕様変更は、agentへ丸ごと任せて自動mergeしません。preview、migration diff、backup、recoveryを人間が確認します。

料金と再現性

coding agentの費用は月額planだけで比較できない場合があります。Premium model request、credit、cloud runtime、GitHub Actions、team seat、外部APIのように別の利用量が発生することがあります。小さなtaskを数回試し、何に課金されるか、組織で上限を設定できるかを確認してください。料金表だけで、実際のtaskあたり費用を断定しないことが大切です。

再現性が必要なteamは、model名だけでなく、agent version、prompt、repository revision、tool permission、test commandを記録します。出力を再現できない環境でも、少なくとも最終diffとCI結果を保存すれば、何をreviewしたかは追跡できます。

AIものさしの判断

IDEでの補助ならIDE-first、GitHub issueからPRまで進めるならGitHub-centered、commandを含めてterminalで進めるならterminal-first、長時間または並列のtaskならcloud / worktree型を候補にします。選択は製品の一般的な優劣ではなく、チームが許可できる操作範囲とreview方法に合わせます。

試すときは、小さなtaskでread-only調査から始め、限定したbranchで編集とtestを許可します。同じrepositoryでdiff、testの信頼性、review時間、費用を比較し、secretとnetwork権限を広げる判断は後にします。coding qualityの独立した実測がない場合は、順位をつけず、確認できたworkflow差だけを採用してください。