🍣

DevinとCursorを比較してみてわかった、マルチタスクエンジニアにはDevinこそが救世主である理由

2025/02/03に公開

はじめに

こんにちは。Ubieでプロダクト開発エンジニア兼社内入稿システムのPOをしている、えんぴつと申します。
「完全自律型AIソフトウェアエンジニア」Devinと、次世代AIコードエディタCursor。どちらも大きく注目されていますが、「実際どう使い分けるの?」「スクラムや日常業務に組み込むには?」と悩む方も多いのではないでしょうか。

私自身の業務内容としては、

  • プロダクトの実装
  • Epicの立案やPBIの起票
  • レビュー対応・ドキュメント整備
  • 採用関連やチーム外のステークホルダーとのアライン

という感じで開発以外のタスクもなにかと抱えています。
まとまった時間を取りづらいため、Devinのようにスキマ時間を使って開発タスクを進められる仕組みは本当にありがたいです。一方、Cursorは大きめの腰を据えた開発や実装の方針が固まっていないタスク、複数のファイルにまたがった作業などに向いていると感じています。

ここでは、DevinとCursorの特徴やフィットする使い方を、具体的なシーンを交えながら紹介します。

TL;DR

  • Devinは攻殻機動隊の世界でいうタチコマ。

    • 複数のタスクを並行して依頼が可能で、スクリーンショットの撮影も可能なので開発以外の仕事が多いエンジニアが、スキマ時間でタスクを進めるのに最適。
    • ただし、ジュニアエンジニアだと思って扱う必要があり、依頼するタスクは明確で小さなものでないと課金分のリソース(ACU)があっという間に尽きてしまう。
  • Cursorは攻殻機動隊の世界でいう義体。

    • Devinだと難しいタスクはCursorと協業して進めるのがよい。
    • 操作するのは自分自身なので自分の関心を払い続ける必要があるが小回りがきく。
    • 月額制プランが有り課金上限も決められるので実装方針が固まっていないタスクや広範囲のファイルに影響がある修正でも○
  • ただしどちらも万能ではなく、指示やレビューを適切に行わないと意図と外れた成果物になりがち。

  • 生成AIのパワーを最大化するにはテストや静的解析やドキュメンテーションなど環境整備が必要。

Devinの特徴:スキマ時間に作業が進む“自律型”AI

指示すればPR作成&修正まで自動対応

Devinは「完全自律型AIエンジニア」と銘打つだけあって、Slackで指示すればブランチ作成→実装→PullReq作成→lintの修正→PR上にコメントしたフィードバックに対する修正まで自律的に進めてくれるやってくれるのが強みです。

Devinについての詳細は鹿野さんが書いた以下の記事が詳しいのでぜひ。

https://zenn.dev/ubie_dev/articles/devin-for-test

EpicやPBIの整理、レビュー対応、MTG準備など開発以外の仕事に追われていると、ブランチ切り替えやちょっとした修正が面倒になりがち。
そこをDevinに任せることでコンテキストスイッチの負担を減らせます。

スクショも撮影してくれるので成果物の確認もかんたん

とくに便利な機能が、スクリーンショット撮影機能です。Devinが使うマシンにはエディタとターミナルだけでなくブラウザも用意されているので、
「npm run devでアプリケーションを立ち上げて。localhost:xxxx にブラウザでアクセスしてスクリーンショットを撮影してチャットで送って」 のように指示すればSlackに画像を送ってくれます。

私は社内管理画面の機能開発をDevinにお願いすることが多いのですが、「〇〇の作成画面からテストデータを入稿して、詳細画面のスクショをちょうだい」といえばローカル環境を立ち上げたりQA環境にデプロイしなくても画面の状態をチェックできます。

自分自身で開発環境を立ち上げなくてもよいので、なんならスマホからDevinに指示 → スクショ確認 → 追加修正 → 人間がPRをApprove&マージ、という流れで一つの開発チケットが完結することもできてしまいます。

「Knowledge」機能で自動で学習・成長する

Devinは指示やフィードバックを「Knowledge」として自動で蓄積し、同様のシチュエーションで再利用します。
「Knowledge」は人間が修正したり、覚えてほしくない内容は却下することも可能です。
公式Docに "Devin is a junior engineer and has lots to learn."[1] とありますが、まさにDevinとの協業はジュニアエンジニアを育成しているような感覚で、使えば使うほど自分の好みやプロジェクトの癖を覚えていくのが魅力です。

https://twitter.com/empitsu88/status/1878982098427760796

公式推奨のユースケース

Devin公式サイトでも、「朝イチに細かいタスクを並行して走らせておき、昼休みにドラフトPRをチェックする」とか、「Slackスレッドでバグの話をしていたらDevinを召喚してすぐ修正させる」といった活用法が推奨されています。[2]
多忙なエンジニアがスキマ時間を徹底活用するのにうってつけです。

Cursorの特徴:腰を据えた開発や実装方針の検討に

VSCodeベース+AI拡張

CursorはVSCodeをベースに、AIがコードの解釈や実装をサポートしてくれるエディタです。
「Composer Agent」や「Yoloモード」などを使うと、コード修正~lint/test実行~PR作成まで自動化できます。
プロジェクトの独自ルールやガイドラインを.cursorrule.cursor/rulesに書くことで指示を簡略化し、出力の品質を向上することも可能です。

Cursorについての詳しい使い方は以下の記事もご覧ください。

https://zenn.dev/ubie_dev/articles/624c9034cc9b43

実務で使うなら月額課金のPro/Businessプランがおすすめ。

ただし、premium requestsとしてカウントされるモデルだと使用できるリソースに上限があるのでその点は注意

使い切ったあと追加でリソースを購入する場合は従量課金 or 一定量を買い切りもできます。

なので厳密には使い放題ではないですが、Cursorはこのあたりのリソース使用量の減りが Devin と比べてかなり緩やかな印象があります。

Ubieでは40ドルのBusinessプランを導入しており、課金上限額も40ドルとしているためその範囲で活用しています。

https://zenn.dev/ubie_dev/articles/2c474a1c5f71a8

DevinやCursorでは“まだ難しいところ”

大量のファイルの単純な修正はAIを使わないほうが早いケースも

大量のファイルにわたる修正をDevinに依頼すると、あっという間に購入したリソース(DevinではAgent Compute Unit - ACUと呼ばれます)が消費されコスパが悪いと感じる場合があります。例えば以下のような使い方です:

  • lintのルールを修正したのち、発生した大量のlintエラーをつぶす
  • 古いコンポーネントを使用している箇所を大量に置き換える

1つ目は、Devinがlintの実行→エラー内容の解析→該当ファイルの読み取り→修正→lint再実施…
を繰り返すせいか、Devinの消費リソースが思ってたよりかかってしまいました。
2つ目の例も「使用箇所の検索→読み取り→修正…」を繰り返すので作業内容の割には高くついた感じました。

一方Cursorは使うモデルを工夫すれば月額定額ですし、premium requests扱いのモデルであってもリソースの消費量はDevinと比べておだやかなので、リファクタや実験的実装を何度試したり修正するファイル数が多くなっても安心です。
ただし大量のファイルを修正するときは処理が重く、実行中はエディタを触りにくいので待ち時間が長いのがネック。作業中は他のアプリで別タスクをするなど工夫しましょう。

単純な文字列置換やlintエラーの修正などであれば、人間がエディタの「検索と置換」や補完機能を使った方が速いこともあるので、AIに任せるかどうかはケースバイケースで見極めが必要です。

深いドメイン知識が要求される場合

独自のアーキテクチャになっていたりや、ドメイン知識がないと意図が読み解けないような複雑な業務ロジックが多いリポジトリで、実装方針が曖昧なままDevinやCursorに丸投げすると的外れなコードが生成されがちです。
CIや自動テスト、静的解析などで不整合を機械的に検出できるようにするほか、ドキュメントの整備などでリポジトリの型やルールをAIにわかりやすく提示する工夫が必要になります。

生成AIのポテンシャルを最大限活かすために、生成AI以外で戦略的に投資するべきことはなんなのかについては以下の記事に詳しく書かれています。

https://note.com/yukukotani/n/nb3b76fcf881c

非エンジニアが一人で使いこなすにはまだハードルが高い

デザイナーやPdMなど、エンジニア以外のメンバーが依頼から実装完了まですべてAIで完結できると理想ですが、現状ではエンジニアリング知識がゼロだと難しい面が多いです。

まず、AIが提案した実装が、機能要件や品質要件を本当に満たしているかを判断できないと、そもそも要件を外れた修正が入っていても気づけないことがあります。

特にDevinは修正箇所や修正方針を具体的に指示しないと、意図と異なる実装が続き、再修正→再修正で消費するリソースがかさみがちです。

Devin公式Docでも "Treat Devin like a junior engineer. Assign Devin tasks a junior engineer or intern could figure out if provided with sufficient, clear instructions."[3] と書かれているため、ジュニアエンジニアやインターンでも理解できる明快で小さめのタスクを依頼する必要があります。

Cursorもローカル開発環境のセットアップが必要なのでそもそも非エンジニアにはハードルが高いですし、こちらもAIの成果物が妥当かどうかを判断するスキルは必要です。

ただ、軽微なUI修正や文言修正程度なら弊社Ubieでもデザイナーが問題なく使えていますし、
それ以上の機能修正でも環境整備を行えば可能性はあると感じています。

例えば、CIやテストを整備して機械的に品質をチェックできる仕組みを充実させたり、Devinがスクリーンショットを撮りやすいようUIカタログや開発者用の画面導線を整備しておくなどです。
現時点では「指示とレビューを適切に行う力」が欠かせませんが、そうした整備を行えば、徐々にハードルは下がっていくはずです。

具体的な使い分けシーン

ケース1: ちょっとしたPR修正をスキマ時間で → Devin

  • 「開発作業中、レビューを出していた別のブランチにちょっとした指摘を受けた」
  • 「小さな修正なのに今の作業をstashなりcommitなりして、別のブランチに切り替えるのが面倒…」

こんなときは、SlackでDevinに依頼すればOK。
Devinは新規ブランチの作成だけでなく既存ブランチに対する修正もできるため、「○○ブランチをcheckoutして、この関数名を変更して」など一言だけで済み、数分後にはcommitがpushされます。
自分のコンテキストスイッチを最小限に抑えられるのが魅力です。

↑自分の実装の修正を途中からDevinにお願いする様子

ケース2: Slackでの会話中に思いついた改善を即実装 → Devin

  • 「同僚とSlackでバグを議論中、ついでに関連画面のちょっとした改善案が出た」
  • 「PBIを立てて…詳細をチケットに書いて…リファインして…とやるとなんだかんだで時間がかかる」

SlackスレッドでDevinを呼び出すと、会話内容を踏まえつつ修正とPR作成まで進めてくれます。アイデアをすぐ形にできるスピード感が、多忙な現場では非常に助かります。

**「PBIを立ててリファインするまでもなくさっさと実装するほうが早いレベルの改善」**をバシバシ進めたいときに最適です。

↑ Slackのやりとりの途中でもDevinを呼んで即修正できる。

ケース3: 実装方針から模索したい / 影響範囲が多岐にわたる大きめのイシューを実装したい → Cursor

  • 「リファクタや設計の方向性をAIと対話しながら練りたい」
  • 「影響範囲が多岐にまたがる機能を実装したい」

こうした腰を据えたタスクはCursorが得意です。使うモデルによっては月額定額ですし、premium requests扱いのモデルであってもDevinよりもリソースの減りが穏やかなので、リファクタや実験的実装を何度試したり修正するファイル数が多くなっても安心です。

自分のチームではスクラムを導入していますが、「Story pointが5以上」のチケットではDevinだとコスパが悪くCursorを使うことにしています。

ケース4: 開発以外のタスクに追われている時 → Devin

  • 「採用関連の打ち合わせ、ドキュメント整理、次のスクラムイベントのリファインなど、開発以外が山積みで、開発に集中するまとまった時間があまり取れない…」

そんなときは、複数のDevinを並行稼働させ、細かい修正をどんどん依頼。

Devinであれば成果物のスクリーンショットも送ってくれるので、合間にPRの状況をチェックすれば昼休みや仕事の合間にリリースできる状態まで持っていけます。
「自分がブランチをcheckout→開発環境を立ち上げて画面を確認」としなくてもSlackとPRの確認だけでapprove、マージまでもっていけるのでコンテキストスイッチを減らせるのが非常にありがたいです。

Cursorは義体でDevinはタチコマ

自分自身は開発以外のタスク(ドキュメント整備やMTG準備、PBI起票など)が多いのと、なにかと気が散りがちな性格なのでコンテキストスイッチングコストがかからないDevinには特に助けられています。
一方でDevinの成果物や能力はまだジュニアエンジニアっぽさがあるので、Devinだと難しそうだな、と感じたタスクにはCursorを使っています。

社内では攻殻機動隊の世界観にたとえて「Cursorは義体でDevinはタチコマ」と表現していたメンバーがおり、なるほどなとなりました。

Cursor as 義体:
自分自身のパワーや能力をブーストするのはCursor。操作するのは自分自身なので自分の関心を払い続ける必要があるが小回りがきく。

Devin as タチコマ:
簡単なことを勝手にいい感じにやってほしいときはDevin。ちゃんと指示すれば最後までやってくれるので作業中は自分の関心を払わなくて良い。

といったところでしょうか。

まとめ

  • Devinは攻殻機動隊の世界でいうタチコマ。

    • 複数のタスクを並行して依頼が可能で、スクリーンショットの撮影も可能なので開発以外の仕事が多いエンジニアが、スキマ時間でタスクを進めるのに最適。
    • ただし、ジュニアエンジニアだと思って扱う必要があり、依頼するタスクは明確で小さなものでないと課金分のリソース(ACU)があっという間に尽きてしまう。
  • Cursorは攻殻機動隊の世界でいう義体。

    • Devinだと難しいタスクはCursorと協業して進めるのがよい。
    • 操作するのは自分自身なので自分の関心を払い続ける必要があるが小回りがきく。
    • 月額制プランが有り課金上限も決められるので実装方針が固まっていないタスクや広範囲のファイルに影響がある修正でも○
  • ただしどちらも万能ではなく、指示やレビューを適切に行わないと意図と外れた成果物になりがち。

  • 生成AIのパワーを最大化するにはテストや静的解析やドキュメンテーションなど環境整備が必要。

生成AIをフル活用する現場で一緒に働きませんか?

Ubieでは、「最新の生成AIをすぐ試せる環境」と「新しいツールの導入を積極的に行うカルチャー」が根付いており、DevinやCursor以外の生成AIサービスもいち早く試しています。

https://note.com/tamosan_01/n/nc9ba156dac78

もし、この記事を読んでUbieの生成AI活用や、そちらを積極的に利活用した業務推進に興味を持たれた方がいれば、ぜひ以下をご覧ください。
Ubieは、新たなチャレンジを楽しみながら成長していく仲間を歓迎しています。

https://recruit.ubie.life/

脚注
  1. https://docs.devin.ai/get-started/devin-intro#limitations ↩︎

  2. https://docs.devin.ai/essential-guidelines/when-to-use-devin ↩︎

  3. https://docs.devin.ai/essential-guidelines/when-to-use-devin ↩︎

Ubie テックブログ

Discussion